What is the minimum power CAN bus solution?

[LMI2]

Posted on August 03, 2015 at 19:31

We could use a 100 device CAN bus, but we have limited power for the system.

Total power would be about 2-3 watts. How low power is possible. Total length of the bus is about 15m. Other requirements for the processor are an ADC and some IO. So not a lot. Speed is also not critical. Is this possible.

[Tesla DeLorean]

Posted on August 03, 2015 at 20:12

How are these being powered?

I don't have any measurements for CAN, you'll need to look at your transceivers and see how much they draw in a quiescent/listening configuration. You can configure the CAN peripheral to listen/filter for specific patterns, and if a specific packet hits the chip it will go into the FIFO and interrupt. The STM32 can be left in SLEEP mode, figure a WFI loop, it will wait in low power mode until you get some activity.For CAN you'll need a continuous and accurate clock.You're going to need to pick components, prototype your board, and measure/analyze the current it uses.There are several STM32 families, with different power profiles. I'd recommend getting some evaluations boards, prototype your concept and then look at there the power consumption is coming from. Low power is a system level thing, so you'll want to look at how you do the supplies, and what you're interfacing to, as things external to the part tend to draw a lot of current. A Cortex-M3 part will draw quite a lot of current doing nothing in a loop, so you definitely want to use WFI. You also want to look carefully at clocking speed vs the time it take to do the job, and how than increases as processor clock drops.

[pmoore]

Posted on August 03, 2015 at 21:48

Mich:

I have been looking into something like this in an environment with roughly 36 watts of power available.  Exclusive of your application I/O needs, I found that the CAN transceiver was a significant load (50mW idle/receiving, 300mW transmit).  So your I/O needs, plus CAN transceiver, plus your processor and external oscillation source (HSI drifts too much for CAN),  gives you your minimum power budget.  If 3.3V CAN is acceptable for your application (rather than 5V traditional CAN), I suggest looking for the lowest receiving state power 3.3V transceiver you can find.  If your response time needs supports it, putting the transceiver into ''sleep'' mode  can also be a huge power savings (the CAN master would know a given node would be ''awake'' to listen for a message only during specific points in time).  Of course you could sleep the processor as well and wake up just to read the I/O state and send packets to the master as needed...perhaps scheduled by at RTC interrupt, so everything except the RTC was off during the idle period.  A CAN EVENT from the slave to the master to say, ''I'll be awake for the next xxx amount of time'' could also be used.  The STM32F042 or STM32F072, run at the lowest core clock rate that meets your application (inclusive of CAN) needs, might be good choices. If you are down-converting from a voltage above the processor voltage, you'll have to figure in the energy loss there as well. A properly designed CAN node that only has CAN bus access and monitors input states at a very low duty cycle (perhaps to support reading an array of thermistors once a minute, or only wakes up when a switch state change toggles an interrupt line) and powered from a high efficiency power supply  might  have an average power draw below 10mW, and thus could fit your power budget.  My target application must always have the CAN transceiver available (so it never sleeps), electrically isolates the processor and application I/O from the CAN bus, runs 5V CAN, and runs a 4 digit .56'' 7-segment LED display, so inclusive of power supply losses,  modelling shows I should be able to run a STM32F072 at the maximum core clock (although it does not need to be that fast) and achieve my goal to stay below 300mW per node (to support 100 nodes with resistive power losses in the bus cabling).

[LMI2]

Posted on August 03, 2015 at 22:18

I noticed an other answer as I was writing. Yes, 36W continously is a little over our power budget. Seriously, all this is valuable information, thank you.

''You can configure the CAN peripheral to listen/filter for specific patterns, and if a specific packet hits the chip it will go into the FIFO and interrupt. The STM32 can be left in SLEEP mode, figure a WFI loop, it will wait in low power mode until you get some activity.'' If we can make only one CPU active at one time sounds just what I was looking for. But I could probably do it also by letting timers wake up the CPUs at slightly different times. If we use a collision proof bus. By the way, how can I mark quotes from mails. The ''Click for help about adding HTML formatting.'' is from Microsoft  = useless.

[LMI2]

Posted on August 03, 2015 at 22:24

Luckily, we have very relaxed specs about what we should do.

On our bus there will be only devices we know and pick, so how much it is possible break the CAN bus rules. Like a lower clock frequency.

[Tesla DeLorean]

Posted on August 03, 2015 at 22:51

By the way, how can I mark quotes from mails.

I tend to selectively cut-n-paste and then use the [B] and [I] buttons.I guess it depends a lot on what power supply (powering scheme) you've created, and the quiescent current for the CAN transceiver. Yes, you could do some time-division scheme where you're active at specific times, or windows. You'd need to keep track of time reasonably accurately, and adjust/resync.Not sure interrupting when you see CAN traffic at a pin level would allow you to react quickly enough. CMOS in a static state should draw very little. Resistive loads you can't swap out is another matter. You'd certainly want to experiment with the filter/sleep scheme, as at that point you're not continually taking the processor up/down with not traffic.

[pmoore]

Posted on August 14, 2015 at 00:18

With 100 CAN transceivers in the idle state (typically about 5ma at 5V), you are at about 2.5 watts, so the only straightforward solution would be to only bring the CAN transceiver out of low-power mode (15 microamps at 5V) when you wish to transmit.  The challenge is you have to either wake up the processor (or have the processor already awake) to figure out if an incoming packet is for that processor's address.  100 processors running slowly all the time, but fast enough to handle 125Kbit CAN, would burn about 1.5 watts (assuming zero power supply losses, about 2mW for a 2MHz crystal and 13mW for something like a STM32F042 clocked at 2MHz), so that does not leave you with much power budget remaining.

You'll have to get very creative if your power budget cannot be increased, your node count cannot be decreased, and you wish to stick with CAN.  If you truly must live with very low power, but nodes only need to rarely be powered enough to service local application devices and communicate to the CAN master (or at least peer that is always listening), putting each slave to sleep and only waking up when an RTC or GPIO line interrupt occurs may be your best option.  Such a system could require many minutes of time to cycle through 100 nodes...and would require very good power management and very efficient power supplies.