Arduino and fsk 4-level decoder

[spadoinkle]

Hi, I am curious if anyone here has written any software that interfaces to an fsk 4-Level decoder circuit such as this: Image:4levfsk1.gif - The RadioReference Wiki

Specifically, I am trying to determine how to translate the output of the dataslicer to ones and zeros. My loose understanding is that the dataslicer converts the possible combinations of 4 (or 2) frequencies to a voltage level which raises various combinations of the 3 output pins. I think it should be relatively easy to read data in from the slicer with an Arduino, I know that several different pieces of software use this same circuit. I don't care about formatting or the protocol coming in at this time, as long as I can convert the decoder output to ones and zeros.

Thanks,
spadoinkle

[Unitrunker]

The decade + old WinFlex code did something like this ...

static const char lookup[16] = { 0, ... };
// upper four bits carry CTS(4), DSR(5), RI(6) and DCD(7).
unsigned char msr = <read modem status register from UART>
msr >>= 4;
msr &= 0xF; // not really necessary.
unsigned char bits = lookup[msr];

In the code snip above - fill in the lookup table with what you think is the appropriate bit pair for a given pin combination. 4 level FSK circuits don't use the ring indicator pin so either mask it off or code your lookup table so that it has no impact on the resulting bit pair.

[MattSR]

Originally Posted by spadoinkle

Specifically, I am trying to determine how to translate the output of the dataslicer to ones and zeros.

The constellation point to dibit mapping is specific to the protocol. (ie, the conversion of FM deviation into ones and zeros) Are you aiming to use this with P25 be chance? I tried to get ahold of some CML CMX series chips to interface to an AVR to make a simple P25 repeater but they weren't interested in selling me sample quantities..

[spadoinkle]

Thanks for your replies. Unitrunker made me realize that, of course, the encoding could be different from one signal source to another, so my question was ambiguous. My first objective is to be able to decode pocsag and flex. If and when I get an Arduino to decode those then I'd be interested in supporting other fsk encoded signals like P25 as well. I have no interest in recreating the wheel though, I don't want to parse the data. My plan for world domination would be to make this a viable method of adding USB->RS232 support to any decoding software that still works with the aged fsk 2/4-level decoder circuits. Existing decoding suites would only have to read in ones and zeros from the USB output on the Arduino and process as normal. No more problems with USB-to-RS232 adapters. Obviously I'd be making this an open design in order to make it worth while to the people maintaining the software. But for now that's just a pipe dream. I just need to sit down, hook up my Arduino to my decoder, and read in some data and see what I can figure out.

[AZScanner]

My rudimentary understanding of this stuff is that it's not just what those pins get set to that matters, but when - and that's the protocol specific part. Are you trying to decode a 4800, 9600, or 19200 baud signal? If you check those pins whenever they get set without any consideration to the baud rate you're trying to decode, that won't really help you much.

Unitrunker: Have you seen what they're doing with GNURadio lately? Allegedly, you can combine a radio scanner and Ubuntu box and have yourself a handy-dandy RD/LAP decoder. I don't know if it works or not - was too busy/unambitious to try it this last weekend. But the info I found was quite interesting, including the fact that the one municipal RD/LAP system that was monitored was in the clear.

Check this out. Fascinating reading.
http://sites.google.com/site/radiora...APPROTOCOL.pdf

-AZ

[MattSR]

You need a USRP - it doesn't work with a scanner.

[spadoinkle]

I've seen that guys page before. While he suggested his results could be recreated with a scanner/decoder rig, like MattSR said, he's using the USRP for all of his work published on his site. Unless you just happen to have one laying around it would be much cheaper to just get a real RD-LAP modem and receive the data that way if you want that protocol, especially the 19.2k data. Hamvention is only a couple months away.

Anyway, I intend to follow up on this thread with more results from my Arduino project, I don't want to see this thread get hijacked just yet .

[Unitrunker]

My only objection to GNU radio is the USRP - for two reasons. #1 is cost. It's like $400 for the base unit; that's before you add RF modules to enable coverage for a given band. #2 is the USRP gives you transmit capability. Understandably, #1 is no objection for some folks and #2 is actually considered an advantage for many. For me, this is strictly a receive only hobby.

Back to the slicer ...

The real problem is how the slicer interfaces (including the 4 level variety) to the serial port. It does not use the RxD pin to deliver a sequential bit stream - in contrast to how most operating systems expect. The workarounds to make a slicer work in Windows and Linux are a pain. We should have fixed what's been broken for over a decade - the slicer.

What spadoinkle is trying to accomplish with a microcontroller can be done with an FPGA or even a lowly PLD. Of course, if an Arduino is what you have, by all means use it!

Try this on your microcontroller: write some code to "slice" the incoming waveform at a bit rate that is a multiple of 1200 (like 19200). Send the bit stream out the TxD pin. For RS232, 2 out of every 10 bits must be replaced with start and stop bits for asynchronous framing of the data. You've lost some accuracy but the raw signal is over sampled the so this is negligible. The host PC can down-sample the data to whatever is needed (eg. 3600, 4800 or 9600 baud for Motorola and EDACS). The modern UARTs and USB/serial adapters buffer the incoming data so the host Windows PC isn't clobbered by interrupts like its DOS counterpart.