USB to Serial adaptor

[Jasen Betts]

I have been trying to find a good USB to RS485 serial adapter. I have
a small contract to modify some code to add MODBUS capability to a
product. I found one item on Amazon that had USB to serial
TTL/RS232/RS485 that really fit the bill, so I got one.

It came in, and seemed to work, then just kinda stopped. I think it
is that TTL capability - makes the whole thing really static
sensitive! I ordered another one, and today right in the middle of
testing, it has gone bad as well. All my commands suddenly started
failing CRC. After spending all day (on a Saturday!) trying to 'fix'
my code, I finally pulled out my old USB to RS232 dongle, and my code
is fine! Not a fun way to spend a weekend, especially since my
customer is supposed to demo the MODBUS capability to the customer on
Monday!

Well, at least on RS232 it works fine...

maybe add to your rs232 interface a rs232 to rs485 adaptor.

 

[Spehro Pefhany]

I have been trying to find a good USB to RS485 serial adapter. I have
a small contract to modify some code to add MODBUS capability to a
product. I found one item on Amazon that had USB to serial
TTL/RS232/RS485 that really fit the bill, so I got one.

It came in, and seemed to work, then just kinda stopped. I think it
is that TTL capability - makes the whole thing really static
sensitive! I ordered another one, and today right in the middle of
testing, it has gone bad as well. All my commands suddenly started
failing CRC. After spending all day (on a Saturday!) trying to 'fix'
my code, I finally pulled out my old USB to RS232 dongle, and my code
is fine! Not a fun way to spend a weekend, especially since my
customer is supposed to demo the MODBUS capability to the customer on
Monday!

Well, at least on RS232 it works fine...

I use a USB-RS232 (generic blue transparent) and an RS232-RS485 from
BB.


Best regards,
Spehro Pefhany

 

[[email protected]]

I have been trying to find a good USB to RS485 serial adapter. I have
a small contract to modify some code to add MODBUS capability to a
product. I found one item on Amazon that had USB to serial
TTL/RS232/RS485 that really fit the bill, so I got one.

It came in, and seemed to work, then just kinda stopped. I think it
is that TTL capability - makes the whole thing really static
sensitive! I ordered another one, and today right in the middle of
testing, it has gone bad as well. All my commands suddenly started
failing CRC. After spending all day (on a Saturday!) trying to 'fix'
my code, I finally pulled out my old USB to RS232 dongle, and my code
is fine! Not a fun way to spend a weekend, especially since my
customer is supposed to demo the MODBUS capability to the customer on
Monday!

Well, at least on RS232 it works fine...

Which end showed CRC errors, the one that received messages from the
adapter or your reading on the USB side ?

A typical bug with RS-485 adapters is that the transmitter is turned
off (into idle state) too early, while the last few bits are still
being transmitted. Does the chip handle the TxEnable control
internally and does it do so, when the last stop bit(s) have actually
been shifted out of the Tx shift register or does it start to turn
off, when the last character into the shift register ? In the latter
case, the failure rate increases with _lower_ line speeds.

Or do you command the TxEnable across the USB ? In this case, how do
you know when that last character has actually been transmitted out of
the shift register ? One way to handle this is to keep the Rx side
enabled all the time, so that you hear your own transmissions on the
RS-485 line. When you hear the echo of the last character, then you
can disable the transmitter.

To satisfy the formal Modbus RTU specifications, you should wait 3.5
character times after the echo of the last character, before turning
of the Tx. Well actually In this echo case, 2.5 character times is
enough, since the echo Rx shift register consumes one character time.

Look also on the transmit turn on sequence before transmitting a
Modbus frame.The standard requires that the transmitter is turned on
(sending "idle") 3.5 character times, before sending the actual frame.
This is very important, if you do _not_ use "fail safe" termination.
With fail-safe termination, the passive pull-up resistors will keep
the bus in the idle state when no transmitters are active.

 

[Charlie E.]

maybe add to your rs232 interface a rs232 to rs485 adaptor.

Yeah, ordering one of those as well as a dedicated USB to RS485
adapter - new rule, always have a back up on essential test equipment!

 

[Charlie E.]

Which end showed CRC errors, the one that received messages from the
adapter or your reading on the USB side ?

A typical bug with RS-485 adapters is that the transmitter is turned
off (into idle state) too early, while the last few bits are still
being transmitted. Does the chip handle the TxEnable control
internally and does it do so, when the last stop bit(s) have actually
been shifted out of the Tx shift register or does it start to turn
off, when the last character into the shift register ? In the latter
case, the failure rate increases with _lower_ line speeds.

Or do you command the TxEnable across the USB ? In this case, how do
you know when that last character has actually been transmitted out of
the shift register ? One way to handle this is to keep the Rx side
enabled all the time, so that you hear your own transmissions on the
RS-485 line. When you hear the echo of the last character, then you
can disable the transmitter.

To satisfy the formal Modbus RTU specifications, you should wait 3.5
character times after the echo of the last character, before turning
of the Tx. Well actually In this echo case, 2.5 character times is
enough, since the echo Rx shift register consumes one character time.

Look also on the transmit turn on sequence before transmitting a
Modbus frame.The standard requires that the transmitter is turned on
(sending "idle") 3.5 character times, before sending the actual frame.
This is very important, if you do _not_ use "fail safe" termination.
With fail-safe termination, the passive pull-up resistors will keep
the bus in the idle state when no transmitters are active.

Interesting point. The CRC errors were on the message from the
adapter. At first, my device was receiving the messages correctly,
but then it seemed to be dragging out zeros in the middle of the
message...

I will have to check my software on the necessary delay after!

 

[miso]

M232R module

But that isn't a converter the end user will buy. It seems to be an
unrelated issue.

 

[miso]

I got my Prolific from Frys. I try not to use ebay for much these days
due to the conterfeit issues. In any event, it is the real thing. The
drivers load, but 64 bit windows had been an issue, which is why I got
the FTDI device.

I wouldn't rule out using Prolific, but I sure would get it at a store
where I could return the device.

Incidentally, my Keyspan has no 64 bit drivers. It was a decent unit,
but time marches on. Drivers have a way of making peripherals useless.

 

[miso]

Dosbox is a serious ass saver. I have used it to run 16 bit software.

Cardbus to serial adapters work in real DOS. That is, USB didn't exist
in the DOS age, so it is funky when you use virtual machine software
that does anything USB. But the PCMCIA or cardbus cards are right on the
bus and DOS recognizes them. Unfortunately my current notebook Ricoh
I/O chip doesn't work in DOS. But maybe an older notebook would do what
you need.

I literally had to break out the DOS manual, doing all that load high
crapola. I used Free DOS. I finally found a windows alternative for the
DOS program I was using, but I totally understand how those old radios
need real DOS.

Mind you, there are many companies that sell cardbus/pcmcia serial
cards, but not all will work under DOS. The only card I found that works
is the now defunct Socketcom (AKA Socket communications). The cards are
easy to find used, but the software is not on line.

I see they just renamed themselves:

http://www.socketmobile.com/

If you reach the point where you are ripping your hair out, I can send
you a card. They also show up on ebay from time to time.

 

[miso]

No thanks. My hair is falling out faster than I can rip it out. I
have a pile of Socket PCMCIA cards somewhere. They worked well under
Windoze (for programming Metricom radios), but failed with
virtualization software, DOS programming software, and weather station
software. For a time, they were all that was available for laptops,
so I did my best to make them work. When USB adapters arrived, I
never looked back. I haven't tried a Socket card with DOSbox because
I'm not a masochist.

The key to socketcom is to run actual DOS. You dual boot the computer.
Otherwise, they are a pain in the ass and USB, especially FTDI, is far
better.

 

[Oppie]

I ought to look around, and see if anybody has implemented an
open-source version of the USB Communications Device Class which would
run in a USB-enabled microcontroller. I have a feeling that Microchip
may have a reference implementation or library available. If so, this
could be a useful building-block for some interesting projects.

I love Microchip's support. We did a USB host application in a PIC32MX575
that took just a few hours to set up.

 

[[email protected]]

"I'm looking for a single USB to serial adapter, that will work with
every known operating system, on every operating system, 16/32/64 bit,
with every known USB interface chip, and on every known application.
Is that too much to ask? (It probably is). The quest for the one
true USB to serial adapter continues."

Yes, it's call "C".
We use an AT90USB162 programmed as USB to Serial. Works on XP, Win7, Linux. etc.

LUFA.

I love Microchip's support. We did a USB host application in a PIC32MX575
that took just a few hours to set up.

We use Atmel's At90USB162 bootloading Microchip's PIC32MX575.