RTTY support

[darkstar007]

Would it be possible to add RTTY support to your great program? I mainly come across RTTY when decoding the telemetry from high latitude balloons - at various baud rates, number of bits, etc. At the moment I have to use dl-fldigi but that doesn't work how I'd like it to work, I'd much rather go via a pipe with raw data than via pulse audio.

Thanks again for maintaining this program (I see you've recently added CW which I'll be trying out shortly),

Matt

[EliasOenal]

While RTTY doesn't sound too hard to implement, I don't think I'll feel like implementing it anytime soon. I'll keep the ticket open nonetheless, maybe someone else wants to do it. Regarding CW I have to warn you that the timing detection is far from perfect so far, you probably want to override it. (e.g. -y -d40 -g70)

[darkstar007]

OK - but disappointing!

(I've tried the CW decoder without much luck yet - when I get a moment I'll actually measure what values I should be using for '-d' & '-g' and see if that makes a difference. The data I'm trying is from a real pass of VO52 which isn't totally doppler corrected (it drifts by a few 100Hz) and only peaks at around 15-20dB over the noise.)

[EliasOenal]

If you define DEBUG 1 in morse_demod.c it'll show you the DIT/GAP lengths it detected. Also feel free to send me a sample and I'll have a look.

On 9/1/13 12:58 PM, darkstar007 wrote:

OK - but disappointing!

(I've tried the CW decoder without much luck yet - when I get a moment I'll actually measure what values I should be using for '-d' & '-g' and see if that makes a difference. The data I'm trying is from a real pass of VO52 which isn't totally doppler corrected (it drifts by a few 100Hz) and only peaks at around 15-20dB over the noise.)

— Reply to this email directly or view it on GitHub https://github.com/EliasOenal/multimon-ng/issues/15#issuecomment-23622751.

[darkstar007]

OK, I'll try that later today.

I'll sort out a subset later (and probably tweak some of the detection/filter settings), but if you want a challenge, here's my data (22050kHz, signed int, intel byte order):

https://www.dropbox.com/s/liu7qipzesd6i70/vo52_cw_raw.dat

[darkstar007]

If you're interest I've recorded a new pass of HO-68 which is here:

https://www.dropbox.com/s/yr8ndjbbhkyprtt/ho68_cw_raw.dat

and did some quick comparisons with dl-fldigi here:

http://mattsrfstuff.blogspot.co.uk/2013/09/cw-decode-from-ho-68-using-multimonng.html

Edit: Let me know if I've messed up any of the links.

[EliasOenal]

fldigi utilizes FFT which results in a narrow bandpass filtering all the unrelated noise. The CW decoder I wrote for multimon-ng on the other hand was optimized for performance. (on my system it processes 1h of input data in less than a second) Applying a bandpass prior to processing with multimon-ng should improve the output.

[darkstar007]

I've put up a new blog page with some results from after applying a bandpass filter and also look at the optimum values for -g & -d:

http://mattsrfstuff.blogspot.co.uk/2013/09/cw-decode-from-ho-68-using-multimonng_21.html

[EliasOenal]

Did you use -y (disable auto timing detection) in addition to -g (gap length in ms) and -d (dit length in ms)? Without -y it just changes the initial values before the auto detection kicks in, that would explain why it made barely any difference. Finding he right -d and -g values while setting -y should also fix the character spacing. ("BJ1SA XW XW" vs "B J 1 S A X W X W") Also if you set "#define DEBUG 1" in demod_morse.c it should tell you the auto-detected timings, which should be a good point to start from. I'll add this option to the verbosity level -v when I find the time.

I am thinking about having an optional bandpass filter as well, yet I am not too sure on how to automatically find the passband, especially if there are several transmissions in parallel. I guess automatically following drifting signals should be possible though.

[darkstar007]

Yeah, I had the -y option on - I'll attach the code to the end of this.

OK I'll add in that #define and see what it says - I remember you mentioned that earlier, but I forgot - sorry.

Yeah, making these tools 'clever' is the really hard part - and getting them to always do the right thing is really, really hard!!

from subprocess import check_output

import numpy
import scipy.misc as misc
import struct
from matplotlib import pyplot
import os

decoder_fp_out = open('decode_5t.txt', 'w')
waste = open('/dev/null', 'w')

im = numpy.zeros((202, 198), numpy.int)
max_val = -1
pos=(-1,-1)
for d in xrange(0,202):
    for g in xrange(0,198):
        output = check_output(['/home/matt/multimonNG/build/multimon-ng', '-t', 'raw','-a', 'MORSE_CW', '-y','-d', str(d), '-g', str(g),
                               'ho68_filtered.dat'], stderr=waste)
        c = output.count('T T T T T')
        decoder_fp_out.write(str(d)+','+str(g)+','+str(c))
        print str(d)+','+str(g)+','+str(c)
        im[d,g] = c
        if c > max_val:
            max_val = c
            pos=(d,g)
            print 'New max is', max_val, pos

decoder_fp_out.close()

max_im = numpy.max(im)
min_im = numpy.min(im)
print 'min',min_im,'max', max_im, max_val, pos

if max_im < 255:
    imbyte = im.astype(numpy.uint8)
    pyplot.imshow(imbyte)
    pyplot.colorbar()
    pyplot.show()
    misc.imsave('multimon_raw_5t.png', imbyte)

im = (im - min_im) * 255.0 / (max_im - min_im) 
im[numpy.where(im < 0)] = 0
im[numpy.where(im > 255)] = 255
imbyte = im.astype(numpy.uint8)
pyplot.imshow(imbyte)
pyplot.colorbar()
pyplot.show()
misc.imsave('multimon_5t.png', imbyte)

[EliasOenal]

Maybe you could have your script look for "BJ1SA XW XW" in order to get the correct spacing. It only depends on the -g value, though. My guess is that one of the lower values for -g it came up in the prior runs would work as well.

[darkstar007]

I'd already kicked my script of looking for "BJ1SA " - but have only just got around to looking at the results. I've put up a new blog entry for them here:

http://mattsrfstuff.blogspot.co.uk/2013/09/cw-decode-from-ho-68-using-multimonng_29.html