discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Problems decoding ASK at high bitrates


From: Meyer S. Jacobs
Subject: [Discuss-gnuradio] Problems decoding ASK at high bitrates
Date: Mon, 1 Aug 2011 14:15:53 -0700

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

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).

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]