Pages: [1]   Go Down
Author Topic: Shield for programming Uno over RS485 signal lines  (Read 1412 times)
0 Members and 3 Guests are viewing this topic.
Offline Offline
Newbie
*
Karma: 0
Posts: 12
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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:
http://epccs.org/indexes/Board/RPUadpt/Documents/RPUadpt,Schematic.pdf

I put a fair amount of time into trying to make everything fit together:
http://epccs.org/indexes/Board/RPUadpt/Documents/14184RSS1%20%5BEPCCS,RPUadptAssy%5D%20RPU-ADPT%203D%20ASSY.pdf

and a 3D STEP model (in zip):
http://epccs.org/indexes/Board/RPUadpt/Documents/14184RSS1%20%5BEPCCS,RPUadptAssy%5D%20RPU-ADPT%203D%20ASSY.zip

My web page with more info:
http://epccs.org/indexes/Board/RPUadpt

Also the board files are in Eagle (CC) BY-SA if you want to download them, just look for the zip link:
https://epccs.org/hg/epccs/Board/file/tip/RPUadpt/Design

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:


Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 12
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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)
https://learn.sparkfun.com/tutorials/logic-levels

Testing with about 600ft of cable,


Also the FTDI board that I used with this part of the project
http://epccs.org/indexes/Board/RPUftdi/
« Last Edit: August 18, 2014, 05:43:20 pm by ron_sutherland » Logged

Offline Offline
Full Member
***
Karma: 7
Posts: 144
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Looks very professional smiley

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

Please don't PM me asking for help. Ask questions in the forum.

Offline Offline
Newbie
*
Karma: 0
Posts: 12
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Thanks,

I borrowed Q1 form Sparkfun:
https://www.sparkfun.com/products/11959

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.
http://electronicdesign.com/communications/implement-idle-bus-failsafe-multipoint-networks

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.
Logged

nr Bundaberg, Australia
Offline Offline
Tesla Member
***
Karma: 126
Posts: 8499
Scattered showers my arse -- Noah, 2348BC.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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?

______
Rob
« Last Edit: August 19, 2014, 05:57:59 am by Graynomad » Logged

Rob Gray aka the GRAYnomad www.robgray.com

Offline Offline
Newbie
*
Karma: 0
Posts: 12
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.

Quote
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:
« Last Edit: August 20, 2014, 08:34:35 pm by ron_sutherland » Logged

Offline Offline
Full Member
***
Karma: 7
Posts: 144
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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 smiley
Logged

Please don't PM me asking for help. Ask questions in the forum.

nr Bundaberg, Australia
Offline Offline
Tesla Member
***
Karma: 126
Posts: 8499
Scattered showers my arse -- Noah, 2348BC.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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.

Quote
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.

______
Rob
Logged

Rob Gray aka the GRAYnomad www.robgray.com

Offline Offline
Newbie
*
Karma: 0
Posts: 12
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
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
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 12
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

Pages: [1]   Go Up
Jump to: