Maker Pro
Maker Pro

Old RS-232 compatibility with new computers?

Emam

Jul 7, 2014
63
Joined
Jul 7, 2014
Messages
63
Dear all,

I have a problem with an old force sensor which has an RS232 output port.
I would like to use this old sensor and connect it to a PC which I bought recently.
So I use a RS232-USB adapter cable like this :

http://www.distrelec.ch/fr/Converti...h34xPVTuVvuPFo0VQ-041sl5iXhQnBnBTIaAqz58P8HAQ


I do not succeed to have this connection.
Do you think that an old RS232 output can not be connected to a new PC using this cable?
Or the problem is somewhere else?

Many thanks and besta regards
 

Gryd3

Jun 25, 2014
4,098
Joined
Jun 25, 2014
Messages
4,098
Dear all,

I have a problem with an old force sensor which has an RS232 output port.
I would like to use this old sensor and connect it to a PC which I bought recently.
So I use a RS232-USB adapter cable like this :

http://www.distrelec.ch/fr/Convertisseur-USB-–-1x-RS232-Moxa-UPORT-1110/p/12573618?channel=B2C&ia-pkpmtrack=31-8353835313236323131303-102-112-703&gclid=Cj0KEQjw_pmoBRDu986bpISz5ZsBEiQANiuHDM2u-gkE6h34xPVTuVvuPFo0VQ-041sl5iXhQnBnBTIaAqz58P8HAQ


I do not succeed to have this connection.
Do you think that an old RS232 output can not be connected to a new PC using this cable?
Or the problem is somewhere else?

Many thanks and besta regards
You may have a problem with the Cable, or the Drivers for the Cable.
I use one of those Cables (From a different manufacturer) To program my BasicStamp with success.
So first thing to ensure is that the Cable works, then test the Sensor again.
 

BGB

Nov 30, 2014
154
Joined
Nov 30, 2014
Messages
154
You may have a problem with the Cable, or the Drivers for the Cable.
I use one of those Cables (From a different manufacturer) To program my BasicStamp with success.
So first thing to ensure is that the Cable works, then test the Sensor again.

or maybe they are not setting the baud rate and format correctly?

unlike with newer interfaces, RS-232 needs to have both ends match in terms of baud-rate, number of data/parity/stop bits, ... in order to work.

most devices I have seen are 8N1 or sometimes 7N1, but baud rate is rather variable (though, IME / IIRC, 9600, 14400, and 57600, and sometimes 115200 tend to be most common).

or such...
 

hevans1944

Hop - AC8NS
Jun 21, 2012
4,878
Joined
Jun 21, 2012
Messages
4,878
It may not be your fault. You may have a problem with a counterfeit FTDI USB-to-serial converter chip. See this ZDNet article on automatic driver updates, distributed by Microsoft, that included FTDI driver software that checks for, and then bricks (makes inoperable) counterfeit FTDI chips. I don't understand how the new driver software identifies counterfeit FTDI chips, or what it does to brick the counterfeits. Scroll down the page and read the comments too.

I agree with the comments made by @Gryd3 and @BGB. You need to somehow verify that the cable and drivers are working independently of your sensor, that the baud rate is the same for sensor and USB-to-serial interface, and that the serial data parameters (parity, number of data bits, number of stop bits) are the same. It may be possible to test the USB-to-serial interface in a loop-back configuration at the DB-9 connector using the Windows Hyper Terminal program. If hardware flow-control is disabled in Hyper Terminal, this may only require that you connect TxD to RxD at the DB-9 connector (usually pins 2 and 3).
 

davenn

Moderator
Sep 5, 2009
14,254
Joined
Sep 5, 2009
Messages
14,254
It may not be your fault. You may have a problem with a counterfeit FTDI USB-to-serial converter chip. See this ZDNet article on automatic driver updates, distributed by Microsoft, that included FTDI driver software that checks for, and then bricks (makes inoperable) counterfeit FTDI chips. I don't understand how the new driver software identifies counterfeit FTDI chips, or what it does to brick the counterfeits. Scroll down the page and read the comments too.

These comments from hevans are VERY important
not all RS232 - USB converters are created equal. Even amongst non-counterfeit ones it is often found
that some will work in some situations and not in others ... it can be very frustrating trying to find a working
setup

Dave
 

Gryd3

Jun 25, 2014
4,098
Joined
Jun 25, 2014
Messages
4,098
It may not be your fault. You may have a problem with a counterfeit FTDI USB-to-serial converter chip. See this ZDNet article on automatic driver updates, distributed by Microsoft, that included FTDI driver software that checks for, and then bricks (makes inoperable) counterfeit FTDI chips. I don't understand how the new driver software identifies counterfeit FTDI chips, or what it does to brick the counterfeits. Scroll down the page and read the comments too.
Good call on that Hevans.
Windows and FTDI have since rolled back the offending driver... but that only prevents bricking new devices, not reversing the effect if a previously used device was bricked by the driver. This also requires that the host computer is either using the old FTDI driver that was unaffected, or has applied the latest updates to overwrite the affected driver.
https://www.electronicspoint.com/threads/alleged-ft232-intentional-bricks.270964/
Was posted when this started to hit the fan. The 'bricked' device will show up in device manager with a PID of "000". If this is the case, the device can be repaired! So as long as the computer has properly installed the device and shows up in device manager, the faulty driver idea 'should' not be an issue.
 

hevans1944

Hop - AC8NS
Jun 21, 2012
4,878
Joined
Jun 21, 2012
Messages
4,878
I have several end-user devices that depend on a USB-to-serial device, usually part of a cable powered from the USB connection. The first one I encountered was an Elecraft KXUSB cable that is used to upload firmware updates to my KX3 transceiver and, later, to my KXPA100 linear amplifier that is driven by the KX3 transceiver. Then I purchased a "handy talky" or HT transceiver made in China by Bao-Feng that came with its own USB-to-serial cable and a driver on a miniature CD ROM. This year I decided to play with the Arduino Uno R3 that I received as a Christmas present two years ago. It came with a USB-A to USB Mini adapter cable because the USB-to-serial interface is built-in to the Arduino PCB. I also purchased another Arduino Uno R3 from Radio Shack this year, along with some XBee shields made by Seeed Studios in China. And finally, I purchased from Sparkfun their XBee Explorer, which also has a USB-to-serial interface built-in to the PCB but requires a USB-A to USB Micro adapter cable. I think maybe the Arduino and the Sparkfun boards use a different USB-to-serial chip than the FTDI, but I am pretty sure the Bao-Feng device uses either a counterfeit FTDI chip or another device because they provided driver software. Why do that if Windows "provides" FTDI drivers?

About the only thing all of these products have in common is the USB connection. And all of them work. So I guess I am really lucky to have (somehow) dodged the FTDI driver bullet. The Elecraft and Bao-Feng products, at least for now, are supported with my Pentium 4 PC, running Microsoft Windows XP Professional (32 bit) SR-3. As just about everyone knows, Microsoft suspended support for XP although I still get online updates from Microsoft for Microsoft Office software installed on this computer.

Eventually the Pentium 4 will be "retired" and retro-fitted with a Linux distro (just because I can, not that I have any working knowledge of Linux) and possibly used as part of a wireless home security system with battery backup and cell-phone communication for security alerts. The USB supported stuff will migrate to an Intel Core i7 system I built two years ago that is sitting idle and becoming obsolete with each passing minute. I built two of these systems, one for my wife and one for me, virtually identical except mine has an SSD to go along with its 1 TB hard disk. Both run Microsoft Windows 7 Professional (64 bit) and accept automagical software upgrades online. Well, we'll see how that goes later this year. The Arduino stuff currently runs on an HP laptop using an Intel Core i3, also with Windows 7 Pro. No problems so far.
 

Kiwi

Jan 28, 2013
471
Joined
Jan 28, 2013
Messages
471
Have you checked "Control Panel" "Device Manager" "Ports (Com & LPT)" to see if the adapter is correctly installed.
Also, what com port is it on? Some RS232 devices will only work on COM1 or COM2.
 

Emam

Jul 7, 2014
63
Joined
Jul 7, 2014
Messages
63
Dear all,
Thank you very much for you help.
I could not resolve the problem yet. In fact, I have tested my cable, it works good with another device which I have (however this device is newer).
Then I have tested different parameters of transmission, including different Baud rates, parity, termination char etc. Still did not work.

Then I even used a simple RS232 cable (not a RS232 to USB adapter) for serial connection to my PC. Even with this cable it does not work.


My sensor (to which I would like to send/receive ) data is old.
Its a kistler z17757 force sensor. The fabricant can not give me info about it beacue its old.

These are my last questions:

- How can I see that "at least" I am able to send/receive data?
- Is it possible that the ASCI data I send are wrong?
- Is it possible that an old RS232 work on different voltage level than what todays computers can manage?

Many thanks and bests regards
 

kpatz

Feb 24, 2014
334
Joined
Feb 24, 2014
Messages
334
RS232 ports in the past (when they were integrated on motherboards or on expansion cards) would use the 12V rails to provide the output signals at +/- 12V. USB-Serial adapters use MAX232 or similar ICs that double and invert the 5V power to derive (approximately) +/- 10V, though in reality it's usually around 8-9V depending on well designed the circuit is, capacitor sizes used, and amount of load on the circuit.

The older device may not recognize a RS232 signal at a lower voltage, and/or may put enough of a load on the USB-Serial interface to lower the voltage below the threshold where it can recognize it. If you have a scope this is easy enough to check, by measuring the voltage of the signal when connected and when disconnected.

If this is the case, you may need to try a different USB Serial adapter and hope it works better for the application. Or get a PCI or PCI Express serial card (assuming you're using a desktop PC and not a laptop).
 

hexreader

Apr 21, 2011
135
Joined
Apr 21, 2011
Messages
135
quote: "- Is it possible that an old RS232 work on different voltage level than what today's computers can manage?"

VERY possible !

Older computers would supply a solid plus and minus 12 Volts at a good 20 milliAmps or more on all outputs.
Modern computers might give +9 Volts and -5 Volts signals if loaded with 20 milliAmps, laptops will give out even less.
Some older peripherals took advantage of the higher power output available in their day, and expected plenty of power from the RS232 port (even though they should not really have)
Many of these older peripherals will not work with lower Voltage and/or current available from Modern PCs.

Older peripherals also depended on handshake signals being present - modern devices (such as cheap USB/232 converters) may not have all handshake signals available, or may have handshake disabled in software.

RS232 is a very variable "standard" and much abused.

It may be that your force sensor does not talk pure ASCII. Does it require a special (possibly DOS) driver?

EDIT kpatz beat me to it by a few seconds :)
 

hevans1944

Hop - AC8NS
Jun 21, 2012
4,878
Joined
Jun 21, 2012
Messages
4,878
Can you post picture of your force sensor and a diagram showing how it connects to the real world? Does it have a DB-9 or DB-25 connector? How is it powered? Is this a load-cell sensor or a piezo-electric transducer? Why do you think it even has an RS-232 output? Is there any documentation for your sensor?
 

Emam

Jul 7, 2014
63
Joined
Jul 7, 2014
Messages
63
Thank you,
In appandex, you can find the picture and also the data sheet that the supplier gave me.
I dont know if this data sheet is well updated. Its a piezo-electric force sensor working with 24 V supply. There is a RS232 output on the backside (see picture).

In the data sheet its written that if i send character "o" , I will start measurement, and if I send "v" for example, I will read value. But when I send these characters nothing happens!!
There is no info about transmission parameters, but I have tested alomost all of the (baud rates etc).

I dont thing that there is a need for a driver on DOS , becuase the sensor is made on 2002.

I will check if the voltage difference is the problem.

Many thankks.
 

Attachments

  • Instruction Manual FoMo.pdf
    251.3 KB · Views: 198
  • photo 1.JPG
    photo 1.JPG
    47.7 KB · Views: 140
  • photo 2.JPG
    photo 2.JPG
    38.3 KB · Views: 139

hexreader

Apr 21, 2011
135
Joined
Apr 21, 2011
Messages
135
I do not think that voltage levels will be the problem. That looks like a proper RS232 device that would be compatible with a modern PC serial port.

Cheap USB to RS232 converter could possibly cause a problem, so use a real serial port if you have a choice. The converter in your link looks like a good quality device, so I would guess it is good.

The manual does not quite give enough information to diagnose what the problem might be. If only the baud rate was specified :(

Without being there, I can't be sure if you might have a cabling problem or not. Too difficult for me without oscilloscope and breakout box and without being there.

Maybe someone else is good at remote diagnosis?
 
Last edited:

hevans1944

Hop - AC8NS
Jun 21, 2012
4,878
Joined
Jun 21, 2012
Messages
4,878
There are a few things you can still do. Make sure the pins on the DB-9 connector are properly jumpered: pin 4 (DTR) or Data Terminal Ready should connect to pin 6 (DSR) or Data Set Ready; pin 7 (RTS) or Request to Send should connect to pin 8 (CTS) or Clear to Send. Then use a multimeter to measure the voltage level at pin 2 (TxD) or Transmit Data. IIRC, this should be a negative potential with respect to pin 5 (SG) or Signal Ground when no data is being transmitted. It will briefly oscillate between the negative voltage and a positive voltage for each character transmitted, but too fast to see with a multimeter. If there is no voltage on pin 2, measure pin 3 (RxD) or Receive Data. The idea is to determine which of these two pins is the RS-232 output and which is the input. If you don't measure voltage on either pin 2 or pin 3, there is something wrong internally, and there is probably no solution.

I had a motorized programmable speed stirrer that went on the fritz and wouldn't respond to ASCII commands, although it did produce ASCII messages. Turned out there was an ASIC (Application Specific Integrated Circuit) inside with a line receiver that was damaged. Manufacturer wouldn't provide a replacement part, so we ended up buying a new controller. The old controller could still be operated manually, but we needed a new one to control the stirrer remotely with a PC.

When transmitting ASCII commands, there is almost always some sort of protocol involving <LF> and/or <CR> characters after each command. Use Hyper Terminal to either insert or delete carriage return (CR) and/or line feed (LF) after sending a one-letter command. Sometimes there is also an ASCII prefix character (or two or three) associated with a command, although the Instruction Manual doesn't mention that. If there are prefix characters, good luck finding out what they are. If you have the software that goes with this instrument, it might be possible to disassemble part of it to determine what it expects. Sometimes binary executables contain plain text that offer clues to operation. As for serial protocol, this is commonly 9600 baud, No Parity, 8 Data Bits, and 1 Stop Bit... usually abbreviated 9600 N, 8, 1. You may have to reverse pins 2 and 3 at your computer. If you have a DB-9 or DB-25 serial port on your computer, use that instead of the USB adapter until you get this figured out. Make sure the serial communications port shows up in Device Manager as COM1 or COM2. You should wire up a loop-back connector to attach to the computer serial port to make sure it is working. Use Hyper Terminal to test the loop-back functionality.

This instrument appears to be in "like new" condition. It is hard to believe that no one at Kistler has any documentation on it. Maybe you could try an e-mail inquiry to their Switzerland office? They list Jason [email protected] as a point of contact.

There are "modern" versions of your instrument, the Model 5015A and the Model 5018A. You will have to register on the Kistler website to download more information and software.
These later instruments require an ASCII colon :)) prefix to the command line and a <CR><LF> characters at the end of the command line. You might try that. Also, the Model 5015A appears to default to a baud rate of 19200 (page 52, paragraph 5.21 RS-232 Interface) according to the Instruction Manual I downloaded from the Kistler web site.

Please let us know if you find out any more information. Oh, BTW, Kistler shows a "null modem" cable is required between the Kistler instrument and a PC for the Model 5015A.
 

Arouse1973

Adam
Dec 18, 2013
5,178
Joined
Dec 18, 2013
Messages
5,178
It may not be your fault. You may have a problem with a counterfeit FTDI USB-to-serial converter chip. See this ZDNet article on automatic driver updates, distributed by Microsoft, that included FTDI driver software that checks for, and then bricks (makes inoperable) counterfeit FTDI chips. I don't understand how the new driver software identifies counterfeit FTDI chips, or what it does to brick the counterfeits. Scroll down the page and read the comments too.

I agree with the comments made by @Gryd3 and @BGB. You need to somehow verify that the cable and drivers are working independently of your sensor, that the baud rate is the same for sensor and USB-to-serial interface, and that the serial data parameters (parity, number of data bits, number of stop bits) are the same. It may be possible to test the USB-to-serial interface in a loop-back configuration at the DB-9 connector using the Windows Hyper Terminal program. If hardware flow-control is disabled in Hyper Terminal, this may only require that you connect TxD to RxD at the DB-9 connector (usually pins 2 and 3).

Hop
https://www.electronicspoint.com/threads/nano-no-longer-working.270650/
Here is a thread that I had involvement in. I had two Nano's with CF FTDI chips. Mine worked great first plug in but then the second time DEAD!. I then found windows had written a 0 into the PID for that device. This rendered it useless. I guess they must have some unique serial number or algorithm which windows would recognise as a genuine part.
Adam
 

Gryd3

Jun 25, 2014
4,098
Joined
Jun 25, 2014
Messages
4,098
Hop
https://www.electronicspoint.com/threads/nano-no-longer-working.270650/
Here is a thread that I had involvement in. I had two Nano's with CF FTDI chips. Mine worked great first plug in but then the second time DEAD!. I then found windows had written a 0 into the PID for that device. This rendered it useless. I guess they must have some unique serial number or algorithm which windows would recognise as a genuine part.
Adam
The same details were brought up earlier in the thread.
Post #9 says the cable worked with another device, but this device will not with the USB-serial cable, or another serial cable.

FTDI actually employed a bit of a trick for detection, they attempt to write to a specific portion of the chip. The fakes accept this write action which allow the PID to be reprogrammed. It's a very simple check and no amount of swapping values will help a fake pass the test without redesigning the chip or firmware. (Windows since rolled back the driver, but any affected chips will not automatically be restored.)
That said, the bricked devices can be recovered using a tool from FTDI funny enough. I'm certain the link in post #6 will have a description for how this is done.

Does anyone have any ideas on how this device can be tested without a scope?
 

alex Chiu

Apr 1, 2015
14
Joined
Apr 1, 2015
Messages
14
The same details were brought up earlier in the thread.
Post #9 says the cable worked with another device, but this device will not with the USB-serial cable, or another serial cable.

FTDI actually employed a bit of a trick for detection, they attempt to write to a specific portion of the chip. The fakes accept this write action which allow the PID to be reprogrammed. It's a very simple check and no amount of swapping values will help a fake pass the test without redesigning the chip or firmware. (Windows since rolled back the driver, but any affected chips will not automatically be restored.)
That said, the bricked devices can be recovered using a tool from FTDI funny enough. I'm certain the link in post #6 will have a description for how this is done.

Does anyone have any ideas on how this device can be tested without a scope?



May be the USB Com is OK. The problem may due to the software, Old software may hard code the IRQ, i.e. COM1 is IRQ4, COM2 is IRQ3, etc. Old software may not unable to "SEE" UART beyond COM4.
 
Last edited by a moderator:

Emam

Jul 7, 2014
63
Joined
Jul 7, 2014
Messages
63
Thank you all for your help.
Especially I would like to thank "hevans" for his helpful commments.
I have partially resolved the problem, however I should still correct some data conversion etc.
The origin of the problem was various but the main problem was that I did not have any documents!!

Here is the summary of what blocked me for a long time:

1. The fabricant gave me a data sheet but it was not a right one exactly. My sensor was an updated version compared to the one for which I had data sheet.
2. The fabricant could not help me, becasue the sensor was too old. The person who did this sensor was no more available.
3. As Hevans said, a "nul modem" cable was necessary for the transfer. I had no idea about that.
4. As "Heavans" said, there was a need to enter <CR> charactere at the end of my ASCI command, to communicate with my device.
5. The righ ASCI command for transfere starts with character ' , ' which I did not know.

Most important thing: I put an entire day, to search everywhere, in the computers of our company, the hard disks of my old colleagues, and our server data storage.
Finally I found the data sheet !!!!

By the way, I know that the problem was not technical problem, but rather organizational problem.
But Its important to work with devices with correct documents.


Again many thanks
 

CDRIVE

Hauling 10' pipe on a Trek Shift3
May 8, 2012
4,960
Joined
May 8, 2012
Messages
4,960
I'm going to add another fly to the soup of USB/RS232 converters. I own 5 or 6 of them and have never had an issue with even the most inexpensive (<$10.00) Chinese import. The only one that gives me an issue is an old (relatively expensive) Belkin model and this is only because it doesn't recognize a "Break" command which some RS232 peripherals use. Programming a Picaxe being one of those peripherals that use the Break command.

Chris
 
Top