Is keying possible via the API or CAT/Serial (RTS or DTR)?

Matt NQ6N

I'm wondering if it is possible to key the 6600 directly via the API (TCP) CAT, or Serial (RTS/DTR) methods.  I know it is possible to send morse characters using cwx or KY, but I am looking to control it more directly.  

It seems that only PTT Is supported via SmartSDR CAT on DTR or RTS, and I tested the Winkeyer implementation and it does not appear to support the tune command. 

So I am thinking that the only way to remotely key the transceiver would be to interface a separate hardware device to the key input connector on the back panel. 

Before I do that I wanted to post this here to double check that I have exhausted all possibilities.

73
Matt NQ6N 

Bob K8RC

DXLab suite does CW with a Flex 6x000 without intervening hardware of any kind. 

In fact the software's interface can use the TCP/IP interface to the radio so it doesn't require a COM port, virtual or otherwise.

And it's freeware! https://www.dxlabsuite.com/

Mike-VA3MW

I do a remote PTT keying on DTR or RTS mapping to  a hardware com port. 

I essentially ground either lead to cause the radio to go into TX for a remote foot switch.  This is all done without a hardware connection to the back of the radio.

If you search, several of us published the details.

What is it you are trying to actually do?

Mike va3mw

Eric-KE5DTO

Matt,

There is a keying interface in the API that we use for Maestro.  It requires periodic timing information in addition to the keying information to help sync the keying data with the radio's timing.  This is possible, but not dirt simple.  I can go into more detail if you wish.

Also, out of curiosity, what Winkeyer command were you trying to use that didn't work?  I want to make sure that this is something that we just haven't implemented as opposed to something that is implemented, but isn't working.  Thanks.

Steven WA8Y

Can you put it in RTTY mode?

Matt NQ6N

Eric -- The keying API you use for the Maestro sounds like it's along the lines of what I want(ed) to build, so more information about that API would be much appreciated. 

That API may be all I need, but even if it's not it sounds like it will give me plenty of control over keying.  I had been thinking of building an element level API but have not yet reached the point of determining whether sending timing information explicitly was going to be necessary. 

The Winkeyer command I tried was <0B><nn>, "key immediate".  

73,
Matt NQ6N

Mario_DL3LSM

Hi Eric,

I'm definitely interested in details about the keying interface API (NetCWStream I guess).

Thanks and 73
Mario, DL3LSM

Matt NQ6N

Just keeping this thread alive. 

Eric-KE5DTO

Sorry for the delayed response.  Here's the details.

The API uses a "cw ptt" and "cw key" commands.  You can see how we use these in Radio.cs of FlexLib (see the CWPTT and CWKey functions beginning near line 7761).

The timestamp is a 4 digit free-running millisecond counter that simply rolls over at 9999.  

So the commands are:

cw ptt [0 or 1] [4 digit ms timestamp]
cw key [0 or 1] [4 digit ms timestamp]

Note that the timestamps are used to understand the jitter on the connection so as to buffer appropriately int the radio to avoid the effect issues with network jitter would have on the on/off keying.  More jitter means more buffering (higher delays).

Matt NQ6N

Eric -- Fantastic. That's pretty much exactly how I was thinking of designing it.  It's great that you've already done the work to automatically adjust the buffering based on the jitter inference. 

Do you happen to know if the implementation ever truncates >1 word space into 1 word space if it determines that it can reduce the amount of buffering? 

Also, one other beginner question: Is there a way to connect to the tcp API via an existing SmartLink connection?  Or will I need to manage the remote connection to the 6600's tcp API separately from SmartLink (or initiate a separate SmartLink connection)?   In my case the rig is used 100% via SmartLink for CW.

Thanks again!

73,
Matt NQ6N

Eric-KE5DTO

Matt,

I'm not sure what you mean on the truncating word space.  Help me understand and I'm sure we can come up with the answer.

If you are interacting with the API, you will be making your own connection to the radio.  In other words, there isn't an interface that allows you to share an existing application's process communication to the radio.  You can build on top of FlexLib if you're using .NET on Windows or you can use the ethernet API to go straight to the TCP commands and status to/from the radio.  If you are remote, we would recommend you use SmartLink, though others have used VPN solutions without SmartLink with success.

Mario_DL3LSM

Hi Eric,

thanks for this info..

One question: what is reason for sending the "cw key" and "cw ptt" commands 4 times via VITA/UDP (every 5 ms) and once via TCP in FlexLib? How is this handled in the radio?

Thanks and 73
Mario, DL3LSM

Eric-KE5DTO

I didn't see anything in the code that would explain that.  Is this something you have observed?  If so, in what context?

Mario_DL3LSM

C# is not my programming language but that's how I interpret the code in Radio.cs:

        public void CWKey(bool state, string timestamp)
        {
            if (_netCWStream != null)
            {
                string cmd = "cw key " + Convert.ToByte(state) + " time=0x" + timestamp + " index=" + _netCWStream.GetNextIndex();
                //SendCommand("cw key " + Convert.ToByte(state) + " time=0x" + timestamp
                _netCWStream.AddTXData(cmd);
                Task.Factory.StartNew(() =>
                {
                    Thread.Sleep(5);
                    _netCWStream.AddTXData(cmd);
                });

                Task.Factory.StartNew(() =>
                {
                    Thread.Sleep(10);
                    _netCWStream.AddTXData(cmd);
                });

                Task.Factory.StartNew(() =>
                {
                    Thread.Sleep(15);
                    _netCWStream.AddTXData(cmd);
                });
                SendCommand(cmd);
            }
        }

73, Mario DL3LSM

Matt NQ6N

Maybe in case a UDP packet gets dropped?  The radio could ignore duplicate messages? 

Eric-KE5DTO

Ahhh yes.  Sorry.  I didn't realize this is to what you were referring.  I believe this is simply to help with dropped packets.  We did testing with automated random packet drops and this helps to harden the interface so that the keying still goes through even if something weird is going on in the network.  On the radio side, the first TCP packet to make it through gets processed and the others are ignored.

Mario_DL3LSM

Just for clarification: the TCP packet will make it allways through but the question is when.. So the first packet (command string) from the 4 UDP packets and the 1 TCP will be used and the others will be ignored..

Thanks and 73
Mario, DL3LSM

P.S. Looks like a new area to play around.. :-) 

Matt NQ6N

Eric -- I thought about it and realized that my question about word space doesn't make sense.  I have noticed the network quality updates coming over the API so I can test the scenario I was wondering about if it turns out to be relevant. 

Wayne

So how does Smartsdr for windows do the PTT in the lower right of the screen? I would think that is being done by API or tcp since thats how its working.

Eric-KE5DTO

There are status messages coming over TCP that the radio sends that updates the GUI.

Matt NQ6N

Eric -- Quick question regarding the cw key command.  Is the timestamp supposed to be the rolling integer milliseconds modulo 10000, represented as hexadecimal? 

I am running into an issue where it works perfectly until the timestamp loops around.  The next command that is sent once the timestamp has looped around fails. 

Not sure if there is any additional step needed... the following results in the radio staying keyed after the last command gets sent. 

CD42|cw key 1 time=0x26A5 index=2
CD43|cw key 0 time=0x26D1 index=3
CD44|cw key 1 time=0x26FD index=4
CD45|cw key 0 time=0x19 index=5

Any suggestions would be much appreciated.  

73,
Matt NQ6N

Eric-KE5DTO

It looks like the values are expected to be hex formatted as 0xnnnn where n is [0-9A-F].  So it would roll over after FFFF (2^16-1).  Sorry for the confusion.

Matt NQ6N

Perfect, works very nicely now!  

Matt NQ6N

I've written a small program to connect a Winkeyer (key and PTT output) to the computer via serial port and allow remote sidetone and paddle usage without needing a Maestro.  If anyone following this thread is interested in being an alpha tester of this program I am happy to share a download link. 

I've had a few short rag chews using the paddles and it seems to work nicely. Currently it works only via VPN remote, not via Smartlink. I'll add Smartlink support once I figure out how to trigger the login/discovery process.

Chris - NZ6T

Matt I just found this thread. If you're still working on the project I'd be interested in giving it a whirl.

Edit:
I found your Groups.io page for this. Thanks I'll give it a try

WX7Y

It's to Bad SmartCAT PTT with a real com port PTT has so many issues that have plagued it for so long, I have gone around and around with this for over a year, one time it keys just great and the next time it shows MOX and pass's MIC Audio showing on SmartSDR but the MOX and TUNE button's get grayed out and NO RF is produced like a interlock issue. 

No Problem with FRSTACK COM port PTT Keying and Matt NQ6N's little program working with the same hardware. 
 
I had everything working 98% of THE TIME with SmartCAT until the **** WIN10 1903 UPDATE broke the COM Ports and once I repaired them this is what I ran into. 
If it was a windows COM port problem then the other two programs would not work and SmartSDR would NOT show the MOX button working. 

Bret

Eric-KE5DTO

Bret,

If the radio is being keyed, then the issue probably isn't with the ports at all.  It sounds more like an issue in SmartSDR to me.  I'll be happy to work with you to figure it out if it is still happening.

WX7Y

I welcome help getting to the bottom of this and would appreciate it very much.

This has been happening in both version's of V3 and yes I kinda agree, only thing is that when I use another keying scheme it works perfect like the OLD "Push to VOX" and "FRstack"  you would think if it was SmartSDR then those would also disable "Grey OUT" the transmitter like it does in SmartCAT.
This does NOT happen every time but often enough you can't and don't want to use it. 

Thanks and hope to hear from you soon
73's

WX7Y

Hi Again Eric
Tried it on my laptop with a seperate USB Cable/PTT button and still have the same issues as the desktop.  Here is a screen shot when it fails, Notice the white lettering on TUNE and MOX is grayed out, This happens randomly with out warning. 
Radio is 6700, WIN10 64K, 3.0.27, FTDI USB cable.

This switch is Active High/DTR, the Switch on the Desktop uses Active Low/RTS as a test to see if one setup did it and the other did not but that makes NO difference.

Thanks and 73
Bret

Eric-KE5DTO

I setup a ticket to handle this.  If you don't see that, shoot me an email directly: eric@flex-radio.com.