OK - I know this might be a wacky idea

I want a simple way to extend RS232 over longer distances - and I have spent days looking at a lot of different options canbus, spi, i2c , rs485 - whatever. I need simple communications (read slow - 10 kbit would be nice) over long distances (100m +) - but for various reasons, none of those is going to work for me - for example the MCP2515 canbus controller requires high speed SPI and my microcontroller cannot handle that.

So Microchip sells a nice chip - a CAN transceiver, handles 3.3v IO and has a 5v CAN bus lines - MCP2562 - it's pretty simple, has Vcc VDD, Tx & Rx (3.3v) and CANH and CANL (5v) and a pin that puts the chip into standby mode.

Since the main function of the chip is to take 3.3v Tx/Rx signals and convert them into CAN signals out on the bus, why couldnt I send my 3.3v microcontroller RS232 signals to/from this chip down a properly terminated canbus and to another MCP2562 where I have another microcontroller read the resulting 3.3v signals coming off the transceiver there ?

(Assume all I want to do is Tx to one single micrcontroller for now)

Is there any way this would work ?

And is the following 'feature' of the chip going to be a problem ? I don't quite understand how long the chip will wait to decide a PDD condition exists ? i.e. say I put the chip into standby - I dont want to do anything for a while, now I have a message I want to Tx, I take the chip off standby, how long do I have to begin Tx'ing and what should I keep the Tx pin voltage level at while I wait (0v or 3.3v ?)

MCP2562 datasheet attached

1.5 Permanent Dominant Detection
The MCP2561/2 device prevents two conditions:​

• Permanent dominant condition on T

​

XD

• Permanent dominant condition on the bus

In Normal mode, if the MCP2561/2 detects an
extended Low state on the T​

​

​

XD input, it will disable the​

CANH and CANL output drivers in order to prevent the

corruption of data on the CAN bus. The drivers will
remain disabled until T​

​

​

XD goes High.​

In Standby mode, if the MCP2561/2 detects an

extended dominant condition on the bus, it will set the
R​

​

​

XD pin to Recessive state. This allows the attached​

controller to go to Low-Power mode until the dominant

issue is corrected. R​

​

​

XD is latched High until a​

Recessive state is detected on the bus, and the

wake-up function is enabled again.
Both conditions have a time-out of 1.25 ms (typical).
This implies a maximum bit time of 69.44 μs
(14.4 kHz), allowing up to 18 consecutive dominant bits​

​

on the bus.​

 

Not sure why a RS422 or 485 wouldn't work. Which microcontroller?

 

Not sure why a RS422 or 485 wouldn't work. Which microcontroller?

I've used RS422/485 over 1000 feet with standard driver chips with good results. Using CAN will involve all of the hardware / driver issues plus it will add layers of protocol that you'll have to deal with.. breaking up the data stream into 8 byte packets for starters. 4-wire RS422 would be a perfect physical layer for UART comms in that no extra software would be required beyond normal UART stuff.

 

Thanks for that guys - I dont know why I didnt think of RS-422 - getting too tired looking at all this stuff

I looked at the 422 chips - there are 3.3v ones available but none seem to be in DIP format - anyone know of any offhand ?

The chips I am using are the Picaxe 18m2 and the coridium BasicChip ($10 for a Cortex). I looked at adding rs232 to ethernet to them using a ENC28J60 but could not get the SPI to work anywhere near fast enough - the ENC28J60 errata says you need 8mhz SPI to get it to work.

In the end, if the RS422 doesnt pan out I think I am going back to something I used 6 months ago, the Ciseco XRF wireless boards - they're only $15 and the wireless serial is pretty transparent.

 

100 metres is pretty trivial for serial at 10 kbaud.

... (Assume all I want to do is Tx to one single micrcontroller for now)
...

In the interest of absolute simplicity, have you tried just putting the 3.3v digital serial data down the wire? Drive the wire with an RC low pass filter that takes about 1 baud (100uS) to go from 0v to 3.3v, and 3.3v to 0v. That will send as good signal down the wire and the receiving micro's schmidt trigger input will do the rest. If you like you can put a matching RC filter at the receiving end too.

 

Just use two 75176 chips, one TX one RX. Like this
http://www.ebay.com/itm/INBOARD-TTL-to-RS422-RS485-LINE-DRIVER-PIC-AVR-ARM-/120617751420

 

100 metres is pretty trivial for serial at 10 kbaud.
In the interest of absolute simplicity, have you tried just putting the 3.3v digital serial data down the wire? Drive the wire with an RC low pass filter that takes about 1 baud (100uS) to go from 0v to 3.3v, and 3.3v to 0v. That will send as good signal down the wire and the receiving micro's schmidt trigger input will do the rest. If you like you can put a matching RC filter at the receiving end too.

With respect, RB, if you google 'RS232 how far how fast' you won't get the spec I was hoping for but you will get citations that do not support RS232 for anything like 10Kbaud over 100meters, but which corresponds to my experience.

Can you do it? Maybe yes, maybe no. Depends. I've done it on occasion. I've also seen long RS232 fail miserably.

I'd say that if you don't want your comms to be another engineering project, respect the spec and go with the balanced RS422/485.

YMMV

 

I looked at the 422 chips - there are 3.3v ones available but none seem to be in DIP format - anyone know of any offhand ?

Sure. Maxim has a bunch. Check out the apnotes as well.

 

With respect, RB, if you google 'RS232 how far how fast' you won't get the spec I was hoping for but you will get citations that do not support RS232 for anything like 10Kbaud over 100meters, but which corresponds to my experience.

Can you do it? Maybe yes, maybe no. Depends. I've done it on occasion. I've also seen long RS232 fail miserably.

I'd say that if you don't want your comms to be another engineering project, respect the spec and go with the balanced RS422/485.
...

I think we are talking slightly different things? You are talking about exact RS232 spec, I was not talking about that but about what will work, ie 100 metres and a 10kbaud 0-5v signal which will work fine, particularly with the filter I mentioned.

I have built many serial comms systems and sometimes followed a traditional spec, sometimes not.

As an example, on one machine I use every week I have a cheap nasty shielded mic cable about 30 metres, running 115 kbaud 0-5v TTL levels and it has run flawlessly for years. The cable also runs around a heap of mains power cables. Part of the secret is to put that RC filter at the transmission end so the cable is being driven with soft transitions, this makes the cable capacitance fairly irrelevant. My 30 metre cable at 115kbaud has a visually identical signal coming out compared to what went in.

As for yourt link saying you can only get 15 metres from a standard RS232 cable, that is WAY off. In the early PC days I used RS232 serial ports for data transfer and gaming all the time (for years!), and used a 50 foot telecoms cable running at 56 kbaud.

I'm not saying you are wrong for suggesting that the offical spec be respected and followed, because that is good advice. But the OP asked for "a simple way to extend distances" and running an RC filter at the start will allow 10kbaud over very long distances, even in a worst case situation using 0-5v logic level data instead of higher voltage bipolar data.

 

All very interesting ideas and a big help to get other viewpoints - all of them

I hooked my scope up to a 1000' cat5 wire and looked at the signal as I pulsed a TTL down it - pretty interesting stuff, I can see how adding what I think of as a Peak Detector would work to smooth that signal out so it would be usable. That is on my list of things to experiment with.

However, as John mentioned above I dont want this to turn into yet another 'engineering project' I've got too many of those already lol - so I have been working on a RS422/485 design as that seems the safest and way more straightforward than my original canbus idea - altho I did see a thread about using a canbus driver to do RS485.

One of my issues is wire cost and cost in general of course. I have 8 devices I want to control - think of a square, 200 feet on a side with 2 of each devices in the corners and the control center in the center. So a single bus for RS422/485 is 1000 feet. And then I was going to use long digital signals to tell the MCUs who has permission to TxRx. So figure 1600 feet of cat5 and assorted install hardware, pipes supports etc. (this is outdoor so need to protect the wiring).

In thinking a little more about this, I could chop the wiring down to 600 feet by using multiplexing the signals but that requires more chips. Anyways I ordered a bunch of stuff over the last few days, put it together and see if I can get it all to work.

 

Roman - interesting thing - I went out to your website and saw your electret sound ranging experiment : http://www.romanblack.com/SonicRanging/Sonic_Ranging.htm

The devices I want to communicate with are doing something very similar - electrets w/opamps which check the time of any loudsounds (gunshot detector) and determe the direction / distance. I did much the same tests as you did, only I used a a speaker and wav files to play fixed sounds to test with. Looked like it worked pretty well. My work so far says an arrangement of 3 mics gives me the direction of a loud sound and by having 4 units at each corner of the square described in my post above communicate their directions to a central processor, then I can use those angles to triangulate a distance.

Fun stuff

 

Sounds like a really cool project. Please keep us informed as it develops!

 

I just wanted to come back and update this thread - big thanks to those of you who pointed me in the RS485 direction. I've gotten my 3.3v RS485 chips and done some testing and been very pleased. I'm running RS 485 over 1000' of cat5 (one way) and no problems thus far. While waiting for parts to get here, I also spent time updating the custom app I wrote on my PC to receive the data so it can redirect RS232/serial - USB over TCP/IP - to do this I found a free app called Comm Tunnel that appears to work quite well :

http://www.serialporttool.com/CommTunnel.htm

I had to try a lot of different things to get all that to work - there is a second app called HSTCP2com :

http://www.hillstone-software.com/hstcp2com.htm

that also works well and has some more flexibility but isnt free. I am sure there are others but out of the dozen or so I tried these seemed to work the best.

I use Powerbuilder during my day job and tying it to the windows API allows me to use window sockets to talk to the RS485 network - with the Comm Tunnel started up as a client and my PB app as a server. Data starts in PB, out thru winsock and IP address + port to Comm Tunnel which reroutes it to USB / serial cards (cheap ebay ones) which goes to a RS485 driver chip, down 1000' of cat5 to another RS485 driver chip tied to a microcontroller with a UART.

Then the return trip in reverse.

Works pretty well in testing thus far. The RS485 does not seem to be overly sensitive as to the resistors used to set the voltage for the A & B lines - and I'm using 100 ohm terminating resistor which matches the cat5 impedance better than a 120 ohm (and I have 1000 of them in a box and no 120's - - right now I only have only one termination resistor and it all still works fine. I used 380 ohm resistors and 1000 ohm resistors paired with the 100 ohm term resistor (3.3v Vcc) to power the bus : ie.e.

Vcc (3.3v) -> 1k R -> (A line connected here) 100 R (B line connected here) -> 1k R -> Gnd
OR
Vcc (3.3v) -> 380 R -> (A line connected here) 100 R (B line connected here) -> 380 R -> Gnd

and both sets seemed to work just fine - so the whole setup seems pretty robust.

I'm attaching some screen shots of the apps in case anyone wants to see the comm tunnel settings I used. I did actually run this a bit @ 920k and 460k over the 1000' and it worked, altho one time the 920k locked up. But this does not really provide much speed increase over say 57k with short messages - I was sending 5 byte strings and rough testing shows about 600 to 1000 messages per second over this setup.

Next is to tie several RS232/RS485 'branches' into a single IP address and see how much data can be fed down the pipe and if it causes any problems. For me even 10 or 20 messages a second would be ok, one thousand is a lot of extra space for loading down the network.

I've also thought a lot about how to handle contention and in reading a bunch it seems like the simplest and most robust would be to just have the master poll the slaves. Lots of other methods but with such short messages and getting so much better performance than I need this should work just fine. Robust and simple is more important than speed for my needs.

Anyways, thanks again, works fine so far and when I get the hardware all fixed up I will post some fotos here again.

 

RS-485 twisted pair and obey proper transmission line termination at both ends. Line biasing at one end.
1200m @ 100kbit/s

 

I've also thought a lot about how to handle contention and in reading a bunch it seems like the simplest and most robust would be to just have the master poll the slaves. Lots of other methods but with such short messages and getting so much better performance than I need this should work just fine. Robust and simple is more important than speed for my needs.

That's how I've done it. For master/slave you'll need a protocol to keep it all organized which specifies the address of the receiver. All slaves listen in long enough to get the address. Only the addressed one processes the message. The others just read and discard until EndOfMessage indicates they should start listening again for the address. MANY variations on this but that's the basic idea.

Take a look at Access.bus and Modbus protocols for ideas.