Re: [Discuss-gnuradio] Having issues getting APT-DECODER Sample working

[Patrik Tast]

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&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

On Sun, 2012-10-07 at 21:34 -0400, Tommy James Tracy II wrote:
> 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
> > 
> > 
> > 
> > 
> > On Sun, 2012-10-07 at 18:31 -0400, Tommy James Tracy II wrote:
> >> On 10/7/12 4:24 PM, Patrik Tast wrote:
> >>> Hi Tommy,
> >>>
> >>>> 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:
> >>>>
> >>>> "address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@^@"
> >>>>
> >>>> 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?
> >>>>
> >>>
> >>> oooh...I suspect that you have something set wrong now?
> >>> I can not understand what you are doing.
> >>>
> >>
> >>
> >> I have attached an image of my GRC flowgraph. It is meant to be an exact
> >> copy of the one presented at the following website:
> >> http://www.oz9aec.net/index.php/gnu-radio/gnu-radio-blog/440-simple-apt-decoder-prototype
> >>
> >> I have either made a mistake, the website has a non-functional flowgraph
> >> on it, or the input WAV file is incorrect; I think you verified the WAV
> >> file.. so i think it is one of the first two.
> >>
> >>> To test I downloaded
> >>> http://www.poes-weather.com/~patrik/apt/audio/24_June_2009/090724_032529_NOAA_18.wav
> >>>
> >>> Screenshot while decoding using my software
> >>> http://poes-weather.com/~patrik/tmp/Screenshot%20from%202012-10-07%
> >>> 2023:08:09.png
> >>
> >> From the looks of the screenshot you sent, you are using a different
> >> application. Do you use Gnuradio under the hood?
> >>
> >>>
> >>> This should be decodable using any software. 
> >>> I suspect you are on the wrong track now.
> >>>
> >>> Patrik
> >>
> >> Thanks again,
> >> Tom
> >>>
> >>>
> >>>
> >>> On Sun, 2012-10-07 at 13:26 -0400, Tommy James Tracy II wrote:
> >>>> On 10/7/12 6:44 AM, Patrik Tast wrote:
> >>>>> 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&id=100%
> >>>>> 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:
> >>>>
> >>>> "address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@^@"
> >>>>
> >>>> 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
> >>>>
> >>>>>
> >>>>> Patrik
> >>>>>
> >>>>> On Sat, 2012-10-06 at 22:43 -0400, Tommy James Tracy II wrote:
> >>>>>> 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
> >>>>>>
> >>>>>>> On Sat, 2012-10-06 at 16:51 -0400, Tommy James Tracy II wrote:
> >>>>>>>> Dear Gnuradio,
> >>>>>>>>
> >>>>>>>>      I'm trying to run the following gnuradio program:
> >>>>>>>> http://www.oz9aec.net/index.php/gnu-radio/gnu-radio-blog/440-simple-apt-decoder-prototype
> >>>>>>>>
> >>>>>>>> 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
> >>>>>>>>
> >>>>>>>> -----
> >>>>>>>>
> >>>>>>>> I think this means that the WAV file (float output) is producing NAN
> >>>>>>>> outputs. Is there any way that I can remove those? Anyone have any
> >>>>>>>> success doing this before?
> >>>>>>>>
> >>>>>>>> Thanks in advance!
> >>>>>>>> _______________________________________________
> >>>>>>>> Discuss-gnuradio mailing list
> >>>>>>>> address@hidden
> >>>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Discuss-gnuradio mailing list
> >>>>>>> address@hidden
> >>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> > 
> > 
> 
>