This flowgraphs takes the 49kHz audio from observations, re-samples it to 62.5kHz like in the original flow graph, does the exact same filtering and feeds it into the NOAA APT sink from the gr-satnogs master.
Now we’ve got a new problem: The resulting png looks perfectly alright.
So hints on what I might be missing here would be highly appreciated.
Currently the only thing that I can think of is that audio written to the file been down-sampled to 48kHz and hence has a smaller bandwidth.
This may filter out some artefacts, that otherwise cause trouble for my line syncing code.
Other than that I’m currently out of ideas.
Also thanks to Alexander for spotting my typo and opening a merge request:
After @DL4PD helped me to stare at things and poke flowgraphs,
we noticed something.
Running my sample flowgraph on the exact same file on a Pi gives me a slanted image as well.
My Pi has a recent enough gr-satnogs installed that it has the same APT sink code as the one on my desktop machine.
So something seems to go wrong when running on ARM.
Interesting idea might have to look into that at some point.
I had the idea that I should take an image decoded on the satnogs station
where the syncing code just didn’t do anything at all and compare it to the same one decoded on my computer with syncing disabled.
In an ideal world that would be pixel perfect identical images.
And there’s our problem.
Everything with large changes from one pixel to the net,
such as the noise at the beginning and end and of course the sync markers is ever so slightly different on the when decoded on the station.
That’s why the line sync code can not find the markers.
So I wrote little python script to look for the sync markers in slanted images from the network.
It uses the same algorithm than the sink, as I was hoping to prototype something more robust with it.
Turns out it identifies the markers just fine for all my test images.
Red indicates potential type A markers, blue potential type B markers.
Since the brightness of the pixels in the PNG are 1:1 the samples processed by the gnuradio module it should work on the station just as well.
I can’t even spot the point where it wrongly since and jumped all over the place.
And even if there was one it should sync fine on the next line.
This is starting to get really weird.
After freeing my raspberry pi 3 from an other permanent test installation I can debug the code directly on the target platform.
Here’s what I found so far:
For some reason the first sample passed to the sink on the Pi will always be NaN.
Since arithmetic operations with NaN will also yield NaN this sample ‘poisons’ the floating average obtained exponential smoothing, which is used by the code looking for the markers.
For some bizarre reason this never occurred on x86 systems.
I’ve added code to skip the NaN samples, which seems to work okay,
but I’ll need a little while to fully test it.
