sku: BOB-09822
Description: This is the newest revision and fixes issues with the last board. This breakout board pairs an SP3485 RS-485 transceiver with an FT232RL USB UART IC to convert a USB stream to RS-485. The SP3485 is a half-duplex transceiver, so it can only communicate one way at a time, but it can reach transmission speeds of up to 10Mbps.
The RTS pin of the FT232RL is connected to the transmit and receive enable inputs of the SP3485, this line is used to control the transmission mode of the RS-485 transceiver. With the proper drivers installed, the FT232RL will enumerate as a virtual COM port; the drivers are available for Windows, Mac and Linux.
This breakout board includes the SP3485, FT232, TX/RX/RTS LEDs, Mini-B USB connector, filter capacitors, and other components shown on the schematic. We've broken out the RS485 output to three different connections: (1) an RJ-45 connector, (2) a 3-pin 3.55mm screw terminal, and (3) a 3-pin 0.1" pitch header; none of these output connectors come populated.
Features:
Dimensions: 1.55x0.9 inches
Documents:
Replaces: BOB-09489
BOB-10124
RS-485 Breakout
Comments 14 comments
So does this version use RTS or the FTDI TXDEN signal to enable the SP3485 driver ?
The schematic seems to still be for the original version of the board.
Sorry about that! Fixed.
But you didn’t fix the description describing your change… just cost me many hours of time :(
“Driver/Receiver Enable connected to RTS line of FT232RL”
Schematic PDF and Eagle files are for RS485 driver board, not the USB to rs485 converter board. (FTDI Chip is not in the schematic, but is on the board in the picture)
Fixed!
Has anyone tried to connect one of these to the RS-485 Breakout sku: BOB-09823?
I have an RS-485 Breakout connected to a Fez Domino and I am trying to communicate through RS-485 to a PC.
We have scoped out the RS-485 line and transmitted data in both directions looks fine.
If we connect a different RS-485 device from a different manufacturer then we can communicate to it in both directions.
So the issue seems to be communicating between two SP3485 based devices.
We have tried adding additional bias resisters similar to those on the other device. But it does not help.
Our best guess is that the issue is related to the 3.3V operation and the fact that each one has a terminating resister. Since an RS-485 network should really not have multiple termination resisters we wonder if this is the problem. Before I start modifying a board I wanted to see if anyone else had sucess with this setup.
As a product suggestion: a switch or jumper to disconnect the termination resister.
The description above
Correct me if I’m wrong, but the TX and RX markings seem to be mixed up on the Silk screen on the newest version (BOB-09822)?
Other than that its a nice little board. Just started using it with PySerial :)
Cheers!
1a: Fixed termination resistor is a bad idea.
1b: The termination resistor is the wrong (common) value.
2: DE should be tied to TXDEN!
3: Don’t tie /RE to DE on the SP3485. (Some of us like to hear what we say…)
I can’t believe all the RS485 break-outs (at the time of writing this) suffer from 1 and 3…
Yeah I agree TX & RX are swapped.
Has anyone else managed to get this to work for DMX-512? I have it set up with openDMX controller software, but the very second I hook it into the DMX system it causes a blackout.
This board seems to have the same circuits as many others online (except for some protection circuits missing) and I see no reason why it shouldn’t work.
I need more throughput than this chip will provide. That is, Larger TX and RX buffers on the chip. Anyone know where I can get a USB to RS485 converter with a larger buffer?
I got mine today and they worked fine once I swapped A & B on the RS 485 end. The Rx and Tx lights are also backwards for my application.
/RE and DE should not be connected. If they are it is NOT possible to perform bus contention testing on a multidrop system. If two transmitters were to send at the same time, the only way they know if there was a collision is to read back what they sent to make sure they are the same. The way you have it implemented, enabling the transmitter disables the receiver! I hope I can modify the board to always enable the receiver, if not, it will have to be returned.