Using the Quatech Serial Port Server

Well at least now there are 2 software solutions which should work. It does mean there is some bug in the Quatech software that probably should be reported. I am only using it with a UPB PIM and W800RF32, so I am not really pushing it as much as you guys are.
 
Strange thing I noticed. Gave the HW-VSP3 version a try (Vista compatible but only 1 port allowed), and the port that was created says it is an Eltima port which is another company that makes simlar products but sells them.
 
I use the Eltimate software as well. I do dislike version 3, and stuck with v2, since it's rock solid.
 
Well, after most of a day running, the Datanab appears solid. The RCS TR-15 also. The Ocelot shows 2 bad messages...not sure exactly what that is, but that's not too bad. The OnQ ALC is the most shaky one still, though. Not as bad as before, I think, but still occassionally the "heartbeat" message gets messed up coming back.

I'm gonna move that to the PC directly so I can check that it's not a hardware or driver issue.

Otherwise, I'm pretty pleased with the stability....FINALLY!
 
Well, the OnQ controller is definitely happier connected directly to the PC. It's much BETTER with the redirector than it was with the quatech drivers...but it was still having occassional issues. The really weird part of that is that the errors were that it was sending back the WRONG message, not that it was sending back no messages. Anyway, I think for now I'll declare victory and retreat.

The Ocelot still shows just a tad of "bad messages" ocassionally, but I'm willing to live with that too. RCS TR-15 and Datanab are without any complaint, though. Yay!!

Now to try the brultech 1240 and see what happens!
 
Well, back to square one.

I went out the door this morning and noticed the ominous *lack* of sound...normally the TTS says the door opened. So, I sigh, and go over and look, and there are 11,000+ bad messages from the Ocelot driver. It basically wasn't talking to the device anymore.

I had found the Ocelot offline the night before, and when I logged in to check the redirector, I found it spamming little dialog boxes on the screen saying it was TRYING to redirect to the quatech IP /port num, but was failing. I then removed the driver (which stopped the attempts at redirection) and reloaded it, and the spamming started again. So I went into the redirector options and clicked a few more checkboxes to configure it differently...and this time when I installed the driver, the redirector popped up a single textbox saying it had successfully redirected to the IP/port.

I guess whatever I fixed last night wore off by this morning.

So now I have no choice but to change my drivers to IP and see if THAT makes it more reliable or stable. If not...then look in the Classifieds soon for several Quatech boxes!
 
I'm amazed at how much trouble Im having with this.

I've now converted the Ocelot driver to use IP or RS232. It seems to open the port ok (it doesn't complain, anyway), but when I try to write out the port, I get:

The connect was aborted by the other side

At that point, the socket is disconnected. Any attempts to reconnect and write to the device result in the same thing.

I've checked the port..it's in Raw mode, with the right baud rate and all that. And I'm sure Im writing to the right port (5002 = 3rd port).

*sigh*
 
Well, ok...I remote reset the quatech, and now it actually is communicating with my driver. I'm having some weird CRC issues with messages, but I'm not yet convinced that isn't my fault. Time will tell....
 
Well, I managed to finally fix it. For some reason, when a bit actually changed (from a digital input), the Ocelot was sending an extra like 8 bytes, which would throw everything off. That "feature" wasn't in the protocol doc, so I had to account for it.

But it's so far behaving, and it's kind of nice to be freed from device driver hell.

One down, 3 more to go....Datanab (which has been losing its connection again lately), TRS RC15 and the Brultech 1240.
 
Well, I managed to finally fix it. For some reason, when a bit actually changed (from a digital input), the Ocelot was sending an extra like 8 bytes, which would throw everything off. That "feature" wasn't in the protocol doc, so I had to account for it.

But it's so far behaving, and it's kind of nice to be freed from device driver hell.

One down, 3 more to go....Datanab (which has been losing its connection again lately), TRS RC15 and the Brultech 1240.

The Ocelot will asychronously transmit SECU input changes, X10 receptions and IR recognition events. Variables are polled.
 
Well...........that would sure make things easier. ;)

My protocol doc (bare as it is) doesnt seem to cover asynch messages. Do you happen to know where a current one is?
 
The IP driver is still solid , as of this morning. Interestingly, when it didn't work last night I found it was because my PC had completely frozen up...AGAIN. Thats about the 3rd time in 2 weeks. I'm (sort of) hoping it's because of the swollen cap issue I have, as I intend to fix that (or ruin my motherboard trying) next week....but otherwise, this system instability is just about driving me nuts.

But anyway, I'll be moving another driver to IP soon, since I've had the(so far) success with the ocelot.
 
Bad caps will definitely cause a total hardware lockup, and it's only going to get worse :/
 
Well, I almost took the quatech, ripped it from the wall, and threw it against the basement floor. I once again found my Ocelot driver screaming about bad writes....about 2 a second. Made the system crawl.

But I took a moment to analyze it and realized that my driver doesn't have a way to recover the port connection if it fails...and I had rebooted all the network equipment because our DSL had gone out (as it often does). So, it just kept trying to talk on a port that was no longer connected, throwing exceptions like crazy.

So, for the moment, the quatech is still working...it's just the software I have to fix.
 
Well, now that the dust has settled a little bit, here's where I stand:

I've converted the Datanab driver to IP connection, and it appears to be rock solid talking directly to the quatech.
I've converted the Ocelot driver to IP connection, and it appears to be rock solid talking directly to the quatech.
I've converted the OnQ ALC driver to IP connection, and it is definitely still have stability issues.

Next up will be the TRS RC-15 thermostat driver, I think.

There's some nice advantages to having the drivers on IP at this point. I'm still having some serious PC problems with my eventual WHS/CQC machine, so in the meantime I've moved everything to the kitchen PC which is on 24/7 also. With the drivers being on IP/port addresses instead of comm ports, the move over to another machine was painless. Also, as part of the troubleshooting process, I removed all the port redirector type stuff...so it's nice to be able to remove that from possible sources of problems. The downside is that I can't easily switch over to software that requires a comm port to connect to the device, like manufacturers software. I guess I could still install the quatech software for just those occassions.

I'm beginning to think that the ALC issues I'm having are the ALC's fault, as detailed in this thread. I think I have a really REALLY picky or faulty serial unit. This thing seems to *only* happy being plugged directly into a PC, and as the thread details, not even really then. It shouldn't be that quirky, so maybe its something I need to replace.
 
Back
Top