Notifications
Clear all
Topic starter
18/09/2025 10:14 am
Hello,
I am switching over from email to the community forum, as answers to these questions might be interesting to other users. I have been testing the device in different operational modes. Overall, I like many things about it. Some questions remain, though.
1) Firmware
Is 0179 still the latest firmware around? I saw some mentions of 0180+ firmware being released soon and wonder what will change and when it will become available. Changing the setup script to work with 0179 worked fine, that's not an issue.
2) Magic Switch
The biggest headaches came from trying out the Magic Switch. The problematic behavior is happening if Magic Switch is enabled and OFF and the device gets power from EPR again. I know this is not a supported operational state, but it could happen if users are careless, and therefore needs to be tested. Since Magic Switch is always shutting the device down as soon daemon is running and EPR power is always waking it up again as soon as it sleeps, the device ends up in an endless rebooting loop.
In my opinion, a different behavior would be more useful: The reboot by detected EPR power should not happen at all, when Magic Switch is enabled and the switch is turned OFF, giving the switch true master functionality, avoiding the fight between switch shutdown and EPR reboot. I could not really find a reason yet for not implementing the switch like this. Is the current behavior intentional?
I temporarily tried isolating the installed pogo pins, but this led to other trouble of not being able to wake up the Pi anymore. I ended up leaving the pogo pins connected and just disabling the switch, leaving it OFF and using the FSSD button for shutdown and wakeup only. This works well so far, so it’s not a big issue, but the switch’s behavior is useless to me at the moment.
3) LED Mapping
The USR LED mappings did not work yet. I can set the USR LEDs manually in registers 0x09 or 0x0a, to get a constant 'system active' LED without problem. But mapping of e.g. SYS or CHG LED using registers 0x17 or 0x18 does not work yet, USR LED will just stay in the manually set state. Is the mapping already fully implemented in the 0179 firmware? Of course I could just solder an external LED to the SYS or CHG LED pads instead of mapping. But if mapping is implemented, I would prefer to set it up correctly to stay flexible.
4) FSSD Behavior
Finally, is there a way to detect the Pi's shutdown state dynamically instead of setting a hard-coded FSSD duration? I imagine the following behavior: FSSD is pressed, Pi powers down safely, and then PIco immediately cuts power, once Pi is detected as down, without waiting for a timer to run out. I have set the FSSD timer to short 8 seconds now to get a pretty quick reaction, but I can not be sure that Pi is always shutting down this fast, therefore this could lead to issues. Is there something I overlooked or misunderstood in the concept?
Thank you for your support!
---------------------------------------------------------------
UPS PIco Firmware..........................: 0179
UPS PIco Bootloader........................: 41
UPS PIco PCB Version.......................: 42
0(b) pico_state...........0x00 : 0x00
1(b) Battery Runtime......0x01 : 0x0f (15 min)
2(b) RS232 Rate...........0x02 : 0x00 (PICO_OFF RPI_OFF)
3(b) rpi_hold_on..........0x03 : 0x00
4(b) pico_rpi_route.......0x04 : 0x00
5(b) sta_timer............0x05 : 0xff (OFF)
6(b) enable5V.............0x06 : 0x00 (OFF)
7(b) battype..............0x07 : 0x49 (Battery Li-Ion 'I')
8(b) setA_D...............0x08 : 0x00
9(b) led_green............0x09 : 0x00 (OFF)
10(b) led_blue............0x0a : 0x01 (ON)
11(b) relay...............0x0b : 0x00 (OFF)
12(b) bmode...............0x0c : 0x00 (BUZZER OFF)
13(w) bfreq...............0x0e : 0x0000 (0 Hz)
14(b) bdur................0x10 : 0x00
15(b) fmode...............0x11 : 0x03 (FAN AUTO HARD)
16(b) fspeed..............0x12 : 0x64 (100)
17(b) fttemp..............0x13 : 0x53
18(b) fsstep..............0x14 : 0x05
19(b) LEDs_ON/OFF.........0x15 : 0x01 (ON)
20(b) on_the_go...........0x16 : 0x00
21(b) map_led_green.......0x17 : 0x00
22(b) map_led_blue........0x18 : 0x00
23(b) chg_ctrl............0x19 : 0x01
24(b) fssd_duration.......0x1a : 0x08
25(b) rpi_OFF_time_reg....0x1b : 0x05
26(b) ad_corectionf.......0x1c : 0x00
27(b) Scheduler_Sel.......0x1d : 0xff
28(b) BS_action_time......0x1e : 0x00
29(b) BS_inaction_time....0x1f : 0x00
30(w) BS_Start_time.......0x20 : 0x0000
31(b) BS_multipier........0x22 : 0x00
32(b) BS_RUN..............0x23 : 0x00
33(b) SAS_number..........0x24 : 0x00
34(b) SAS_run.............0x25 : 0x00
35(b) ps_checking_time....0x26 : 0x1e
36(b) BAT_level_report....0x27 : 0x05
37(w) SC_level_start......0x28 : 0x0000
38(b) debug_mode..........0x2a : 0x00 (PICO_OFF RPI_OFF)
39(blk) RS232_data........0x2b : 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
18/09/2025 11:03 am
Hi,
I am switching over from email to the community forum, as answers to these questions might be interesting to other users. I have been testing the device in different operational modes. Overall, I like many things about it. Some questions remain, though.
I will try to answer as much a s possible.
1) Firmware
Is 0179 still the latest firmware around? I saw some mentions of 0180+ firmware being released soon and wonder what will change and when it will become available. Changing the setup script to work with 0179 worked fine, that's not an issue.
It is ready a long time already, just adding and adding new features before release it. We ware also overloaded with the new M.2 – UPS and Power Management HAT as have had some production problems.
I know, about the script, I was proposing to change it, expected final release of the is about the max next month.
We ware also thinking to release the source code of it to publicity, but form other side, people need to have paid compiler to compile it (it is not made with free one) so not so easy to other to work on that. So, postponed it for now.
The biggest headaches came from trying out the Magic Switch. The problematic behavior is happening if Magic Switch is enabled and OFF and the device gets power from EPR again. I know this is not a supported operational state, but it could happen if users are careless, and therefore needs to be tested. Since Magic Switch is always shutting the device down as soon daemon is running and EPR power is always waking it up again as soon as it sleeps, the device ends up in an endless rebooting loop.
2) Magic Switch
The biggest headaches came from trying out the Magic Switch. The problematic behavior is happening if Magic Switch is enabled and OFF and the device gets power from EPR again. I know this is not a supported operational state, but it could happen if users are careless, and therefore needs to be tested. Since Magic Switch is always shutting the device down as soon daemon is running and EPR power is always waking it up again as soon as it sleeps, the device ends up in an endless rebooting loop.
I check it and update the firmware according to your idea. Open and happy to implement any idea people have.
In my opinion, a different behavior would be more useful: The reboot by detected EPR power should not happen at all, when Magic Switch is enabled and the switch is turned OFF, giving the switch true master functionality, avoiding the fight between switch shutdown and EPR reboot. I could not really find a reason yet for not implementing the switch like this. Is the current behavior intentional?
OK. I will implement that.
3) LED Mapping
The USR LED mappings did not work yet. I can set the USR LEDs manually in registers 0x09 or 0x0a, to get a constant 'system active' LED without problem. But mapping of e.g. SYS or CHG LED using registers 0x17 or 0x18 does not work yet, USR LED will just stay in the manually set state. Is the mapping already fully implemented in the 0179 firmware? Of course I could just solder an external LED to the SYS or CHG LED pads instead of mapping. But if mapping is implemented, I would prefer to set it up correctly to stay flexible.
1. You do not need to solder external LED. The external LED is in parallel with the internal one.
2. As far I know the mapping is working I check it next days when setup the workbench for possible bugs
4) FSSD Behavior
Finally, is there a way to detect the Pi's shutdown state dynamically instead of setting a hard-coded FSSD duration? I imagine the following behavior: FSSD is pressed, Pi powers down safely, and then PIco immediately cuts power, once Pi is detected as down, without waiting for a timer to run out. I have set the FSSD timer to short 8 seconds now to get a pretty quick reaction, but I can not be sure that Pi is always shutting down this fast, therefore this could lead to issues. Is there something I overlooked or misunderstood in the concept?
Yes. Understood. If you power the system via PIco power input, you can monitor the current consumption, so can be implemented quite easy. If you are powering the system only via Raspberry Pi USB-C then the only point of interacting with PIco is the I2C so when Raspberry Pi is "dying" can not be monitored.
The only solution could that we will checking the I2C during this process and if/when stop then start time counting for power cutting.
Please comment them
My Best Regards
PiM
