The watchdog description in the READMEs implies it watches the RPi.
However there is no watchdog reset command sent by the service on the RPi.
The watchdog timer is part of the PiJuice MCU (STM32) and only resets the MCU when it times out (as far as I know).
How was this supposed to work with the RPi?

Add description of a manual package install just in case and also of a local compile etc if necessary

tidy up repo and improve documentation

I've created a user script that I wish to run when SW2 is pressed. I've added the path to the script to the user scripts tab and configured HAT to trigger that script when pressed...but zilch.
Also when I close the PiJuice Configuration app it reverts the user script back to a previous script that I was testing.

The file /var/lib/pijuice/pijuice_config.JSON exists.
Permissions for the file
-rw-r--r-- 1 pi pi 77 Jan 5 13:31 pijuice_config.JSON

Contents of pijuice_config.JSON (Which shows the ORIGINAL command I entered in the user func)
{
"user_functions": {
"USER_FUNC1": "idle3"
},
"system_task": {}
}
Thanks!

Test software setup images

I set up a user_func1 which logs events as described in the Software->Test README.
Put the limit for low charge at 15%.
Started with a full battery and disconnected it from the USB power.
Button events (SW2 triggering USER_FUNC1, and 10 sec press, power-off) worked.
However the charge passed 15% and nothing happened.
Battery ran out and got a forced-power-off (properly logged).
Reconnected the power and the RPi woke up at 60% as specified.

Looking at the condition for triggering low charge in _EvalCharge() a > has to be replaced by >=:

if level == 0 or ((level < th) and ((chargeLevel-level) > 0 and (chargeLevel-level) < 3)):

has to be

if level == 0 or ((level < th) and ((chargeLevel-level) >= 0 and (chargeLevel-level) < 3)):

After this change I got a crash because lowChgEn was not defined inside _EvalCharge()
lowChgEn has to be declared global at the top of main() and inside _EvalCharge().

lowBatVolEn in _EvalBatVoltage() has exactly the same problem.

After these additional changes the low charge detection (finally) worked properly.

0929-7-15-20-75-14-11-0 is OK to use instead of 0929-7-15-20-77-14-11-0.

We just tested it. Just recording this here so I don't forget!

add firmware source code

For those of us who run our Pi's headless, are there any commands that can be run to check battery level etc?

We have decided to adopt a two digit group versioning with major version for big group of fixes and minor for each build.
We should adopt the same for both software and firmware.

Additionally we need to provide a change log for SW and FW in a descriptive form listing bugs and improvements

The change log shall be one file only with two sections:

• Header Section explaining how to check the versions from command line or GUI, other info
• Version x.y
• Software
  Improvements
  Fixes
• Firmware
  Improvements
  Fixes
  -Append of the previous Versions

Next software release will be 1.1 and so will it be for firmware I reckon.

@DenisKhrutsky @mmilann @tvoverbeek @shawaj any thoughts on this are welcome.

@klint-k asked this...

I can not remember if the PiJuice can stack on an other PiJuice. If a person got three Pijuice would it be 12 hours working time on the RaspberryPi?

The answer is as follows:

It might be possible if disable 5V GPIO input so one board will not charge another, than only way to charge is through USB Micro input. But it is not efficient to do that way, much better to just use bigger battery. And I2C address should be changed but also rpi software does not support multiple pijuices(yet)

The following items need to be documented.

Wakeup on charge updated to be activated only if power source is present.
Futher this enables wakeup after plugged if this parameter is set to 0.

Button wakeup functions power off and power off can be now assigned to arbitrary button events.
Removed constrain to be assigned only to long_press2 for power off, and single_press for power on.

Added reset function that can be assigned to some of buttons and button events.

Added no battery turn on configuration.
Now it can be set whether or not user wants to turn on 5V rail as
soon as power input is connected and there is no battery.

Added configuration for 2 IO ports.
They can be set to analog input, digital input, digital output and pwm output.

There are debug prints in pijice_sys.py that could be unnecessary execution overhead in system task loop. Suggest to remove all of them.

Basically - a gui-less version of the software.

Either have a pijuice-lite installer, or alternatively, split the debs into pijuice and pijuice-gui or something similar...

I think 10 seconds for LONG_PRESS1 associated to SYS_FUNC_HALT and 20 seconds for LONG_PRESS2 associated to HARD_FUNC_POWER_OFF are far too long.
I'd propose to preset LONG_PRESS1 to 5 seconds and LONG_PRESS2 to 10 seconds. This is mostly to do with the fact that once you power off the Pi the PiJuice won't automatically remove power to the Pi and people will have to use SW1 to do so.

Hello

@reviewers - could you check out this code:

#!/usr/bin/python
from __future__ import print_function
from pijuice import PiJuice
pijuice = PiJuice(1,0x14)

for K in range(61):
        pijuice.status.SetLedBlink('D2', 1,(244, 66, 104), 0.3, (0, 0, 52), 0.1)
        pijuice.status.SetLedBlink('D2', 1,(255, 33, 52), 0.5, (0, 0, 0), 0.75)

If it works I would call it "Frankenstein" else it should be called "Igor". If it dose not work Igor did not bring the right parts.

All stuff exclusively between pijuice_gui and the system task) does not update immediately when the system task is already enabled (although the JSON is updated immediately on 'Apply'.
Similarly when unchecking the system task enable checkbox the task is not disabled (changing from disabled to enabled does restart the service which will then pick up the configuration).

I do like the info on the README. I am still wondering why there is a pogo in the package? Where is it meant to go?
That is a great start on the more info.

Setting one of the RGB components in the GUI for D1 doesn't change it's colour. Furthermore after applying the new settings the green status light disappears. The blue charging light stays no matter what happens.
It all goes back to normal if resetting the board via "Reset to default configuration".

Also noticed that when messing with the D1 RGB settings in the GUI I get communication errors.
Suppose the update LED command to the STM32 interferes with the STM32 LED commanding.
Probably also what happens when the green disappears.
Something to fix in the firmware?

@mmilann this is related to what I was telling you about lately. What do you think?
@tvoverbeek could you post the errors you were talking about?

On / off settings for the items on this menu save, but the expire period, trigger level, and two threshold figures do not save in the JSON?

See here for the menu pictures.

We need to show thorough documentation about the JSON file, how to use it, how it ties in with the GUI/software and all of the features that can be enabled.

Here is an example of a JSON with some features enabled:

{
  "system_events": {
    "low_battery_voltage": {
      "enabled": false
    },
    "forced_power_off": {
      "enabled": false
    },
    "forced_sys_power_off": {
      "enabled": false
    },
    "low_charge": {
      "function": "SYS_FUNC_HALT",
      "enabled": false
    }
  },
  "system_task": {
    "enabled": true,
    "wakeup_on_charge": {
      "enabled": true
    },
    "min_charge": {
      "enabled": true
    }
  }
}

PiJuice.config.GetFirmvareVersion() now returns version='10', variant='0'.
With the agreed versioning I would expect version='1', variant='0'.
For the upcoming release version='1', variant='1'
Also note the current spelling of GetFirmvareVersion (v instead of w).
Intentional? Or just a typo?

The service only reads the configuration when it starts.
When initially the system_task is disabled the service exits after the initial checks.
If the system_task is active any changes in the gui for the service are not seen by pijuice_sys.py.
Also when enabling the system_task in the gui the service is not (re)started.

This could be confusing for new users, unless you document clearly that a restart is required
after changing settings in the gui.

In the main README -> Basic Functionality -> Power On and Off the Pi the picture shows the LEDs and switches in the order SW2 - LED2 - SW3 - SW1 - LED1.
The LED1 and LED2 labels have to be exchanged.
The picture in the hardware section is correct.
Also I had trouble orienting myself with the picture in the main README, since it is not
clear where the edge of the board is located (bottom of the picture) especially since
LED1 and LED2 labels are in the wrong place.

These functions are defined in pijuice_sys.py

In the changelog for the 2017-10-23 firmware it says:

Added command to configure charging, enable/disable
Added command to configure inputs, disable/enable 5V io input to charger, set usb micro in current limit, set usb micro in DPM voltage

Are these new commands already supported in pijuice.py?

Anyway I managed to get my PiJuice in a state where it was not charging the battery, with the power connected to the 5V PiJuice USB.
Power went to the Pi, but the battery remained at constant charge level (no blue blinking LED1).
Got it back to charging by shutting down the Pi, removing external power, removing the battery and reinsert the battery, reconnect power to PiJuice USB.

The pijuice.sh bash script in Software/Test does not work at all (wrong commands).
Below a modified version which works.
Should be checked by somebody knowing the firmware.

#!/bin/bash
#
# This script assumes the pijuice service is not running.
# Otherwise the long press on SW1 will shut down the Pi.
#

BUS=1
ID=0x14

GET_BUT_EVT_CMD="BUT_EVT=\$(i2cget -y $BUS $ID \0x45  b |sed -e "s/^0x//" |tr "a-z" "A-Z")"
GET_RSOC_CMD="RSOC=\$(i2cget -y $BUS $ID \0x41  b |sed -e "s/^0x//" |tr "a-z" "A-Z")"
GET_VER_CMD="VER=\$(i2cget -y $BUS $ID \0xFD  w |sed -e "s/^0x//" |tr "a-z" "A-Z")"
GET_CUR_LOW_CMD="CUR_LOW=\$(i2cget -y $BUS $ID \0x4f  b |sed -e "s/^0x//" |tr "a-z" "A-Z")"
GET_CUR_HIGH_CMD="CUR_HIGH=\$(i2cget -y $BUS $ID \0x50  b |sed -e "s/^0x//" |tr "a-z" "A-Z")"
GET_TEMP_LOW_CMD="TEMP_LOW=\$(i2cget -y $BUS $ID \0x47  b |sed -e "s/^0x//" |tr "a-z" "A-Z")"
GET_TEMP_HIGH_CMD="TEMP_HIGH=\$(i2cget -y $BUS $ID \0x48  b |sed -e "s/^0x//" |tr "a-z" "A-Z")"
GET_BATVOLT_LOW_CMD="BATVOLT_LOW=\$(i2cget -y $BUS $ID \0x49  b |sed -e "s/^0x//" |tr "a-z" "A-Z")"
GET_BATVOLT_HIGH_CMD="BATVOLT_HIGH=\$(i2cget -y $BUS $ID \0x4A  b |sed -e "s/^0x//" |tr "a-z" "A-Z")"

eval $GET_VER_CMD
echo Firmvare version: V${VER:2:2}.${VER:0:2}

# Clear button 1  events
i2cset -y $BUS $ID 0x45 0xf0 0xff 0xf0 i

while true; do

eval $GET_BUT_EVT_CMD
eval $GET_RSOC_CMD
eval $GET_CUR_LOW_CMD
eval $GET_CUR_HIGH_CMD
eval $GET_TEMP_LOW_CMD
eval $GET_TEMP_HIGH_CMD
eval $GET_BATVOLT_LOW_CMD
eval $GET_BATVOLT_HIGH_CMD

echo CHARGE = $((0x${RSOC}))%, Temp = $((0x${TEMP_HIGH}${TEMP_LOW}))[10K], VBAT = $((0x${BATVOLT_HIGH}${BATVOLT_LOW})) mV, #Current = $((0x${CUR_HIGH}${CUR_LOW})) mA,

if [ $BUT_EVT = "05" ]; then
    # Long press (10sec) on SW1
    break
fi

sleep 1
done 

The weight specified in the Material Safety Data Sheet is given as 35kg.

One Amazon advertisement gives the weight as 36g, 3 orders of magnitude smaller.

This certificate may need to be re-issued.

add info about programming firmware without GUI

add device tree and driver files

I have no idea what the System Switch referenced in the HAT tab of the GUI does.
Moreover you cannot change it in the HAT tab (unless you are very very fast) because _RefreshStatus() overwrites the values every second.

OK. This is the last one for today

Have had a look at the user guide but it seems very short of info. Like I assume that I plug my power supply into the Pi-Juice rather than my Pi, but cannot see where it tells me what to do. I assume I don't have to do anything to get the system to switch to the pi-juice if there is a power failure but again I could not find this in the docs. I give the basic documentation one star as it seems to be missing the basics and jumping into projects

We should create a Python 2 / 3 Wrapper for software package to make it easier to use within scripts in a python library

For version 1.1 the package has changed name from pijuice to python-pijuice.
Since the pijuice package is already in the raspbian archives, this might cause problems.
For instance the prerm script should now also remove existing installs of pijuice.
control should indicate this replaces the pijuice package.

Both the -light (still on 1.0) and the python-pijuice package contain old firmware file PiJuice.elf.binary with size 64600

add hardware sources or just add PDF schematics in hardware folder

We should add links back to the quick start guide and battery level calculator on the website

The JSON file that stores the settings from the GUI is found here

/var/lib/pijuice/pijuice_config.JSON

If it doesn't exist create an empty one with the following contents

{
  "system_task": {}
}

The RGB LEDs also don't seem to provide too much of a different light when displaying orange or red, I would assume this is true for many of the colour combinations you could achieve. Maybe worth rethinking what can these LEDs can/should actually do or be used for by possibly providing only combinations that will make sense and not the full spectrum of RGB combinations. When running down the battery it turns on the red LED when < 50% (looks more like orange). No change when charge level drops below 15%. I suppose you cannot differentiate between orange and red with this 3-color LED.
Description of red (level < 15%) in the hardware README to be deleted?

pijuicetest:

• https://github.com/PiSupply/PiJuice/blob/develop/Software/Source/pijuicetest.py
• https://github.com/PiSupply/PiJuice/blob/develop/Software/Source/src/pijuicetest.py

under Software/Source/doc there are two readme files which could be incorporated under the main READMEs instead. Are those for the Debian package structure?

Same for PiJuice\Software\man\pijuice.1

Same for PiJuice\Software\Source\README.md

Same for PiJuice\Software\Install\README.md

Same for PiJuice\tree\master\Software\Test\README.md

Could we not have these information incorporated in the main READMEs? If we need these to be there can we not still have all info in the main READMEs and only copy specific paragraphs of these into the files for Debian?
Having too many files like that around will be confusing and difficult to maintain.

There is placeholder for ON_OFF_STATUS LED function in software but not implemented in firmware. This can confuse users and should be removed as option from configuration or to implement in firmware.

@francesco-vannini was inspired by the recent news about apple dynamically reducing the CPU power on their devices due to aging batteries - and had a neat idea.

Potential to underclock the CPU to increase battery life.

Needs further investigation

Just had a quick thought. Not sure how feasible it is but it might be cool to have a "tool tip" type functionality where hovering over some setting gives a definition of what it does and/or how to use it

eeprom repgrogramming guide

To avoid issues with it getting stuck in a reboot loop?

From @mmilann:
"I do not recommend having browse button. Without authenticity check user
can load and file this will make non responding to any command and also
activating bootloader to re-update, so user must initiate bootloader
manually. Other reason is that new firmware will usually bring new features
that requires software update, so no sense to update only firmware without
software.

What can be good is to have all previous firmware in
same /usr/share/pijuice/data/firmware/ directory, and maybe having option
to revert to previous version."

Nice that you can configure the IO pins in the GUI.
These are 2 unused GPIOs on the STM32.
It is not documented how to get input and output from these STM32 GPIOS.

Hello,
This should be a simple question, I hope. I have a RPi2 that hase been wating for the PiJuice, it has pijuce software installed on it.
Will the software update with apt-get? (How would we know?)

Klint-K

As raised here - http://www.recantha.co.uk/blog/?p=17790

The PiJuice automatically powers the Pi on as soon as you attach it to the Pi. Perhaps have this configurable in the software instead but have it defaulting to off as this is probably a safer way of it working

add eeprom code / settings