Direwolf – What’s not to like
The more I learn about the various software demodulating algorithms in the amateur community, the more I like their commitment towards using correlation and other techniques to squeeze a few more good AX.25 frames out of the ether. The Direwolf project appears to be one effort incorporating the lessons learned from many others. I’ve tried it on my ham shack VHF rig plus regular PC and it decodes very well and with little fuss.
…takes a bit of learning to appreciate, but once you do, the information provides useful information about the inner workings of Direwolf during packet operation.
The VAPN block diagram changes… again
With an eye towards modularity in the multi-frequency port design of the VAPN, and Direwolf’s ability to provision a radio’s TNC face on the local network, I ambitiously revised my VAPN block diagram thus…
Besides reorganizing the ports left-to-right by frequency, the big difference is the replacement of the Raspberry PI, TNC-PI stack with one Raspberry Pi for each VHF/UHF radio. This design rests on the hope the BPQ software running on the master processor can access the remote radio TNCs through its IP-address:8000 or some such address:port. Yes this is lots of Raspberry Pis, but they are cheap.
Most folks desire to squeeze as many features possible into one Raspberry-Pi including the BPQ software suite along with the various Direwolf or equivalent radio interfaces. There is a place for this, but the proposed VAPN installation isn’t necessarily hurting for physical space or bumping into any power limits. Why squeeze if you don’t have to.
Modular radio channel assemblies
One goal for the VAPN equipment rack assembly is to house all electronics for one particular frequency to include the radio, filter, power supplies and TNC-assembly. The only ports for the VHF and UHF assemblies, using the above design, are RF, Ethernet and AC power.
I’ve long desired to abstract an entire radio channel and its systems to some IP address:port on a local Ethernet. The discovery of Direwolf and the Raspberry-Pi may be one way to accomplish this goal. The result is a more modular system with SPF distributed, but such that the failure of one channel’s Pi doesn’t take down the rest… I think… I hope.
I am still not convinced the Raspberry Pi approach is reliable, but the price point begs to give it a go. With one instance of Direwolf running for each radio on its own Pi, a lot of processing power is applied to the demodulating task of each frequency port. This relieves the processor running the BPQ suite of heavy duty DSP tasks.