PiJuice charging + case sizing

balenaFin
1

Good morning!

We are just sorting out adding PiJuice hats to our Fins, and was hoping you could provide your verdict on power supplies.

The reported status for the battery:

pijuice.status.GetStatus()
{‘data’: {‘isFault’: False, ‘isButton’: False, ‘battery’: ‘NORMAL’, ‘powerInput’: ‘NOT_PRESENT’, ‘powerInput5vIo’: ‘BAD’}, ‘error’: ‘NO_ERROR’}

The powerInput5vIo value, as you can see, is BAD; this is using the fin with the standard PSU supplied with it at 12V/1.5A. The documentation isn’t exactly clear about what BAD means in terms of charging at all vs very little. After two days, I wouldn’t expect the battery level to be reporting at only 54%. Though, I have only recently begun reporting battery levels so maybe it was lower and is (very) slowly charging - I will keep an eye on it.
Do you have approximate charging time figures we should be expecting?

Another topic briefly mentioned the PiJuice being fine with any PSU at around 5V/2A. Can you suggest and/or provide other more suited PSUs for use with a Fin/PiJuice combo?

Yet another topic covered the PiJuice fitting within the standard Fin enclosure (answer was simply to use the Phoenix ring case, which we have no plan to use).
In the standard case it’s… tight. Could do with being just like 1-2mm taller to allow it without the bulging, but it’s passable without.

I mention this because you also have an issue with the width of the case and the SIM slot - I don’t know if this has been reported yet.
There is something approaching zero space between the case and the SIM card - with the side of the case being plastic, and therefore flexible.

If someone has picked the unit up from a particularly unlucky side (or hit in transit, or assembles the unit without due care), this can have - and has had - the unfortunate effect of very slightly disengaging the SIM card. In this minuscule deviation from the contacts after ejection, it seems to actually brick the SIM card. We lost two cards before discovering this particular fault.

For any reading this with a similar issue, we do have a simple, temporary solution:
We have made use of the micro-SIM adapter that the core nano-SIM was supplied within. This is thin enough (~1mm) and obviously fits around the nano-SIM sizing to be able to put it around the SIM slot and between it and the casing.
This protects the SIM from falling foul of even fairly determined flexing as it reduces the target area to only about 1cm, and with a smaller area comes a lessened ability to bend it enough to actively hit the SIM card.

Do you have any plans already in the works for modifying your existing casing that may or may not include such changes? Are you likely to? I can understand leaving the height, disappointing as it would be, but the sizing for the SIM is something that we feel should not be ignored.

3

Do you have approximate charging time figures we should be expecting?
Sorry, we don’t. That would be a question for PiJuice.

Another topic briefly mentioned the PiJuice being fine with any PSU at around 5V/2A. Can you suggest and/or provide other more suited PSUs for use with a Fin/PiJuice combo?
Have you tried using the offical raspberry pi wall adapter? It’s 5V/2.5A: Buy a Raspberry Pi 1, 2 and 3 Power Supply – Raspberry Pi .

Do you have any plans already in the works for modifying your existing casing that may or may not include such changes? Are you likely to?
There are currently no plans for modifying the cases but maybe there will be some eventually. Thanks for reporting these issues.

4

Do you have approximate charging time figures we should be expecting?

Sorry, we don’t. That would be a question for PiJuice.

Another topic briefly mentioned the PiJuice being fine with any PSU at around 5V/2A. Can you suggest and/or provide other more suited PSUs for use with a Fin/PiJuice combo?

Have you tried using the offical raspberry pi wall adapter? It’s 5V/2.5A: Buy a Raspberry Pi 1, 2 and 3 Power Supply – Raspberry Pi .

Do you have any plans already in the works for modifying your existing casing that may or may not include such changes? Are you likely to?

There are currently no plans for modifying the cases but maybe there will be some eventually. Thanks for reporting these issues.

6

Hi zvin,

Thanks for answering.

New questions abound, seeing as how the battery is indeed not charging. We don’t have any standard Pi PSUs, best I could find around was a 12v/2A, but the PiJuice still reports as ‘BAD’.

What have you guys experienced with the PiJuices? How have you hooked it up to your Fins? The PiJuice documentation lists about a billions ways you can hook it up, half of which involve using the microUSBs in one configuration or another.

It also has one small reference to needing the micro in:

Note: Turning on the Raspberry Pi via the onboard intelligent switch only works when the power is provided to the micro USB on the PiJuice.

However, that warning isn’t repeated a little further on in the Automatic Wake-up section. Which is it?! Have you covered this at all in your own testing? Do we need to additionally attach the PiJuice via a USB somehow? I don’t immediately see any available headers or anything one could access looking at the one in front of me - and we certainly aren’t going to use one of the external ports and feed it back round into the case…

At the end of the day, if power is lost (or unplugged) we want the PiJuice to keep the Fin alive until we hit, for example, 20% battery and then we’ll shut it down. If it’s off and power is then restored, it should power the device (so long as it’s off off, this works just like if you were plugging the device in, generally, and works as-is). If it shuts down and power is restored mid-shutdown, it should additionally boot it back up (watchdog functionality; which doesn’t appear to be enabled by default?).

Pretty standard, nothing out of the ordinary, but trying to chew my way through the documentation that is Pi-based (should, in theory, be very similar to Fins, I would hope) isn’t getting me as far as quickly as I hope some simple direction from yourselves could provide.

Our current setup:
Balena Fin (in standard Fin case)
~12v/2A input into Fin case DC connector
GSM module (EC20)
PiJuice (BP7X battery) attached only via the Hat header

Thanks in advance!

7

Hey @krenom, I believe some of our team members have experience with PiJuice, some other people have experience with other batteries and the Fin. Will forward this question to them. I believe the difference between the Fin’s power management and the Raspberry Pi boards power management is enough to be confusing (both for the user and for the hardware provider potentially).

For the power supply, on double-check, the Fin indeed needs currently more voltage through the barrel connector (6-24V input needed there). The regular Pi wall PSU us not applicable.

Will keep you posted when we had a chance to test things.

9

Hi imrehg,

Power
Power.jpg3024×4032 1.75 MB

A brave micro USB cable sacrificed its life to get spliced into the barrel connector, so 5v/2.5A DC now goes straight into the juice with the Fin being powered directly from that.

This now puts the juice into the charging state; but anything less than 2.5A labels the power in as ‘BAD’, similar to my previous post, and thus doesn’t charge. It works, though, that’s the main thing!

The watchdog seems to work, sort of. If, at any point, I don’t hit the juice with a command for 2m, it confuses the hell out of me as to why my terminal on Balena Cloud has shut down until I realise that the juice has just triggered a reset and my containers got shut down!
I guess I should hook up the polling soon before I go mad…

However, with my current setup it doesn’t seem to reboot the device successfully if I shut it down. I suspect that with the juice in it now, the shutdown procedure actually has to be to trigger the juice shutdown (SetPowerOff(x)?) and then do the Fin shutdown. After which, in theory, I guess the wake on charge should bring it back up after the watchdog timeout.

That’s the plan, anyway. Will update further as I succeed/fail.

13

Good morning,

Quick update from our side: it’s working, mostly.

The short of it:

pijuice.power.SetWatchdog(5)
pijuice.power.SetWakeUpOnCharge(0)

And yes, I was right in my previous reply that when shutting down it needs a:

pijuice.power.SetPowerOff(200)

Now for the more complete version:

Hardware:
5v/2.5A directly into the PiJuice micro USB and have the Fin powered via the PiJuice. That doesn’t seem to be in question at all at this point.

Settings:

The watchdog - needs to be set on first usage. This is stored in non-volatile memory so doesn’t need to be done every time, but it doesn’t hurt to set it, regardless, on startup. Seems it should be set at something like the 5m mark to cope with shutdown time plus restart time so containers kick in and start polling the PiJuice.

Wake on charge - this deserves an entire section unto itself. This has caused many a shed tear and we are not the only ones. Using pijuice.power.SetWakeUpOnCharge(0) tells the PiJuice to always boot when there’s power in, as opposed to waiting until the battery is at least some other % charged.
This setting is NOT saved in non-volatile memory. This setting is wiped every time it is used and boots the device. This setting, therefore, needs to be set on EVERY start up.

We’re not too certain about the viability of this, and are awaiting a response on how to proceed; one of the comments on the issue mentions the line to save that setting into the non-volatile memory is just… commented out.

Powering off - Just using the max value of 255 was not having the effect of setting a timer for 255s. Using 255 is actually the value for not turning it off. Thanks for that. Our complete procedure for shutting down our Fins is now:

pijuice.power.SetPowerOff(200)
http req: ...supervisor/v1/shutown?apikey=...

200s is enough time to have the Fin do a complete shutdown before the PiJuice cuts the power; it’s actually most of a minute over but it’ll do and give some wiggle room, especially if we add any more containers.

Without telling the PiJuice to cut the power, it leaves the Fin powered in some small fashion (some LEDs are still on), so the only way to turn it back on is to use the physical button on the PiJuice; un/re-plugging has no effect without removing the PiJuice battery (because it’s a UPS solution!)

So, TL;DR:

  1. Switch the power from going into the Fin to going into the PiJuice micro USB
  2. Use minimum of 5v/2.5A power
  3. EVERY boot, pijuice.power.SetWakeUpOnCharge(0)
  4. Ensure (if not every boot) WD is set for at least 5m pijuice.power.SetWatchdog(5)
  5. When shutting down, MUST tell the PiJuice to power off pijuice.power.SetPowerOff(200)
15

Hi @krenom

Great progress and thank you very much for sharing your insights on this here. As far as I can see everything should work from the Fin side. In case I overlooked something, please let us know how we can help.

17

Hi @afitzek,

You can make our cases a couple of mm bigger :wink:

You’re welcome. I just hope that this helps others find answers and usage quicker than myself.

To that end, I can add a couple of other details regarding our UPS docker container:

I gave up trying to sort the requisite packages on Alpine like several of our other containers, and just went in for an Ubuntu one to get it working. I’m sure we should be able to get away with cutting our container down from 400MB at some point in the future…

Main gist of our Dockerfile.template:

FROM balenalib/%%BALENA_MACHINE_NAME%%-ubuntu-python:3.6

RUN apt update
RUN install_packages gcc python3-dev python3-urwid python3-smbus
...

ENV UDEV=1
...

And because I’m not the biggest Linux/Python user in the world, also gave up on directly trying to install (and reference) the actual PiJuice package (thus it’s not in the above).

I just ripped the pijuice.py file from their github and added it as another standard old file to the project; all that matters is that with the above install_packages, it works…

18

@krenom thanks so much for the wealth of information you’ve shared in this thread! I have a project planned with the PiJuice on the Fin too so this is going to be really useful.

20

Hey @krenom Krenom,

Thanks for posting so much information about how you accomplished this, we are looking at going down this path one day so you can run the devices off a battery pack and hot-swap between battery packs with the Pi juice inside maintaining power temporarily.

When I was working with the fins, I needed to run with the lowest power consumption possible. To do that I turned off the status LEDs and HDMI port and limited the CPU scaling_governor.

Just in case that helps your use case:

commands = []
if self.our_env['turn_off_hdmi_leds']:
    print('Turning off hdmi and leds')
    print("We expect two I/O errors here")
    commands.extend([
        'echo 507 > /sys/class/gpio/export',
        'echo "out" > /sys/class/gpio/gpio507/direction',
        'echo 1 > /sys/class/gpio/gpio507/value',
        'echo 511 > /sys/class/gpio/export',
        'echo "out" > /sys/class/gpio/gpio511/direction',
        'echo 0 > /sys/class/gpio/gpio511/value'
    ])
if self.our_env['put_cpu_in_powersave']:
    commands.append('echo "powersave"| tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor')
for command in commands:
    command_on_host(command)

The status LEDs and HDMI being off doesn’t make much difference, probably less than a tenth of a watt. But the CPU power save mode prevents the CPU from drawing its max load and can bring the max load down from 6 watts to 5. Overall I wouldn’t recommend it because it is probably more efficient to let the CPU draw as much as it needs and then drop back down to its low power state.

As for a bigger case, I felt that need when we had thermal issues with USB power load causing reboots. We designed this lid to replace the stock lid:

image
image.jpg903×750 201 KB

Files for the design here

They allow you to use the same screws and can be 3 printed or injection molded depending on your scale. They feel sturdy and but if visuals are important they don’t look good when 3d printed. The design is for 3d printing but we may be revisiting this and if we do I will try and update the forum.

Good luck and thanks for sharing your progress.

-Thomas

22

Hi @tacLog,

You’re welcome, and thanks for your own information!

The casing details I will certainly pass on for people to take a look at, and while I’ll probably squirrel away the power information, our use-case is that we use the Fins as base stations for separate sensors to stream data to; we expect the devices to be on - and powered - 24/7.

The visuals aren’t a deal-breaker; these are, in theory, down and out of sight and mind whereas the sensors are the visible units.

The main use for the juice is to keep it alive long enough to send an alert, do a proper shutdown, etc. and, rather importantly, have the Fin boot back up as soon as power is restored.

That last point is quite the sticking point right now, however. Though this morning I also question its ability to shutdown properly:

Last night: I did my aforementioned shutdown procedure (that has worked before) - pijuice.power.SetPowerOff(200) - and even threw in a quick loop to watch it count down while the Fin ran through shutting down.

The Fin never turned off (completely). It was left in that familiar powered/not-really-powered state, so I had to hold the power button on the juice to shut it down fully.

I didn’t expect much this morning as I got in to the office and threw some power into it. I was not disappointed. Power button had to be pressed to start it booting, so either the not-quite-shutdown cleared the WakeUpOnCharge value, or it just… doesn’t save it for particularly long (ignoring the fact we know it doesn’t save in non-volatile)?

I guess the story isn’t over quite yet, so I’ll endevour to continue to provide updates for any breakthroughs we manage in the hopes others following in our footsteps can walk away with less hair being torn out.

23

Thanks for the feedback, and indeed please keep us posted! This is very useful! (and we’d like to keep people’s hair intact as well!)

25

Good afternoon!

Ok, I think final update.

Here is the most relevant part of a reply we got from PiJuice regarding various features that are otherwise poorly documented:

Function flags=pijuice.status.GetFaultStatus() returns dict with fault flags, ‘watchdog_reset’ field states if there was watchdog reset. This function can be called after boot, after that call pijuice.status.ResetFaultFlags(flags) to clear them.

There is no currently implemented software command directed hardware reset, however as you said you can combine wd and stopping i2c or delayed power off to do hard reset.

SetWakeUpOnCharge is recommended function to turn on as soon as power is back with parameter 0 or usually some greater value for better stability (assuming that battery is always near full in your case).

Overall, we have the PiJuice working as effectively as we can, with only some minor reservations - such as what happens in a couple of edge cases with regards to not booting etc. etc.

On every device boot:

  1. Set watchdog (10)

In order to SHUTDOWN the device - this means removing power to the Fin, and having the Fin power back up once power is plugged back in:

  1. Power must be unplugged!
    1.1) To use the wake on charge, power MUST NOT be connected (however, see below)
  2. Set watchdog 0
  3. Set wake on charge (0)
  4. Set power off (x)
  5. Request host OS shutdown

In order to RESTART the device - and this means full cold-reboot style restart:

  1. Set power off (x)
  2. Request host OS shutdown
  3. … let watchdog power it back up

The key to all of the problems has been the misunderstanding about the wake on charge. Point 1.1 of the shutdown above is the main point to the whole thing - we had been thinking that the wake on charge would only come into effect if the device was off or whatnot. This is most definitely not the case. With knowing that, we can work the shutdown procedures and whatnot around it.

On power loss, e.g.:

  1. Start timer
  2. Lost power > 5 or battery < 20%?
  3. Set watchdog (0)
  4. Set wake on charge (0)
  5. Set power off (x)
  6. Request host OS shutdown

Basic time/charge checks before, essentially, triggering the above shutdown process. This will enable the device to boot back up as soon as power is supplied again.
We worried about the case wherein power is restored after all of that has been set and before shutdown has finished. The answer is that due to the wake on charge (0), as soon as power is restored, it will trigger a soft reset anyway that also removes the power off timer so that the device doesn’t shut down at all. It means that the device isn’t safely shutdown at all but forcefully restarted - but the chances of the timings coming together to cause this edge case should be sufficiently small.

With the above power loss procedure, it means that a basic unplug of the device will, after 5m, actually do a shutdown. The only real difference between triggering a shutdown and having it auto-shutdown after a power loss is the 5m timer.

All of the above suits our use case, at least, of having our devices up constantly (so long as there is power) and providing time to send signals and do a proper shutdown in the event power is removed; followed by the device coming back online once power is restored.

Finally, the addendum to the wake on charge mentioned way up there. PiJuice did provide a new v1.4 firmware binary file that we could, if we wanted to take advantage, flash onto them (that I can’t upload because binary file…).

This update, in their words:

Also attached is the latest firmware V1.4 binary with update to not allow deactivate of wake-on charge while there is active power of count-down. that you can update via pijuiceboot tool.

Very useful, and is exactly what I had tried to do in my first week of playing with the PiJuice:

  1. Set power off (x)
  2. Set wake on charge (0)

Without the update, you get the current functionality described above (forcing a restart if you try setting it with power attached). With the update, you are free to begin the shutdown and then immediately set the wake so that it will take effect once the unit is off - not before.

I hope this helps people have an easier time getting underway with using the PiJuices in future!

27

Really final reply now that the GitHub issue has been killed off on this matter:

PiJuice cannot/does not/will not support 100% guaranteed device power-on when power is supplied. You can get the approximate behaviour from all of the pain already described in the past posts by using the flag, etc.

However, after having a wave (~6 out of ~25 current installations) needing a physical site visit to pop open the case to press the power button because the Fins didn’t boot upon power being restored, we are making moves to remove the PiJuices from our production devices. They are just not suitable for our use case (closed case, always on, full-remote management).

Having reviewed the advantages of a UPS solution, the deal-breaking cause for pause is the hardware watchdog feature that the PiJuice provided that we need to replace in some fashion.

I hope anyone wanting the same from their UPS solution reads this before buying several thousand [insert currency]-worth of PiJuices like we did so that you know what you’re getting.

1 Like