RSSI does not recover when conditions improve about rc_rx_cabell_v3_fhss

[soligen2010]

Telemetry never worked well, and I never run with telemetry anymore because I got tired of all the RSSI warnings. If I have a bug in there causing the issues and you have a fix, or even if you come up with a whole other algorithm that works well, I would like to see it.

Just a note: The RSSI is a simulation and not true RSSI because the NRF24L01 doesn't report a useful signal strength, so I would never expect it to be as good as a protocol based on a chip that has RSSI in hardware (like FRSky's protocol)

[philj404]

Yes, it looks like the returned value is closer to "received packet success rate in percent" rather than some more technically correct value in dB. I'm OK with that because it is easier to calculate and understand.

I will set up a pull request with my changes. If you would like to merge these changes (and they work), please do so. If there is some reason they will not work, go ahead and reject the change.

I like having some NRF24L01 example code which works with an off-the-shelf transmitter! That lets me focus on getting the robot working.

[philj404]

See #10.

[soligen2010]

I refreshed my memory on my code and I understand your PR, but I think there is a better way to achieve it. The getRSSI method gets called every packet, so by resetting the sequential count, it basically completely disables the sequential count penalty/recovery feature..

A better way to do this is this is by adjusting these values in RSSI.h

#define RSSI_MISS_ADJUSTMENT            5                     // Each consecutive miss deducts this from the packet rate
#define RSSI_MISS_ADJUSTMENT_RECOVERY   1                     // The rate at which a hit removes the miss adjustment

You can achieve the same thing by setting RSSI_MISS_ADJUSTMENT to zero. Using these you can tune the behavior. for example Instead of turning it off you can set the adjustment small and recovery high (opposite of what I have), or anything in between, or turn it off.

Based on this I am going to decline your PR. I hope you take this suggestion and play with the numbers instead of the change you made. I'd be interested in what numbers you end up liking.

And on another note, you shouldn't need to comment out the code for the second NRF24L01. The code automatically determines if there is one or 2 connected. However, packet rates are much better with 2. Orient the antennas at 90 degrees to each other.

[philj404]

Thank you for reviewing the change, and clarifying how to better customize settings for this receiver. I will make local changes and report back if I discover anything.

I MAY add a second receiver for diversity, but I didn't anticipate it when I originally wired my shield. I will have to figure out how to fit it in.

Originally I was using the TMRh/RF24 library, without any frequency hopping. Its reliability was more consistent, but I need a protocol compatible with this transmitter. I think the base transmitter/receiver communication is OK. I suspect something is going on with frequency synchronization. If I discover something useful I will let you know.

In the meantime 94% to 100% packet success rate is still quite good. I never saw two failures in a row, so any failure only added ~4ms of latency. It is still way faster than many protocols, and overkill for my robot.

[soligen2010]

That is the base library I use too ( a slightly tweaked version), but there are other modes this chip can run in if you use that library that may seem to help reliability. You can have the feature to ACK and auto-resend missed packets. I don't use this feature because if a packet is missed, there is no point in re-sending the missed packet, because the next packet will be more up-to-date anyway.

[philj404]

I was using the RF24 "receiver sends ACK with a payload" feature before I found your code. It works, but I found I had to prepare the payload in advance, and once prepared it was not easily updated -- you had to wait until a new packet was received and the ACK was transmitted. So intermittent connections could end up with very stale updates.

Your code is more responsive with recent RSSI/voltage updates (with more work for switching the hardware from "receive" to "transmit" and back). Timing calculations get much easier if you avoid retries if a handshake is missed, and only send one fixed-size packet before changing channels.

I guess if you are hopping frequencies, switching between "transmit" and "receive" all the time isn't that much extra effort.