Pic ==> RF module TX ==> RF module RX ==>Pic

[igeorge]

Hello,
I do not have a clue if this is the best place to ask or not, but I try.
I have a PIC controller and I want to use the UART/I2C/SPI to send a string of 48 bytes BY AIR (wireless) to another PIC.
I do not know RF communication and I tried with some of the shelf cheap transmitters and receivers from chine, but no luck.
I am looking for some guidance/schematics/parts to use.
My PIC send to the UART port the 48 bytes string, and I want to receive it on the other PIC.
Please help me if you can.
I am a complete dummy on RF communication.
I want to start simple first with the cheap Chinese TX/RX modules, then replace them with some transceivers.
In the end of the application, it is a remote control.
I know, they are millions of them from China and cheap, but I want to implement my own encryption on the transmission.
I mean, each time, I send a different packet for the same function, and somebody listening will not decode it.
Thank you

 

[KlausST]

Hi,

Rather vague informations...

I tried with some of the shelf cheap transmitters and receivers from chine, but no luck

Which transceivers exactly? (Manufacturer, partnumber, link to manufacturer internet site, datasheet) No need for luck, usually the manufacturers of the transceivers give all informations you need (guidance, schematics, parts).
They want to sell their products, thus they want satisfied customers.

You talk about UART..
So some transceivers need a preamble for the receiver to adjust.
You need to care for valid voltage levels of PIC and transceiver..and you need to choose the correct and accurate baud rate on both sides.

No need for deep knowledge about RF. The manufacturer tells you what to care for. Then the transceiver will work.

I recommend to give more detailed informations. 48 bytes of payload, but how often and at which baud rate?
What distance?

Encryption has nothing to do with transceiver, usually it's just software...

And: a picture (sketch) tells more than a lot of words..

Klaus

 

[betwixt]

Some preamble is certainly necessary to allow the receiver to adjust its gain. You probably also want to encode the data to add protection bits or to balance the number of zero and one bits in the data.

Are you using AM (aka OOK) or FM transmitters and receivers?

Brian.

 

[igeorge]

Thank you very much to both of you for suggestions, but I think I am in the wrong place.
As I said before, I do not have a clue about RF communications, protocols, or hardware.
Maybe my tile should be Pic ==> ? TX ==> ? RX ==>Pic
I will try to search on the web until I will find a forum for peoples like me, where to find a schematic and already working solution.
Thank you to both of you for the time spent.

 

[betwixt]

You only describe your modules as "the cheap Chinese TX/RX modules" but they come in two flavors, AM and FM. How they are used is quite different so we need to know which you have.

Brian.

 

[KlausST]

Hi,

where to find a schematic and already working solution.

As already written ... the datasheet gives all information you need.

For sure you can do an internet search for "rf module wiring diagram".... hundreds, maybe thousands of results.
But I guess this does not give more reliable informations ... than those provided by the manufacturer.

Klaus

 

[igeorge]

The model I bought to try from Amazon Canada is NOYITO 433MHz Ask Wireless Transmitter and Receiver Module Kit STX882 SRX882 with Copper Spring Antenna but is noting mentioned as baud rate for my TX/RX port.

 

[Aussie Susan]

Think of the combination of the Tx and Rx and a piece of wire - you put a '1' at the Tx 'data pin and a '1' will appear at the Rx data pin.
That being said, there are limitations on the 'effective baud rate' you can push dow the wire (the data sheets I've seen have a bandwidth of 200kHz).
You say you need to transfer 48 bytes - that is 480 bits (8 data, 1 start, 1 stop = 10 bits per byte) so would 9600Baud be OK - that would get the packet there in but 1/20th of a second. (If you follow the sage advice of the others above and place the payload into a structured packet that can be error checked etc. then it would take a little longer.)
Susan

 

[KlausST]

Hi,

In post#2:I asked about manufacturer ... and links to datasheets.
I see you don't want to put any effort to make helping easy for us.
You don't even tell us about the expected distance ... nor any photo/picture/sketch..

Thus I don't want to spend the time either.

Klaus

 

[FvM]

According to internet information, SRX882 is a simple ASK receiver supporting 0.1 to 9.6 kBaud data rate. An important point with this kind of receivers is that they don't work well with regular UART data streams. The data needs to be pre-encoded using Manchester or 8b/10b code. There are several software projects doing the encode/decode job as well as frame synchronisation with a preamble.

--- Updated May 9, 2022 ---

To make your life easier, use state-of-the-art FM modules, e.g. from Hope RF that do all the low-level protocol stuff inside.

 

[igeorge]

Hi,

In post#2:I asked about manufacturer ... and links to datasheets.
I see you don't want to put any effort to make helping easy for us.
You don't even tell us about the expected distance ... nor any photo/picture/sketch..

Thus I don't want to spend the time either.

Klaus

It is OK, Klaus. You maybe missed the Amazon Link. On Amazon, they do not give data sheet. They just sell a product and assume you know how to use it. Distance it is not important for my case because it is under 10 feet.

--- Updated May 9, 2022 ---

Think of the combination of the Tx and Rx and a piece of wire - you put a '1' at the Tx 'data pin and a '1' will appear at the Rx data pin.
That being said, there are limitations on the 'effective baud rate' you can push dow the wire (the data sheets I've seen have a bandwidth of 200kHz).
You say you need to transfer 48 bytes - that is 480 bits (8 data, 1 start, 1 stop = 10 bits per byte) so would 9600Baud be OK - that would get the packet there in but 1/20th of a second. (If you follow the sage advice of the others above and place the payload into a structured packet that can be error checked etc. then it would take a little longer.)
Susan

Thank you, Susan. It is clear like water. I will test to see how it works. Send my string of 48 bytes to TX pin at 9600 baud and see what I get on the other side. On the receiver PIC I have a receive interrupt so when the first byte com in, it will keep listening and store in a buffer until the byte 48.

--- Updated May 9, 2022 ---

According to internet information, SRX882 is a simple ASK receiver supporting 0.1 to 9.6 kBaud data rate. An important point with this kind of receivers is that they don't work well with regular UART data streams. The data needs to be pre-encoded using Manchester or 8b/10b code. There are several software projects doing the encode/decode job as well as frame synchronisation with a preamble.

--- Updated May 9, 2022 ---

To make your life easier, use state-of-the-art FM modules, e.g. from Hope RF that do all the low-level protocol stuff inside.

Hello FvM. Now I am scared. After reading Susan post I had the impression that it is easy, but now encoding, I will get lost again. Do you have a part number for Hope RF to use? Distance it is just 10 feet. Speed, it is not important. With the Hope chips, I will just connect TX pin in one side and RX pin in the other side and nothing else to do ? Probably I have to set the chip to work at my speed or what ever setup (one time), but no encoding and the rest.
Does Hope come in a transceiver module too ? I might add a reply if the message arrive complete at the other side.
The max speed I can use is 115k, and the max distance is 10 feet (ca. 3 meters).

 

[Aussie Susan]

Sorry but it seems to me that you are always looking for the 'easy way out' and not wanting to make the transfer of the information reliable.
I'm sorry if you missed the part of my previous message abut placing the data into a structured package of some sort. That can also be enhanced by encoding etc..
Also simply starting to read when you get the first byte and counting 48 of them is almost certainly doomed to failure. You need to take into account noise that might be received and interpreted as a value, or noise that disrupts a byte as it is received and corrupts is value etc.. Encoding helps to overcome (or at least detect) such errors as does adding things such as CRC checks.
Is it possible for the transmitter to start sending before the receiver is ready and so it will start seeing the packet half way through? Adding a header (and/or trailer) will help detect these situations.
One thing you will need to determine is if you can safely ignore a packet that has been corrupted. If not then you may need to also include some feedback mechanism to ask for the packet to be sent again. I know that doubles the circuitry required but that is a design decision that only you can make.
However you will to start doing some reading up about communication techniques - none of the things mentioned here are undocumented and there are generally a number of code examples available BUT you can't just grab any old thing and plug it in - you MUST understand what you are trying to do, what the example code does and also modify it to suit your purpose.
Susan

 

[igeorge]

Thank you, Susan,
I will start reading about wireless techniques.
I was under the impression that it is a plug in solution. It looks like it is not.

 

[Aussie Susan]

It is and it isn't.
It's more like 'lego' in that there are multiple parts that go together in different ways to achieve whatever result you need. Every situation is different (that is what engineering is all about!).
Also you need to break down the problem into smaller chunks and solve each of those (in a coordinated fashion of course). For example, you started with solutions at the hardware RF layer and your application layer: there are several other layers in between that you might need to connect everything together properly - and some of these have been pointed out above.
For example, the RF layer is going to do what you expected - send a '0' or '1' and (hopefully) have the '0' or '1' received at the other end. Your application layer has the 48 bytes that you need to transfer and the other end needs to do something with those bytes.
In between you need to consider packet boundary identification, error detection along with error correction (possibly requesting a resend or implementing 'forward error correction' which allows some errors to be detected and corrected by the receiving end but means more data has to be sent) and the like.
I'm not suggesting that you need something as complete as the full OSI model but understanding what the various layers are n that model and what they do might get you thinking along the right path for your situation.
Susan