I am sending a data packet of 5 bytes of 8 bits long + a start and stop bit. My first byte consists of a hex value of 5. The transmitter is either cutting it off or the receiver is clipping it. I can’t seem to find any data on what the start and stop bits should be. Should the start be a positive going pulse or go negative. Same goes for the stop bit. All the data after the initial byte is correct, it seems the first byte is used to wake up the transmitter or receiver. Any thoughts on this??
Are you using the hardware uart in your MCU? IF so, you can check what the transmitter is sending by temporarily connecting the MCU to a max232 circuit just for debug purposes and then seeing the display on your terminal.
Working with these modules, I send a two byte preamble 0x55,0xAA to synchronize the receiver with the transmitter. Then a four byte packet is sent with the last byte being a checksum of all the bytes in the packet with the exception of the two preamble bytes. The packet will be sent 4 or 5 times just to ensure the receiver received it.
There are other ways to decode such as manchester decoding, however the easiest way would be to use an encode/decoder pair such as the Holtek HT12D/HT12E series.
I recently built a system using the Holtek devices and it is very reliable.
There is lots of source code available if you specify what MCU you are using and the language you program with.
I’m using the UART from a Mega168, I have a scope hooked up and can see the data fromt the Tx pin and moniter the Rx on the receiving MCU. The transmit data looks fine, the receiver is totally dropping the first byte.
The first byte I had set to 0x00 because I noticed it was dropping data bits, the second is 0x55 and the last is 0xAA. The third and fourth are address and data. I look for a 55 and AA before I even consider looking at
the address and data bytes.
I also notice on the Rx side the pulse width is thinner, not 2400 like I sent. I may slow down the baud rate to see if that helps.
The receiver has an automatic gain control (AGC) that has to adjust to the incoming signal. Most designs send a few (3) characters prior to the actual data to allow the receiver to adjust itself.
Shoefly2k:
The first byte I had set to 0x00 because I noticed it was dropping data bits, the second is 0x55 and the last is 0xAA. The third and fourth are address and data. I look for a 55 and AA before I even consider looking at the address and data bytes.
Your receiver code should ignore the 0x55,0xAA and look for a specific start byte. This is the only way i have been able to make these things work semi-reliably with a hardware uart on the avr. (and without a hardware encoding/decoding chip) Are you using the uart interrupts or polling? It is a totally different thing to have the system work perfectly with a wire. The receiver module is constantly receiving garbage whereas an avr connected to another avr will not receive anything.
I got it working. Not seeing the start bit of my first byte was the issue. I now toggle the TX enable and pull that line low prior to enabling it and sending my packet. This allows my receiver to see the start bit. Before the receiver would show a high 3 or 4 bits into my first byte, that would screw up my packet. Essentially my receiver start bit was 3 to 4 bits off.
Shoefly2k:
I am sending a data packet of 5 bytes of 8 bits long + a start and stop bit. My first byte consists of a hex value of 5. The transmitter is either cutting it off or the receiver is clipping it. I can’t seem to find any data on what the start and stop bits should be. Should the start be a positive going pulse or go negative. Same goes for the stop bit. All the data after the initial byte is correct, it seems the first byte is used to wake up the transmitter or receiver. Any thoughts on this??
thanks,
cory
Greetings,
Send before your data some preamble bits as 0xcc or 0xaa.
Also, don’t forget to implement an error detection routine… you must do this if you want data integrity.