Go Down

Topic: OOK transmission format decode problems (Read 3574 times) previous topic - next topic

jradcliffe

I am working with a medical sensor that transmits some data every five minutes.  I know some specs on the transmission based on FCC information and other published material.  (OOK, 8192 bits/sec, 300khz bandwidth, 76 bits in the packet, 5 ASCII Char Transmitter ID, 402.142mhz).  The problem is the format of the transmission.  I am
using an RFM22B module from HopeRF/Sparkfun, and it wants to know the format (preamble length, sync word, CRC, etc) so it can detect a legitimate transmission before it puts it in the buffer.  I have tried guessing, but there are too many variables to make that an option.  I have a radio (being a ham) that can RX on that freq, and tried using my soundcard as a spectrum analyzer to record the signal for manual decoding into binary.  I am pretty sure the sound card is not fast enough to get a sample to use.  Also, with the transmission being only 9ms long, it's hard to catch it completely.  I am going to try reading the analog output (GPIO0) with the Arduino board next, but I am running out of ideas on how to get the pulse stream so I can decode it and determine the transmission format.  Has anyone done something like this before and have some ideas on how to accomplish this?

Thanks!

Jay

johnwasser

Download this spreadsheet:

http://www.hoperf.com/upfile/RF22B%2023B%2031B%2042B%2043B%20Register%20Settings_RevB1-v5.xls

Use it to calculate the register settings for FIFO Mode (not PacketHeader+FIFO Mode).

Send those to the radio and see what data you get in.  I hope that by using FIFO mode it will pass you the data as it arrives and not look for a packet header.
Send Bitcoin tips to: 1L3CTDoTgrXNA5WyF77uWqt4gUdye9mezN
Send Litecoin tips to : LVtpaq6JgJAZwvnVq3ftVeHafWkcpmuR1e

jradcliffe

If I read the document correctly, you still need the preamble and sync words to be correct for the FIFO mode to work.  I could be wrong though.....

johnwasser

You can reduce the sync word to one byte and try them each until you get data.  :/
Send Bitcoin tips to: 1L3CTDoTgrXNA5WyF77uWqt4gUdye9mezN
Send Litecoin tips to : LVtpaq6JgJAZwvnVq3ftVeHafWkcpmuR1e

jradcliffe

Here's what I am trying currently:
Preamble Detection Threshold (Register 0x35) set to 0x7A (giving me the longest Threshold possible- 16 bits)
Preamble Length (Register 0x34) 0x01 (smallest) to 0xff (largest) I am starting at 1 and working my way up every 10 minutes
SyncWord 3 (Technically the "first" sync word) is the only one enabled. I have this set to 0xAA (Which should be the same as the preamble 10101010)

My hope is that I can confuse the receiver to take the preamble as the preamble and the sync, and then put the next 255 bits into the buffer. So far no luck. Problem is I have no clue what the sync word could be.  my fear is that it's all too small.  9ms transmission @ 8192 bits is a shade less then < 80 bits.

So the packet structure could look like this:

0xAA            0x??     0x30     0x43     0x54     0x41     0x33     0x??     0xYY
Preamble      Sync     |-------------Transmitter ID------------|    Data      CRC

Assuming the documentation is right, 76 bits = 9ms @ 8192 bits/sec.  72 bits with a nibble left over? Maybe the preamble is longer?

jradcliffe

I have switched to using a CC1101 RF module now.  I am shocked that I can't get anywhere with either of these.  I'm not even getting the board to see that there is a signal. 

brucethehoon

Did anyone else suddenly think of Terry Pratchett when reading the post title?

Go Up