A little conversation - Githubissues

HamzaYslmn commented 3 weeks ago

I haven't been able to fully test every feature yet. As someone using your code for the first time, I wanted to share some experiences I had, which might be helpful for further development.

First of all, since you've modified other libraries and presented this code, there might be updates or conflicts in the future. To prevent this, I would suggest using the libraries in your code without modifying them (if you have made changes).

Normally, we would set the power level using the radio.setPALevel(RF24_PA_MIN); command.

Additionally, I think if you make the code compatible with ESP32 and RTOS, it could be used by more people. I'm experiencing conflicts when sending large data due to interrupts. If RTOS is supported, it could be used in larger projects (e.g., RC planes, RC cars).

While using your code, I encountered frequent issues like watchdog errors. Thanks to FHSS, I can leverage ESP32's Bluetooth and Wi-Fi features to parallelize data to my main device while also working long-range with NRF.

theboot999 commented 3 weeks ago

Thank for the input and thanks for trying it!

Yes It'd probably a good idea to include the rf24 library. It's using the stock version of the rf24 library.

The interrupt is very short. It's only grabbing a timestamp off when a packet is received.

Your problem likely stems from having set the slowest data rate (512) and a large packet size with a high framerate. At 512 data rate and sending 3 packets per frame the rf24 is blocking for each send, and takes a long time to send

Feel free to use and grab whatever you want from here. I made a version that used a teensys frequency clock counter rather than micros to get more accurate time stamps when packets are received. I'm not sure if the esp32 has an easily readable clock counter register.

HamzaYslmn commented 3 weeks ago

https://iotcircuithub.com/esp32-internal-rtc-timer-control-relay/

esp32 has direct RTC inside :D

theboot999 commented 3 weeks ago

Great! You would get more accurate timing of the rtc as well.

I figured putting the interrupt inside the Slave.cpp made it easier to use without having to set up the interrupt yourself.

The timing was difficult to get right. Even if the master sends a packet at exactly the same time the nrf24 always has a slight variance in time when it will trigger the interrupt. Also using nanos (or even a teensy 4.1) the clock speeds are always slightly different. So it will adjust the frame time slightly to try and compensate. You can read the amount kts adjusted from totalAdjustedDrift.

The hardest part to get stable was if the master turns off and back on and getting the slave to resync. It should be pretty solid but.

The biggest issue would be using a slow data rate, large packet size and high framerate and the rf24 takes too long a frame time to send the data

Let me know if you have some success with it.

HamzaYslmn commented 3 weeks ago

also bidirectional FHSS would be nice

theboot999 commented 3 weeks ago

It is bidirectional.

I'm using it for an rc plane with gps, gyro and barometer with homecoded autopilot etc.

Check the 2 examples. Master sends to slave and slave sends to master.

theboot999 commented 2 weeks ago

Did you test bidirectional?