Second build sold out. Message will appear here when store is ready for third build ordering.

Automatic Link Establishment - MIL-STD-188-141a (ALE 2G) decoding extension

2»

Comments

  • Late yesterday I was having pretty good luck. It's almost like it fails to "lock" sometimes even though the incoming signal is strong. But there's no associated PLL (just an FFT) so nothing to lock to and FEC should allow it to recover even if it gets a bad start.

  • still running and decoding fine here

  • one fallout from this testing is seeing what occurs on a 100 mile path over 24 hours.

    Except for a short period of noise, every Sound came through indicating both groundwave and skywave were in play. The Skywave kicked in when the sun came up and at times when the skywave was weak, there surely was a lot of Multipath, GW vs. SW. This could be observed in the BER going up doing those periods.

    Illustrates the challenge of NVIS comms.

  • Hello all,


    Great idea!!! Here are my suggestions:


    - 8 Frequencies Scanning

    - Automatic voice recording when a connection is established

    - Logs of the voice recording should get a timestamp


    Thanks a lot and good luck.


    73 Josef

    DE3JGA  

  • I would think the recording could be done outside of the kiwi world with something like


  • Audacity can also be set to record over a set threshold.

    Preferences - Sound Activated Recording.

    WA2ZKD
  • @WA2ZKD and Powernumpty...

    Many thanks for the tip!

    73 Josef

    DE3JGA

  • edited June 2021

    3GALE is primarily military these days, much dynamically encrypted (content and addresses), so a dedicated decoder for it is not really very useful for UTE monitoring. This could change if non-mil users convert eventually to 3G. But that is unlikely to happen soon, since 2G ALE is ubiquitous and adequate for most civilian or governmental applications.

    Decoding and listing 2GALE "from" and "to" address calls of all types are the most useful. Store/append to a text file with timestamp and frequency. The most recent should be displayed in a live window. The addresses with channel timestamps should also be appended to an ongoing local file of "heard" addresses. For 2G ALE, the USB dial frequency (phantom carrier frequency) is most commonly utilized, rather than the centre of energy in the RF signal. That is because 2G ALE is defined in its protocol by audio modulation frequency, when utilized with channelized HF gear.

    One of the most useful features I could recommend for an ALE KiwiSDR receiver would be a "To" and "From" address decode Alarm. To implement it, to or from addresses would be inputted by the user and stored. The program would present visual and audible alarms whenever a stored address is received by the SDR. This would enable to KiwiSDR to monitor for calls to an individual or a net, and alert the user. It would also dovetail well with remote monitoring and stations which have dedicated ALE radios.

    AMD texting is very much still in widespread use. The reason many think it is not, is because the exchange is often so quick that 2 channel per second scanning receivers are unable to eavesdrop very well on it, and they are programmed to skip over and ignore direct calls from one station to another. AMD also forms the basis of most ALE position tracking and status reporting (as well as proprietary protocol extensions).

  • edited June 2021

    3G and 4G operation tends to be "behind a curtain"... even some 2G is treated the same way in terms of public info... WRT to freqs. schedules etc. Spoofing of 2G is part of what prompted 3G.


    Ever wonder what 1G was?

  • I have AMD TX'ing on 4416.9 now on 0,10,20... 50 seconds

  • of course that works as prop permit as it is 110 miles from my RX:8075

  • AMD msg sent = QBF but first receipt did not = that. Perhaps someone with other decode means can see what they get

  • edited June 2021

    I imagine thhat this data scheme means that something more needs to be in the decoder beyond what is use for the address

    Although I am not recovering the original data, what is recovered is the same each time I receive a decent call.

  • jksjks
    edited June 2021

    Your signal (recorded), from my latest standalone version (not merged into Kiwi extension yet) with more decoding:

    [00:00:22] [FRQ 0.00] [To: ] [His BER: 3]
    [00:00:22] [FRQ 0.00] [CMD] [AMD: "THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG"] [His BER: 3]
    [00:00:24] [FRQ 0.00] [Sounding THIS WAS] [From: BAS ] [His BER: 2]
    


    Others (from recordings people sent me), including a DTM:

    [00:00:30] [FRQ 0.00] [Call] [From: G8JNJ0 ] [To: G8JNJ3] [His BER: 0]
    [00:00:38] [FRQ 0.00] [Call ACK] [From: G8JNJ3 ] [To: G8JNJ0] [His BER: 20]
    [00:00:42] [FRQ 0.00] [Call EST] [From: G8JNJ0 ] [To: G8JNJ3] [His BER: 0]
    [00:00:54] [FRQ 0.00] [CMD] [AMD: "MESSAGE READS 12345"] [His BER: 0]
    [00:01:04] [FRQ 0.00] [Call] [From: G8JNJ0 ] [To: G8JNJ3] [His BER: 10]
    [00:01:04] [FRQ 0.00] [CMD] [AMD: "CONFIRM 54321"] [His BER: 10]
    


    [00:00:31] [FRQ 0.00] [Call] [From: SHAEENQ2 ] [To: USMANQ7] [His BER: 1]
    [00:00:31] [FRQ 0.00] [CMD] [DTM: "WE ALSO PASSED MSG TO OUR SECTION ALREDY TODAY MORNING ABOUT HOLIDAY HERE"] [His BER: 1]
    


    WA2ZKD
Sign In or Register to comment.