Would RFM69W be more reliable than NRF24L01+ for my project?

[midix]

Hi everyone.

I currently am working on a project to modify & extend a MIDI device that needs to send data (no more than 4 bytes per packet) wirelessly. The data rate is low, no more than 10 packets per second, but latency and reliability are crucial.

I chose NRF24L01+ because I had experience with them.

In general, everything works great and in 99% of cases, the roundtrip time (send+ACK) time is never higher than 3ms. But it occasionally spikes up to more than 200ms for a single packet and then it's completely normal again for the next 20 - 100 packets.

I wanted to know if RFM69W would be free of such behavior, considering that it's operating on a less saturated frequency (868MHz instead of 2.4GHz) and also is less likely to be a counterfeit module of low quality. Lots of fake NRF24L01 around, and also they are very picky about power regulators and SPI noise. I have two capacitors- one soldered directly on the power pins of the NRF24L01s and another one of 470uF for my cheap 3.3V switching regulator. Without those, I had lots of problems with NRF24L01 built-in ACK reporting false positives and false negatives.

Here's what I'm currently doing:

I have disabled the built-in ACK for NRF24L01+ (both because it was unreliable on my clone modules and also because I need custom ACK logic to overwrite the packet with new data if it could not be delivered at once)
take current time with millis()
send a packet to the remote side
switch to listening mode and wait for the response from the remote side in `radio.available()` loop
if did not receive the reply within 200ms, give up, switch back to sending mode and then resend the packet next time (possibly with new data)

Configuration is set to MIN power because both devices are expected to be not farther than 5 - 20m.
Every packet has a byte with a sequence number, so that the receiver can detect if this message might be a duplicate. The data rate is set to 1MBPS.

The receiver device (Teensy + NRF24L01+) is connected to a PC and pretends to be a USB MIDI device. There are no delays in my loop() on both receiving and sending sides. I have set also a time detection in loop() on the receiver to warn me when it takes more than 5ms to reply. Haven't seen it triggered yet. However, the receiver occasionally reports that it has received a duplicate message - it could be at those moments when the sender reports it timed out while waiting for an ACK. In the most recent measurements, it had about 1000 "hiccups" in 10 minutes.

I'm wondering if anyone has seen similar behavior on RFM69W? How picky is it regarding power source and noise?

I'll try to attach a larger antenna to the receiving end to see if it helps. The receiver is located close to computer and router, and it might be overwhelmed with noises and whatnot.

I'm also considering ordering a few Moteinos and playing with them. I wish there was a Moteino based on ATmega32U4, so that it could be used as a USB MIDI device directly, but I can connect it to a separate Micro Pro anyway to make it a serial->USB MIDI gateway.

[Felix]

Potentially it could do it, very short packets will take around the same amount of time IMO. But you'd have to try to be sure.
The RFM69HCW is what I'd recommend, on the Moteino there should be no power supply issue as long as the Moteino is powered properly (at least 3.6v or so to give head room to the onboard 3.3v LDO).

[midix]

Thank you for your reply and all the awesome stuff you are creating.

I found some RFM69W modules in a local store and am now experimenting with those. Seem indeed more reliable than NRF24L01; no more weird "stuttering" issues, and with set300KBPS the latency is good enough for me, the message roundtrip seems to be always under 4ms. Packets get lost sometimes, but I'll deal with it by resending copies of messages with short intervals between them and then filtering the duplicates out on the receiver side, using a counter byte in every message.

However, now I seem to have a Teensy-related RSSI issue, but I created a new thread specifically for that.

[midix]

Just an update, in case someone happens to encounter the same weird stutter.

It turned out to be something Teensy-related! As soon as I replaced Teensy with ATmega32U4-based board, the weird 200ms delay went away. I have no idea if the problem is with Teensy itself or the NRF24L01+ libraries.

[Felix]

Thanks for the update.
Coincidentally there's another Teensy related post right now where some dropped packet issues are happening.