Was having a hard time getting data transfer using the ASK (another way of saying OOK) RF modules between a pair of PICs.
I’d been used to the Linx LC series in which the OOK receiver data was squelched. The constant hash present in the Spark Fun RX module data out presented a synchronizing challenge.
I created an assembly subroutine similar to a software receive UART except it uses the interrupt on change feature available on PORTB 4:7 pins to insure the bits were noise free. In addition, I also rotated the bits in to a 16 bit buffer doing a comparison after each bit received, looking for a sync byte and the start/stop bits in the right order.
Then the program switches over to the standard software receive UART.
So far it’s been rock solid. The project is still quite beta, but this was a happy step forward.
Interesting. I was able to get the hardware UART on the PICs to deal with the noise just fine. I used some snippets and info I found here and links to other sites on how to sync the hardware UART up, they give a list of binary numbers to send, then I just check the RX buffer and see if it’s what I want. Of course, between that and the sorta-manchester encoding, it’s not very bandwidth efficient, but it works.
It would be nice if there were a squelch or at least an RSSI output on these receiver modules. But they are super cheap little things, and with a little work on the code, they can get the job done for what I want to do. I might try the uMIRF next, nice looking little module.
Some of these receivers do have an RSSI output (it is labeled Analog output). The receivers that I purchased a couple of years ago have them, but there is some indication that the newer circuits have pins 2 and 3 connected together. For those receivers with the “analog” output, a simple squelch circuit (dual op-amp and three resistors) works really well.
riden:
Some of these receivers do have an RSSI output (it is labeled Analog output). The receivers that I purchased a couple of years ago have them, but there is some indication that the newer circuits have pins 2 and 3 connected together. For those receivers with the “analog” output, a simple squelch circuit (dual op-amp and three resistors) works really well.
My Spark Fun receiver has those pins tied - bummer.
RSSI would be handy for another project I was contemplating.
Has anyone built a thermometer eavesdropper to decode your neighbor’s outdoor thermometer?
As for cost, the Linx 433-LC ASK modules are about $22 for a RX/TX pair in Digi Key.
Only downside is they are SM, but position well on .010" proto-board.
Who knows, maybe Sparky could be coaxed into a Linx breakout board?
I just joined this forum so I thought I’d contribute here.
I’ve been developing custom RF solutions for years so perhaps I can offer some input
First, ASK/OOK is not the best way for data transfer of course, but hey if it’s low cost.
OK, squelching radios for data transfer is not really a good idea as it degrades the receive ability. Either you allow for hysteresis but then you’re raising the RX listening floor (your radio is less sensitive), or the squelch is ‘too close’ to maximum sensitivity so then it’s chattering anyway, defeating the purpose of not having to deal with noise…
However, you can easily use a HW UART with minimal impact on the code/CPU time and on data transfer throughput.
No ASM fiddling or Manchester schemes etc.
Here’s what you do :
Use a receive Interrupt for the UART
Implement a small state machine within this RX ISR
The state machine has the following states :
Looking for preamble
Looking for a SYNC word
Get the packet length
Read the packet data (while building CRC)
Check CRC
If CRC OK, flag RX packet and wait, else reset state machine
The principle works like this :
The preamble is set for 0x55 (or 0x5555). Reason is that this produces a 50% dutycycle signal if you account for the start and stop bits (8N1 UART settings).
This is especially useful for FSK based systems, as it trains the dataslicer as well.
It is of benefit to the ASK dataslicer too.
The last reason for this preamble is that no matter where the UART picks up the first bit in RX (from the preamble) it will always flush because the Transmitter sends a 0xFF between preamble and SYNC word. (there are enough high bits to qualify as stop)
Then the rest is easy. Just proceed with each state when the condition is met.
If SYNC hunt or CRC check state fails, reset to “hunt for preamble” state.
