RFC: 1-Wire PWM dimmer/motor controller for 12V vehicle systems

[Lomax]

Hi all,

I'm currently designing the electrical system for a houseboat, which I want to include a certain level of automation. For various reasons, I have decided to go for a 12V (nominal) "house" electrical system, with a 1-Wire automation bus, and I'm currently trying to finalise the design for an embedded dimmer circuit. Pretty much every single light source on board (navigation lights excluded) will have its own independent PWM dimmer, and I would also like to be able to use the same boards to control small motors, such as ventilation fans (up to ~2A/25W). The design is based on the BAE0910 1-Wire slave, which provides a great deal of flexibility, with low power consumption and a small footprint. The power input is designed to accept whatever voltage is presented by the 12V house battery bank, which can vary between 11.5-14.5V, depending on state of charge and charger operation.

To enhance reliability of the 1-Wire link, this has a separate data ground, allowing the GNDD to "float" along with the 1-Wire data line (DQ) with respect to the power GND. For this purpose 5V Vcc is provided by an on-board buck converter, isolated from the 12V supply by a small choke. The boards can be "daisy-chained" with pass-through connectors for 1-Wire and 12V power, as well as two push-button buses which can be selected by means of a jumper - the intention being that a given string of lights can be divided into two groups, with on/off/dim controllable from a single push button for each group - which should remain operational regardless of whether the main computer control system is online or not.

Although I'm pretty inexperienced in circuit design, I've beaten my way through the jungle and have now reached a point where I think it's time to build a first prototype - but before I start working on the board layout I thought I'd ask the knowledgeable people on this forum for comments on my design, lest I waste time laying out a broken circuit. I would be very grateful if anyone would care to cast their eyes on this schematic and let me know if they spot any obvious faults.



Wrt the buck converter, I am trying to decide between the Texas Instruments TPS62120, which can deliver up to 75mA with a quiescent current of just 13uA, and a 90% efficiency with a 12V input and 5V 10mA output, and the higher power 500mA TPS560200, which is why both those alternatives are included on the schematic. I am leaning towards the lower power TPS62120, in the interest in reducing power consumption, though it does cost nearly twice as much as the TPS560200. The 15V max Vin of TPS62120 also lies uncomfortably close to the up to 14.5V which may be present, though cable losses and the 0.3V drop of the polarity protection diode improves that margin somewhat.

As the design is for a (diesel) vehicle, I have tried to protect it from ESD with TVS diodes on the external connections, and would be interested to hear if this is going to be sufficient, considering noisy alternator and starter motor, and the threat of nearby lightning strikes.

[ovnr]

Nothing shockingly bad. I'm just going to jot down some points:

* You WILL see spikes well in excess of 14.5V. I'd never design anything automotive-related that couldn't cope with at least 24V continuous.
* You may want to add a PTC fuse and a beefy TVS/zener on the 12V side to protect against spikes.
* Your quiescent current is probably less important than you think it is. An Iq of 100 µA will take 68 years to drain a 60Ah battery.
* Your ground isolation is not really going to accomplish very much. If you're willing to string four wires to everything (+12V, signal, PGND and SGND), why not go for RS-485 and a different controller? It's much more reliable, and actually intended for the application. You can also avoid the complexity of your isolated gate driver, etc.


Also, I noticed that the BAE0910 is insanely expensive at €18/pop. It's just a pre-flashed microcontroller. Since you're making a few, I'd really recommend rolling your own solution and saving €170+.


If you just want a solution and not a project, I'd be happy to throw together something for you.

[Benta]

Check this thread for a recent discussion on overvoltage in boats:
https://www.eevblog.com/forum/chat/alternator-diodes/

[Lomax]

Nothing shockingly bad.

Phew! Thank you. Always a bit nervous about showing my crazy ideas on the Internet

You WILL see spikes well in excess of 14.5V. I'd never design anything automotive-related that couldn't cope with at least 24V continuous.

Roger that - strong argument for going with a higher input voltage buck converter. If not, could I clamp it with a zener?

You may want to add a PTC fuse and a beefy TVS/zener on the 12V side to protect against spikes.

A PTC is a good idea, will take a look at cost & footprint. I do already have a TVS on the 12V input, the SMAJ15, though this clamps at a much too high voltage (24.4V).

Your quiescent current is probably less important than you think it is. An Iq of 100 µA will take 68 years to drain a 60Ah battery.

True. Though you have to multiply that for every dimmer, maybe ~20 in total. I also thought the smaller buck converter would be more efficient at low currents - the design has an estimated 10-15mA draw on the 5V side. Even if it's cheaper, a 500mA converter seems like total overkill?

Your ground isolation is not really going to accomplish very much. If you're willing to string four wires to everything (+12V, signal, PGND and SGND), why not go for RS-485 and a different controller? It's much more reliable, and actually intended for the application. You can also avoid the complexity of your isolated gate driver, etc.

You say that, but what if the (single-ended) 1-Wire data connection is twinned with data ground in a separate twisted pair? Now any induced currents should shift them both by the same amount, offering both some protection against over-voltage on DQ and an improved signal. A differential scheme like RS485 would be more resilient, but 1-Wire has a more flexible topology and is supported out of the box by the automation control software I will be running (Domoticz). I will be using RS485 in a few places, for example for talking to the inverter/charger, and solar charge regulators, but these are less "networky" connections.

Also, I noticed that the BAE0910 is insanely expensive at €18/pop. It's just a pre-flashed microcontroller. Since you're making a few, I'd really recommend rolling your own solution and saving €170+.

It's a pre-flashed MCU with a very clever piece of firmware. 1-Wire interfacing is quite complicated. And they're not €18 but €10, when bought in quantity >25 (which I would be). I think you were looking at the far more advanced BAE0911.

If you just want a solution and not a project, I'd be happy to throw together something for you.

Thank you, that's a very kind offer! However, a lot of thought has gone into deciding on the interface and topology of this design - I'd like to see if I can get it to work. Estimated finished board cost is well under £20 per board, which is fine by me. Other people have been asking me why I've chosen a 12V system instead of a 24V one. All these debates can be had - I just want to say that they are not chance decisions taken without consideration. I have looked at RS485, CAN bus, Ethernet, NMEA... 1-Wire won.

[tatus1969]

Your GND0 potential is not only used to reference the signaling, but it also carries the sum of all local power supply return currents up to a single point where you connect it with GNDPWR. You will probably not be using thick wires for the "OW" pair, and the supply current of all active nodes could again sum up to ground level shifts that you initially want to avoid.

I see no real advantage of 1-wire comms when you then add a second wire (and again, use it for power return). I would also rather go for RS485, or CAN. Both use two wires and differential signaling. There is also the automotive LIN bus, using only one wire, that is used in the automotive area for just the purpose of intelligent light control and similar. They make it tolerant against ground shifts by using the full 12V bus voltage, and suitable low-pass filtering.

Maybe powerline communications can be an option. It completely eliminates the additional wires, and talks directly through the power wires. TDA5051 is a popular candidate. You need to add a microcontroller, and a suitable coupling network. The datasheets gives a good starting point.

[Lomax]

Your GND0 potential is not only used to reference the signaling, but it also carries the sum of all local power supply return currents up to a single point where you connect it with GNDPWR. You will probably not be using thick wires for the "OW" pair, and the supply current of all active nodes could again sum up to ground level shifts that you initially want to avoid.

Almost correct; GNDD will carry the sum of all the 5V supplies on any particular spur, the largest of which (currently) consists of 12 nodes over a (cable) distance of 15 metres. 12x15mA = 180mA, should be fine on a 15m length of 22AWG/0.25mm², no?

I see no real advantage of 1-wire comms when you then add a second wire (and again, use it for power return).

Ok, so I really don't want to get into a discussion of the pros and cons of 1-Wire comms, but in brief:

• 1-Wire is designed for minimal power consumption
• It allows weird mixed topologies
• It is self enumerating
• It is supported natively by Domoticz
• OWFS

I think the aversion many people seem to have towards its usage is simply that they don't know enough about it, or that by habit they feel more comfortable with other interfaces. I partly think this is Dallas' own fault, for failing to promote it properly.

Edit: In my particular case there is another benefit of using 1-wire: there will already be a 1-Wire master computer on board anyway, to which various weather, level and temperature sensors will be connected. In fact there will be two of them, for slightly different kinds of tasks, with different levels of guaranteed availability. And there's a third embedded computer on board, for navigational tasks, running (amongst other things) the wonderful OpenCPN chart plotter package. This has GPS and AIS receivers connected over USB. And these three computers talk to each other over Ethernet. So I'm actually using 1-Wire, RS485, USB and Ethernet to build this system.

[janoc]

Ok, so I really don't want to get into a discussion of the pros and cons of 1-Wire comms, but in brief:

• 1-Wire is designed for minimal power consumption
• It allows weird mixed topologies
• It is self enumerating
• It is supported natively by Domoticz
• OWFS

I think the aversion many people seem to have towards its usage is simply that they don't know enough about it, or that by habit they feel more comfortable with other interfaces. I partly think this is Dallas' own fault, for failing to promote it properly.

People aren't stupid.

The problem you are completely overlooking is that apart from Dallas parts almost nothing uses it. Also most parts that actually used it are now obsolete/EOL. You will most likely discover few years down the road that you can't get the components you need for it anymore and will be faced with redoing the setup or having to roll your own interfaces and everything.

RS485 is a simple UART that any cheap micro can handle and CAN is present in many $1-2 micros, ready to go, needing only an interface chip (costing few cents). You can also exploit the availability of the automotive components that are designed to work with LIN/CAN buses, saving costs and reinventing the wheel. There are also cheaply available USB dongles for these - useful for development & testing.

I don't see the advantage of designing in a part that costs $10 in quantity and is the same $1 microcontroller bitbanging the 1-wire bus. And we aren't even starting to get into signal integrity problems and such which you are going to fight in a noisy environment like a car or a boat. RS485 and CAN use differential signalling for good reasons and certainly not because the designers weren't familiar with 1-wire 

[ovnr]

Ok, so I really don't want to get into a discussion of the pros and cons of 1-Wire comms, but in brief:

• 1-Wire is designed for minimal power consumption
• It allows weird mixed topologies
• It is self enumerating
• It is supported natively by Domoticz
• OWFS

I think the aversion many people seem to have towards its usage is simply that they don't know enough about it, or that by habit they feel more comfortable with other interfaces. I partly think this is Dallas' own fault, for failing to promote it properly.

I quite like 1-wire, but it's not really well suited for large-scale things (bus capacitance can get excessive, it's not at all noise-immune, etc). I've used it a lot, but only for things residing in a single enclosure.

As for your points:
* If you use fail-safe RS485 transcievers, it consumes no bus power when idle.
* What do you mean by weird topologies? If you don't run RS485 anywhere close to "fast", you don't have to care too much about termination and such.
* Most buses can be self-enumerating. I've got a custom 1-wire bus I use a bit (just open-drain UART with RX/TX on the same wire, with hard time slots): Self-enumerating. I2C? Self-enumerating. RS-485? If your protocol uses addresses, it's self-enumerating. For any small bus, your address options are unlikely to exceed 16 bits, so it's fairly trivial to just poke all 65536 addresses. And realistically you'd be fine with just 8 bits.
* Software support: *shrug*. OWFS boasts 300k total lines of source to... let you read sensors? That doesn't sound like an advantage, tbh.


Back to the hardware:

* The separate signal ground will do little, because any junk on +12V will be coupled to it via L2 (filter inductor before DC/DC) and C4/C5 (input caps on DC/DC). The switching ripple on +12V from the PWM will also be coupled to it.
* Buck converters: Use TI's power architect thing to calculate efficiencies. It's not going to be a massive difference - DC/DC efficiencies don't scale quite as horribly as PC power supplies, for instance, unless you compare something wildly different like a 25 mA reg and a 50 A reg.


And to stop being Negative Nancy for a second: I really do like your layout - it's clean, easy to read, and you've clearly put some thought into it. It's certainly better than what I'd expect from a first-timer.

[Lomax]

Ok, ok, ok, let's not turn this into a stupid argument about the pros and cons of X vs Y. I count three out of three endorsing RS485 as the better alternative - you have convinced me to take another look at it, though I will need to be reassured on power consumption, topology and enumeration, so anything you can provide me in terms of links which might help with this would be... helpful.

And not to but I would like to answer a couple of the points raised against 1-Wire.

Noise immunity: while 1-Wire doesn't have the benefits of differential signalling, it does have a 5V voltage difference and built in error checking/retries. I'm sure I've seen examples (on the Internet) of very large networks of 1-Wire sensors, hundreds of nodes over long distances, running without any issues. I'll see if I can dig up any of them now.

OWFS: Don't knock it just because it's a library; the functionality it provides is pretty damn neat, and goes well beyond "reading a sensor value". For one thing it is a read/write file system, so you can write data directly to a node - indeed this is how the BAE0910s are programmed. The "self awareness" a 1-Wire system provides is pretty impressive IMO.

Topology: By "complex topology" I really meant "mixed topology". As long as you take care to minimise reflections and don't go completely overboard you can freely mix star, line and tree topologies. All that's needed to add a node to the network is to connect it to the nearest 1-Wire bus and power it up. A minute or so later, OWFS on the 1-Wire master will be aware of the node and its capabilities. Nodes have a unique random ID, so it doesn't matter if you move them around or switch them on/off; they will always be recognised as the same device.

Domoticz: I have already been using this home automation system for a couple of years and I am extremely fond of it. To the point where I have actually donated money towards the project. It really is quite good. But while I'm sure it's perfectly possible to use any kind of device interconnect you might like to use - including RS232 infrared transceivers if you still live in the 20th century - 1-Wire support (via OWFS) is built in to Domoticz from the get go - plug your node in, power it up, a minute later it is listed in Domoticz list of devices, and you can start using it.

Obsolescence: Yes. Agreed. There is some concern that Dallas have seemingly abandoned 1-Wire. But I think it is a sufficiently open standard, with a sufficiently wide adaptation in the processing industry to survive. There are a number of companies who produce sensors and interfaces for 1-Wire - and it was even included on the top-tier hardware hacker / small industry PLC Monarco Hat. I can provide many more examples of new and exciting 1-Wire hardware. So while it looks like the poor cousin of CAN bus, or LIN bus, I don't think you should dismiss it quite so readily.

[Lomax]

And to stop being Negative Nancy for a second: I really do like your layout - it's clean, easy to read, and you've clearly put some thought into it. It's certainly better than what I'd expect from a first-timer.

Now you made me blush

[Ian.M]

I did suggest LIN transceivers in your previous topic, and pointed out that there was a track record of using something very similar over fairly crappy cabling in marine applications - the  Autohelm proprietary original 'SeaTalk' instrument bus. 

At €10 per MCU. and with one of the pins directly connected to the bus (they should have provided two pins , one data in, the other the active low open drain data output so you could tie them together for short well screened buses, or separate them and use external buffers) there is an even stronger incentive to *AVOID* them and re-think the protocol.   Any Dallas/Maxim 1Wire sensors can be on short local busses with a node on the main bus acting as a protocol bridge.

Concepts to keep from 1Wire:
* Globally Unique hardware address including device family
* fast discovery

I'm agnostic on whether it should be a single ended bs like LIN or differential RS485

It shouldn't be too hard to knock out an addressable 9 bit bootloader for any MCU with a 9 bit capable UART and self-write FLASH.  If you add a LONG time-constant RC network and a micropower PSU supervisor, it should be possible to reliably put all the devices into bootloader mode by holding the bus in its dominant state for tens of seconds.  Then if you reserve all addresses with the high bit set for bootloading, the nodes can simply exit to the main application if they see an address (or discovery starts with) the high bit clear.   You've got a bit more work to do if you want to use AVRs with the Arduino toolchain - a 9 bit aware bootloader and an AVRDUDE replacement to talk to it would be needed.

At the master end, well that's a matter of bridging to some protocol that Domotix can talk . . . .  Its a pity it doesn't seem to have (much) DMX-512 support.

[janoc]

Here is a good primer to RS485:
https://www.lammertbies.nl/comm/info/RS-485.html
http://home.scarlet.be/colleman/techinfo/Rs232/spec.htm

RS485 is really easy, because it is regular serial UART, only the electric signalling is different. So trivial to interface to any microcontroller. However, that is also a disadvantage - there is no error recovery or anything bus arbitration or anything like that. If  you need something like that, you have to implement it yourself.

Here is some intro to CAN, to give you an idea:
http://www.digikey.com/pt/en/techzone/microcontroller/resources/articles/can-primer-creating-your-own-network.html
http://www.keil.com/appnotes/files/apnt_236.pdf
http://www.computer-solutions.co.uk/info/Embedded_tutorials/can_tutorial.htm

CAN is a broadcast bus - every message is heard by every other device, then you can filter by various IDs. The CAN interfaces in the microcontrollers handle that for you in hw. CAN has many robustness features built-in, does automatically handle bus arbitration so devices don't talk over each other, can recover from various failures, etc.


LIN is OK too, but if you are going to wire the entire boat, CAN will likely give you more features for the future, because any device can talk to any other that is sitting on the same bus. LIN is master-slave, that could become a bottleneck in the future if you decide to add some more devices to the network.

Also the fact that RS485 and CAN are differential is a large advantage over something like LIN or 1wire that you discover the moment you press the transmit button on your boat's radio (I assume that if you need lighting control the boat is large enough to have a radio as well) or turn on some electric motor.

[Ian.M]

Yes. There are many marine industry instrumentation and control buses already using CAN, including NMEA-2000.

[Lomax]

Since we are in learned company, let me expand on things a little bit to give you a better idea of what I'm trying to achieve. It all started off with me wanting to buy a small house somewhere in the sunny southeastern countryside of the UK, where I could settle down and grow old. But despite trying to save up for years, getting even the minimum required 20% deposit together seemed beyond me - house prices kept going up at the same rate I could stash money away. Then Brexit happened and the whole appeal of staying in the UK dropped by something like a country mile. Yes, I'm one of those horrible scrounging EU migrants who've come to rob the UK of its NHS, its jobs, and its unemployment benefits - almost twenty years I've been at it too! I'm really sorry to see the UK go, and think it's a pitiful mistake they've made, but hey, life goes on! The direction of my plans duly, and thoroughly, shifted, I instead decided I'd try and fulfill another one of my life dreams; to live on a houseboat on the canals and rivers of Europe. So I promptly dumped my meagre savings on a rusty old barge, with, in hindsight, perhaps a tad too little hesitation.

That was six months ago, and with said barge now being rather less rusty, courtesy of an extended stay in a very expensive boatyard, it's soon going to be time to start working on the internal fit-out, which of course includes a brand new electrical system. To me, and I'm sure you'll all agree, this is the most interesting part of owning a boat, from a technical perspective: the quirky particulars of minimising power consumption, the plethora of sensors and actuators, the infinite scope for automation and monitoring, the challenging environmental conditions. A houseboat is a veritable geek paradise and I intend to embrace that opportunity fully.

I've spent much of my spare time this winter working on the design of it, going through many iterations and complete re-thinks, and this is the gist of what I've settled on:

The DC electrical system is 12V nominal. I considered 24V, which has some benefits, most importantly the lower cable losses, but 12V won because of the wider availability of cheap components, and the cost and losses of doing 24V > 12V DC/DC conversion. Pretty much any piece of equipment I would like to use is available in a 12V version. Try finding a 24V DAB radio, LCD monitor, or audio amplifier for example. Yes, they exist, of course, but the selection is more limited, and prices are higher. From what I've seen, quality is also lower, unless you're prepared to spend truly stupid amounts of money, or you happen to live in the US, where the trucking industry feeds the 24V market. Many people have tried to convince me I should go for 24V, but I'm sticking with 12V and believe I have good reason to. The only on board device that might challenge this would be a bow thruster, or maybe an electric windlass, but if at some point I would like to fit either there are ways around the cabling problem.

The main ("house") battery bank consists of flooded lead acid cells, around 1kAh capacity. Yes, I am aware of the appealing benefits of other chemistries, and variations on lead acid such as AGM and gel cells, but I've done my research, I've weighed them up(!) against each other, and flooded lead acid is the winner. For me. I have not yet decided on the exact configuration, and whether it will be made up by 12, 6 or 2 Volt units, but for height reasons I'm currently leaning towards four 230Ah 12V beasts in parallel, as these have the lowest height I've been able to find. The diesel engine starter motor will have its own, smaller, 12V battery, which will also be of the flooded type.

There will be at least three energy sources from which this bank is charged:

• The engine alternator
• A shore power battery charger (connected via isolation transformer)
• Two 300W solar panels, with independent MPPT charge controllers
• Possibly, a 300-500W wind turbine of the type commonly used on yachts

There will also be an inverter on board - this is actually part of the shore powered battery charger, a Mastervolt Mass Combi, which combines a 100A multi-stage battery charger and a 2200W 240V inverter in the same package. This has an RS485 port which will be connected to the "resources" computer (see below), for monitoring charge status of the house bank, shore power availability, and inverter power usage. The shore power feed goes via a 3600VA Victron isolation transformer, to prevent galvanic corrosion. Shore power, when available, apart from running the battery charger, will be used to run a 1kW immersion heater in the hot water supply boiler (which can also be heated from the engine, a Webasto diesel heater, and a back-boiler equipped wood burning stove), a dehumidifier and other power hungry 240V devices. I also need 240V, from shore or inverter, to run certain machinery, such as power tools and my OmioCNC router, though on the whole I consider 240V a necessary evil, and the inverter will only be switched on when its needed (speaking of quiescent currents - the inverter draws 750mA no-load).

I'm not going to go into detail about how the 12V system is divided up, not only because it's not very interesting, but also because I haven't finalised those plans yet. What I do know is that all power goes through a main distribution panel, from which each circuit is connected via a thermal circuit breaker, not dissimilar to a house electrical system. There will be load monitoring, but I haven't decided how granular I want this to be (another 1-Wire project is a current monitor). More interesting are my plans for the control and monitoring system, which will consist of three computers:

1. Security
This is the only system that is guaranteed to be "always on". It is mounted in the forward cabin, well away from any potential fires and near the ceiling, and has its own 22Ah SLA battery backup, courtesy a very nifty little OpenUPS charge controller, which allows it to monitor house bank voltage and backup-battery state, and adapt based on available power. This system maintains a 3G/4G connection through a Sierra Wireless Raven RV50 vehicular router/modem with GPS, and not that much else. Its main task is to provide a way "in" for me while I am not aboard, and to send me alerts via email and SMS should certain events be triggered. The security system controls the power for the other two on board computers, and can boot them up/shut them down as required. In terms of sensors, it is equipped with a minimum of security related inputs:

• Bilge water level sensors
• Fire/smoke detectors
• CO2/gas detectors
• Vibration sensors
• IR movement/intrusion detectors
• Weather instruments

To minimise power usage, and simplify installation, most of these sensors will be using the 1-Wire bus. The exception being the movement/intrusion sensors, since these may need to be responded to immediately. For such time critical sensors I will will use individual I/O pins on the Raspberry Pi.

It will also have 2 to 4 cameras connected via an IVMech IVPort camera multiplexer. These will be unpowered until requested by sensor input, still image capture schedule, or a remote request for images. In the same power domain sits a Netgear GS105 five port Ethernet switch, to which the other computers are connected. Real-world testing indicates a 15-20h runtime on the 22Ah backup battery, when fully charged. 

2. Resources
This control system is embedded in the main power distribution panel, and deals with controlling and monitoring power consumers, such as lights, heating and ventilation, as well as monitoring fuel, fresh water and waste water tank levels. As long as the house bank holds a sufficient level of charge, this system will be operational, allowing remote monitoring of on-board resources as well as scheduled and telemetry triggered lighting and HVAC control. Much wider in scope than the "security" system, this computer is connected to the Mastervolt charger/inverter and the Morningstar MPPT solar charge controllers over RS485, 1-Wire tank level sensors, a multitude of temperature sensors (also 1-Wire), dozens of light and ventilation controllers of the type discussed in this thread as well as individual current sensors on the different 12V circuits. Pretty much anything that can be switched on/off by a button while on board can be automated and remote controlled by this system. I am very tempted indeed to invest in a Monarco Hat for it, but we'll see.

3. Navigation
The lowest priority system from a power perspective, this system is normally off unless navigating, but can be woken up by "security" should the need arise (for example if while away, I would like to monitor traffic in the area, or listen in to local VHF transmissions). Its responsibilities include anything to do with moving the boat around, including positioning, engine status, and radio communications. It is equipped with its own GPS/Gallileo/GLONASS receiver (NaviLock NL-8022MU), a dAISy AIS reciever and an SDR device, yet to be decide upon. It is also connected to various engine telemetry sensors, such as engine and gearbox temperature sensors, oil pressure and RPM, as well as heading, list and trim sensors (a combined fluxgate compass/accelerometer/IMU type thingy). This telemetry data is combined in OpenCPN, and displayed on a 12" touchscreen LCD in the wheelhouse. Possibly this system will at some point include some kind of autopilot functionality, though I don't know if I could ever trust my Python Fu that far.

All three computers, in addition to their specific task related software, run an instance of Domoticz, with "navigation" and "resources" sharing their devices with "security" (which can be regarded as the "master" system). In turn, "security" pushes all data to a cloud node over an SSH tunnel (the closest thing to a static IP on a mobile network unless you're a millionaire), so that this remains available even in a disaster scenario.

There you have it, a basic outline of my crazy plan. Of course I do not intend to build this all as one monolithic project - some of it may never even happen - the plan goes in stages, and I've tried to make the benefits of each stage independent of future plans; I'm a big fan of "loosely coupled" designs, in software as well as hardware. And things are already well under way; I already have working versions of the "security" and "navigation" systems, both of them Raspberry Pi 2s, and much of the core equipment has been purchased - in fact I am looking at its boxes crowding my livingroom while I type this. It's strange but once you own a boat it kind of... takes over your life. In good and bad ways. Hard to explain, like a love affair. At least now you know why I will be pestering this forum with an endless stream of boat related electronics questions going forward I hope you'll all bare with me.

[ovnr]

Bonus points if you name it Boaty McBoatface, or whatever it was.

12V/24V: +1 for 24V, obviously, but it's not terribly important. Beyond that, my relationship with boats is best described as "I'd rather not, thank you very much".

On RS485 power consumption: I didn't have time for an exhaustive search, but the MAX3471 transciever is meant for battery-powered systems, and takes only 1.6 µA in receive mode. It's a bit pricey at $2.55 (25+), and I expect there are a number of other low-power solutions.

It's also fail-safe, which means you can leave the bus unpowered (so no loss in the termination resistors).

Cheaper options - the ST485CDR takes 300 µA, looks like it's fail-safe, and costs $0.75. Again, there's probably a middle ground, but even if each node eats 500µA and you have 100 nodes, it's 50 mA total - your 1kAh bank will last for years on that; it's probably less than the self-discharge. And if you intend to live on it year-round (as opposed to leaving it in a dock for months on end), it matters very little.

[Lomax]

Bonus points if you name it Boaty McBoatface, or whatever it was.

At one point I was considering naming her "Brexit", or "Brexodus", but that would be too much fun. I'll look into the transceivers you mentioned, but presumably these would need an MCU as well - otherwise "where" do I run my dimmer code?

[Lomax]

I should point out as well, that I would never have gotten this far if it wasn't for the help @Ian.M provided in an earlier thread - any credits for the quality of my design really should go to him. Thanks Ian!

[Lomax]

Yes. There are many marine industry instrumentation and control buses already using CAN, including NMEA-2000.

But then NMEA-2000 has only been partially reverse engineered, and remains a proprietary protocol with many secrets, to a much greater extent than 1-Wire. If I was to make use of any NMEA protocol it would be the 0183 variety, for which public libraries are available. No need to reinvent the wheel here. It's not rocket science.

[ovnr]

Bonus points if you name it Boaty McBoatface, or whatever it was.

At one point I was considering naming her "Brexit", or "Brexodus", but that would be too much fun. I'll look into the transceivers you mentioned, but presumably these would need an MCU as well - otherwise "where" do I run my dimmer code?

Yep, you'll need a micro. Anything with an UART will work, and even *that* isn't essential.

I'm partial to PICs myself.

[Lomax]

Yep, you'll need a micro. Anything with an UART will work, and even *that* isn't essential..

Right, so where's your power consumption now? And how do you program the MCU? What if you want to change the PWM ramp speed, or change its behaviour?

I'm partial to PICs myself.

Ouch. A Norwegian PIC lover. Have to say I'm more of an Atmel guy myself.

[Lomax]

Let me just make one thing clear here: I am interested in a lot of things, but writing my own boot loader is not one of them. Respect to those who get a kick out that shit, but Assembler aint my game. Not even C can get me particularly excited, seems more like a chore I have to deal with sometimes. Gimme a full Linux stack with a good package manager and a Ruby or Python interpreter and I'm happy.

[Ian.M]

So, if I understand you correctly, you don't really want to get heavily into MCU development, hence your desire to use off-the-shelf chips targeting home automation - which, together with your desire to use Dometix, is what's driving you towards 1Wire.

I do think that you will need some sort of backbone bus with nodes that  handle 1wire spur buses so you can keep each one localised.  Maybe the way forward is to use an Ethernet backbone with something like http://linuxgizmos.com/worlds-smallest-quad-core-sbc-starts-at-8-dollars/ as local control nodes talking 1Wire or other protocols to slave nodes in the same cabin.   

[BrianHG]

For RS-485, bidirectional without a transceiver IC, I used to use a PIC's comparator input as a true differential receiver, then switch those same 2 comparator input pins to output generating a true differential transmitter.  Modern PIC's have over a +/- 25ma drive per pin, max +/-50ma.  Though, with this solution, you must use a software UART.  With this, I had a 10 story apartment building with 3 node on each floor with temperature & lights monitoring, light's power on/off + display & input button control without any additional ICs for a building wide monitoring system.  Worked free of any errors at 9600 baud with simple unshielded solid copper core phone cables.  2 conductors for +12v power & 2 for bi-directional differential 5v RS-485 data.

The nice thing about this solution is that every addressed unit was just a PIC + some resistor & caps & protection diodes + 78L05 regulator with the module's id stored in the PIC's flash.  No other ICs.

[janoc]

Right, so where's your power consumption now? And how do you program the MCU? What if you want to change the PWM ramp speed, or change its behaviour?

Power consumption depends on what the micro is doing. That can be anywhere from a tens of nanoamps when sleeping up to tens of miliamps when actively doing something.

Things like PWM ramps or whatever you program yourself. Standardize on a largeish micro so that you can work with it comfortably without pinching Flash bytes and having to change part numbers all the time. Then making a small interpreter with a few commands coming down the bus in something like C is pretty simple. If you don't like C, there are other languages available too. You certainly don't need to go to assembler unless you really really want to.

If you rather want Linux and "full stack", then go with ethernet as a backbone as suggested by others - however, then you are likely not concerned with power consumption anymore as the Linux-capable boards are power hogs.

[ovnr]

Right, so where's your power consumption now? And how do you program the MCU? What if you want to change the PWM ramp speed, or change its behaviour?

Power consumption? Well, given that your micro can sit in sleep mode until there's activity on the bus, taking a few µA... it's not really a big deal?
Use a linear reg like the RT9058 ($.55 @ 25+, also rated for 40V) at 3.5µA quiescent, 1.6µA for the transciever, 1-10 µA for the MCU... it's not going to take much. Even if you *had* to run the micro all the time, something like the PIC12F1840 will take 210 µA when running at 500 kHz (which is plenty for "listen to the bus and see if it changes state" - I'd just use an interrupt to wake it, tho).

Programming? Build your software so it reads ramp speeds/other parameters from RAM. These days I just put all "interesting" variables in a single block of RAM, and just have read/write memory commands. Say you have 16 bytes of config memory; just send a Set Pointer command with 0 as the argument, send a Write command, then dump 16 bytes of config into it. If you put the desired PWM value into the first couple bytes, you can get by with only sending those.

As for bootloaders, I write mine in C, with a miniscule sprinkling of assembler - something like 5% of the total code. I've never been very fussed about getting them down into some tiny corner - larger chips are cheap.

[Lomax]

So, if I understand you correctly, you don't really want to get heavily into MCU development, hence your desire to use off-the-shelf chips targeting home automation - which, together with your desire to use Dometix, is what's driving you towards 1Wire.

That is a very accurate summary, thank you.

I do think that you will need some sort of backbone bus with nodes that  handle 1wire spur buses so you can keep each one localised.  Maybe the way forward is to use an Ethernet backbone with something like http://linuxgizmos.com/worlds-smallest-quad-core-sbc-starts-at-8-dollars/ as local control nodes talking 1Wire or other protocols to slave nodes in the same cabin.

Kind of. If you read my lengthy post outlining the on-board systems, you'll see that the work is split over three computers, each with their own set of 1-Wire buses, and talking to each other over Ethernet.

Some links for those interested in 1-Wire and the Pi:
http://www.sheepwalkelectronics.co.uk/index.php?cPath=22
https://www.abelectronics.co.uk/p/76/1-Wire-Pi-Zero
http://www.hw-group.com/products/sensors/index_en.html
https://www.monarco.io

[Ian.M]

Yes, I read you already have three computers.  However I don't think you are splitting the 1Wire buses up enough.  Running long 1Wire buses with many nodes is asking for trouble and also makes it very difficult to 'future-proof' the system^*.
If you go with an Ethernet bridge to 1Wire master node per cabin (Linux as you want to avoid deep embedded stuff), the cable runs will be short enough to use screened cabling without excessive capacitance on the 1Wire bus, and if the master node is located appropriately to minimise the run lengths, it will also mitigate the voltage drop concerns.  The Ethernet magnetics provide a considerable amount of protection against common mode induced transients, and with a steel hull and superstructure providing screening it should survive anything short of a direct lightning strike on the superstructure.

* Cat5+ Ethernet is here for the long haul - you'll still be able to get similar parts in 25 years time.  You can bet that Brain4Home *wont* be producing the BAE910 in 25 years time, and even the PIC they use for it may no longer be in production.  If you break it up into smaller buses, when spares availability becomes an issue, you can convert one cabin at a time to whatever new system you like, reconditioning pulled units as spares for other cabins you don't want to convert yet.

[Lomax]

Yes, I read you already have three computers.  However I don't think you are splitting the 1Wire buses up enough.  Running long 1Wire buses with many nodes is asking for trouble and also makes it very difficult to 'future-proof' the system^*.

What I didn't explain is that each of these computers will have multiple independent 1-Wire buses. For example, the SheepWalk RPI3 interface provides no less than eight 1-Wire channels. But I have just been skimming through Springbok Digitronics' design guide for the layman: understanding, designing and building MicroLanTM (1-Wire) networks and it made me feel so very very tired. Perhaps this whole thing is beyond me.

[Lomax]

* Cat5+ Ethernet is here for the long haul - you'll still be able to get similar parts in 25 years time.  You can bet that Brain4Home *wont* be producing the BAE910 in 25 years time, and even the PIC they use for it may no longer be in production.  If you break it up into smaller buses, when spares availability becomes an issue, you can convert one cabin at a time to whatever new system you like, reconditioning pulled units as spares for other cabins you don't want to convert yet.

Those are all good and valid points, but Ethernet was dismissed at a very early stage due to its high power consumption, large footprint and thick cabling.

[ovnr]

Those are all good and valid points, but Ethernet was dismissed at a very early stage due to its high power consumption, large footprint and thick cabling.

I think the point of the Ethernet was to run long spans using that, then branch each out. So you'd have, say, one Ethernet cable going to the engine compartment, which branches out to whatever goes on in there.

[Lomax]

I think the point of the Ethernet was to run long spans using that, then branch each out. So you'd have, say, one Ethernet cable going to the engine compartment, which branches out to whatever goes on in there.

Ok, and that's exactly how it's laid out, although the "navigation" and "resources" computers share the task of monitoring what goes on in the engine room, which has a very high concentration of sensors.

[Ian.M]

Thick cabling?   You can get CAT5 STP patch cable (so foil screened with stranded conductors as thin as 6.2mm dia.  e.g. http://www.minitran.co.uk/pdf/F-UTP%20LSOH%20Cat5e%20Patch%20Cable%20Data%20Sheet1.pdf
Anything much under that is getting too flimzy for permanent installation on a boat.

However the star topology of a twisted pair Ethernet network may be the issue as finding space for a seven cable bundle is far more problematic than for a single cable.

For the power consumption issues, well that comes with the territory if you want to use Linux master nodes. 

The only way around these issues is to go to something like CAN bus or RS485 that can be daisy-chained for the backbone, and use low-power capable embedded MCUs (with all the toolchain and C pain that brings) for the bridge nodes.  If you don't want to do that from the outset, at least future-proof your installation by running an unused ring of CAT6 cable right round the boat with enough slack to cut and terminate it at each junction box where a 1Wire spur connects to your 1Wire backbone.   

Unfortunately Maxim discontinued the DS2409 MicroLAN Coupler several years ago, which was essential to make reliable larger backbone and spur 1Wire networks.  You *MAY* be able to source a lifetime supply NOS, or find an equivalent, as I certainly wouldn't consider building a large branching 1Wire network without them. In AN148, Maxim advise 120R damping resistors between each spur and the backbone but caution that this degrades noise immunity by 80% and doesn't work with many of their masters! 

[Lomax]

However the star topology of a twisted pair Ethernet network may be the issue as finding space for a seven cable bundle is far more problematic than for a single cable.

That's what I meant.

For the power consumption issues, well that comes with the territory if you want to use Linux master nodes.

That's why the "navigation" master is normally offline, and the "resources" master only online when house bank holds sufficient charge. After all, what would be the point of keeping a system whose task it is to control lighting and ventilation online unless there is sufficient power available to actually turn those things on Similarly, there's no need to enable the "navigation" master unless you're intending to move the boat - in which case the engine alternator will provide all the power I need. Ethernet power usage depends both on the number of connected devices and the length of the cabling - while the GS105 switch needs to be powered at all times, since it also links the "security" master node to the mobile network router, it is clever enough to lower its power usage accordingly. The whole security node has been tested and power consumption was found to be surprisingly low, totalling just 3.82 W while idling and maxing out at 5.72 W. This does not include the cameras (which will normally be powered off) or the power usage of the 1-Wire bus or any of the security sensors - only the bits that go inside the enclosure (Raspi 2, 5-port switch, 3G/4G router, OpenUPS BMS, a 6x6cm axial fan and a 12>5V DC/DC converter). But I am happy with this.

The only way around these issues is to go to something like CAN bus or RS485 that can be daisy-chained for the backbone, and use low-power capable embedded MCUs (with all the toolchain and C pain that brings) for the bridge nodes.

Exactly. Or 1-Wire. Going with the BAE0910 will save me the work of writing the low-level node software and allow me to concentrate on higher level functionality. This is what I'm paying the €10 for.

At least future-proof your installation by running an unused ring of CAT6 cable right round the boat with enough slack to cut and terminate it at each junction box where a 1Wire spur connects to your 1Wire backbone.

Good point! I'm going one better though, in that most of the internal wiring will run in conduits, allowing me to add or remove members as needed. Up to a limit of course.

Unfortunately Maxim discontinued the DS2409 MicroLAN Coupler several years ago, which was essential to make reliable larger backbone and spur 1Wire networks.  You *MAY* be able to source a lifetime supply NOS, or find an equivalent, as I certainly wouldn't consider building a large branching 1Wire network without them.

Yes, that's very unfortunate. Again, I think Dallas could have done a better job of promoting and supporting 1-Wire than they have. Too late now! But it doesn't really matter to me, since the "star" topology would be provided by the master nodes themselves. If I use the SheepWalk RPI3 interface already mentioned, each node can have up to eight trunks, with dozens of slaves hanging off each one. I do not see a problem here.

In AN148, Maxim advise 120R damping resistors between each spur and the backbone but caution that this degrades noise immunity by 80% and doesn't work with many of their masters! 

Actually I already added this resistor, remember? But having skimmed the Springbok guide linked to earlier, I've decided to swap this to a ferrite bead instead, which will do a better job of keeping noise out, while also limiting reflections.

[Lomax]

Here's a thought: if one of the RS485 advocates in this thread would be prepared to write the MCU software I need, capable of running on a low power/small footprint Atmel MCU, and provide an updated schematic based on an RS485 transceiver, then I would have a spare €200 to hand over. Any takers?

[Ian.M]

The problem is the safe length of the spurs off each trunk.  You end up with basically a thicket of coppiced willow shoots (i.e. multiple daisy-chains from the same root node with only short stub spurs, if any) rather than a trunk and branches which brings you right back to the cable volume problem, albeit eased by the fact that you can run four 1Wire trunks down one CAT 5 cable.    That still means a Pi Zero per zone (cheapest/smallest/lowest power option to run a Sheepwalk RPI3), assuming you are going to run a USB or RS-485 backbone (Check: does the RPI3 leave the Pi UART pins available?) or a Pi B if you want to use an Ethernet backbone.

What you need is some sort of affordable addressable micropower remote 1Wire interface . . . .

Unfortunately £200 doesn't buy you much pro-grade MCU development.  A large chunk of that would get chewed through for development hardware, as you don't want code from anyone who hasn't built and tested a prototype.

[Lomax]

The problem is the safe length of the spurs off each trunk.  You end up with basically a thicket of coppiced willow shoots (i.e. multiple daisy-chains from the same root node with only short stub spurs, if any) rather than a trunk and branches which brings you right back to the cable volume problem, albeit eased by the fact that you can run four 1Wire trunks down one CAT 5 cable. That still means a Pi Zero per zone (cheapest/smallest/lowest power option to run a Sheepwalk RPI3), assuming you are going to run a USB or RS-485 backbone (Check: does the RPI3 leave the Pi UART pins available?) or a Pi B if you want to use an Ethernet backbone.

Pi 2s all around actually, but yes, as I have stated repeatedly this is exactly how the system has been designed, for the reasons you mention, and others. You don't think three master nodes is enough, but I suspect you think my boat is rather larger than it is. Apart from a few reading lights, and two USB power outlets, there is nothing happening amidships. Most of the action is concentrated in and around the engine room, with a few things happening up front, most notably the 3G/4G router. The only 1-Wire trunk going the whole length of the cabin (about ten metres) is the one for the engine room bilge level sensor and fire detector.

What you need is some sort of affordable addressable micropower remote 1Wire interface . . . .

You're kidding, right?

Unfortunately £200 doesn't buy you much pro-grade MCU development.  A large chunk of that would get chewed through for development hardware, as you don't want code from anyone who hasn't built and tested a prototype.

Yeah, well, my suggestion was rather tongue in cheek. Intended more to highlight the issue I'm facing wrt to the workload of redesigning everything from first principle, including writing my own custom firmware and designing my own communications protocol. It may be what others would have done, but it's just not a realistic proposition for me.

A single MicroLAN bus can be up to 300 m long and contain literally hundreds of electronic labels.
- Dan Awtrey, Dallas Semiconductor

[Ian.M]

A single MicroLAN bus can be up to 300 m long and contain literally hundreds of electronic labels.
- Dan Awtrey, Dallas Semiconductor

Yes, subject to a whole shed load of constraints.

Perhaps if you post a rough dimensioned layout of your barge, we'd have a better idea what to recommend.

I got the impression it was a fairly substantial vessel, probably a European barge design, from what you had mentioned about it including that you were fitting out in the UK for Europe (as UK canal barges, especially narrow-beam ones aren't really suitable for coastal passages and major European rivers unless heavily modified and grossly overpowered, and several of the UK BSS regulations are incompatible with good seaworthyness).

[Lomax]

Will this do?

Edit: Dimensions are 45' LOA, 10' beam, 2' draft, 8'6" air-draft, 12t displacement.

Edit: Engine is a six cylinder, 5.8 litre Perkins 6.354, developing around 120bhp.



Savvy?

[ovnr]

Here's a thought: if one of the RS485 advocates in this thread would be prepared to write the MCU software I need, capable of running on a low power/small footprint Atmel MCU, and provide an updated schematic based on an RS485 transceiver, then I would have a spare €200 to hand over. Any takers?

Kinda. I'd do it if you were fine with PICs? I mean, Atmel is now Microchip, so... 
(Incidentally, I PM'd you some terrible code I wrote earlier today. I do better when it's not a one-off.)

Also, budget per node? "Less is better", sure, but I expect you'd want reliability to be a priority.


Make it £200 and I'll throw in a PCB design too.

[Lomax]

Kinda. I'd do it if you were fine with PICs? I mean, Atmel is now Microchip, so... 

I don't really care tbh, but a couple years ago I invested in the Atmel toolchain, both in terms of hardware and learning how to code for it. I have never used a PIC MCU, or the "Arduino" style Atmels.

(Incidentally, I PM'd you some terrible code I wrote earlier today. I do better when it's not a one-off.)

Thank you, yes I looked at that. Interesting!

Also, budget per node? "Less is better", sure, but I expect you'd want reliability to be a priority.

£15 is a good target, though if another £5 would offer significant benefits I may be swayed to spend £20.

Make it £200 and I'll throw in a PCB design too.

Thank you, that's a very kind offer. TBH I'm too tired of the whole thing right now to know what to do. I didn't come here to ask which would be the appropriate interface to use - I thought I had already spent a great deal of time researching this - but to get feedback specifically on my circuit design. The sheer weight of all the posts saying RS485 have made me confused, and I no longer feel sure of anything. I know I can get a 1-Wire network to function with the hardware and software platforms I have chosen - for example, I already have the weather station working and feeding data to Domoticz. It's typical of the Internet I guess, that people always answer the question they would have liked to see asked - why else reply - but it is wearisome to spend so much time arguing.

[Lomax]

As you can see below, I do have one or two other things to worry about apart from how I'm going to turn the lights on and off...

[BrianHG]

For a boat that size, with outdoor hardened connections, I would use coax outdoor grade CATV wire with screw connectors. You will get a good 10 or 100 megabit network if you want to use off the shelf Ethernet, (good for existing security video cameras which already support this, power on coax with Ethernet .h265 video....) or similar, and you can feed a good amount of electrical power down it as well with that solid core and little worries about interference since it's coax.  Yes, single core coax Ethernet still exists.

However, now, each MCU needs a network interface port with TCPIP stack, though, today, this is still under 4$ mcu, but, you will need a coax Ethernet cable driver with it's isolation transformer on you PCB.

[Ian.M]

I just took another look at the BAE0910  - I don't know why I was thinking its based on a Microchip MCU as the pinout is wring for both PICs and AVRs.   

I think before you firmly commit to 1Wire you should make some prototypes and do some torture testing - one 1Wire bus as long as the longest one you'll need with some BAE0910 based boards and a sprinkling of 1Wire sensors.  Design the boards with the expectation that you will install them for the actual application if successful, lay out and connect the bus on the ground, then see what happens if you try various high current pulsed loads with their wiring laid beside the bus.  If you can enlist the help of a radio ham with a 2m band transceiver to torture test it legally with something very similar to a marine band VHF transmission so much the better.  You may find you need to make some changes to you plans e.g. relocate a master or add another one to shorten the cable run, or you may find you need screened cable and can tolerate the extra capacitance if you keep the cables as short as you reasonably can.

[Lomax]

I just took another look at the BAE0910  - I don't know why I was thinking its based on a Microchip MCU as the pinout is wring for both PICs and AVRs.

Yeah, I don't know which MCU he's using, but it doesn't matter much since it's really the firmware I'm after. The ability to easily (re-)program a given node via OWFS at any time is pretty neat, and the "Automation Engine" interpreter looks fairly capable.

I think before you firmly commit to 1Wire you should make some prototypes and do some torture testing - one 1Wire bus as long as the longest one you'll need with some BAE0910 based boards and a sprinkling of 1Wire sensors.

Yes. From the original post that started this whole discussion:

Although I'm pretty inexperienced in circuit design, I've beaten my way through the jungle and have now reached a point where I think it's time to build a first prototype

Design the boards with the expectation that you will install them for the actual application if successful, lay out and connect the bus on the ground, then see what happens if you try various high current pulsed loads with their wiring laid beside the bus.

Why would I do that though - it's not something I would expect to happen in real life? There should be no trouble keeping the 1-Wire buses well away from "high current pulsed loads". I certainly wouldn't put it in the same trunking...

[Ian.M]

Its going down the same cable as the supply to PWMed dimmers + there are going to be high current DC circuits nearby you cant fully test until they are installed and the boat is win afloat + you were concerned about the effects of lightning induced surges^* so torture testing its EMC is worth doing.  e.g. if you can crash it by running the cable to a 750W angle grinder 10cm away then making a heavy cut, you'll know that you'll need meters of clearance from any bow thruster wiring!   Also, see how near you can put a mobile phone to each board and ring the number without unexpected effects.

* It is possible to optoisolate a 1-wire bus ONCE (i.e. two would introduce too much delay).  I would strongly recommend isolating the 1Wire bus that goes up the mast immediately under the deck.   It wont do any bloody good if you get a direct strike, but if the boat in the next berth over gets struck, it may save your bacon NOT to have a nice vertical aerial coupling the induced transient directly into your control computer's 1Wire interface.

[Lomax]

Its going down the same cable as the supply to PWMed dimmers + there are going to be high current DC circuits nearby you cant fully test until they are installed and the boat is win afloat + you were concerned about the effects of lightning induced surges^* so torture testing its EMC is worth doing.  e.g. if you can crash it by running the cable to a 750W angle grinder 10cm away then making a heavy cut, you'll know that you'll need meters of clearance from any bow thruster wiring!   Also, see how near you can put a mobile phone to each board and ring the number without unexpected effects.

Very well, I will do some stress testing, I guess that was part of the plan all along. Thanks for concrete suggestions on practical tests. Not to be pedantic, but because I have settled on a 12V nominal system, any heavy consumers such as an electric windlass or a bow thruster would need to have its own local battery. Ultimately, the only test that can really settle if a 1-Wire system will work on my boat is to install it and use it. Should I find that I cannot get it to work then that's not critical; the system has been designed to function even if the 1-Wire network - and indeed any of the master nodes themselves - is offline. We all know what computers are like...

* It is possible to optoisolate a 1-wire bus ONCE (i.e. two would introduce too much delay).  I would strongly recommend isolating the 1Wire bus that goes up the mast immediately under the deck.   It wont do any bloody good if you get a direct strike, but if the boat in the next berth over gets struck, it may save your bacon NOT to have a nice vertical aerial coupling the induced transient directly into your control computer's 1Wire interface.

Now this is a very interesting topic! I haven't gotten very far on planning how to isolate outside connections - and there will be many - but I do know that lightning protection is high on the list. I looked at the surge protection products made by L-Com a while back, but haven't bought anything yet. I've also looked a bit at how radio hams protect their rigs. Perhaps this discussion is better suited for a separate (and later) thread though.

[ovnr]

Quick RS485 design:

(Yes, I neglected to add your button inputs. I think we can agree that they're quite trivial, however. Also didn't put any effort into making it pretty.)

BOM cost around £6 (w/o VAT, 25 units), add around $1 for the PCB. I have no idea what kind of connectors you want, but there's plenty of budget left for it.


I chose an intelligent switch for the output; it provides short-circuit protection, overvoltage clamping, current sensing, etc. It will, however, limit the PWM frequency a bit.


Edit: Also, easy to just add a 1-wire port to it so you can use it as a simple/cheap RS485 to 1-wire bridge for sensors/whatever.

[Lomax]

Quick RS485 design:

Thank you!

I chose an intelligent switch for the output; it provides short-circuit protection, overvoltage clamping, current sensing, etc. It will, however, limit the PWM frequency a bit.

That's a nifty little chip! An earlier version of my design had a MAX9938F current sensor feeding the ADC on the BAE0910 for power monitoring - nice to see that built in. Couldn't find any info in the datasheet re. max switching frequency?

[ovnr]

That's a nifty little chip! An earlier version of my design had a MAX9938F current sensor feeding the ADC on the BAE0910 for power monitoring - nice to see that built in. Couldn't find any info in the datasheet re. max switching frequency?

Current sense: It's likely not very accurate. As for frequency, look for Ton/Toff. If it takes 100 µs to rise/fall, I'd suggest keeping the PWM frequency below 1 kHz. I'd probably go for 250 Hz.

Incidentally, since I personally utterly hate "low" frequency flicker like that, I'd find a different chip. ISTR the OmniFET IIs are pretty fast, but don't offer current sensing. They're also low-side switches; high-side is better, in case something gets shorted to ground.

[Lomax]

Current sense: It's likely not very accurate.

Yeah, I only planned to use it to monitor for abnormal conditions, dead LEDs, stalled motors, shorts... Actual power consumption will be measured higher up the chain, with better precision. Anyway, I dropped that requirement to simplify things - though the surplus pins on whatever MCU I end up using will be tempting to use for something.

As for frequency, look for Ton/Toff. If it takes 100 µs to rise/fall, I'd suggest keeping the PWM frequency below 1 kHz. I'd probably go for 250 Hz. Incidentally, since I personally utterly hate "low" frequency flicker like that, I'd find a different chip. ISTR the OmniFET IIs are pretty fast, but don't offer current sensing. They're also low-side switches; high-side is better, in case something gets shorted to ground.

250Hz is way, way too low. I've been doing some testing with three different in-ceiling LED modules here and got good results with 1-10kHz. Not only is the flicker at low PWM speeds annoying, it can be downright dangerous when you're dealing with any kind of revolving machinery. Good point about the benefits of high-side switching btw.

[Lomax]

Quick RS485 design:

I'm curious about a few things in this schematic:

• You've opted to use a linear regulator for the 5V - how come? Considering these nodes are "always on" (provided there's enough power available) the losses multiplied for every node would be significant.
• The data lines and output are not isolated in any way, though I see you have bidirectional TVS diodes on the data input. Is this not advisable to do?
• You have included an in-circuit programming header, which I think will be of little use, considering that many (most?) nodes will be mounted in difficult to access locations. Some other means of programming the nodes is required.
• The output does not have a diode to deal with back EMF - maybe this is not needed with the ProFET Smart Switches?

Please don't take this as a request for changes - they're only questions. I don't want you to be spending time on a circuit design which may well not be used for anything.

[Ian.M]

You need an ICSP header or at least a footprint for one that can be accessed with pogo pins on nearly anything involving a Microchip PIC as they don't come factory preprogrammed with a bootloader.  It also provides debug access for chips that have built-in debug silicon.   Once you've programmed it with a suitable bootloader, further updates can be done remotely over the wire, though you do need some robust method of resetting the PIC to reenter the bootloader, even if the running firmware has crashed badly, which is why I suggested a long time constant RC network from the RX data line after the transceiver to trigger a PSU supervisor (micropower comparator with internal reference) to pull down /MCLR (reset) if a *VERY* long break is sent e.g. over ten seconds.

[ovnr]

* Linear reg: This reg uses 2 µA quiescent current. The rest of the circuitry is going to use less than 50 µA quiescent; when it's actually running, I'd ballpark it around 5 mA - which your LED lighting will swamp. A switcher will use more quiescent current, cost more, and be more fragile.
* RS485 is quite resilient to noise, which is why people tell you to use it.
* ICSP header is for production programming - it gets plugged in once. It's just an unpopulated header on the board, there's no need to solder on an actual header. Reprogramming is handled via a bootloader.
* No output diode required with the fancy switches. They clamp the voltage to a safe level.


On switching devices, here are your main options:

* Fast, cheap, but low-side and no sense: OmniFET IIs, f. ex. VND7NV04 (6A, 50 kHz): £1.26
* Medium speed, high-side w/o sense: AUIPS6021 (32A, 1.5 kHz): £1.52
* Medium speed, high-side with sense: TPS1H100 (custom limit to 4 A, 2 kHz): £1.77
* Or a custom discrete solution. Probably £5+, but will do 10 kHz PWM, high-side switching with a custom current limit.

The TPS part seems to fit the bill fairly well.

[Ian.M]

Nice.  Between the PIC's ECCP PWM auto-shutdown mode and the TPS1H100's current sense output, you can do automatic cycle by cycle current limiting without using any instruction cycles, which means its trivial to make it sufficiently bomb-proof to survive a hard short to ground or trying to drive a grossly oversized brushed DC motor.   There's plenty of spare pins left, as the ICSP pins can be shared with buttons with a simple isolation resistor between the ICSP pin and the filter circuit for the button, so a robust 1Wire bus interface with separate input and output pins would be easy to add.

[ovnr]

Nice.  Between the PIC's ECCP PWM auto-shutdown mode and the TPS1H100's current sense output, you can do automatic cycle by cycle current limiting without using any instruction cycles, which means its trivial to make it sufficiently bomb-proof to survive a hard short to ground or trying to drive a grossly oversized brushed DC motor.

On overcurrent detection: I did a discrete design a while ago, which had a simple current sense amp going into the PIC's comparator (other comparator inpt was supposed to go to the 5-bit DAC, but due to ~issues~ I screwed that bit up). It fired an interrupt which disabled the PWM output; still cleared shorts within 50-120 µs, including the somewhat lackluster rise time of the current sense amp I was using. I did a number of shorting tests on it, without anywhere close to an issue, even with a fairly large capacitance being shorted into the output FET.

Honestly, these days it's just bad design to make an user-accessible output that doesn't survive a short or two.

[Lomax]

re-think the protocol

There seems to be some movement WRT getting Modbus support in Domoticz. Could be a long time before its usable though.

Edit: From another thread on the Domoticz forum:

Ideally, though, I'd like to add native hardware support for modbus (which is a serial communication protocol) directly in domoticz, perhaps using the 1wire code (another serial protocol) as a template. Then it would be possible to add sensors within domoticz directly. But I need some sort of pointer to where the actual devices are specified, and crucially, how complicated devices like this need to be handled.

Oh, the irony.

Edit: The TPS1H100 looks great btw.

[Lomax]

<jk>
Thank to everyone who's contributed - I have updated my schematic based on the feedback:

• Don't use the 1-Wire interface
• Don't use the 1-Wire protocol
• Don't use the BAE0910 MCU
• Don't use the BAE0910 firmware
• Don't use a discrete MOSFET switch
• Don't use a PTC fuse
• Don't use a buck converter
• Don't isolate the logical GND
• Don't isolate the output
• Don't filter the data lines

Accordingly, it now looks like this:



</jk>

[Lomax]

<jk>
But the really exciting thing is that I can now upgrade the user interface for my home automation system from this:



To this:



</jk>

[ovnr]

• Don't use a PTC fuse

Hey, I suggested you use a PTC. Your original design didn't. Get it right, man.

/s

[Lomax]

Hey, I suggested you use a PTC. Your original design didn't. Get it right, man.

Yeah, you're right. Apologies. And you did provide an alternative circuit. And much other useful information. I'm just feeling a little dejected since I thought I was basically done with the system design - which I have spent a considerable amount of time on - only to find I'm not going to be able to use any of my chosen solutions, and have to start over from square one. Unless of course, I choose to ignore the advice given in this thread and go ahead with my original plan regardless, but it's difficult to feel enthusiastic for something which has been so thoroughly panned. So what now? I really don't know. 

[max_torque]

A few comments from me:


1) Its your project, feel free to do it how you see fit (and that does include ignoring suggestions on here)

2) Even if you scrap everything you've done, and re-jog the whole thing, you've almost certainly learnt a lot from that. So don't count it all as a waste

3) Thinking about all this stuff ahead of time, rather than just crashing in and building something is really good, because the old "if i knew i were going there, i wouldn't have started here" factor comes into play a lot otherwise!

4) The 'halfway house' otherwise known as Engineering Compromise is the true art. Nothing is 'built without compromise' despite what the marketers might try to tell you.  Somewhere between your original plan, and the tear up suggestions on this thread is the right path.  Your job, is to filter all the options and chose the right path to the best compromise. That's real engineering, and yes, it's often a major PITA!



Now, here's my two pence worth:


Question 1: Is this system a one off / hobby project, could it become saleable ever?  Is the answer is yes, then how you do it really doesn't matter, you'll be able to get it to work any which way, as cost / time is irrelevant

Question 2: Any 'distributed' system lives or dies by it's modularity and ease of install / extension. If more complex nodes bring overall savings via simplification of the network, then that's ok.


As soon as anyone says "12v / 24/ or automotive" then my std answer is of course CAN as it was specifically designed for this purpose. Whilst you probably aren't going to have to EMC test your install, you might well benefit from the differential bus and it's ability to still work with large ground offset voltages

[Lomax]

1) Its your project, feel free to do it how you see fit (and that does include ignoring suggestions on here)

Sure. But I'm not deaf to criticism, nor do I think I know better than those who have condemned 1-Wire. After all, my practical experience of using it is quite limited.

2) Even if you scrap everything you've done, and re-jog the whole thing, you've almost certainly learnt a lot from that. So don't count it all as a waste

Whohoo! I actually knew about RS485 (and CAN bus) long before I even had the idea of buying a boat. I used to work in industrial automation in the 90s and used a lot of RS485 (Modbus) and RS422 equipment. I've also used GPIB and other variants. In fact I wrote a nice Python app a number of years ago to do graphical data logging from my HP oscilloscope. I also have a friend who works with automotive power systems and he always talks about CAN bus, and I have read up on it a bit. It looks very good, of course, but also fairly complex. And 1-Wire wasn't chosen because of its physical properties - I knew from the start that being single ended was a major weakness (as you can see if you look at the circuit diagram I have tried to mitigate this) - but because of its compatibility with other things, most notably Domoticz, and the ease with which nodes can be added, removed, and reprogrammed.

3) Thinking about all this stuff ahead of time, rather than just crashing in and building something is really good, because the old "if i knew i were going there, i wouldn't have started here" factor comes into play a lot otherwise!

This is true.

4) The 'halfway house' otherwise known as Engineering Compromise is the true art. Nothing is 'built without compromise' despite what the marketers might try to tell you.  Somewhere between your original plan, and the tear up suggestions on this thread is the right path.  Your job, is to filter all the options and chose the right path to the best compromise. That's real engineering, and yes, it's often a major PITA!

Even more true!

Question 1: Is this system a one off / hobby project, could it become saleable ever?  Is the answer is yes, then how you do it really doesn't matter, you'll be able to get it to work any which way, as cost / time is irrelevant

Purely "hobby", purely non-critical systems. I have designed the system so that no critical functionality on board depends on any of the master nodes being online, or the 1-Wire network being up. As an example, there will be three bilge pumps on board, each one controlled by its own level sensor. I only read the status of this sensor to determine if there is water in the bilge - Domoticz does not tell the pump to run, it only logs the fact that it ought to, and the pump will still do its job regardless of whether anything is listening at the other end. Everything works along this principle, including the dimmers discussed in this thread, which can be controlled by the manual buttons as long as the 12V power supply is available.

Question 2: Any 'distributed' system lives or dies by it's modularity and ease of install / extension. If more complex nodes bring overall savings via simplification of the network, then that's ok.

I'd say that's one of the strengths of the 1-Wire protocol (confusingly, 1-Wire refers both to the physical interface and the protocol used to communicate over it, unlike RS485 which is purely a physical standard, requiring a protocol on top). 1-Wire is self enumerating and self healing - you can add and remove nodes as you like, while the network is up, and they will be found by the master. It also has some rudimentary error checking with retries (8-bit CRC). Of course, there is nothing to stop you from making an RS485 network behave like this but you have to design the protocol and write the firmware for it yourself, which I can confidently say I neither have the time, patience or skill to do. Most importantly, 1-Wire is supported out of the box by the "home automation" platform I want to use (Domoticz + OWFS), while neither RS485 (e.g. Modbus) or CAN bus is. There are many good Modbus libraries for Linux, but to get a functioning system I would either have to replace Domoticz with something else (ask me if you want a list of requirements), or write my own Modbus (or CAN bus) layer for it (which again I can confidently say I neither have the time, patience or skill to do). This is why I am so frustrated; abandoning 1-Wire leaves me with no viable alternative. I'm dealing with a real world situation, and not some hypothetical engineering "best practice" demonstration.

[Lomax]

F-it, I'll give you the requirements for which Domoticz is such a good fit anyway. Off the top of my head: 

• Open source and Linux compatible
• Minimal footprint and CPU usage
• Wide support for different devices and protocols
• Historical logging of all telemetry
• Slave support, allowing disappearing slaves
• Built in event triggers and logic
• Built in advanced sheduling of events
• Weather data support
• Surveillance camera support
• Extensible alert/notification system
• Rudimentary security system ("burglar alarm")
• Scenes and groups
• Graphical user interface for configuration
• Python API (though LUA is also strong w. Domoticz)
• Customisable GUI for monitoring/operation
• HTTP(S) access with authentication
• An active community of hobbyists and tinkerers

Edit:

• Not Java

I would be interested in suggestions for alternative systems which tick the above points while also providing support for Modbus/CAN bus. Maybe I have missed something?

[ovnr]

You know, Domoticz has a JSON API.

All you (seemingly) need to do to get your custom devices to work, is to write a simple shell script that runs however often you need updates, which queries the RS485 bus and does whatever needs to be done. It then fires off requests to Domoticz to update it.

It didn't seem 100% clear if you could add action-capable virtual hardware; the API seems simple enough, however.


Do you want Domoticz to control devices on your bus, or just read data from it?

[Lomax]

You know, Domoticz has a JSON API.

All you (seemingly) need to do to get your custom devices to work, is to write a simple shell script that runs however often you need updates, which queries the RS485 bus and does whatever needs to be done. It then fires off requests to Domoticz to update it.

Yes, there are many ways of extending and interacting with Domoticz. I wrote a simple fan control script in Bash (don't laugh) which uses the RasPi hardware PWM output to control a small cooling fan, while reporting to Domoticz via the JSON API. I also wrote a LUA plugin to monitor the OpenUPS BMS I will be using for the "security" master's backup battery (USB <> NUT). And I will need to write something to monitor the main house bank battery charger, and the solar MPPT chargers - both of which use RS485 - though no commands need to be sent to either device, so a simple polling script with hard coded addresses will do. And of course, being an open source project means I could get under the hood of the core service as well - or talk directly to the database. There's no lack of options, only time.

Do you want Domoticz to control devices on your bus, or just read data from it?

Mostly to read, but I do want to be able to control (most of) the lighting on board, so I can have them scheduled when away (to discourage burglars). Domoticz also needs to be able to turn on the external floodlights when armed away and someone steps aboard. I also want to use the "scene" support in Domoticz to create magical switches to change the lighting or the operating mode of Domoticz itself (e.g. a keypad for arming/disarming the burglar alarm). That kind of stuff. So the circuit that started this epic discussion needs to do (at least) three things:

1) It needs to be able to turn a light/motor on/off and dim it based on an external push button to ground.
2) It needs to answer queries from Domoticz and report the current status (on/off/duty cycle)
3) It needs to accept commands to turn lights/motors on/off and set duty cycle from Domoticz
4) Ideally, it needs to accept changes to the configuration, for example the button behaviour and gamma curve
5) Bonus points if it monitors the load current, and exposes the value on the data bus

[Ian.M]

Unfortunately Domoticz's device support list is full of commercial products using proprietary protocols, a great many of them over RF links, and light on open standards for interfaces like DALI or DMX-512.  However as it supports slave Domoticz controllers, and the concern for most of us here is that long 1Wire buses will be unreliable,  I think my suggestion to add more PIs or similar on an Ethernet LAN to let you use shorter 1Wire buses still has merit.  It will of course use quite a bit more power, but thats the price you pay for not being willing to write any firmware or do much scripting. 

What are the minimum system requirements for a Linux Domoticz slave? Can it run without a GUI?  Maybe one of us can point you at a cheap low power headless Linux minimalist IOT board  with Ethernet, GPIOs and not much else.

[Lomax]

Unfortunately Domoticz's device support list is full of commercial products using proprietary protocols, a great many of them over RF links, and light on open standards for interfaces like DALI or DMX-512.

Yes. That is one of its main downsides. Though don't knock the proprietary/commercial device/protocol support - I may well want to use some of those devices! I use it at home with Z-Wave dimmers, which although they work well most of the time are not 100% reliable, and certainly not lag free. They also cost a whooping £40 each...

Edit: Before you ask, yes, I have considered using Z-Wave on board, but disqualified it for a number of reasons. Please don't make me list them...

[Lomax]

What are the minimum system requirements for a Linux Domoticz slave?

I do not know, but it runs beautifully on the RasPi2. The "security" master idles at 0.00 0.02 0.03 load average with Domoticz running and polling a small number of 1-Wire sensors as well as the OpenUPS BMS, maintaining a TCP/IP connection, polling the 3G/4G router's GPS position, and with a number of other background services running, like upsd, gpsd, sshd and iptables. Current draw is just 260mA (@ 5V). I am happy with this.

Can it run without a GUI?

Yes.

Maybe one of us can point you at a cheap low power headless Linux minimalist IOT board  with Ethernet, GPIOs and not much else.

I'd be more interested in replacements for Domoticz than the hardware platform itself.

[ovnr]

I looked at the Python plugin thing. I really don't see any big roadblocks to getting it to work with custom hardware?

The only thing I'm even slightly worried about is oscillator start-up time/UART sync when waking up from sleep. Easy enough to fix; just send 0xFF as the first byte, then spin-wait until you reach the stop bit before starting the UART.

Protocol-wise, I'd probably do a fixed start byte anyway. Then an address byte, a command/length byte (4 bits of command, 4 bits of packet length), the payload, and a CRC8 checksum byte to tie it off; slaves would always respond with a single ack byte within a fixed time after the checksum is sent. I'd probably handle reads as the master sending a read command, then the slave sending a full packet to the master.


Doing a full bus scan (assuming 8-bit addressing) would take <50 ms. Do note that whichever way you do it (1-wire included), bus traffic will wake up all the slave devices, so needlessly spamming the bus should be avoided if you're worried about wasting power.

[Lomax]

the concern for most of us here is that long 1Wire buses will be unreliable, I think my suggestion to add more PIs or similar on an Ethernet LAN to let you use shorter 1Wire buses still has merit. It will of course use quite a bit more power, but thats the price you pay for not being willing to write any firmware or do much scripting.

So I had exactly the same thought some time back (February?), which is when I went through my list of sensors (and actuators) and grouped them into three groups based on task, priority and location. That's how I came up with the three masters "security", "resources" and "navigation", and the power schemes "always on", "ideally on" and "on demand" respectively.

In terms of long 1-Wire buses, the longest straight line will go from the "security" system up front via the forward, midships and aft bilge water level detectors. This is a ~10m "leg" and will be connected to its own 1-Wire bus on the "security" master. Since this bus will run under/near the floor, it will also be connected to other security sensors placed low en-route, at the moment a CO₂ detector and a gas detector (5-7 sensors in total).

There will be a similarly long line going from "resources" to the fresh water tank in the forward hull, which will pass the fresh water flow meter on the way (2-3 sensors in total). A third long leg will go at ceiling level from "security" to the fire/smoke detectors, forward, midships and engine room (3-5 sensors in total). Neither of these three need to run alongside any power cables, or transmitting antenna connections, in fact they're pretty lonely, though the ones entering the engine room will of course be entering electromagnetic hell*. They will all be host powered.

Then there is the long u-shaped bus which runs from the "resources" master in the main distribution panel, to each of the in-ceiling LED lights (the subject of this discussion). I would like this bus to pass all 12 in-ceiling lights, and take in two reading lights on each side on the way, so 16 slaves in total over ~15m. But this can quite easily be split up into two shorter buses (~7+9m) - remember that each master provides eight of them, so I can have 24 individual 1-Wire buses on board...

As I said before, PIR and door/hatch sensors, which need to "push" events, will be connected directly to input pins on the "security" master (with appropriate ESD protection), though I haven't decided the exact scheme for this yet. CAN bus certainly holds an ace here, but there are only six or seven of these "pushy" sensors, and they're all binary, so this shouldn't be too troublesome. One benefit of having a steel boat is that it's always easy to intentionally pull things to (something that resembles) ground. One drawback of having a steel boat is that it's always easy to unintentionally pull things to (something that is far too close to) ground...

No other 1-Wire buses will be more than 3-4 meters in lenght. Most of them will only be used to measure temperatures and tank levels (very "slow" values).

Here is an early version of the block diagram, which although not updated to include the 3-way split (it only has one "master"), should give you some idea of how, and how much, I have been thinking:



*) Actually, I don't think it's all that bad. The alternator and the inverter are probably the loudest and messiest sources of noise, followed by the macerator motor, and the greywater pump. There should be no problem staying well away from these. The other equipment in there shouldn't produce any electrical noise worth mentioning. Also, remember it's a diesel engine, not an angry sparky petrol thing.

[janoc]

*) Actually, I don't think it's all that bad. The alternator and the inverter are probably the loudest and messiest sources of noise, followed by the macerator motor, and the greywater pump. There should be no problem staying well away from these. The other equipment in there shouldn't produce any electrical noise worth mentioning. Also, remember it's a diesel engine, not an angry sparky petrol thing.

The largest problem with motors and such is not the sparking from the spark plugs of the main engine (which yours doesn't have anyway) but the power spikes and noise that various electric appliances and electronics both radiate and inject to the power bus - e.g. switching spikes from alternator.

Keep in mind that your 10m of bus is a 10m long antenna unless you shield it, picking up all sorts of crap from "the air". That could be your (or your neighbor's!) motors but also a microwave, radios, TV, nearby AM radio station ... What is worse, this antenna will also radiate noise out to the outside.

That's a recipe for all sorts of problems and flakiness. You can certainly shield the cabling, but that gets expensive and makes problems with complicated connections, ground loops, etc.

[Ian.M]

1Wire may not be excessively fragile if you keep the  buses short and use screened cable.  OTOH it may be.  You wont know till you build one and torture test it.   I presume you have already tested controlling a BAE0910 with Domoticz, so you should have a few handy, and presumably you have a few DS18B20 or similar.  I don't think you will run into a lot of trouble with sensor only nodes, its the  BAE0910 power control nodes that are most likely to cause the worst problems.   Put together a 5m bus with a node every meter and torture test it.  If it passes that, extend it out to 10m and repeat, then to 15m.  You'll soon have a pretty good idea what's viable and what isn't, maybe even by Monday if you get your skates on!

Plan your wiring to allow Ethernet and/or RS-485 in the future i.e trunk wiring should have a spare cat6 or at least be possible to easily mouse one through and should have a spare pair in the current data cable for RS-485.  Then if you find you have to get rid of the BAE0910 nodes in the future, you'll be able to do so without major effort.

It may be possible to put unpopulated footprints for a PIC, its ICSP header and a RS-485 transceiver and an input connector on the board you are designing so that converting to RS485 would simply be a matter of adding those two chips - either the PIC would take over from the  BAE0910, or it would act as a bridge from <whatever> protocol on RS-485 to the BAE0910.  That will only cost you board area *NOW* but adds a fair bit of future-proofing.

[Lomax]

Thanks Ian, that's very helpful information! Apologies for my slow reply - I've spent the last two days crawling around under the boat, removing rust and "blacking" the outside of the hull. Messy and back-breaking work - and 1/3 of the hull still to do!

1Wire may not be excessively fragile if you keep the  buses short and use screened cable.

Ok, so screened cable might be better than a plain twisted pair? I read that the increased capacitance of screened cable might cause issues, but maybe I can find a low capacitance option? I assume the screen in this case should be grounded only at the master end?

I presume you have already tested controlling a BAE0910 with Domoticz, so you should have a few handy, and presumably you have a few DS18B20 or similar.

I haven't tested the BAE0910 yet - that's what the prototype design we're discussing here would be for. This is why I'm eager to get the circuit design finalised, so I can start on the board layout and then produce a prototype board. This will be a dual layer board, which I will isolation mill on my CNC router. Only once I've built one or two of these and have successfully tested them would I go ahead and order a production run, probably 25 boards. I have however tested the "security" master with four 1-Wire sensors attached: two temperature sensors, one "counter" (windspeed) and one ADC (wind direction). Three of these sensors are combined in an AAG Electronica TAI 8515 "weather instrument", which will be mounted part way up the mast (we'll get to the discussion about how to protect this from nearby lightning strikes later, in a separate thread). This test rig works very well indeed, despite using normal RJ11 flat "telephone" style cables, one of which is ~3m long.

I don't think you will run into a lot of trouble with sensor only nodes, its the  BAE0910 power control nodes that are most likely to cause the worst problems.  Put together a 5m bus with a node every meter and torture test it.  If it passes that, extend it out to 10m and repeat, then to 15m.  You'll soon have a pretty good idea what's viable and what isn't, maybe even by Monday if you get your skates on!

That sounds like a good plan, but I need to finish my circuit design first, then lay out and produce the boards. I already have a pending order on Mouser for the components (apart from the BAE0910), but question marks remain around the 5V regulator (buck or linear, as suggested by ovnr?). I'm also interested to hear what other suggestions people might have as to how the circuit can be further improved, to minimise power consumption, improve 1-Wire reliability, and provide adequate ESD / EMI protection.

Plan your wiring to allow Ethernet and/or RS-485 in the future i.e trunk wiring should have a spare cat6 or at least be possible to easily mouse one through and should have a spare pair in the current data cable for RS-485.  Then if you find you have to get rid of the BAE0910 nodes in the future, you'll be able to do so without major effort.

Good point - I will bear this in mind when choosing the data cable.

It may be possible to put unpopulated footprints for a PIC, its ICSP header and a RS-485 transceiver and an input connector on the board you are designing so that converting to RS485 would simply be a matter of adding those two chips - either the PIC would take over from the  BAE0910, or it would act as a bridge from <whatever> protocol on RS-485 to the BAE0910.  That will only cost you board area *NOW* but adds a fair bit of future-proofing.

I think I'd rather do a new board if it ever comes to this - I want the footprint to be as small as possible, ideally small enough to fit behind the in-ceiling LED modules (<50mm dia).

Edit: I should add that for the inter-board connections I plan to use right angle Molex KK terminals, 254 pitch for data and buttons, 396 pitch for power. The load connector will probably be a screw terminal of some sort, or straight solder.

[Lomax]

For the cable, maybe something like the Belden 8761MN might work?

• Foil shield with 24 AWG drain wire (0.2mm²)
• Single twisted pair, 22 AWG (0.33mm²)
• Stranded tinned copper conductors
• Blue sheath, 3.43mm diameter
• Nom. Capacitance Conductor to Shield:
  183.408 pF/metre
   55.903 pF/foot
• Nom. Capacitance Conductor to Conductor:
   94.493 pF/metre
   28.802 pF/foot
• Nom. Characteristic Impedance:
   51 Ohm
• Nom. Inductance:
    0.102 uH/m
• Nom. Conductor DC Resistance:
   48.887 Ohm/km
• ~£1.85 per metre on 30m reels (inc. VAT)

[Ian.M]

Screened cable is a tradeoff between reduced noise, and slower risetimes stretching the active state pulses.  As Maxim's 'Guidelines for Reliable Long Line 1-Wire Networks' states that 200m weight CAT5 cabled networks are achievable with a simple resistor pullup, and 24pF has an equivalent weight of 1/2m, you can trade distance for screening.

[Lomax]

I'm now updating the schematic to use the TPS1H100 high-side "smart switch" suggested by ovnr - a great little chip that solves several issues, and adds one or two bells/whistles. But I'm having trouble calculating the value of the programmable current limit resistor; the formula given in the datasheet refers to a value K_CL, but doesn't explain what this is or how to derive it. In the application examples the value used for K_CL is 2000, but again no explanation given. I assume this is because people who know this stuff don't need to have it explained to them - alas I'm not one of them... Can anyone help me understand?

[Ian.M]

K and K_CL are specified as parameters - datasheet page 7

[Lomax]

Ah, there we are, thanks! Didn't come up when I searched for some reason.

[Lomax]

Humm. I liked the look of the current limiting functionality on the TPS1H100 at first; since it's a closed loop I thought I might be able to use it to create a constant current source of sorts, but I see now that it's only got a precision of ±20% at 0.5 A. The LEDs I plan to use for general lighting want 200mA, but will run hot at 240mA, and noticeably dimmer at 160mA. I guess this is not the intended use for this function... Should I bother configuring it for the intended load current, or just set it so some safe, higher current?

Edit: Now looking at Allegro's A6217 Automotive-Grade, Constant-Current PWM Dimmable Buck Regulator LED Driver. Much better for lighting (no flicker, matching brightness on all LEDs, higher efficiency, less LED stress), but no good for controlling fans or other motors. Humm...

Edit: Nah, that won't work; the large difference between V_IN and V_OUTMax mean the lights would only work when V_BAT is at or near its maximum. I do want to be able to use 12V LED modules, and they must produce a usable amount of light even when the house bank is close to being fully discharged (~11.5V). I shall have to sleep on it.

[ovnr]

The TPS1H100 current limit is intended to act as a fast, self-resetting fuse - it's not meant to regulate any current, just prevent it from exceeding a threshold.

Just PWM the LEDs, if they're basic 12V resistor-ballasted strips. If you need a closed-loop solution, sense their current and use that to inform whichever algorithm you use to choose the PWM setpoint. They're LEDs; it's not like you need to do this at a very high rate.

If you're using LEDs with integral drivers, you're out of luck on anything above on/off control, unless you really want to roll your own proper LED drivers.

[Lomax]

The TPS1H100 current limit is intended to act as a fast, self-resetting fuse - it's not meant to regulate any current, just prevent it from exceeding a threshold.

Yep, I realised this when I read the datasheet a bit more carefully. Still a nice feature.

Just PWM the LEDs, if they're basic 12V resistor-ballasted strips.

I'm not sure what you mean by "resistor-ballasted strips"? The LEDs in question are cheap 12V "under cabinet" modules, which may or may not work ok at higher voltages: I have purchased three different models for testing, two of which are fine at higher voltages, but the ones I would prefer to use (due to colour rendering, beam characteristics, and physical size) run very hot at higher voltages. Hence my interest in current limiting; 200mA provides full brightness (~2.5W) while leaving these LEDs nice and cool.

While I can approximate this with a gamma curve, it may be difficult to get all LEDs on a given power supply chain to be equally bright under varying levels of charge (there will be some voltage drop along the cable length). House bank battery voltage can vary between something like 14.5V and 11.5V, and while some change in brightness is acceptable I need the lights to function throughout this range. PWMing at too high a voltage might also stress the LEDs, even if they're not running hot; each "on" pulse would drive a higher current through the LED than it is designed for. I am not sure how important this is, but it's something I've been thinking about.

If you need a closed-loop solution, sense their current and use that to inform whichever algorithm you use to choose the PWM setpoint. They're LEDs; it's not like you need to do this at a very high rate.

This might be the way forward, but I'm not sure the current sensing ability of the TPS1H100 is precise enough?

If you're using LEDs with integral drivers, you're out of luck on anything above on/off control, unless you really want to roll your own proper LED drivers.

There are PWM dimmable LEDs with integrated drivers for automotive use; I have also been experimenting with four reading lights using dimmable G4 LED modules with built in drivers, which behave very well at all voltages and dim very well with PWM. In fact they're quite lovely, very similar to halogens. Maybe I should be looking for something similar for my in-ceiling lights.

Edit: Actually, looking at the datasheet again, the current sense precision is better than ±5% at the currents we're talking about here - that should be plenty good enough. So I'll need to integrate the current measurement with the PWM gamma curve. Should be doable.

[Ian.M]

There is an alternative. other than replacing the resistor ballasted LEDs.  You could add a switching regulator (buck converter) in the feed to all the ceiling LEDs in one cabin to maintain a stable 12.0V supply to them as long as the battery voltage is above that level.  To minimise the standing current drain, either you'd have to use one with a very low quiescent power consumption, or one with a shutdown pin, with another BAE0910 controlling it, acting as a master switch for the lighting zone.

Another matter:  Have you considered what happens to a BAE0910 and the 1Wire bus if its local 5V supply is missing?   I suspect bad things happen, and tgat it will drag the bus down, with the possibility of latchup if power is reapplied to it while its connected to a powered 1Wire bus.   The cure would be a MOSFET switch between it and the bus that will isolate it if its not powered.  A 2N7002 should do the job, Source to DQ, Drain to the bus and gate pulled up to +12V via a fairly large resistor, so it can swing with the bus due to the gate to channel capacitance rather than adding extra capacitive loading.  When the +12V is present, there will be at least 7V of positive gate bias and the 2N7002 will be hard on.  When the +12V supply is absent, other loads will drag it down to 0V, and there will be 0V of gate bias, so the 2N7002 will be offr.

[Lomax]

There is an alternative. other than replacing the resistor ballasted LEDs.  You could add a switching regulator (buck converter) in the feed to all the ceiling LEDs in one cabin to maintain a stable 12.0V supply to them as long as the battery voltage is above that level.  To minimise the standing current drain, either you'd have to use one with a very low quiescent power consumption, or one with a shutdown pin, with another BAE0910 controlling it, acting as a master switch for the lighting zone.

Yep. I have looked at some 10-20V > 12V DC/DC converters with high efficiency (remember that I want to keep losses to a minimum). It might be an idea to have one large stabiliser for the whole house system, thus ensuring a reliable 12V at all times - but even a highly efficient one (>90%) feels like an unnecessary waste?

Another matter:  Have you considered what happens to a BAE0910 and the 1Wire bus if its local 5V supply is missing? I suspect bad things happen, and tgat it will drag the bus down, with the possibility of latchup if power is reapplied to it while its connected to a powered 1Wire bus. The cure would be a MOSFET switch between it and the bus that will isolate it if its not powered.  A 2N7002 should do the job, Source to DQ, Drain to the bus and gate pulled up to +12V via a fairly large resistor, so it can swing with the bus due to the gate to channel capacitance rather than adding extra capacitive loading.  When the +12V is present, there will be at least 7V of positive gate bias and the 2N7002 will be hard on.  When the +12V supply is absent, other loads will drag it down to 0V, and there will be 0V of gate bias, so the 2N7002 will be offr.

I had not. Thanks for pointing it out - I have added such a switch to the schematic. You reckon it should sit before or after the ferrite bead on the data input?

Still working on the updated schematic using the TPS1H100; since it wants 3-5V on the IN pin (7V max) I can't drive it with an opto @ 12V - should I drop the idea of a separate floating data GND? Kinda liked the concept, like a pseudo differential signalling scheme, but have no idea how much it would help improve 1-Wire noise rejection. Perhaps not worth the effort?

[Ian.M]

I had not. Thanks for pointing it out - I have added such a switch to the schematic. You reckon it should sit before or after the ferrite bead on the data input?

After ferrite beads and any protection that clamps to ground.  Before any protection that clamps to any positive rail as those rails will be at 0V.

Still working on the updated schematic using the TPS1H100; since it wants 3-5V on the IN pin (7V max) I can't drive it with an opto @ 12V - should I drop the idea of a separate floating data GND? Kinda liked the concept, like a pseudo differential signalling scheme, but have no idea how much it would help improve 1-Wire noise rejection. Perhaps not worth the effort?

A simple potential divider will fix that.  You already need a pulldown resistor anyway, just add another resistor in series with the phototransistor.  Design for 3V level with the +12 supply at 9V, and you'll get 5V when the +12 supply is 15V, and it will tolerate 21V before that pin exceeds its +7V abs.max. rating.   If you need a wider range add a 4.7V Zener to clamp it.

[Lomax]

Ok, here's the updated schematic using a TPS1H100. There's a voltage divider on the opto output, and a switch on the data line. The low powered buck converter option has been removed. The part annotations have been updated. I suppose I don't really need the PTC on the 12V feed any more. Won't the current sense (CS) fluctuate in this configuration, as measured at the MCU's ADC pin? They do not share a ground reference...

[Ian.M]

Yes, it will fluctuate.  You'd  need an OPAMP based differential amplifier to reference it to U1 Gnd, (see http://hyperphysics.phy-astr.gsu.edu/hbase/Electronic/opampvar6.html) and you are increasing the coupling between the 5V/1Wire bus and the power sides of the circuit to the point where the optocoupler may no longer be worth using.

[Lomax]

Yes, it will fluctuate.  You'd  need an OPAMP based differential amplifier to reference it to U1 Gnd, (see http://hyperphysics.phy-astr.gsu.edu/hbase/Electronic/opampvar6.html) and you are increasing the coupling between the 5V/1Wire bus and the power sides of the circuit to the point where the optocoupler may no longer be worth using.

How about using a dual opto?

Edit: By that I mean one with two photodiodes, one of which can be used in a feedback loop to ensure linearity.

Edit: Something like this:

[Ian.M]

That could work, but its a lot of additional complexity and linear optos cost money.  Your board doesn't have true isolation anyway as the existing opto setup merely compensates for ground bounce and any offset between the power and signal grounds. 

[Lomax]

Yep. Even I, deep in my 1-Wire trance, can see that this is getting rather silly. And expensive.

[Ian.M]

We are over-thinking this:

8.3.1 Accurate Current Sense
For version B, the high-accuracy current sense function is internally implemented, which allows a better realtime monitoring effect and more accurate diagnostics without further calibration. A current mirror is used to source 1/K of the load current, flowing out to the external resistor between the CS pin and GND, and reflected as voltage on CS pin.
K is the ratio of the output current and the sense current. It is a constant value across the temperature and supply voltage. Each device was internally calibrated while in production, so post-calibration by users is not required in most cases.

Because its fed by a current mirror, if you simply return all components connected to the CS pin to data ground rather than power ground, the voltage across the CS resistor will be relative to data ground!

However this does have some restrictions.  The abs.max ratings say the CS pin cant be taken more negative than 2.7V and the fault condition V_CS,H (4.75V) on that pin will be referenced to power ground.   Otherwise we are back to a differential amplifier to shift the voltage by the difference in the grounds, with some trickery to keep the OPAMP inputs within the rails.

[ovnr]

In the vein of "oh god this is such a pile of hacks": How about using a simple 555 circuit on the power side to digitize the CS voltage, pass it thru an opto, then filter it?

Alternatively, any way to get the BAEwhatever to do serial comms of any kind? I'd personally be tempted to drop a $0.50 MCU on the power side, then do isolated comms to that. And yes, I'd be happy to supply those if you want; I've got a tube of PIC12F1501s that I don't particularly like, that can be pre-programmed with the incredibly simple program needed.

[Lomax]

Because its fed by a current mirror, if you simply return all components connected to the CS pin to data ground rather than power ground, the voltage across the CS resistor will be relative to data ground!

Aha! You mean something like this?

However this does have some restrictions.  The abs.max ratings say the CS pin cant be taken more negative than 2.7V and the fault condition V_CS,H (4.75V) on that pin will be referenced to power ground.

If I understand you correctly, swings of more than -(V_cs + 2.7)V relative to power GND might cause malfunction, or even damage the pin? And the fault condition voltage of 4.75V is not produced by this magical "current mirror", and hence will vary relative to data GND?

[Lomax]

In the vein of "oh god this is such a pile of hacks": How about using a simple 555 circuit on the power side to digitize the CS voltage, pass it thru an opto, then filter it?

Alternatively, any way to get the BAEwhatever to do serial comms of any kind? I'd personally be tempted to drop a $0.50 MCU on the power side, then do isolated comms to that. And yes, I'd be happy to supply those if you want; I've got a tube of PIC12F1501s that I don't particularly like, that can be pre-programmed with the incredibly simple program needed.

Many thanks, that's very kind of you. But going down either of these routes (linear opto, opamp, pre opto ADC, or even adding a second MCU) just seems a bridge too far to me. There has to be some limit to this madness, and I think we're dangerously close to the point where paying someone to write a Modbus driver for Domoticz is more sensible. Maybe it has already been passed.

[ovnr]

There has to be some limit to this madness, and I think we're dangerously close to the point where paying someone to write a Modbus driver for Domoticz is more sensible. Maybe it has already been passed.

Nooooo. That can't possibly be.

[Lomax]

There has to be some limit to this madness, and I think we're dangerously close to the point where paying someone to write a Modbus driver for Domoticz is more sensible. Maybe it has already been passed.

Nooooo. That can't possibly be.

Well I know you think it has But you're not looking at this from quite the same angle as I am.

[Lomax]

We are over-thinking this

@Ian.M It may be that you're just fed up with this discussion - I wouldn't blame you if that's the case - but I suspect you may have missed my response to your last post?

[Ian.M]

Didn't miss it, just didn't have anything to add.  It would work subject to the constraint that there must *NEVER* be more than 2.7V difference between the power and digital grounds. However as you have guarantee that constraint is met without clamping you haven't shown - no comment.

I'd still prefer something with an OPAMP differential amplifier entirely powered by the 5V side, designed to allow an operating common mode range of several volts without affecting the desired 0V-5V signal, and with its inputs protected against damage due to ground offsets up to double the maximum possible battery voltage to allow for transients due to wiring inductance and possible loose connections of the power wiring.

You are going to a lot of work to add current sensing you didn't originally have.  Beware of feeping creaturism.

[Lomax]

Didn't miss it, just didn't have anything to add.

Fair enough!

However as you have guarantee that constraint is met without clamping you haven't shown - no comment.

I'm sorry, but I'm struggling to decipher this - are you saying I could/should clamp the GNDD offset with a diode somehow?

I'd still prefer something with an OPAMP differential amplifier entirely powered by the 5V side, designed to allow an operating common mode range of several volts without affecting the desired 0V-5V signal, and with its inputs protected against damage due to ground offsets up to double the maximum possible battery voltage to allow for transients due to wiring inductance and possible loose connections of the power wiring.

I hear that. Thanks.

You are going to a lot of work to add current sensing you didn't originally have.  Beware of feeping creaturism.

It's either current monitoring or supply end voltage stabilisation. Current monitoring will make it easier to ensure equal brightness in a chain of lights.

[Ian.M]

However as you have guarantee that constraint is met without clamping you haven't shown - no comment.

I'm sorry, but I'm struggling to decipher this - are you saying I could/should clamp the GNDD offset with a diode somehow?

I'm saying, if you don't have anything to prevent that constraint being exceeded, all your lamp control boards will go bang the first time you get a bad connection on the power ground.   OTOH, if you do clamp the grounds together (maybe via a string of antiparallel diodes to allow say +/-2V offset)  you reduce noise immunity, and if the power ground comes loose at the feed end, you probably end up melting your data ground wire as it tries to handle the ground return current from ten lamps.

I'm afraid we are back into increasing complexity.  You *could* use a NPN current mirror referenced to power ground, to drive another PNP current mirror referenced to +5V, with a Schottky diode between them to protect both if the power ground goes above the 5V rail to transfer the CS current to the logic side, but at best that's three more discrete semiconductors ( diode + two dual transistors) and it doesn't offer anywhere near the 'isolation' of an OPAMP with 100K input resistors.

[Lomax]

Thanks. I am now looking at Node Red as a possible replacement for Domoticz. It appears to have good Modbus support, but I need to do some more research before I know if this is a viable option. I would also need to find/write some kind of bootloader and Modbus implementation for a suitable (Atmel) MCU.

[Lomax]

The ATTiny102 has everything I need in an 8-pin package, including a USART, @ £0.50 a pop: http://www.microchip.com/wwwproducts/en/ATTINY102 Shame it only has 1k of flash, that might not be enough for a Modbus implementation.

[Ian.M]

The 8K flash ATtiny841 might be a better choice.  Ok, its a higher pin count, but its 20M2, 20-pad, 3 x 3 x 0.85 mm package is pretty small, (smaller than the full footprint for an 8 pin SOIC chip) and if you want to do serial comms reliably over a normal working temperature range, you really should be using a crystal or resonator, not the on-chip oscillator.   There's also an Arduino core for it if you want something easier than Atmel Studio.

[Lomax]

The 8K flash ATtiny841 might be a better choice.  Ok, its a higher pin count, but its 20M2, 20-pad, 3 x 3 x 0.85 mm package is pretty small, (smaller than the full footprint for an 8 pin SOIC chip) and if you want to do serial comms reliably over a normal working temperature range, you really should be using a crystal or resonator, not the on-chip oscillator.

I looked briefly at the "automotive" versions, which IIUC are slightly more ESD tolerant. Can't seem to find a price anywhere though, and if you need to ask... If this design is ever finished and proves successful I will need quite a few of them, but not a reel of 3000 An 8 pin chip would be nice, but if I can't find a small enough Modbus implementation the ATtiny841 might be the best bet. Note taken re. external crystal, though I think I already knew this somewhere in my cluttered head.

There's also an Arduino core for it if you want something easier than Atmel Studio.

The what now instead of the what now? I've only ever used the open source AVR toolchain & command line compiler, and the AVRDUDE programmer. Seems to work ok?

[Ian.M]

If its not listed at MicrochipDirect, its future product vapourware.  You probably don't really need 'automotive' grade - it wont be directly exposed to off-board signals and the only possible issue will be the 85 deg C upper end of the temperature range for normal fully specified operation.  For the standard part, the usual major distributers seem to have stock in the EU.

If you are already comfortable with command line GCC and bare-metal AVR programming, ignore the Arduino comment.

[Lomax]

If I'm going to dive in and embrace RS485/Modbus + Node Red, I'll need to get some isolated TTL > RS485 converters. While looking around, I found this one: http://www.ebay.co.uk/itm/122282850664 Seems expensive @ £27 though, is it worth spending this much?

[Lomax]

I see there are AVRs with built in CAN Bus controller, for example the ATMEGA16M1: http://www.atmel.com/Images/Atmel-8209-8-bit%20AVR%20ATmega16M1-32M1-64M1_Summary.pdf Maybe this is a better route than RS485/Modbus?

[ovnr]

If I'm going to dive in and embrace RS485/Modbus + Node Red, I'll need to get some isolated TTL > RS485 converters. While looking around, I found this one: http://www.ebay.co.uk/itm/122282850664 Seems expensive @ £27 though, is it worth spending this much?

That's... not very well designed, what with the near-zero clearance/creepage distance.


On CAN bus: Certainly an option. Probably not a much better option though; it's a better protocol for a multi-master system (not entirely relevant here), but also much more complicated. You'll still need transceiver chips, but at least it seems like they have lower quiescent current.

[Lomax]

That's... not very well designed, what with the near-zero clearance/creepage distance.

Good point. I like the gas discharge tube though. And the send/receive LEDs - though I'd likely remove these when finalised, to save a couple of mA... Do you know of a better/cheaper option? Not sure I want to design a board for this as well, especially considering it's taken me weeks to (not) design the RTU 

On CAN bus: Certainly an option. Probably not a much better option though; it's a better protocol for a multi-master system (not entirely relevant here), but also much more complicated.

All I know about CAN Bus is that it is "multi master", and that people keep saying it's complicated  Multi master is nice I guess, since it would allow the RTUs to push notifications, but I don't like "complicated".   My thinking was that the built in controller on e.g. the ATMEGA16M1 would save me at least the step of implementing the communications controller firmware, leaving me free to concentrate on the PWM/control side. I haven't seen any, but maybe there are MCUs with built in Modbus support?

You'll still need transceiver chips, but at least it seems like they have lower quiescent current.

Low power consumption is high on my priority list.

[ovnr]

The GDT is cute. It also doesn't do anything to prevent blowing the shit out of the transceiver, as it just keeps the data pairs within 100 volts of each other - they can still be at 1 kV to ground.

The CAN bus hardware in a micro just handles the addressing and framing stuff. You're not likely to find hardware modbus support, because it's so simple you might as well just do it in software. Remember, this just deals with the low-end stuff - equivalent to level 2 on the OSI model. You'll still need to implement the rest yourself.

[Lomax]

The GDT is cute. It also doesn't do anything to prevent blowing the shit out of the transceiver, as it just keeps the data pairs within 100 volts of each other - they can still be at 1 kV to ground.

Right-oh, so do you have any suggestion for what I should be looking for - or will I have to roll my own?

The CAN bus hardware in a micro just handles the addressing and framing stuff. You're not likely to find hardware modbus support, because it's so simple you might as well just do it in software. Remember, this just deals with the low-end stuff - equivalent to level 2 on the OSI model. You'll still need to implement the rest yourself.

I see. I must admit I didn't read too deeply; I just assumed the on board CAN Bus implementation would provide some higher level objects for me to use in the code. WRT Modbus support, I've found this library which looks quite promising: https://github.com/mbs38/yaMBSiavr Having looked at the code, it's not what I would call "so simple" - certainly not something I could knock out myself - but at least I can understand what (most of) it does.

[ovnr]

Well, this USB to RS485 converter looks fairly decent (with the caveat that it's impossible to tell entirely thru the plastic case - at least it's well isolated). Just rip out the FTDI chip inside and connect it to your Raspberry Pi or whatever. Or just use it over USB for that matter.

Alternatively, there's this one, which is more expensive, has worse protection but doesn't include a FTDI chip that needs to be removed.

[Lomax]

Thanks to everyone for their contributions - especially @ovnr and @Ian.M. I'm afraid that time has caught up with me, and I'm going to have to put this project on hold for now - but at least I have avoided making a costly mistake. I will revisit lighting control for my boat at a later date, and that design will be based on RS485/Modbus; 1-Wire is dead - long live 1-Wire! But regardless of the postponement, there is one question which still has some urgency: cabling. Rather than spend money on cabling which will need to be replaced (once the 21st century catches up with the 20th) do you reckon I should invest in the Belden 1502R and run this to all the lights? Looks to me like it would work well for combined RS485 + power?

[ovnr]

It would work well. I'd probably balk at the cost, but I'm a massive cheapskate.