Laipac TLP/RLP 315mhz

Can I control the receiver/transmitter with a 16F84A and 12F629 respectively? All diagrams I can find use the HT12E and HT12D to endcode/decode.

When I read the PDF above that describes the transmitting/receiving modules, I was left with many questions.

Basically, how do these things work? Let me explain. When I pull transmitter low, does the digital data out pin of the receiver go low as well? Isn’t that the point? I thought it would be simple to test this by making a LED 4x7 display on the receiving end say “----” when the pin was low and “SGnL” when it was high. Then I made the transmitting end simply put negative voltage on the data-in pin and take it off, sort of like blinking a LED, only blinking the negative voltage on the transmitting pin about every second or so.

Well, the problem is this: If the transmitter is off, the receiver will show SGnL for about a second, and then it will light up both SGnL and ---- at the same time (jumping back and forth so quickly that they both appear lit). This is very strange, as I would expect the pin to be low if there is no transmitter.

Hooking up the tranmitter, it appears that the correct result is show on the display only for maybe a tenth of a second after the transistion. After that, both ---- and SGnL appear. This leads me to believe that if nothing is being transmitted, the pin somehow oscillated back adn forth between 0 and 1, and during transition, it is 0 or 1 for a tenth of a second.

What is the deal with this? How am I supposed to transmit data and then read it? Does this have anything to do with TTL input and ST (Schmidt trigger) input? What is the difference?

Also, all diagrams I see with this device are using HT12E to transmit and HT12D to receive. Should I be using these, and what do they do? What is the advange? Please help.

rewguy

Welcome to RF!

It’s noise. The receiver is ALWAYS receiving something. It is meant to output only quick bursts of information - that way you will never see a constant low, only for a part of a second. You will need to start transmitting information recording in bytes rather than simple highs or lows.

We have used the tx/rx pairs for a multitude of data transmissions using all sorts of PICs (16F88 to 877A, 628 to 628, etc). The trick is catching all the data and making sure you aren’t recording noise.

Remember that you must set any UART to no higher than 4800bps. This is the max data rate for the TLP/RLP series.

-Nathan

Thanks a lot Nathan.

Just a quick question then: If I am trying to make a simple RF remote control that does only one function, what should I have the transmitter send when I don’t want the receiver to pick up anything?

If I pick some random byte to send that is supposed to mean for the receiver to do something, how is the receiver supposed to know that I am now sending it valid data instead of just trash? Is there a website you happen to know of that has “RF theory” or RF basics?

Thanks a lot

Andrew

RF is always a fun topic! When you use an inexpensive transmitter/receiver pair like Laipac modules, you will have to develop a data encoding method and a transmission protocol to use so your system can reject invalid signals. One of the easier ways to encode data is to use Manchester encoding. In this system you send 2 bits for every one bit of data that you have. A Zero bit is transmitted as a “01” and a One bit is transmitted as a “10”. This effectively halves your transmission rate but it allows you to easily syncronize your receiver to the data you are transmitting because you never have more than 2 consecutive 1’s or 0’s in your datastream.

The HT12E encoder chip used in Laipac’s datasheet uses a different type of encoding. For Zeros it outputs “001” and for Ones it outputs “011”. With this encoding (after you are syncronized), your receiver will measure how long the signal is high to determine what bit was sent.

Once you have your encoding down, then you will have to think about your protocol. For instance, you might send your data preceded and followed by marker bits. You would combine all these bits into a packet and send it to your receiver in one burst. The receiver locks onto the marker bits which syncronizes the system and then deciphers the data bits from the stream. This is a very common approch to transmitting data between devices.

A simpler approach to control a device that is either On or Off is to have a code word for the device you want to control and then transmit that code several times to give your receiver a chance to decipher it. The HT12E works in this manner. It has 8 address bits and 4 data/address bits that it combines into one word that is 12 bits long. When you activate the encoder, it outputs the 12 bit word using the encoding I mentioned in the second paragraph of this post. The 12 bit word is outputted 4 times which gives the receiver enough time to lock onto the signal.

This sounds like a lot of work but it is necessary to ensure that the data you send is properly syncronized and less prone to noise. Once you have a routine up and running, you will easily be able to reuse it in other projects as well.

Some things to take a look at:

Sheldon’s PIC Microcontroller Page. More specifically http://www.enel.ucalgary.ca/~patterso/p … ler-5.html which explains how he used Manchester Encoding in his RC car project.

Also download the datasheet to the HT12E encoder and the HT12D decoder chips. They have good timing diagrams that show how their protocols work.

I hope that gets you going in the right direction!

-Bill

-edited for spelling

I also forgot to mention that you do not have to use the above methods to transmit your data. In places where there isn’t much noise, you might be able to directly hook up the transmitter to the hardware UART on the PIC. If you are transmitting a lot of data in a noisy environment, the UART may fall out of sync so it would be necessary to use a software based serial protocol with Manchester encoding. There are any number of ways you can transmit your data with pros and cons to each one. It is up to you to decide which combination works for you!

-Bill

Thanks a lot to both of you. I have developed a protocol using manchester encoding. I have not implemented CRC checking but I will try to add that later. 2 bytes of 1’s and 0’s (10101010 10101010) are sent to make initialize contact and let the receiver know that a transmission is to follow.

I have just a couple short questions left to make sure I am doing this correctly. The tranmission is no faster than 2400 bps, so I am using a data rate of 2000 or 1 bit every .5 ms. To sync up the receiver, I have it check about every .05 ms to see if a 1 is being sent. If it is, I wait .25 ms - .025ms = .225 ms. This should be within .025ms of the center of the bit. Then I check to see if a 1 is being sent still, then wait .5 ms, check for 0, wiat .5ms, check for 1, etc.

Is this roughly what I should be doing? Is .05 ms good enough to find the beginning of a 1?

My other question is much more simple. If I am receiveing with a 16f84A, should I use RA4, the Schmitt trigger input, or should I use RA0-RA3, TTL input? What is the difference? Also, would it be a good idea to add a large resitor from this pin to ground?

Thanks again to both of you guys. You have been a great help.

Andrew

P.S. On a slight side-note, what is the best way to calibrate the internal 4mhz oscillator in the 12f629? My 16f84A is using a 20mhz crystal. I was thinking of making blink-a-led programs for each that shuold blink the led at the same rate, then just tweak the calibration value of the 12f629 until they match up. Is this how it is normally done?

Sorry about my ignorance - I am just getting into this stuff.

Wow - the forum is getting smarter by the week. I may not be of much help soon…

I have used the TLP and RLP links for numerous projects. They are difficult to setup and trouble shoot. But once you’ve got a good encoding scheme, you’ll be set.

I like the manchester idea, but I would stick with external crystals. Because of the timing issues of an internal oscillator, you’ll be ripping your hair out.

To try to tune the internal oscialltor, I believe I read a Microchip app note about outputting a given length square wave. Using an o-scope you can view what is actually being output and then trim the osctune (?) register as need be. Trying to tune the oscillator via an LED would be pretty difficult. A slight change of 5% in the oscillator will reak havoc with a system, but your eye will certainly not notice a difference in the blink of an LED.

-Nathan

Hi, im using the TLP & RLP 434A module in a microcontroller (AVR) project. It seems the data feed from the line stays low when nothing is received. However for RS232, the data line should stay at 5V. Hence no output is observed as there is never a stop bit.

eg, if i constanly Transmit U, ill see a U on a scope, but then follwed by a constant low ack!!

Also if i tie the transmit to +5V, the receive stays high for about 1 second, and then returns to gnd.

How does one overcome this?

Thanks

Angela

Hi Angela,

It sounds to me like you are trying to use a hardware based RS232 port on your AVR. Unfortunately, the hardware ports were designed with wires in mind. It will work if you hook the transmitter directly to the UART, but it is unreliable and you can run into problems like you have already encountered. The solution is to use a software based serial port with a custom data encoding scheme. If you have a look at one of my previous posts in this thread, I recommended a format and gave a couple of links to sites that can get you started.

You will have to put a fair amount of effort into your project to get it functioning properly but once you do, you will have a reliable data transmission system with enhanced range and data integrity which will also be portable to other projects.

Good luck!

-Bill

Sparky & Forum,

For my low data rate wireless link I use the SNAP (Scaleable Network Addressing protocol) from www.hth.com

I use simple OOK AM RF modules working on 433MHz (in the UK) and a data rate of 1200 baud. This may seem slow - but is sure is reliable, 300 yards in an open field, 100 yards built up area - all from a 3.6V NiMH.

I found a PIC implementation of SNAP on the HTH site written by a couple of Italian gentlemen - originally for the PIC16F84.

I re-cooked this for the F88 and it fits into about 850 bytes - including all the CRC routines. Some of these are redundant if you just want to use 16 bit CRC and 8 bit node addressing

A very simple implementation could be written in C.

I now have a couple of remote thermometers - solar powered - one in my greenhouse, and the other probing the depths of the compost heap.

I converted a couple of solar power lamps ($8 each) to house the PIC wireless transmitters. These make a neat waterproof housing complete with a 2" x 2" solar cell (about 4.1V) 2 x AA Nicads and a brilliant white LED and booster circuit.

These have been running happily all summer.

Anyone interested in the asm code for my SNAP wireless link - contact me directly.

regards,

Ken

Hi rewguy, & forum

I noticed that you are sending data at 2000 baud.

I did this once for a project - because it seemed to fit the system timing / clock divide ratios. I wish I hadn’t :frowning:

I now use either 1200 baud or 2400 baud because I can use my PC and standard serial com port and hyperterminal or similar to debug the received data.

I have a version of the SNAP transmission protocol running on a PIC16F88 if it is of any interest to you. Runs at 1200 baud and is really robust and reliable even with low cost AM rf modules.

I have also noticed that the lower the data rate - the greater the range. Although the transmitted messages take longer to send, and are thus more prone to interference and corruption from other sources, I found that I get much better performance at 1200 baud than 2400 baud.

regards,

Ken

Ken:
Anyone interested in the asm code for my SNAP wireless link - contact me directly.

Hey Ken,

I’m definitely interested!!! my email is susanlau_3@hotmail.com

Do you also have the code in C?

thanks :smiley:

Hey… I’m Diego, and i’m trying to send a burst of data to a microcontroller (37 Bytes specifically)… I’m using Software Uart routines to do this, and i managed to send data even at 9600 bps…

Anyway, i didn’t see any difference transmitting at 4800 or 2400 bps… While I transmitt continuosly, it seems to be ok… but, if i send that data burst (37 bytes)… it doesn’t work, since when it’s inactive, it gets a lot of noise and maybe it causes receiver to miss bytes or have sync problems…

I read about the manchester encoding, and it might be laborius to write code for that… Specially for the receiver, since it must get some kind of sync stream that states the begining of the transmission…

An ‘1’ is transmitted as ‘01’ and a ‘0’ as ‘10’… I know that, but what if you miss the first zero, how could you state the end of the sync pattern???.. Should i write code for a more complex encoding with three or more bits???.. Is there any other way of improving rf tx performance without that coding??? (I even have CRC5 and CRC16 routines working propertly, but changing the transmission scheme seems to be a lot of work… and extremately hard to debug)…

Do you know where to find an implementation of this bit encoding scheme??? I’m using a PIC12F629 as a transmitter, and a PIC18F2550 as a receiver… If it’s in assembler or C, better…

Thanks!!!

the really cheap Amplitude modulated radios need you to keep the bit stream duty cycle near 50% ones and zeros. They don’t work with too many successive ones or zeros. Hence, coding schemes are used.

These schemes do not double the number of bits as you mentioned above.

No matter, you always need error detection via either CRC8 (simple table lookup) or checksum (trivial). Error correction in cheap systems is usually by using a negative acknowledgement message from the receiver or omitting a positive acknowledgement message at the receiver. The sender reacts by retransmitting. A message sequence bit or number allows the receiver to deal with lost or duplicate messages in this process.

Actually, what i meant is not to duplicate bitrate or anything… i meant ‘10’ as a transition from 1 to zero, etc… I’m clear about what manchester encoding means, but i’m not so sure about how to implement it…

Manchester receivers carry out some convolution and stuffs “simple” in hardware, but not in software… I would poll the data rx pin and check for the time between transitions or something, but i’m not very sure of how can it be done, since missing a single transition (for example, the first one) and the whole message would be wrong…

That is without counting on noise, since the receiver switches randomly and it’s pretty hard to know if it’s noise or not… If you know about an algorithm “not soo hard to implement” in C, please let me know… I’m kinda lost here…

About the Crc, i have already tested crc16 & crc5 routines (loop_implemented), and work fine… however… they are usefull only for checking purposes (in my application), since It’s a one-way transmittion (unidirectional, i think is the word… sorry for my spelling, I don’t speak english too good)…

Thanks for your time… and your help!!!

It takes a short time for the AGC in the RLP to adjust itself to the

carrier from the TLP. If a 0 is transmitted too long the AGC

will revert to full gain and garbage will be received. This is where

manchester encoding comes in.

(I’m not sure if it’s actually an AGC or a squelch, I’ve never found

documentation on the inner workings of the TLP/RLP modules).

To transmit packet:

Enable the transmitter with TXEN=1. The idle pattern of the PIC UART

is a 1, so this will turn on the TLP. Add a pulldown resistor on the PIC

TX output (TLP data in) so when the UART TX is disabled (Hi-Z) the

TLP is off.

Wait about 16ms.

Transmit the manchester encoded packet.

set TXEN=0, TLP is off.

For receive:

The UART will be reciving junk most of the time which will need to be

ignored. Manchester encoded data has invalid patterns which can be used as a start marker. The receiver interrupt will look something like:

/* reset receiver on error */

if OERR {

CREN=0;

CREN=1;

}

/* receive byte */

rx_byte = RCREG;

switch (state):

/* 1st start byte is 0xCC */

case 0:

if rx_byte == 0xCC then set state to 1

/* 2nd start byte is 0x33 */

case 1:

if rx_byte = 0x33 then set state to 2, set rx_buf_index to 0

else state = 0

/* assume receiving packet now */

case 2:

/* start byte in data resets state machine */

/* other invalid patterns detected on decode */

if rx_byte = 0xCC then set state to 0

else

rx_buf[rx_buf_index++] = rx_byte

if rx_buf_index == PACKET_LEN set state to 3

case 3:

/*

  • do nothing, packet received and ready for decode

  • main loop will reset the state machine when ready

*/

To manchester encode

/*

  • net_msg is the vanilla input. message assumed to be 8 bytes

  • net_tx_buf is manchester encoded output 18 bytes first

  • two will be the start code (0xCC,0x33).

*/

void net_msg_encode(void)

{

unsigned char i,j,k,l,b,vb,mb;

/* index to encoded message */

l = 2;

/* foreach byte in the message */

for (i = 0; i < 8; ++i) {

/* get vanilla byte */

vb = net_msg*;*
/* foreach nybble */
for (j = 0; j < 2; ++j) {
/* manchester byte=0 */
mb = 0;
/* foreach bit in the nybble */
for (k = 0; k < 4; ++k) {
/* get a bit */
b = vb & 0x01;
/* next bit in vanilla byte */
vb = vb >>1;
/* next twobit in manchester byte */
mb = mb >>2;
if (b == 0)
mb = mb | 0x40; /* 01 */
else
mb = mb | 0x80; /* 10 */
} /* k */
net_tx_buf[l++] = mb;
} /* j */
} /* i */
} /* net_msg_encode /
_/
_
* input is net_rx_buf manchester encoded
* output is net_msg
* return >0 if decode failed (illegal byte sequence)
*/
unsigned char net_rx_decode(void)
{
unsigned char i,j,k,x,tb,mb,vb;
/* tb=two bit,ijkx=counter,mb=manchester byte,vb=vanilla byte */

i = 0;
for (x = 0; x < 8; ++x) {
vb = 0;
for (j = 0; j < 2; ++j) {
mb = net_rx_buf[i++];
for (k = 0; k < 4; ++k) {
tb = mb & 0x03;
vb = vb >>1;
if (tb == 2) {
vb = vb | 0x80;
} else if (tb != 1) {
net_msg[0] = net_rx_buf[i-1];
return i+1; /* decode error */
}
mb = mb >>2;
} /* k */
} /* j */
net_msg[x] = vb;
} /* x */

return 0; /* good */

} /* net_rx_decode */

Manchester receivers carry out some convolution and stuffs “simple” in hardware, but not in software… I would poll the data rx pin and check for the time between transitions or something, but i’m not very sure of how can it be done, since missing a single transition (for example, the first one) and the whole message would be wrong…

That is without counting on noise, since the receiver switches randomly and it’s pretty hard to know if it’s noise or not… If you know about an algorithm “not soo hard to implement” in C, please let me know… I’m kinda lost here…

The UART will take care of the timing issues for you. The cost is an extra stop and start bit sent over the air. Assuming the absence of other transmitters and using pseudo-code in my previous message the chance of the UART getting confused on start and end positions of bits in a character while receiving a data packet is pretty low. That’s what a CRC or checksum is for though.

I don’t understand why use manchester in that case - you are taking a balanced encoding and re-encoding it in NRZ. Kind of wastes the Manchester benefits.

I don’t bother with a uart to send manchester. Just use an illegal manchester sequence as lead-in/lead-out and stuff it directly in the transmit pin of the TLP. Receive is the harder part anyway.

I don’t understand why use manchester in that case - you are taking a balanced encoding and re-encoding it in NRZ. Kind of wastes the Manchester benefits.

Without encoding the data a long string of 0’s will upset the AGC in the receiver, resulting in random noise from the RLP. The encoded output from the UART is still DC balanced although I’ve never understood why it’s necessary with these modules. It may be that only the AGC needs a DC balanced bitstream and using the op-amp / comparator method described here a few weeks back would work without needing to encode. That said, when trying to get a pair to work initially I also noticed that when sending a long string of 1’s then a 0, the 0 would show up as a 1.

mark

to transmit on an AM cheap radio, I suggest that a standard UART is unlikely to work. Most software implementations I’ve seen toggle an output pin using simple code to take the data, shift it, XOR it to yield manchester, etc.

The uart approach might work if you use a lookup table or, as listed above, a state machine, to preclude too many succssive ones or zeros.