OOK transmission format decode problems

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

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.

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

You can reduce the sync word to one byte and try them each until you get data. :confused:

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?

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.

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