your script show different values from pimodules provided status script

[RTLflat]

this is the back to back output of pico_status.py and yours. why am i seeing such different values?

pi:~/rpi-ups-pico $ sudo python ~/Downloads/pico_status.py

    pico status V1.0

---

UPS PIco Firmware: 54 Powering Mode: RPi BAT Volatge: 4.2 V RPi Voltage: 4.99 V SOT23 Temperature: 26 C TO-92 Temperature: 00 C A/D1 Voltage: 0.0 V A/D2 Voltage: 0.0 V

---

pi@:~/rpi-ups-pico $ pico-i2cd -s -i pico_firmware_version 84 pico_mode 1 pico_battery_volts 4.320000 pico_host_volts 5.510000 pico_temperature_1_celsius_degrees 38 pico_temperature_2_celsius_degrees 0

[RTLflat]

although im thinking the pimodules script is correct.... psu supply shows 5.08v

[EffinMaggie]

Heya, thanks for reporting this!

What I'm reading out is what the PIco manual describes. Unfortunately the manual isn't very clear about data formats, and plain wrong in other places (e.g. GPIO pin assignments) so there was a bit of guesswork involved. Since I didn't have Python installed, I couldn't run this back-to-back to verify, and the main goal was to get the buttons on the PIco to work as an input device (which reportedly works fine).

The two things it's reading out correctly is the firmware version and the power mode: the firmware version is actually 0x54 (in hex), and this is just displaying it in decimal (which is 84) and the power mode is 1, meaning it's running off the mains connector on the Pi and not the battery (which is 2).

I'm further thinking that the remainder is actually in 4-bit BCD and I was reading it out in plain binary (for instance, that would make the temperature readout end up with 26 instead of 38). I'll fix that over the weekend.

[RTLflat]

No problem thanks for working on alternatives. Are the pins used determined by hardware or could they be moved around in you script to avoid conflicting with other hats?

And a side effect of this bug BTW appears that battery charges after initial boot but stop due to high reading

[ScrumpyJack]

The pins can be changed somewhat by pulling a cable from the jumper switch of pin to a different pin. FSSDR jumper is for GEN22 FSSDU jumper is for GEN27 So if you want to map pin22 to pin(x), open the FSSDR jumper and connect a cable between the out of the FSSDU jumper to pin(x) on your RPi

[EffinMaggie]

Uhm, I guess I could see that working... I haven't looked at the circuit but I'd assume it's wired in a way that makes that work. But it doesn't sound advisable and the firmware does expect the pins to be #22 and #27 :).

picod and pico-i2cd don't actually control the charging mode, though. The firmware just allows access to its own voltage readout, neither of them is writing that readout back to the firmware. The firmware would stop charging the battery if you wouldn't run picod nor picofssd.py - it needs either of them running to figure out if the Pi is booted and refuses to charge if it isn't. At the same time, pico-i2cd is not a substitute for picod, so only running pico-i2cd will not get your PIco to charge.

[ScrumpyJack]

Just as a note: "it doesn't sound advisable and the firmware does expect the pins to be #22 and #27" You're not changing the pins that the firmware uses, you're just cabling the from the HAT out to something else. They are still #22 and #27 when they go back to the HAT from the RPi. Perhaps you were talking about something else and I've got the wrong end of the stick.

[RTLflat]

well if they were unjumpered and cabled out to something else that would mean im using them for something else and making them unavailable for the pico to use right? meaning remapping different pins to replace as well as a firmware change. and i was actually wanting to free up the tx and rx pins in order to use alamode on top of pico. i think that means id have to set 2 other pins to ALT 3 function and jumper those in to replace rx/tx. most info ive found about this for rpi B+ tho not the 2 so id have to see if that changes things. i might be overthinking this though. its 330am and im bored and this damn alamode dont work on the pico

[EffinMaggie]

Well, not saying it won't work... I mean I hooked the RPi up to an Arduino and that went (mostly) fine, so... yeah :).

Speaking of, you could probably programme the Alamode to do the pulse train and then you wouldn't need picod. There's an example for that in the arduino/ dir. I'm not sure if the Alamode lets you access the GPIO pins like normal pins, but it probably should...

Anyway, you're going to lose at least one pin if you want to charge the battery and by default that's GPIO 22. GPIO 27 is what controls the shutdown, so you could reasonably just remove that jumper. Also the serial Tx/Rx jumpers could be removed if you don't need them, letting you access that from the Alamode.

If you don't want to charge the battery nor auto-shutdown, then you won't lose any pins. The PIco still works and will fail over to battery, but you'd have to charge the battery with some other device :).

[RTLflat]

thanks ya i just now decided to RTFM and noticed those pins are optional. -_-

[EffinMaggie]

Alright, fixed the issue in the OP.

magnus@salty-dog:~/projects/rpi-ups-pico$ /sbin/pico-i2cd -s -i
pico_firmware_version 84
pico_mode 1
pico_battery_volts 4.210000
pico_host_volts 5.480000
pico_temperature_1_celsius_degrees 38
pico_temperature_2_celsius_degrees 0

magnus@salty-dog:~/projects/rpi-ups-pico$ ./pico-i2cd -s -i
pico_firmware_version 84
pico_mode 1
pico_battery_centivolts 416
pico_host_centivolts 494
pico_temperature_1_celsius_degrees 26
pico_temperature_2_celsius_degrees 0

This seems to be more in line with what's probably in there. Note that I didn't change the parsing of the firmware version, as that is usually represented as "0x", which makes me think that this is actually in hex and not BCD and the output format is supposed to be compatible with Prometheus, which doesn't do hex numbers.