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

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

AmbystomaLabs — Tue, 19 Jun 2018 13:34:11 GMT

There are plenty of config problems that can cause that to happen. That's really not my area of expertise. I'm sure there is a lot of info on it in the devzone.

Did you get my reply on your ground pours and thermals? I don't see it now in the list.

Actually right now I don't see most of the my last comments on your recent spin. I only see 2 comments and I sent you at least 4 or 5. I have been having a lot of issues with the new devzone site and I think the system may have lost them.

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

rogerarchibald — Tue, 19 Jun 2018 01:41:32 GMT

Just out of interest, I was starting to play with a new project idea and I configured one of my initial boards for that and used my DK as a Central. The DK can see my custom board, but still no luck with a phone. I assume that my antenna design is just crappy enough to not work with a phone's chip antenna but I'm right on the edge where a PCB antenna can see it.

I just received rev2 of my board today, and the stencil is on its way. Here's hoping that this one behaves better. Thanks again for the input on this!

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

AmbystomaLabs — Fri, 08 Jun 2018 14:08:04 GMT

I don't have more comments on the design.

I still think you should choose a different buck converter with integrated charge management. You still don't have a LiPo charging solution on the board.

TI has plenty of integrated buck/charge controller combos for 1,2, or even 3 cell solutions.

http://www.ti.com/power-management/battery-management/charger-ic/products.html#p1152=1;1&p1153max=0;1

Next time send me a PM or just email. The new Nordic site isn't working well and I rarely get notifications on questions. I think a lot of stuff is getting lost.

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

AmbystomaLabs — Thu, 07 Jun 2018 14:07:20 GMT

Yes that is the correct way to hookup C25. It actually doesn't matter if there are extra ground connections on the outside, but telling people to do it like this ensures that the phase reference for C25 is the same on all designs.

Your traces between series parts should be as fat as possible. Otherwise you are creating parasitic inductances with each interconnect. In this case same width as the pad will be fine. Then pinch in the ground flood to the limit of your boardhouses capabilities, generally about 5-6mils is ok. It still won't be 50ohms, but it will get it a little closer. You will still have matching work to do, but it will likely work reasonably well with whatever ref design values you are copying.

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

rogerarchibald — Thu, 07 Jun 2018 14:07:05 GMT

I was going to use SOL_SNS just to determine whether or not the solenoid is present before enabling the Boost. The plan is to use a pull-up in the NRF and then read it. If the low resistance of the solenoid is present, I'll detect a low input voltage of D2's Vf. If the solenoid isn't present then I'll see a hi-level and won't enable the Boost. You're probably right that it would be worthwhile to put some protection on the nRF side....If nothing else, a little RC between the nRF and the anode of D2 would hopefully catch anything that got through D2...That circuit is only measuring DC voltage prior to enabling the boost, so I could put a pretty big C there and 100 ohms between nRF and the C to hopefully snub anything out.

I'm hoping that I won't have too many issues with back-emf due to not switching the solenoid...If I was driving it with a low-side switch then I'd be more concerned, but I was thinking that things would be relatively graceful with this design, and that Q1 would never see much VDS due to it floating up with the boost output.

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

AmbystomaLabs — Thu, 07 Jun 2018 13:50:32 GMT

You should always pin out nReset to the SWD. This shows up a lot on the devzone. Your code can keep the SWD from initializing. If makes debug a real pain when this happens since holding the nRF in reset is the only way to fix the problem.

The J-link does does a pin reset in addition to issuing a reset command via SWD during programming.

Also you might find it easier using the standard 10 pin header that the programmers normally have. This makes the hookup easier since you don't have to make your own cables.

R5 is pointless since the nRF has internal pullups.

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

AmbystomaLabs — Thu, 07 Jun 2018 13:33:10 GMT

I don't know what the purpose of SOL_SNS is but even with D2, I would be concerned about the back emf from the solenoid being large enough that you could damage the nRF. It will take a few nsec for D6 to turn on and in that time the reverse voltage could easily be over 20 volts, maybe more.

For similar reasons you should use something other than the DMP1045U. The spec shows a max Vds of 12V. This should be a 50-100v part. That back emf will be massive from the solenoid. Also, to reduce the back emf, D6 should be a schottky and there should be a 100 volt chip cap across D6. Maybe a 1206 package so you can get the value right later. It doesn't need to be a big cap it just picks up the slack until the schottky turns on.

If you want to have some math fun you can find the inductance and Rdc for the solenoid and then calculate the peak voltage when you turn it off for your cap/schottky combo.

If SOL_SNS is to figure out when the solenoid has reach steady state, then you should do it another way. The boost converter will just increase the duty cycle as the current builds in the solenoid. Ideally at D2 you will just see a steady Vsolenoid nothing more. A safe easy approach would be a fat resistor on the ground return for the solenoid and monitor the voltage build with the nRF. There are plenty of cheap small ohm value resistors like that since they get used for the feedback in DC/DC converters. If you don't want to use the SAADC to monitor then choose a resistor value that will trip the CMOS to logic high.

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

AmbystomaLabs — Thu, 07 Jun 2018 12:52:47 GMT

Vias should always flood over vias (ie, no thermals) especially when they are used to get rid of heat as in your LED. The only time thermals should be applied to a via is when it is a thru-hole part then it is done to aid soldering.

Actually thru-holes and vias are normally treated as two different model types in most cad packages since in addition to thermals, the annular ring will be different.

Similarly you should not thermal the heat relieving pads on your led for the same reason. The only reason thermals get used on SMT is to help prevent tombstoning. This won't be an issue for your led as the ground pads are massive compared to the signal pads.

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

rogerarchibald — Tue, 05 Jun 2018 00:49:41 GMT

Please don't apologize, I'm willing to wait for free advice! I hope your travels were pleasant.

I added the upper layer ground pour and some stitching vias. One change here compared to the first board was that I ensured that C25 only returned to the ground pad of the NRF as suggested in the product spec, which I'd neglected to do on V1.

When I started looking into buck converters with plans to use a single 3.7V battery, most of the ones I found suggest at least 500mV of headroom between source and output. That means that if I wanted to use the entire range of the battery, my VCC would be well below 3V...I'm concerned about driving the Boost FET with that low of a gate drive, since the current FET's upper limit for VGSth is 3V. Stacking two batteries gives me loads of headroom, allows for use of a proper gate driver on the boost and will let me drop the DC on the boost drive. It's a bit of a tradeoff on cost to include two batteries, but I think it's worth it for the points mentioned above.

If I continue to run into RF issues with this board, I am considering moving this to a Rigado module, leaving the RF stuff to people who know what they're doing while maintaining a small footprint. The additional benefit of that route is a relatively easy transition to an NRF52840 in the future if I determine that I need the additional range offered by BLE 5, which is a serious concern of mine.

devzone.nordicsemi.com/.../Files2V2.zip

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

AmbystomaLabs — Mon, 04 Jun 2018 14:01:33 GMT

Sorry for the late reply. I've been traveling.

I will review more thoroughly later today. But, first thing I noticed is there are no stitching vias and no ground flood on the first layer. The ground pour on the top layer will help with your hot led also it serves to unify the top and bottom into one big ground plane and can help fix ground loop issues. There probably won't be any pour near the nRF, due to the congestion, but there is a lot of room elsewhere.

On your boost since it is a one shot event, I would keep it on the single LiPo and just put a big electrolytic on the output. You will have to figure out how long the latch opening takes. But I would guess it isn't over 200msec and a fat electrolytic would fit easily on the transducer side of the board. Then you don't care what the current output of the boost converter is since the power will come from the cap. Just keep the cap charged up and fire it when needed.

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

rogerarchibald — Fri, 01 Jun 2018 02:08:50 GMT

Attached is the next spin on this. In the zip are gerbers, Eagle files and a schematic pdf. Taking a bit of your advice, I've gone to a 2-layer board and implemented bucks for VCC and onboard for the NRF. After messing around with the first board powered off of a single 3.7V battery, I think that I'm running too close to the limits of what that can do when running the boost converter, especially once it gets down <3.7V. Things work great at 4.2V, but I want a bit more headroom for comfort, so I'll run this off of 2x smaller 3.7V liPos in series.

I have to clean up some reference designators on the board, and I've not yet gone over the schematic with a fine-tooth comb for errors, but any thoughts/pointers on this would be well received. I'm looking around for access to some RF gear, hopefully I can get some eyes on what's happening with the radio...

Thanks!

Rogerdevzone.nordicsemi.com/.../Rev2Files.zip

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

rogerarchibald — Fri, 18 May 2018 01:10:43 GMT

Thanks for even mentioning that, but in the end I will end up respinning this myself....it's the best way to learn! That said, if you had any more robust antenna layouts from previous builds that you may be willing to share, I would definitely appreciate that.

Ultrasonic is really interesting. The first spin of the 8-bit trap used a PIR sensor, but it was too prone to false positives when set outside on a sunny day. You're correct that the ultrasonic is driven at 40KHz, but I've never seen any critters hesitate to go in there any more than they do with a standard live trap. Obviously 40k is too high for human hearing, but I fire the ultrasonic every 100mS and there's a faintly audible 10Hz 'ticking' when the transmitter is firing.

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

AmbystomaLabs — Thu, 17 May 2018 20:09:28 GMT

Sorry, my company HQ is out of Florida and currently I'm working out of Massachusetts. I get out to SF once in a while, sometimes for Arm Tech Con or ESC Silicon Valley.

If I can work it into my schedule, I will spin a design for your live trap. The ultrasonic stuff looks interesting and I'm thinking about doing a PCB artwork based output match for the RF and antenna that Nordic might like.

I'll pass along the design info if it happens.

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

rogerarchibald — Thu, 17 May 2018 00:48:13 GMT

The solenoid current is pretty substantial (~2A @12V) and the prepackaged boost drivers aren't an option here. The 5A rating is for the internal FET, and if I'm looking at say 3.5V Vbatt boosting up to 12V @ 2A, the internal FET is going to get fried. Those solutions are great for a regulated supply at a moderate load, but my discreet boost is sacrificing simplicity, size and regulation for pure beefiness. I'm planning to run this off of a 26650 battery which will supply more than enough current, provided I have a decent efficiency (and make sure that the power LED is turned off as part of the solenoid fire function!). One thing that my current rev doesn't have, but is needed, is a 'solenoid sense' circuit so I don't fire up an unregulated boost designed to provide that kind of power when there's no load. I have a simple circuit in mind that I think will work nicely.

I've used little battery managers (Microchip 73831) with smaller lipos. I'm not sure if I'll go that route here...I haven't looked into compatibility with the big batteries and had just assumed on using an external charger, but an on-board charger with a micro USB connector might be a good option here. That is what I used for the battery on the remote of the first revision of OpenTrap.

Again, I'm sure you're a busy man and I appreciate you taking the time to provide feedback on my design. If by any slim chance you're planning to be at the SF Maker Faire this weekend, I would like to offer to buy you a frosty beverage!

Cheers,

Roger

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

AmbystomaLabs — Wed, 16 May 2018 20:23:41 GMT

I made a mistake. You will still need your turn off fet for the solenoid due to the boost topology.

Sorry, I missed that.

Though, I would still use a packaged device instead of the way you have it in the schematic.

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

AmbystomaLabs — Tue, 15 May 2018 13:31:53 GMT

Yes the SN74 makes a good buffer. Prob not necessary to use its inverting cousin in the design, you can easily use two gpio out of phase of each other to make your bi-phase arrangement.

Though I understand the prudence in using the SN74, a MuRata spec on a 40kHz transducer shows it as 2,500pF. Assuming 5mA gpio you can easily switch this thing rail to rail at 200kHz. For more margin, you could lash two gpio onto each phase for 10mA total sink/source capability. GPIO state changes for all gpio on the same clock edge, so they will always stay in phase as long as you write the register correctly. But as you stated, more assurance with a buffer.

On the boost then, assuming you have something like a 1amp 12vdc solenoid on the door latch, then I would still use a packaged converter. Just use the chip enable on the converter to turn it on and off. Then you can lose Q1, D1, Q6 and the sn74 is just replaced with the boost chip. There are many out there, but here is an example of one from Diodes that give 12vdc at up to 5amps from a 2.5-5.5vdc source. Assuming 1amp out and 3vdc in that means switch current of around 4amps. You will need to buy a good inductor. But there are plenty of smt devices that will handle that kind of current. Something with a saturation current of around 8amps or so should do it. Boost chip example: www.diodes.com/.../PAM2421_22_23.pdf

I agree with you LDO's are easy, but on something with a LiPo you are going to want a complete solution with charge, protection, buck switcher. Then you end up with a user friendly device that you plug into a wall wart once in a while to charge it up.

You didn't specify what frequency the ultrasonic is running at, buy you may want higher than 40kHz. The web says cats can hear to 64kHz. I know our cats get freaked out by high frequency noises. Though it is possible a feral cat might wonder what the noisy cage is all about and be inquisitive.

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

rogerarchibald — Sun, 13 May 2018 16:08:52 GMT

Thanks for taking the time to write such a detailed response.

I'm going to ditch the level shifters on the ultrasonic transmitter on the next spin and drive it off of VCC via some buffers (It's a highly capacitive piezo transducer and I'm weary to drive it direct from the NRF GPIO). I'll have to increase the gain on my ultrasonic receiver due to the lower drive voltage, but at least it will be a constant voltage and not varying with Vbatt as you say.

On my previous board I had a much higher battery voltage and I used gate drivers in the places where there are currently level shifters: the gate drivers' enable line was tied to VCC, so when my LDO was off they drew virtually no current...On that note, Q8 serves to disconnect the resistor divider for battery voltage to further reduce current consumption, and on the previous board, when VCC is disabled and Q8 was off, I was down to a few hundred nA consumption. Next time around I'm not going to be so miserly about a few hundred uA here or there and just have a power switch that turns the whole thing on.

I didn't mean to give the impression that the boost is going away: the boost is a separate circuit from the ultrasonic and it actually develops the voltage required to fire the solenoid when the user actuates the trap. Q6 is a pretty beefy part with a decent amount of gate capacitance and I was concerned about driving it directly from the NRF, but again the level shifter probably isn't the best device to use here...That drive was so much easier with a >6V Vbatt and a proper gate driver!

I've used quite a few buck converters in hobby designs before, but usually constant current devices for hi-power LED's. I understand that LDO's are somewhat wasteful, but in a device with a power requirement of ~100mW I'm generally not too concerned about it....In my day-job of working with downhole oilfield electronics where power budgets can get tight, switchers are a necessity, so sometimes I like to play with different toys in my hobby electronics. I'll look into a buck for the next spin. I'm a fan of Diodes Inc. switchers: they seem to work as well as TI parts but they're substantially cheaper for an equivalent topology.

D7 is a power LED as you state. I found that package on Luxeon's website. I was weary of the concentration of vias but I've had that part made at two different board houses so far (I use it on a few other projects as well) and nobody's complained.

Thank you again for your input! I've shared the link for cattail with my neighbour, whose cat has set off my OpenTrap alarm several times in the course of my back yard testing! I'm making some progress with porting my firmware over to SES and SDK14.2, and once that's all solid and I understand all the new changes I'm going to resin this thing.

Cheers,

Roger

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

AmbystomaLabs — Sat, 12 May 2018 14:16:59 GMT

As an amusing coincidence, my company makes Cat Tailer (www.cattailer.com). It is a +9dBm, bluetooth tracking device for pet cats. During a stint in the UK, we embraced the RSPCA's approach of, if you are going to have a pet cat, let it live a natural life by experiencing the outdoors where it is reasonably safe to do so. Cat Tailer serves to enhance this by giving you a way to find your cat to get them is at night, or as a way to keep track of them and know they are safe. A scared or injured cat won't call out for you when you look for them. Cat Tailer give you a way to always find your pet.

We are also big advocates of controlling feral populations and your live trap and spay/neuter and release program with the ASPCA sounds great!

I would love to provide assistance on your respin. When it is complete, please pass it by me either directly via email or the devzone before you have it built.

Below are my comments on your design:

1. You said you were losing the boost converter, but notes on it anyway: On the boost converter, it appears you are doing PWM to modulate the ultrasonic transducer you mentioned. I assume you would be using the onboard pwm on the nRF to facilitate this. Not sure why you need the level shifter, Vgs should be low for your fet. If not then choose a better one. Diodes Inc. always has nice products in useful packages,especially for heat dissipation. Vg threshold should be less than 0.5volt and the device should be full on by 3volts. ie, nRF_VDD

2. On U2, linear regulators just throw away power. Always use a switcher(ideally there will be one switcher for the whole device, see comment 4). Again, look for a synchronous buck converter. Many operate at 1-3MHz so the inductors are small. TI, ST, and Diodes Inc.are all good companies. The topology is super easy, and they will all come in a small QFN package with ground slug. Also I no idea what the point of Q8 is. I would suggest you could remove a lot of U2, resistors and Q8 and replace everything with a proper LiPo controller. And, resistors just suck power so a good design should have 10k voltage dividers. ie, r38, r37

3. There is no point in running the ultrasonic transducer off of vbat(ie, vin). vbat will vary from 4.2 to 2.7 for a single LiPo. Correspondingly the output from the transducer will vary and give you unreliable performance. Just run it off of the switcher you choose from comment 4 which will make Vdd_nRF.

4. If you use a LiPo as you mentioned, look at some of the TI solutions. You can get charge management, over voltage protection, under voltage protection, over current protection, different charge voltages to optimize the life and a synchronous buck converter that will go to 100% duty all one tiny QFN.

5. I thought I saw a tantalum on your design. Never use tantalums. They have static losses that are substantial and will shorten your battery life. Also, they fail easily. They can dump current so fast that an accidental short while you are debugging causes them to blow apart from the thermal stresses. Chip caps are safe and fast, plus you can get small 0805 devices at 47uF cheaply. Always use a mix of cap SRF's though. This is required due to the noise from all the electronics. I've gone on about it elsewhere on the devzone if you want to read up on it. Generally these things will have a mix of 47uF, 2.2uF or 4.7uF, and 0.1uF's on VDD.

6. Unless you have a real reason not to, then you should use the buck converter on the nRF, then you can have 3-3.6vdc gpio, better power management software and maybe lose some of the level shifters. If you are really trying to push your LiPo then you can run the nRF at 2.7 while still using the internal buck converter for the 2.7 to 1.8 solution.

7. Generally you don't need all the 1k gate resistors. They show them on data sheets simply because you can fry the gate with a large inrush of current. Most cmos devices can't deliver that much current so generally the need is not there. But you should always go through the specs to make sure. I bet they take up a lot of room though.

8. D7 seems to be a massive LED. The via pattern will not be liked by a fabhouse. The vias are too close together and this tends to weaken the board. Also, they don't seem to serve much purpose since they didn't connect to the ground pours. It looks like you copied it from the datasheet. Since they obviously didn't complain when you got the board made, just make sure to connect the vias to ground so it floods on all 4 layers. Then it should be fine. It's not pretty though.

9. You will save a lot of space on your board by using a current standard for the pad sizes. Looks like your models are following an old standard. You should update to a more modern take on this. Also, if you are hand soldering the parts, I advise against it. Really easy to cause thermal cracks on chip parts and they are nearly impossible to see even with a microscope. Also, most home built ovens are a bad idea they tend to overheat the parts. For hand built prototypes or one-off designs, I normally buy a cheap metal stencil from OSH Stencils for the paste, then once the parts are placed preheat the board on a rather cool hotplate to 100c then hit it with hot air reflow until done about 60 seconds. Been doing that for years and never had a problem. Plus it is easy to stick to the recommended reflow profile.

10. So, all this brings us to why doesn't it transmit well? It'd be great if you had a spectrum analyzer, but I'm guessing you don't. There are really cheap USB WiFi card based ones if you want to consider it.

Here is what I see wrong on the nRF stuff:
A. Your grounding is just really bad. I see a lot of shared grounds You even seem to stress them in the schematic. As an aside, it is always better to never have a 4 point junction since it is ambiguous whether you have 4 things connected or just a dot over a couple of connected things. Also, if you break out the parts and put a ground symbol on all the caps you tend to think about how it will have to get laid out to still have good grounding. So, always avoid shared grounds. A via is about 0.7nH and a lot of impedance can show up at high enough frequencies. Where possible always put a via in for every ground. For this reason I always use big 15 or 20 mil stitching vias in the floods then a bunch of 8-10mil vias for local grounding and ground slugs (eg, nRF). You can't turn the board into swiss cheese but you need grounds that won't talk to each other.

B. You will never be able to match that antenna to the nRF with 2 components. A quarter wave monopole has an ideal impedance of 36.5+j21.25. The two components on there are just the ones Nordic specs to get the nRF to 50ohms, after that you need to match the antenna to 50ohms. Even Nordic uses about 5 elements to get a 1/4 wave to match to the nRF. You could try to do a complex impedance match between the two, but without a VNA you won't succeed. You might consider a more forgiving antenna like an F-meander hybrid. TI wrote a nice whitepaper on one. It has even been referenced in the devzone.

C. You could save some space by using an SMT header for the SWD. I think the standard jtag/segger ribbon cable is 50mil pitch and mates well with an SMT header. You can get the correct orientation of the pins from the segger site. I did similar on a programming jig for one of my companies products.

D. Ah, power planes! I don't like power planes. Over 20 years, I have never had a problem on boards with routed power and one common ground, yet I have been called in many times to debug boards with power planes and split ground planes. The power plane results in a lot of unexpected coupling between power and signal routing. It is just one big capacitor sitting underneath all that stuff on the bottom.

E. Your microstrips on the nRF output aren't characterized. Not really important since you have to match it anyway. But matching is more deterministic when the strips are 50 ohms. I have a standard 0.062" 4 layer stackup I use with FR4 that is very reliable. Also too, you could easily do this as a 2 layer design and save money. This could be useful since it is an open project for the community.

F. Also, your RF grounding is pretty bad. But that's all part of (A).

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

rogerarchibald — Fri, 11 May 2018 14:04:04 GMT

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

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

AmbystomaLabs — Thu, 10 May 2018 14:13:59 GMT

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.

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

rogerarchibald — Thu, 10 May 2018 00:53:19 GMT

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.devzone.nordicsemi.com/.../OpenTrap_5F00_BLE1.sch devzone.nordicsemi.com/.../OpenTrap_5F00_BLE1.brd

Thanks again for the support and I welcome any feedback.

Cheers,

Roger

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

Edvin — Wed, 09 May 2018 14:03:08 GMT

sorry. I didn't see that you responded to the other comment.

Ok. Then this sounds like there could be some issue with the antenna or the pcb. We can check the PCB layout if you like. I am not the one doing this around here, but if you can upload the entire schematics, someone can take a look at it. If you don't want to upload it in public, you can create a private ticket.

Best regards,

Edvin

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

AmbystomaLabs — Wed, 09 May 2018 12:17:02 GMT

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.

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

rogerarchibald — Wed, 09 May 2018 02:15:47 GMT

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

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

AmbystomaLabs — Tue, 08 May 2018 16:56:17 GMT

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.