Amateur Radio HF digital modes are a great way to transfer small
amounts of data, and, especially in the realm of emergency
communications, are gaining popularity even on the VHF/UHF bands.
While the more robust HF modes are not nearly as fast as packet or
D-Star, they have a big advantage: aside from a computer and a radio,
they require no extra hardware. Modes such as MT-63
can be used via "acoustic coupling" by placing the computer and radio
near each other so that their microphones are near each other's
speakers, and manually pressing the PTT as one would do during normal
voice communications. A $200 netbook with free software and a
$100 2m FM radio works just fine. In fact, a ham radio isn't even needed; other audio transport links, such as telephones, can work as well.
Sure, better equipment will yield better results, but reducing the need for special equipment means more available communications assets in an emergency. It might be handy if everyone had a portable welder in their go-kit, too, but I'd much rather carry a roll of duct tape!
Digital modes work well for plain text, but what if you want to transfer binary files? What if you need to ensure 100% accurate copy (which is usually necessary for binary files)? Flarq was developed to address this -- when used with Fldigi, it allows guaranteed reception of large amounts of binary data by -- but it has a couple of shortcomings with regard to the purpose described above. It requires a hardware interface (or VOX control) to automate the handshaking. It also precludes the use of transmission modes that don't support the ASCII control characters it uses. It's also unsuitable for disseminating information to multiple parties simultaneously, since it requires a one-to-one connection session.
While automated retransmission is nice, it's not necessary in many cases; if the underlying transport (e.g. MT63 over a strong FM link) is reasonably reliable and the file isn't too large, the entire file can be resent if it didn't make it the first time. Eliminating this feature allows us to achieve the other goals.
There are a few stand-alone programs out there that will encode/decode binary files for text-mode transfers, but I haven't found any that are very easy to use in the situatiuon previously described. Using them to accurately pull a file from a ham radio transmission requires effort, and you must still use a separate step to verify the received file. A separate hash utility can be used for this, with the hash communicated over the same link and compared at the receiving end. This checksum verification is also fairly easily accomplished by putting it in a .zip container, which has the added benefit of compressing some types of data for faster transmission at the same time.
Hardcore geeks have been manually doing this type of multi-step process for
many years, over wired and wireless connections; my goal is simply to
make it easier and more accessible to the average ham, and save time in an emergency situation.
The current contents of the clipboard are displayed in the bottom half of the form. This information is automatically updated when you move your mouse over the upper half of the form; this allows you to, for example, easily verify what you're about to encode before you hit the button.
You can disable the ZLib compression by deselecting its checkbox prior to encoding. You may wish to do this, for example, if the recipient is using a different program to perform the Base64 decoding. Normally, you will leave this option selected.In testing, I found that once files got larger than about 2MB, they started taking a long time to encode. This is of little concern, however. If you're planning to transfer a single 2MB chunk over an HF mode, you're insane, anyway; that would take almost 30 hours using MT-63/2000 (20 cps), and over 2 weeks using Olivia-8/250 (1.46 cps) -- and if there's a single error, you get to start all over....
Option for inserting a callsign banner periodically
in the data
stream. As it is, even using MT-63/2000, you shouldn't transfer
over 12kB of data at once, due to the FCC requirement to ID every 10
minutes. (Even at maximum compression, this program is itself a
3-hour transfer.) Then again, 10 minutes is a long error-free
transmission under most conditions -- and not overly friendly to anyone
else needing the frequency -- so perhaps there's no point in doing
this. This program is intended for *quick* transfers, and over 10
minutes isn't quick.
Automatic calculation of transmission time, based on selected mode