This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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

Parents
  • 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. 

  • 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.   

  • 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.

  • 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.

  • I am not even sure whether you use bonding, but if you could just check it, to be sure that this is not the issue, you could save yourself a couple of days of work. The reason that it works on the DK could be that the bonding data is properly stored on both devices. If this for some reason was not stored on the chip (e.g. after a chiperase), then you will get this behavior.

     

    Either way, if you are sure that the bonding is not the issue, there must be something else. Either a faulty XTAL or antenna. Do you use an external antenna on the custom PCB?

     

    Best regards,

    Edvin

  • Hi Edvin,

    I had replied to your post above to say that deleting bonding made no difference.

    My board has a PCB antenna.  The image above shows the PCB design where the antenna line leaves the NRF52832 and goes through the termination circuit and out to the antenna.

    Thanks,

    Roger

  • 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.

Reply
  • 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.

Children
  • 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

  • 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.

  • 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

  • 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.

  • Any feedback is appreciated.  A few items on there are copy-pasted from my first board when I was using a 7.2V Nimh battery and gate drivers to drive the ultrasonic transmitter and the boost converter.  I intend to use a 3.7V lipo here and some of the design decisions I'd made for power saving with the big battery aren't going to yield much results here.  Just wanted to explain the weird power-up circuit.  I think on my next spin of this I'm just going to use an on-off switch rather than the push-button, and I'll probably leave the battery level divider on all the time rather than switch it through the pair of FETS.

    Cheers,

    Roger

Related