Migration To Debian 12

[Opubose]

I am interested in migrating the CubeSatSim image to support a more current Raspbian image, which uses Debian 12. The biggest issues I see are the usages of:

• The deprecated WiringPi library. I believe there's a newer unofficial fork of this.
• An old fork of rpitx
• Some old system configs in /boot/config.txt, which may be incompatible(?) with the newer Debian version. Will need to test this.

Am I missing anything? I think migrating to the newer Debian release will be a worthwhile endeavor.

[alanbjohnston]

I agree this is worthwhile to do. It has been on my ToDo list for a while, but it hasn't been a priority yet. But I'm happy to help work on it.

The other thing is Python. The environment needs to be added, and the packages will all be different and need code changes for them to continue to work.

Alan

[ve3ukw]

I've tried upgrading due to issues with Cameras - couldn't make IMX219 sensors working with bullseye.
couple of issues I ran into

• busio library is hard to find - installing adafruit-blinka solves this but you need to force it as newer versions of Python insist on using environments. I haven't investigated how venv could be used with services.
• the other issue is that GPIO27 is reserved in newer versions - this conflicts with TX LED and prevents transmit.py from working. There is an empty GPIO next to GPIO27 that could be used but I have yet to try that.
• The other issue is memory - 512MB is getting very tight. I tried on a Pico 2W. The order of install becomes critical. Start with an vanilla light OS, download/build libcamera first before installing anything else (need to add -j1 at the ninja state or you'll run out of memory)
• then download install the rest.
• the other bit that is way out of date is direwolf. Current release is 1.8. upgrading this is straight forward and can be done once everything is running.

This is as far as I've got.

Marcel

[alanbjohnston]

Hi Marcel,

Thanks for posting your progress so far!

For this issue: "the other issue is that GPIO27 is reserved in newer versions - this conflicts with TX LED and prevents transmit.py from working. There is an empty GPIO next to GPIO27 that could be used but I have yet to try that." According to this https://forums.raspberrypi.com/viewtopic.php?t=287928 , it might be possible to get around this: "If you really must use those two pins with RPi.GPIO then you need to change your code to use the Broadcom GPIO numbers and not the board/physical pin numbers."

I am working on a PCB that has jumpers so that PI_LED2 the blue LED can be connected to GPIO27 (pin 13 on the GPIO) or GPIO17 (pin 11 on the GPIO) which would avoid this problem in the future.

I'll keep you posted on this and perhaps we can test it out.

Alan

[ve3ukw]

re using Brodcom GPIO: haven't tried that. Not sure this is a good way forward though - someone might want to use a hat and then this change breaks detection.
I understand the issue of backwards compatibility - using a jumper (pad) is probably for the best. make GPIO17 the default but give "legacy" installs a chance to change over to the old GPIO27.
BTW: since you are reworking the PCB: any chance to increase the footprints of the SMD parts? I tried to use as many SMD parts as possible but some of the pads are mighty tiny. KiCAD has two pad sizes. Handsolder or "regular" for machine placements - a slightly larger pad would make soldering much easier.

Always game to test things - let me know when you have the design ready.

Thanks
Marcel