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: fcn1
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
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.
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:
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.
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.
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.
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.
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&option=com_content
This is beyond GNU Radio, GR does RX/TX user decipher the data…
Honk when we can test your decoder.
Good luck,
Patrik
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.