Doesn't show up on iPhone 6

[Isaac96]

I am using a nRF24L01+ with a Nano and the send.ino example. It doesn't show up on a iPhone 6. Am I doing something wrong?

[floe]

Could you try a recent Android phone to see if it shows up there? You could also try a second Arduino with the receive example in parallel.

[Isaac96]

Sorry, the only Android device I have is from about 2008. It does not have BLE. I tried it already and it doesn't work. But I will try the second Arduino.

[jikelmon]

Tried it with an OnePlus 2 and a raspberry pi with activated le scan. Neither my phone nor the pi recognizes the advertised data from my arduino uno. Strangely enough the receiving on my arduino uno only works with deactivated channel hopping whereas on an arduino nano neither receiving nor advertising data works.

EDIT: I am using a nRF24L01+ module

EDIT2: Do you think it could be an platform issue between Uno and Micro?

[floe]

Keep in mind that this is abusing the Bluetooth spec pretty hard, I've seen a lot of issues where some specific combination of Arduino model and phone model works, and another combination not at all. I suspect it's some kind of timing issue related to channel hopping, but I've never been able to pin it to a specific cause...

[floe]

Just for the record, the guy from #16 used an Arduino Uno, and it worked in both directions there (using a Galaxy Note 5).

[ardyesp]

I had problem with iPhone taking too much time to detect nrf advertisement packets. After analyzing with packet sniffer, it turned out to be CRC errors on CH 37 and 38. I figured that my module is probably not tuned properly and used another module which worked ok.

nrf24L01+ green module with Arduino Nano

[floe]

@ardyesp very interesting, thanks for sharing. That would explain why this behaviour seems so entirely random (and if certain channels work better than others on de-tuned modules, that would also explain why it can sometimes be mitigated by disabling channel hopping).

[2bndy5]

@floe Not sure if this helps, but I've been trying to implement this concept in CircuitPython. Among my research, I found this source code comment:

buf[L++] = 0x42; //PDU type, given address is random; 0x42 for Android and 0x40 for iPhone

It would seem that smartphone devices look for different PDU types. Your library is using 0x42. I'm waiting on a friend to test my implementation using PDU type 0x40 with an iPhone. He reported that his iPhone also doesn't pick up advertisements with PDU type 0x42. So far it seems either type will work for everything else (Chromebook included), but smartphones are picky.

[2bndy5]

@floe I just got confirmation that the PDU type 0x40 works with iPhones while 0x42 works with Android I could submit a PR if you want. Fixing this issue would need a new setter function allowing the user to specify which PDU type (& maybe getter function for convenience).

[floe]

Wow, weird. What Android device(s) did you test with?

[2bndy5]

Samsung Galaxy s4, s5, & s10. My friend, @jerryneedell has the iPhone that was tested, but I don't know the exact model (I could ask if its important).

[jerryneedell]

FYI -- I hav been using both an iPhone 11 and an iPhone 7 to test the nRF24L01 library from @2bndy5
The iPhone's "see" packets with PDU type 0x40 or 0x42 -- The Android phones I have tested only "see" them if the PDU type is 0x42.
I initially reported the the iPhone11 was not seeing PDU type 0x42 but that may have been a configuration problem.

Here are some examples using nRF Connect on an iPhone 11

PDU type 0x40

PDU type 0x42

[2bndy5]

oh, I was under the mistaken impression the PDU types were an XOR situation. This calls for adjustment to the defaults on my library. Also, it now makes a little more sense why Dmitry Grinberg used PDU type 0x40 in his initial research.