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" <marcus.muel...@ettus.com > > <mailto:marcus.muel...@ettus.com>> 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" <marcus.muel...@ettus.com > >> <mailto:marcus.muel...@ettus.com>> 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" > >>> <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>> > >>> 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 > >>> > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> > >>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >>> > >>> > >>> _______________________________________________ > >>> Discuss-gnuradio mailing list > >>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> > >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >>> > >> > > > -- JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 32 av. observatoire, 25044 Besancon, France _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio