Shield for programming Uno over RS485 signal lines

I have got a little more done on my garden automation project. This shield is another part of the puzzle; others may find the ideas useful.

My goal is to control irrigation using moisture sensors. But my firmware skills are rusty, and even at my best I worked iteratively. By iterative, what I am trying to say is getting something simple working and then adding to it, while trying to keep each addition working along the way. So I need a way to upload the firmware (again and again) into an Uno in the garden while I'm at a desk with cold, dry air some distance from the water works and sun.

The schematic:,Schematic.pdf

I put a fair amount of time into trying to make everything fit together:,RPUadptAssy%5D%20RPU-ADPT%203D%20ASSY.pdf

and a 3D STEP model (in zip):,

My web page with more info:

Also the board files are in Eagle (CC) BY-SA if you want to download them, just look for the zip link:

I have not yet made the board, but another puzzle part is in place.

an image of it stacked between an Uno and latching solenoid driver shield:

Well I am happy with how it fits on an Arduino

And the back side.

Debuging hardware... Channel one (yellow) is Arduino pin 0 (MCU RX) while channel two (green) is on FTDI TX output (which is from the host computer). sadly I did not spot the problem right away, but it is obvious (spoiler bellow image). Before seeing this problem, R13 was 1.5kOhm and acted as a voltage divider with the output drive from on board USB interface (Mega16U2 TXD1 goes through a 1kOhm resistor before arriving at the Arduino pin zero circuit node). When I change R13 to 180 Ohm it pulls down enough so the Mega328 can see the logic low (bellow 0.9V)

Testing with about 600ft of cable,

Also the FTDI board that I used with this part of the project

Looks very professional :)

I am puzzled about the purpose of Q1, it seems to disable the transmitter when TX is high?


I borrowed Q1 form Sparkfun:

But before I did I was confused by why it worked and was a good idea.

I probably need to start with some background; RS485 defines the range between -200mV and +200mV as "no-mans land," e.g. if the differential pair is inside this range some devices see it as high others see it as low. Some years ago almost everyone decided this was a bad idea and started using fail-safe biasing.

Fail-safe will force the bus into a known state when not driven.

Later chips like the one I am using (INTERSIL, ISL3172EIBZ) reduced the undefined range (-200mV thru -50mV), which also removes the need to bias for Fail safe.

So now that the bus has fail-safe transceivers I can power it off in the default high state (job of Q1). It is a huge deal, because driving the RS485 bus at 3V takes a lot of current with 100 Ohms at each end. So now my project could be battery powered. I only have to drive the low state when data is sent. I don't see much signal loss over the 600 feet of CAT5 I have. How far will it go? RS485 is rated for 4000 feet, but that is with 20 AWG twisted pair I think, and CAT5 is 23AWG.

Nice job.

I've not seen that trick with the transistor (Q1) before but have done a similar thing by using the data to directly drive DE. Would that not do the same thing?

That Sparkfun page is misleading as it's 4000' OR 10Mbps, you can't have both at the same time. Also they call RS-485 a "protocol" which it isn't.

What data rate are you using?


Thanks Graynomad,

The bootloader (optiboot) worked thru 600ft of cable at 115k, and ISL3172EIBZ is a bandwidth limited transceiver so it should top out at 250kbps. My project does not need high speed; I may end up running at 9600. It will be nice to work from the desk, and if needed use an old phone as a web cam to watch as my mistakes unfold.

directly drive DE

So when the Data was low it would turn off the Driver. Did you have a fail-safe bias so that devices on the undriven RS485 bus could see it as low? The chip I am using has a built in high state fail-safe, e.g. when the undriven differential voltage is 0V all devices see that as high, at -49mV it is also high, but at -50mV (thru -200mV) it may be high or low. From what I see the USARTS rest or default state is high, and that is when I want the bus off. The TX and RX rest state can be seen:

Ah, I thought it might be related to power saving. The CPU could drive the transmit enable so it is only enabled when transmitting, which perhaps is the "conventional" way to do it. So the real benefit is saving power and saving an IO pin on the controller.

Also it allows the standard serial driver to be used. As long as the rise times are ok, it's a useful trick. We use Modbus over half-duplex 485 at work, I might suggest it to the hardware guys :)

It’s been a while now and I can’t find the schematics, but I think I used an inverted data signal to DE and tied DI low.

So when the Data was low it would turn off the Driver.

So that scheme would do the reverse, the driver is off for an idle (or otherwise high) UART output.

Also I was just thinking, for low data rates the termination resistor should not be required in the first place. I’m designing something similar right now and the use of a 120R resistor would blow any low power ideas out of the water, so I am thinking of limiting the speed and ditching the termination resistors.


the termination resistor should not be required

Without the termination resistor reflections can be a huge problem, even noise can bounce around and grow into a detectable signal. A bandwidth limited transceiver like I used may help. Also, I have had some luck with low-frequency EMI ferrite suppressor as termination, but that was years ago, and the details... well I would have to do some digging

I was not going to mention this; it is just a thought experiment after all. Since the TX bus is not driven, and RX and DTR are receive-only, I think more than one Uno can be on this bus if all will keep quiet unless addressed. Firmware uploading gets tricky, but I was thinking I would need a complex addressing system using DTR in a half duplex mode to get more than one on the bus.

The full stack...

The plastic DIN mounting hardware is amazing, I can just snap it on and off the DIN rail, and it grabs (it is not easy to slide). Part number is on the BOMs of the solenoid driver shield.

Lookin' good. I was about to ask you about the DIN clip you are using, now I don't have to :)

According to a couple of Intersil data sheets

Short networks using the 250kbps versions need not be terminated, but, terminations are recommended unless power dissipation is an overriding concern.

I am tempted to try without termination for slow speeds, but then I just found the LTC2854/2855, it has a 120R internal resistor controlled by a pin, so I can decide at run time if it's required.