Virtual Com / Serial ports - huh?

Walt - KZ1F

I almost added this as a comment on the thread about removing virtual ports but concluded their was tangential to that thread and, perhaps, merited it's on question based thread.

To be honest I never got my head around the whole virtual com port / VSP notion. Yes, I understand it is just another IPC (Inter Process Communication) model that clings tightly to the bygone era of pre-IP, pre-shared memory, COM1-COMn are king. The loopback portion of the TCP/IP stack has been around for over 25 years and works incredibly well. In fact, virtual com ports tie two processes to the same machine whereas only the 127.0.0.0/8 range ties two IP processes to the same box. My first exposure to COMn and LPTn was in 1978. I shutter at the thought some segments have not progressed beyond that. Part of this may be I went from a TS530 (pre CAT) to an F1500 to an F6500.
I am thinking outloud, so bear with me. So some OP controlling their whatever from their TRS-80 machine would use a serial cable to connect their TRS-80 to their radio. In that environment you really needed two serial ports, one on the computer (being generous to the TRS-80) and another on the radio. These two were tied via RTS CTS handshakes to pass the commands and acknowledgements. Take away the serial cable now the port may or may not exist, as often computers now don't have such archaic devices, preferring the orders of magnitude faster USBs. 

If the computer is hosting the radio, as would be the case with PSDR and SSDR then the flow is between two programs, i.e. HRD, Fldigi or some log program. So then that requires some program to be a shim for the absent physical port(s) and some logical pairing simulating two complementary ports each owned by a distinct process. In the case of com4 and com14 anything written to com4 can be read on com14 and visa versa? an RTS on com4 can be responded to by a cts on com14 and visa versa?

Two questions:
1) Does that pretty much cover it? This may be overly simplistic as it isn't terribly well gelled in my head.

2) Why are we still doing this, as opposed to just sending information sender blocks when buffer full and receiver receives data from buffer, or simple cmd/response like the tcp

Terry K8EET

Someone should put a video tutorial together about connecting external programs through DAC/CAT.

Tim - W4TME

Q1: The com port pair we used enumerates two serial ports in a null modem cable configuration.

Q2: This is a question for third-party applications that only provide a serial interface because that is what is on a majority of radios.  We would prefer if we never had to deal with another virtual anything, serial and sound cards.

Walt - KZ1F

Thank you Terry. Thank you Tim. Yes Tim, I agree with you on Q2. As I've said before it just strike me as such an anachronisms. But that is not an FRS issue as it needs to interact with 3,rd party apps. I didn't know if there was some compelling reason for apps to maintain such a dated technology.

KY6LA_Howard

@Walt

Blame it on the Japanese who have traditionally not been that advanced with the computer age.  So they continue to build radios with totally outdated serial and parallel port technology...  For example every Icom still comes with 1970's TTL (not even RS-232) CI-V port for communications.  You have to buy a CIV (TTL) to RS232 adapter in order to communicate with 1980's RS-232 peripherals...

This in turn forces the App and peripheral hardware developers to replicate COMx, LPT and Sound Card ports for their Apps to be able to communicated with the radios...

The good news is that times are SLOWLY Changing as more and more App developers are being pushed into the 21st Century to accommodate forward thinking companies like Flex and 4O3A who have adopted TCP/IP. communications standards.

Frankly I applaud Flex for NOT including a RS-232 interface on their radios

Michael Coslo

Japanese radios are becoming the trailing edge of technology. Which of course is why I have the radio I do now.

Walt - KZ1F

Totally agree Howard. In fact the reason I asked the question and followed it with trying to noodle out the why then ask if I got it right is professionally I probably did my last com port programming with my Imsai VDP-42 when I rewrote that portion of its control program to be reentrant. That was in 78.

Peter K1PGV

You've got it Walt. 100% correct. Though the details of the RTS/CTS, DSR/DTR flow control thing vary, mostly only apply to half-duplex, and are generally ignored today. Because the vast majority of rigs are still "out in the physical world"... and serial port interfaces are cheap, well understood, and shared in common by devices of all types(radios and other things), serial port interfaces still make sense. App developers seek to maximize ROI, and thus write for the most common cases... or don't want to deal with changing their rig interfacing at all once it's been written and tested. The reason we haven't seen these interfaces disappear is that there's no common standard for "in box" program-to-program communication for amateur radio. Flex has a unique protocol; Some other rig/package/tool has another protocol, etc. But, heck... just about everyone understands "Kenwood" serial protocol. So, we wind-up with virtual serial port drivers (which are surprisingly difficult to write, by the way... a true nightmare to make those ports *really* look like hardware serial ports). Someday, maybe somebody will create a standard ham radio network-based protocol. That'd work in box, off the box, across the internet, wherever. Ah, some day... I hope that helps, at least some. Peter K1PGV

IW7DMH, Enzo

This is almost right, but 90% of devices out there use serial ports. I think it is a gap "today" ignoring this fact at all: we are in a kind of paradox because we have a standalone remotable rig that needs a personal computer for devices integration.
The RS232 issue should be splitted in two parts: one for the software and another for the hardware.
For the first one, SSDR-Cat is the great solution. Nothing can beat a dedicated virtual serial driver. For the second one SSDR-Cat can't be the best solution.
It would be desiderable and add-on board/box just to keep things simpler and (I think) to make simpler the "migration" steps to the ssdr attracted but frightened hams.

73' Enzo
iw7dmh

Walt - KZ1F

I'd make one correction Peter. Flex has a unique and proprietary command syntax. TCP is a ubiquitous and well understood protocol. Vita-49 is also a std protocol for the binary data. COM ports predate 78. But, from the standpoint of roi, yes, I agree with you. Thanks. It's still a failure of imagination that we're still using a 40 year old technology.

Elen Reynolds

It's not a secret that USB can't replace serial ports and there is some reason - telecommunication and radio hardware need this type of connection. So we just have to use Serial Port Emulator to pair com port device with application on PC...