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

[Patrik Tast]

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.

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

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

Patrik



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