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

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