Re: [Elecraft] K4 and RTTY question

[Stewart Bryant]

+1

Stewart/G3YSX

> On 23 Jul 2020, at 15:46, Paul Christensen  wrote:
> 
> I dread the thought that the K4 includes an embedded variant of the
> RemoteRig -- as a means to accelerate product development.  Although it's
> probably too late for Elecraft to consider a real, internal WK chip (and
> negotiate a deal with K1EL), that would have been my preferred method of
> generating CW from a remote location.  

__
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to arch...@mail-archive.com 

Re: [Elecraft] K4 and RTTY question

[Gordon LaPoint]

I have had good luck with the RemoteRig setup with RTTY when running 
N1MM, but it is much better with WriteLog.  WriteLog was much more 
tolerant of the jitter and lag in internet connections than N1MM was.

Gordon - N1MGO

On 7/23/2020 13:50 PM, E.H. Russell wrote:

Hi Paul,

I also had good luck with the dual WKUSB setup here. Haven't tried RemoteRig
but I do know of a few top contesters that seem to get good results with it.
Will be interesting to see what the K4 does.


ED / W2RF




-Original Message-
From: elecraft-boun...@mailman.qth.net  On
Behalf Of Paul Christensen
Sent: Thursday, July 23, 2020 10:47 AM
To: elecraft@mailman.qth.net
Subject: [Elecraft] K4 and RTTY question


"This includes RemoteRig boxes, the YCCC SO2R Box, the Mortty, etc.
None

of them will pass the WKTEST program."

After two years, I gave up.  RemoteRig's internal keyer and COM port path
when using N1MM are flat-out awful unless the Internet connection has
extremely low latency and jitter.  Low-error results cannot be accomplished
from multiple remote sites while traveling.  No amount of adjusting over a
two year period would correct all the timing errors.

I'm now using two WinkeyerUSB boxes and K1EL's Remote Software.  One WKUSB
box is installed at each end of the link.  CW from paddles or keyboard is
always perfect even with marginal internet connections.  Setup is easy and
having a WKUSB at the control point also gives me four physical memory
buttons.  The box is small and doesn't add much weight or space inside a
remote equipment case.

I dread the thought that the K4 includes an embedded variant of the
RemoteRig -- as a means to accelerate product development.  Although it's
probably too late for Elecraft to consider a real, internal WK chip (and
negotiate a deal with K1EL), that would have been my preferred method of
generating CW from a remote location.

Paul, W9AC

__

Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html Message
delivered to e...@qrv.com

__
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to gordon.lapo...@gmail.com



__
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to arch...@mail-archive.com 

Re: [Elecraft] K4 and RTTY question

[E.H. Russell]

Hi Paul,

I also had good luck with the dual WKUSB setup here. Haven't tried RemoteRig
but I do know of a few top contesters that seem to get good results with it.
Will be interesting to see what the K4 does.


ED / W2RF




-Original Message-
From: elecraft-boun...@mailman.qth.net  On
Behalf Of Paul Christensen
Sent: Thursday, July 23, 2020 10:47 AM
To: elecraft@mailman.qth.net
Subject: [Elecraft] K4 and RTTY question

>"This includes RemoteRig boxes, the YCCC SO2R Box, the Mortty, etc.  
>None
of them will pass the WKTEST program."

After two years, I gave up.  RemoteRig's internal keyer and COM port path
when using N1MM are flat-out awful unless the Internet connection has
extremely low latency and jitter.  Low-error results cannot be accomplished
from multiple remote sites while traveling.  No amount of adjusting over a
two year period would correct all the timing errors.  

I'm now using two WinkeyerUSB boxes and K1EL's Remote Software.  One WKUSB
box is installed at each end of the link.  CW from paddles or keyboard is
always perfect even with marginal internet connections.  Setup is easy and
having a WKUSB at the control point also gives me four physical memory
buttons.  The box is small and doesn't add much weight or space inside a
remote equipment case.

I dread the thought that the K4 includes an embedded variant of the
RemoteRig -- as a means to accelerate product development.  Although it's
probably too late for Elecraft to consider a real, internal WK chip (and
negotiate a deal with K1EL), that would have been my preferred method of
generating CW from a remote location.  

Paul, W9AC   
   
__
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html Message
delivered to e...@qrv.com 

__
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to arch...@mail-archive.com 

[Elecraft] K4 and RTTY question

[Paul Christensen]

>"This includes RemoteRig boxes, the YCCC SO2R Box, the Mortty, etc.  None
of them will pass the WKTEST program."

After two years, I gave up.  RemoteRig's internal keyer and COM port path
when using N1MM are flat-out awful unless the Internet connection has
extremely low latency and jitter.  Low-error results cannot be accomplished
from multiple remote sites while traveling.  No amount of adjusting over a
two year period would correct all the timing errors.  

I'm now using two WinkeyerUSB boxes and K1EL's Remote Software.  One WKUSB
box is installed at each end of the link.  CW from paddles or keyboard is
always perfect even with marginal internet connections.  Setup is easy and
having a WKUSB at the control point also gives me four physical memory
buttons.  The box is small and doesn't add much weight or space inside a
remote equipment case.

I dread the thought that the K4 includes an embedded variant of the
RemoteRig -- as a means to accelerate product development.  Although it's
probably too late for Elecraft to consider a real, internal WK chip (and
negotiate a deal with K1EL), that would have been my preferred method of
generating CW from a remote location.  

Paul, W9AC   
   
__
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to arch...@mail-archive.com 

Re: [Elecraft] K4 and RTTY question

[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, fra...@pwpconsult.com (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:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to arch...@mail-archive.com 

Re: [Elecraft] K4 and RTTY question

[john]

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:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to arch...@mail-archive.com 

Re: [Elecraft] K4 and RTTY question

[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:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to arch...@mail-archive.com 

Re: [Elecraft] K4 and RTTY question

[Bill Frantz]

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, n...@arrl.net (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*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.  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  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:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to arch...@mail-archive.com 

Re: [Elecraft] K4 and RTTY question

[Joe DeVincentis]

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  wrote:
> 
> On Mon, Jul 20, 2020 at 7:03 AM Joe DeVincentis  > 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 
>  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 pr

Re: [Elecraft] K4 and RTTY question

[Bob Wilson, N6TV]

On Mon, Jul 20, 2020 at 7:03 AM Joe DeVincentis  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
 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:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to arch...@mail-archive.com 

Re: [Elecraft] K4 and RTTY question

[Christopher Hoover]

+1 for winkeyer support.   73 de AI6KG

On Mon, Jul 20, 2020, 7:03 AM Joe DeVincentis  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  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*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.  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  > 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:Elecraft@mailman.qth.net
> >>
> >> This list hosted by: http://www.qsl.net
> >> Please help support this email list: http://www.qsl.net/donate.html
> >> Message delivered to n...@arrl.net 
> >>
> > __
> > 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  >
> > Post: mailto:Elecraft@mailman.qth.net 
> >
> > This list hosted by: 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 j...@ko8v.net 
> __
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:Elecraft@mailman.qth.net
>
> This list hosted by: http://www.qsl.net
> Please help support this email list:

Re: [Elecraft] K4 and RTTY question

[Joe DeVincentis]

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  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*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.  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  > 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:Elecraft@mailman.qth.net
>> 
>> This list hosted by: http://www.qsl.net
>> Please help support this email list: http://www.qsl.net/donate.html
>> Message delivered to n...@arrl.net 
>> 
> __
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft 
> 
> Help: http://mailman.qth.net/mmfaq.htm 
> Post: mailto:Elecraft@mailman.qth.net 
> 
> This list hosted by: http://www.qsl.net 
> Please help support this email list: http://www.qsl.net/donate.html 
> 
> Message delivered to j...@ko8v.net 
__
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to arch...@mail-archive.com 

Re: [Elecraft] K4 and RTTY question

[Bob Wilson, N6TV]

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*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.  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  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:Elecraft@mailman.qth.net
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to n...@arrl.net
>
__
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to arch...@mail-archive.com 

[Elecraft] K4 and RTTY question

[Bill Frantz]

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:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to arch...@mail-archive.com