So I’ve been tinkering with my Raspberry Pi board, and one of the most recent additions is a pair of heat-sinks to offset the addition of additional thermal loading due to over-clocking. In an effort to get soundmodem working on the pi, I’ve increased the clock frequency by a moderate margin to see if I can alleviate some bottle-necking in the decoding of AX.25 packets.
I am using two different USB soundcards in an attempt to see if the sound devices themselves are part of the resource management issues the Pi seems to be having. In addition, I’ve added a powered USB hub to rule-out power issues for the USB back-plane on the Pi.
Despite my best efforts, the CPU load still seems to be pegged out while running soundmodem, which means that the packet capture rate will be extremely poor at best. This is very frustrating considering that the CPU on the Raspberry Pi should (on paper) be able to handle the task fairly easily.
Now I could take the easy road like many others and use a dedicated hardware TNC but that completely misses the point of this exercise. My objective is to create a $35 TNC/digipeater/igate/tracker module – all exploiting the Raspberry Pi’s hardware. In theory, this task should be relatively straightforward, I mean heck, a fricken’ Arduino is capable of encoding AX.25 packets! (I’ve made a transmit-only position reporter using an ATMega 328)
I haven’t given up on this project, but I am a little dismayed. I’m by no means a software expert and so my attempts at trimming the fat on the Pi have been fairly fruitless. I am hoping that someone a bit more talented has a look at the resource issues and make some headway on the soundmodem implementation on the Pi.
I’ll keep poking and prodding, perhaps I’ll uncover one of the root problems. I’m wondering how better to utilize the Pi in the meantime.