Does the cubesatsim support a "full-size" Pi board as a drop-in replacement of the Pi Zero?

[Opubose]

For my research and testing, I wish to swap out the Pi Zero that is intended for use with the cubesatsim with a more performant and capable Pi 4 (or 5) board. Is there anything I need to keep in mind with respect to OS or hardware compatibility, considering that I will flash the full-size Pi's SDcard with the same image as the Pi Zero and use an extra GPIO stacking header to connect to the battery board?

[alanbjohnston]

Hi Agastya,

The CubeSatSim software is based on Debian 11 Bullseye and should run on a Pi 3B or 4. It won't run on a Pi 5 which requires Debian 12 Bookworm. The code could be ported to Bookworm - there's just a lot of annoying Python, camera, and configuration issues to sort through. I tested the existing SD card image on a Pi 4 and it seems to work! I couldn't get a decode on APRS packets for some reason, but they sounded correct. The other modes and rpitx seemed to work, along with the Pico serial communication and Command and Control. Note that to save power, the software only uses one CPU (the maxcpus=1 in /boot/cmdline.txt forces this). So you could remove this to get more CPU processing on the Pi Zero 2 (which has 3 CPUs) or the 3B or 4.

The CubeSatSim hardware is designed to run directly on the battery voltage, which is in the range 4.1 V to 3.5 V for three NiMH cells. This battery voltage powers the Raspberry Pi through GPIO pins 2 and 4, which are nominally 5 V. The Pi Zero, Pi Zero W, and Pi Zero 2 all run fine with this voltage between 3.3 V and 5 V. The Pi Zero generates the regulated 3.3 V which powers everything except the FM transceiver module, which also runs at the battery voltage.

This is a problem for a Pi 3B or Pi 4 which needs to run on 5 V. These Pi's all complain if this voltage drops by even 0.1 V or so. This is why many USB-C power supplies designed for the Raspberry Pi actually output more the 5 V (some of them even exceed the USB voltage maximum) so that the Pi never sees a voltage below 5 V and so doesn't complain.

This means that a Pi 3B or Pi 4 plugged into the board stack where the Pi Zero is usually plugged in can't be powered through the battery pack. It also can't be powered through the USB-C port on the Main board unless you bypassed the two series diodes D1 and D4. Even then, it might not work unless you used a Raspberry Pi power supply USB-C that supplied a higher than 5 V. Without diodes D1 and D4, the charging voltage and current would be too high for the batteries.

Without a Battery board (or with the JST connector unplugged to the Battery board), you can power the Pi 3B or Pi 4 directly, and it will then power the rest of the CubeSatSim through GPIO pins 2 and 4, and everything should work. This is how I tested it.

If you really needed to still run it on batteries, you could try either a Boost Converter circuit between the battery and the GPIO that would boost the 3.5 V to 4.1 V up to 5 V (or a little higher). The other thing you could try is a battery pack with four NiMH cells - this would give you a battery voltage above 5 V which might power a Pi 3B or Pi 4. I have tested this in the past with a Pi Zero and it works, but charging the batteries will require some kind of charging circuit.

Of course, the Pi 3B or Pi 4 wouldn't fit in the frame without some modifications, either.

Good luck, and let us know if you get this working!

Alan

[Opubose]

Thanks for the detailed response Alan! I used it to troubleshoot some problems I was having with the Pi's boot process. Last night, I tried connecting both the Pi 4 and the Pi 5 to the sim. As you said, the Pi 5 wasn't working at all. I did manage to get the Pi 4 working with the sim and it gave me full shell access. However, when I tried to recreate the process today, the Pi 4 shut down right after dropping me into the shell, even though the satellite itself was still transmitting RF as per the blue LED. I tried to power the Pi through various ways:

• With the USB-C connected to the main board and all the JSTs intact
• With the USB-C connected directly to the Pi board and the battery board JST removed
• With the USB-C connected directly to the Pi board and the battery board JST intact

However, I am not able to get shell access on the Pi through any of these means. As soon as it drops me into the shell, I get 2 rfkill warnings, immediately after which the Pi shuts down. What could be going wrong?

[alanbjohnston]

I would use this setup:

With the USB-C connected directly to the Pi board and the battery board JST removed

and I would flash a new SD card from the image.

I suspect yours is corrupted.

Ala.

[Opubose]

I realized what the problem is. It's not that the pi 4 shuts down, because its onboard LEDs are flashing just fine. It's that, for some reason, the pi's HDMI output turns off right after login (which led me to falsely believe that the pi shut down). I could connect to the pi via SSH from a different computer while it was attached to the board stack and power it with USB C directly (battery board disconnected). Do you have any theories as to why I lose HDMI output?

[alanbjohnston]

Uncommenting the line

hdmi_force_hotplug=1

from /boot/config.txt usually fixes these types of HDMI issues.

Note that to use the Raspberry Pi Graphical User Interface, you will need to use the very latest iso image and also use sudo rasp-config to enable boot to Desktop. The default is to boot to command line.

Alan

[Opubose]

Thanks for your help on this matter! I noticed that the rate of logging of sensor data in /dev/serial0 is far slower with the pi 4 as opposed to with the pi zero. Why would that be? Could this have something to do with you not being able to decode APRS packets?

[alanbjohnston]

Can you copy and paste a few pages of the main log so I can see it? The output of this command:

CubeSatSim/log

Alan

[Opubose]

Sorry for the delay! I was out on break. Here are the last 10,000 or so lines of the log file. I hope this is helpful!
cubesatlog.txt

[alanbjohnston]

Thank you for posting the log file with the CubeSatSim/log command - very helpful!

I looked it over and I don't see any delays in recording payload sensor data. It happens about every 4.6 seconds most of the time. You can find each instance by searching for START_FLAG

I do, however, occasionally see a longer than expected loop time. This would result in the payload sensor data being read less frequently. For instance, at timestamp 18:17:11 you see:

Aug 21 18:17:10 cubesatsim-pi4 cubesatsim[1277]: Socket_send!
Aug 21 18:17:10 cubesatsim-pi4 cubesatsim[1277]: socket send 1 6888 ms bytes: 460082
Aug 21 18:17:11 cubesatsim-pi4 cubesatsim[1277]: START_FLAG_OK BME280 29.45 988.02 212.20 28.93 MPU6050 -0.41 0.35 3.16 -0.13 0.00 0.89 GPS 0.0000 0.0000 0.00 TMP 24.00_END_FLAG Payload length: 109
Aug 21 18:17:11 cubesatsim-pi4 cubesatsim[1277]: get_payload_status: 1
Aug 21 18:17:11 cubesatsim-pi4 cubesatsim[1277]: INFO: Battery voltage: 3.96 V Threshold 3.50 V Current: 0.0 mA Threshold: 100.0 mA
Aug 21 18:17:11 cubesatsim-pi4 cubesatsim[1277]: Start sleep 2283725 Sleep period: 0 while period: 4617
Aug 21 18:17:11 cubesatsim-pi4 cubesatsim[1277]: ++++ Loop time: 8.378 sec +++++

Notice the Loop time of 8.4 seconds instead of 4.6 seconds. The reason seems to be a 6.9 second delay in sending data over TCP where it says socket send 1 6888 ms I see these TCP delays about every minute or so at the start of the log file. This might be caused by another Linux process running in the background and using the CPU. If you watched with the top command, you might be able to see this application running (you will need to Control-C out of top).

What made you think that there were delays in the payload sensor data? Was it from looking at cat /dev/serial0 perhaps? This also might be interrupted by another Linux process.

What do you see in the timestamps in this file: cat /home/pi/CubeSatSim/telem.txt which logs the payload sensor data received?

Alan

[Opubose]

After checking the output of telem.txt, I realized that I was mistaken. The sensor data is indeed issued every 4 seconds on average. As you said, my earlier misconception was from looking at /dev/serial0, because I thought that data wasn't being written to it at a sufficiently high rate.

As per the top output, I see that cubesatsim, sendiq, python3, and multiple csdr processes are the ones that take up the most CPU usage. The others are standard background linux processes.