Remote Footswitch - How to (LAN/ VPN solution)

Richard - W1RW

Michael, This problem still occurs when Flow control is set to "None" or when it is set to "Hardware".  I am using a FTDI Cable. https://www.amazon.com/gp/product/B07RBK2P47/ref=ppx_yo_dt_b_asin_title_o05_s01?ie=UTF8&psc=1

It is wired as was illustrated by Mark - W3II with the Black (GND) and Brown(CTS) on each side of the switch and a 10K resistor between Red(VCC) and Brown(CTS)

Mike-VA3MW

OK, thanks.  On mine, I have no extra parts.  I short Pin 7-8 or 4-6 through the foot switch (see the first post) so that makes the solution I am using different.  

Mike 

WX7Y

I hate to even say anything on this subject because of the attitudes and comments by some FLEX employees in past posts BUT seeing MANY more people are trying remote operation now have also ran into this issue and I'll try to help before they get to frustrated and stop trying because it really is a awesome experience to run remote. 

 I tried several different USB to COM Port devices from different manufactures with both FTDI and Prolific chip sets and I finially found a Cable on Amazon from "Plugable" 
 https://www.amazon.com/gp/product/B00425S1H8/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1# 

This cable has worked for me on my 2 NUC computers, a couple Laptops and a Windows Tablet for the last 8 months after several months and many cables trying to fix this issue and being told it wasn't a "SmartSDR CAT" issue even though FRStack worked with all the cables I tried.

I did not have to use any external pull up resisters or debounce circuit with this cable,  I hope this cable works for the majority of those who try it BUT like anything  else with Windows OS and all the different hardware AND driver configuration of course it may or may not work for you so your mileage WILL vary.
(BE SURE to download the correct drivers from the cable manufacture) 

GOOD LUCK and hope it helps you out and the cable works for you like they have for me. 

73's 
Bret 
WX7Y

Mike-VA3MW

Hi Bret

Please do not take this the wrong way.  I want to get it to fail.   

In order to get it fixed at some point, I have to have it fail in a LAB environment so that we can then toss more tools at it to see what or why it is failing.  If I can get it to fail, then I can run some serial port monitors and look at the registers.   

Right now, we are dealing with 2 serial ports.  The physical one the foot switch is on and the other virtualized in SmartSDR CAT.  Which one is failing when this fails, I have no idea sadly and all we have is the symptom.    

Just to confirm, are you using my solution or Marc's?  On mine, I just have a DB 9 connector on the end of my foot switch connected to pins 7 and 8.  Oh, since the thread is a bit long, is this with or without SmartLink?

If FRStack works, that is great and a solid and valid solution.   

73 and enjoy the long weekend, Mike 

WX7Y

I am only using the PTT in SmartCAT DB9 ports RTS Pins 7 & 8.
My original Posts started about year ago for my foot switch and heil thumb PTT switch issues. 
as I stated in my previous post a few minutes ago I tried many cables and finally found one that works so I put the rest aside. 
I tried several different buffering and debouncing circuits using 2N7000's, relays and opto isolator but still worked the same until I got the "Plugable" cable then I abandoned all the junk I built because there was no difference then just the cable which work fine and didn't want another failure point.  
This happened with SmartLink and direct on the same network
On my Windows tablet I couldn't have the overhead from FRStack with it's limited resources so I needed a direct connection

Bret
WX7Y

Mike VE3CKO

I've recently setup a Studio C, in our sunroom and implemented this PPT method to my computer using a USB to serial with FTDI chipset. The Heil footswitch is unusable as it stays keyed until you press down a bunch of times, the Heil handswitch is better but bothersome as every other xmission I have to key 2 or 4 times to xmit.

My radio is a 6700 with the latest software. Has anything been determined if it's a chipset or software issue?

Mike-VA3MW

@Mike VE3CKO

What pins are you using for the foot switch?

Mike

Mike VE3CKO

7 & 8 as per for RTS

Mike-VA3MW

Hi Mike

That is strange. Can you try a different USB/RS232 adapter? Could there be power saving turned on with it?

Also, watch in the LOG on SmartSDR CAT and see if you the TX ON and OFF messages.

We have had a few report the same thing and I can't recreate it. I've even used Prolific USB adatpers without issue, as long Windows can see it.

Mike

Mike VE3CKO

Here is the log from Heil handswitch

Engaging handswitch:

2021-01-18 12:28:28.352 COM19 [rcvd]: TX1;

2021-01-18 12:28:28.405 COM19 [rcvd]: TX1;

2021-01-18 12:28:28.419 COM19 [rcvd]: TX1;

2021-01-18 12:28:28.419 COM19 [rcvd]: TX1;

2021-01-18 12:28:28.420 COM19 [rcvd]: TX1;

2021-01-18 12:28:30.179 COM19 [rcvd]: TX1;

Lettting go:

2021-01-18 12:28:30.180 COM19 [rcvd]: TX1;

2021-01-18 12:28:30.182 COM19 [rcvd]: TX0;

I may have to put a de-bouncer in there. I will have to find one of four hundred or so 555 timers in some box somewhere. Now that I thought about it I remembered coming across another post related in the past of of a software debouncer. Yes, I found it:

https://community.flexradio.com/discussion/6987425/push-to-vox-version-1-0-0-is-now-available

I googled found latest version 1.0.2 on github https://github.com/K1DBO/push-to-vox/releases/tag/1.0.0

Ran the program set the comport for the PTT, used the default latch times. This has fixed the problem on both the Heil hand switch and foot pedals. I can't see anything now in the log for that comport PTT any longer.

Mike-VA3MW

I wasn't even aware that that was written by Don. Very nice.

There is also an FTStack version.

No, you won't see TX commands any more since the app it communicating to the radio via the TCP/IP port.

73

WX7Y

I could never get any of the FTDI several REAL FTDI chipset's I tried worked with out PTT dropouts, even the ones FLEX sells so I tried the Cable Maters Prolific chipset cable with the latest PL2303 chipset and it NEVER skipped a beat.

I used this cable on several laptops and my work Desktop in remote operation and it just works.

I bought several of these cables and they all worked the same so it is repeatabley.

Your mileage may vary of course

Tom OK1DWQ

I recognize same problem. I have FTDI chip. With FRstack not problem work and with SmartCAT 1 of 3 ptt activation not going bias into linear

Tom OK1DWQ

Mike-VA3MW

I have seen the same thing with the FTDI dongles. I suspect there is some setting within Windows Device Manager that should resolve it, but I haven't had a chance to look deeper.

Howard K7JNX

Mike, I've tried your solution from the top of this discussion using both a (non FTDI) USB-to-RS232 converter and a real physical RS232 port on a card plugged into the PC motherboard. I've tried it with both RTS and DTR. And I've tried using various values of resistance between the pins. I've also tried setting flow control to hardware instead of none. In no case does it work well enough to be usable.

Here's a typical trace of what the physical RS232 port sees:
Depress switch
2021-04-25 21:59:42.101 COM4 [rcvd]: TX1;
Release switch
2021-04-25 21:59:47.610 COM4 [rcvd]: TX0;
2021-04-25 21:59:47.614 COM4 [rcvd]: TX0;
2021-04-25 21:59:47.618 COM4 [rcvd]: TX0;
Depress switch
2021-04-25 21:59:55.534 COM4 [rcvd]: TX1;
2021-04-25 21:59:55.540 COM4 [rcvd]: TX0;
2021-04-25 21:59:55.544 COM4 [rcvd]: TX1;
release switch
2021-04-25 22:00:02.060 COM4 [rcvd]: TX0;
depress switch
2021-04-25 22:00:10.688 COM4 [rcvd]: TX1;
2021-04-25 22:00:10.703 COM4 [rcvd]: TX0;
2021-04-25 22:00:10.706 COM4 [rcvd]: TX1;
release switch
2021-04-25 22:00:40.508 COM4 [rcvd]: TX0;
2021-04-25 22:00:40.510 COM4 [rcvd]: TX0;
2021-04-25 22:00:40.513 COM4 [rcvd]: TX0;
2021-04-25 22:00:40.514 COM4 [rcvd]: TX0;
2021-04-25 22:00:40.519 COM4 [rcvd]: TX0;
depress switch
2021-04-25 22:01:02.631 COM4 [rcvd]: TX1;
2021-04-25 22:01:02.637 COM4 [rcvd]: TX0;
2021-04-25 22:01:02.641 COM4 [rcvd]: TX1;
release switch
2021-04-25 22:01:04.120 COM4 [rcvd]: TX0;
depress switch
2021-04-25 22:01:05.674 COM4 [rcvd]: TX1;
2021-04-25 22:01:05.679 COM4 [rcvd]: TX1;
2021-04-25 22:01:05.731 COM4 [rcvd]: TX1;
release switch
2021-04-25 22:01:07.245 COM4 [rcvd]: TX0;
2021-04-25 22:01:07.247 COM4 [rcvd]: TX1;
2021-04-25 22:01:07.251 COM4 [rcvd]: TX0;
2021-04-25 22:01:07.253 COM4 [rcvd]: TX0;
2021-04-25 22:01:07.256 COM4 [rcvd]: TX0;
2021-04-25 22:01:07.261 COM4 [rcvd]: TX0;
2021-04-25 22:01:07.266 COM4 [rcvd]: TX0;
depress switch
2021-04-25 22:01:10.135 COM4 [rcvd]: TX1;
2021-04-25 22:01:10.139 COM4 [rcvd]: TX0;
2021-04-25 22:01:10.140 COM4 [rcvd]: TX1;
release switch
2021-04-25 22:01:11.698 COM4 [rcvd]: TX0;
depress switch
2021-04-25 22:01:14.185 COM4 [rcvd]: TX1;
2021-04-25 22:01:14.189 COM4 [rcvd]: TX0;
2021-04-25 22:01:14.192 COM4 [rcvd]: TX1;
release switch
2021-04-25 22:01:15.634 COM4 [rcvd]: TX0;
depress switch
2021-04-25 22:01:18.245 COM4 [rcvd]: TX1;
2021-04-25 22:01:18.250 COM4 [rcvd]: TX0;
2021-04-25 22:01:18.252 COM4 [rcvd]: TX1;
release switch
2021-04-25 22:01:52.885 COM4 [rcvd]: TX0;
depress switch
2021-04-25 22:01:54.654 COM4 [rcvd]: TX1;
2021-04-25 22:01:54.657 COM4 [rcvd]: TX0;
2021-04-25 22:01:54.659 COM4 [rcvd]: TX1;
release switch
2021-04-25 22:03:08.798 COM4 [rcvd]: TX0;
depress switch
2021-04-25 22:03:10.992 COM4 [rcvd]: TX1;
2021-04-25 22:03:11.002 COM4 [rcvd]: TX1;
2021-04-25 22:03:11.007 COM4 [rcvd]: TX1;
release switch
2021-04-25 22:03:12.299 COM4 [rcvd]: TX0;

Clearly the physical port is seeing lots of contact bounce that the SSDR software needs to debounce (but presumably is not currently doing) before passing it to the virtual PTT port and thence to the radio.

About half the time the radio goes into xmit even after all the bouncing. When it fails, some of the time it goes into transmit but does not pass any audio (very peculiar!) and the rest of the time it does not go into transmit at all.

When it works, the MOX button is lit, the noise floor on the panadapter falls, and there is signal in the slice passband.

When it fails the first way, it goes into transmit, the noise floor on the panadapter falls, but there is no signal in the passband.
When it fails the second way, the MOX button does not light, the noise floor does not fall and there is no signal in the passband.

Howard, K7JNX

Mike-VA3MW

Hi Howard

Not sure what to say. It may need a pull up to get it to settle down. You may need to scope the pins. On mine that I posted orgianally, I didn't use any resistance at all. I suspect this is in the actual hardware. I can't recreate this with my hardware.

If it keeps flopping from TX1 to TX0 then windows is telling CAT that the level has changed.

You also may want to look in Windows Device Manager and make sure the Hardware flow control it turned on since you are now using hardware control levels.

The other option is to use FRStack and see if the switch behaves better. In the FRStack wiring he does have some resisters involved.

73

Mike-VA3MW

Here is the FRStack wiring

https://community.flexradio.com/discussion/8023558/frstack-and-remote-ptt

Mike-VA3MW

Another idea if you want to give this a try, it looks like this tool will allow you to monitor the RS232 port levels.

You should be able to see if they are solid or not.

https://realterm.sourceforge.io/#Pins__Status

Mike

KD0RC

Thanks for this Mike. This is an easy way for me to get debugging info from my TeensyMaestro without bringing up the Arduino environment. I don't control the rig with USB data, but I do send debugging info there.

Mike-VA3MW

This is a nagging problem for me as well. When I get rid of some other projects I'll see about getting to debug it further.

Howard K7JNX

Mike,

Re your suggestion to try using the frstack wiring: THAT'S IT!!!

Here's a sample trace using real COM4 configured for no flow control in Windows device manager:

2021-04-28 16:28:09.659 COM4 [rcvd]: TX1;

2021-04-28 16:28:09.667 COM4 [rcvd]: TX1;

2021-04-28 16:28:10.871 COM4 [rcvd]: TX0;

2021-04-28 16:28:10.876 COM4 [rcvd]: TX0;

2021-04-28 16:28:12.893 COM4 [rcvd]: TX1;

2021-04-28 16:28:12.898 COM4 [rcvd]: TX1;

2021-04-28 16:28:14.333 COM4 [rcvd]: TX0;

2021-04-28 16:28:14.336 COM4 [rcvd]: TX0;

2021-04-28 16:28:15.971 COM4 [rcvd]: TX1;

2021-04-28 16:28:15.975 COM4 [rcvd]: TX1;

2021-04-28 16:28:17.214 COM4 [rcvd]: TX0;

2021-04-28 16:28:17.216 COM4 [rcvd]: TX0;

No stuttering or bouncing, and the MOX operation seems very reliable. Presumably the double TX1 and double TX0 are due to the fact that I enabled both DTS and RTS in setting up the virtual PTT port. Understand, this is not using frstack, only the frstack wiring diagram with the K0VM real port + virtual PTT port combo you described at the beginning of this discussion.

Oh, it's important that the polarity is active high.

Thanks for your ideas and help.

73, Howard, K7JNX

Mike-VA3MW

BTW, I updated this one too.

https://community.flexradio.com/discussion/8023558/frstack-and-remote-ptt

K4XD

[EDIT] I hadn't noticed there was a page 2 to this thread - I will try the de-bounce suggestions, that's probably what's happening. FYI, using the Heil footswitch [/EDIT]

I tried setting this up for the ARRL SSB Sweepstakes contest this past weekend. Chipset of the RS-232 to USB adapter is FTDI. Wired the footswitch between pins 7 & 8, set up CAT as shown above. Set flow control of the COM port to Hardware. When I close the footswitch, the MOX button turns blue but the letters MOX are sometimes white, sometimes gray. No audio is transmitted if the letters are gray, but it is transmitted when the letters are white. Has anyone figured this out? I will implement the FRStack version in the meantime.

BA4KW

choose between pin 7 & 8 short a 104 capacitor, which perfectly solves the anti shake problem

KI5RLR

> @Mike-VA3MW said:
> First, I want to thank Al, K0VM for this solution.  He provided it just as I needed it.

> Mike va3mw

Thanks! This worked like a champ using my Heil HMM connected to my laptop.

KI5RLR