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

[Tommy James Tracy II]

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


-- 
  Tommy J. Tracy II
 Computer Engineering
University of Virginia

APT_Decoder.png
Description: PNG image

signature.asc
Description: OpenPGP digital signature