Problem with wireless serial transmisson

[Tracy Chin]

Hi, I am doing school project and have encountered a problem when using T5/R5 module and PIC16F877 USART feature for RF communication.

Datasheet for T5/R5 module and my schematics are attached. Basically, the route is T5 Tx pin -> PIC Tx -> transmission media -> R5 Rx pin -> PIC Rx. I didn't use any encoder/decoder related chip.

When I directly connected PIC Tx to PIC Rx, the circuit worked. However, after I added RF modules, the communication between two PIC failed. I observed the wave in oscilloscope. When a signal was sent from Tx, a similar shaped signal was received from Rx. But when nothing was sent from Tx, noises presented in Rx (I saw waves up and down in high freq). That may be why PIC failed to interpret the meaningful signal I sent.

The baud rate I use is 4.3Kbps. Anyone has the idea about what the problem is? Shall I change the capacitor value or baud rate? Many thx.

 

[banjo]

This is typical behaviour. The RX module has a automatic gain circuit. When no valid TX signals are present, the gain keeps increasing until the background noise starts being detected.

The usual fix for this is more firmware code. Usually, the TX circuit sends a repeating pattern as a header. This is to normalize the gain of the RX circuit. After the known header, the TX circuit sends with message usually with a checksum.

The RX firmware just looks for a valid data packet and checksum. It ignores the header and any random data that does not contain a valid checksum.

Why does your RX decoder see nothing? Usually, because your transmitted data is too short to properly adjust the gain control back into the proper active region. The more scientific members with describe this in terms of the data slicer, but the effects are the same.

P.S. The header is most often a balanced repeating pattern, hex AA.

 

[Tracy Chin]

Usually, the TX circuit sends a repeating pattern as a header. This is to normalize the gain of the RX circuit. After the known header, the TX circuit sends with message usually with a checksum.

Hi, thank you for your help. Could you elaborate more on how I should process the header, the message, and the checksum? What should be the pattern of a checksum and what is its usage?

I use c to program my PIC. Do I need to include any codes to decrypt the header and the checksum?

Appreciated your help.

 

[banjo]

First, please read the other thread, "Problem with wireless serial transmission" There are over 50 posts in the discussion and a link should appear at the bottom of the web page.

Also, you can check out the following links:

**broken link removed**

**broken link removed**

**broken link removed**

A checksum is an added piece of data whose value depends on the contents of the previous data it is designed to check for. The purpose is to allow garbled data to be detected. There are numerous checksum methods. For example, we could add up all the bytes of the data portion and transmit the sum as a checksum. The receiver does the same arithmetic and then compares its answer with the checksum. If they match, the data is valid. If they disagree the data is corrupted. Simple addition is not foolproof. If the data has two errors, it is possible that they exactly compensate for each other and the checksum would pass. Therefore, many system use CRCs which are more complex calculations, but are better at finding errors.

I am not familar with the libraries available for the PIC microcontroller. I tend to use the AVR. For the AVR, there is a published library, AVRLIB, that contains all the routines needed to send and receive wireless data. You simply include the library and then call the appropriate functions. Perhaps a similar library is available for the PIC.

Added after 4 minutes:

Did another web search and found this Circuit Cellar Article. It appears to contain links to some PIC source code.

**broken link removed**

 

[Tracy Chin]

Hi,

Sorry to reply you so late as I am busy with my marketing project as well these weeks.

I just thought that if I countinousely sent a signal which is balanced with 0s and 1s to Rx side, it should be able to detect it as the theory is similar to sending headers. However, when I tried it, it did not respond as I expected. There were some time between receiving two signals and my RF had detected noise during that period. So, even I saw the signal appeared on the oscilloscope at Rx side, the PIC could not recognize it. Is there any way (like using filter) to eliminate noise received?

I am not familiar with the usage of filter. Great if you can provide me some suggestions. Thank you very much.

 

[betwixt]

Hi Yudi.

The noise is not the problem. you will always get noise between transmissions, it is like the hissing noise you get on an FM radio when not tuned in. It will show as random data coming out of the receiver but that is only because without knowing the average frequency, it can not tell if instantaneous frequency (normally representing the data you are sending) is above or below that average. When no signal is received, the average could be anything so background hiss will appear to be random 1's and 0's.

The trick is not to remove the noise but to make the receiver ignore the random data.

ps. I tried one method that is working. When I connected the Tx pin with signal generator that generating square wave with freq > 7.9 KHz, the noise at Rx side disappeared. Instead, a square wave with lower amplitude existed at Rx side. When I sent some message once, the chip can detect it with 70% acuaracy and react accordingly. However, when I try to replace square wave by PWM from PIC, it did not work again.

This confirms what I have been explaining. Your signal generator is producing a constant square wave, effectively 01010101... data so the number of zero and number of one levels are the same. I will try to explain using numbers, please understand that these are example numbers to make the math clearer so do not try to measure them on your project:

Lets say your signal generator is producing 8KHz, the output is low for 62.5uS then high for 62.5uS, lets say a low produces an RF carrier at 433.0 MHz and a high produces an RF carrier at 433.1 MHz. The output of the transmitter is switching from 433.0 to 433.1 at an 8KHz rate.

It would be easy to say anything at 433.0 should produce a '0' output and anything at 433.1 should produce a '1' output. The trouble is, the next transmitter module off the production line might produce 433.2 and 433.3 MHz, still within the manufacturers specification but the receive would not be able to decode what it receives, the frequencies are too far away for it to make a decision on what is '1' and what is '0'.

So what we need is something that (within reason) ignores the ABSOLUTE frequency but uses the CHANGE in frequency to recover the data. This is what the adaptive data slicer does. All the data slicer does is compare two voltages, exactly like a comparator does, except that one of the voltages is taken directly from the receiver so it changes immediately, and the other is the same receiver signal but filtered so it cannot change quickly. Remember that your modules are FM so the receiver is converting the frequency it picks up into a voltage, a higher frequency (within the receiver range) will produce a higher voltage.

So you signal generator is making the instantaneous receiver output voltage low for 62.5uS then high for 62.5uS. What isn't known is what those voltages actually are, only that one is higher than the other. This is where the filtered input to the comparator comes into play. Because the filtering stops it changing quickly, it will slowly drop for 62.5uS then slowly rise for 62.5uS if the filtering is working properly, the voltage will stay fairly constant somewhere close to the mid point of the two output voltages, whatever they actually are. Now it becomes easy to decode the data, any direct voltage greater than the average is a '1' and any direct voltage lower than the average is a '0'. The comparator is simply comparing the received signal with the average.

Now look at what causes the noise you see:

If you send several '0' bits together, the average starts to fall and keeps falling until the average itself reaches zero. Now any residual noise in the system, because it is greater than zero will appear to be a '1'. Similarly, if several '1' data bits are transmitted together, the average will rise toward full voltage and any noise will appear below it and produce a '0' output. With random noise at the receiver, the instantaneous and average will drift unpredictably and random data appears at the output.

To keep the average at the mid point of '0' and '1', you must keep them alternating as often as possible so the filtered voltage doesn't have change to drift too low or high. This is why the square wave works but other data may not.

I'ma bit worried that you suddenly mention PWM. Are you sending data or PWM?

If it is PWM you will have problems because just as the average voltage of PWM is proportional to the mark/space ratio, so will the average at the data slicer. If you really want to send PWM, the best way is to send data from the transmitter to tell the receiver to generate the PWM rather than sending the PWM itself.

Brian.

 

[Tracy Chin]

Hi Brian,

Very glad to see your reply

Thank you for your explaination. I understood the theory now, but had problem to continousely send signal to Rx side without delay. Below are my codes.

Transmitter side:
for (i=0;i<20;i++) //send 20 bytes of header
{
while (TXIF==0);
TXREG = 0x55;
}

for (i=0;i<10;i++) //send 10 bytes of useful signal
{
while (TXIF==0);
TXREG = 0xA6;
}

Receiver side:
if (OERR == 1) //overrun error
{
CREN = 0;
CREN = 1;
signal = RCREG;
signal = RCREG;
signal = original_signal;
}
else
{
if (RCIF == 1)
signal = RCREG;
}

orginal_signal is stored in EEPROM

I found that if transmitter side transmitted more than 2 signals together, the receiver side could not read from register (maybe because of over run error all the time).

So I would like to ask whether there is a way to transimit and receive 10s of bytes of signals continousely?

Thank you very much.

Regards,
Tracy