Protocol for low rate data over a single wire

[cowana]

I'm developing a driver board to control several channels of high power LEDs. This board will consist of several constant current regulators for the LEDs, and a microcontroller to PWM them. The board will get the required PWM levels from a controller located seperatly (and controlling multiple driver boards).

For interests of cost, I want to use regular 3-core mains cable to connect the lights to the central controller. With GND and +24v on two wires, this leaves one wire for the (single direction) comms from the controller to the light. The distance is likely to be up to 20 meters. The data being sent is low (around 6 bytes per update) - but to maximise expandability it would be nice to be able to send packets at around 50Hz (which translates to around 2400 baud).

If I had both the controller and driver on a single board, I would use standard TTL serial to communicate between them. Ideally for this distance I would like to use RS485 - however this isn't possible due to being restricted to one wire (plus ground).

I would imagine the best solution for my application is standard serial coding, but with something more noise resistant than 3.3v logic level serial. Would +12v/-12v RS232 levels be more suited? 0v/+24v levels? Have a load resistor at the driver to use current signaling (say 0mA/20mA levels)?

The environment is not particularly electrically noisy - however the 0v/24v wires in the cable may well have a slightly pulsed current in it due to the switching nature of the driver.

Cheers,
Andy

[Boltar]

I can only say what I'd consider doing in the same situation, which may not be the best solution, I've only just started doing this stuff myself. Personally, I'd pull the data line up to your highest voltage available, say 24V via a resistor, then pull that line to ground at the transmission end with a transistor to create a binary data stream. Then a comparator (high voltage one) on the receiving end to shift the 24V/0V to 3.3V/0V using a 12V reference threshold and a large amount of hysteresis to deal with any possible noise induced in to the data line by the power line. Also has the advantage of being bi-directional in case the need ever arises.

[fcb]

I'd write my own protocol personally.  Signal the data line at something like 0 & 12V, and use a zener diode & potential divider on the receive pin of the micro (4K7 & 47K - use the zener to prevent over voltage).  Run the protocol as slow as possible BUT allow for a >15bit period pause between packets so your receiver can sync easily to the data.

Alternatively look at LIN.

[David_AVD]

I'd probably go with the system Boltar is suggesting.  The comparator receiver should work well and is cheap.

I would use a beefy than required NPN transistor or MOSFET (say 2A rated) to sink the current and add a 100mA polyswitch in series with the outgoing data line.  This will give the driver stage protection against a short to the +24V line.

[mikerj]

Sounds like the open drain  bi-directional single wire interface used in e.g. ISO9141 would fit the bill at the physical level.  A simple protocol with a fixed frame length makes decoding easy and reliable.

[cowana]

Thanks for the suggestions - as mikerj summed up, that open drain scheme sounds best (and does allow future expansion of bidirectional comms).

Does it matter which end of the bus the pullup resistor is on? It seems if it is at the remote device end then any voltage drop/fluctuation along the length of the power wire will be coupled onto the data wire. However, if the pullup is at the master controller end, it's basically a long wire only connected at one end - and could like an aerial and pick up noise from the power wires.

Maybe one pullup (each twice the equivalent value) at each end of the wire is a better solution? Or am I over thinking this?

Andy

[tszaboo]

I would use LIN. It has drivers, hardware support, software support, proven working, cheap.

[mikerj]

I would use LIN. It has drivers, hardware support, software support, proven working, cheap.

I agree that LIN drivers are cheap and robust, but the LIN protocol itself may be a little more complex than the OP's design warrants. 

[Richard Crowley]

You may be under-estimating the amount of interference you will see from the high-power PWM. You didn't mention what the current levels are that you are designing with.  But I question the practicality of using ordinary 3-core power cable and unbalanced data. I really think you need a balanced data transmission path to deal with the hostile environment of high-power PWM.

Could you use Cat-5 cable with 6 of the 8 wires dedicated to power distribution, and a remaining balanced pair for the data transmission?  Since we don't know what kind of currents you are planning on, we don't have any idea whether this is a practical suggestion.

Of course, another method of dealing with unreliable data transmission would be to continuously transmit the data and accept only the messages with proper check-sums.

[Richard Crowley]

There is also wireless data transmission.  For < US$20 you can get a postage-stamp size board with a full microcontroller (for the message deciding and the pwm control) PLUS wireless data transceiver.  (i.e. Moteino et.al.)  Then you could use any old 2-core power cable.

[daqq]

Take a look at SDI-12. Slow as they get, simple hardware, low power.

[Neilm]

For interests of cost, I want to use regular 3-core mains cable to connect the lights to the central controller.

Is this a commercial product? If so you had better check what ever regulations you need to comply with. I know several that state if there is  yellow/green in a wire, it can ONLY be used for connections to safety earth, even if the unit is battery powered and doesn't connect to mains.

[David_AVD]

For interests of cost, I want to use regular 3-core mains cable to connect the lights to the central controller.

Is this a commercial product? If so you had better check what ever regulations you need to comply with. I know several that state if there is  yellow/green in a wire, it can ONLY be used for connections to safety earth, even if the unit is battery powered and doesn't connect to mains.

Is this really the case when the connectors are not mains types?

[tszaboo]

I would use LIN. It has drivers, hardware support, software support, proven working, cheap.

I agree that LIN drivers are cheap and robust, but the LIN protocol itself may be a little more complex than the OP's design warrants.

I dont think LIN is much harder than UART. You need to configure like 2 extra registers in your MCU, and since the communication is uni-directional, there is no timing requirements.

[tylernt]

cowana, you might look at the Dallas 1-wire protocol for inspiration in designing your own.

[T3sl4co1l]

I can only say what I'd consider doing in the same situation, which may not be the best solution, I've only just started doing this stuff myself. Personally, I'd pull the data line up to your highest voltage available, say 24V via a resistor, then pull that line to ground at the transmission end with a transistor to create a binary data stream. Then a comparator (high voltage one) on the receiving end to shift the 24V/0V to 3.3V/0V using a 12V reference threshold and a large amount of hysteresis to deal with any possible noise induced in to the data line by the power line. Also has the advantage of being bi-directional in case the need ever arises.

I also like this.

Another possibility is to use two wires, period: you can, for example, couple modulated RF onto the power lines.  In a closed system, you don't have to worry too much about signal levels or frequency ranges (no need for radio stuff like AGC and tuning), and the RF can be differentially coupled so it stays in the wires (which can be twisted pair).

Tim

[mikerj]

I would use LIN. It has drivers, hardware support, software support, proven working, cheap.

I agree that LIN drivers are cheap and robust, but the LIN protocol itself may be a little more complex than the OP's design warrants.

I dont think LIN is much harder than UART. You need to configure like 2 extra registers in your MCU, and since the communication is uni-directional, there is no timing requirements.

I'm talking about the actual network protocol, not the hardware layer.  For LIN there are 6 different frame type, variable payload size, multicast reception etc. which would have to be dealt with if you followed the specification to the letter.

[Neilm]

For interests of cost, I want to use regular 3-core mains cable to connect the lights to the central controller.

Is this a commercial product? If so you had better check what ever regulations you need to comply with. I know several that state if there is  yellow/green in a wire, it can ONLY be used for connections to safety earth, even if the unit is battery powered and doesn't connect to mains.

Is this really the case when the connectors are not mains types?

Yes - IEC61010-1 has a clause that goes "green or green / yellow wires not used for any purpose other than safety earth". I had to reject a design for breaking that very clause a few years ago.

[zapta]

I'm talking about the actual network protocol, not the hardware layer.  For LIN there are 6 different frame type, variable payload size, multicast reception etc. which would have to be dealt with if you followed the specification to the letter.

Since the OP controls both the master and slaves, he can implements a subset of the protocol or a variation of it.

IIRC the LIN transceivers expect 12V so if he change from 24V to 12V it will be even better fit.

[David_AVD]

For interests of cost, I want to use regular 3-core mains cable to connect the lights to the central controller.

Is this a commercial product? If so you had better check what ever regulations you need to comply with. I know several that state if there is  yellow/green in a wire, it can ONLY be used for connections to safety earth, even if the unit is battery powered and doesn't connect to mains.

Is this really the case when the connectors are not mains types?

Yes - IEC61010-1 has a clause that goes "green or green / yellow wires not used for any purpose other than safety earth". I had to reject a design for breaking that very clause a few years ago.

I understand that, but what I'm asking is does that standard even apply in the case of a non mains powered device?

[Richard Crowley]

does that standard even apply in the case of a non mains powered device?

As long as you don't use conventional mains-type connectors at any point in the circuit, and the cables are already terminated in non-mains connectors so there is no confusion about what the common colors mean.

I continue to believe that attempting to send baseband data over a path which depends on such a noisy ground/return path is doomed to failure.  Perhaps FSK modulating the digital data onto some higher-frequency carrier can make it easier to filter out the noise from the PWM switching of the high-current loads.  I don't recall seeing any clarification or revelation of the kinds of currents we are talking about here, so we are all shooting in the dark here.

[cowana]

cowana, you might look at the Dallas 1-wire protocol for inspiration in designing your own.

I do like the idea of the master controlling the communication (particulally if there are multiple slaves on the bus). I may well end up using some of the OW system's aspects in my scheme.

I'm talking about the actual network protocol, not the hardware layer.  For LIN there are 6 different frame type, variable payload size, multicast reception etc. which would have to be dealt with if you followed the specification to the letter.

Since the OP controls both the master and slaves, he can implements a subset of the protocol or a variation of it.

IIRC the LIN transceivers expect 12V so if he change from 24V to 12V it will be even better fit.

It looks like you can get LIN tranceivers that run happily on 24v. I would imagine the simple open collector scheme would provide enough signal integrity (I will use checksums and can repeat corrupted data) - however I'll have to do some testing and experimentation to see if this is the case or if something more robust is required.

does that standard even apply in the case of a non mains powered device?

As long as you don't use conventional mains-type connectors at any point in the circuit, and the cables are already terminated in non-mains connectors so there is no confusion about what the common colors mean.

I continue to believe that attempting to send baseband data over a path which depends on such a noisy ground/return path is doomed to failure.  Perhaps FSK modulating the digital data onto some higher-frequency carrier can make it easier to filter out the noise from the PWM switching of the high-current loads.  I don't recall seeing any clarification or revelation of the kinds of currents we are talking about here, so we are all shooting in the dark here.

At 24v, the current involved will likely to be <1A (average). The LED drivers run at around 450kHz, and state a peak current draw of around 1.5 times the average (although I'd imagine this could be closer to 2 times worst case). There will be a couple of hundred uF of low-ESR decoupling capacitors located in the slave device, so hopefully the peak current's in the cable shouldn't be too high.

I am hoping to make this PCB as flexible as possible, so in addition to the open collector scheme (or LIN if required), I will also include (unpopulated) footprints on the PCB for RS485 (via twisted pair) and 2.4GHz wireless modules, to allow for future expansion.

This system is being designed for one-off manufacture for personal use, so certification requirements shouldn't be an issue.

Andy

[Boltar]

I'll be very interested in how you implement this especially if you eventually make it wireless. It's been a little dream of mine for a while to install strip lighting around the main room here. There is a rail 3/4 of the way up the wall all the way around the room, so I could place the strips there and have them "uplighting" so to speak. But what I actually want to do I've never seen available. That is to have a wireless box stuck on the wall with three pots for red, green and blue. That would allow a huge range of intensity and hues and be very simple. I'm not bothered about cycling or strobing or any of that stuff. The only kind of "complete" solutions I've seen come with those crappy dome button, button cell remotes that work for a week or so then die forever, and the remotes do not give you nearly enough control over brightness and hue.

Would you mind keeping this updated with any progress you make? Assuming you're willing to share of course

[Richard Crowley]

I would use ordinary "LAN" Cat-5 cables with RJ-45 connectors.  Dirt cheap. Easily available in different lengths.  Easy to DIY custom lengths.

Cat-5 cable is rated "Maximum current per conductor = 0.577 A"
So 3 conductors would total capacity > 1.5A 
3 for supply, and 3 for return, and one pair for balanced data.
There are many pieces of gear that use exactly this wiring scheme.
The industrial remote-control pan-tilt heads for my cameras use exactly this scheme.

[mikerj]

I'm talking about the actual network protocol, not the hardware layer.  For LIN there are 6 different frame type, variable payload size, multicast reception etc. which would have to be dealt with if you followed the specification to the letter.

Since the OP controls both the master and slaves, he can implements a subset of the protocol or a variation of it.

Yes, we've come full circle as this is what I implied in the original post.