Hi Stephan,
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:
- Record a signal and test with that -- doing everything live makes things complicated and hard to reproduce.
- Use a xlating FIR filter to move a single 12.5kHz channel to 0Hz, so that either symbol is +- 4.5kHz
- this will require that you design a filter. Don't worry, that's relatively easy:
- run gr_filter_design
- 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).
- 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)
- set the decimation of that xlating FIR to something reasonable, so that rate_in/decimation > 12.5kHz/2, but not >>.
- this way, you'll get "just enough" rate at the output.
- set the center frequency to the middle of your two symbol frequencies in the input spectrum
- add visualization sinks here and there, and verify :)
- add a real high-pass filter
- 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.
- 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.
- 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.
- repeat "add visualizations" :)
- 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
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> 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> 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); 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> 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
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
