High reliability mode / guaranteed wake mode for Witty Pi 4

@drunkenungulate yes, this feature will be implemented for Witty Pi 4, Witty Pi 4 Mini and Witty Pi 4 L3V7.

@admin Do you have an ETA for when you can complete the implementation? (Dont want to stress you but it would be helpful to know) 🙂

@eagleshot we are currently running some tests to partially cover this new feature, I think we will be there within next week.

@admin Perfect - thank you for the quick implementation. I will deploy some systems next week (probably around thursday) so if you already have a (preliminary) firmware or that you could share or release it before that would be awesome. I will also do some testing anyways, so I will share my feedback as well. 😀

@admin Any updates? 😀

@eagleshot The modifications for Witty Pi 4 and Witty Pi 4 Mini has been committed to the GitHub repository. Pre-compiled firmware files are also updated. Witty Pi 4 L3V7 has not updated yet, the use case is rather different, so are the configurations.

Register 49 is used for configuring the guaranteed wake mode. Its default value (0) will disable this feature. The highest bit (bit 7) defines the unit (1=day and 0=hour), the lower bits (bit 0~6) define the value (0~127). Which allows to define a duration from 1 hour to 127 days.

The software is not updated yet, so it doesn't know this new reason (12) at the moment. You have to use command to configure this mode too. For example, "i2cset -y 0x01 0x08 49 0x81" will make sure to wake up the device no longer than 1 day. 

@admin Thank you very much, that is awesome!🤩 

@admin I had issues with the raspberry pi constantly rebooting. According to the amended update on firmware rev7 i assume that you had similar problems? I am testing the new firmware now, do you have any inputs?

@eagleshot had it finished the boot? Or the power was cut during the boot?

The amended Rev 7 firmware adds ~3 min delay for performing the first low voltage detection. This will give some time for rush fixings if the low voltage threshold was not properly set.

The pi itself finished booting and shut down properly, the only thing is that it may not properly communicate its state since i shut down my systems manually via „shutdown -h 0“ to save as much power as possible. I also saw the power being briefly cut on the 4G-module that is connected to the pi. The startup reason was listed as low voltage recovery, which is strange, since the system was connected to a lab power supply. Hardware-wise this exact system (including a 4G-module) has previously been running for several months without this issue, which was very strange. The only thing i did was update the daemon software, firmware of the witty pi as well some other changes to the software running on the pi itself. Do you think this could be connected to how i shut down the pi and know why this only occurs now? I will continue to investigate but couldnt really pin-point the issue so far.

Also what do you mean by the terminology „rush fixing“ - i didnt really understand that part.

With certain configuration, low voltage recovery could even happen when powering with lab power supply. What are your settings on these registers?

• I2C_CONF_LOW_VOLTAGE
• I2C_CONF_RECOVERY_VOLTAGE
• I2C_CONF_IGNORE_POWER_MODE
• I2C_CONF_IGNORE_LV_SHUTDOWN

About "rush fixings/repairs": if your device is powered with battery, and you set the recovery-voltage threshold just a little bit higher than the low-voltage threshold, or you just set the low voltage threshold to a rather high value, there is chance that the battery voltage drops under the low-voltage threshold during the boot. If the device has been remotely deployed, you won't have a chance to fix that because the device will be shutdown during the boot. With the newly introduced 3-minute protection, it will be possible to access the device and correct the configuration within this time window.

@admin After newly installing everything (OS, Witty Pi daemon and new firmware v7) the problem went away and so far didn't occur anymore. The weird thing is, that it happened irregardless of these 4 settings. It happened in multiple different configuration of those settings, e.g. when both low- and recovery voltage were set and the rest off.

After that, the guaranteed wake mode worked as expected in my first tests. 🤩  Just to confirm my configuration as I only tested it with a shorter duration so far - does "i2cset -y 0x01 0x08 49 0x82" set it to wake up at least every two days?

@eagleshot Yes,  "i2cset -y 0x01 0x08 49 0x82" will set 2 days, alternatively you may also use  "i2cset -y 0x01 0x08 49 0x30", which will set 48 hours.

Hi @admin @eagleshot can you help me out with how I2C_CONF_GUARANTEED_WAKE  works ?

// 8 bits for guarenteed wake configuration.
// bit-0~6: guaranteed wake duration (0~127)
// bit-7: guaranteed wake duration unit (0=hour, 1=day)

Does this mean if bit 7 is 1 and bits 0-6 are say decimal 10 it will wake once a day for 10 days ? And the time of the wake is when the register was written. So if I write at 8am it wakes at 8am.

Or have I totally got that wrong

Thanks

@mhornsby if you set bit 7 to 1, and write decimal 10 to bit 0-6, that configuration will garentee to wake up your device once within 10 days. It is not accurate, it could wake up the device on the 8th or 9th day, at any hour.

The way it works, is to add up a counter, and wake up the device when the counter exceeds the preset threshold. That counter starts counting after your Pi is off. It counts once per second but it is not very accurate, so please do not rely on it. It is there as a remedial measures, when some configurations were not well set, you get the chance to remotely access the device to fix those.