Serial port over IP


Senior Member
There are talks on the CQC forum about supporting IP connections to your COM ports. This means that CQC would allow you to connect a device to another PC possibly even over the internet and then be able to talk to that COM port just like if it were actually connected to your own PC. I brought this up to Dean after electron had shown me the splitting com ports into virtual ports was possible. The reason this is great news for CQC is because it would allow Dean to connect to a device over the internet and write drivers for that device. In other words if there is a device you have and you want support added then it could be done natively in CQC because dean could have access to the device for testing purposes.

The initial topic came up as a inexpensive hardware solution to this problem. The cheap hardware solutions found were $400+ which in my eyes is not very cheap. Which is why I aske Dean if something like a virtual port could be created.

Anyone have any thoughts about this?
There are already some (even free if I rememember correctly, you'll have to google for this) software applications which can do this, so I am not so sure if it's a good idea to have Dean waste his time on that. It definitely would make it easier to add support for new hardware.
I think GPS Gate can do this (in software). It's not free, but it's pretty cheap.

I have not used this product at all, yet. But I'm planning on trying it on my PDA to split input from a com port to multpile virtual com ports.

GPS Gate
Actually, the doing of the remote serial port thing won't be all that much work. I've already added the fundamental stuff necessary to do it. The reason it's not been done yet is that I want it to cleanly integrate into the rest of the system, and to also able to allow for support of things like the serial ports in the GC-100. That requires that I move from simple COM1, COM2 type names to some sort of path based system like "/Local/COM1" or "/CQCRemote/" or "/GC-100/" and that kind of thing.

That will allow me to create a pluggable virtual com port architecture and to have them show up to CQC users in a list from which they can choose, and when they select one then the app they are in can ask to have it opened and not know anything at all about whether it's a real or remote port.

I just haven't had time to make that change yet, so I've not implemented the remote port over software thing yet. We use our own ORB so it's pretty trivial to write a rich client/server interface like you'd want for a software-based remote serial port.

I could though, in the meantime, just in the driver development tools, provide a way to select a remote port specifically without it being all abstracted away and whatnot. That would be pretty easy to do without having to implement the fully abstracted, pluggable virtual com port scenario above.
Yeah what he said :(

I just like the idea of the software developer being able to provide support for products that you own instead of having to try and write your own driver for the product. This just seems like it would be much faster for someone experienced to do it. It also allows Dean to catch bugs that might not be noticable to the end user because he has the IDE tools and all the code exposed to him.

Even though Dean provides a great IDE which has an awesome debuger built in for driver development its just nice that he can use a lower level debuger.

Also something to note is that Dean has a hold on things. He only markets what he has created him self. Even though it is possible to develope your own drivers and share them with other users you won't catch those drivers for sale on Deans site. This is because dean like to maintain a clean and tidy application which he has control of.

Sorry for rambling on.
IMO, enabling a software-based method for remote user access to serial ports would be a great feature and selling point for home and theater automation software. Having just gone through the pain of purchasing and configuring a hardware-based serial server (a 2-port unit from Atop, sold by, I suspect that a software solution would be much easier from the customer's perspective.

Nothwithstanding the aggravation of configuring the hardware device, giving Dean of CQC the ability to directly control my serial gear was awesome. It was a blast to be on the phone with him while he turned my plasma on and off.

Dean has -- in less than two days -- written device drivers for my Panny plasma and Outlaw 990 pre/pro. For the Outlaw, he discovered undocumented features and a few errors in the protocol document.

From my perspective, I now have full-featured two-way control of m A/V gear. From CQC's perspective, they now can claim support of two more brands of popular A/V gear.

Finally, having a software-based method of controlling an user's serial devices would be a great tool for the professional installer. Not only could the installer write or tweak device drivers, he/she could troubleshoot problems with a user's system remotely.

- Ken
And we now have a software-only remote serial port solution. I just got it basically working last night and will refine it today. So now just by having CQC installed on your end, I can connect to your system and write serial-based device drivers from here. This will be a very useful tool moving forward.
Thats great Dean! Can you describe to us in simple terms what you have to do in order to set it up. Is it just like another driver or is it a seperate application? Any screen shots with it? When will it be available for download?
It's just a simple standalone program. It has a very simple GUI since it doesn't need much info from you. You just start it, indicate a port for it to listen on if the default isn't to your liking, and you can put in a source address that it will only accept a connection from. Then you click the Enable check box and it's ready. To disable it, just uncheck the Enable box. It's not a service based app, so you only run it when it's needed.

That's all you'll need to do on your side, so it's very simple to set up. It's way simpler than an IP based box. No drivers or anything like that, on your side or mine. And that's an advantage for us, in that every user could have a different IP based box and we'd have to have all these drivers from who knows where loaded on our machines in order to connect to them and make them look like local ports.

With this scheme both you and we only need CQC installed and nothing more.
Oh, and I'll be getting a new side build to Ken, who I'm already working on some drivers for (he unfortunately bought into the IP based box before I decided to go ahead and do this, so we started on his drivers via the box.) If it's all happy there, then I'll make it available to some other folks who might need some driver work, still as an unofficial release.

We are thinking at this point that, because of the high level of utility of this new feature, and the event support that I'm also working on, that we are going to limit 1.5 to just those things and get it out there very quickly, like in a few weeks. That way, folks won't have to wait for these very important new features. We can get them out there and then go off and work on some longer term features for a closer to the end of the year 1.6 release.
We used the new remote port server in anger for the first time today, on a real customer installation across the country and it worked perfectly. Quite nice. Much nicer than the IP based box for this type of thing anyway. We brought it up and set up the port forward and enabled it, and the development IDE immediately saw it and I could see his serial ports. I spent a couple hours working on a driver with no problems, till he knocked me off line to watch TV.
From my (the aforementioned customer) perspective, the remote port server is fantastic. It took about 3 seconds for me to configure it on my end, and I watched Dean turn on my plasma from across the country. In record time, he's now delivered a fully-functioning device driver for my Panasonic plasma and is working on a driver for my more-sophisticated Outlaw 990 preamp.

The only thing slowing him down was our need to use the plasma to watch TV -- how rude! :blink:

- Ken