Hi everyone, I’ve been tinkering around and come up with an enhanced control tool for the AIO board. The reason is that the original tool doesn’t run on Kali Linux, so I made it compatible and expanded its functionality.
Displays at the top: Power, CPU, RAM, TEMP. Checkboxes to enable/disable GPS, LoRa, SDR, and USB (this was already present). I then added an autostart function for the devices so they are activated at boot. Autostart for the tool itself is handled through the GUI. There’s a start function for the services and an indicator showing whether they are already running or not. The small buttons behind the services are for restarting them. Everything can also be controlled via CLI. Reinitialization of GPS, LoRa, SDR and USB is also possible via CLI.
I’ve disabled the services and only start them when needed. Additionally, the devices are switched on and off once at startup. This means SDR is no longer active after booting. (Problem is: GPIOs up to 8: default state is 1 (HIGH, or close to 3.3V). GPIOs 9 to 27: default state is 0 (LOW, or close to 0V after Boot).
The tool isn’t finished yet, and so far I’ve only tested it on Kali Linux. Once it’s complete, anyone who wants it can have it. My initial question is: What else can be added? Is there a service missing that’s needed for the AIO board? I’m open to tips, suggestions, and extensions.
The obvious answer to me re switching modules on and off is to ensure all are off on boot and only activate a module when relevant software is run (so seamless to the user and max power saving)…
That’s the purpose of the program: to ensure the modules are switched off at startup. But I, for example, want the WLAN card to be switched on after startup, hence the autostart function. Someone else might want a different module to be switched on automatically.
The service management refers to the software (pygpsclient, Meshtastic mui, sdr++, tar1090) that Rex provides for the board. I don’t know which services iNTERCEPT needs, but those could be added later.
I’ve been using AIOV2 for quite some time - but now I’m fighting my way to conserve power.
While it seems like all devices are disconnected using GPIOs (and AIOV2_ctl) - there’s one exception: GPS.
As far as I understood all available documentation, it supposed to power down devices by using GPIOs for that. But, first of all, which one is GPIO27 on Minipci-ex port?
Second, is that correct behavior to turn off GPS using GPIO/CTL and still get location and NEMA data using PyGPSClient on /dev/ttyAMA0?
Or I’m simply missing something?
the cm5 board is mostly the same as the official cm4 board, the main difference is the camera lanes being being repurposed to carry ethernet instead, everything else that the cm5 adapter changes goes to it’s extra connectors
That’s not the case. There’s constant 4.2V on VCC pin for GP-02.
When LDO is de-soldered - found GPIO27, 5V and GND on it and according to extensive search - seem like 150mA LDO - I have 4.7V on VCC. So it seems like there’s some kind of short on PCB.
So yes, GPIO27 in fact supposed to shut it down - so need to realign schematic
