SSDR V3 CAT not communicating on existing serial port

DaveAB3I

I'm trying to interface a Raspberry Pi RP2040 (Pico) based MCU board with SmartSDR via the CAT software. I'm running SSDR V3 (latest) on Windows 11.

The RP2040 board has a USB to serial chip onboard and appears on the PC as COM5. I've connected to the MCU board with PuTTY and it is passing serial data back and forth with the PC just fine, 38400 baud, recommended Flex settings from N1MM for start, stop, and parity, and with flow control set to NONE in Putty.

SSDR CAT is also passing traffic back and forth with PuTTY just fine when I connect PuTTY to a VSP (COM9 in this case), using the same settings for PuTTY as I used to talk to the MCU board. If I type "ZZFA;" in the PuTTY serial terminal, I can see the data streaming in on the logging window, with a response from the radio as soon as it sees ";".

However, if I have SSDR CAT connect directly to the existing COM5 port that the MCU board creates, no traffic passes either direction. If I open the logging/debugging terminal on that COM5 I can get the radio to respond to a command entered on the terminal, but the MCU board never sees that data, and none of the data the MCU sends makes it to the radio.

If I use a third party bridging app to bridge COM5 with COM9, it works, so the actual format of the data itself does not appear to be the issue.

Can anyone offer any insight into how SSDR connects to existing ports that might explain why the MCU board can't just pass traffic directly to SSDR on a CAT port, as any other hardware device might be expected to? I've explored the possibility of Flow Control causing an issue, PuTTY can talk to both fine with flow control set to "none". The software that bridges COM5 and COM9 only works if that software is set to have DTR and RTS both set to ENABLED.

I'm about at wit's end with this project, I've been swearing at it for the better part of 8 hours now and it seems to be deaf to my pleas for mercy.

David Decoons, wo2x

My guess is the Pi and PC both are presenting as DCE. You would need a “crossover” or null modem.

What you could do is use a USB A to A bull modem FTDI cable. That would allow DCE to communicate to DCE.

These cables are about $40 from Mouser and DigiKey.

73 Dave wo2x

John KB4DU

Null modem.

David Decoons, wo2x

As John said, and after reading your issue again, if using true serial between the two adapters, a null modem adapter. Or as I mentioned, the USB A to USB A null modem FTDI cable.

Dave wo2x

DaveAB3I

Posted to say that the null modem cable didn't work at all, but testing it with other devices, I think I got a dodgy cable. Will report back.

DaveAB3I

The Null Modem cable does indeed just prevent the RP2040 board from communicating with any software on the PC. Since all other applications, including serial bridge software, serial terminals, data loggers, and the Arduino IDE can all communicate with both the RP2040 and SSDR CAT strongly points to it not being an issue of both systems expecting DCE from the other.

Anyone familiar with flow control in SSDR CAT? That's still the most obvious issue, but I can't find any information on this at all.

Mike-VA3MW

Did you watch the data flow in SmartSDR CAT? Highlight the Serial port and then click on the Log... button on the bottom of SmartSDR CAT.

That will allow you to watch the data flow.

DaveAB3I

Yes, the SSDR CAT log window sees no traffic from the RP2040. If a command is entered in the log window test box, the radio responds, however the RP2040 never sees that traffic. All of this traffic moves normally when talking to PuTTY instead, and the RP2040 and radio can talk to each other if I create a CAT VSP, and use serial port bridging software to connect that VSP to the RP2040's existing port.

Mike-VA3MW

You can't connect those 2 ports directly to each other without setting up a VSP Bridge between them. That part is required.

DaveAB3I

Ahh ok, any recommendations for good serial bridge software for windows? I've been using one that works but is really meant for developers, it's rather overkill for this.

Mike-VA3MW

There are many. I think I use Com0Com.

https://com0com.sourceforge.net/

David Decoons, wo2x

Best for Windows is Virtual Serial Port Emulator. It is the “Swiss Army Knife” of serial port utilities for Windows. It can create virtual cables, splitters, port forwarders, etc.

In your case, both the Pico and the CAT port are operating as DTE (computers), hence the need for the null modem “cable” between com 5 and 9.

Dave wo2x

DaveAB3I

I've been working this a bit more, and rereading the CAT manual, and I feel like I'm missing something, or not communicating what's going on well enough here.

Do all hardware devices that connect to a hardware COM port on a PC require bridge software to connect to SSDR CAT? If so, what is the point of SSDR CAT being able to connect to an existing port at all? Is it only for connecting to ports created by freestanding bridge software?

Dave, a null modem cable does not fix it, it renders the RP2040 entirely unable to communicate with the PC. With a standard USB cable the RP2040 is communicating with all other windows applications, and all other serial devices I've tried it with, without issue. Only SSDR CAT is failing to receive the traffic.

David Decoons, wo2x

The PC com port is designed to connect to devices such as amps, modems tuners, etc. it cannot connect to another computer with a straight through cable (Pi Pico). Computer to computer connections require RXd connects to TXd and TXd connect to RXd (null modem).

SmartSDR CAT does not require any flow control to start data flow. Sounds like the Pico may expect handshaking. Check out this site and the section null modem with Loopback handshaking.

73

Dave wo2x