FLEAR is an open-source and open-standards incubator for Ham Radio

We got APEX running on a Raspverry Pi today. Wonderful new addition to the shack.

APEX stands for "APrs EXtended"; It will be a new protocol which expands on and fixes most of the issues in the older APRS protocol while still remaining backwards compatible.

APEX defines both a new protocol and a new paradigm. Since much of the new protocol will not run on existing hardware APEX also includes a Python reference implementation that will provide a full APEX application out of the box. Since APEX is backwards compatible with APRS it can fully utilize existing APRS hardware to route APEX packets across the network. Though only APEX capable stations would be able to make full use of the information in an APEX packet.

The software for the project can currently be found at the APEX GitHub page.

APEX Routing Paradigm

The APEX routing paradigm defines a few new routing identifiers in addition to the common ones such as "WIDE2-2", and a few new behaviors on how the paths are consumed.

The problems with the current APRS model are numerous. One problem is that aside from the use of WIDE and GATE there isn't much flexibility on how we can route packets when we don't know the explicit digipeaters with which to specify; Using WIDEN-n is more of a sledgehammer when we need a scalpel. It is also completely ineffective at being able to route a VHF message across HF channels which may be critical during an emergency. A similar problem occurs when we consider multiple HF nets across multiple bands; as it stands right now there is no paradigm that defines cross-band digipeating paths. The closest we have is the GATE path which is generally used to only digipeat from HF into VHF. This has some limited usefulness at best. As such the initial release of the APEX reference application attempts to address these problems (though testing and feedback may change the details of the specification as described here).

Cross-band Path Routing

In order to facilitate cross-band routing the APEX protocol defines several new designators as well as includes many of the old ones. Obviously WIDEN-n, GATE, and your own callsign will behave similarly to how they behaved in the old paradigm. However the new band-specific designators will have a form of ##M### or ###M## where # represents any digit 0 to 9. The first group of numbers specifies the band ID, while the second group of numbers is the net ID and is optional. In this way the designator 30M would represent the 30 meter band as a whole (specifically any nets on that band the station is capable of). When 30M is specified in a path, a station will digipeat that packet out on any port which is tuned to the 30M band. Similarly 30M1 would specify a frequency (net) that resides within the 30M band. The list of identifiers for the various nets will be updated periodically as new nets show up. However right now 30M1 would specify the world wide FSK based APRS network residing on 10.1476 Mhz USB; similarly 30M2 would specify the world wide Robust Packet Radio based APRS network which resides on 10.1473 Mhz USB. similarly other designations would be chosen for other networks throughout the world. A complete list would have to be compiled.

Using these new designators in a path would be relatively straight forward. If, for example, you wanted a packet to take one hop, then move over to the 30 meter Robust Packet Radio channel, then move back to ordinary VHF for its last hop, and you dont care what the specific frequency on that hop, then you would construct your path as follows:

WIDE1-1,30M2,2M

Notice the last hop is just 2M with no number suffix. This is because we just want it to gate into 2M network and don't care which frequency on that band it is gating into. As a side note the GATE specifier would actually perform the same function as the 2M specifier.

Preemptive Routing

Preemptive routing is unique to APEX and also made it into the initial release of the APEX reference implementation. With preemptive routing a digipeater can respond to certain specifiers in the path even when they are not the next hop in the path. With the cross-band path specifier mentioned above, ###M##, an optional ssid can be added to the end. If the ssid is not 0 then it specifies that the path should be treated preemptively. Essentially what that means is if it is the next hop then treat it normally however if it is a future hop you can skip all the hops in between and go straight to the hop, assuming the station is capable of operating that band (otherwise it is ignored).

For example say we wanted to create a path where I get a packet out over HF and thats all I want to do. Consider the following path:

WIDE1-1,WIDE2-2,30M-1

In this case since 30M-1 is preemptive then the packet will hop across the WIDE path but every station that hears it along the way that is capable of 30M band transmission will emit the packet on that port as well. Contrast this without preemptive paths where it would look like:

WIDE1-1,WIDE2-2,30M

In this case the packet would follow the WIDE path and even if they are capable at digipeating on 30M it will not do so. Only the very last stations that hear the packet after the WIDE portion of the path is spent will actually be the ones to digipeat over to 30M. This would cause far fewer emissions on the 30M band while still ensuring the transmitting stations are geographically spread out. In an emergency this might be a good way to send an emergency packet out.

When a path specifier has a non-zero ssid it is preemptive. The value of the ssid indicates its priority. So when there is a long path with several preemptive routes specified it is always the one that is the highest priority and when there is a tie it is always the right-most (last in the path) specifier that gets triggered. For example say we had the following path:

ECHO*,80M-2,WIDE1,30M-2,80M-1

In this case if the packet is received from a all-band capable station then it would emit the path for 30M-2 when digipeating the packet. The reason is that 2 is a higher priority than 1 and of those of equal priority the 30M-2 was the later one in the path.

Also important to note is that when preemptive pathing is executed all the intermediary paths that were skipped get dropped from the path entirely. So the above path, once digipeated, would be transformed to the following path:

ECHO*,WI2ARD-1*,30M-2*,80M-1

Another interesting twist is how preemptive routing handles the other types of path specifiers. Basically the WIDEN-n type specifiers are never treated preemptively. However specifiers which reflect the stations own callsign are always treated preemptively. callsigns, unlike cross-band specifiers do not have their priority reflected by the presence of an ssid; they are also still treated as preemptive even when they have an ssid of 0.

When there is a mix of callsign and cross-band preemptive specifiers in the same path then first the cross-band preemptive specifier is determined as before, second the right most occurrence of the station's callsign is determined. Which ever of the two occur right most in the path is the one that wins. For example:

WIDE2-2,WI2ARD-1,30M-1

In this case the preemptive path would jump to 30M1. However if instead we had the following:

WIDE2-2,30M-1,WI2ARD-1

In this case the preemptive pathing would jump right to the WI2ARD-1 path.

APEX Reference Implementation

As part of the APEX initiative the project includes an APEX and APRS client that acts as the APEX reference implementation. It is extensible and anyone with python experience can write plugins to expand it and hook their own software into it. This allows for lots of opportunities from the community to get involved and contribute to the project.

Currently the reference implementation implements all the features I described here so far. It also includes the transmitting beacon, status, and id packets, and digipeating. So everything is ready to be played with. As new features roll out they will be added to the APEX Reference Implementation as well. It is a command line Python 3 application and you can find it on github. It is very simple to run and you just need to configure a few things in the config file to get it up and running.

Below is a screenshot showing it digipeating packets as they come in across two TNCs.

What's Next?

There are many features that have yet to be implemented and we have some pretty lofty goals in store for APEX. A lot of this is brainstorming from the team so it is subject to change as well. But here are the ideas we have so far on what needs to get implemented into APEX and defined within the protocol.

• Ability to send a signal check packet. These will never get digipeated. Instead you send a packet which contains some diagnostic information about the antenna (HAAT, Power, gain, etc). Next any station which directly heard you will respond immediately with information regarding their own antenna information. Also if possible data will be encoded to indicate received signal strength of the received packet (on most setups this information wont be encoded). The signal test request packet will also specify if they desire the reply packet to be over the air, or through APRS-IS or both. In this way the information can be used for someone to probe band conditions as well as objectively try to configure a new antenna installation.

• When possible encapsulate all existing AX.25 packets in FX.25 packets instead, thereby introducing backwards-compatible Forward Error Correction.

• Provide throttling to prevent congestion. Packets are given priority based on several factors such as the length of the packet, and how frequent the sender sends packets, to determine a packets priority. Higher packets go through while lower priority packets get dropped. Misbehaving nodes, or out of date notes not running APEX would be potential reasons to give a packet a lower priority in addition to traffic statistics.

• Include the ability to send images and other media, potentially across multiple packets.

• Optionally request acks at the packet level. This is particularly useful when using callsign paths. Though for WIDE paths it is still useful to know what paths a packet took for diagnostic reasons and path discovery reasons. In this way an initial packet in a series can use wide but once the paths are discovered then the explicit paths can be used for the subsequent packets. This would reduce network congestion.

• Subscribe-to-callsign: a mechanism whereby a request can be sent to a normally out-of-range station to send me periodic updates to their beacon or other similar packets (comment, id). This is useful for tracking a friend when the station doesnt have internet access of their own.

• Improve or replace the IGATE system so that multiple instances of the same packet can be reported to it (with different paths)

• Rolling beacon ranges. Stations will move over to a store and forward approach. Essentially they will cache as much information about the system as possible. The longer it stays on the net the more information it should receive from distance nodes. This is accomplished with rolling beacons. Basically every station will keep track of how many times they have heard a beacons from the various stations. Any time a beacon is heard more than 'D' times where the receiving station is the last hop, then it will digipeat the beacon, and reset the counter. The value of D is an integer representing decay rate. A higher letter for D and stronger the decay rate. What this will cause is a beacon from a station that has been on a long time will get their beacon across the world hundreds of hops, but very slowly. Because the packets decay with distance this also wont cause a lot of net congestion. For example you might hear a beacon on VHF come from across the continent, but such occurrences would be very rare as well. So it may be exciting to follow rare DX like that. Using this system even if the network went down across the world (not an expected occurrence) it would still be possible for systems to communicate across long distance APRS links, by leveraging the stores cache of beacons every station has they can easily form a path.

• Smart routing for internet capable stations. When considering #8 combined with IGATE access it makes smart routing a possibility. Smart routing would be the process where the route of a packet to reach its destination can be discovered from the fixed stations in a region. The idea is that if the internet goes down these stations still have a cache locally of where the stations are around the world and in their area. This information can be used to create more direct route for message-type packets with a specific destination. This will significantly help congestion since these packets no longer need to try to follow WIDE type paths. Plus a system like this will be more resilient in situations where you have wide spread internet outages.

• Enforcement of certain behavioral rules for stations and to react automatically to a misbehaving station. For example if a beacon rate is too high then all beacons above the accepted rate will be dropped. This will also penalize the priority that station gets when routing its packets.

• Proper standards defined and implemented to encode the protocol version into the packets.

• Geographic routing: We want to add the ability to route packets to approximate geographic coordinates, either in an attempt to send a specific message or to transmit a WIDE message at that location to seek contact with anyone who may be actively listening.

• Better software messages for responding to various types of messaging: CQ, Bulletins, and messages need a nice clean GUI to work with or command line tool

• Delay Tolerant Networks - The general use case is to leverage moving cars for long-distance packets where latency isnt a top concern. It can transport high volumes of data long distance where normal packets could not.

• Retry packets from partial path: When a packet doesnt get to its destination, since stations will be expected to a have a large cache of packets heard, delivery can be retried by the closest node that successfully received the packet. This would make long-distance packets far more feasible.

• Mobile stations can announce stationary "home station". Once geographic packet routing is in place then two mobile stations can stay in touch by simply knowing their route to the home station at anytime. This simplifies discovering routes that would otherwise be impossible between two mobile stations without the use of the internet.

• Formalize the use of ID packets to clearly specify the various path identifiers that can be used with the station and their effects. for example "WI2ARD/30M2 IGATE" might specify I have a station with ID WI2ARD on 30 meter robust packet radio, and it is also igate capable. This, along with position beacons, should make it possible to discover paths dynamically.

After much frustration trying to get my old KAM-XL TNC up and working I finally got it all back up a few weeks ago. For the sake of future hackers I'd like to share the steps it took to get it all configured.

First off, buy the correct cables for your radio and hook it up. Less problems to troubleshoot for you in case things don't work right. For me both the Yeasu FT-2000 and my Kenwood D710 radio hooked directly to a single port on each radio. For the Kenwood D710 You want to attach to the DATA port on the back of the unit; for the YEasu FT-2000 you connect it to the PACKET port. Obviously each radio type has its own name for the port to use, so that part you will need to figure out for yourself.

The hard part for me was getting the radios configured and properly tuned. Most of the information I could find on the internet gave misleading and often blatantly wrong information as far as this goes. The first, and most glaring issue, is that most internet sources claim the tuning frequency for the KAM line of TNCs (which I took to include the KAM-XL) was 10.14760 MhZ USB or the equivalent LSB frequency. I prefer to use USB since the frequency is so close to the band edge and some radios will erroneously block transmission if using USB; which was the case on my FT-2000. The actual frequency you want on HF for use with the KAM XL is 10.14710 Mhz USB. For the VHF radio you will want to tune to 144.390 Mhz FM in the USA, outside of the USA the frequency may differ.

This should be enough for the radio to work, but there are a few other settings I found improved reception on the HF radio, my Yeasu FT-2000. The ideal settings for me were as follows: Attenuator off, IPO ON (no pre-amp), FLT Thru (the VRF should be turned off), R. FLT 6Khz, AGC off, Noise Blanker off, Transmit Power 25W or less. Since I see no difference when i transmit at a full 100W either way I keep it under 25W. Though for my radio I did not see any decrease in performance at full power.

For the Kenwood D710 the only important settings seem to be the squelch and the TNC setting. Squelch should be set such that you hear incoming beacons but static gets squelched when no incoming signal occurs. If you don't do this the TNC will think the radio is always busy and will never send outgoing packets, only receive them. The TNC setting should be off such that neither the APRS TNC nor the KISS TNC are engaged. If you see any of the following on the display then the TNC is still engaged and must be turned off: Packet12 or APRS12. The number 12 may vary depending on the baud setting of the radio at the time.

Next, we want to set a few things on the TNC itself. The easiest approach is to use KISS mode, in which case none of this matters and you can get up and running right now. ui-view or any APRS software can get you up and running in KISS mode. However if you wish to use the TNC in host mode or as a standalone TNC not hooked up to a computer then you will need to tweak the settings a bit. Also ui-view can still work with the TNC in host mode (as opposed to KISS mode) but since the TNC will send out its own beacons and status packets you will want to disable ui-view from doing this or else you will have duplicate packets.

The settings of the KAM-XL you need to set, at a minimum, in host mode are as follows: MYCALL, HBAUD, and BTEXT. MYCALL should be set to the call you want to use on each port separated by a slash. So if you want no ssid on the HF port (same as ssid of 0) and a ssid of 1 on the VHF port you would do something like "WI2ARD/WI2ARD-1". Similarly if you want to transmit out of both ports you will need to set HBAUD to "300/1200". Finally set BTEXT to be your beacon text including coordinates (if you use a GPS attached to the KAM-XL this can get set automatically). My BTEXT for me was set to "!3955.05N/07510.06W&http://JeffreyFreeman.me". Everything after the ampersand is the comment, this can be anything, and the data before the ampersand are the coordinates.

That's all there is to it, your KAM-XL should now be up and running in host mode. One thing to point out though, do not expect to hear many incoming packets, a few a day at most. The KAM-XL works with the older AX.25 over FSK modulation which isnt very good on HF (though works fine still on VHF). For this reason not very many packets will get through. Luckily Robust Packet Radio (RPR) is a new type of modulation that is quickly replacing APRS on HF. While RPR is backwards compatible and will still pick up the older APRS beacons the KAM-XL itself is not capable of RPR. By moving to RPR you will notice a significant increase in the quantity of received packet from the APRS network. I highly recommend updating to a SCS Tracker (the only TNC capable of RPR) if you want the best results from APRS over HF.

Found this little gem on the bottom of the cradle charger for my Beofang.

It reads as follows:

PLACE TYPE Li-ion BATTERY CHARGER

Note: Prevent cooks meals or is injured, only battery assigns carry on the charge.

Input: DC 10V
Output: DC 8.4V 400mA

Charging

The charge completes

Bright trickling charge (battery stops using has been long) / the chareto mistake.

I'm just going to leave this here, and remember Beofang puts just as much attention to detail into their hardware as they do their English. But hey, at least their punctuation was completely correct.