En, It's hard to judge exactly from your screen shots... if I had your .grc files and sample inputs, I might be able to do a little better! You may find the APRS test CD [1] useful, if you haven't used it already.
Here's what I get using the test CD, and aprs-wav.grc. I happened to take the screenshot just at a good moment! You can consider the bottom graph to be the output of the QD block, though in this implementation it's measuring the difference in amplitude of the 1200 and 2200 Hz tones. First, I should note, people use Bell 202, AFSK, AX.25, and APRS interchangeably... but they are not! - Bell 202 is the physical layer spec, which sends data 1200 baud with 2FSK. The "tones" used are 1200 Hz and 2200 Hz. - AFSK is a term I don't like very much... audio frequency shift keying? It often refers to Bell 202, although wouldn't P.25 C4FM be audio frequency shift keying as well? Either way, I digress! - AX.25 is a protocol which specifies a packet format and communication standard. Interestingly enough, it does not specify the physical layer at all. - APRS is an application of AX.25 which almost exclusively uses Bell 202 and NBFM VHF radios to send packets with position reports. (Much to the designer's chagrin, I might add... but when you only have UDP style frames, ensuring receipt is rather difficult...) Most of what I'm writing focuses on a generic APRS application. Anyways, with that out of the way! I'll start my discussion at the end of the receiver, and work my way back to the "audio waveform" itself. http://i.imgur.com/KOBLLDz.png The top graph shows the recovered "bits". Note how there is nice separation between the 1's and 0's, and how the waveform is nicely centered around 0. This should lead to good data recovery. The bottom graph (although not aligned with the top graph) shows the data waveform just before clock recovery. You can see the distinctive "HDLC frame sync byte" of 0x7e (ASCII ~) being repeated over and over again. This is in contrast to other radios that use (0x55) and a sync word. You can read more about it here: https://en.wikipedia.org/wiki/High-Level_Data_Link_Control http://i.imgur.com/HV3EjTE.png In the bottom graph, you can see the original audio signal. If you look very closely, you might even be able to see the sync byte being repeated (0x7e, or 01111110). Unlike your application which uses the QD block to demodulate the FSK, I'm doing a receiver more like the one you can find here on page 9. ( http://edge.rit.edu/edge/P09141/public/FSK.pdf) That's why there's a red and blue waveform that are near compliments of each other. You may find this paper interesting as well, as it explains many of the troublesome points of APRS. http://digitalcommons.calpoly.edu/cgi/viewcontent.cgi?article=2449&context=theses - Tim On Sun, Dec 27, 2015 at 10:00 AM, En Shih <seanstone5...@gmail.com> wrote: > Thanks for the reply, Tim. > > - The WBFM is a remnant I've never corrected. I now have the audio from > NBFM. > - The baudrate is 1200. > > This is the Fourier after Hilbert before QD: > <http://gnuradio.4.n7.nabble.com/file/n57488/13.png> > <http://gnuradio.4.n7.nabble.com/file/n57488/11.png> > and the corresponding time plot: > <http://gnuradio.4.n7.nabble.com/file/n57488/10.png> > <http://gnuradio.4.n7.nabble.com/file/n57488/12.png> > I am unsure if that looks right or not. > > Is it so that the signal after QD should look something like this? > <http://gnuradio.4.n7.nabble.com/file/n57488/demod_timedomain.png> > (image taken from > > http://www.indigresso.com/wiki/lib/exe/fetch.php?media=opentag:radios:demod_timedomain.png > ) > > I have tried your FSK demodulator block, and the initial result looks nice. > <http://gnuradio.4.n7.nabble.com/file/n57488/2015-12-27_23-35-40.png> > <http://gnuradio.4.n7.nabble.com/file/n57488/2015-12-27_23-40-37.png> > <http://gnuradio.4.n7.nabble.com/file/n57488/2015-12-27_23-38-51.png> > However, I haven't been able to identify the characteristic preamble for > each data packet. Am I using the block correctly, or is there some > tweaking/synchronization that I should do? > > Regards, > En Shih > > > > > -- > View this message in context: > http://gnuradio.4.n7.nabble.com/Help-decoding-Bell-202-tp57483p57488.html > Sent from the GnuRadio mailing list archive at Nabble.com. > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
