RLP434A / TLP434A problems

Wireless & IoT
1

I am trying to connect two ATmega168 chips using USART via RLP434A / TLP434A. I met the following two problems:

  1. If there is no data on the line (transmitter sending high all the time), the receiver delivers noice. Is that normal?

I solved the problem by sending something constant and let the receiving AVR detect deviation from the constant as data. But that makes it impossible to use interrupts for the receiving AVR.

  1. The baud rate applicable is 256. Anything above that makes the line lose bits. I looked on a scope, and the on-bits seem to be much shorter than the off-bits. That seems to be the reason for the bandwidth problem. Is that normal? 2400 bps should be manageble?

I solved the problem by using 256 as mentioned. I don’t actually need a higher speed at the moment. But it would be nice to know what I did wrong in case I need 2400 later.

Right now, the transmitter and receiver antennas are less than 2 inches apart. This is because they are sitting on the same board. Could that be the cause of the problems mentined above?

All help and comments appreciated.

Atmel AVR rocks!!!

2

look down in this list. there are threads that directly address your issues.

on the asymetric pulse width - I’ve had good luck adjusting the transmitted pulse width. You will definitely get higher speed that way. by the way. I was seeing the on-width much wider than off. you sure that’s what you saw?

baud rate is 256 bps? I think you can do A LOT better than that.

yes, when the transmitter is not transmitting, you will get lots of noise. use a protocol that allows you to reject the noise. I use manchester coding and an illegal manchester sequence for the lead-in. that way, I can turn the transmitter off to save power and not get my receiver’s panties in a wad…

antennas that close could cause over modulation. best put them on seperate BBs. besides, you’ll want to do some distance tests, right?

3

Thank you for your answer.

Philba:
look down in this list. there are threads that directly address your issues.

I will scroll through the list.

on the asymetric pulse width - I’ve had good luck adjusting the transmitted pulse width. You will definitely get higher speed that way. by the way. I was seeing the on-width much wider than off. you sure that’s what you saw?

Yes, on my devices, the on is definitely narrower than the off.

yes, when the transmitter is not transmitting, you will get lots of noise. use a protocol that allows you to reject the noise. I use manchester coding and an illegal manchester sequence for the lead-in. that way, I can turn the transmitter off to save power and not get my receiver’s panties in a wad…

I see. But then there is no way of using external interrupts in the receiver when data comes in, because it must check for noise or data all the time?

antennas that close could cause over modulation. best put them on seperate BBs. besides, you’ll want to do some distance tests, right?

Yes I will try that too.

4

I use timer interrupts to check for the lead-in sequence. Once it is detected, I turn the interrupt pin on. works quite well.

there is some chance of noise being interpreted as the LI so I check for illegal transitions during receive (pulses less than a min width, illegal manchester transitions, incorrect state transitions …). using a state machine approach allows you to catch a lot of errors. Also, I use a checksum to verify a correct packet.

5

IMHO, the digital output from these types of receivers is useless without a threshold control. It is one thing to have to discriminate between other transmitters on the same frequency and another to filter out random background noise. I can’t imagine what possessed someone to build this “feature” into a receiver and suggest that people use it. As was mentioned, since the transmitter is being keyed on and off, there is always a chance for a burst of noise to trigger the data between bits. However, if you could do a reasonable job at suppressing the background noise, your problems are greatly diminished.

I hit upon the idea of using a comparator since the S/N ratio of the analog output is great enough for the idea to work. Coincidentally, I happened upon a project called “[Cricket” on the web that took a similar approach. I’m measuring about 2.8 volts on the analog output of the receiver without any incoming signal, and while the digital output is continually generating pulses due to background noise, the output of the op amp (a LM324 in my case) is clean as whistle.

Since the input to the PIC is clean, I can simply use SERIN and SEROUT to send and receive data without having to use Manchester. Seems a much simpler approach and you can still use CRC or checksums to verify packet integrity.](http://members.cox.net/berniekm/cricket.html)

6

Riden,

Can you explain or post schematic of how to connect the lm324 to the analog output.

Thanks,

Amir

7

I’m using basically the same circuit as Luhan’s Cricket project. The schematic is located [here.](http://members.cox.net/berniekm/cricket.html)

8

riden:
IMHO, the digital output from these types of receivers is useless without a threshold control. .

I was under the impression the Laipac TLP/RLP modules have an AGC. Feed a TLP module with a 20kHz square wave. Once the AGC has locked on to the signal a ‘0’ can be received on the RLP side. Leave the signal off for a little bit and the AGC loses lock and the noise shows up again.

This is why just trying to connect the TLP/RLP modules to a UART doesn’t work all that well without manchester encoding. Encoding provides sufficient 1’s density for the AGC and a preamble allows the AGC enough time to settle before the real data.

I’m still skeptical using a hardware UART with these modules works all that well. The pulse out of the RLP is skewed depending on bit rate and noise at the wrong time would confuse the UART.

I’ve looked at the data format for a few devices (wireless doorbell, keyfob remote, wireless X10) that use the 310, 315, and 434 MHz bands and they all seem to use something similar to the IR protocol where bits are defined based on the time between leading edges of pulses. See http://www.printcapture.com/files/X10_RF_Receiver.pdf. This is fairly easy to decode with a PIC.

–

mark

9

maf:
I was under the impression the Laipac TLP/RLP modules have an AGC. …

Yes, they do have AGC although I haven’t seen the specifications for the attack and decay times. One of the problems is that when there is a lack of signal, the receiver runs wide open which generates the noise on the output and the forum posts about data being outputed continously from the receiver.

maf:
This is why just trying to connect the TLP/RLP modules to a UART doesn’t work all that well without manchester encoding. Encoding provides sufficient 1’s density for the AGC and a preamble allows the AGC enough time to settle before the real data.

I understand your comment that you need to give the receiver time to adjust to the input signal and using Manchester encoding will help ensure the receiver sees enough “1” data to prevent it from jacking up the receiver gain between data bytes. I can’t speak to this receiver’s design, but most AGC circuits are designed for a fast attack (i.e. reducing the receiver’s gain when the input signal is strong) and a much slower decay (increasing the receiver’s gain when the input signal is diminished). The code that I use allows time for the AGC to set itself by sending preamble bytes before sending the actual data. I haven’t experienced issues with not having enough “1” data. However, I do send my data in ASCII format which could mitigate some of the issues (i.e. 0 is sent as 30 hex instead of 8 zero bits).

maf:
I’m still skeptical using a hardware UART with these modules works all that well. The pulse out of the RLP is skewed depending on bit rate and noise at the wrong time would confuse the UART.

I can’t speak directly to this point as the hardware UART is used for debugging or data output to the PC (I use SERIN – bit-banging instead). However, receiving noise at the wrong time would be problematic with any transmission protocol.

What I’m suggesting is that one might consider using the analog output of the receiver with a comparator instead of the digital output. I have taken this approach and am able to use SERIN (software UART) for 2400 baud data links of 75-100 feet (the maximum range that I needed for my project). As always, your mileage may vary, but I think the technique is worth a look.

maf:
I’ve looked at the data format for a few devices (wireless doorbell, keyfob remote, wireless X10) that use the 310, 315, and 434 MHz bands and they all seem to use something similar to the IR protocol where bits are defined based on the time between leading edges of pulses.

There are certainly advantages for taking this approach. The data rate and timing to a certain extent can vary, which means that the manufactures can simply their design and produce it more inexpensively. The early tx/rx modules used LC networks to establish the frequency and the performance could vary greatly depending upon QC at the time of manufacture and subsequent installation. X10 wireless modules are especially noteworthy as devices that can be tuned for better performance! Now that devices use better frequency generation approaches, SAW for example, some of the reasons for taking this approach are no longer as compelling.