The broadcast won't appear on an iPhone about btle

[floe]

Hm, what Arduino are you using? I'm quite certain that this is a timing issue and depends on the speed of the µC. On my Arduino Micro, I didn't have any problems with the iPhone, but rather with Android...

[acalatrava]

I'm using Arduino Nano with an Atmega 328P-AU. Also on the Mac won't show at all... Hints?

[floe]

I haven't yet been able to nail this issue down in any way, since it's so random. You might want to try different delays a) between the 3 consecutive advertisement packets and b) between each block of 3 packets. I think the default values I've put into the example are consistent with the BTLE spec, but apparently there's some other factor at work here...

[acalatrava]

I've been trying A LOT of combinations. I also read the BTLE spec and it shouldn't be so random. According to the specs you should send an advertising packet and hop to the next channel in less than 10ms. I measured how long it takes to send 3 advertising packets (one on each channel) and it takes 5ms. Also you should send every advertising event every n*0.625 ms with a max of 10.24s and a min of 100ms. There is also a random delay between advertising events between 0ms and 10ms. So I don't understand why this is so random! It doesn't make sense...

[floe]

OK, at least this means that we both interpreted the spec in the same way :-) Do you have an Android phone at hand? You could briefly check if advertisements are visible there...

[acalatrava]

Unfortunately the only Android device I have is a Samsung Galaxy SII which don't have btle...
Another thing I spotted is that every time it appears it will show a different UUID, why is that? Did you notice it?

[acalatrava]

I just tried with an Arduino UNO and the result is the same... I even tried with a different nRF24L01+ just in case and added a capacitor on the 3v3 line to reduce noise: same result. I don't understand why this is working for you... Which Arduino are you using?

[floe]

I've been using an Arduino Micro, with which the broadcasts were visible on an iPhone, but not on Android unless I played around with delays.

[acalatrava]

Still digging into it ;) I started to listen for incoming advertisements from my iPhone and check what is the difference. I don't understand why but this is 3 sample packets I received:

40 9 94 9E F9 AF BF 67 2 1 1A 68 52 4D 38 B6 9A B2 90 8B 17 21 12 F8 38 FB 79 3B 2A 6E 5A 8A
40 9 94 9E F9 AF BF 67 2 1 1A 68 52 4D 1E 9D BB 32 55 2B 71 BC CE 87 7 EB 3B 1F 63 6E 5A 30
40 9 94 9E F9 AF BF 67 2 1 1A 68 52 4D 9E DD 14 CD FD 6F E6 90 4F 28 53 2F E8 5A C2 18 9D 4B

HEADER:
0x40 = PDU Type
0x09 = Length
0x949EF9AFBF67 = MAC

PAYLOAD:
0x02 = Payload Chunk Size
0x01 = Device Flags
0x1A = LE General Discoverable Mode + Simultaneous LE and BR/ERD

CRC:
0x68524D

Total length to here: 9 bytes (6 MAC + 3 PAYLOAD)

So, what the heck is the rest of the packets?

[floe]

The leftover bytes are actually easy to explain - they are just noise, as the nRF24L01+ is operating in "raw" mode and after it has received a suitable preamble, it just continues receiving until the 32 byte FIFO is full.

[floe]

Seems to be answered in #3 - de-tuned modules may be the culprit.