ALE 2G extension: what now? (your input requested)
This discussion was created from comments split from: Automatic Link Establishment - MIL-STD-188-141a (ALE 2G) decoding extension.
It looks like you're new here. If you want to get involved, click one of these buttons!
seems ready for prime time
I haven't read enough to know what the extension user interface should actually do with the data. gr_ale will autostart a recording of a negotiated connection on whatever new, agreed frequency is. There could be various logging options. I don't know what multipsk or the others do.
Then there is the question of channel scan strategies, network databases (probably downloaded from sources outside the Kiwi app so they can be kept up-to-date like DRM).
There could also potentially be multiple Kiwi channels involved in ALE scanning somehow. Initially this can be as simple as a single URL which opens multiple Kiwi channels, starting up multiple copies of the extension with different parameters.
2G uses an asyncronous channel scan scheme.... just to add to the design agony here.
2G ALE was designed to handle "slow" hardware. That is a Transmitter/Antenna Coupler that takes time to emit energy on a new channel or a receiver that is limited by LO settling times or relays in a preselector.
Fortunately we have no such limits in the KiwiSDR and while the original schemes might be limited to a channel scan rate 1 or 2 channels per second, we can go much faster or even monitor in parallel.
The randomness of the TX scanning sequence can be a function frequency or prior linking success so a RX must be ready for anything.
You'll note that a tranmission times are long enough to let the receiver go through the whole set.
Typically channel groups/sets are 10 channel or less.
Given that, a way to enter 10 channels in a list and scan them at 5 per sec. is my thought.
For now, that would be limited to detection of Sounds, just like the limit in gr-ale and we have in this development code.
(I hope I haven't confused any of this with 3G!!)
For users to see what it currently does, visit my site
4416.9 Khz USB
there is a DX Label for setup
The test TX transmits every even 5 minutes
NOTE: the ALE ext does not force USB, you need to select it
Hi Jim, is it possible to program an AMD message in your Harris PRC-150 in addition to the sounding. Just to see if that is detected also in this extension?
I guess most HF utility DX listeners will be already be happy with the data currently displayed for traffic analysis and propagation checks. If AMD messages can be displayed and additional n seconds voice after a 3-way handshake can also be recorded that would be a luxury.
Scanning is most efficient for ALE reception and additionally avoids folks from tying up a single frequency on a Kiwi channel for a long time.
Although commercial transceivers have high scan rates like 10 channels/sec, I found that scanning at lower rates like one channel every 2 sec using the Kiwi works pretty well to catch most transmissions. This was done using Multipsk and Catsync and some com port interfacing. Doing this, settling time after freq change and AGC setting and a minimum ALE detection time have of course to be considered.
Not sure how fast a Kiwi could practically made to change frequencies. Perhaps the existing 10 sec scan from the IBP scanner extension can be adopted for this.
I don't think there is a good public source of ALE net frequencies, so I propose to initially include in the extension a dropdown list of well known nets first. If via the admin page a named scanlist of say 10 freqs could be defined by the Kiwi owner that may speed up the discovery of active ALE-2G nets. This info in turn could be sent to a common database.
PS: Yesterday I sent an email to jks.at.kiwisdr.com with some more info on this.
gr-ale doesn't do AMD
Could not test AMD with gr-ale due to some errors in my GRC installation. Thanks for the info.
from gr-ale gitbub readme
"Incomplete support of ALE protocol features, currently only sounding and call establishment are decoded"
Question DSP time to pass signal through sdr slow down scan speed too much for many channel
After some spec & code reading I'm pretty sure I can add AMD easily. So if it's not too much trouble to setup that would help me test the change.
It may be Monday before I add that but shall see. Sounds can be scheduled. May have to build an external script for automated AMD sends
I just realized, generating AMD's requires 2 xcvr's communicating. A bit more work!
Maybe Benson knows of an existing freq. with AMD traffic.
Jim, WA2ZKD allowed me to use his Kiwi for some scanning tests and the results are shown in the attached "results ALE scan 20210605.txt"
I used Catsync with his Kiwi loaded and a frequency database of 10 channels to scan at different rates. Multipsk was fed via a virtual sound card at the same time. AGC delay set at 50ms.
1/ Using a rate of 2 sec/channel caught most completed decodes with this Catsync set-up.
2/ A scan rate of 1 sec/channel resulted in some missed decodes sometimes cut off at the first frame, not surprisingly because the scan keeps going regardless of whether an ALE frame decoding is in progress.
If scanning is temporarily halted when decoding is going on before continuing, higher scan rates should be possible.
3/ For display of the decodes the lines preceding the timestamp, showing TWAS, DATA or TO might possibly be omitted with a "DX" setting, somewhat akin to that in the NAVTEX extension showing less detail.
4/To my sense the BER calculation is implemented correctly in gr-ale and the ALE 2G extension.
Just to mention that in Multipsk the measure is reversed quoting their manual:
[The "BER" ("Bit-Error Ratio"). In fact, it is the number of bits (over 48) which have not got the unanimity when the 2/3 logic voting takes place. However, to be compatible with other softwares, the BER is reversed. So the higher the BER, the less the number of errors. In a practical way, the better the link is, closer to 30 the BER is. Reversely, the worse the link is and closer to 0 the BER is (below 6, it is considered that it is not a 141A frame)]
5/ Sensitivity during scans on par with Multipsk, sometimes better.
About AMD messages seems they are seldom used, last I have seen those are on IARU HFN Net. I suppose with so many alternative ways of sending digital messages available nowadays this lost its importance.
For display of the decodes the lines preceding the timestamp, showing TWAS, DATA or TO might possibly be omitted
Sorry, I had enabled the printing of each decoded protocol word to help me understand what was going on. This will definitely be a temporary situation (and easy enough to add a "debug" switch to the extension interface).
AMD's were handy BITD for sending short messages without having to have a computer. 3G replaced them with SMS capability.
Thanks everyone who sent sample files. I actually found a long AMD embedded in the sample file on the sigidwiki.com website: https://www.sigidwiki.com/wiki/Automatic_Link_Establishment_(2G_ALE) And Martin emailed me a custom ALE transaction he created containing a bidirectional AMD.
I am finding the ALE protocol to be very complex. It's one thing to just extract soundings and call setups as the gr-ale software does. But for anything else you have to process things very carefully. It's a "spaghetti" protocol that only a military contractor could love.
Most ALE exchanges I've seen contain an embedded 2nd generation "ALE quick call" (AQC) sequence right in the middle of everything that must be handled. There also seems to be a lot of junk that makes it past the error detection. And sometimes it resembles valid protocol which can make it difficult to filter out. I've also seen slight deviations from the spec which is annoying (I'm reading MIL-STD-188-141B)
the protocol was designed by committee! Google Eric Johnson ALE and you'll find related docs.
Looking forward to this being in an upcoming release.
Working on it (and ten other things) at the moment.