[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Regular FM radio fine, POCSAG horrible
From: |
Marcus Müller |
Subject: |
Re: [Discuss-gnuradio] Regular FM radio fine, POCSAG horrible |
Date: |
Tue, 02 Jun 2015 10:12:03 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 |
That's pretty awesome :)
On 06/02/2015 09:44 AM, address@hidden wrote:
> If it can be of any help, I use POCSAG to illustrate one of the SDR labs I
> teach: the flowcharts are pp.4 and 5 of http://jmfriedt.free.fr/tp_sdr.pdf
> (don't
> mind the text in French, only look at the pictures) and the associated videos
> are at http://jmfriedt.free.fr/ (first two ones from the top).
>
> JM
>
>>> I am sure GR can do that, but I can't ;-)
>> I can't help but propose you change that ;) No, seriously,
>> cross-compiling GNU Radio for an ARM sounds more complicated than doing
>> non-coherent binary FSK demod, but then again, that might just be me :D.
>>
>> In fact, you're absolutely right: getting a solid signal quality before
>> attempting decoding might be a good idea. However, most probably pagers
>> don't need awesome SNR, so "somewhat noisy" might still be ok.
>>
>> so how do you get the samples into GNU Radio?
>> I guess you use the gr-osmosdr source? which sampling rate? Where in
>> your base band are your carriers?
>> What does your flow graph look like?
>>
>> Generally: If you have a RF recording, [1] might just profit from one
>> more entry, and we'd have something more tangible to talk about :)
>>
>> I'll outline the steps I'd do to try to achieve better signal:
>>
>> 1. Record a signal and test with that -- doing everything live makes
>> things complicated and hard to reproduce.
>> 2. Use a xlating FIR filter to move a single 12.5kHz channel to 0Hz, so
>> that either symbol is +- 4.5kHz
>> 1. this will require that you design a filter. Don't worry, that's
>> relatively easy:
>> 1. run gr_filter_design
>> 2. select low pass, enter your source's sampling rate, set the
>> end of the pass band to let's say 5kHz and the start of the
>> stop band to 7.5kHz (If I understand wikipedia correctly,
>> channel spacing is 12.5kHz, and symbol deviation is
>> +-4.5kHz, so from the center of the lower channel to the
>> lower bit of the upper channel it's 12.5kHz - 4.5kHz = 8kHz).
>> 3. You'll notice that if you start with a high sampling rate,
>> your filter gets ridiculously long. If that's the case, you
>> might want to reduce the sampling rate of your signal
>> source, or add a stage of half- or quarter bandwidth FIR
>> decimation (with a decimation factor of 2 or 4, respectively)
>> 2. set the decimation of that xlating FIR to something reasonable,
>> so that rate_in/decimation > 12.5kHz/2, but not >>.
>> 1. this way, you'll get "just enough" rate at the output.
>> 3. set the center frequency to the middle of your two symbol
>> frequencies in the input spectrum
>> 3. add visualization sinks here and there, and verify :)
>> 4. add a real high-pass filter
>> 1. Your single-channel spectrum looks something like [1] with 0 Hz
>> in the middle. Since we've filtered away stuff above 5kHz, we'd
>> now concern ourselves with filtering away everything below 4kHz.
>> 2. Same procedure as for the xlating fir, but use the reduced
>> sampling rate and a 4 kHz high-pass with a 2kHz stop band or
>> something. The closer the stop band is to pass band, the longer
>> your filter gets.
>> 3. In principle, a 4-5 kHz real-tapped bandpass xlating fir would
>> have done the same, but doing this step by step reduces error
>> probability.
>> 5. repeat "add visualizations" :)
>> 6. You should now have a clean signal with only two peaks in your
>> spectrum at +-4.5kHz; does your external decoder deal well with that?
>>
>> In principle, you're extremely close to having your own decoder by now.
>> Non-coherent BFSK decoding would simply do the same as step 2, but with
>> two filters, each centered on either symbol frequency, baudrate-wide
>> passband, decimating to the baudrate, followed by a
>> complex-to-magnituded-squared conversion each, then something like
>> division of the 1-filter magsquared by the 0-filter magsquared, followed
>> by a threshold decision (threshold=1). You'd then be getting a raw
>> POCSAG bitstream :D
>>
>> Best regards,
>> Marcus
>>
>>
>> [1] from http://edge.rit.edu/edge/P09141/public/FSK.pdf ,
>> Watkins-Johnson Company "Tech-notes Vol. 7 No. 5 September/October 1980:
>> FSK: Signals and Demodulation", p. 8 FSK spectrum
>> <http://edge.rit.edu/edge/P09141/public/FSK.pdf>
>>
>> On 06/02/2015 12:04 AM, Stephan van Beerschoten wrote:
>>> I am sure GR can do that, but I can't ;-)
>>> Also, I don't have a good waterfall at all of the pocsag broadcast,
>>> which is probably part of why I can't make it out with my ears either.
>>> Yes, I think I have too much noise.
>>> I hope it can be overcome with the right settings and filters.
>>>
>>> I'll try to capture a screenshot of what I see. It's nothing like the
>>> screenshots in Wikipedia.
>>>
>>> On Jun 1, 2015 5:47 PM, "Marcus Müller" <address@hidden
>>> <mailto:address@hidden>> wrote:
>>>
>>> Hi!
>>> I personally think the soundbite from wikipedia is broken, since
>>> it's 11kHz sampling rate violates Nyquist ;)
>>> Well, I must admit that my preferred way of analyzing this
>>> wouldn't be the audible reproduction; if you can see it clearly on
>>> the waterfall, and "optically" have enough dB between the carriers
>>> and noise, then you'll be fine decoding it.
>>>
>>> Now, I trust you're actually seeing excessive noise -- this might
>>> point to problems with your receiver (unsuitable antenna, too much
>>> noise in the amplifier, too little gain, intermodulation). The
>>> first step in limiting noise is always adding appropriate
>>> filtering. Can you add a FIR that selects your POCSAG channel out
>>> of your sampling bandwidth?
>>>
>>> Best regards,
>>> Marcus
>>>
>>> On 06/01/2015 11:28 PM, Stephan van Beerschoten wrote:
>>>> You're right in that I need more than GR. The audio of a pocsag
>>>> broadcast is very distinct. It's also clearly visible on a
>>>> waterfall.
>>>> The problem is that I have too much static in there. Way too much
>>>> noise. I can't get the gqrx module (where I tune and see the
>>>> waterfall) set right so the reception is fine.
>>>> I think the Wikipedia article had a soundbite of a pocsag
>>>> encoding. If you listen to it you'll notice it's very distinct.i
>>>> just have 90% noise and I can hear the broadcast in the very
>>>> background.
>>>>
>>>> On Jun 1, 2015 5:25 PM, "Marcus Müller" <address@hidden
>>>> <mailto:address@hidden>> wrote:
>>>>
>>>> Hi again,
>>>>
>>>> Ok, I'm not familiar with the standard POCSAG, but if you got
>>>> a signal that you still need to decode with something else,
>>>> how do you know you don't get clear reception? What is your
>>>> measure for "good reception"?
>>>>
>>>> As far as I read the English wikipedia, POCSAC uses a 4.5kHz
>>>> binary FSK, so can you see the two alternating frequency e.g.
>>>> in a waterfall plot of your RX signal?
>>>> Ideally, you'd directly be able to see the 512, 1200 or 2400
>>>> baud.
>>>>
>>>> To explain a bit more:
>>>> GNU Radio is not a decoder for any specific standard; think
>>>> of it as the LEGO of SDR. You can build amazing things with
>>>> it, in fact, there's a lot of examples that come with GNU
>>>> Radio, and useful and complex standard implementations (FM
>>>> receiver, DTV transmission!), but if you need to have
>>>> something that's not there, you might need to a) use someone
>>>> else's Out-Of-Tree module or b) implement that functionality
>>>> yourself. So I must admit that I don't have the slightest
>>>> idea which settings you're referring to :) Maybe you're
>>>> interested in a quick&dirty introduction to GNU Radio [1].
>>>>
>>>> In the case of POCSAG, I remember gr-pocsag being a thing
>>>> (search for pocsag on cgran.org <http://cgran.org>); I can't
>>>> remember the original author, and I presume it's pretty much
>>>> dead -- but I'd love to be proven wrong.
>>>> Also, pyboms has pocsag-mrt package, but that seems to rely
>>>> on GNU Radio 3.6.2, if the Readme is correct, so that's
>>>> pretty dead, too.
>>>>
>>>>
>>>> Best regards,
>>>> Marcus
>>>>
>>>> [1] https://github.com/iZsh/pocsag-mrt
>>>> On 06/01/2015 10:18 PM, Stephan van Beerschoten wrote:
>>>>> It is. I plan on running the output through a utility that
>>>>> can decode it. However, before that can happen I need to
>>>>> find out how I can get a clear reception of the broadcast.
>>>>>
>>>>> On Jun 1, 2015 4:15 PM, "Marcus Müller"
>>>>> <address@hidden <mailto:address@hidden>>
>>>>> wrote:
>>>>>
>>>>> I'm a bit confused, I though POCSAG was a text pager system?
>>>>>
>>>>> On 06/01/2015 10:04 PM, Stephan van Beerschoten wrote:
>>>>> > Hi Guys,
>>>>> >
>>>>> > I compiled gnuradio for my ODROID ARM platform, and I
>>>>> can listen to
>>>>> > regular wideband radio just fine. I am using a
>>>>> Generic RTL2832U with
>>>>> > Rafael Micro R820T tuner.
>>>>> >
>>>>> > The radio quality is fine, and even when using the
>>>>> rtl_fm tool
>>>>> > directly (off topic for this list), it works.
>>>>> >
>>>>> > However, when I switch channels to 155.520 to capture
>>>>> POCSAG
>>>>> > broadcasts I cannot get a clear reception. I can't
>>>>> find any decent
>>>>> > documentation on GR to tell me what each setting is,
>>>>> and I am not a
>>>>> > HAM radio operator so some of the basics evade me.
>>>>> >
>>>>> > I can't get decent POCSAG reception with the rtl_fm
>>>>> tool either, so
>>>>> > this is probably a setting thing somewhere.
>>>>> >
>>>>> > Why can't I get clear reception? Any pointers?
>>>>> >
>>>>> > Stephan
>>>>> >
>>>>> > _______________________________________________
>>>>> > Discuss-gnuradio mailing list
>>>>> > address@hidden <mailto:address@hidden>
>>>>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Discuss-gnuradio mailing list
>>>>> address@hidden <mailto:address@hidden>
>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>
>
- Re: [Discuss-gnuradio] Regular FM radio fine, POCSAG horrible, (continued)
- Re: [Discuss-gnuradio] Regular FM radio fine, POCSAG horrible, Stephan van Beerschoten, 2015/06/01
- Re: [Discuss-gnuradio] Regular FM radio fine, POCSAG horrible, Marcus Müller, 2015/06/01
- Re: [Discuss-gnuradio] Regular FM radio fine, POCSAG horrible, John Malsbury, 2015/06/01
- Re: [Discuss-gnuradio] Regular FM radio fine, POCSAG horrible, Stephan van Beerschoten, 2015/06/01
- Re: [Discuss-gnuradio] Regular FM radio fine, POCSAG horrible, Marcus Müller, 2015/06/02
- Re: [Discuss-gnuradio] Regular FM radio fine, POCSAG horrible, Stephan van Beerschoten, 2015/06/02
- Re: [Discuss-gnuradio] Regular FM radio fine, POCSAG horrible, Marcus Müller, 2015/06/02
- Re: [Discuss-gnuradio] Regular FM radio fine, POCSAG horrible, Stephan van Beerschoten, 2015/06/02
- Re: [Discuss-gnuradio] Regular FM radio fine, POCSAG horrible, Marcus Müller, 2015/06/02
- Re: [Discuss-gnuradio] Regular FM radio fine, POCSAG horrible, jean-michel . friedt, 2015/06/02
- Re: [Discuss-gnuradio] Regular FM radio fine, POCSAG horrible,
Marcus Müller <=
- Re: [Discuss-gnuradio] Regular FM radio fine, POCSAG horrible, Stephan van Beerschoten, 2015/06/02
- Re: [Discuss-gnuradio] Regular FM radio fine, POCSAG horrible, West, Nathan, 2015/06/02
- Re: [Discuss-gnuradio] Regular FM radio fine, POCSAG horrible, Stephan van Beerschoten, 2015/06/02
- Re: [Discuss-gnuradio] Regular FM radio fine, POCSAG horrible, Philip Balister, 2015/06/02
- Re: [Discuss-gnuradio] Regular FM radio fine, POCSAG horrible, Stephan van Beerschoten, 2015/06/02