Updated library compatibility issue?

[Mmessiter]

I recently (rather late!) downloaded the most recent RF24 library and updated my radio control project. The transmitter worked perfectly and immediately without any code changes. But when I updated the receiver code, it only partially worked with lots of extra lost packets. So I reverted the receiver to the older library which fixed it immediately. I am puzzled! Today I ran some tests with the new library in the receiver code: I increased the packet count between channel hops massively. This reduced error rate by a similar proportion. So it’s clearly changing channel that’s the cause. But why and how to fix it is a mystery. If anyone has a clue I’d really appreciate it!

Malcolm Messiter

[Avamander]

GPS+autonomy requires a magnetometer and calculating your location's declination. The MPU6050 is great for off-loading some expensive calculations (the extra software must be loaded on boot every time though), but it doesn't have a magnetometer. There is mention of attaching another I2C slave to the MPU6050 to act as a magnetometer (in the MPU60xx datasheet), but I've never actually seen anyone try that.

There are very cool premade dead-reckoning (and RTK) GNSS solutions that would be very suitable for this purpose. Often with those sensors built-in. But they can be a bit expensive.

[Mmessiter]

I plan to look into the options for autonomy, waypoint and RTH after stabilisation is done - and before that of course the RF link and ordinary control must first be as robust and bullet proof as possible.

[Mmessiter]

I will try to send now some picture of the GUI screen on the transmitter. This might give an idea of current state…

[Mmessiter]

[Mmessiter]

Well that almost worked! But the order got shuffled !

[2bndy5]

You should definitely get this project on github!

Clearly a lot of work went into it (I'm very impressed). Giving it its own repo will also give you a place to further the project's discussions (not to mention promote and document it). Obviously, contributions would also be mainstreamed.

[Mmessiter]

Yes it was my lockdown project - and I’m truly hooked now! It’s also flying models better by far than anticipated. I can’t leave it alone.

Yes I’d like it to be shared on GitHub but I need to learn how to do this - might need some help! I will look at YouTube briefly…

[2bndy5]

@Avamander you see that scanner output? seems like what you want for #714

[Mmessiter]

What does “Giving out its own repo” mean exactly?

[Mmessiter]

It’s scanner - at home - shows mostly my wifi noise! But out at the flying field scans show reassuringly very little traffic!

[2bndy5]

@Mmessiter That was a typo. I edited/fixed it. Feel free to tag me when you get this repo started (use @2bndy5). This is a worthy endeavor

[Mmessiter]

I’ll write a doc file now so that others can build and fly with this system …

[2bndy5]

You might want to learn markdown syntax so GitHub can render it beautiful. If you're familiar with Python's reStructuredText, GitHub will also render that syntax kinda well.

[Mmessiter]

I’ll try to learn! …

[stanekTM]

@Mmessiter Congratulations on a great project that deserves a thread at https://www.rcgroups.com or at https://www.mode-zero.uk Your compatriot has developed FHSS on Arduino https://www.mode-zero.uk/viewtopic.php?f=42&t=971

[Mmessiter]

Thank you. I’d like to share it with many - as its loads of fun and seems more reliable than expected. Others can make up this system - more easily after I’ve written a full doc file. Might take me a few days. I’ve flown many tests with zero failures and zero crashes so far!

[Mmessiter]

I realised the other day that although my radio does a lot it so far does not offer expo and it really must. … So I think I must perfect just one function, very like MAP() except with one extra parameter - expo rate. Also it must return a 32 BIT float and not an int.

Ie something like :

MapX(StkIn, StkMin,StkMax,SrvoMin,SrvoMax,Ex);

The value returned is sent to servo !

When this function works well the rest will be very easy!

But has anyone written the function already ?!

[Mmessiter]

Today I experimented again with the newest RF24 library in my receiver code. I got it working, eventually, but I found I had to add a short delay (about 5 milliseconds) before every call to radio.available() otherwise it usually returned false. This delay isn’t needed for the April version. Perhaps the polled receive isn’t ideal - should I move to an interrupt driven receive? Last time I tried that it slowed it all down too much. But perhaps it’s different now? Hoping for advice here!

[Mmessiter]

… incidentally I have meanwhile got exponential working well now - using the my new version of the map function which adds expo 😁

[2bndy5]

I got it working, eventually, but I found I had to add a short delay (about 5 milliseconds) before every call to radio.available() otherwise it usually returned false. This delay isn’t needed for the April version.

Hmm, maybe the change to available() from #631 made it too fast for high-speed CPUs? Since v1.3.12 (the release that included the solution to #631), someone reported available() returning false incorrectly on an atmega32 board in #728. BTW, the code on that Dropbox link didn't use "the April version" (v1.4.0) on the RX side; it used v1.1.5 (unless that Dropbox code was outdated).

should I move to an interrupt driven receive? Last time I tried that it slowed it all down too much.

I expect the library to be a little quicker than v1.1.5 in this regard, but that ultimately depends on your project's code. There is a note about using available() during ISR callback functions in the docs. Also keep in mind that calling RF24:: write() is prohibited in an ISR callback (due to the internal use of millis() to implement a timeout).

[Mmessiter]

Thank you for your wisdom! I will continue to explore possibilities. It’s truly fascinating. Sorry I was delayed while implementing “exponential”. Maths is not my strongest subject!

I have another question to which you probably know the answer: I have made some new PCBs that permit the simultaneous connection of two RF24 transceivers,(ML01SP4s) both on the same SPI bus, but with different CE and CSN pins of course. I have found that if I connect just one (either of them) it works fine. But if I connect both, neither can be made to work. Do you know how I might fix this? Two would add extra security for expensive flying models!

[2bndy5]

If it isn't a routing issue with the PCB, then it's likely a power issue (as in not enough current in the supply line for 2 radios). You should review what the manufacturer states for power requirements (ebyte modules tend to have different specs per model).

[Mmessiter]

Thank you - I’ll check. A single ams1117 supplies 3.3V to both and nothing else. I had thought it enough..

[Mmessiter]

Ok! Interesting discovery I made just then : when two transceivers are installed they must BOTH be initialised before either is useable! leaving one initialised kills both for some reason. I’m getting closer to a robust result!

[Mmessiter]

Great progress here: it’s now successfully swapping between two transceivers while retrying when contact was lost - in case the other receiver has its aerial at better angle. And it all happens in less than 100 milliseconds. Can’t tell while flying on the simulator!

[Mmessiter]

Although I have now got the new library working and two transceivers working, on these Teensy 4.x it seemed more robust and faster with the older library and just one transceiver and no extra delays. So for the moment I’ve reverted to using these. Perhaps the Teensy 4.x is simply to fast for that new library. I will await next update which might perhaps suit very fast MCUs better.

[Mmessiter]

Interestingly, as an experiment I took the new .available() function from the older library and pasted into the new one, replacing the new code. I thought that might fix it - but it didn’t - so I guess there’s lots more I don’t yet know about!!

[2bndy5]

Well that helps me answer my question about the improvement to available()

[Mmessiter]

Glad to be of help if I can! Increasingly, I think perhaps the Teensy 4 simply didn’t need extra speed. And mysteriously doesn't handle it well, on receive anyway. If you’d like me to run any test - or if you’d like me to send you a transmitter & receiver for your tests - I’d be glad to. I’d like to update to the latest library when I can because of extra functionality - but right now my system is working really reliably on the older version. I’m flying helicopters with it!

[2bndy5]

Sadly, I would agree to sticking with whatever is most stable for your project.

I do think that a 5 millisecond delay is a long time for the teensy. Does it have to be 5 milliseconds? Would it work just as well with a 10 microsecond delay (or something less than 5 milliseconds)?

[Mmessiter]

I tested with delays from 0 to 10 milliseconds. 5 or 6 was the best compromise. But that resulted in a slightly reduced frame rate, and oddly I also saw that only 90% or so of packets were acknowledged. So it was ok, but not ideal. With older version (.cpp file is dated April 2021) and zero delay, the frame rate is higher, and 100% of packets are acknowledged at close range anyway.

[Mmessiter]

…I’m keen to help if I can. I’m a huge fan of Teensy 4 and I think this radio, after a few more lockdowns, can be truly amazing because of the speed and capacity of the MCU. It can easily store loads of data on its 32 gig sd card 😁

[2bndy5]

Here is the diff between the 2 versions (April 2021's v1.4.0 vs July 2021's v1.4.1). I'm posting the link because there isn't many changes to the lib source code (excluding changes to examples), and I don't see anything that would cause such a catastrophe.

[Mmessiter]

Indeed - those differences seem rather minor. I wouldn’t call it a catastrophe - but it’s certainly puzzling, for me anyway. I should apologise for my obvious naivety by the way - I began learning C++ during May 2020 so I’m really rather a beginner with a heck of a lot still to learn. I used to use 8086 assembler - in the 1980s.

[2bndy5]

I'm beginning to think that there's something in your project (be it a lib vs lib conflict or a lib vs project-src conflict). I would suggest you put this on hold and get the code uploaded in GitHub, so I can better inspect the actual source code you're currently using (the copy on dropbox doesn't seem to be updated with your latest experiments).

[Mmessiter]

Thank you - yes - I should have done this before. Sorry. I got very preoccupied with new code for exponential etc. I’ll do it tomorrow. I think we’ll all feel much better when we know what’s going on. And I really appreciate all help from those with vastly more experience than I. For me - tomorrow’s project is: Figure out GitHub and push the code there!

[Mmessiter]

Astonishingly - I have deleted my earlier tests, created a new repository, pushed all the files there, and even made a meaningless test edit, committed it and pushed it and confirmed it’s on GitHub! … and it’s only 10.30 so I’ll spend the rest of the day learning more about GitHub 😃

[Mmessiter]

I have invited you to collaborate on the LockdownRadioControl repository … I think! Do tell me if I did it right! 😃

[Mmessiter]

… if you would like to test you’ll need the hardware (transmitter & receiver). I’d be happy to send these if you’d like that.

[2bndy5]

I got the invite (thanks). You don't need to go through the trouble of sending any hardware. I will start diving into the code soon...

[Mmessiter]

Ok thanks! The offer stands if you change your mind. I can assemble transmitters and receivers very fast and easily using PCBs. I’ve today discovered GitHub is massively convenient even for merely synchronising the code between my different computers here. I should have used it a long time ago! 😃

[2bndy5]

expect a PR from me (I've created a branch called "use-pio-better")

[Mmessiter]

Ok ... what's a PR ? 😊

[2bndy5]

oh, sorry, its short for Pull Request (github lingo)

[Mmessiter]

I'm learning! Slowly. No need for apology!

[Mmessiter]

Do I need manually to respond to a Pull Request?

[2bndy5]

you'll see... 😉

[Mmessiter]

I feel I'm back at school! ... Which I left in 1967

[Mmessiter]

In the receiver code you'll see quite a lot of PID stabilisation code (for MPU6950 etc.) and quadcopter etc code which is currently never called - because it's not ready yet! I'll work on that later. Currently the receiver just drives servos and/or sends SBUS output.

[2bndy5]

@Avamander Turns out @Mmessiter uses an uncommon display (or at least uncommon to me) for his project. From what I gathered, the Nextion display has a separate MCU included to load firmware as the display's digital interface (I think the firmware can be customized by the user as needed). At runtime, the driving MCU sends display data to the Nextion's firmware over a Serial connection. I will post only the scanner algorithm on #714 as a possible jumping off point.