Custom board not seen by IOS device but it is seen by NRF-Connect Desktop

[rogerarchibald]

Hi There,

I've been developing a product using the NRF52DK.  I had some custom PCB's made after I had my circuit designed, and I programmed them with the NRF52DK.  Now my boards and the NRF52832 on the DK are running the exact same firmware.

With the NRF52DK, I can connect to my service on NRF Connect for IOS and Desktop (with an NRF51 dongle). 

With my boards, I can't see them with IOS (using NRF Connect or LightBlue) but I can see them using NRF Connect Desktop.  

When I scan with NRF Connect Desktop, my boards' RSSI indicates a fairly strong signal (~ -55dBm) and I can connect and view/control all the characteristics fine.  

I'm going to continue poking around to try to understand what's different but I'm quite stumped as to why IOS will only see the NRF52832 on the DK, but NRF Connect Desktop will see either the DK or the custom board.  I've tried an iPhone and an iPad and got the same result.

Any suggestions would be greatly appreciated!

Thanks,

Roger

[AmbystomaLabs]

Make sure you don't broadcast with an Apple manufacturer ID (ie, 0x004c).  iOS segregates all 0x004c broadcasts to the CoreLocation API's, only non 0x004c show up in the CoreBluetooth API's. 

Or, if you are using CoreLocation in iOS then you can only broadcast with an Apple ID. 

[rogerarchibald]

Thank you for the suggestion, but I am fairly sure it's not an addressing issue since I can connect just fine using the same firmware on the PCA10040 DK.   

[AmbystomaLabs]

You should also measure the frequency error of your board.  Not advisable to do it directly at the 32MHz since scope probe will pull the crystal.  Instead just use DTM code to park it on a channel and measure the error.  BLE spec is max +/-150kHz error.  Ideally you will see about +/-20kHz or so error.

It is entirely possible either your PC or iOS device while still within spec is shifted just enough to see/or not see your custom board.

[rogerarchibald]

Thanks for the advice, I'll have to do some research on DTM code.

THIS is the 32MHz XTAL that I'm using, with 2% NP0 12pF caps.

[AmbystomaLabs]

As I'm sure you are aware, the layout can make a huge difference on the center frequency of the crystal. Also, your crystal at 30ppm is getting close to the edge of the tolerance range for BLE. And, unless you placed the 12pF load caps yourself, your CM might well have placed the wrong caps.

All the other comments in this thread that I see don't really address why it doesn't show up in nRF Connect on one type of device vs. another type of device. That app just uses the bluetooth framework to report on advertisements.  The LFXTAL has nothing at all to do with advertisement quality or data rates.  As long as you broadcast as non-iBeacon (ie, non 0x004c) the iOS devices should see it.

Also, issues with your antenna are kind of moot too.  A bad antenna will keep you from receiving at >2meters or so, but you can terminate an nRF into a resistor and still receive it when under 1 meter.

This seems to point to a signal quality problem and not a coding, timing problem. You should try to get access to a spectrum analyzer. Measure the channel accuracy while broadcasting CW.  And also get a picture of how the spectrum looks for standard BLE 1Mbps. You can use either DTM or RadioTest code to do these.  Both are in the SDK.

Please post your results if you can.

[rogerarchibald]

Thanks again for the suggestion.

I placed the caps myself: I did the layout myself but I tried to mimic the Nordic PCB examples very closely on cap placement.

I think that my problem must be layout.  I am in the process of porting my project from SDK 11 with Keil to SDK 14 with SES(my code size passed the limits on the free version of Keil).

Once I get that all sorted and get a bit more of my functionality figured out I will re-spin my boards with whatever circuit changes are needed, and I will also clean up my antenna routing and source a tighter-tolerance 32M XTAL.

I don't know when this will happen since my day job is becoming more of a night-and-day job, but it will likely be several weeks before I have new PCB's in hand.  If it is preferable to close out this ticket, I will re-open it if needed when the boards arrive.

Thanks very much to Richard and Edvin for your support here.  This is a great board and I have learned a lot!

Cheers,

Roger

[AmbystomaLabs]

Glad to have provided some assistance to you.

If you want to post your current layout, I would be happy to review it and provide feedback.  It could save you a lot of time on the next board spin.

[rogerarchibald]

I'm happy to share files if any advice can be given from them.  If I eventually get this working it will all be posted as Open Source anyway.  Attached are Eagle files, I can upload Gerbers if that's preferable.

FYI, I am trying to make a BLE version of this.  The current version is built on a pair of 8-bit AVR's with NRF24L01+ transceivers.  It works well enough and a couple of local animal rescues have had success using it to trap animals for TNR (Trap Neuter Release) but the interface is clunky and a BLE version would be significantly less expensive due to only having one 'smart' box and not requiring separate transceivers.  I also hope that an app would be more user-friendly for your typical 'cat lady' then a remote with small buttons.OpenTrap_BLE1.schOpenTrap_BLE1.brd

Thanks again for the support and I welcome any feedback.  

Cheers,

Roger

[AmbystomaLabs]

All files received and work fine.  Plus I got the chance to try out the latest Eagle. It has turned into a pretty nice layout package.

I will go through and review the entire thing since you are doing a respin.

It will take about a day to complete. There should be a lot of useful feedback for you.