CW Decode from HO-68 using MultimonNG - Update II

(This is an update to this post)

I tweaked the string that my stupid search script uses to be "BJ1SA " - this should then take into account the proper spacing of the characters. The best result I got out from that was this (I used the data to which I'd applied a narrow band filter):

 J1RA XW XW AAA TTT AW- ATE ETT TTT TTT TTT TTT TTT TTT TTT TTT XW XW EE
BJ1SA XW XW AAA TTT AU4 TBE ETT TTT TTT TTT TTT TTT TTT TTT TTT XW XW
BJ1SA XW XW AAA TTT AU4 TNT ETT TTT TTT TTT TTT TTT TTT TTT TTT XW XW
BJ1SA XW XW AAA TTT AU4 AVT ETT TTT TTT TTT TTT TTT TTT TTT TTT XW XW
BJ1SA XW XW AAU T5H H 5 <._.......>DHSH IIIEIS

BJ1SA XW XW AAA TTT AU4 AVE ETT TTT TTT TTT TTT TTT TTT TTT TTT XW XW
BJ1SA XW XW AAA TTT AU4 TBE ETT TTT TTT TTT TTT TTT TTT TTT TTT XW XW E
BJ1SA XW XW AAA TTT AU4 AVT ETT TTT TTT TTT TTT TTT TTT TTT TTT XW XW EIE
BJ1SA XW XW AAA TTT AW4 TDT ENTTTT TTTETTNTTTTTNAAAVATUA<....._>

This appears to be better than the previous decoding. The graphical representation of the search space is show here:

As you can see there is a much smaller range of parameters where the best decoding occurs.

I have now integrated in the multimonNG decoding of CW signals into my GroundStation software and have decoded signals in realtime from a number of satellites including FO-29 and CO-55. The current implementation I use is far from optimum as I have around 2.5kHz of audio going into multimonNG, so as mentioned previously I'll be able improve the performance by additional filtering.

I've also improved the calibration of one of my RTLSDR receivers such that I can receive meteor signals from the GRAVES transmitter - more data to follow on that subject at a later date.

CW Decode from HO-68 using MultimonNG - Updated

(This is a follow-up to my previous here.)

The author of MultimonNG suggested that in addition to altering -d and -g, I should also use a bandpass filter before passing it to MultimonNG as the code does no filtering of itself. I applied a bandpass filter of around 400Hz wide. This filter is wider than I would have liked to have used, but the signal drifts due to, probably, instabilities of my RTLSDR receiver and errors on the Doppler corrections - there are ways to automatically correct this, but I've not had time to implement them yet.

If I now decode the data after applying the filter I get the following ASCII:

            W X W A A A T T T A U   A T E E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W E E
B J 1 S A X W X W A A A T T T A U 4 T B E E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W
B J 1 S A X W X W A A A T T T A U 4 T N T E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W
B J 1 S A X W X W A A A T T T A U 4 A V T E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W
B J 1 S A X W X W A A U T 5 H H 5

B J 1 S A X W X W A A A T T T A U 4 A V E E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W
B J 1 S A X W X W A A A T T T A U 4 T B E E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W E
B J 1 S A X W X W A A A T T T A U 4 A V T E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W EIE
B J 1 S A X W X W A A A T T T A U 4 T D T E D T N N T T T N E

Which is significantly better than without the filter (see previous post) and better than dl-fldigi.

Next I investigated altering the -d and -g parameters. To do this I wrote a Python script to run multimonNG that counted the number of occurrences of the string "T T T T T" were in the output. I looped over values for -d from 0 to 202, and -g from 0 to 198. The out put can be see in the graphic below (sadly I forgot to label the axes before I created it) - the y-axis is -d and the x-axis is -g:

From this is can be seen that for this data the value of -d is not too important, but the value of -g is more critical. However looking at the output for the best combination of -d and -g shows no significant difference from the results above. It is also questionable if the number of "T T T T T" in the output is really a good metric to measure decoding quality - but for the moment it will suffice!

In conclusion - make sure you appropriately filter your input to MultimonNG and you should get good results. Over the coming weeks I'll be trying with data collected from other sources which won't be so nice and clean.

CW Decode from HO-68 using MultimonNG

Using the pass from 09:45 UTC this morning, I recorded some CW from the beacon which peaked around 35-40dB over the noise. If I decode it in dl-fldigi (via an 8kHz, 8 bit WAV file) I get this output (for reference it should look like this):

* J 1 S A X W X W A A A T T T A U 4 A T E E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W
* J 1 S A X W X W A A A T T T A U 4 T B E E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W
* J 1 S A X W X W A A A T T T A U 4 T N T E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W 
* J 1 S A X W X W A A A T T T A U 4 A V T E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W
* J 1 S A X W XWUA AT**R*W X W
* J 1 S A X W X W A A A T T T A U 4 A V E E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W 
* J 1 S A X W X W A A A T T T A U 4 T B E E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W 
* J 1 S A X W X W A A A T T T A U 4 A V T E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W 
* J 1 S A X W X W A A A T T T A U 4 T D T E T T T G T T T T M T M X T M M A D**

If I use the new version of MulitmonNG I get this (using the standard default arguments - i.e. not changing -g or -d):


              X W A A A T T T A U 4 A T E E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W
B J 1 S A X W X W A A A T T T A U 4 T B E E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W
B J 1 S A X W X W A A A T T T A U 4 T N T E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W
B J 1 S A X W X W A A A T T T A U 4 A V T E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W

                W A A A T T T A U 4 A V E E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W
B J 1 S A X W X W A A A T T T A U 4 T B E E T T T T T T T T T T T T T T T T T T T T T T T T T T X W X W
B J 1 S A X W X W A A A T T T A U <..._..>A V T E T T T T T T T T T T T T T T T T T T T T T T F

So multimon certainly doesn't do a bad job, but it has some room for improvement. I'll try tweaking the values of -g, -d, etc and see how that changes  things.

Latest new & things

New TLE of Aenaes (and friends) from DK3WN makes collection a lot easier. These are a couple of packets I just received:

APRS: KE6YFA-1>CQ,TELEM:4341455255531D0040020008090B020D072837050000001000F075000070130049C08F13411D4F
APRS: KE6YFA-1>CQ,TELEM:4341455255531D0040020008090B020D080037050000001000F075000070130049C08F1341D581

Which means that the port to GnuRadio 3.7 now seems to work - it took a lot of effort due to the relocation of a whole bunch of classes from one module to another (and also some bugs the GnuRadio maintainers introduced on the way). So after a week of effort I'm back to where I was with version 3.6, and don't really have anything more to show for it! Ho hum.

I did order some better crystals for my RTLSDR receivers - although as they're at 14.4MHz I need to do some more work in order to get them usable - but it should cure the really crap frequency drift I see with the recent received I purchased.

I've just ordered a Rigol DS1052E oscilloscope - I'm not expecting much, but it should take some of the guess work out of some of the things I do! Now I just have to win the lottery and I can get that VNA I need!

I now have some test data (from HO-68) which I can use to evaluate the new CW mode in MultimonNG.