QUATECH ThinkQ QSE-100D-BA 4 Port RS-232 Serial Server (CHEAP!)

[beelzerob]

Yes, I set all the ports for Low Latency.

The Ocelot has had no issues that I can tell. I'll hook up a couple more devices tonight that were giving me issues (datanab and RCS TR-15) and see how they do.

I checked it this morning, and sure enough, the OnQ had disconnected several times.

So far as I can tell, the reason for the disconnects is because it is occasionally not getting a reply to "are you there?"....basically just a heartbeat sensor. It doesn't happen every time I check for a pulse...just sometimes. So, that sounds like a message that isn't getting passed along...which again, could be anything down the line...router, switch, quatech, or ALC.

Tonight what I'll do is move the ALC to the one native port on this PC and see if it still has that issue. If so, then that leaves it being the ALC (or possibly the CQC driver, but I highly doubt that...the driver is of unquestionable quality).

I'm fairly certain I can code around this....just simply make it more tolerant to not getting back a pulse (maybe administer a little ALCPR too), but I'd rather not. In my opinion (and greatest desire), it should just work.

 

[myyaz33]

now you understand why the hard reset is so critical to isolating the remote access problem;

This is an Adminstratative issue and its EXACTLY as I analyzed it.

Its a major administrative problem with these units since they do NOT support true remote RE-configuration and especially after HARD RESETS and keep in mind its NVRAM can be easily damaged by electrical power surges etc...a good power spike or failure and the memory may be erased by "DEFAULT" via firmware trigger...just like in some of those old routers and thus you wont be able to remarry it unless you drive 120 miles back and reinstall drivers etc..and remarry the unit to the orignal local Gateway. Also don't use a DSL provider as your source for the original Gateway. I will explain later.

thus in your case Gary a 120 miles distance and in my case (90 miles) make these units extremely impractical for our purposes..you can still use them remotely, but you have to know in advance what can cause the loss of remote access and the only way to restore it is to return to the orginal local gateway 120 miles away for configuration. that's a major problem that makes long distance remote use of this item impractical.

They did that deliberatly probably as an added security feature...

We are NOT just concerned about seeing it remotely we are also and EQUALLY concerned about its abilty to be RE-configured and modified REMOTELY which in Garys case and mine is extremely vital.

If you go back and read my first post on this matter..I was telling you guys there is a "marriage" involved here and its creates a REMOTE access RE-configuration problem and thus one must the US Postal mail to ship these things around when re-configuration is being tested.

Tech support has confirmed now, EXACTLY what I had diagnosed originally and this may become an administrative problem for anythign that is trying to RUN REMOTE APPLICATIONS thru it that require frequent changes.

thank you Gary, at least someone bothered to contact tech support and get the true lowdown on this thing, rather than just speculating or posting their local observations.

This is why you read the manuals, it warned us in advance about this issue, but is rather vague about it and ONLY warns against power failures and HARD RESETS being the trigger for lost remote RE-configuration access.

Also, if you change your router (new MAC #) or if the DNS host changes the IPs (like DSL IPs are often changed daily) that may become another problem for this thing since it may trigger a new RE-marriage scenario. So if you test one of these things fortotal REMOTE access outside the Gateway, then a real business STATIC IP binding address may become essential..at the server's end at least. Also, If you unplug a ROADRUNNER based cable modem for 30 minutes (this is what TIME WARNER cable uses in our area) it will trigger a new dynamic IP address from their DNS host and thus your router may reject the packet from the remote Quatech. I am going to test that soon.

I have NOT tested that scenario yet, but I would not be surrpised if these things do NOT work well remotely at locations fed FROM a dynamically changing IP enviroment like DSL providers or ROADRUNNER base dynamic DNS hosts that change them after power failures automatically.

Dan, you were way nice to this fella! I am surprised that no one pounced on his basic lack of general networking knowledge. How else can you explain his multiple references to the DNS host dishing out ip addresses or the delusion that spoofing or changing a MAC address is any harder than spoofing an IP address.

Anyway this post was helpful to me in potentially solving a remote driveway sensor post I made. Thanks.

 

[beelzerob]

Ok, so now I have the OnQ ALC connected to the native serial port, and the Ocelot, RCS TR-15 and Datanab connected through the Quatech. Sooo far, they are all behaving. So I'm thinking the PC had at least something to do with the wonkiness.

I'll let this sit overnight, then reconnect the ALC to the quatech and see if that occasional disconnect happens again. If so....then I'm not sure where to go from there. It seems strange that it would only affect the OnQ with the ocassional heartbeat request, whereas the datanab is polling the device every second...surely if there was the occasional lost message, that would show it first.

We'll see what tomorrow shows.

 

[AceCannon]

Ok, so now I have the OnQ ALC connected to the native serial port, and the Ocelot, RCS TR-15 and Datanab connected through the Quatech. Sooo far, they are all behaving. So I'm thinking the PC had at least something to do with the wonkiness.

I'll let this sit overnight, then reconnect the ALC to the quatech and see if that occasional disconnect happens again. If so....then I'm not sure where to go from there. It seems strange that it would only affect the OnQ with the ocassional heartbeat request, whereas the datanab is polling the device every second...surely if there was the occasional lost message, that would show it first.

We'll see what tomorrow shows.

This has got to be some sort of coding, syntax, or other software issue. I just seems so weird that these things (Quatechs) would behave as anything other than regular com ports.

Or, maybe the ALC hardware is the problem.

Hell, take a look at DirecTv's latest sat tuners. The CQC driver cannot maintain comm because the sat boxes are so agonizingly slow.

 

[electron]

It could be an issue with the Quatech device, device failure happens, but considering these are industrial devices, it would be the lowest on my list of possible culprits.

What power supply are you using? The Hong Kong one? Since you are using all serial ports, your power requirements will be a little higher, and maybe the cheap power supplies are causing issues.

myyaz33: All I know is that using them remotely works for other people, and myself as well, so I gave up arguing about it.

 

[AceCannon]

It could be an issue with the Quatech device, device failure happens, but considering these are industrial devices, it would be the lowest on my list of possible culprits.

What power supply are you using? The Hong Kong one? Since you are using all serial ports, your power requirements will be a little higher, and maybe the cheap power supplies are causing issues.

myyaz33: All I know is that using them remotely works for other people, and myself as well, so I gave up arguing about it.

FWIW, I did have a Quatech that stopped working. It powered up, was visible on the LAN, but the serial ports never appeared available... this was after it had been working fine for a few days. I swapped it out for my other unit, all was well, same power supply. (The seller replaced the bad one). But this was a TOTAL loss of function, i.e. not like Beelz's situation where three other devices seem to be working just fine through the Quatech.

Re cheap power supplies, the one I linked to earlier in the thread (cheap ebay PSP supply and some barrel connectors with screw terminals) seem to work fine for me with all four com ports functioning.

I like the versatility of these so much, I bought two additional units. 16 com ports does not seem like overkill anymore. . .

 

[beelzerob]

Well, overnight I didn't have any disconnects with the ALC, so this morning I switched it BACK to the quatech. So far....no disconnects. So I dunno. I'll let it go the rest of the day.

Ya, I'm using the cheapo hong kong power supplies. No issues that I've noticed. Really, if any device was to be flaky, I'd think it'd be the datanab since it polls for quite a bit of data every second.

 

[beelzerob]

Well...... *shrug*

It's been fine every since. I even moved it back to the original configuration, which is that it went:

OnQ->Quatech->HP 5700->CQC

(before that, I had removed the HP5700)

No disconnects, all night. So I dunno what it is or was. But so far, all of the devices I have connected appear to be doing fine.

One annoying thing...on my (now suspect) older PC, I was able to remove all the comm ports and then reinstall the quatech drivers in order to get comm's from COM3 onward. However, on the media PC I'm using now, when I installed the quatech drivers, it started at COMM65!! There are no other comm ports on the thing except the native COM1. Any idea how I reset windows COM port counting scheme to start at 3 again?

 

[beelzerob]

Spoke too soon.....11 disconnects today on the ALC.

I moved it back off the 5700 to the CQC server. Really all that does is remove any possibility it's between the cqc server and the 5700, which seems really unlikely. But I'll let it sit for quite a while this time and see what happens.

Also, I have a lot of wiring to cleanup before I can REALLY start to blame something else.

 

[Jimmyjam]

My ALC has been up since Wednesday with no disconnects using the CQC ALC driver using a MOXA. So I don't think the driver is the problem.

 

[beelzerob]

Well, I'm pretty convinced the Quatech is involved in this somehow. I just have to try and eliminate other possibilities.

 

[mustangcoupe]

So I decided to unpack mu Quatech and actually start to use it. It appears that I am doing something drastically wrong.... It lights up and nothing else happens, I cant communicate with it from the software. The manual is not really any help because it only discusses a reset button not a default button. arrg.... I know I should have gotten two

I have tried 3 power supplies, one of them is even a 5amp supply so I am sure it is not the same as Tony's problem back on page 1 or 2 ...

 

[AceCannon]

So I decided to unpack mu Quatech and actually start to use it. It appears that I am doing something drastically wrong.... It lights up and nothing else happens, I cant communicate with it from the software. The manual is not really any help because it only discusses a reset button not a default button. arrg.... I know I should have gotten two

I have tried 3 power supplies, one of them is even a 5amp supply so I am sure it is not the same as Tony's problem back on page 1 or 2 ...

Did the indicator lights change when you plugged it into the network?

When you run the driver software, does it get to the part where it scans your subnet for the Quatech's MAC address?

 

[mustangcoupe]

Did the indicator lights change when you plugged it into the network?

When you run the driver software, does it get to the part where it scans your subnet for the Quatech's MAC address?

Thanks Ace,

Yes I get the link light both in front and the link and activity light near the e-net connector. Yes it scans but it doesnt find anything.

 

[purple_motion]

Did the indicator lights change when you plugged it into the network?

When you run the driver software, does it get to the part where it scans your subnet for the Quatech's MAC address?

Thanks Ace,

Yes I get the link light both in front and the link and activity light near the e-net connector. Yes it scans but it doesnt find anything.

I had lots of problems getting mine to scan properly as well. I had my XP work laptop (no go), my Vista machine (no go) and finally my XP home laptop (worked!). I don't know what the issue was but make sure both the laptop and the device server are on the same physical network segment (i.e. both connected to same router/switch). You have to make sure the broadcast packets make it to the Quatech.

FYI: my Quatech was configured for 10.66.208.33. Worst case setup a 10.66.208.xx network and then try and ping the device.