Forum: GNU Radio Having issues getting APT-DECODER Sample working

Dear Gnuradio,

  I'm trying to run the following gnuradio program:
http://www.oz9aec.net/index.php/gnu-radio/gnu-radi...

I found a WAV file online to use as the input to the APT-Decoder, so I
fed it in. Unfortunately, the output file resulted in a bunch of '^@'
characters instead of the expected ASCII(0) through ASCII(255).

To make sure that the Audio file source was actually producing an
output, I hooked up an AUDIO_SINK block between the File Source and the
Band Pass Filter. I heard the expected APT sound.

I then proceeded to drop in a WX GUI FFT Sink, and kept getting the
following error:

Has anyone seen this?
-----

Traceback (most recent call last):
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/plotter/plotter_base.py",
line 187, in _on_paint
    for fcn in self._draw_fcns: fcn[1]()
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/plotter/plotter_base.py",
line 59, in draw
    self._draw()
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/plotter/grid_plotter_base.py",
line 407, in _draw_point_label
    label_str = self._populate_point_label(x_val, y_val)
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/plotter/channel_plotter.py",
line 151, in _populate_point_label
    label_str += '\n%s: %s'%(channel, common.eng_format(y_value,
self.y_units))
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/plotter/common.py",
line 82, in eng_format
    coeff, exp, prefix = get_si_components(num)
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/plotter/common.py",
line 48, in get_si_components
    exp = get_exp(num)
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/plotter/common.py",
line 37, in get_exp
    return int(math.floor(math.log10(abs(num))))
ValueError: cannot convert float NaN to integer

Hi Tommy,

Most likely the file (wav) you have found is in 8bit.
Try to adjust your source file sink.

Patrik

On 10/6/12 5:37 PM, Patrik Tast wrote:
> Hi Tommy,
>
> Most likely the file (wav) you have found is in 8bit.
> Try to adjust your source file sink.
>
> Patrik
>
Dear Patrik,

  What do you mean by source file sink?
I used soundconverter to convert the WAV file to mp3, and then back to a
32-bit sampled WAV. I tried it, and it failed with the same error.

I also tried to use FFT with byte input, but that doesn't exist. The
only options are float or complex.

Again thank you!

Tom

Hi Tommy,

>What do you mean by source file sink?
I thought you were using GRC and if the file was downloaded from me I
know it is (recorded) in 8bit 2.4kHz carrier.

You will find a lot of hits regarding APT when googling and be very
objective, most are copy -> copy....

Sure we can/could convert it to 16, 32, 64, 128 bit etc.
The fact is that APT is 8bit so why change it to 32bit?
The result will be a 4x bigger file almost full of zeroes since again
only 8 bits are used (gray scale). If recorded as 16bit it will be of
course 2x bigger than required since max is again 0x0000 ffff.
In this case you wont win if more bits are used.

APT bandwidth is ~30kHz @ 137Mhz

Some samples here, don't convert:
http://www.poes-weather.com/~patrik/apt/audio/24_June_2009/
Images & tests:
http://www.poes-weather.com/index.php?view=article...
3Asunday-6th-july-2008&Itemid=73&option=com_content

24/7 images:
http://www.poes-weather.com/~patrik/apt/logs/daily/

Patrik

On 10/7/12 6:44 AM, Patrik Tast wrote:
> The fact is that APT is 8bit so why change it to 32bit?
> http://www.poes-weather.com/index.php?view=article...
> 3Asunday-6th-july-2008&Itemid=73&option=com_content
>
> 24/7 images:
> http://www.poes-weather.com/~patrik/apt/logs/daily/

Thank you for the reply; I took one of your 8bit samples:
 www.poes-weather.com/~patrik/apt/audio/24_June_2009/090723_213010_NOAA_17.wav

and opened it in the file source, and ran the gnuradio program. If I do
a cat of the output.dat file, I found that there was nothing in it. I
then opened it in VIM and found the following string repeated:

"^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@"

I think those aren't valid characters so maybe the float_to_uchar was
unsuccessful.

Did you use a different algorithm? Do I need to multiply the input to
fit it between the 0->1v range before the 255 multiplier?

Sincerely,
Tommy Tracy II

Hi Tommy,

> fit it between the 0->1v range before the 255 multiplier?
>

oooh...I suspect that you have something set wrong now?
I can not understand what you are doing.

To test I downloaded
http://www.poes-weather.com/~patrik/apt/audio/24_J...

Screenshot while decoding using my software
http://poes-weather.com/~patrik/tmp/Screenshot%20f...
2023:08:09.png

This should be decodable using any software.
I suspect you are on the wrong track now.

Patrik

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

You will have to investigate more.

Try download/build the
<http://www.qsl.net/5b4az/pkg/apt/wxapt/wxapt.html> or (I use)
<http://atpdec.sourceforge.net/>

It shouldn't be that hard...

Patrik

On 10/7/12 7:23 PM, Patrik Tast wrote:
> You will have to investigate more.
>
> Try download/build the
> <http://www.qsl.net/5b4az/pkg/apt/wxapt/wxapt.html> or (I use)
> <http://atpdec.sourceforge.net/>
>
> It shouldn't be that hard...
>
> Patrik

Yes, thank you. I would run wxapt or atpdec if my goal was to decode the
APT images, but my goal is different.

I would like to take a gnuradio program that is currently running on one
machine, and split it among several computers. I chose this program
because A it does not require a USRP (I feed in a straight RAW file), B
it is non trivial and has a branch; it is also fairly compute intensive
when compared to other 'easier' gnuradio applications.

My goal is to get APT decoding to work in gnuradio without using any
other programs.

Thanks again!

Tom

> Yes, thank you. I would run wxapt or atpdec if my goal was to decode the
>
> Thanks again!
>
> Tom
I put this together a few months back, attached.

It decodes it down to the symbol level, but doesn't turn it into useful
bitmap files or anything.  That's a little outside the scope of what
   Gnu Radio is intended for.

On 10/7/12 9:48 PM, Marcus D. Leech wrote:
>> Yes, thank you. I would run wxapt or atpdec if my goal was to decode the
>>
>> Thanks again!
>>
>> Tom
> I put this together a few months back, attached.
>
> It decodes it down to the symbol level, but doesn't turn it into useful
> bitmap files or anything.  That's a little outside the scope of what
>   Gnu Radio is intended for.

Perfect! I like your algorithm. What I have done is taken Patrik's WAV
file and fed it in to the flowgraph after the Frequency demodulation
block, removing everything that came before.

The result was a completely grey image. Also, the FFT didnt show
anything. I will continue tweaking it.

Tom

Hi Tommy,

Excellent idea!

Just some facts and questions to consider when you render APT data to an
image:
- which satellite transmitted to me at that time and that location using
those TLE:s that file, every satellite (NOAA-15,-18,-19) got different
settings. You will need to add a satellite tracker (libpredict?).
- users want to configure how to render the received images (false
color, IR, Video A/B etc) easily.
- some user want to project the received data on a map, I used geotrans.
- there are infinite possibilities how to render the data.
- etc

You will have to build your own custom block that does at least some of
the above.

I have done it and been there. I started APT:ing 2002 and did it wrong,
I programmed everything in windows and it can't be cross compiled. It
did not take 100 lines of code it took million lines and then some.
Feel free to copy my code
<http://www.poes-weather.com/index.php?Itemid=74&op...

This is beyond GNU Radio, GR does RX/TX user decipher the data...

Honk when we can test your decoder.
Good luck,
Patrik