Not receiving all packages

[rienkvandenberg]

Hi,

I use 2 arduino pro mini's @ 16mhz with one running the transmitter example and one running the receiver example. There are no changes in the examples except the transmit and receiver pin number.

On the serial monitor of the receiver I see packages id 1-7. After that there is nothing for about 45 sec and than I see packages id 16-23. So packages are receiving in one periode and than missing in the next periode and so on.

If I change backoffDelay to 10 in the RFTransmitter.h file. I do receive all packages. But still it looks like there is an delay (more than the 5000ms in the transmitter example).

Do you have any suggestions?

[zeitgeist87]

Hi @rienkvandenberg,

Thanks for reporting this. I tried the examples with an Uno and a Nano both at 16Mhz, but I could not reproduce this issue.

There are many possible reasons for your problems. These RF modules are cheap for a reason. They are often very badly tuned. It is possible, that you've got a transmitter and a receiver that are a bad match. It is also very important to have a proper antenna for the receiver as well as the transmitter. You can get copper spiral antennas very cheaply on Ebay or make them yourself from a piece of copper wire. Furthermore these modules use AM radio, which is more susceptible to interference than FM. It is possible that there is some sort of interference in your house, like a PC power-supply or a LED light-bulb with a switch-mode power supply.

The transmitter needs more current when it sends data. I found that adding a moderately sized capacitor between Vcc and GND near the transmitter module can improve the performance and range.

I hope this was helpful to you.

Cheers

[rienkvandenberg]

Hi,

I have tested with different transmitters and receivers. Not the cheapest ones from ebay. I have looked with a scope on the transmitting side and receiver side. The receiver signal is a perfect copy of the transmitter signal, so i still think it is software related. The missing packages are totaly random now. Could it be something with the pinchangeintetupthandler? I'm not a programmer so it is difficult for me to find the problem. I'm also not sure if the problem is on the transmitter or receiver side.

Thank you for your help.

[zeitgeist87]

Hi,

That indeed seems like a software problem. Unfortunately it is quite hard to debug these kind of issues even when you can reproduce them. Nevertheless I will look over the code again and see if I can find something. I've also noticed that the signals look quite good on a scope.

[rienkvandenberg]

Thank you for your time. Here you see the scope signals. Blue is the transmitter, yellow the reciever.

I will also test more with different settings to see if I can make it work. As I meantioned earlier, if i change the backoffdelay to 10, I do recieve more (or maybe all packages). But I dont understand why this parameter has to be changed.

[zeitgeist87]

You could try and increase the pulseLength parameter on both the transmitter and the receiver. Maybe to 150 or 200. This reduces the transmission speed. If it works with a lower speed, it could mean that the PinChangeInterruptHandler library is too slow. However it seems to work quite well with my setup.

Which digital pin do you use on the receiver? Maybe I can reproduce the problem if I replicate your pin configuration exactly. I also own an Arduino Pro Mini. I will try and use it as the receiver instead of the Arduino Uno, although I can't imagine why that would make a difference.

I am also working on a slightly better encoding, but it needs more testing and I don't know if it can solve this issue.

[zeitgeist87]

I was able to reproduce a similar issue, by reducing the resendCount parameter to zero. That way I was able to improved the line encoding. The latest version here on Github should work much much better now. If it still doesn't work, try increasing the pulseLength parameter.

[rienkvandenberg]

Hi Andreas,

Thank you again! I will try it and let you know how it goes. Kind regards,

Rienk

[wifixcort]

Hi all.

I'm having the same issue with an Arduino Nano as Transmiter and one Arduino Mega 2560 as Receiver.

The loop freeze after this line:

byte len = receiver.recvPackage((byte *)msg, &senderId, &packageId);

Both are working good. I test them first with the most simple scketch. Transmiter: ` void setup() { // put your setup code here, to run once: pinMode(11, OUTPUT); }

void loop() { // put your main code here, to run repeatedly: digitalWrite(11, HIGH); delay(1000); digitalWrite(11, LOW); delay(1000); } `

This is what I see with my airspy:

Then the receiver code:

` void setup() { // put your setup code here, to run once: Serial.begin(115200); pinMode(2, INPUT); }

void loop() { // put your main code here, to run repeatedly: Serial.println(digitalRead(2)); } `

This is "graphical" reading with arduino serial plotter:

[rienkvandenberg]

Hi,

After testing with the updated library, i couldn't receive anything. But if i increase the pulseLength parameter, for both transmitter and receiver to 250 microseconds, i receive all packages.

The default parameter is 100 microseconds. Increasing means a slower bitrate. If i understand it correct, with a pulseLength of 250 microseconds, the bitrate is 1000bits/s (1 bit is 4 pulses long).

I hope this wil work for you too.

Kind regards, Rienk

[zeitgeist87]

After testing with the updated library, i couldn't receive anything.

@rienkvandenberg so are you saying, that the updated library is worse? During my tests, the results were much better. There is also an update for the transmitter library. The old version is no longer compatible with the new receiver. Maybe that was the problem.

The loop freeze after this line:

byte len = receiver.recvPackage((byte *)msg, &senderId, &packageId);

@wifixcort Thanks for your report. The call to recvPackage() is blocking. You can use the ready() Method to implement a non-blocking version:

RFReceiver receiver(2);

void loop() {
  if (receiver.ready()) {
    char msg[MAX_PACKAGE_SIZE];
    byte senderId = 0;
    byte packageId = 0;
    // Should not block
    byte len = receiver.recvPackage((byte *)msg, &senderId, &packageId);

    // Use the received data
  } else {
    // Do something else
  }
}

@wifixcort I've never used the Arduino Serial Plotter before. It seems like a really nice tool. If I have time today I will repeat your experiment and post my results. On your airspy screenshot there are two spikes around 434 Mhz. Could those be the source of your interference?

[zeitgeist87]

@wifixcort It seems a delay of 1 second is too long. The transmitter shuts itself off and then you get random noise:

If you use 100ms it works beatifully:

void setup() {
// put your setup code here, to run once:
pinMode(11, OUTPUT);
}

void loop() {
// put your main code here, to run repeatedly:
digitalWrite(11, HIGH);
delay(100);
digitalWrite(11, LOW);
delay(100);
}

[wifixcort]

@rienkvandenberg, @zeitgeist87 thanks. I gonna try this evening that non-blocking option or update the pulseLength if the first doesn't work.

I use Serial Plotter just for reference because it's not a really good plotter but for fast test is a good tool. That random noise don't really exist, if you open Serial Monitor you have a clear signal but "hard" to interpreted.

[zeitgeist87]

Something seems to be wrong with the recent update. I have to do more testing...

[rienkvandenberg]

@zeitgeist87

I'm not sure if it is worse than before. I have updated the transmitter and receiver library. After updating i noticed that the examples didn't work anymore. Not with default settings for pulseLenght. After increasing it to 250us I had a solid receiver signal. I have not looked at it with my scope, so i can't give you more info right now. If i have time i'll do some more testing tomorrow.

Kind regards, Rienk

[wifixcort]

@zeitgeist87 it works with the non-blocking option :+1: :1st_place_medal: