Elecraft

K4 and RTTY question

Classic

List

Threaded

10 messages Options

Bill Frantz

K4 and RTTY question

I'm getting ready for NAQP RTTY today, and I am reminded of an
old bug using the KY CAT command to send RTTY text. I am using
RUMlogNG on my MacBook Pro in contest mode which uses the CAT
interface to send and receive RTTY. (It also uses CAT with CW.)

If I try to chain output, e.g. press the function key to send my
callsign several times, frequently the first parts of the
chained output are dropped, as shown by the text shown in the
VFO-B display.

This does not occur on CW, so I think the CW to Data conversion
may be involved. The command is defined in the programmer's
Reference as:

KY (CW or CW-to-DATA Keying from Text;

If I chain by using a K3 memory and pressing the M1-4 button
several times, the VFO-B display shows "CHAIN" and things appear
to work correctly.

I will admit, that while I can check what is being sent by
listening to the monitor tones with CW, but I can't quite be
sure about the RTTY.

Will this problem be fixed on the K4?

73 Bill AE6JV

-----------------------------------------------------------------------
Bill Frantz | When an old person dies, a | Periwinkle
(408)348-7900 | library burns. - Joe McGawon | 150
Rivermead Rd #235
www.pwpconsult.com | Irish Ethnographer |
Peterborough, NH 03458

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

Bob Wilson, N6TV

Re: K4 and RTTY question

Bill,

Before it can be "fixed" in the K4, the logging software has to be fixed to
send the proper KY command. If it is sending KY<blank>*somes-string*;,
then the messages are not going to be chained. If it is sending KYW
*some-string*;, then the messages should be properly chained, perhaps with
a very brief pause in between if 0x04 (Ctrl-D, ^D or EOT -- ASCII End of
Transmission character) is appended at the very end of a each chained
message, before the terminating semicolon. The "W" means "wait for message
completion," as documented in the K3 Programming Manual.

However, once a message sent via KYW starts, you will not be able to
interrupt the transmission by pressing "Escape" or sending an "RX;"
command. The RX; won't be processed until the message completes, which
isn't very helpful.

Maybe *that* will be addressed (somehow) in the K4.

In sum, if you need chaining more than you need message interrupt
capability, use KYW in your macros. If you need message interrupt
capability more than you need chaining, use KY<blank>. If you need both,
maybe you'll have to "wait" (sorry) to see if the K4 team comes up with
some way to interrupt chained messages already in progress via a special
"high priority" software command or key tap.

73,
Bob, N6TV

On Sat, Jul 18, 2020 at 7:39 AM Bill Frantz <[hidden email]> wrote:

> I'm getting ready for NAQP RTTY today, and I am reminded of an
> old bug using the KY CAT command to send RTTY text. I am using
> RUMlogNG on my MacBook Pro in contest mode which uses the CAT
> interface to send and receive RTTY. (It also uses CAT with CW.)
>
> If I try to chain output, e.g. press the function key to send my
> callsign several times, frequently the first parts of the
> chained output are dropped, as shown by the text shown in the
> VFO-B display.
>
> This does not occur on CW, so I think the CW to Data conversion
> may be involved. The command is defined in the programmer's
> Reference as:
>
> KY (CW or CW-to-DATA Keying from Text;
>
> If I chain by using a K3 memory and pressing the M1-4 button
> several times, the VFO-B display shows "CHAIN" and things appear
> to work correctly.
>
> I will admit, that while I can check what is being sent by
> listening to the monitor tones with CW, but I can't quite be
> sure about the RTTY.
>
> Will this problem be fixed on the K4?
>
> 73 Bill AE6JV
>
> -----------------------------------------------------------------------
> Bill Frantz | When an old person dies, a | Periwinkle
> (408)348-7900 | library burns. - Joe McGawon | 150
> Rivermead Rd #235
> www.pwpconsult.com | Irish Ethnographer |
> Peterborough, NH 03458
>
> ______________________________________________________________
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:[hidden email]
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to [hidden email]
>

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

Joe DeVincentis

Re: K4 and RTTY question

Personally, I'd like to see the K4 support something like the TinyFSK protocol for doing RTTY.

It could present multiple serial ports. one for CAT, one for FSK and one for Keying. The FSK could emulate tinyFSK and the keyer could emulate the K1EL keyers. That way programs don't need to fight over who gets the serial ports.

While I despise the following phrase as a SW guy (specifically embedded real time operating systems): Hey, it's just S/W. I can see this as very doable in the K4 given what I know about the architecture to date.. Much harder in the K3s.

Joe, KO8V

> On Jul 19, 2020, at 18:50, Bob Wilson, N6TV <[hidden email]> wrote:
>
> Bill,
>
> Before it can be "fixed" in the K4, the logging software has to be fixed to
> send the proper KY command. If it is sending KY<blank>*somes-string*;,
> then the messages are not going to be chained. If it is sending KYW
> *some-string*;, then the messages should be properly chained, perhaps with
> a very brief pause in between if 0x04 (Ctrl-D, ^D or EOT -- ASCII End of
> Transmission character) is appended at the very end of a each chained
> message, before the terminating semicolon. The "W" means "wait for message
> completion," as documented in the K3 Programming Manual.
>
> However, once a message sent via KYW starts, you will not be able to
> interrupt the transmission by pressing "Escape" or sending an "RX;"
> command. The RX; won't be processed until the message completes, which
> isn't very helpful.
>
> Maybe *that* will be addressed (somehow) in the K4.
>
> In sum, if you need chaining more than you need message interrupt
> capability, use KYW in your macros. If you need message interrupt
> capability more than you need chaining, use KY<blank>. If you need both,
> maybe you'll have to "wait" (sorry) to see if the K4 team comes up with
> some way to interrupt chained messages already in progress via a special
> "high priority" software command or key tap.
>
> 73,
> Bob, N6TV
>
> On Sat, Jul 18, 2020 at 7:39 AM Bill Frantz <[hidden email] <mailto:[hidden email]>> wrote:
>
>> I'm getting ready for NAQP RTTY today, and I am reminded of an
>> old bug using the KY CAT command to send RTTY text. I am using
>> RUMlogNG on my MacBook Pro in contest mode which uses the CAT
>> interface to send and receive RTTY. (It also uses CAT with CW.)
>>
>> If I try to chain output, e.g. press the function key to send my
>> callsign several times, frequently the first parts of the
>> chained output are dropped, as shown by the text shown in the
>> VFO-B display.
>>
>> This does not occur on CW, so I think the CW to Data conversion
>> may be involved. The command is defined in the programmer's
>> Reference as:
>>
>> KY (CW or CW-to-DATA Keying from Text;
>>
>> If I chain by using a K3 memory and pressing the M1-4 button
>> several times, the VFO-B display shows "CHAIN" and things appear
>> to work correctly.
>>
>> I will admit, that while I can check what is being sent by
>> listening to the monitor tones with CW, but I can't quite be
>> sure about the RTTY.
>>
>> Will this problem be fixed on the K4?
>>
>> 73 Bill AE6JV
>>
>> -----------------------------------------------------------------------
>> Bill Frantz | When an old person dies, a | Periwinkle
>> (408)348-7900 | library burns. - Joe McGawon | 150
>> Rivermead Rd #235
>> www.pwpconsult.com | Irish Ethnographer |
>> Peterborough, NH 03458
>>
>> ______________________________________________________________
>> Elecraft mailing list
>> Home: http://mailman.qth.net/mailman/listinfo/elecraft
>> Help: http://mailman.qth.net/mmfaq.htm
>> Post: mailto:[hidden email]
>>
>> This list hosted by: http://www.qsl.net
>> Please help support this email list: http://www.qsl.net/donate.html
>> Message delivered to [hidden email] <mailto:[hidden email]>
>>
> ______________________________________________________________
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft <http://mailman.qth.net/mailman/listinfo/elecraft>
> Help: http://mailman.qth.net/mmfaq.htm <http://mailman.qth.net/mmfaq.htm>
> Post: mailto:[hidden email] <mailto:[hidden email]>
>
> This list hosted by: http://www.qsl.net <http://www.qsl.net/>
> Please help support this email list: http://www.qsl.net/donate.html <http://www.qsl.net/donate.html>
> Message delivered to [hidden email] <mailto:[hidden email]>

Christopher Hoover

Re: K4 and RTTY question

+1 for winkeyer support. 73 de AI6KG

On Mon, Jul 20, 2020, 7:03 AM Joe DeVincentis <[hidden email]> wrote:

> Personally, I'd like to see the K4 support something like the TinyFSK
> protocol for doing RTTY.
>
> It could present multiple serial ports. one for CAT, one for FSK and one
> for Keying. The FSK could emulate tinyFSK and the keyer could emulate the
> K1EL keyers. That way programs don't need to fight over who gets the
> serial ports.
>
> While I despise the following phrase as a SW guy (specifically embedded
> real time operating systems): Hey, it's just S/W. I can see this as very
> doable in the K4 given what I know about the architecture to date.. Much
> harder in the K3s.
>
> Joe, KO8V
>
> > On Jul 19, 2020, at 18:50, Bob Wilson, N6TV <[hidden email]> wrote:
> >
> > Bill,
> >
> > Before it can be "fixed" in the K4, the logging software has to be fixed
> to
> > send the proper KY command. If it is sending KY<blank>*somes-string*;,
> > then the messages are not going to be chained. If it is sending KYW
> > *some-string*;, then the messages should be properly chained, perhaps
> with
> > a very brief pause in between if 0x04 (Ctrl-D, ^D or EOT -- ASCII End of
> > Transmission character) is appended at the very end of a each chained
> > message, before the terminating semicolon. The "W" means "wait for
> message
> > completion," as documented in the K3 Programming Manual.
> >
> > However, once a message sent via KYW starts, you will not be able to
> > interrupt the transmission by pressing "Escape" or sending an "RX;"
> > command. The RX; won't be processed until the message completes, which
> > isn't very helpful.
> >
> > Maybe *that* will be addressed (somehow) in the K4.
> >
> > In sum, if you need chaining more than you need message interrupt
> > capability, use KYW in your macros. If you need message interrupt
> > capability more than you need chaining, use KY<blank>. If you need both,
> > maybe you'll have to "wait" (sorry) to see if the K4 team comes up with
> > some way to interrupt chained messages already in progress via a special
> > "high priority" software command or key tap.
> >
> > 73,
> > Bob, N6TV
> >
> > On Sat, Jul 18, 2020 at 7:39 AM Bill Frantz <[hidden email]
> <mailto:[hidden email]>> wrote:
> >
> >> I'm getting ready for NAQP RTTY today, and I am reminded of an
> >> old bug using the KY CAT command to send RTTY text. I am using
> >> RUMlogNG on my MacBook Pro in contest mode which uses the CAT
> >> interface to send and receive RTTY. (It also uses CAT with CW.)
> >>
> >> If I try to chain output, e.g. press the function key to send my
> >> callsign several times, frequently the first parts of the
> >> chained output are dropped, as shown by the text shown in the
> >> VFO-B display.
> >>
> >> This does not occur on CW, so I think the CW to Data conversion
> >> may be involved. The command is defined in the programmer's
> >> Reference as:
> >>
> >> KY (CW or CW-to-DATA Keying from Text;
> >>
> >> If I chain by using a K3 memory and pressing the M1-4 button
> >> several times, the VFO-B display shows "CHAIN" and things appear
> >> to work correctly.
> >>
> >> I will admit, that while I can check what is being sent by
> >> listening to the monitor tones with CW, but I can't quite be
> >> sure about the RTTY.
> >>
> >> Will this problem be fixed on the K4?
> >>
> >> 73 Bill AE6JV
> >>
> >> -----------------------------------------------------------------------
> >> Bill Frantz | When an old person dies, a | Periwinkle
> >> (408)348-7900 | library burns. - Joe McGawon | 150
> >> Rivermead Rd #235
> >> www.pwpconsult.com | Irish Ethnographer |
> >> Peterborough, NH 03458
> >>
> >> ______________________________________________________________
> >> Elecraft mailing list
> >> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> >> Help: http://mailman.qth.net/mmfaq.htm
> >> Post: mailto:[hidden email]
> >>
> >> This list hosted by: http://www.qsl.net
> >> Please help support this email list: http://www.qsl.net/donate.html
> >> Message delivered to [hidden email] <mailto:[hidden email]>
> >>
> > ______________________________________________________________
> > Elecraft mailing list
> > Home: http://mailman.qth.net/mailman/listinfo/elecraft <
> http://mailman.qth.net/mailman/listinfo/elecraft>
> > Help: http://mailman.qth.net/mmfaq.htm <http://mailman.qth.net/mmfaq.htm
> >
> > Post: mailto:[hidden email] <mailto:[hidden email]>
> >
> > This list hosted by: http://www.qsl.net <http://www.qsl.net/>
> > Please help support this email list: http://www.qsl.net/donate.html <
> http://www.qsl.net/donate.html>
> > Message delivered to [hidden email] <mailto:[hidden email]>
> ______________________________________________________________
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:[hidden email]
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to [hidden email]
>

Bob Wilson, N6TV

Re: K4 and RTTY question

In reply to this post by Joe DeVincentis

On Mon, Jul 20, 2020 at 7:03 AM Joe DeVincentis <[hidden email]> wrote:

> Personally, I'd like to see the K4 support something like the TinyFSK
> protocol for doing RTTY.
>

There's really no urgent reason to do this once the KY host command is
improved to allow message stacking with interrupt capability. If you want
to use TinyFSK (which has its own problems), connect a Mortty to the K4 ACC
port, same as you would on a K3. If you don't want to solder your own
DE-15 connector, or if your ACC port is already occupied, use a Y-BOX
<https://bit.ly/Y-BOX> plus 3.5mm stereo to dual RCA cable to connect
Mortty to K3 or K4. I have a few of both still in stock. It will take a
few weeks to order more boards if there is sufficient demand.

It could present multiple serial ports. one for CAT, one for FSK and one
> for Keying.

This is already in plan. The K4 provides two virtual serial ports via the
USB cable (FTDI), one legacy 9-pin serial port, plus the 15-pin ACC port.
Any of them may be used for FSK keying, PTT, and CW keying, using MMTTY or
your logging software. This is keying via TXD, DTR, or RTS pins, with no
external hardware required (unless using ACC pins). EXTFSK will be
required on the virtual serial ports. The 9-pin legacy port will not
require EXTFSK if your PC serial port or USB-to-Serial adapter doesn't
require it (example: Edgeport/4).

The FSK could emulate tinyFSK and the keyer could emulate the K1EL
> keyers. That way programs don't need to fight over who gets the serial
> ports.
>

There will be no more fights over the serial port because the K4 has more
than one, and they will operate independently and in parallel (unlike
Icom rigs, which provide one and only one virtual serial port pin at a time
for PTT keying).

TinyFSK has a problem. Using it with MMTTY and a Mortty, try the "send
RYRYRY... forever" macro while using TinyFSK.FSK. Hear the problem? It
hesitates every 32 characters or so. So its timing is not as "perfect" as
claimed, at least not with that configuration.

While I despise the following phrase as a SW guy (specifically embedded
> real time operating systems): Hey, it's just S/W. I can see this as very
> doable in the K4 given what I know about the architecture to date.. Much
> harder in the K3s.
>

As a software guy, you can appreciate that it is impossible to perfectly
emulate someone else's code (or chip) if you have no access to the source
code, and only work from the external API. Lots of devices have attempted
to emulate the WinKey interface, but none of them are 100% compatible with
the chip. This includes RemoteRig boxes, the YCCC SO2R Box, the Mortty,
etc. None of them will pass the WKTEST program (
https://www.hamcrafters2.com/WKTESTX.html), last time I tried. The
RemoteRig emulator works OK with N1MM+, but not with Win-Test or DXLog.net
(unless you select a unique option). These programs all use the WinKey
chip differently. They work fine with a real chip not with the emulators.
The only devices that pass the WinKey 100% compatibility tests are devices
that use a real WinKey chip inside, such as those provided by the microHAM
devices.

Retooling the K4 to put a real WinKey chip or Mortty hardware inside, or
attempting emulation via firmware, could delay K4 shipment or distract from
other higher priority issues. It could also raise the price a bit. I
don't think anyone wants to see either.

Finally, there's no reason for Elecraft to try to take sales opportunities
away from the manufacturers of WinKey and Mortty devices, is there?

73,
Bob, N6TV
https://bit.ly/Y-BOX
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

Joe DeVincentis

Re: K4 and RTTY question

My intent was not to emulate the exact H/W and its problems, but the APIs used (eg, programs using TinyFSK send [ , then text and ] to end the TX). I know TinyFSK has issues. But I was not intending that Elecraft copy the problems. I just wanted something similar to what TinyFSK does ( send a '[' to start transmit, send characters, send ']' to end). It could even be something different. Just something other than having to string together KY macros which doesn't seem to work well with software other than the K3 utility in conversation mode.

As to the emulating of the winkeyer, I can't comment too much on it as I'm not a CW guy nor a user of a winkeyer product. If it is tough to get a good emulation on it, then it may not be a good candidate. I can live with that, others may have different opinion.

The intent is to reduce the number of cables and boxes involved. One cable from the K4 to the computer and I get everything I need to do every digital mode that can be generated on a computer). In addition, I don't have to rely on the Windows machine to do any thing but send data characters to the machine at rates faster than the radio can put it out on the air (e.g send RTTY characters at 9600 baud for 45.45 output). That ensures, I'm not at the mercy of Windows stalling on a character send due its lack of being able to do anything with determinism. That's why I'm. not a fan of using windows keying a line to generate FSK. Too many non real time issues to have the guarantee.

My goal is as perfect a(n) RTTY signal as I can get when I'm using that mode. I've been looking at the TinyFSK code to see if I can fix the issues i have with it - I've already found one bug in the software (500 doesn't fit in 8 bits). But that project got put on hold when K4 was announced with the hope I wasn't going to need it. But if I need it to get a near perfect 45.45 baud, I'll resurrect it and make it work. The little arduinos should be more than capable. If not with the original code, I'll put a better RTOS on it.

As to taking business away from Mortty and Winkeyer, Is Elecraft wrong for taking business from the SDR guys because they put that capability in their radios? Is it wrong that I don't need to buy remote rig anymore? Again, no. That's two businesses that loose out because of the K4. And I was considering the purchase of both of those up until the K4 was announced.

It's the nature of business - adapt or die.

So far Elecraft has done well adapting. From what I see the K4 is a great example of adapting. They listen to their customers and to date they can see the handwriting on the wall when things change (touchscreen with knobs, SDR, Ethernet, remote capability all built in). As an example of listening, I can personally attest to it. When I chatted with Eric at Dayton about the K4, I gave him an idea for the machine. It was good enough that he stopped chatting, put a note in his phone and asked me not to patent it. I don't think he was kidding either. Maybe he was, but it did make me feel good. I just hope that idea made it into the radio.

Joe,
KO8V

> On Jul 20, 2020, at 12:52, Bob Wilson, N6TV <[hidden email]> wrote:
>
> On Mon, Jul 20, 2020 at 7:03 AM Joe DeVincentis <[hidden email] <mailto:[hidden email]>> wrote:
> Personally, I'd like to see the K4 support something like the TinyFSK protocol for doing RTTY.
>
> There's really no urgent reason to do this once the KY host command is improved to allow message stacking with interrupt capability. If you want to use TinyFSK (which has its own problems), connect a Mortty to the K4 ACC port, same as you would on a K3. If you don't want to solder your own DE-15 connector, or if your ACC port is already occupied, use a Y-BOX <https://bit.ly/Y-BOX> plus 3.5mm stereo to dual RCA cable to connect Mortty to K3 or K4. I have a few of both still in stock. It will take a few weeks to order more boards if there is sufficient demand.
>
> It could present multiple serial ports. one for CAT, one for FSK and one for Keying.
>
> This is already in plan. The K4 provides two virtual serial ports via the USB cable (FTDI), one legacy 9-pin serial port, plus the 15-pin ACC port. Any of them may be used for FSK keying, PTT, and CW keying, using MMTTY or your logging software. This is keying via TXD, DTR, or RTS pins, with no external hardware required (unless using ACC pins). EXTFSK will be required on the virtual serial ports. The 9-pin legacy port will not require EXTFSK if your PC serial port or USB-to-Serial adapter doesn't require it (example: Edgeport/4).
>
> The FSK could emulate tinyFSK and the keyer could emulate the K1EL keyers. That way programs don't need to fight over who gets the serial ports.
>
> There will be no more fights over the serial port because the K4 has more than one, and they will operate independently and in parallel (unlike Icom rigs, which provide one and only one virtual serial port pin at a time for PTT keying).
>
> TinyFSK has a problem. Using it with MMTTY and a Mortty, try the "send RYRYRY... forever" macro while using TinyFSK.FSK. Hear the problem? It hesitates every 32 characters or so. So its timing is not as "perfect" as claimed, at least not with that configuration.
>
> While I despise the following phrase as a SW guy (specifically embedded real time operating systems): Hey, it's just S/W. I can see this as very doable in the K4 given what I know about the architecture to date.. Much harder in the K3s.
>
> As a software guy, you can appreciate that it is impossible to perfectly emulate someone else's code (or chip) if you have no access to the source code, and only work from the external API. Lots of devices have attempted to emulate the WinKey interface, but none of them are 100% compatible with the chip. This includes RemoteRig boxes, the YCCC SO2R Box, the Mortty, etc. None of them will pass the WKTEST program (https://www.hamcrafters2.com/WKTESTX.html <https://www.hamcrafters2.com/WKTESTX.html>), last time I tried. The RemoteRig emulator works OK with N1MM+, but not with Win-Test or DXLog.net (unless you select a unique option). These programs all use the WinKey chip differently. They work fine with a real chip not with the emulators. The only devices that pass the WinKey 100% compatibility tests are devices that use a real WinKey chip inside, such as those provided by the microHAM devices.
>
> Retooling the K4 to put a real WinKey chip or Mortty hardware inside, or attempting emulation via firmware, could delay K4 shipment or distract from other higher priority issues. It could also raise the price a bit. I don't think anyone wants to see either.
>
> Finally, there's no reason for Elecraft to try to take sales opportunities away from the manufacturers of WinKey and Mortty devices, is there?
>
> 73,
> Bob, N6TV
> https://bit.ly/Y-BOX <https://bit.ly/Y-BOX>

Bill Frantz

Re: K4 and RTTY question

In reply to this post by Bob Wilson, N6TV

I don't think the logging software is the problem. Since the KY
command works for both CW and RTTY, I tried an experiment: I
switched the mode using the K3's front panel from Data to CW and
the problem did not occur. (I listened to the monitor output.)
The UI for the program still showed RTTY, so I don't think it
noticed my change and changed its behavior.

There may be a problem handling the Control-D character in the
K3. This character is ignored in CW, but it tells the K3 to stop
sending RTTY when processed in RTTY. My guess is that RUMlogNG
appends it to all KY sends. If another KY command's data is
added to existing data in the buffer, The Control-D at the end
of the first set of data may cause the second KY's data to lose
the first character.

What should happen if the last character in the buffer is a
Control-D, and more data is added, is to remove the Control-D so
the two sets of data are merged for transmission.

Now I'm getting tempted to haul the KX3 up next to the K3 and
decode what actually goes out over the air. Another interesting
question is what happens if the first character of the second
part of a chain is a "W"?

BTW, I worked on similar software systems when writing the
Tymnet interface for Tymshare's IBM/370 VM systems.

73 & GL Bill AE6JV

On 7/19/20 at 6:50 PM, [hidden email] (Bob Wilson, N6TV) wrote:

>Bill,
>
>Before it can be "fixed" in the K4, the logging software has to be fixed to
>send the proper KY command. If it is sending KY<blank>*somes-string*;,
>then the messages are not going to be chained. If it is sending KYW
>*some-string*;, then the messages should be properly chained, perhaps with
>a very brief pause in between if 0x04 (Ctrl-D, ^D or EOT -- ASCII End of
>Transmission character) is appended at the very end of a each chained
>message, before the terminating semicolon. The "W" means "wait for message
>completion," as documented in the K3 Programming Manual.
>
>However, once a message sent via KYW starts, you will not be able to
>interrupt the transmission by pressing "Escape" or sending an "RX;"
>command. The RX; won't be processed until the message completes, which
>isn't very helpful.
>
>Maybe *that* will be addressed (somehow) in the K4.
>
>In sum, if you need chaining more than you need message interrupt
>capability, use KYW in your macros. If you need message interrupt
>capability more than you need chaining, use KY<blank>. If you need both,
>maybe you'll have to "wait" (sorry) to see if the K4 team comes up with
>some way to interrupt chained messages already in progress via a special
>"high priority" software command or key tap.
>
>73,
>Bob, N6TV
>
>On Sat, Jul 18, 2020 at 7:39 AM Bill Frantz <[hidden email]> wrote:
>
>>I'm getting ready for NAQP RTTY today, and I am reminded of an
>>old bug using the KY CAT command to send RTTY text. I am using
>>RUMlogNG on my MacBook Pro in contest mode which uses the CAT
>>interface to send and receive RTTY. (It also uses CAT with CW.)
>>
>>If I try to chain output, e.g. press the function key to send my
>>callsign several times, frequently the first parts of the
>>chained output are dropped, as shown by the text shown in the
>>VFO-B display.
>>
>>This does not occur on CW, so I think the CW to Data conversion
>>may be involved. The command is defined in the programmer's
>>Reference as:
>>
>>KY (CW or CW-to-DATA Keying from Text;
>>
>>If I chain by using a K3 memory and pressing the M1-4 button
>>several times, the VFO-B display shows "CHAIN" and things appear
>>to work correctly.
>>
>>I will admit, that while I can check what is being sent by
>>listening to the monitor tones with CW, but I can't quite be
>>sure about the RTTY.
>>
>>Will this problem be fixed on the K4?
>>
>>73 Bill AE6JV

-----------------------------------------------------------------------
Bill Frantz | Since the IBM Selectric, keyboards have gotten
408-348-7900 | steadily worse. Now we have touchscreen keyboards.
www.pwpconsult.com | Can we make something even worse?

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

Bill Frantz

Re: K4 and RTTY question

In reply to this post by Bill Frantz

I got spotted 3 times with AE6JV and once with E6JV. ??!!??

Headed back to Rivermead after watching the comet. TTYL

73 Bill AE6JV

-----------------------------------------------------------------------
Bill Frantz | Truth and love must prevail | Periwinkle
(408)348-7900 | over lies and hate. | 150 Rivermead Rd #235
www.pwpconsult.com | - Vaclav Havel | Peterborough, NH 03458

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

john@kk9a.com

Re: K4 and RTTY question

In reply to this post by Bill Frantz

I thought that the suggestion to include WinKey and FSK hardware was a
good one. It would be nice to plug directly in instead of needing
additional peripherals. There already is an internal keyer in most
newer transceivers so business was taken away from the many external
keyer manufactures as technology improved.

John KK9A

Bob Wilson, N6TV wrote:

Retooling the K4 to put a real WinKey chip or Mortty hardware inside, or
attempting emulation via firmware, could delay K4 shipment or distract from
other higher priority issues. It could also raise the price a bit. I
don't think anyone wants to see either.

Finally, there's no reason for Elecraft to try to take sales opportunities
away from the manufacturers of WinKey and Mortty devices, is there?

73,
Bob, N6TV

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

Bill Frantz

Re: K4 and RTTY question

In reply to this post by Bill Frantz

Apologies to the list. The message quoted below was meant just
for N6TV.

[I have BCCed the author of RUMlogNG.]

By way of explanation, After my last post on this thread, I got
a telephone call from TV Bob, N5TV. We discussed the problem and
narrowed it down quite a bit.

We assume that RUMlogNG is sending RTTY data using the KY CAT
command(*). We also assume that is isn't using using the W
(wait) feature. We also assume that it is ending every string
with EOT to quickly stop transmission.

The UI of RUMlogNG is basically a standard contest logger. It
has function keys, with basically the same definition of those
in N1MM. You can also send free text by typing it into a window
and using buttons to send and stop sending.

What I observe: If I try to chain sends by pressing a function
key before the entire previous function key message has been
sent, frequently the first character of the chained message is
dropped. My usual use case is to press F4 several times to send
my call multiple times. I first noticed that the "A" in my call,
AE6JV, was being dropped.

When TV Bob and I discussed the issue, one of our theories was
that the problem was only in the K3's logic that displayed the
output of the send. We decided to set up a test using the
Reverse Beacon Network (RBN) to discover what was actually being
sent on the air.

I set up F1 to be a bunch of CQs followed by DE, "CQ CQ CQ CQ CQ
DE". I then started transmitting the CQ message by pressing F1
followed by 2 presses of F4. I observed the problem on the K3's display.

My message to TV Bob was the results of looking at the RBM
spots. I will note that while E6JV can be a valid call (from
Niue, DXCC Entity #188), the RBN did not report any spots before
I started my experiment. The spot generated from my experiment
is the right time and frequency to be one of my transmissions.

73 Bill AE6JV

On 7/20/20 at 11:09 PM, [hidden email] (Bill Frantz) wrote:

>I got spotted 3 times with AE6JV and once with E6JV. ??!!??
>
>Headed back to Rivermead after watching the comet. TTYL
>
>73 Bill AE6JV

* The (edited and abridged) description of the KY command from
the Programmer's Reference:

KY (CW or CW-to-DATA Keying from Text; GET/SET)

SET format: KY*[text]; where * is normally a BLANK and [text] is
0 to 24 characters. If * is a W (for “wait”), processing of
any following host commands will be delayed until the current
message has been sent. This is useful when a KY command is
followed by other commands that may have side-effects, e.g., KS
(keyer speed).
Basic RSP format: KYn; where n is 0 (CW text buffer not full) or
1 (buffer full). Also see TB command.

The following keyboard characters are mapped to CW "prosigns":
( KN + AR = BT % AS * SK ! VE

In addition to these prosigns, these special characters can be
inserted anywhere in the KY command text:

< Puts the K3 into TX TEST mode, until a '>' character is received
> Returns the K3 to TX NORM mode
@ In CW mode, this character normally terminates any CW
message (via KY or manual send), emulating the K2. However,
tapping 2 in CONFIG:CW WGHT changes ‘@’ to a prosign: the
‘at’ sign as used in e-mail addresses. This is the newest
Morse Code character; it can be remembered as the prosign
‘AC’ (as in “the At Character”).

^D (EOT, ASCII 04) Quickly terminates transmission; use with CW-to-DATA.

-------------------------------------------------------------------------
Bill Frantz | When it comes to the world | Periwinkle
(408)348-7900 | around us, is there any choice | 150
Rivermead Rd #235
www.pwpconsult.com | but to explore? - Lisa Randall |
Peterborough, NH 03458

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]