Re: [Discuss-gnuradio] Problems decoding ASK at high bitrates

[Nick Foster]

On Mon, 2011-08-01 at 14:15 -0700, Meyer S. Jacobs wrote:
> Hey,
> 
> I'm currently working on an open-source reimplementation of the
> FasTrak protocol using GNU Radio and the Ettus E100. What I have so
> far (currently non-functioning) is available here:
> https://github.com/Meyermagic/OpenFasTrak

Cool project! Really excited to see what you come up with.

> 
> Anyway, I've run into a couple of problems, most probably related to
> my complete lack of DSP experience, but I thought I'd try making a
> mailing list post anyway.
> 
> First, I currently have the E100 with a Class-4 MicroSD card, which
> should guarantee sustained 4MB/s write speed.
> 
> My first problem comes from the fact that the bitrate of the FasTrak
> communications is 300kbps, and with manchester encoding on the bits,
> sampling at 600kHz should get me exactly one sample per half-bit. I
> initially tried recording data at 915MHz carrier with a 64MHz sample
> rate, and simply storing it to a file, in order to analyze it later
> (and extract the "agency code" I need to communicate with a FasTrak
> transponder). Unfortunately, this would theoretically require a
> 512MB/s sustained write speed, so I got frequent overrun errors (it
> took me some time of trying to analyze the incomplete stored data to
> realize the printed "O"s were on stderr, and were significant).

First off, you won't be able to do anything at a 64Msps sample rate. Let
the USRP help you -- the FPGA will decimate data for you. Run it at
1Msps and then resample it later to whatever sample rate you like.

If you're not doing extended recording, you might also consider making a
ramdisk and recording to that, then copying over to Flash storage
afterward.

--n

> 
> To compensate for this, I tried capturing at an offset carrier
> frequency, bandpassing for the real carrier, demodulating it, and
> thresholding the data, all before writing to a named pipe. On the
> other side of the pipe, I had a C program reading and
> run-length-encoding the data, outputting to a real file. Each half-bit
> being ~107 samples at 64 MHz sample rate (which comes to a bit over
> 4MB/s if I write 1 byte for every half-bit), I figured, with buffered
> i/o, I would be able to receive the whole message. Unfortunately, this
> didn't seem to be true, as I again got overrun errors, and found
> mostly runs of 0s in the output file.
> 
> Finally, I realized that since the reader to transponder polling
> message is so short (around 786.3us, including the transponder's
> response packet), and there are only 2^16 possible Agency Codes, I
> could try every possible agency code in under a minute. I wrote some
> simple C programs for this purpose, and chained them together in a
> shell script to output a run-length-encoded version of the data to
> send. Testing the decoding program on my desktop, I got hopeful
> results:
> 
> address@hidden tests]$ time ./rle2samples fuzzmessage.rle.dat /dev/null
> 
> real    0m41.390s
> user    0m41.217s
> sys     0m0.077s
> 
> On the E100, though,
> 
> address@hidden:~/New# time -p ./rle2samples fuzzmessage.rle.dat /dev/null
> real 1044.22
> user 36.43
> sys 1006.12
> 
> So, this time, I got underrun errors when I tried to send the data.
> 
> rle2samples.c available here, for reference: https://gist.github.com/1118976
> 
> Can you guys offer any help with this situation?
> 
> -Meyer S. Jacobs
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio