This post explains a technique to drive a KISS TNC with a specially constructed packet that contains an ISOCHRONOUS test packet, a packet that will produce equal high and low tone alternation in the transmitted AFSK signal.
Above is the waveform recovered from a receiver without de-emphasis (a Motorola R2009D communications analyser in this case).
Continue reading Adjusting KISS TNC AFSK tx level using an isochronous test packet
Readers of my article Galvanised steel wire OCF dipole have asked whether the analysis applies to an ordinary centre fed half wave dipole, and this answer is no, not exactly, but very close.
The current distribution on the OCF is very slightly different to a CF dipole, and this causes a very slight change in loss, 16.55W vs 16.68W.
Updated 24/10/14.
I purchased an Opentracker USB (OT-USB) after a review of documentation and some screen shots of the configuration tool OTWINCFG which suggested that the product ‘understood’ the challenges. Continue reading OpenTracker USB review
Viscous digi is a feature to reduce unnecessary digipeater transmissions. Upon receiving a packet, the viscous digi puts it in a hold queue for a configurable time pending hearing another digi repeat the same packet. If none are heard, then it is repeated as usual, otherwise it is discarded. Continue reading aprx: evalution of viscous digi
One of the shortcomings or RPi for (m)any serious applications is that it lacks a hardware clock so when it starts, the clock is not set correctly.
This deficiency can be overcome to some extent for some applications with the fake-hwclock module and SNTP where the RPi is always connected to a network.
The standard scheduling daemon cron does not run tasks that were missed because the system was not running at the time they were scheduled. It is a significant shortcoming that has been overcome by adding another element, anacron, which wraps the cron tasks and is scheduled by cron and at startup. All of this is very dependent on correct clock time, and for RPi systems that lack a hardware clock (the out of the box hardware), the system time can be quite wrong at the time anacron is scheduled as part of the startup procedure.
Continue reading Cron configuration improvements for Raspberry Pi
One of the shortcomings or RPi for (m)any serious applications is that it lacks a hardware clock so when it starts, the clock is not set correctly.
This deficiency can be overcome to some extent for some applications with the fake-hwclock module and SNTP, but this is not a solution if the RPi is not always connected to a network time reference.
One solution is a real time clock module such as the DS1307, or better still the DS3231. The latter has an internal crystal with 2ppm (5s/month) accuracy from 0-40° which is much better than typically achieved with a DS1307 (which is dependent on the external crystal). Continue reading Real time clock for Raspberry Pi
APRS is almost exclusively source routed, and depends greatly on sensible path configuration by each and every user.
This is one of those cases where individuals acting independently and rationally for their own personal behave contrary to the whole group’s long-term best interests by depleting some common resource (the tragedy of the commons).
Increasing the available WIDE path length does expose a station’s packets to more iGates, but the average effect of everyone following that strategy is to literally exponentially increase channel busy as the available hops is increased. Continue reading APRS: how many digi hops to make it to APRS-IS
A study of APRS traffic was conducted by analysing the log of VK2OMD-3, a VHF APRS ‘fill-in’ digi and iGate.
The capture period was during the busy hour(s) (BH) 0600-0900 local time on Saturday 11/10/2014. Continue reading APRS traffic study – VK2OMD-3 11/10/2014
aprx is APRS iGate / digipeater server software for the *nix environment by Matti Aarnio. In my case, I am developing and running on RPi / Rasbpian Wheezy.
This article comprises notes on the digipeater module as modified over recent weeks to address shortcomings in its operation. Continue reading Notes on my fork of aprx
A short test drive was conducted to evaluation APRS effectiveness in capturing a motor vehicle journey of about 30km.
The test area is between two digipeaters spaced almost 40m apart, so within the overlapping coverage area of VK2RHR-1 about 17km NW of the test area, and VK2AMW-1 about 17km SW of the test area.
Three position capture devices were used: