Question about battery voltage

[Boovtech]

I would like to ask a question about battery voltage. When my cubesat simulator sits on the USB charger it only comes up to about 4 volts. When I run it in SSTV mode it seems to like to reboot after it has sent one or two pictures, as if that high duty cycle of transmitting picture data is forcing it to shut down, but then it starts back up and the cycle starts over. When it's plugged in it does fine in SSTV mode. I did get it up at around 4.3 volts once. I need to do some more experiments putting it in the sun and seeing how high I can get it to charge, but only 4 volts after sitting in charge for days seems low.

Please let me know if there is something amiss here.

Thanks
73
Virginia NV5F

[W7DGP]

Let me take a shot at an answer to your battery voltage questions. The batteries or (cells actually) are NIMH AA size that have a nominal fully charged voltage of 1.2v. Three of them in series being fully charged would be 3.6v. The battery management chip, U9 on the main board, NiMH CN3085 3s charger will allow them to charge up to about 1.4v. That's a bit overcharged but really the max they should be charged up to. At 1.4v each, the total is 4.2v. The 4.3v limit you are experiencing is due to the programming of the U9, CN3085.
I believe the best long term 100% SOC (State of Charge) is 3.6v. Also, it is a characteristic of NiMH (and NiCads too) to self-discharge a bit of that overcharge. In other words, while supplying power at 4.3v, it will discharge an additional bit to get down to 3.6v.
My question has been: is there telemetry for the satellites SOC? I want to see a %age reported in the telemetry.
About the SSTV mode, my sat will send pictures all day or until the batts get low. Tomorrow (9/29) I'll try some more SSTV and see if I can duplicate your problem. It could be, as you observed, SSTV is a power-hungry mode.
73, Larry W7DGP

[W7DGP]

Hi Virginia,
After posting the reply, I wondered why there was no good NiMH website for engineering information. It was all sales-y but no meat, no math, no chemistry and no graphs, etc. You know, the stuff EEs think they need. Well, here is my recommended link:
https://en.globtek.com/nimh-battery-safety-notes
Very meaty! The 10/c discharge rate for our cells is 20mA. Its a 2 Ah cell, right? The 10/c discharge curve shows flat from 1.25v to 1.18v. NiMH is an excellent choice for the cubesat sim. There's lots more info to digest about the amazing NiMH cell.
73, Larry

[W7DGP]

Running my cubesat, I find the SSTV, battery pack current is not much different from any of the other modes. I've been running it for about an hour.
73, W7DGP

[Boovtech]

Hi W7DGP

Thanks for doing that test. I'm not sure why mine reboots sometimes. Further investigation is needed.

Also thanks for the clarification on the batteries. I got it in my head that they should be 1.5 volt cells, so the voltages make perfect sense now. I'll run a few more tests to see if I can find some consistency. I don't seem to have the reboot issue on SSTV when I am hooked up to power.

I appreciate the help.

73
Virginia
NV5F

[W7DGP]

I haven't had the reboot problem. I did let it run for a few hours and ran down the battery pack. Running FSK, I watched battery volts steadily decline to 3.56 to 3.55 (was toggling) then it quit transmitting. There was no reboot - just quit. That's 1.18v per cell which is a discharged condition. I believe the 5v boost regulator drops out thus removing 5v to the Raspberry Pi. There is some voltage because I could see the red LED on the Pi was lit. The drop in battery pack volts was linear all the way down to the end. The rechargeable pack of NiMH cells fed to a boost regulator is an excellent design. I just inserted the RBF plug and charged it back up.
From you description, it does not reboot with the charger plugged in. The boost regulator isolates the Pi from the battery pack so I can't figure out how the Pi would "know" the charger is plugged in. Its like: what causes a Raspberry Pi to spontaneously reboot? Is the boost regulator removing 5v then coming back on line? That would cause a reboot. I have to think about this one. The upside of all this query is learning a lot more about the cubesat sim.
73, Larry W7DGP

[Boovtech]

Hi Larry,

You're right! All my unusual experiences along the way have caused me to know a lot more about this thing than if it had all gone perfect. I guess that's the point!

I ran my sim in SSTV mode on battery last night and also did not have the issue either. It did happen more than once before however I am willing to call it a fluke. I'll definitely keep an eye out for it in the future.

Thanks for testing it and investigating the issue. I really appreciate it!

73
Virginia NV5F

[Boovtech]

Hi All,

The reboot saga continues. I was demonstrating the sim at the Dallas ARC last night and it did it's reboot process in SSTV on a full charge. It had not done it the other night. I have been testing it this evening and it continued it's odd behavior. I restarted it in FSK DUV and it rebooted there also. I am running it right now to see if it behaves differently as the voltage on the batteries comes down. I'm not sure what the connection could be. Sometimes it will just shut down and NOT reboot.

I wonder if the SD card might be corrupted. I might see about replacing or reflashing it.

Does anyone out there have any other suggestions?

Thanks for any ideas.

73
Virginia
NV5F

[W7DGP]

If you look at spontaneous reboots as crashes then a reflash of the SD card sounds like a good idea. If the reboots are hardware related, then it could be power, overheating, etc. For that you need to look "inside" using: vcgencmd.
https://www.raspberrypi.com/documentation/computers/os.html#vcgencmd
Power seems pretty solid in the cubesatsim. The 5v regulator maintains the proper voltage on the Pi but vcgencmd will tell you if there was an undervolt that caused the reboot. Overheating could be a problem though it seems unlikely with the Pi being in a ventilated open frame. Again, vcgencmd will help.
It seemed to me to be a good idea to log into mine and take some baseline data to help troubleshooting this problem. So now I have my own problem! I can no longer log in as pi and use the standard password as I have in the past. I have been doing Raspberry Pi projects for years and this is the first time I've been locked out. I don't remember changing it. So, I can't use vcgencmd or even determine if it comes with the current OS. In my past working life, often put Unix workstations and servers in single user mode to recover or change root passwords. But the Pi? Time to get out a screwdriver and pull the SD card.

[Boovtech]

Thanks Larry,

I did some more testing last night and SSTV ran for about 30 minutes before the Pi rebooted (batteries were at about 3.79v). I ran DUV off and on after that to check voltage. When it got down to around 3.56v on the batteries SSTV would reboot about every 2 cycles and then it shut down. A time or two the Pi rebooted during DUV as well.
All told the sim ran for about 3 hours.

The card is easy enough to remove once I pull off the solar panel if needed. I am very unskilled at using the logs on the card to see what has transpired. Looks like I will be getting some opportunities to try it!

I will attach my graph of the spikes in current and drops on voltage. Seems that in DUV mode these should be smoother since it is transmitting continually.

I have a spare card. I can flash and stick in there and see what happens without having to erase this one. I might do that and see what happens.

Thanks for the advice.

73
Virginia

[W7DGP]

A new flash of the software would be a good test even with all the rebuilding you have to do.
I finally remembered my cubsat's password. It is now documented as well. I tried the vcgencmd with a number of parms to create a baseline you can use to compare. I'll copy them below:
pi@cubesatsim:~ $ vcgencmd measure_temp
temp=33.6'C
pi@cubesatsim:~ $ vcgencmd get_throttled
throttled=0x0
pi@cubesatsim:~ $ vcgencmd measure_clock arm
frequency(48)=1000000000
pi@cubesatsim:~ $ vcgencmd measure_clock core
frequency(1)=187500000
pi@cubesatsim:~ $ vcgencmd measure_clock isp
frequency(45)=0

Measure temp checks for overheated
get_throttled checks for undervolt, undercurrent and high temp hardware crashes. 0x0 means no hardware crash
The 3 clocks verify that the software does not overclock any processes.
Try it and let me know.
73, Larry W7DGP

[W7DGP]

Oh, I forgot this. From your graphs, it looks like the 5v regulator is working well. I don't see any dropout of the 5v that would cause a reboot. However, 3.56v is 1.18 volts per cell. This would be considered a discharged battery pack. The boost regulator will still output 5v but the supplied current will drop. The graph will be fine, however the Pi will suffer an undercurrent condition and may reboot as a result. A lot of this has to do with the problem many people have been having powering a Raspberry Pi with a standard 5v USB phone charger. They all manage to output 5v but the output current varies wildly and may not adequately power the Pi. The Pi 4 is especially particular in this regard. We're using a Pi Zero W and it's not all that particular, but it still needs the minimum amount of current to operate.
73, Larry
(Also, I have no idea why part of my reply above has large bold type.)