Forum Replies Created

Viewing 9 replies - 1 through 9 (of 9 total)
  • Author
    Replies
  • in reply to: Audio decoding #11845
    Rabbe Fogelholm
    Participant

    The integrating decoder currently works like this: It looks for dashes by integrating the signal multiplied by a dash-like folding function over a time interval that is slightly longer than one dash, thereby sensing the edges as well as the bulk of the dash. This procedure is repeated at a great number of points along the entire telegram, of the order every 10 ms. Since the length of an individual dash varies, this is then redone for a range of possible dash lengths.

    The integrals with the highest scores point out the likely dashes. Once a dash has been located, many nearby candidates can be dropped as they would overlap.

    The same procedure is then used to find the likely dots, using a shorter integration interval and a dot-shaped folding function.

    Some dash and dot candidates will overlap, especially when a dash is a bit weak in the middle. A choice is then made, by comparing the strength of the dash candidate to the strengths of the two candidate dots. It turns out that the strength ratio limit is a quite sensitive parameter – either many “t” will come out as ”i”, or the other way around, if the limit value is not right. I tweaked the limit by testing against a set of SAQ recordings of varying quality.

    I was happy to find that the integrating scheme seems to do better than the previous tone/silence edge-finding schemes. However, my impression is that the ear+brain is unbeatable when the signal to noise ratio is poor. And the brain does it with no floating-point arithmetic whatsoever!

    in reply to: Audio decoding #11384
    Rabbe Fogelholm
    Participant

    Until now the detection of dots and dashes in gerke-decoder has relied on finding the points in time where “silence” changes to “tone” and back. This method works fine with strong signals, but it is sensitive to noise: The timing gets disturbed, false dots may be detected, true dots may be missed, dashes may be misinterpreted as dots, etc. All of this causes the decoded text to be garbled.

    There is a new version 3.2.3 of the decoder that doesn’t rely on tone/silence detection at all. Instead it computes integrals of the signal over short time intervals, thereby locating what are the most likely dots and dashes. This produces better results than previous versions, especially so for recordings with considerable noise.

    Try it out if you like: Build from source at https://github.com/fowlay/gerke-decoder/ or use this executable jar: https://privat.bahnhof.se/wb748077/radio/3.2.3/gerke-decoder.jar

    If you notice problems, let me know.

    in reply to: Audio decoding #10598
    Rabbe Fogelholm
    Participant

    Version 3.1.5 is available. The handling of unexpectedly long dashes is improved. Such “super-dashes” can appear if the dip between two tones becomes too short or shallow. Super-dashes are now interpreted as “dot dash”, “dash dot” or “dash dash”, depending on timing and position of the dip.

    in reply to: Audio decoding #10094
    Rabbe Fogelholm
    Participant

    Version 3.1.1 is available. A new option -T has been added, controlling the output style (lower case, upper case, or capitalized, and line length). Furthermore .mp3 files can now be given as input; this requires the ‘mpg123’ (www.mpg123.de) conversion utility – use your host system package manager to install it.

    in reply to: Audio decoding #10035
    Rabbe Fogelholm
    Participant

    There is now a new version of gerke-decoder: 3.1.0. This version fixes a coding fault – now decoding works well also in case there is a period of silence at the beginning of the recording.

    A new option -M has been added, whereby histograms of tone lengths and space lengths can be drawn. Have a look here: https://privat.bahnhof.se/wb748077/radio/2023-02-13-grimeton/

    As before, the program source and build instructions are here: https://github.com/fowlay/gerke-decoder

    Building from source is straightforward on Linux. Alternatively you may use this pre-built executable jar: https://privat.bahnhof.se/wb748077/radio/3.1.0/gerke-decoder.jar – you simply run it with “java -jar gerke-decoder.jar”

    Comments, questions and suggestions are welcome! You can reach me in this forum, or on github.

    in reply to: Audio decoding #9582
    Rabbe Fogelholm
    Participant

    It is sad to hear that the Old Lady is not fit to sing out over the oceans this summer. Let’s hope for a steady and fast recovery.

    Analyzing old recordings can be done anytime though! There is now a version 3.0.0 of the gerke-decoder program, where adaptivity against frequency drift and fading has been added.

    The program expects input in .wav format and prints out the Morse code message as cleartext. Information about audio frequency, words-per-minute rating, timing of inter-character spaces, etc can be printed too. The signal can be displayed graphically for studying dashes and dots shapes, garbled characters and such.

    Recordings in .mp3 format work well also, after converting to .wav format with some tool like Audacity.

    By default the program listens for audio in the comfortable audible range, but a different frequency range can be specified – even up at 17200 Hz if a recording of the raw antenna signal has been made.

    Find the program here: https://github.com/fowlay/gerke-decoder

    Building from source is straightforward on Linux. If you don’t have a Linux box you may instead use this pre-built executable jar: https://privat.bahnhof.se/wb748077/radio/3.0.0/gerke-decoder.jar

    Comments and ideas are always welcome.

    in reply to: Audio decoding #9220
    Rabbe Fogelholm
    Participant

    The UN Day SAQ transmission is approaching – so what could be a better time for an updated version of “gerke-decoder” 🙂

    The latest addition is a decoder routine based on least-squares fitting of straight line segments to the signal data, thereby locating the dashes and dots. My hope is that this could be a bit more noise insensitive than the other decoders, which all look for on/off transitions of the signal in one way or the other.

    As before, try it out if you like: https://github.com/fowlay/gerke-decoder – if you have questions I will try to help, here or on github.

    in reply to: Audio decoding #8989
    Rabbe Fogelholm
    Participant

    I have uploaded a new version (2.0.1) of gerke-decoder. More filtering and decoding options are available, please see the README.md file. If you recorded one of the recent SAQ transmissions it may be fun to try and decode it. Any feedback welcome, here or on github: https://github.com/fowlay/gerke-decoder

    in reply to: SAQ transmission on October 24th 2020 (NOT FOR QSL) #8659
    Rabbe Fogelholm
    Participant

    Outdoor recording in Sollentuna, Sweden, JO89xk. Very damp weather and less-than-ideal antenna. Capture of the SAQ signal made directly with Audacity on laptop and exported as 44100 samples/s 16-bit mono WAV file.

    Offline analysis of the WAV file indicates that SAQ was sending at 17206 Hz?

    Using the very versatile HDSDR program (www.hdsdr.de) in CW mode I was able to write down the message of the day, after really many listenings due to poor S/N ratio. A lot of fun; thanks to all who made this possible!

Viewing 9 replies - 1 through 9 (of 9 total)

Subscribe!

Be the first to know about upcoming SAQ transmissions by subscribing to our newsletter.

No, thanks!