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.

For several years now I wanted to replace my older High Frequency antenna which had partially fallen down; it was a G5RV Jr. However it never really worked right; it used a metal mast which had detuned the antenna and after about a year it started to fall down and became completely inoperative anyway. Throughout the years it got me some DX, but overall it really never performed that well.

I am in a rather unique situation when it comes to antenna options. I live in south Philadelphia; that means there aren't many sky-scrappers immediately around my house, however, I am surrounded by a sea of row homes as far as the eye can see. Since a tower of any reasonable size is clearly off limits that meant my backyard wouldn't be a particularly useful place for an antenna. That left me with just one option, my roof. This of course has the advantage of being 25 feet off the ground and giving me a reasonably decent view of the horizon. Of course it also has the disadvantage of having very little room to work with.

In the end a vertical type antenna, with coil traps to make the size manageable, was selected; Specifically the Hustler BTV-6 antenna which is designed to work everything from 80m to 6m. A balanced dipole type antenna wouldn't work too well since I would have had very little control over the takeoff angle since the ground plane for such an antenna would be 25 feet down, and through my house. That meant a dipole type balanced antenna would be very hard to configure effectively. With a Vertical type antenna, however, the radials act as the ground plane, so seemed like a far better choice.

One other advantage to using the roof is that the distance to run the coaxial feed line from the radio to the antenna is very short. With only 10 to 15 feet of coax that means feed line loss will be very low even when the Standing Wave Ratio is high. I tried to position the coax on the roof such that the run is as short as possible. This should help prevent common mode current which could occur if the shielding of the coax becomes inductively coupled with active element of the antenna. Since the coax is significantly shorter than the wavelength being transmitted this effect should be minimized. Of course when putting a vertical in a yard you can actually dig a trench for the feed line placing it beneath the radials. Since this wasn't an option in my setup it became critical to keep the coax line as short as possible.

Here are some pictures of the newly installed antenna including all the radials.

As you can see in the last picture the antenna occasionally made contact with the metal mast which supported it. When this happened it would create a short to ground and completely detune the antenna. As such I added some insulating foam to the supporting mast to ensure it wouldn't be able to make conductive contact with the antenna.

Finally to top everything off I added a new 8 foot by 5/8 inch ground rod to the system. For that I chipped a hole in the cement in my back yard and hammered it into the ground just outside the radio shack's window. I then attached a ground clamp to it and ran some solid bare copper wire (4 AWG) to the window on the second floor.

For now I have the coax and grounding cable coming directly through an open window. But I have a window panel to be installed to fix that. The ground cable must be connected with the house's electrical ground or else dangerous ground loops can occur; this connection was made in the shack and an additional connection will be added in the basement to ensure it is up to electrical code. Inside the shack at the window I installed an automatic remote tuner. The ground wire connects to the Tuner as well as running to a junction box which connects together all the radio equipment in the shack.

It is important you use a grounding junction such as the one above rather than daisy chaining your ground together between devices. This ensures that even if one connection becomes loose all the others still maintain their connection to ground.

By having additional paths to ground it reduces the impedance as well as resistance for the path from the radio and antenna to the ground rod. This can and has had a noticeable effect on reducing unwanted effects and RF Interference.

And finally a picture of the entire shack just for completeness.

As many of you know for many years now I've invested in, and had an interest in, cryptocurrency. However until now I never owned a mining rig simply because it didn't seem profitable enough to be worth the trouble. However recently a few things changed; first, with Ethereum entering the scene it became a profitable endeavor with a ROI that would exceed the initial investment in less than a year. So after running all the numbers to make sure it was profitable, and testing it out on genesis-mining.com to see some cash flow first, I decided to give in and invest in a top of the line mining rig. Since I also do a lot of R&D in Machine Learning and Parallel Processing I figured it could double as a useful tool for my day job, one that will pay for itself when not actively being used. Really in many ways it is a win-win proposition.

Like so many other things I get into I had to take my endeavor to the extreme. I wanted the best, most profitable, mining rig I could build; something that would be equally powerful for my professional endeavors as well. This meant top of the line AMD OpenCL compatible GPUs with a significant number of cores, memory, and memory bandwidth. Of course I also needed to figure out how to accommodate four double-wide graphics cards on any normal motherboard. I spent about 2 days surfing NewEgg.com and Amazon.com and finally arrived at all the parts to build this beautiful mining rig.

UPDATE: Added some velcro to secure that 4th card. Looks much better now and is a bit safer than before.

The specifications are as follows:

4x Radeon R9 Fury X Graphics Cards
1x AMD FX 4350 Unlocked Quad Core Processor (4.2 Ghz)
1x Corsair RM Series, RM1000, 1000 Watt PSU
1x Thermaltake CORE P5 ATX Open Frame Case
1x ASUS Crosshair V Formula-Z Motherboard
4x Kingston HyperX FURY 4GB 1600MHz DDR3 Memory
1x Samsung 850 EVO 120GB SATA III SSD Harddrive
4x PCI-e X16 Reisers

In the end once it was all setup and configured this beast produced an impressive hash rate.

111,149,056 hashes per second (111 MH/s)

With current network parameters; that means I mine about one block each day at about 5 ETH per block. Market prices fluctuate wildly so by the time you read this these numbers may change, but that is somewhere on the order of about 10$ per day. So the cost invested to build the computer should pay for itself in about a year assuming there aren't any significant changes to the network in that time. Not too shabby.

Roadblocks

It took me about 2 days to fully assemble the box and get it to the point where it was mining Ethereum. I am an Arch Linux fan so most of that time I spent trying to get it to run under Arch Linux. While normally Arch Linux is a pleasure to work with, no matter what I tried i found it impossible to get it to get the C++ Ethereum client to mine successfully. There were a slew of problems, with xorg-server being the wrong version as a dependency, and OpenCL throwing segfaults complaining "PPLib wasn't enabled". In the end I gave up and moved to Ubuntu. While I'm not usually a huge Ubuntu fan for day-to-day stuff, in this case it really did make the setup much easier.

Once Ubuntu was freshly installed on the system I just had to add a few repositories and install a few packages. I found a tutorial which described the process pretty accurately. Only difference was I didn't find i had to install AMD-APP-SDK or the C++ Ethereum code manually, all these were available precompiled in the repositories so I just installed them with apt-get.

One thing did perplex me though; anytime I tried to run the miner using the eth command as described in the tutorial it would run for a minute and then abort claiming it was "killed" without any details. After racking my head for hours I found that if i ran it with the ethmine command instead it ran successfully. Here are the commands I ran to get the miner going.

geth --rpc --rpccorsdomain localhost &
ethmine -G

Tweaking

Never content to just leave things as they are, I wanted to try to find ways to tweak the settings to boost performance slightly. While I wouldn't be willing to run a custom kernel, since security is still a major concern, that left me mostly with just the ethmine settings with which to tweak. Two settings in particular struck me as useful, as they effected how much work is sent to the GPU at one time. These were --cl-local-work and --cl-global-work. Knowing I had a top of the line GPU I figured boosting these values a bit might increase performance. Indeed they did, but I had to play with a lot of different numbers to get the benchmarks to max out. Finally the max hash rate I mentioned above of 111,149,056 hashes per second (111 MH/s) was achieved with the following command. This was about a 10% improvement over the default settings.

ethmine -G --cl-local-work 256 --cl-global-work 8192

I tried enabling the CPU too with --enable-opencl-cpu however that produced a segfault. So I left it out.

Conclusions

With an ROI that pays for itself in under a year, and the future usefulness of such a rig, it is really a no brainer for me to have set this up. It was also a lot of fun, and profitable. Though I think a cost-analysis might be useful to compare different rigs and hash rates to ultimately figure out what is the cheapest rig for the output it produces. Sadly I don't have the information on other rigs to be able to do this, nor do I have the time. Also it should be noted that while this rig works really well for Ethereum it would be far less effective on other cryptocurrency where the memory bandwidth isn't as critical; so don't expect it to be the ultimate rig for all cryptocurrency mining needs.

I hope that helps you guys in setting up your own mining rigs, happy mining!

Updates

turns out the power supply is under-powered for the system. I advice upgrading to something with a bit more power, next model up should do it.

Clones

Since I've posted this article there have been a few clones of the miner. I will add names and pictures here. The following is from Rolf Versluis rolfv@prioritycue.org: