SparkFun Forums

[brainwav]

I'm trying to get a RF-KLP RF link pair working. I understand how it works and have read all the thread on here about this RF. I will be using machester encoding. I have a few questions:

1)I only need to send data when I need to. This will be maybe 30 times an hour for one hour a day. Should I use a transistor or a relay to turn the power on the transmitter?

2)How will the receiver know when to start receiving info? I will have it on all the time, but since I am not transmitting all the time, I don't understand how it will distinguish between noise bytes and transmitted bytes.

3)when I send a byte, how will the receiver know that its the start of that byte and not the middle? Is there a way to sync it up?


Denis

[Philba]

there are a fair number of threads that discuss these topics. in brief:

1) either would work but I don't understand why you would use a relay if power was an issue? You will probably draw more current for the coil than the transmitter. If power isn't an issue, why use anything? I'd use a P-MOSFET though there is a recent thread on this exact topic. Note that an ASK transmitter is essentially only transmitting when a high is presented at the data pin.

2) use a lead in sequence that is an illegal manchester encoding. The likelihood that will be confused as noise is fairly low. Design your manchester state machine with error transitions so that you will tell when noise gets injected in the middle.

3) see #2 - use a lead-in sequence. Design your protocol so that it is either resilient to lost transmissions or uses some sort of acknowledge (i.e. 2 way). I sometimes use a sequence number so I can tell on the receive side if I'm losing packets. Good for debugging, if nothing else.

[brainwav]

Thanks for the quick reply

1) Ok, I will use a transistor, since I already have one to turn the relay on. I'll take out the relay.

2)What does an illigal manchester encoding look like?? Can you point me to an example of a manchester state machine? I have an idea for a state machine that matches the incoming bit with the lead-in sequence, would that work? and if something doesn't match, it just restarts matching from the start of the lead-in bits. If I get to the end of the lead-in (matching), then I listen for the data.

3)I guess that state machine would work. I have no way of doing a 2-way thing because of power requirements on the transmitter side. The transmitter will only be on for less than 5 seconds at a time. and about 20 times a day to save on power.

Denis

[Philba]

illegal manchester encoding - think about the definition of manchester coding. You should easily see that there are sequences that can never be generated. for example, 3 clocks worth of high or low. You will want to balance the overall transmission. For example, I've used 4 clocks high, 4 clocks low as a lead in. That will never be confused as a manchester sequence. Start your state machine looking for the leadin. I also use a "leadout" sequence that is similarly illegal. This way my reception code doesn't need to parse the packet structure.

Note that because of the leadin and need for error checking, I would try to send more than one byte of payload at a time. Clearly it's a balance between efficiency (overhead vs payload) and noise susceptibility (longer sequences have a higher probability of errors).

[brainwav]

Hi, I've found some code on here to do what I want to do. Basically I will sent some non-manchester code bytes first to sync the serial ports, then then the preamble using the manchester coding and verify it on the receiving side. Then send the data. I guess I will have to sent this 3 times to make sure that the receiving end gets the message and is not thrown off by noise.

Does this sound like a good idea?