BLE: SoC recommendation needed - Page 1
Forum section: electronics / projects

author: poorchava
author_rank: Super Contributor
timestamp: February 06, 2017, 01:13:12 pm
content: Hi there,I want to ask about your practical experiences with BLE solutions from leading manufacturers. I'm in the process of developing a custom building automation project, for which BLE seems like a perfect fit. The BLE peripheral will just switch some IO an and off.The problem is that I do not want to spend shitload of money on custom compilers and IDEs, but I need this to be a one-chip solution due to size and cost constraints. I also don't have resources for lengthy bluetooth stack development or similar stuff. I just want to register a custom GATT based profile. It would be best it the whole BLE stack was already in ROM with headers provided or available as a binary in order to build into my application.So far I've looked into Nordic nRF51822, and it seems like it does support free tools, but I'm not sure how does it look in reality (eg. if it's not something like: you must buy our software stack or write it on your own). They also seem to be supported fairly well by VisualGDB, which I've thought of buying.Cypress Semi also seems to have several parts, some of their own design, some acquired from Broadcom. I assume that their own original parts use their PSoC Creator IDE, am I right?TI has CC2540, but as far as I can tell it requires some expensive toolchain from IAR (correct me if I'm wrong).If there is another low-volume friendly option, I will consider it as well. If you have some chip you like in particular, please post. If you have some bad experience with some chip, please also post.

author: Benta
author_rank: Super Contributor
timestamp: February 06, 2017, 03:21:37 pm
content: For this kind of stuff in low volumes, go for a module every time. Easiest are serial port adapters, which you control through a serial port with AT commands.Edit: something like the NINA-B1 perhaps?https://www.u-blox.com/sites/default/files/ShortRange_LineCard_%28UBX-14003456%29.pdf

author: alexanderbrevig
author_rank: Frequent Contributor
timestamp: February 06, 2017, 03:32:52 pm
content: I've used both PSoC and Nordic. Both are good but the nRF52 would be my choice. It also has RFID for pairingHere's my recipe for setting up gcc:http://alexanderbrevig.github.io/technology/2016/01/25/nRF52-gnu-toolchain/Just as an absolute last comment. If you've not decided on BLE, check out Thread a well

author: poorchava
author_rank: Super Contributor
timestamp: February 06, 2017, 05:12:14 pm
content: I need to avoid anything that requires a microcontroller (as in module + uC talking via AT commands). I also do not want serial emulation, as it seems like an unnecessary complication.Especially, that as far as I understand BLE, serial port implementations are kind of hacks, not something that was intended from the beggining (maybe I'm wrong here).Also, by 3-of I meant that this will not go into open market, at least there is no intention to do so, but still 3 installations will contain between 50 and 170 nodes each, so price of single node does matter.As long as NRF51 is not obsolete or something, I will prefer it over NRF52, as I have no use whatsoever for extra features the NRF has, and judging from prices of chips and modules - the NRF52 is 2x more expensive.The mentioned Thread protocol has paid membership, and seeing the price they have 'fuck off small player' attitude. Another thing is that in my application controller devices are also smartphones, so it pretty much has to be BLE.EDIT:the module might be fine, if it enables me to configure it in such a way that i can run my own application on it. Eg, some sort of AT command bootloader. Application language might be anything, C, basic, python or whatever else, as long as it works.

author: janekm
author_rank: Unknown
timestamp: February 06, 2017, 05:23:22 pm
content: Quote from: poorchava on February 06, 2017, 05:12:14 pmNRF51 is still a perfectly fine choice. It's probably the most widely implemented BLE SoC so it's not going anywhere. There's massive availability in the channel. The more recent versions of the Nordic SDK support GCC pretty well with makefile projects. You don't have to buy anything, not even a dev board any more (used to need that for the key to download the SDK but they came to their senses).NRF52 is nice though... You mentioned that you are not that price sensitive so it might be nice just to have the flexibility. I'm using it on almost all my recent projects aside from those that are super price-sensitive (i.e. <$5 manufactured cost in volume).

author: free_electron
author_rank: Super Contributor
timestamp: February 06, 2017, 05:41:26 pm
content: cypress psoc with ble on board.easy peasy. drop in whatever hardware you need in the psoc designer. write code. works.and they have excellent demo video's.http://www.digikey.com/product-detail/en/cypress-semiconductor-corp/CY8C4247LQI-BL483/428-3368-5-ND/5044728

author: alexanderbrevig
author_rank: Frequent Contributor
timestamp: February 06, 2017, 06:02:07 pm
content: Requirements are revealing themselves. So it's something along the lines of 300 units with BLE...?What about power? Does it need certification? Are you sure BLE range is sufficient?You asked for experiences and it seems you've got a fewPS: Thread license is only required if you market it as a thread device. You can use OpenThread for this intranet. Just saying for the benefit of reader, not OP as BLE is a requirement.

author: Benta
author_rank: Super Contributor
timestamp: February 06, 2017, 07:43:36 pm
content: The reason I recommend a module is, that the majority of the modules on the market with built-in stack are already approved.Spinning your own also means getting your product certified and homologated, and believe me, that's expensive!In experience, the break-even point between an own SoC design and certified modules lies at around 10k...20k pcs.Just because a frequency band is "unlicensed" does not mean, that you can do what you want. It just means that you don't have to pay for using the band (unlike, eg, FM radio).Every piece of equipment going "on air" needs to be certified, or at least be provably able to fulfill all requirements. Guess what:youneed to prove that it's OK if someone asks. Not the SoC supplier.It's a minefield, don't go there.

author: hlavac
author_rank: Frequent Contributor
timestamp: February 06, 2017, 07:53:27 pm
content: I have looked into BLE stuff from TI (CC) but their only toolchain was a ridiculously expensive third party ide.Might be cheapest for extremely large quantities but not my case.Ended up picking Cypress PSoC4 that has nice free IDE.

author: miceuz
author_rank: Frequent Contributor
timestamp: February 06, 2017, 08:00:46 pm
content: I had a good luck using silabs BGM111 module. It has a former Energymicro cortex m3 core inside - very nice design, good documentation and prompt support. It has just started to support gcc, but also can be programmed using a simplified scripting language. All ble related stuff is abstracted away - you just provide xml file describing services and characteistics, then use simple bindings in code. I'm developing under Linux, so it's crossplatform.

author: poorchava
author_rank: Super Contributor
timestamp: February 06, 2017, 11:20:54 pm
content: Quote from: Benta on February 06, 2017, 07:43:36 pmBy no means do i want to spin my own module. I just require the said module to be programmable in some sensible language so that it can work standalone and run some very simple application without external uC. As far as I understand most of the modules, even if based on nRF51822 or similar SoCs, just expose an UART interface for "BLE do this, BLE do that" style AT commands.As for the certification, I don't care about it that much. Besides, ETSI rules for stuff like WiFi and such limit power to about 18-20dBm depensing on modulation scheme. IIRC most BLE SoC cited something like 3dBm and that's at a very low duty cycle considering they only broadcast advertisement packets.Quote from: free_electron on February 06, 2017, 05:41:26 pmI see that I can get a module with PRoC chip for about 5...5.50€ + VAT. I did some stuff with PSoC in the past, so I know my way around tPSoC creator. Any idea whether or not I can reuse the debug interface included in PsoC 4 or PSoC 5 devkits? I actually have a few of those laying around, which I brought from recent trade fair in Munich (btw, Cypress guys had really nice live demos going on).EDIT: How about Microchip? They seem to have some normal, BLE and dual mode modules, but I haven't found one, that would be normally programmable with PIC or MIPS core. Maybe I didn't look hard enough?This seems like a solution: ATSAMB11. Microchip borged Atmel tech?

author: janekm
author_rank: Unknown
timestamp: February 07, 2017, 09:28:39 am
content: Quote from: poorchava on February 06, 2017, 11:20:54 pmMost of the modules based on NRF51 expose the SWD interface for reprogramming, there's a list here:https://www.nordicsemi.com/eng/Products/3rd-Party-Bluetooth-low-energy-ModulesThe NRF51 line is in my estimation by far the most stable BLE platform, and unless you have some specific requirements that would need say a PSoC I would look there first. They're on version 12 of the SDK. There is also support by just about every community project that touches BLE out there. Nordic's support team are also superb and very approachable. I know I sound like a broken record but I've used those chips since 2012 so I feel comfortable to recommend them (and I suppose it also makes me somewhat biased).BTW there's two types of certification for BLE, the physical hardware certification required for CE/FCC (which in many cases needs to be done for the complete product anyway, not just the module) and BLE SIG certification (which is essentially required for the patent and copyright license that they implicitly offer through their certification), which these days also can't be completely skipped by using a module (at least they still want their fees). Though I imagine there are some projects which skip the BLE SIG registration (pretty expensive) and don't put the trademarked logo, deferring the costs until the letter from the SIG arrives.BTW CE/FCC testing is cheap compared to the tests required by the Bluetooth SIG. It's a bit of make-work for the test labs approved by the SIG.Quote from: poorchava on February 06, 2017, 11:20:54 pmI would stick with a vendor that has been around in the BLE space for a while, otherwise you may end up debugging their SDK the moment you stray beyond the blinking lights examples. And many of the SDKs are pretty lacking once you start needing more than the basic features.

author: Wilksey
author_rank: Super Contributor
timestamp: February 07, 2017, 11:04:15 am
content: No affiliation or anything, just to say.I use the NRF52 chip, the main difference apart from cost over the NRF51 is a Cortex M4 vs Cortex M0, pay your money, take your choice.The BLE stack is a free soft core (called "Soft Device") which is programmed in a particular memory region of the chip, like an API, and your program origin should be a particular address (all in the docs).I have had great success with this chip, and I later moved to a full FCC approved BLE600 series from Laird (again, no affiliation, just a good product), I think it cost around £6, and is widely available, they also do one based on the NRF51 I believe too.If I remember all programming pins are available on these modules (Single Wire Debug, SWD).

author: danadak
author_rank: Super Contributor
timestamp: February 07, 2017, 12:23:37 pm
content: Cypress PSOC, tool is free, just a few tidbits about it -For me what stands out is -1) Routability2) Fast 12 bit SAR A/D and slow 20 bit DelSig3) DFB (Digital Filter Block) that is dual channel, handle FIR or IIR filters, or DFBcan be used as a GP fast processor block, similar to RISC block4) MSI logic elements GUI based and/or the UDB Verilog capability. Eg. the FPGAlike capability5) Onboard Vref6) IDAC, VDAC, OpAmps (up to 4), comparator, mixer, switch cap, analog mux....7) LCD, COM, UART, I2C, I2S, One Wire, SPI, Parallel, LIN, CAN, BLE, USB9) Custom components capability, create with schematic capture or Verilog10) DMA to offload processes like filters, COM, Display11) ARM M0 (PSOC 4) or M3 (PSOC 5LP) or 8051 core(PSOC 3)12) Extensive clock generation capabilities13) All components supported by extensive prewritten APIshttps://www.element14.com/community/thread/23736/l/100-projects-in-100-days?displayFullThread=truehttp://www.cypress.com/documentation/code-examples/psoc-345-code-examplesGreat video libraryAttached component list. A component is an on chip HW resource.Free GUI design tool with schematic capture, "Creator". Components have rich API library attachedto each component. Compilers free as well.PSOC 4 is low end of family, consider 5LP parts as well. PSOC 4 also has arduino footprint boards (pioneer) as wellhttps://www.elektormagazine.com/labs/robot-build-with-cypress-psochttp://www.cypress.com/products/32-bit-arm-cortex-m-psocBluetooth -http://www.cypress.com/documentation/development-kitsboards/cy8ckit-042-ble-bluetooth-low-energy-ble-pioneer-kithttp://www.cypress.com/documentation/development-kitsboards/cy8ckit-042-ble-bluetooth-low-energy-42-compliant-pioneer-kit?source=search&keywords=CY8CKIT-042-BLE-ARegards, Dana.

author: poorchava
author_rank: Super Contributor
timestamp: February 07, 2017, 12:26:07 pm
content: Hmm, turns out we had the BLE devkit from Cypress at work and I got permission to borrow it for a week or two. Checking the prices, it seems like I can get Cypress modules for around 5.50€ + VAThttp://pl.mouser.com/Search/Refine.aspx?Keyword=cyble&Ns=Pricing%7c0&FS=TrueSilabs stuff comes next, at a very similar price. Any idead about the toolchain used to program those? Free or commercial? In theory it uses CM4F core, so GCC-based tools should be out therehttp://pl.mouser.com/ProductDetail/Silicon-Labs/BGM113A256V2/?qs=sGAEpiMZZMsGelYiB%252bjhZoTNNZoEXaEGaVtK5%2fIkX3pNW1s8zbAT2A%3d%3dCheapest Nordic-based module seems to be this (it's nRF52):http://pl.mouser.com/ProductDetail/Laird-Technologies-Wireless-M2M/BL652-SA-01/?qs=sGAEpiMZZMsGelYiB%252bjhZleLG2Ifdw%252ba8ag%2fP5J92LyQQE5B8fpuMw%3d%3d

author: janekm
author_rank: Unknown
timestamp: February 07, 2017, 03:23:41 pm
content: If you do care about cost (you said you didn't, but now that's all you seem to be considering?) then by far the cheapest is to just place the NRF51 directly on the board. Takes very few additional components and not hard to do if you just follow the reference layout (and you said you don't care about certification).

author: Benta
author_rank: Super Contributor
timestamp: February 07, 2017, 06:41:23 pm
content: Quote from: janekm on February 07, 2017, 03:23:41 pm"As for the certification, I don't care about it that much."Love that statement. Especially taken in conjunction with another thread here, where someone has a problem finding a rogue 433 MHz transmitter. And in my own neighbourhood, where cheap Chinese babyphones have killed all the garage openers as well as basic BT functionality."Nah, don't care about that. It's the neighbours' problem."Until the Polish equivalent of the FCC or the "Bundesnetzagentur" are at your door with a 50k Euro fine.

author: Wilksey
author_rank: Super Contributor
timestamp: February 07, 2017, 08:34:07 pm
content: Hmm,Well, at least the chip itself is certified, but buggering around with the antenna etc might cause it to flip.Just make sure you use the recommended antenna matching circuitry at least for testing!

author: janekm
author_rank: Unknown
timestamp: February 07, 2017, 09:14:57 pm
content: Quote from: Benta on February 07, 2017, 06:41:23 pmUsing the reference layout from an SoC vendor is not very different from using a module, if you think about it. Think of the reference layout as a module that you plug into the rest of your PCB layout. It's possible to make a module misbehave if you don't follow the guidelines from the module vendor (wrong groundplanes, wrong antenna, poor power supply). Same is true with the SoC (wrong crystal load capacitors, say). In fact, it would be easy to get higher unintentional emissions from a module if you're not careful. Most modules try to break out as many of the pins from the SoC as possible, and consequently have compromised groundplanes and a lot of short traces dangling off into space, perfect little unintentional antennas if not properly terminated. Consider this module for a particularly egregious example:https://www.aliexpress.com/store/product/PTR5528-Fingertip-size-nRF51822-Module-Ultra-Low-Power-Bluetooth-4-0-Low-Energy-RF-Module-Free/130096_1705429590.htmlSome IC pads broken out helpfully to completely unterminated traces that go nowhere. Massive interruption in the groundplane making a perfect slot antenna and terrible ground return paths. Laughable PCB trace antenna and placement. Ludicrous crystal placement with decoupling capacitor bridging over one of the crystal traces. You'd really have to try hard to make a layout that bad on your own boards. Of course most modules don't look like that, but they typically try to be as small as possible while breaking out as many pads as possible which will always be a compromise.The rules from the FCC made sense when they were written, but for most intents and purposes the NRF51 and similar chips (even more so for say NRF52 with built-in balun) are "modules on a chip". If you're using the softdevice for all the radio handling, you will not be able to exceed the Bluetooth limits on channel occupancy. And exceeding transmit power limits would also be pretty hard to do as the chip doesn't have a PA powerful enough for that. That pretty much leaves harmonics, which you could get if you're using the wrong balun components with NRF51 (so best to stick with the ones from the DK).In contrast, some of those Chinese babyphones and similar equipment are built from the cheapest of hand-soldered discrete transmitters with hand-rolled coils and little regard to harmonic suppression. It's kind of amazing they work at all. Much easier to get that wrong especially when the drive for cost reduction is taken into account.Making stuff carries risks, and if you try to protect against all of them, you'll never really get anywhere. If you're Apple, it's appropriate to spend a few million $ or so to comprehensively test the iPhone and production processes against every possible eventuality. And it's a good idea because phones catching on fire doesn't make for great marketing.If you're making 100 units of something, and your overall budget is say $10000, you're going to have to think carefully about what testing is appropriate, or the project can not happen. Some people take the attitude that those projects just shouldn't happen, but I don't personally agree. HP started with $538 in working capital (including the drill press). If they had decided that they couldn't sell their first product without full FCC certification, the company would have most likely never have happened at all. Same for Apple, for that matter. And Dell too.

author: poorchava
author_rank: Super Contributor
timestamp: February 08, 2017, 12:51:34 am
content: I'm aware of the mess that FCC / CE certification is. In my day job I'm a senior designer for a company dealing in highly specialistic test equipment (insulation meters, low resistance meters, electrical grid parameter analysis and such) aimed mainly at energy generation and communication industries. I've gotten several commercial products through certification process (admittedly - CE, not FCC which is much more of a pain in the ass).In my book using modules is beneficial, because they are often made using what would be very expensive pcb tech for a larger board(multilayer SBU and stuff like that) which enables them to have superior EMI performance in comparison to anything we could roll on our own (we pretty much limit ourselves to 4 layer boards at most).After some 2 hours I've gotten the CY8KIT-042-BLE devkit to work. Some highlights:-there is another thing called CY8KIT-042-BLE-A, which uses different devices and has somewhat different support packages-downloading CySmart BLE sniffer requires installing some awkward download manager software (who the hell needs that?)-the software absolutely refuses to work if anything is not updated to the latest firmware. This includes debug interfaces and BLE sniffer-for whatever reason the way the example projects are configred, debugging does not work, with debugger failing with error M0015. After some half an hour of work i found some forum post, that pointed out that debug options are set to GPIO instead of SWD which pretty much disables any debugging. This is really dumb considered, that debugging is probably the first thing anyone is gonna try when starting out with that kit.On the plus side there is really a lot of documentation and application notes through which I'm gonna be going over next few days. It seems like that documentation does a pretty good job explaining the complex beast that BLE stack is in a simple way.

author: free_electron
author_rank: Super Contributor
timestamp: February 09, 2017, 03:24:58 pm
content: Quote from: poorchava on February 07, 2017, 12:26:07 pmthe silabs 111 and 112 doesn't require a devtool (or an antenna)hook up to the serial port. invoke command prompt and start writing code. it has a JIT compiler on board.

author: JPortici
author_rank: Super Contributor
timestamp: February 09, 2017, 04:51:49 pm
content: RN4871 from microchipi had a simillar need not so long ago, there is this new BLE module from microchip that has a scripting engine built in.what i had to do: an mcu is doing simple logic, switching leds on and off based on input and talking via uart to a device.want to use bluetooth as input too but didn't want to use both (very small board)actually, i have yet to try it but it seems it will be just what i needcheap-ish, very small format.

author: picdev
author_rank: Contributor
timestamp: January 11, 2018, 07:58:09 pm
content: dear soc guys, I want to create a very simple ble 5 application , nordic is the cheaper one, but how dificult is to start with soc?is there any book , or a full tutorial ?Also I came across with this module , it use texas IC , and as I see the have a fw that you can sent commands from UART(serial to ble api)http://www.mouser.com/ds/2/223/337-0201-1113267.pdfhttps://www.lsr.com/embedded-wireless-modules/bluetooth-module/sable-x-ble-module/serial-ble-api