Hi,

Posted by: @s3000

↑

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.

Posted by: @s3000

↑

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.

Posted by: @s3000

↑

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.

Posted by: @s3000

↑

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.

Posted by: @s3000

↑

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.

Posted by: @s3000

↑

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

Posted by: @s3000

↑

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

Posted by: @piadmin

↑

I will try to answer as much a s possible.

Thank you very much for your fast and detailed answer.

Posted by: @piadmin

↑

people need to have paid compiler

Which one?

Posted by: @piadmin

↑

I check it and update the firmware according to your idea. Open and happy to implement any idea people have.

Posted by: @piadmin

↑

OK. I will implement that.

I am impressed. Did not know if there was any reason before to not change it. But if you could redesign this functionality as described, it would be awesome. Then I could enable Magic Switch as true master. Only if device is switched on by switch it boots, charges etc. but if switch is OFF it just doesn't do a thing. There could be the state where switch is ON, battery runs low, pi shuts down safely but device looks like being ON to the user if he just looks at the switch state, even though it has no power.  To me this is fine if waking up the Pi by feeding EPR and maybe setting switch OFF - ON quickly is possible. Or only by feeding EPR. EPR just should not trigger boot if switch is OFF. 

Posted by: @piadmin

↑

You do not need to solder external LED. The external LED is in parallel with the internal one.

Don't fully get what you mean. I meant soldering an external (housing) LED directly to the SYS or CHG pads IF mapping to one of the USR LED pads does not work. Would prefer the mapping and soldering to USR LED pads. Soldering the external LED I will need to do in any case.

Posted by: @piadmin

↑

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.

I won't be powering the system via Pi USB at all. Only PIco EPR and BAT are connected, so your suggested approach of monitoring current consumption could actually work.

Thanks a lot for your support!

@s3000 

Hi,

Posted by: @s3000

↑

Thank you very much for your fast and detailed answer.

🙂

Posted by: @s3000

↑

Which one?

www.ccsinfo.com

PCD version

The most compact and fastest, even better that Microchip.

https://www.ccsinfo.com/compilers.php

We have the full one, but as I see now there is a limited version low cost, limited to 12 MCUs

Posted by: @s3000

↑

I am impressed. Did not know if there was any reason before to not change it. But if you could redesign this functionality as described, it would be awesome. Then I could enable Magic Switch as true master. Only if device is switched on by switch it boots, charges etc. but if switch is OFF it just doesn't do a thing. There could be the state where switch is ON, battery runs low, pi shuts down safely but device looks like being ON to the user if he just looks at the switch state, even though it has no power.  To me this is fine if waking up the Pi by feeding EPR and maybe setting switch OFF - ON quickly is possible. Or only by feeding EPR. EPR just should not trigger boot if switch is OFF. 

The limitation in the hardware is physics

The limitation in the software is human brain

So whatever you imaging if supported by physics can be done

Posted by: @s3000

↑

Don't fully get what you mean. I meant soldering an external (housing) LED directly to the SYS or CHG pads IF mapping to one of the USR LED pads does not work. Would prefer the mapping and soldering to USR LED pads. Soldering the external LED I will need to do in any case.

The USR LEDs are 2. The LEDs are on the PCB but also their pins are routed to connector. These connector Pins are in parallelly with on board USR LEDs. With mapping you can map behaviors of "internal" LEDs (i.e. SYS, BAT etc) to the USR LEDs so then to external soldered.

If you are building your own device that contains Raspberry Pi and PIco, and i.e. you would like to see the BAT or SYS externally, then you connect cable to the USR LEDs place them externally of the case, and map the BAT and SYS functionality to them. 

Hope explain it properly

Keep me informed

Best Regards

PiM

Posted by: @piadmin

↑

https://www.ccsinfo.com/compilers.php

We have the full one, but as I see now there is a limited version low cost, limited to 12 MCUs

Thanks for sharing! Going open source could change a lot regarding firmware customizations in general. It could also help to detect bugs faster and could save some headaches maybe 😀 I am really not saying that your hardware is buggy. But here and there a few checks could do the trick, e.g., regarding synchronisation of manual, firmware and scripts. I appreciate your quick support, though.

Posted by: @piadmin

↑

The limitation in the hardware is physics

The limitation in the software is human brain

The limitation of quality is testing 😎 I think I found one to mention.

I assume some confusion on register numbers in the script and in the manual: execution of status script shows Green LED mapped to SYS and Blue LED unmapped, while setup script shows 0x17 set to 0x00 and 0x18 set to 0x01, telling us Green LED is not mapped and Blue LED is mapped to SYS.

Status script 1.4hv4.0:

User LED Green Activity....................: OFF
User LED Blue Activity.....................: OFF
Green LED mapping setup....................: SYS
Blue LED mapping setup.....................: none

Setup script 2.6hv4.0, no registers changed in between:

+----------------------------------------------------------------------------------------------------------------------+
|Number| Register |Address|Value| |Number| Register |Address|Value|
+----------------------------------------------------------------------------------------------------------------------+
0(b) pico_state...........0x00 : 0x00 | 20(b) on_the_go...........0x16 : 0x00
1(b) Battery Runtime......0x01 : 0x0f (15 min) | 21(b) map_led_green.......0x17 : 0x00
2(b) RS232 Rate...........0x02 : 0x00 (PICO_OFF RPI_OFF) | 22(b) map_led_blue........0x18 : 0x01
3(b) rpi_hold_on..........0x03 : 0x00 | 23(b) chg_ctrl............0x19 : 0x01
4(b) pico_rpi_route.......0x04 : 0x00 | 24(b) fssd_duration.......0x1a : 0x08
5(b) sta_timer............0x05 : 0xff (OFF) | 25(b) rpi_OFF_time_reg....0x1b : 0x05
6(b) enable5V.............0x06 : 0x00 (OFF) | 26(b) ad_corectionf.......0x1c : 0x00
7(b) battype..............0x07 : 0x49 (Battery Li-Ion 'I') | 27(b) Scheduler_Sel.......0x1d : 0xff
8(b) setA_D...............0x08 : 0x00 | 28(b) BS_action_time......0x1e : 0x00
9(b) led_green............0x09 : 0x00 (OFF) | 29(b) BS_inaction_time....0x1f : 0x00
10(b) led_blue............0x0a : 0x00 (OFF) | 30(w) BS_Start_time.......0x20 : 0x0000
11(b) relay...............0x0b : 0x00 (OFF) | 31(b) BS_multipier........0x22 : 0x00
12(b) bmode...............0x0c : 0x00 (BUZZER OFF) | 32(b) BS_RUN..............0x23 : 0x00
13(w) bfreq...............0x0e : 0x0000 (0 Hz) | 33(b) SAS_number..........0x24 : 0x00
14(b) bdur................0x10 : 0x00 | 34(b) SAS_run.............0x25 : 0x00
15(b) fmode...............0x11 : 0x03 (FAN AUTO HARD) | 35(b) ps_checking_time....0x26 : 0x1e
16(b) fspeed..............0x12 : 0x64 (100) | 36(b) BAT_level_report....0x27 : 0x05
17(b) fttemp..............0x13 : 0x53 | 37(w) SC_level_start......0x28 : 0x0000
18(b) fsstep..............0x14 : 0x05 | 38(b) debug_mode..........0x2a : 0x00 (PICO_OFF RPI_OFF)
19(b) LEDs_ON/OFF.........0x15 : 0x01 (ON) | 39(blk) RS232_data........0x2b : 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

From the manual, 0x18 and 0x19 handle the mapping, not 0x17 and 0x18:

sudo i2cset -y 1 0x6b 0x18 0x01 (0b00000001) Mapping of System SYS LED on the User Green LED
sudo i2cset -y 1 0x6b 0x19 0x02 (0b00000010) Mapping of System BAT LED on the User Blue LED

But the manual also mentions the Embedded Battery Charger as register 0x19, as in the setup script.

There is actually also some confusion on the hardware itself as the Green LED pad paralleled to U2 is labelled LR (means red?), while Blue LED pad paralleled to U1 is labelled LG (means green?).

I tried setting each register 0x17, 0x18 and 0x19 to 0x01 (all possible registers I know for mapping). I tried additionally with 0x09 and 0x0a set to either 0x00 or 0x01, as I don't know if this could affect the mapping? In none of those cases I get any mapping of the USR LEDs to the SYS LED, e.g. a blinking USR LED. I can only set USR LED to constantly ON or OFF.

Do you agree regarding the confusion or is there any wrong thinking from my side?

And more important: How would I set a mapping correctly in 0179 firmware, let's say mapping USR LED blue (labelled U1 / LG) to SYS?

Thanks again!

status script:

def map_led_blue():
time.sleep(0.1)
data = i2c.read_byte_data(0x6b, 0x17)

def map_led_green():
time.sleep(0.1)
data = i2c.read_byte_data(0x6b, 0x18)

vs setup script:

def map_led_green():
time.sleep(0.1)
return i2c.read_byte_data(0x6b, 0x17)

def map_led_blue():
time.sleep(0.1)
return i2c.read_byte_data(0x6b, 0x18)

Hi,

I will answer in details tomorrow evening, after setting of the workbench.

My Best Regards

Ioannis

Hi,

I made  a simple test of mapping and it is working well

See attachment.

sudo i2cset -y 1 0x6b 0x18 0x01 (0b00000001) Mapping of System SYS LED on the User Green LED

After that command the SYS LED is mapped to Green LED.

As also in the manual page 94

My Best Regards

PiM

Hi Ioannis,

Thank you for testing the mapping yourself. Unfortunately, it doesn't help me much, as on my board, this command doesn't change the LED behavior at all.

To illustrate the register confusion in a more visual overview, please see the attachment. As the setup script writes the values, I would assume it is the point of truth. Then

• 0x17 is USR LED Green mapping,
• 0x18 is USR LED Blue mapping, and
• 0x19 is the charger. 

My assumption might be wrong, and the setup script could have a swapped naming of mapping registers. Did you get a green blinking LED when mapping to SYS in register 0x18 via direct I2C command? Then either our boards, the firmware, or our scripts are different, and the setup script I am using would have swapped registers.

I am using this setup:

pico_status1.4_hv4.0.py
pico_setup2.6_hv4.0.py
ups_pico4_main_Firmware_0179_20062024_.hex
UPS PIco Bootloader : 41
UPS PIco PCB Version : 42

Which values do you set at registers 0x09 (green LED) and 0x0a (blue LED) when you activate mapping, or does it not matter for the mapping if those registers are set to ON or OFF?

In register 0x15 I have the LEDs generally set to ON. I tried all possible setting combinations regarding LEDs and mapping via the setup script and via direct I2C commands. I can only set single LEDs ON or OFF in 0x09 and 0x0a, but can't map them on my board. Of course the registers show the bits set for mapping correctly, but the LEDs just don't behave accordingly.

LED Mapping is not a crucial functionality, but it would be nice to have. I am wondering why the behavior is working on your board, while on mine, this functionality is not available. Do you maybe have any ideas why this is the case?

Thank you.

Hi,

Posted by: @s3000

↑

Thank you for testing the mapping yourself. Unfortunately, it doesn't help me much, as on my board, this command doesn't change the LED behavior at all.

yes, I see the green is working the blue not

Must be a bug, checking and back to you soon

BR PiM

Hi,

Thanks for uploading the video. I am not able to reproduce the mapped state the video is showing, neither using green nor blue. The mapping does not have utmost importance as it is rather a nice-to-have feature, not a strict requirement.

Posted by: @piadmin

↑

Must be a bug, checking and back to you soon

Thanks again for your awesome support 😊 

Posted by: @piadmin

↑

OK. I will implement that.

Will this Magic Switch behavior already be shipped in the upcoming firmware update?

Best regards,

s3000

@s3000 

Hi,

Yes to all !

Hope next week to release it

What firmware do you have ?

BR PiM

Posted by: @piadmin

↑

Yes to all !

Hope next week to release it

Nice! Looking forward to testing it.

Posted by: @piadmin

↑

What firmware do you have ?

Posted by: @s3000

↑

pico_status1.4_hv4.0.py
pico_setup2.6_hv4.0.py
ups_pico4_main_Firmware_0179_20062024_.hex
UPS PIco Bootloader : 41
UPS PIco PCB Version : 42

Have a nice evening.

BR s3000