Genesis moment for VAPN prototype

John, KX4O, and Mark, KD6AKC, worked through set up issues and parameter adjustments to arrive at a nice Eureka moment in the progress towards a VAPN roll out.

Using what you have for testing

We are far away from a final hardware solution. Thankfully our likely packet switch software is available for both Windows and Linux making testing a matter of using what’s likely already in the shack.  In my case I have an Icom 746 with a spiffy Navigator USB interface by US Interface. I recently put a Diamond CP22e 2m antenna on the roof and can reach most of my local friends with ease using simplex. With the transceiver plumbed with a soundcard and PTT interface, I had everything needed to test the DireWolf “soft” modem and network hooks to downstream packet software. Before starting I fired up my copy of MixW in Packet mode to check things out. Indeed Mark and I were able to perform basic tests. Also, the DireWolf software was used during the Appalachian Trail Golden Packet to route heard packets to APRS-IS.

I setup an instance of DireWolf and BPQ32 on my desktop Win7 machine while Mark connected simplex over an unused 2m packet frequency. Under test were the elements shown below.

Pieces of a packet system
Major components of a modern packet system node

What the FRACK

Ah AX.25 parameters… set with incorrect values, you can have your transceiver keying up several times a second as the above system did while not waiting long enough for ACKs. It’s one of those painful moments in life when you realize how much of something you have forgotten and pesky little TNC parameters are no exception. It’s all coming back parameter by parameter.

One significant difference I noticed in AX.25 parameters involving “time” is BPQ32 seems to have a base unit of milli-seconds where TNCs of old often have base units of 10 milli-seconds or more; My PK-88’s FRACK value is in seconds!  A value of 300 for FRACK in an old TNC might be 3 seconds, but in BPQ it’s 0.3 seconds… not long enough in this particular case. A quick change to 3000 made a world of difference.

The school of hard knocks is in session.

Conclusion

After much twiddling with parameters like PACLEN, TXTAIL, FRACK, etc. the system above more or less just worked. Mark and I exchanged a test message or two on the BBS and ran Chat just fine. The HTTP view into the guts of the BPQ32 node program worked well.

Our proof-of-concept goal was to verify the “TCP/IP only” connectivity between the entire BPQ32 suite of programs and the DireWolf software TNC. Yeah it took a while to sort through the myriad options, but success was achieved in the end. This key capability suggests the Ethernet connectivity between the main BPQ32 node and the various radio boxes shown in our overall block diagram should be possible outside the confines of the PC’s 127.0.0.1 net. We will believe it when we see it, but this test nicely confirms the possibility.