FHSS

[HamzaYslmn]

Describe the behavior you would like

I need a simple but working FHSS example.

Like 50Hz two way FHSS. I'm not looking for 1600hop/s like bluetooth.

Or if there is a simple solution for these confusions, I would be very happy to inform you that I cannot see.

Propose an implementation or solution

If NRF24 FHSS support comes, I think the usage areas will increase a lot. I have an E01-ML01DP5 nRF24L01P 2.4GHz module with a shield, but I experience a lot of packet loss in channels where communication is dense.

Two Way Comm

20-40 packets gone. (10 meter 250kbps)

With FHSS loss "5 packet" in the same range as the code of the person I shared.

FHSS works by transmitting the signal by quickly hopping between different frequency channels. The transmitter and receiver communicate by hopping between the same frequencies in a specific sequence and speed. If there is interference or jamming on one frequency, communication continues on the next frequency channel.

Describe alternatives you have considered

https://github.com/theboot999/NRFFHSS/tree/main/Master

Additional context

I tried a lot of things myself. I did offset calculation with PTP and synchronized the times automatically, but I couldn't get the timings right, the channel kept deviating.

The friend in the link I shared did very well, but his library is complicated, I want something simpler and more useful.

[HamzaYslmn]

Im using Esp32 BTW

@2bndy5 Can you explain why you don't need FHSS, I have a lot of interference problems with this module, how else can I solve it? What are the alternatives?

[2bndy5]

The RF24 library only employs the Enhanced Shockburst ("ESB" for short) protocol embedded into the nRF24L01 firmware. The ESB protocol is designed to be flexible enough for consumers to implement their own proprietary wireless protocols.

Frequency hopping is not a desirable feature in regards to the RF24 library because it is not part of the ESB protocol. You need to implement frequency hopping yourself, or use a third-party library that implements it for the nRF24L01.

The friend in the link I shared did very well, but his library is complicated, I want something simpler and more useful.

Sorry, but we are not here to do all the work for you (and then maintain it indefinitely). There are many approaches about how to implement frequency hopping. We will not volunteer to support them all (or even a subset) in this library.

[HamzaYslmn]

Sure, thank you.

Thanks, then it would be much better for me to deal with the solutions on the LoRa side. Now I understand much better why ESP-NOW is recommended instead of NRF.

[2bndy5]

I have a lot of interference problems with this module, how else can I solve it?

The RF24::setAutoRetries() feature is supposed to compensate for that.

[HamzaYslmn]

The RF24::setAutoRetries() feature is supposed to compensate for that.

In the module I have, for some reason it does not work properly when radio.setAutoAck(true) or when I use radio.setRetries(5, 0);. I bought the module 2 days ago.

[HamzaYslmn]

If I cannot solve the problem, I will create a return anyway, it would be better to turn to different solutions for my needs.

I use it for stress testing (channel 67).

[2bndy5]

Have you read the docs? Setting the retry count to 0 only reduces the amount of retries the radio will attempt.

It sounds like you want something more from the radio than nRF24L01 can offer. It would make sense to turn elsewhere. Nordic has marked the nRF24L01 as "not recommended for new designs" since around 2014.

[HamzaYslmn]

and deleting it didn't change anything.

Yes, I think it would be better for me to move to newer technologies. Lora and Esp-Now like

I was dreaming that I could do more beautiful things with the pa lna module.

[HamzaYslmn]

but like you said, I think it's not suitable for big projects anymore.

[2bndy5]

You cannot disable auto-ack feature and expect the auto-retry feature to still work. If you are having problems with ACK packets, then your ESP32 board is probably not supplying the nRF24L01 with sufficient power ($P = I * V$). PA/LNA modules are known to be power hungry (though less hungry than the ESP32 radio).

[HamzaYslmn]

I use NRF power modules from AMS1117 3.3V If I don't turn off auto retry, the packets never go, let me send you a ss.

[HamzaYslmn]

[HamzaYslmn]

I'm using a circuit like this. And that's the distance between the modules right now.

[2bndy5]

If RF24::write() returns false when auto-ack feature is on, then it means the ACK packet is never getting sent back by the receiver. THIS IS A COMMON ISSUE, especially with PA/LNA modules because of the power requirements.

[2bndy5]

Where is the 5V USB coming from? It might be better to power the PA/LNA module with a external power supply for the nRF24L01 (or try a different MCU board that doesn't consume so much power internally).

[HamzaYslmn]

Where is the 5V USB coming from? From Laptop, I get “5V 1A” output from the laptop and feed them. (each USB port 5V 1A)

I connected it to the 5V output on the Esp32 (shorted to USB+), NRF module is actually fed by usb. Not ESP32's output.

Esp32 consume 250mA max, NRF 750mA can use it.

[HamzaYslmn]

Im using RF24_PA_LOW on NRF side BTW

[HamzaYslmn]

MY breadboard filter lookslike this

Low and High is filtered. This is the cleanest electricity I can offer for the NRF.

my seperate power module

[2bndy5]

and you're sure the USB cable is outputting more than 0.5mA?

[HamzaYslmn]

and you're sure the USB cable is outputting more than 0.5mA?

Yes ım using Type-C - Type-A USB hub, on phone usb A ports support normal charging (not slow , not fast) So 1A yeah.

[HamzaYslmn]

Also, I can stream 1000hz when ack is false. I think it would not allow if there was a power problem. (with %0 packet loss. on channel 125)

[HamzaYslmn]

İf my port gives 500ma, peaks: 250 + 200 = 400ma, still 100ma available.

[2bndy5]

Dust off the multi-meter and measure it manually. There's often a difference between what a product says it does and what it actually does. Seriously, the main reason the ACK packet isn't returned is due to insufficient power.

---

BTW, the your ebyte module (ML01DP5) has different stats: from the official pdf

[HamzaYslmn]

to verify your thesis, I turned off esp32's wifi modes and reduced the current draw to 20ma and ı use powerbank but the problem persists

[HamzaYslmn]

If 400mA is not enough, what am I running :D

[2bndy5]

ok, if you're not going to use a different MCU board or power the nRF24 separately from the MCU (in which case the grounds must be tied together), then my hands are tied.

Remember the required current is a peak (instantaneous) measurement. I can't really help you any further because this no-ACK packet problem is very likely a power problem (not a software problem), assuming that all other setting match on both nodes (& I think they do given your screen shots).

[HamzaYslmn]

Thanks for your help, I've filed a return. NRF isn't really my thing. I realized that I needed to move towards new technologies.

I'll create a return for the nrf's.