selcal/scripts
2024-05-29 22:07:16 +09:30
..
selcald Fixed some broken scripts 2024-05-25 13:07:57 +09:30
.gitignore Added live detector graph 2024-05-27 13:11:27 +09:30
add-user-to-audio-group.sh Replaced cout logs with log4cxx 2024-05-25 12:05:34 +09:30
audio-capture.sh Added live detector graph 2024-05-27 13:11:27 +09:30
audio-pipe.sh Added live detector graph 2024-05-27 13:11:27 +09:30
filters.py Cleaned up the selcal-detect.py file, so I understand it better 2024-05-29 22:03:59 +09:30
live.py Added live detector graph 2024-05-27 13:11:27 +09:30
raw-to-wav.sh Fixed weird stuff about tones not registering properly - was an audio conversion stereo/mono bug 2024-05-26 00:00:49 +09:30
README.md Added README with algorithm notes 2024-05-27 12:11:10 +09:30
requirements.txt Moved python/* into scripts directory 2024-05-25 14:57:44 +09:30
samples.py A bunch of WIP stuff needing cleaning 2024-05-25 19:59:41 +09:30
selcal-detect.py Fixed some print statements 2024-05-29 22:07:16 +09:30
selcal-fft.py Final bit of cleanup in selcal-fft 2024-05-27 11:47:45 +09:30
tonegen.py Moved python/* into scripts directory 2024-05-25 14:57:44 +09:30
tones.csv Moved python/* into scripts directory 2024-05-25 14:57:44 +09:30
tones.py Added tones generator 2024-05-26 23:14:14 +09:30
utilities.py Final bit of cleanup in selcal-fft 2024-05-27 11:47:45 +09:30

Planned algorithm

From selcald: One possible solution to this problem is to step back from trying to determine the frequencies of the individual tones and to instead verify that:

  • There are two tones present
  • The difference in frequency between the two tones matches a pair of known tones in the alphabet

The author of selcald seems awfully hung up on trying to ensure correct detection of the silent period between two tones. I don't think this is worth actively trying to detect, as it is more important to find two dominant tones for a period of ~1 sec, followed by another 1 sec with two dominant tones. The silence period is irrelevant - according to the spec of 0.2 +/- 0.1 sec at the transmitter it could be impossibly short to reliably distinguish between successive A*-A* tones at the receiver.

Terrible pseudocode

collect samples from audio source <wavfile, arecord>
low pass & decimate if necessary
<simultaneously>
    run wide fft over a large sample window
    detect peak bin (with some hysteresis)
    if peak bin within tone band:
        assume difference is due to doppler shift
        gradually adjust expected freq(s) for tone(s) to match
    record RMS energy into buffer

<simultaneously>
    run correlation over small sample window
    For each tone in the alphabet:
        Cross correlate the audio with the adjusted tone
        Record normalized tone energy into tone buffer

    For tone record in tone buffer:
        sort tones by amplitude
        if:
            - the two highest amplitude tones are within 3 dB of each other
            - the two highest amplitude tones are at least 3 dB greater than the next nearest tone
            - the sum of the two highest tones account for at least 60% of the modulation energy (-2.22 dB)
                (as determined relative to stable RMS energy calc'd by wide fft)
                (nominally 90% / -0.458 dB)
        then:
            record dominant two tones in tone buffer

        if any two tones are dominant tones for the majority of previous 1 sec:
            record dominant two tones in code buffer
            reset tone detection counter (prohibit detecting codes for another 0.5 sec)

    upon code record in code buffer:
        if dominant code previously occured within 1.25 sec
            emit SELCAL detection
            reset code detection counter (prohibit detecting codes for another 0.5 sec)