I've been working on a decoder for these APT images for a while now. I started years ago, in Python, and was able to implement a working decoder quickly. A few months ago, I came back to the project and decided to move to C++. I have not been making good progress, and I don't know what I am doing wrong.

See here for a description of the signal. Briefly, 256-level 4160 Bd image data is amplitude modulated onto a 2400-Hz subcarrier, which is frequency modulated onto a 137-MHz RF carrier.

Question the first: how is it possible (or rather, how it is meaningful) to use a carrier with frequency lower than the message? Is my misunderstanding perhaps to do with the frequency content of the message itself, rather than the rate it has been sampled at? Or something else?

I have the signal stored as a WAV file, 16-bit LPCM at 20800 Hz. I read these samples into an array, working one line of decoded image at a time. APT is two lines per second, so my array contains 10400 elements.

Now, the problem seems to come down to AM demodulation. It is my understanding that the proper way to do this is via computing the magnitude of the analytic signal. I do so by taking the DFT of my array, setting the negative frequency components to zero, and doubling the positive elements. Then iDFT back, and take the magnitudes as the demodulated signal.

I do some median filtering, do a naïve low-pass by zeroing bins in DFT, scale to 256 levels, and generate an image. Seems relatively simple -- so why does the output look so horrible? I am not sure what else to try. From my explanation, is there something I am doing I ought not be, etc.?

My decoded image

The bars on the right side look to me to be the telemetry frames, so it seems that my process is "working" in some sense. I'm not sure what the source of the high-frequency "circle" curves are you can see in the image.

  • $\begingroup$ It's often a good instinct to mistrust Wikipedia's wording on signal descriptions! On a quick skim, I couldn't find an authorative source for the APT standard. Do you happen to know one? $\endgroup$ Jan 6 '21 at 8:52
  • $\begingroup$ Are you translating your working Python code to C++? If so, the problem is likely in your implementation of the envelope detector or a filter. Maybe use an existing library, like liquidsdr, first, and then replace each function with your own code, one by one? $\endgroup$
    – MBaz
    Jan 6 '21 at 14:42
  • $\begingroup$ @MarcusMüller noaasis.noaa.gov/NOAASIS/pubs/… $\endgroup$
    – MBaz
    Jan 6 '21 at 14:44
  • $\begingroup$ @MBaz found that, too, but it seems too vague to actually be guidance... $\endgroup$ Jan 6 '21 at 14:54
  • 1
    $\begingroup$ @MarcusMüller Evidently! The thing that drew me to start this project the first time (over two years ago!) was the lack of a feature rich, free software decoder for APT. I had left the project for a long time, and noticed someone had forked it a few months ago, which to me showed there was still interest in the (dying) protocol. So I decided I’d move to Qt/C++, my framework of choice, and try to implement a strong toolkit for working with APT. It has been a long time since one has been around. $\endgroup$ Jan 6 '21 at 15:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.