Looking at BLE SOCs, nRF52

[JPortici]

I'm asking here because i know there are some nordic afficionados, we are considering transitioning one product from MCU + BLE Module to an integrated solution, and before diving in i wanted to ask some questions.
To throw a partnumber: nRF52810

First, it seems that the nordic parts are not plagued by dealbraker erratas such as in the ESP32, and that is good. By looking at the errata it seems that the NRF52 ADC is actually usable, good. And the PWM module while being fairly simple seems to be Good Enough™ for analog signal generation. So far so good.

However, i don't understand if there are input capture and output compare modules. That is a hard requirement because we need to acquire and generate some bitbanged signals with microsecond resolution (which is not a problem for a lowly PIC24 at 16MIPS, but with ARM cores, i honestly don't know)
It seems the timer module implements input capture and output compare but i don't know the limitations if i want to do both, and the total amount of channels (2in + 2out should be enough)

Another question: these devices are single core, which means that the CPU is bound to be spending some time managing the BLE stack. Can i assume that it is going to be a hell of a problem for the bitbanged signal generation/acquisition, which has the top priority? (Provided that DMA can't help me)
How much CPU time should the BLE stack take? because if it's frequent but really short i can work around it, if it's going to take a whole 1-10ms continously, that is going to be a major problem.
Ideally i should look for a dual core device - and there are new STM parts i'm also looking at as well

Final question: is there is a preferred IDE/Toolchain? i'm a fan of prepackaged things that "just work", i see that many sources seem to favor VSCode, which i'm not really a fan of

Bonus: How much of a pain would it be to certify the thing?

[nctnico]

Which ESP32 are you referring to? For the ESP32-S3 is errata is pretty short and the software ecosystem is pretty good in my book. I'm currently working on an ESP32-S3 project using BLE and I must say I'm quite happy with the software ecosystem Espressif is providing.

[JPortici]

I remember reading, just a couple of months ago, much longer errata documents for ESP32 modules of the ones i can find now, with many features i was interested in (mainly CAN and ADC) being effectively useless. (NB: this particular application does NOT require CAN, i was just mentioning the fact)
I believe it was the S3

[mayor]

Have you checked TI's CC2652? I think it has what you need, having a Cortex M4F, dedicated Cortex M0 core for radio operations, as well as another core for different types of sensor processing (including comparators, for example).

[SiliconWizard]

Have you checked TI's CC2652? I think it has what you need, having a Cortex M4F, dedicated Cortex M0 core for radio operations, as well as another core for different types of sensor processing (including comparators, for example).

In terms of power consumption, these TI chips are very good.

[tszaboo]

Another question: these devices are single core, which means that the CPU is bound to be spending some time managing the BLE stack. Can i assume that it is going to be a hell of a problem for the bitbanged signal generation/acquisition, which has the top priority? (Provided that DMA can't help me)
How much CPU time should the BLE stack take? because if it's frequent but really short i can work around it, if it's going to take a whole 1-10ms continously, that is going to be a major problem.
Ideally i should look for a dual core device - and there are new STM parts i'm also looking at as well

I'm fairly sure this one also has a coprocessor with some sort of ROM memory handling all the radio things. Most of these 2.4GHz radio chips will, unless it's a dedicated transceiver.

Bonus: How much of a pain would it be to certify the thing?

What certification we are talking about. RED? BT? Honesty, I would just forget about the BT certification, it's a subscription for your company, for every year you could get an 1 GHz oscilloscope or other new toys, or this logo.

Have you checked TI's CC2652? I think it has what you need, having a Cortex M4F, dedicated Cortex M0 core for radio operations, as well as another core for different types of sensor processing (including comparators, for example).

In terms of power consumption, these TI chips are very good.

It's OK, but it's a 5 year old chip and it shows. I've seen chips that have -3dB better receive sensitivity, and use 30-50% less power when transmitting with the same power on this band. That sleep current looks good, but that only matters if your average current consumption is less than 5-10uA, or it's a "smart button" type of thing.

[bookaboo]

I’ve used the ESP32-S3 for BLE with very few problems. Pretty happy with ESP-IDF on VS-Code.

My colleague also uses nRF52x because of the lower sleep current available. Occasionally I have to check the code or make a small mod on SES which I don’t find particularly intuitive and as far as I know has no intellisense.

I’d rate Espressif support better too.

[SiliconWizard]

It's OK, but it's a 5 year old chip and it shows. I've seen chips that have -3dB better receive sensitivity, and use 30-50% less power when transmitting with the same power on this band.

We would be humbly obliged if you cared to share a reference.

[tszaboo]

It's OK, but it's a 5 year old chip and it shows. I've seen chips that have -3dB better receive sensitivity, and use 30-50% less power when transmitting with the same power on this band.

We would be humbly obliged if you cared to share a reference.

Most of the Series 2 Silicon Labs Blue Geckos.

[SiliconWizard]

It's OK, but it's a 5 year old chip and it shows. I've seen chips that have -3dB better receive sensitivity, and use 30-50% less power when transmitting with the same power on this band.

We would be humbly obliged if you cared to share a reference.

Most of the Series 2 Silicon Labs Blue Geckos.

OK thanks, I was not really impressed by previous generations of Silicon Labs MCUs, but this Series 2 looks pretty nice.
Looking at the specs of the EFR32BG24, it's clearly superior to the CC2652 even just on paper.

[cv007]

I only do simple ble broadcasting data such as temperature, or device 'odometers' (keep track of run times of devices), but have used nRF52 and EFRBG22.

For the nRF52 (52810 raw device via Laird board, and 52840 usb dongle, later bought an nRF dev board), I was using the command line only (they have a bunch of examples with makefiles), using the led on the 52840 dongle for error codes (many at first, since frequently using sdk wrong), and could get a basic app running without a lot of problems. It is a process at first to figure out the software stack that needs to be loaded, and how to deal with programming via the nRF desktop app (electron app). They also have a big config file with tons of defines/options to sort out or find, which is not pleasant to deal with. The actual hardware is pretty nice, as its generally quite simple work with and things work as expected. (The Segger ide can be used, is free for nRF, but I did not use it).

Not long ago, I started to use an EFRBG22 via a ~$10 board they sell, doing the same projects as the nRF52. Although I'm not a big fan of ide's, their Eclipse implementation is polished and probably took 10 minutes to get a basic example working, and very little time to do the same projects as I was doing on the nRF52. I don't really need to deal with buying the raw mcu as I simply use their cheap dev board or can find cheap boards using the BG22 (Laird, etc.), but looking at mouser, they have lots of stock and quite inexpensive compared to the others. The hardware is also quite simple to deal with, and their sdk is also pretty good.

The bottom line for my simple needs is that the EFR is quite a bit easier to use, has low power consumption similar to the nRF (either which I can get years out of a small 3v battery). Silabs also has plenty of good documentation.

Get some dev boards and simply try them out. It does require some effort to get to a point where a good decision can be made. I had tried Silabs a few years ago, but was lost and gave up too soon. The BG22 for some reason seemed relatively easy- I think they have improved their ide/sdk/documentation quite a bit, so maybe that contributed to success this time. (I don't know what Nordic has done in the last year or so, maybe they have improved also).

[tszaboo]

It's OK, but it's a 5 year old chip and it shows. I've seen chips that have -3dB better receive sensitivity, and use 30-50% less power when transmitting with the same power on this band.

We would be humbly obliged if you cared to share a reference.

Most of the Series 2 Silicon Labs Blue Geckos.

OK thanks, I was not really impressed by previous generations of Silicon Labs MCUs, but this Series 2 looks pretty nice.
Looking at the specs of the EFR32BG24, it's clearly superior to the CC2652 even just on paper.

I've been regularly using the geckos in the past 5 years, and I've been very happy with it. The software guys complain about the default IDE, but they always complain about every IDE, so no difference there. What is really nice is that you can re-map all the GPIOs practically everywhere, has a built in very low power DC-DC, loading caps for crystals, and the RF has impressive specs. I regularly get 500m+ range with 10dBm output with inverted F PCB antennas, but they also measure good at EMC/RED.

[Siwastaja]

I've been using nRF52 extensively lately, and the chip peripheral design is quite fresh which shows in both good and bad sense, mostly good, with great ideas that ease the use and increase flexibility - like routability of any peripheral into any pin, TASK/EVENT system with totally generic interconnect so that any peripheral can work together with any other peripheral, DMA which is so trivially easy to use that they don't offer non-DMA modes on some peripherals at all; etc. That said, you will see strange limitations like a timer incapable of zero-latency resetting at a certain count (obvious with most other microcontrollers; in nRF, you do it using the event system shortcut which still adds some clock cycles of delay), or impossibility of instantly disabling UART because someone thought that it might have to "flush" 4 bytes or some bullcrap like this.

That being said, PWM peripheral is capable of doing quite some advanced stuff from DMA alone - sequences with repeat counts, looping or double buffering, even loading different counter top values from memory for each cycle. They also have good number of peripheral instances, e.g. nRF52833 has five TIMERs, 4 PWM generators, three realtime counters (really useful for low-power stuff). Could be much fewer, actually if you compare to ST for example you see similar number of instances only on the flagship cortex-M7 models.

Lack of generic DMA peripheral which could be triggered to do a transfer from any EVENT (given their excellent EVENT system) is nearly unbelievable, since it would be trivial for them to implement. But it seems you could use TIMER(s) to do input capture and PWM(s) to do output generation, but realistically you would have to prototype it quickly because as with any microcontroller, some weird limitations are not easy to see until you actually start writing code and testing it!

I just did an IR remote signal generation with the PWM peripheral with very little CPU intervention and it was an interesting project; they show you a fully-DMA example idea on web but that is unsuitable for real-world IR remote standards as it would require kilobytes of RAM buffers, but instead I made heavy use of the repeat counts and double buffering of the PWM unit so that the interrupt handler always updates one symbol in advance which makes it forgiving against interrupt jitter, and then the peripheral just repeats configured number of 38kHz cycles and gives an interrupt when the generation of next symbol has started, so that the repeat count for the next after that can be written.

Their SDK, their examples and their softdevices are a complete and utter mess, totally unusable. You have to write code from scratch and use third-party code for BLE if you need that, I'm pretty confident about this now. The difference to their HW design is massive. These MCUs are very nice to program register-level, much easier than STM32 for example, but on the other hand completely impossible to program using any SDK stuff. I spent a full week not getting even a simple LED blinker working with their SDK, and then spent another week writing a completely functional radio stack from scratch using their easy-to-understand radio peripheral on register level!

And the softdevices cannot be used because they are so bloated they don't actually fit to the device with any customer firmware! I don't know what they have been smoking. If you have a 512KB flash device, that will be 256KB after partitioning in two separately upgradeable sections which is mandatory if you want to update the networking stack and not brick devices, and then the BLE stack is over 200KB IIRC so you have some tens of KB for your whole application! Probably they thought you would factory program in their "perfect" softdevice and not allow it to be updated.

[Siwastaja]

What is really nice is that you can re-map all the GPIOs practically everywhere, has a built in very low power DC-DC, loading caps for crystals, and the RF has impressive specs. I regularly get 500m+ range with 10dBm output with inverted F PCB antennas, but they also measure good at EMC/RED.

How does this differ from nRF52 which you implied performing significantly worse? I'm seeing well over 500m range with 8dBm output with PCB antenna and good margins in EMC/RED, using Fanstell modules. No problems whatsoever.

[tszaboo]

What is really nice is that you can re-map all the GPIOs practically everywhere, has a built in very low power DC-DC, loading caps for crystals, and the RF has impressive specs. I regularly get 500m+ range with 10dBm output with inverted F PCB antennas, but they also measure good at EMC/RED.

How does this differ from nRF52 which you implied performing significantly worse? I'm seeing well over 500m range with 8dBm output with PCB antenna and good margins in EMC/RED, using Fanstell modules. No problems whatsoever.

Well, I was comparing it to the TI CC chip. But if you want  to compare it to the nRF, the max power is 11dB more for some gecko part numbers, which might be over the limit some cases, the receiver sensitivity is 1-2dB better for the BG27 series it's -99dBm for BT. Better sleep modes, and ~50% better RX currents. You have to be careful with the RX currents when comparing, some MCUs define it with DC-DC on, and the radio running on 1.8V though. Also for those nRFs, the ones with a lot of Flash and RAM get a worse radio for some reason.
The Nordic chips are very good compared to other solutions to be frank. If you need USB its a clear winner. I cannot comment on the modules, I have to use my own design.

[JPortici]

It's OK, but it's a 5 year old chip and it shows. I've seen chips that have -3dB better receive sensitivity, and use 30-50% less power when transmitting with the same power on this band.

We would be humbly obliged if you cared to share a reference.

Most of the Series 2 Silicon Labs Blue Geckos.

OK thanks, I was not really impressed by previous generations of Silicon Labs MCUs, but this Series 2 looks pretty nice.
Looking at the specs of the EFR32BG24, it's clearly superior to the CC2652 even just on paper.

as superior as it might be, it won't make me design in anything radio from sillab. I am still haunted by EzRadios and the geckos from that period

Their SDK, their examples and their softdevices are a complete and utter mess, totally unusable. You have to write code from scratch and use third-party code for BLE if you need that, I'm pretty confident about this now. The difference to their HW design is massive. These MCUs are very nice to program register-level, much easier than STM32 for example, but on the other hand completely impossible to program using any SDK stuff. I spent a full week not getting even a simple LED blinker working with their SDK, and then spent another week writing a completely functional radio stack from scratch using their easy-to-understand radio peripheral on register level!

Though this does not inspire confidence, at all. Being a BLE MCU targeted at BLE communication i expect the BLE peripheral stack to be a black box that just works that exposes a function to register a GATT profile, one to read and one to write a characteristic and a series of interrupts/callbacks for when it is connected/disconnected to a central, characteristic notifications and such things

[cv007]

but on the other hand completely impossible to program using any SDK stuff. I spent a full week not getting even a simple LED blinker working with their SDK

Though this does not inspire confidence, at all.

I'm not great at mcu, but was able to get their nRF52840 usb dongle to do some examples without a lot of problems. Command line only, except for programming the usb dongle which required their desktop app. There are some things to figure out, like which soft device to use etc. Initially I used an existing example (makefiles), created my own gpio class just from the datasheet, used an led to blink out error codes from the sdk for error return values. Eventually bought one of their dev boards, but used it only for programming a Laird module that had a 52810 on it (and could then use segger rtt to printf debug info via swd, instead of simple led error code blinking). Not saying it was all a walk in the park, but I wouldn't say you have to throw out the sdk and start from scratch. I think one of the reasons I initially chose nRF was because they did not require any registration to download any of their stuff (sdk, apps, etc., could even get the segger ide from segger if wanted without any hassle).

I wouldn't dismiss Silabs based on past experience. I have no previous experience other than I couldn't figure anything out several years ago, using one of their 'thunderboards'. Not that long ago, I bought their ~$10 (more now I think) eval board for a BG22 (BG22-EK4108A) and using their ide was able to easily do examples and create my own projects. Their cheap board has a segger debugger on board, and the ide has everything you need to program/debug, including a network viewer where you can monitor ble. It takes a little to figure out their 'code generator', but once you get a handle on that it is relatively easy (the harder part is simply dealing with ble, which is the same for any mcu). The advantage of this over nRF is everything is under 'one roof' (ide), although nRF users have free access to the Segger ide I think you will still end up dealing with separate parts (ide, nRF desktop app, download sdk and maybe toolchain on your own, etc.), but have not touched nRF for a couple years so may be different now.

Get some inexpensive eval/dev boards for various mcu's that look interesting. Give them a test drive, and get first hand experience. Like all recommendation threads, there can be no substitute for first hand experience even if not extensive. About the only useful info these type of threads can produce is if most agree that something is either horrible or great. There is no one yet commenting on certification (or dealing with the bluetooth cartel), so maybe that info would be useful if someone had first hand experience.

It looks like the advantage you have now is you already have something that works, so can make good comparisons with a real app (not example apps). plus maybe not under pressure to get something else working quickly so can evaluate at a slower pace. It may turn out that your current mcu+ble module is a better solution, although I would suspect cost is the driving factor here.

[artag]

With regards to the Nordic SDK, is that the old one (which I found fairly easy to use, though I didn't like having my code buried 15 levels deep in the directory tree) or the new one, which is platformio and VS Code, and therefore a horror ?

[JPortici]

It's not really cost but the desire to move from the current, very limited solution to a more flexible one, and of course to drive costs down why not look at an integrated solution? Full disclosure: we recently found a supplier for cheap ble remotes, which expose the programming port. We were looking for something like this for a while (for another project) and as luck would have it these remotes use the older nRF521, so i started looking at nordic more closely because i will have to get comfortable with them anyway.

In any case, i program bare metal so i want an ide with an header file that has the register definitions, no platformio bullshit, and the BLE stack.

[eleguy]

We have used different models of ESP32s and nRF52s. I think in our case the answer is pretty simple. If one has to do somewhat light battery product then nRF52 is the answer. We have not used their own development environment but instead done things more hard way and used Zephyr as RTOS.  With the zephyr one can manage low one digit uA levels some what "out of the box". WARNING... learning curve can be visualized as a right angle and  .

In general ESP32 beats nRF52 in the most of the "common" specs like mem and speed. However, our favorite nRF52833 has up to 48 GPIOs depending on the package you select. Ok, I need to admit their aQFN73 chip is not the first chip you pick into your practice project. I would recommend starting with the QFN40 model instead and try if a nRF52 fits into your mindset or not.

My first nRF52833 based sensor project did look something like this at the time. Done with kicad and freecad.

[Siwastaja]

With regards to the Nordic SDK, is that the old one (which I found fairly easy to use, though I didn't like having my code buried 15 levels deep in the directory tree) or the new one, which is platformio and VS Code, and therefore a horror ?

I guess the "old one"; last time I discussed this the story was that the old one was bad and the new one is great, but you are saying the opposite? (This also demonstrates the problem of committing one's time in manufacturer's software solutions: they abandon this stuff faster than they change underwear, so that the support goes down the drain every few years.)

Could be any stupid mistake of mine why none of the examples worked out of box (including just working with wrong examples), but I don't know, with "hello world" example being a True Software Project consisting of 200 .c files with well over 100kLoC total and consuming the whole flash of the device, what are you expected to do when the logger library, which comes with 10000 lines of configuration of message colors, fails to log? Is one realistically supposed to try to start debugging this stuff? Examples should be "minimum working code", not some architectural masterpieces, but maybe I'm just old-fashioned.

I have written millions of lines of code, most of which is crap, in my life, and I have had zero problems whatsoever integrating stuff like mbedtls in my own codebase, but probably I'm not just competent enough to use Nordic Semi's SDK, you would need a True Software Engineer and not some self-proclaimed embedded greybeard. The point is: if I can't do it, I'm 100% confident many others, especially beginners, cannot either, regardless of fact that some people say they have succeeded.

But I still recommend their products because the hardware is easy to use. I have so far managed doing without BLE stack but I have this good feeling about it that I will find a working non-bloated BLE stack using Google which runs on nRF52 with no or minimum modifications, if and when that need arises. So far I have been working with own custom radio stack which, in some ways, is way superior to BLE LR simply because being custom, it is tailored for the use case without decades of compatibility requirements driving the design.

Seeing that nRF52 implements many of BLE stuff in hardware (well designed, with easy register interfaces!), I'm 99% positive fully working BLE stack should be < 10 .c files, < 2000 LoC, < 10KB of flash. I'm sure someone has done it, and if not, it is actually something I could consider doing if that's the only way.

[cv007]

With regards to the Nordic SDK, is that the old one

In my case, nRF5 SDK, which is the 'old' one. I'm quite sure if I tried nRF Connect, I would be lost and would then echo Siwastaja's comments. Anything with Zephr and I'm going to be lost, and if nRF Connect was the only option I'm quite sure I would have given up.

I have so far managed doing without BLE stack

So you are using the radio but not doing ble? The nRF SDK has various examples of non-ble radio usage, and is 10x easier than dealing with ble. That would be nice, but in many/most cases the cellphone is the the 'other end', so have to deal with ble however unpleasant. In my case, I just wanted an easy way to view data remotely and the cellphone is probably the simplest way to do this even though it means dealing with ble.

[Siwastaja]

I have so far managed doing without BLE stack

So you are using the radio but not doing ble? The nRF SDK has various examples of non-ble radio usage, and is 10x easier than dealing with ble. That would be nice, but in many/most cases the cellphone is the the 'other end', so have to deal with ble however unpleasant. In my case, I just wanted an easy way to view data remotely and the cellphone is probably the simplest way to do this even though it means dealing with ble.

The RADIO peripheral gives you all the low-level BLE long range greatness, offers CRC, address matching etc. in a very simple to use register access package, so all you need to do if you write your own protocol is some sort of interrupt-driven logic which tracks message timing so that it starts RX at correct time (just before expected TX), sets pointers to a packet, enables TX at correct time, maybe tags messages with sequence numbers and request for resends - much of this preferably using the RealTimeCounter peripheral independent of the CPU so that core can sleep. Preferably hop frequencies given some predetermined table. None of this is rocket science but of course it takes time to get right; I found it super helpful to use the GPIOTE to route RADIO EVENTS directly to GPIO transitions (independent of CPU), so that one can see on oscillosscope/logic analyzer when the participants start or stop listening, start transmitting, receive address or packet ends.

As a plus side, you can get better protocol than BLE which is a compromise defined by being somewhat suitable for all workloads. My current implementation is 1200 LoC for master, 800 LoC for slave and includes low-power sleep modes, wakeup-by-radio stuff, running mode, frequency hopping, multi-slave time slicing, timing correction packets, resends, run-time adjustable timing parameters, message FIFOs. Of course, there is not going to be any interoperability with anything else than your own code, which is, depending on case, either a plus or a total showstopper. If you have to interface with Zigbee products, then you can't avoid Zigbee, and if you want to interface with mobile phones, you can't avoid BLE. And using nRF's softdevices, you can't have them both since they are so bloated they won't fit. And actually you can't have BLE either because it's still so bloated you are left with some tens of KB for your whole app, which is just ridiculous. Don't know about the new Zephyr route but probably it's as bloated.

[janoc]

With regards to the Nordic SDK, is that the old one (which I found fairly easy to use, though I didn't like having my code buried 15 levels deep in the directory tree) or the new one, which is platformio and VS Code, and therefore a horror ?

Don't use either, just use Zephyr (which Nordic has replaced their old SDK with, AFAIK) and be done with it. Zephyr has great support for Nordic parts and as long as you don't need some proprietary protocols like ANT or Zigbee (which the Nordic chips also support) you will be fine.

Platformio/VS Code you don't have to use. They only make getting started and debugging easier because setting up something like Zephyr from scratch is both a significant learning curve and takes some time - it is a complex system!

The old SDK was "easy to use" - but also an enormous PITA if anything went wrong and the softdevice (basically a proprietary RTOS blob encapsulating their RF black magic) started to throw errors (and crashes!) at you. Debugging that is "fun". With Zephyr/new SDK based on it you get all the source so if the BLE stack is e.g. refusing authentication for some reason you can figure out why. Also using something like BLE Mesh (not regular BLE!) with the old softdevice based SDK and Zephyr - give me Zephyr any day, despite the extra complexity with having to manage device trees and what not. The API is much saner - which matters when it comes to implementing complex protocols like this.

[Siwastaja]

the softdevice (basically a proprietary RTOS blob encapsulating their RF black magic)

I did hear these magic words a lot and I simply hate it; there is absolutely nothing RF nor nothing magic in softdevices. All the "RF black magic" is implemented on-chip, as hardware, and nRF guys have clearly done great job at it. All the software has to do is basic MCU firmware stuff like write "send packet" commands on bog standard interrupt handlers, manage device addresses, keys, states. Just like a networking library would manage TCP/IP headers, or a USB implementation would look at interrupt flags and manage data flow between the peripheral and application.

And I'm pretty sure softdevices do not use any kind of RTOS, just normal interrupt driven code, they even list the timers and other peripherals they use so that you can avoid using them in your own code. But of course I could be wrong. In any case, to me these softdevices look like much larger than I would expect them to be, and total lack of simple examples of how to use them is devastating.

[janoc]

And using nRF's softdevices, you can't have them both since they are so bloated they won't fit.

They probably would fit in the larger parts but you can't have multiple of them because they are an RTOS + protocol stack using the same hardware peripherals, so they would conflict. They are not designed to be interoperable and allow to use multiple protocols on the air at the same time.

And actually you can't have BLE either because it's still so bloated you are left with some tens of KB for your whole app, which is just ridiculous. 

Which is often plenty and all that you need. If you are using the low end parts with little flash you are likely implementing some low power sensor or a little gizmo controlled by a phone (e.g. "smart lightbulb"), so there isn't going to be a lot of sophistication in there. If you need more, you use nrf52832 or nrf52840 instead which have 0.5-1MB of flash, USB, NFC support and what not.

Don't know about the new Zephyr route but probably it's as bloated.

It is +/- the same. However, that's the "tax" of using these complex protocols like Zigbee or BLE. If all you need is exchanging a bunch of packets and don't need any interoperability, just use Shockburst and be done with it, no need to implement the protocols from scratch by driving the radio directly. Then you don't need any softdevices either. And you will still be able to talk to the old school nrf24L01+ devices which use it ...

[janoc]

the softdevice (basically a proprietary RTOS blob encapsulating their RF black magic)

I did hear these magic words a lot and I simply hate it; there is absolutely nothing RF nor nothing magic in softdevices.

The "RF black magic" is meant to be the protocol stack. If you fancy to implement something like BLE/Zigbee or ANT+ protocol stack, be my guest. However, most people aren't masochists enough to do so and/or have better things to do with their time.

Moreover, these stacks are proprietary, which is why Nordic ships them as binary "softdevice" blobs. There is an open source BLE stack in Zephyr not requiring the softdevice but there isn't (AFAIK) a Zigbee one or ANT+ one.

And I'm pretty sure softdevices do not use any kind of RTOS, just normal interrupt driven code, they even list the timers and other peripherals they use so that you can avoid using them in your own code. But of course I could be wrong.

Of course they list the used interrupts and times, any RTOS would need that too. Implementing something as complex as BLE without an RTOS would require a very special kind of crazy, IMO.

In any case, to me these softdevices look like much larger than I would expect them to be, and total lack of simple examples of how to use them is devastating.

That's because they are not meant to be used for "simple" use cases. The softdevices implement the complex protocol stacks like BLE or Zigbee, there is no way to make those "simple" or "not bloated". If all you need is to flick a few packets through the air, use Enhanced Shockburst and be done with it. For that you don't even need any softdevice.

[Siwastaja]

It seems you arrived at circular proof that because nRF folks ended up with 150-200KB+ implementations of said protocols, these protocols must be this complex. I choose to disagree. For example, I think Zigbee stack has been implemented on some PIC microcontrollers, and it's nearly two decade old stuff.

I have good reasons to believe the bloatness goes into these proprietary, closed binary blobs, from what I have seen from the code they have published, for example just simple "print text to UART" implementation being thousands of LoC.

But as they are closed and as I have no interest of disassembling and reverse-engineering them, I have no hard evidence, no interest in obtaining it, and could well be wrong.

edit: for example, Apache NimBLE seems much smaller already (http://events17.linuxfoundation.org/sites/events/files/slides/Mynewt%20BLE%20-%20ApacheIoT.pdf page 16). I don't know what would be the difference between "base" and "complete" versions but assuming base would suffice, host+controller would be just 48KB, equivalent SoftDevice is over 200KB IIRC.

Enhanced Shockburst is way too simplistic and lacks basic features for robust communication over license free bands, e.g. frequency hopping, but I kind of liked it as it was one of the only sane examples they offered. That was my starting point. When I added frequency hopping over what was basically a copy of "ESB", the improvement in radio range (between my living floor and concrete basement) was just massive.

And I don't think that one can fundamentally choose that BLE and Zigbee cannot coexist. Why are the products marketed as if they support all these protocols if you have to fix it design-time? You sure can talk both TCP and UDP through a single Ethernet PHY, and you sure can share radio time between BLE and Zigbee so it's an arbitrary limitation. Given shared resources, you could always time-division multiplex them. It's surely not easy to implement but seeing these "secret magic" implementations are so large one could maybe expect they also would deliver such special features.

In fact, the project I'm currently working on could have some customer demand for combined BLE and Zigbee and despite not high on priority list, I'm keeping my eyes on if it could be implemented with less than 100KB of flash, and single radio. You probably say it's impossible, but I have been doing these "impossible" (to some) things before. In the meantime, we are going with my own "masochistic" protocol which works great and is just a few K, with the obvious limitation of no interoperability but no one has asked for it - yet.

[cv007]

The RADIO peripheral gives you all the low-level BLE long range greatness

I realize that, but my question was whether you use ble or not. I take it the answer is no. For anyone wanting to use ble with these mcu's, as the original post indicates, the reason is most likely that there is a requirement to communicate with a cellphone. The self-designed rf protocol is useless if that is the case.

[janoc]

It seems you arrived at circular proof that because nRF folks ended up with 150-200KB+ implementations of said protocols, these protocols must be this complex. I choose to disagree. For example, I think Zigbee stack has been implemented on some PIC microcontrollers, and it's nearly two decade old stuff.

I invite you to read the specification of BLE, try to implement it and then you would have a leg to stand on to complain about bloat. Until then you are only ranting about stuff based on guesses and (wrong) impressions. The "Core Specification" for Bluetooth has "only" 3000+ pages and that's without the specs for all the extra profiles, etc. - that's thousands of pages extra.

The low energy controller part relevant for implementing BLE is 440 pages by itself. On top of that you have all the various services, profiles, etc. that you will need for a practical application, such as GATT, HID over GATT, the mandatory crypto, bonding, etc.

Good luck.

I don't have any illusions about code quality in any proprietary blobs but the "bloat" you are ignorantly ranting about is the direct consequence of how voluminous and "everything but the kitchen sink" design Bluetooth is. BLE is a bit better than the "Classic" Bluetooth in this regard but it is certainly not a "lean" protocol by any measure.

And I don't think that one can fundamentally choose that BLE and Zigbee cannot coexist.

Nobody said they can't. Don't put words in my mouth. I have said the softdevices can't do that because they weren't designed for it and they use the same hardware, so if you try to load them at once they will conflict. That's all. Feel free to implement your own multiprotocol stack. The Bluetooth specs even have a part dedicated to coexistence with other protocols.

In fact, the project I'm currently working on could have some customer demand for combined BLE and Zigbee and despite not high on priority list, I'm keeping my eyes on if it could be implemented with less than 100KB of flash, and single radio. You probably say it's impossible, but I have been doing these "impossible" (to some) things before. In the meantime, we are going with my own "masochistic" protocol which works great and is just a few K, with the obvious limitation of no interoperability but no one has asked for it - yet.

Don't forget that there is a huge difference between a hacked up "lite" implementation of the stack that does only what you need for your application - and a complete, qualified stack that has to handle even things you don't use and didn't implement. But someone else does and does require that certification because they want to put the official Bluetooth logo on their gadget and don't want to get sued by the Bluetooth SIG over it.

However, again, you are very welcome to implement a dual protocol stack in 100kB of flash, I am sure there would be a lot of people even willing to buy it if you did. There isn't anything similar on the market, AFAIK.

[nctnico]

Don't forget that there is a huge difference between a hacked up "lite" implementation of the stack that does only what you need for your application - and a complete, certified stack that has to handle even things you don't use and didn't implement. But someone else does and does require that certification e.g. because they want to put the official Bluetooth logo on their gadget.

Agreed. It makes no sense to try and implement a BLE stack from scratch. The ones you get with the various RF chips are certified and likely have many tweaks & hacks to cover the blank areas in the specification to ensure real world interoperability.

A long time ago I wrote an ISDN protocol stack from scratch because these where not available to mere mortals. I tested it against the test vectors as used for certification. But when I started to deploy the ISDN stack for real, it turned out various (telephony) switches had their own idea of how the protocol would work in certain situation so I ended up with having to support quite a few ISDN flavours as well. Moral of the story: creating a robust and versatile protocol stack for a complex protocol is not easy and not a small job.

[Siwastaja]

Talk is cheap, but answer this simple question:

If there exists two different solutions (nRF52 deprecated softdevice, and Apache NimBLE), both implementing the same specification, one of which is 4 times the size of other, to the point that it just barely fits the device it's intended to run on, why I am not allowed to express my opinion that the larger one is probably bloated, without being questioned whether I could implement yet another version of said protocol? Film critics need to make better movies themselves? If your answer is that one of the stacks has more features (which can't be stripped down for user needs), then congratulations, we agree: that's exactly the definition of bloat.

Also, if ability of implementing this full stack from scratch is prerequisite for discussing it, have you done it? If not, shut the fuck up.

Or, actually, don't bother replying. You are obviously just confrontational for no reason. Ignored from now on.

[nctnico]

From what I've seen quite a few RF chip vendors have (more or less) dropped their own Bluetooth implementation in favour of Nimble nowadays.

[SiliconWizard]

You mean that? https://mynewt.apache.org/

[tszaboo]

However, again, you are very welcome to implement a dual protocol stack in 100kB of flash, I am sure there would be a lot of people even willing to buy it if you did. There isn't anything similar on the market, AFAIK.

Silicon Labs has multiprotocol stack. I'm not trying to convince you all BTW, just different perspective.

[robca]

From what I've seen quite a few RF chip vendors have (more or less) dropped their own Bluetooth implementation in favour of Nimble nowadays.

I have been writing firmware for commercial IoT products based on nRF52 (832 and 840), using the "old" nRF5 SDK (still fully supported). The initial earning curve was relatively painless: good toolchain (based on Segger, free license for Nordic users), great examples with "ready to ship" code, great Nordic support and community. I never disclosed the company I was working for, so I got the same support that Nordic would provide a hobbyist, and that was well above my expectations. Plenty of tutorials to get started on the toolchain and libraries. IF you need to build, e.g. a cycling speed and cadence monitor, you simply take the Nordic sample, change the name to reflect your name, and you can ship that one as is. Want OTA update? add the Secure DFU example, compile the secure bootloader, and you have a BLE S&C sensor with updateable firmware.

I came as an hobbyist from the STM32 world, where the ST HAL code is barely usable, with non-existent sample and ST support. I still love the STM32 for certain things, but the ST libraries are not one of those

Yes, the Softdevice is a proprietary blob, but well implemented, bug free (for all my purposes) and supports additional protocols like ANT+. There are various version, depending on the features needed with different memory footprints (also, different working RAM, depending on the functionality). More importantly, the Nordic libraries fully implement things like a secure wireless firmware update (over any of the supported protocols), with guaranteed recovery in case of problems. Good luck rebuilding all of that on top of a library like NimBLE. I mean, it can be done, but I'd rather spend my time on writing unique code for my scenarios. And even if we implement a half dozen of BLE profiles and are running BLE and ANT+ at the same time, sending data at 100Hz plus managing analog channels and IMU sensor fusion on the M4 (using ST's MotionFX), we never had any memory issue or slow execution.

Lastly, thanks to Segger's MMD (Monitor Mode Debugging), you can fully debug your code while maintaining the BLE (or ANT+) connection alive. MMD works with the Softdevice to allocate enough cycles to the radio code, while giving you full step-by-step control of your code (on a single core processor). Debugging BLE applications is much harder without something like MMD.

A radio stack by itself is rather useless if you need a full solution with multiple radio stacks. Try sending BLE and ANT+ data at the same time, like pretty much all sports enabled devices do these days, and doing it on a device with exceptional battery life like the nRF52.

There are stupid parts to the Nordic SDK (like the sdk_config.h file, which is a hot mess, but something you deal with only once then copy over and over), and things that are questionable choices, but minor quibbles for the most part.

And, no, I don't own Nordic stock just a happy user sharing my experience developing for commercial products.

P.S. ANT+ is Garmin proprietary and only available as binary implementation. Nordic is, as far as I know, the only implementation that works with BLE on the same radio

[Siwastaja]

I guess the design choice of a "complete finished but modifiable megaproject" is either a total hit or a total miss. If you can take an example project and it's close to your final application, and you have no design constraints (i.e., can define your project as you go), then you can pretty much ship the example or modify it a bit. If the example compiles and runs, you can get your IoT thing finished in a week. Especially if your own part is trivially simple (in which case it would fit in the remaining 50K of flash, too).

Things totally change if your project has its own goals - functionality, architecture, even coding style -, or even worse, existing implementation. In other words; your project is complex, and radio is just small part of it. For example, I might already have a working secure firmware update tooling, with all server infrastructure, in place. Then I just want a radio communication layer, nothing more. If I have a 100kLoC project and I want to add radio functionality to it, then I want a radio-only library and clear documentation thereof, where "getting started" guide must look like "call this init function, call this send function, link with these linker settings". In such case, a 200LoC example, minimum viable code which demonstrates BLE only, and not logging in multiple colors, is much more valuable than a 200-file, 100kLoC example which is a complete product.

Massive megaprojects are also problematic when something goes wrong. As I explained, I spent a week trying to get the examples working, and did not succeed, and I can find similar experiences from a simple Google search. Then again, for others, the examples seem to work out of box, so . Maybe it depends on which devboard you got, which SDK version you happened to download, or if you made some stupid mistake or wrong assumption early in the path - I probably did - that some others apparently do not make.

Nordic Semi's support has been excellent, probably the best in class, this I can agree with.

I would prefer to see "unix philosophy" more, that is, self-contained libraries with clear and documented interfaces, which you can use as building blocks. It seems the MCU world is going the opposite way, where you get a complete "ecosystem" or a project which you then modify. Learning how to integrate a library has a bit steeper learning curve than getting out-of-box ready project you just modify, but this learning curve is relatively constant over all types of projects, simple and complex.

[robca]

Especially if your own part is trivially simple (in which case it would fit in the remaining 50K of flash, too).

The nRF52832 has 512kB flash, the nRF52840 1M. The Softdevice is 100kb for the basic BLE peripheral, ~120kB for full BLE (more for bigger versions, but not much). Nordic offers a family of device all code compatible with no changes, so not sure why flash size is such a big deal in this discussion. We use complex algorithms (including third party code like MotionFX) and multiple services, plus local data processing and a variety of peripherals. We have flash to spare even on a nRF52832 with the BLE/ANT+ combined Softdevice. And I have a hard time imagining what kind of application would you have to write to eat all that flash, and still decide to run it on a single core M4. There are plenty of startwatches with complex UI and apps using those chips

I'm not sure how you'd only have 50kB flash to play with, unless you chose the wrong chip for your application. Even the smallest device with 192kB flash and the basic BLE stack would have more than 85kB to play with, but it's easy to move to a chip with more flash. Is NimBLE+RTOS (the Softdevice is both) really that much smaller than 100kB when compiled for a nRF52? I can't find any example or information on that. Do you have an .hex file compiled for a nRF52 to see the size? did you manage to build a sample app using NimBLE and, if so, what was the total size?

The Softdevice doesn't force you into a specific coding style, while I agree that if you cut&paste examples, you would inherit that coding style. But with NimBLE you also have to use their environment for lot of things, unless you port everything to your environment and manage updates.

Our code didn't start from examples, btw, but over time we pulled in bits and pieces from the examples, adapting to our needs. Having a working example that implements exactly what you need and is "ready to ship" saves countless hours of development. Even just by being able to look at how something works on the SDK board and debugging that. And, for what is worth, our firmware is modular: the same core functionality is used for common things (like secure OTA firmware update, battery, configuration services, etc) but it is customized to ship dozens of different devices with different functionality.

I love the "unix" mindset when I'm working with powerful PCs and servers. For embedded devices, every time I find a working implementation from the manufacturer with good examples and good support, I'll gladly take it. Strict HW integration, timing and especially battery life make developing generic libraries that work on multiple incompatible HW very, very hard. We focused on memory, but if for example the NimBLE library used 10% extra battery life in a specific scenario, I'd rather trade off memory for better battery life. The Nordic stacks have all been optimized for incredibly good battery life and work with the rest of the chip to save battery everywhere. And NimBLe only supports Nordic and one Renesas chip, so not exactly generic.

Nordic has a really good track record and their BLE and ANT+ stacks are industry standard by now, probably one of the most common BLE stacks you are likely to encounter in the wild. For an OEM focused on shipping hardware, the bootstrap time is short and the results predictable. iOS and Android phones have also been fully tested against those devices, unlike something like NimBLE. That alone is worth peace of mind for me.

But I agree that it comes down to philosophy and preferences, I'm just sharing my experience with becoming productive in a much shorter time than I thought possible (and I'm not really a good programmer at all)

[Siwastaja]

The nRF52832 has 512kB flash, the nRF52840 1M. The Softdevice is 100kb for the basic BLE peripheral, ~120kB for full BLE (more for bigger versions, but not much).

512KB/2 - 120 = 136KB remaining for the app, which is quite acceptable actually. I was looking at some other softdevice which was around 200K, don't remember which, and don't know why I looked at it instead of the "basic" version, if the basic suffices.

so not sure why flash size is such a big deal in this discussion.

Would you guess why? Some of us do this for a living, and if something does not work and cannot be fixed, then it's a no go. No hard feelings - but it has to be ditched. I'm merely stating the fact it is too big to the constraints I'm working with - you may disagree, with different constraints, but you are the only one who's making it a "big deal".

We use complex algorithms (including third party code like MotionFX) and multiple services, plus local data processing and a variety of peripherals. We have flash to spare even on a nRF52832 with the BLE/ANT+ combined Softdevice. And I have a hard time imagining what kind of application would you have to write to eat all that flash, and still decide to run it on a single core M4.

Nice to hear that your project fits. Ours does not. It uses flash for configuration settings, duplicated copies of which exist for graceful fallback to old settings, it has mbedtls and Paho libraries, and a lot of other stuff, and every piece of application code (except very tiny and simple bootloader) - including TLS and radio stack - is over-the-air upgradeable, so must exist twice in the flash, as brickage cannot be accepted in case of power loss during update. This is why there is ~60K left for radio stack. This is why we don't invest any time in trying to learn how to use Nordic's softdevice - it does not fit. Custom stack fits excellently so we are doing it that way. NimBLE is considered if business case exploration reveals demand for mobile phone interoperability - no one has asked for it yet. On paper, NimBLE fits. Does it really fit - I have no idea. Nordic SoftDevice does not fit even on paper, so would be wasted time to explore.

I'm not sure how you'd only have 50kB flash to play with, unless you chose the wrong chip for your application.

Yeah, good old "let's blame the user for not buying excessive hardware" excuse for bloat. I merely pointed out this obsolete implementation is many times bigger than what some others claim to be, and why I think it is a problem. Your mileage may vary, and I'm glad it doesn't matter in your project.

Even the smallest device with 192kB flash and the basic BLE stack would have more than 85kB to play with,

Nope, 192/2 - 100 = -4KB, does not fit at all. But then again, I choose to not build non-upgradeable mass market devices which we need to then recall when a serious security bug appears instead of just OTA upgrading it. Your mileage may vary, and I'm well aware that in IoT business, safety practices are all over the place.

Is NimBLE+RTOS (the Softdevice is both) really that much smaller than 100kB when compiled for a nRF52?

I don't know. I quoted numbers I found from a presentation. Because NimBLE claims to be tailored for nRF52, I'm assuming these size numbers are also real for nRF52. I have not tried it. I also don't need an RTOS (NimBLE comes with something they call RTOS, and I have no problem with it, as long I don't need to touch it besides the bare minimum). I also have absolutely no idea if NimBLE is any good or not. If someone has more in-depth experience, I'm willing to hear.

[robca]

so must exist twice in the flash, as brickage cannot be accepted in case of power loss during update.

No, that's really not the case. I mean, yes, one could have a monolithic app+communication stack and have to use twice as much flash. But Nordic, which does this as their core business, realized a long time ago that the ideal solution is a secure bootloader (~2k including crypto libraries), a small communication stack (Softdevice ~100k) and the user application. The OTA DFU supports a fully buffered approach where it requires twice the memory, and in case of problems reverts back to the full functionality. But it also supports a memory-efficient model where each of the 3 components is updated and verified independently (or even just one of the 3, usually the user app), and in case of problems stays in bootloader OTA DFU mode, never losing functionality. I mentioned it in a previous post that the Nordic DFU guarantees a no-bricking situation. And it's secure end to end, with full validation before, during and after.

The only time when some memory needs to be doubled, is the Softdevice update, which is a rare occurrence. But in that case it can be done while the user app is not in flash, so it's never a limitation.

As a matter of fact, using the Nordic Softdevice, I can update a much bigger user app than I could with a monolithic app that includes the communication stack, even if the other communication stack were, say, half as big. I could have a 350k user app in a 512k device, with some flash left for storage (which is also handled properly during DFU). And, yes, one could also write the other solution to separate the communication stack and develop a secure bootloader, plus all the mechanism to handle every possible scenario. It's just a lot of work with a lot of pitfalls I'd rather not have to deal with for no other reason that a trivial memory footprint save (at the cost of using a library that could use more power, have unknown bugs, not officially supported with guaranteed responses for commercial development)

I have to say that this conversation is becoming frustrating: you are arguing about non-existing problems with a platform you are not familiar with, while suggesting as a better alternative a library you haven't tested... All along implying that I don't understand the platform I, my colleagues and thousands of companies have been using for 3+ years and that has been shipped in more than a billion devices.

To be clear: I'm not dissing NimBLE or the other approaches. To each their own, and there are cases where owning the communication stack is beneficial. But there's a reason why, for certain low power BLE scenarios, Nordic is a de-facto default choice.

[Siwastaja]

So you are just confirming exactly what I said, with some marketing weasel words poured in, but coming into conclusion that you trust the softdevice update is "rare" enough you can ignore the update concerns of it. I choose to disagree, I am not putting a 180KB binary blob (I looked into both peripheral + central which is why my numbers were higher) which cannot be updated OTA, and reach the same conclusion as Nordic Semi themselves: not use the softdevice.

No matter how much you add, simple logical truth does not change: in flash-based technology, where erase is slow, for each piece of code that needs to be updated, same amount of extra flash is needed to store a copy. This is a well-known truth and you can try to twist around this reality but it starts looking like you were rationalizing flat Earth trying to make it look more plausible than it is. In other words, the only way to break free from this flash size doubling, is to choose that significant part of the code cannot be safely updated. It looks like you are not eager to admit this and try to hide this non-upgradeability behind pretty marketing words. I don't like it. Just admit it can't be upgraded and you trust it's bug-free; it's a valid and often used approach, just one I choose not to do.

The reason I want to be able to update the whole stack is long enough experience that shows that doing otherwise is risky. Risk is awkwardly small; it's a classic small-risk-high-consequence situation, which is why it's hard to see to some, especially management. Simply put, I put no value to marketing bullshit bingo saying "this is their core business, trust them, they realized long time ago this is ideal...", especially when they, for some weird undisclosed reason, discontinued that very practice!

I want to give 10-year guarantee to customers though and that includes future maintainability of the project. I don't like throw-away IoT products. They need to keep working. They need to expand into new radio stack versions, and security fixes need to be applied. And unlike expensive special gear where we could fly to the customer and update it through JTAG, IoT stuff must be OTA updateable, and cost must be minimized. And if we are projecting truly high sales numbers, then NRE costs can be allowed to be higher, including good optimization of flash size.

Sad to hear you find this frustrating. You are free to go. You are the one who is questioning my points and getting agitated. Problems I mention are definitely not non-existing, even if they do not affect your design because you have chosen different design constraints and goals. For me, both difficulty in getting started with the SDK, and large size of softdevices were real showstoppers; take this with a grain of salt and feel free to express your disagreement. Your experience can be different but does not negate mine; there is no singular truth in complex engineering matters. We can choose to disagree and that's fine to me, even if it's not fine to you.

[robca]

So you are just confirming exactly what I said, with some marketing weasel words poured in, but coming into conclusion that you trust the softdevice update is "rare" enough you can ignore the update concerns of it. I choose to disagree, I am not putting a 180KB binary blob (I looked into both peripheral + central which is why my numbers were higher) which cannot be updated OTA, and reach the same conclusion as Nordic Semi themselves: not use the softdevice.

You are wrong. As I said, each of the 3 components can be updated independently or all at once (in any combination). In all cases, the OTA DFU ensures you can recover from a problem and never brick the device. And never require twice the flash of the full firmware. The Softdevice can be easily updated OTA, we have done a few times (but it's so stable now that it's rarely required, that was my point).

Considering that you keep being wrong on the supposed problems of the Nordic solution, the rest of your arguments are rather pointless.

[nali]

You are wrong. As I said, each of the 3 components can be updated independently or all at once (in any combination). In all cases, the OTA DFU ensures you can recover from a problem and never brick the device. And never require twice the flash of the full firmware. The Softdevice can be easily updated OTA, we have done a few times (but it's so stable now that it's rarely required, that was my point).

That's not quite true, this shows valid combinations of updates


The DFU is only validated if there is enough room in flash to buffer the update before writing to flash which Nordic call Dual Bank update, so that's basically the same as Siwastaja is saying. If there isn't room then it will do a single bank DFU, if that fails the device remains in DFU mode until it receives a successful update.

[Siwastaja]

That table is clear as day. You update the softdevice with the same major version of the same softdevice, since the softdevice isn't double buffered and has to modify itself. It's unknown how much complexity this update feature adds to the softdevice itself, but probably some. Many prefer simple solutions with minimized risk and no vendor lock in, and this is polar opposite to it. Which is probably why people didn't like it and it got discontinued.

(See also https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v15.2.0%2Flib_bootloader_dfu_banks.html )

And that "DFU mode" "receiving" a "secure" update must mean it has safe and secure BLE implementation and crypto (i.e., the softdevice), you can't erase that. No amount of data shuffling fixes it; if you try to swap the softdevice as a separate step, then you need enough buffer space to store a copy of it, and this space cannot be used for app. No matter how you shuffle data and numbers around, it always end up with the same result: if you want to update everything, you will need double the space. Creative use of compression and self-expanding code could actually mitigate, but it's unclear by how much, and by what cost.

This is as simple as verifying claims of overunity. No amount of mental acrobatics change the simple physics, or in this case, elementary school math and logic. It is easy to make outragerous claims if you don't exactly know what you are talking about and define things loosely, in marketing speak, this is exactly what we are evidencing here when this marketing shill popped out of nowhere to pick a totally unnecessary fight.

His confusion probably stems from the fact that all that complexity is hidden from him so he doesn't know what's actually happening under the hood; he, just like janoc, assumes there is black magic going on. In reality, there is no magic, just science and engineering, and the "single bank" update mode has risk of application loss, but in a typical battery-powered design with a fixed, non-user-replaceable li-ion cell and no physical power switch, risk of power outage during update is small, so one can "play around" as if the problem I described didn't exist. And then the constraints change, devices are manufactured in tens of thousands and they are not battery but mains powered, and you want to change to a different radio stack. What now?

Personally, I have used non-dual-banked flash updates in many projects, and always use RAM as the buffer and verify CRC before erase-write cycle. But it still has a section of death which lasts for a few seconds. This is then an accepted and documented tradeoff.

This is all basics to embedded engineers who can write code and build their own tooling, but probably black magic to those who modify examples. I'm not claiming either is superior way of working, just different. It is just that experience shows that the more you trust in the complex and unique software solutions offered by chip manufacturers, the more risk there is; and if you believe it's magic, the risk shoots through roof. There probably is reason why 99% of the Kickstarter IoT startups fail to deliver. Prototyping is quick, even using an Arduino; reliable product which can be manufactured and maintained totally different.

[Siwastaja]

This is how softdevice update actually happens:

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v15.2.0%2Flib_bootloader_dfu_banks.html

tldr: old application is erased, also old softdevice is erased, all you have left is the new softdevice + the new DFU. It has to work, there is no fallback.

Even if you trust it's free of bugs and nothing can go wrong, the point is totally moot if your update path is not BLE + customer having a bluetooth device with update app installed. For example, I do secure firmware update through MQTT/TLS/TCP/Ethernet in a product, so erasing the app and using Nordic's BLE DFU is out of question, it won't do it. We have these IoT devices which need to upgrade on their own, customer might be 1000 kilometers from home.

There is no replacement for understanding what's happening under the hood. Robca, if you are still young, drop the arrogance and continue learning - and don't forget to question yourself. Arrogance is sure way to destruction. I know that because I have had those moments too.

[nctnico]

To me this looks like a consequence of having too little flash to work with for the software provided by Nordic. So either roll your own software or use a device with more flash (if available). Assuming the 'Nordic software' supports using mirrored data where you have (at least) one working image while writing the update. A different example: Espressif's S32-S3 together several MB of flash has the ability to store 3 firmware images and one never gets erased as this is the 'factory' image. So even if you have 2 messed up OTA images (for whatever reason), the device still has a working firmware. I agree that microcontroller manufacturer provided software typically isn't the best but after having spend a while with Espresssif's IDF I must say I'm quite satisfied with what is there out of the box (including encrypted firmware images). The most interesting part is that Espressif doesn't really impose a particular update method / protocol. The actual transfer of the image is left to the implementer so you can transfer the file any way (serial, BLE, Wifi, network, etc, etc) you want for as long as it ends up in the right flash section. In other words, if ultra low power isn't an issue but being able to do OTA is important, then the Espressif S32-S3 series is definitely worth a look.

[robca]

Without refuting every single misleading statement, let me at least correct the biggest misconceptions:

You can update the softdevice to any version (even different major versions) as long as you also have the right bootloader for that new softdevice. If you want to update only the softdevice (i.e. no bootloader update), it can only be the same major version (table provided by @nali says as much, but it can be red wrong and mistakenly assume only same major version can be installed). The toolchain manages everything for you, and you do not need to do anything manually.

If you don't have enough flash to update everything at once, but still want to update everything, the DFU deletes the old app, uploads a new copy of the softdevice (and bootloader, if needed), verifies that everything is working, then deletes the old softdevice. There's no condition where you are left with a non-working configuration and no way to recover. Then , once bootloader+softdevice is validated, the app is loaded (new or old). It's the most efficient use of flash possible while still having a safe fallback.

The whole process is secured by crypto-signed binaries (can choose the crypto libraries)

The Nordic ship only supports BLE, ANT+ and a few other protocols. No Wifi, no ethernet. Every protocol and transport supported can be used for DFU updates, including ANT+. Of course you can't update over a non-existent interface... We are not discussing a general approach for every conceivable platform, just what the OP asked for: BLE SOCs.

1MB is more then enough flash for everything that can conceivably run on a M4 at 64MHz and Nordic has provided tools to address any common developer and user scenario. Everything discussed here works just fine, misconceptions aside. Not saying it's a perfect device, and clearly there are devices with more flash (even external flash). But none works from a CR3032 for a long time, as far as I know. If I needed WiFi or more processing power, the ESP32 would be a strong contender.

Everything is a compromise. If you are designing a BLE or ANT+ device, though, you'd be hard pressed to find a better platform today than the Nordic one. I have no connections to Nordic, just a happy user, and sharing my experience on the OP question.

[Siwastaja]

robca, all that is based on assumption that customer is running the update through BLE using their mobile phone and installing an updater app. This is not possible in many IoT products! IoT products, by definition, are connected to the Internet, and BLE is not Internet.

In fact I did not even think about it since none of the few projects I have using these parts for could do that. If I had thought about it, I would have understood your point better from the start.

The most interesting part is that Espressif doesn't really impose a particular update method / protocol. The actual transfer of the image is left to the implementer so you can transfer the file any way (serial, BLE, Wifi, network, etc, etc)

I think this is pretty usual. Almost always you want to come up with your own update infrastructure and cannot just use manufacturer's preferred interface. Having modular design with clear interfaces would allow you to use some of the manufacturer supplied software components for any communication layer. As manufacturer solutions often do not allow that, it leads to writing everything from scratch, which I'm fine with, except that some complex enough stuff like TLS, BLE stack or filesystems I don't want to write; therefore I want them as easy-to-use libraries.

And now I can correct what I said earlier by adding a conditional: the size of softdevice doubles in flash if the update path is not Nordic's BLE updater app, which for many purposes, including all those use cases of mine, is always the case, but I kinda understand how robca was not met with this limitation as he modified the examples and could update through BLE.

Everything is a compromise.

Oh, you are starting to get it! Nice to hear that.

[robca]

robca, all that is based on assumption that customer is running the update through BLE using their mobile phone and installing an updater app. This is not possible in many IoT products! IoT products, by definition, are connected to the Internet, and BLE is not Internet.

In fact I did not even think about it since none of the few projects I have using these parts for could do that. If I had thought about it, I would have understood your point better from the start.

Look, I kept answering the original question in this thread: BLE SOC. By definition, you update a BLE device via BLE. There's no reason to have a BLE device if you don't also have a smartphone or other BLE control point  . Nordic provides a standalone DFU app, or the manufacturer can incorporate Nordic code in their smartphone app to provide seamless DFU. That's how BLE devices work and it's an optimal end user experience (custom app with automatic updates). Nordic provides the same if you only ship an ANT+ device, commonly used in sports. The end user doesn't need more than that for these devices.

Along the way, someone complained that the Nordic solution didn't work by providing incorrect information due to being unfamiliar with the platform. Having used that platform extensively, I provided the correct technical information and how the platform addresses all the concerns raised (for those specific scenarios, not in general). The softdevice is extremely mature and, for all its downsides, nicely solves every conceivable scenario raised. Other options like NimBLE simply are not as mature to provide an end to end solution that covers as much. The developer using that must write a lot of code and solve a lot of problems that are already working in the softdevice/sdk.

I never disagreed that there are better ways for generic IoT devices to manage updates and the software stack, or the superiority of open vs closed implementations. But that has nothing to do with the topic here, and I'm not interested in that part. If a developer wants to develop a pure BLE or ANT+ device, they'd be hard pressed to find a better solution than the one Nordic offers and supports. There are better devices and frameworks for other scenarios. I really don't think there is much to argue with this position, but I'd be interested in some else's experience with BLE SOCs offering as much (just BLE, our customer base needs/wants nothing else).

[Siwastaja]

Look, I kept answering the original question in this thread: BLE SOC. By definition, you update a BLE device via BLE. There's no reason to have a BLE device if you don't also have a smartphone or other BLE control point  .

What!? No, of course not! You can't just arbitrarily come up with such limitations for others; for your own product, sure! Of course others can have a real need for BLE communication without BLE DFU path.

I already explained a use case, which is not synthetic at all, but what I'm actually currently working with: the devices are updated through ethernet port, automagically, without user intervention, because user might be on the other side of the planet. Users pay us a monthly fee exactly so that the things keeps running trouble free; we can't ask users to install updates. BLE would be used for example to communicate with external temperature, humidity etc. sensors, but also for user interaction when the user happens to be present, e.g. during initial configuration or looking at real time data, but that doesn't necessarily coincide with the need of update. Now if you stop to think about this use case, you also realize why I would need both BLE central and peripheral. Now combine all this information, and 2*180K for the softdevice becomes reality. Talk is cheap; show me a real way around it without changing the constraints I just explained. To me, NimBLE looks the best way forward - if it's any good and up to promises, that is.

And before you go, "oh, that's a very special case", I say no it isn't. What does the I in IoT stand for? I would assume the Internet is the primary DFU path in nearly all IoT devices. Of course, not every BLE device is IoT though.

Your posts demonstrate the problems of "full package" manufacturer solutions: they are completely inflexible, but they are also so complex that it is not instantly obvious what you can and cannot do. The deeper you dive, the more limitations, which cannot be circumvented, you find. If you promised an internet-connected device only to later find you can't update it through the internet, but only interactively by the user, it's going to take a full year of re-design, re-certification etc. to get the fixed device on market. The cost is easily a million in wages, lost revenue, etc. In my opinion, having looked at some startups, too much trust in "easy" manufacturer solutions and too little competent workforce of your own is one of the key reasons why so many of them fail to finally deliver (even with promising early prototypes), but I could be wrong and maybe these technological problems are always solvable. Then again, I do also see some that are very successful with the approach you describe. It completely depends on requirements.

I'm merely suggesting, be informed before you make the decision; assumptions in engineering are root of all evil. And being informed consists of reading and understanding both my and robca's viewpoints - those parts that have some actual content of their own, the part where he makes strawmen out of my arguments is unnecessary noise.

Now at this point I'm done with this troll and this discussion. I merely offered my professional opinions which I think I explained properly, but got in two unnecessary fights with two fanboys*, which hijacked the thread. Hope it was still helpful to others.

*) fanboyism is cancerous in engineering

[robca]

What!? No, of course not! You can't just arbitrarily come up with such limitations for others; for your own product, sure! Of course others can have a real need for BLE communication without BLE DFU path.

Have you looked at the thread title and the original question? I'm simply on topic, answering the original question on BLE SOCs, specifically Nordic SOCs when used for BLE.

You have been adding a lot of technically correct, but completely off topic information. My point is that I was focused on answering the original question, not having a discussion on anything else, no matter how much you tried to. When I developed internet-connected devices, I used different solutions and libraries. For BLE, Nordic. Horses for courses.

[nctnico]

What!? No, of course not! You can't just arbitrarily come up with such limitations for others; for your own product, sure! Of course others can have a real need for BLE communication without BLE DFU path.

Have you looked at the thread title and the original question? I'm simply on topic, answering the original question on BLE SOCs, specifically Nordic SOCs when used for BLE.

In all fairness, the OP didn't specify what other connectivity is involved in the project. What if the OP's project involves an internet connected device that is intended to read sensors over BLE?

[Siwastaja]

In all fairness, the OP didn't specify what other connectivity is involved in the project. What if the OP's project involves an internet connected device that is intended to read sensors over BLE?

The opening post is specifically mentioning it's an existing projects which increases chances of it already having an update path which needs to be maintained that way. Or then again, maybe not. The OP is probably vague on purpose to generate discussion instead of getting one exactly correct best reply, because free exploration of ideas is usually fruitful. Whether my or robca's advice happens to suit better to the OP is beyond anybody's guess; this is why both should be valued.

[DannyTheGhost]

I am currently working with nRF52840 developing Matter application, which is... HARD. Especially when it is first ever project using any RTOS anywhere.
Hardware-side - I have no issues, as I did not have any problem making input-synced PWM driver using Timer, GPIOTE and PPI peripherals with minimum CPU intervention (with only rechecking input pulse period value to disable output in case of some error).
It was quite the challenge to learn Zephyr RTOS, that is used in nRF Connect, but it is quite powerful tool with KConfig and DeviceTree bindings. I do not have anything bad to say about Zephyr, except it cannot be called 'light-weight' RTOS (22KB for kernel and UART driver and the 23KB for their "Hello world" example into serial interface).

But I do have some issues with Nordic libraries, and the current course of IoT development. You want to use their SoftDevice (it's a requirement for Matter protocol on nRF chip)? No traditional ARM debugging for you as it will throw error or some fault at you when you try to stop CPU to see some variables' values. You would also need to click on 10 consecutive links in their online documentation database just to find what peripherals are used by their SoftDevice (and looking through 300+ pages document about it).
Little bit of off-topic: all this stuff is really that bloated when they boast that they 'freed additional 30-40KB of Flash memory for Your application' , when basic Matter application with stack functionality and simple IO devices takes almost 800KB and no way to avoid using external flash for DFU. Although, I have to admit that bootloader with external flash works out of the box.

[cv007]

Bonus: How much of a pain would it be to certify the thing?

The question left unanswered.

Was the original mcu+ble module dealt with in any way, such as fcc/equivalent testing, Bluetooth SIG 'membership', etc. I assume this is a murky area when using an existing module, which at first glance one would think is all taken care of by the module creator- already has fcc/equivalent id, and would assume the module creator is the one that has to deal with the bt sig. Whether that answer in in your favor or not, I would assume you could potentially spend a lot of lawyer money if you become a target of the bt sig (they probably choose their targets wisely, but if they get slow with not much to do then maybe they search out smaller targets just for fun).

Is the module user basically in the same boat as the module creator- in both cases about the same $ involved (rf testing, bt sig fees), but the former has an easier time because of the previous 'testing'?

When for your own use, no one of course cares about this, but if you want to sell your widget the amount of $ involved eliminates the low quantity widget creator. I wonder how the esp/similar crowd handles this, and how does a 'dev board' fit into all of this (with or without loaded firmware).

Any 'been there, done that' members that can give the real world answer in this area?

[nctnico]

I need to go down the certification road as well. The test lab I contacted has asked for a certificate for an RF module but the design I made doesn't use a module but has the chip on a board I designed. I want to try to see if the test lab can be persuaded to treat the chip as a module because the reference module design (which is certified) is nothing more than the chip and an antenna. For sure the PCB design + decoupling is a factor but I kept that functionally equal as close as I could.

[SiliconWizard]

I need to go down the certification road as well. The test lab I contacted has asked for a certificate for an RF module but the design I made doesn't use a module but has the chip on a board I designed. I want to try to see if the test lab can be persuaded to treat the chip as a module because the reference module design (which is certified) is nothing more than the chip and an antenna. For sure the PCB design + decoupling is a factor but I kept that functionally equal as close as I could.

Yeah, no, that's not how it works unfortunately.

With that said, I'm assuming the certification involves RED? (If that's something else, then the requirements may be different.)
As I remember, the fact you would use a pre-certified RF module in a device would not per se make a bif difference in terms of certification, so I'm not sure I completely get the point of your test lab here (but I'm of course only judging from the minimal info you provided here.) What makes a big difference is whether you use a module that is not an essential part of the device, and can be installed or removed by the user. If it's a module that's permanently soldered to your device's PCB, for instance, as I remember, it makes only a minor difference in the certification process and the tests that have to be made.

[nctnico]

I need to go down the certification road as well. The test lab I contacted has asked for a certificate for an RF module but the design I made doesn't use a module but has the chip on a board I designed. I want to try to see if the test lab can be persuaded to treat the chip as a module because the reference module design (which is certified) is nothing more than the chip and an antenna. For sure the PCB design + decoupling is a factor but I kept that functionally equal as close as I could.

Yeah, no, that's not how it works unfortunately.

With that said, I'm assuming the certification involves RED? (If that's something else, then the requirements may be different.)
As I remember, the fact you would use a pre-certified RF module in a device would not per se make a bif difference in terms of certification, so I'm not sure I completely get the point of your test lab here (but I'm of course only judging from the minimal info you provided here.) What makes a big difference is whether you use a module that is not an essential part of the device, and can be installed or removed by the user. If it's a module that's permanently soldered to your device's PCB, for instance, as I remember, it makes only a minor difference in the certification process and the tests that have to be made.

To clarify: with a pre-certified module soldered to the board, the RED testing is limited compared to doing a full test (which is what I would expect) according to the quotation I got. Now the interesting question is: how far can you go by saying that a chip like the ESP32, which has everything inside where it comes to the radio part, can be considered a pre-certified module.

[JPortici]

Bonus: How much of a pain would it be to certify the thing?

The question left unanswered.

Was the original mcu+ble module dealt with in any way, such as fcc/equivalent testing, Bluetooth SIG 'membership', etc. I assume this is a murky area when using an existing module, which at first glance one would think is all taken care of by the module creator- already has fcc/equivalent id, and would assume the module creator is the one that has to deal with the bt sig. Whether that answer in in your favor or not, I would assume you could potentially spend a lot of lawyer money if you become a target of the bt sig (they probably choose their targets wisely, but if they get slow with not much to do then maybe they search out smaller targets just for fun).

Is the module user basically in the same boat as the module creator- in both cases about the same $ involved (rf testing, bt sig fees), but the former has an easier time because of the previous 'testing'?

When for your own use, no one of course cares about this, but if you want to sell your widget the amount of $ involved eliminates the low quantity widget creator. I wonder how the esp/similar crowd handles this, and how does a 'dev board' fit into all of this (with or without loaded firmware).

Any 'been there, done that' members that can give the real world answer in this area?

well, of course we don't use bluetooth's symbol anywhere in the advertisement / packaging (using a more generic "phone connectivity" instead, something like that), in the past regulatory ends were satisfied with the BLE Module's manufacturer's FCC/CE compliance paperwork, so i think we could get a "good enough" sticker by only certifying the hardware and using the vendor provided BLE stack which is already "certified"

and i obviously stand with nctnico in the idea that using a precertified "module" in a board makes it already certified for RED (or at least, that it's "good enough")

[Siwastaja]

The consultants we used expressed that nevertheless of using a "pre-certified" module, full compliance measurements for RED are needed, so we paid for them. (I don't know/remember if some other checks were skipped; we use consultants exactly because there are so many details to think about.) Quite obviously to me, the pre-certified Fanstell modules passed (the lab expressed their opinion that even with pre-certified modules, designed in according to appnotes, this isn't always obvious at all; they have seen them fail). The intentional radiator measurements (basically with test code just outputting packets at minimum and maximum frequency) were just a tiny part of the whole deal and ran in an hour or two. EMC, radiated and conducted, was a much bigger deal, and you have to do it anyway, so I think for us the total difference would have been like 8K vs. 10K€ or something like that.

As always, you want to prepare for the testing so that your custom firmware is as flexible as possible and you can turn on/off interfaces/features without having to modify your code and reflash in the lab. And you also want to minimize the self-test cycle time below 1 second so that excessive dwell time does not blow up the test schedule; lab time is expensive. We ran self-test of all interface subsystems repeatedly in 800ms, and used ASCII messages over MQTT which output current and cumulative error counts of all subsystems, and simple MQTT input messages to turn subsystems on/off - for example you want to turn radio TX off for radiated compliance, but keep it on for immunity and conducted tests; or turn stuff off to troubleshoot which part is causing emissions and you want to do this in seconds, not hours.

[nctnico]

and i obviously stand with nctnico in the idea that using a precertified "module" in a board makes it already certified for RED (or at least, that it's "good enough")

That is not what I wrote. Even with a pre-certified module, you'll need to prove that your product complies with RED. So testing/verification is still needed.

I have been glancing over the BLE tests in the EN 300 328 and there are quite a few of them so testing is time consuming. OTOH I get the impression that RED compliance is self certifiable (where I leave in the middle whether it is wise to skip tests and /or do the testing yourself or not).

[Siwastaja]

Even with a pre-certified module, you'll need to prove that your product complies with RED. So testing/verification is still needed.

Yes. As with all testing, in the end RED is still self-certification. So you can choose not to test/measure anything, pre-certified module or not. It's just that if your product causes problems, you are going to face more serious consequences for signing a document in which you claim that you know for sure the product is compliant. You can't know without testing, and "oh, it was a pre-certified module so I thought..." does not help much. Maybe it helps a bit, I don't know. It is like "I kinda tried to do due diligence partially..."

Pre-certified module likely passes though, so you can think about not testing it as taking a smaller risk than not testing a full custom design, but that's it. Problems can arise and "it was pre-certified" is no good excuse; at least you made a mistake trusting the manufacturer data, not understanding it, or the implications when integrating into part of own design.

[tszaboo]

EMC, radiated and conducted, was a much bigger deal, and you have to do it anyway, so I think for us the total difference would have been like 8K vs. 10K€ or something like that.

That's quite a bit. You should shop around, I had RED measured devices for far less, with multiple radio interfaces. In proper anechoic chamber, and R&S equipment. I think it was 2-3 hours per device.
We had prepared multiple samples, some of them were continuously transmitting (more than 50% of the time). Some were to test link budget and things like that. Some had SMA cable soldered instead of the antenna. We didn't test frequency hopping though, and only did thermal chamber/RF test when it was close to the limit.

[bookaboo]

Some of the problems you can still run into with a pre-certified module:
- Setting them outside of the legal bands (some will let you)
- Setting their power levels to high (some will let you)
- Setting the above correctly , but your antenna has gain in one direction, now you are above allowed levels in that direction.
- Too high a duty cycle, it depends on the band but some are limited (not sure about the 2.4GHz but certainly the ISM bands are)
- Not accounting for temperature drift (ask me how I know :/ )
- The module doesn't perform to spec (ask me how I know :/ )

All the same it's usually easier, and for proof of concepts or low volume, I've often done some sanity checking by replicating the proper RED tests on my bench.

[Siwastaja]

That's quite a bit. You should shop around, I had RED measured devices for far less, with multiple radio interfaces.

Sorry, I was unclear. That total included other standards we had to comply with plus LVD testing under accreditation because the thing has mains power relays. Of course if the only standard you have to comply with is RED then the radio measurement part (RED includes EMC, too) is bigger percentage of total.

[nctnico]

EMC, radiated and conducted, was a much bigger deal, and you have to do it anyway, so I think for us the total difference would have been like 8K vs. 10K€ or something like that.

That's quite a bit. You should shop around, I had RED measured devices for far less, with multiple radio interfaces. In proper anechoic chamber, and R&S equipment. I think it was 2-3 hours per device.
We had prepared multiple samples, some of them were continuously transmitting (more than 50% of the time). Some were to test link budget and things like that. Some had SMA cable soldered instead of the antenna. We didn't test frequency hopping though, and only did thermal chamber/RF test when it was close to the limit.

Is this complete with a certification report?

[tszaboo]

EMC, radiated and conducted, was a much bigger deal, and you have to do it anyway, so I think for us the total difference would have been like 8K vs. 10K€ or something like that.

That's quite a bit. You should shop around, I had RED measured devices for far less, with multiple radio interfaces. In proper anechoic chamber, and R&S equipment. I think it was 2-3 hours per device.
We had prepared multiple samples, some of them were continuously transmitting (more than 50% of the time). Some were to test link budget and things like that. Some had SMA cable soldered instead of the antenna. We didn't test frequency hopping though, and only did thermal chamber/RF test when it was close to the limit.

Is this complete with a certification report?

It's with EN 300 328 and few other standard precompliance test report. I'll PM you the company.

[nctnico]

EMC, radiated and conducted, was a much bigger deal, and you have to do it anyway, so I think for us the total difference would have been like 8K vs. 10K€ or something like that.

That's quite a bit. You should shop around, I had RED measured devices for far less, with multiple radio interfaces. In proper anechoic chamber, and R&S equipment. I think it was 2-3 hours per device.
We had prepared multiple samples, some of them were continuously transmitting (more than 50% of the time). Some were to test link budget and things like that. Some had SMA cable soldered instead of the antenna. We didn't test frequency hopping though, and only did thermal chamber/RF test when it was close to the limit.

Is this complete with a certification report?

It's with EN 300 328 and few other standard precompliance test report. I'll PM you the company.

I know the company from the PM (Kiwa, formerly Telefication). I got a quotation from them as well for pre-compliance and the actual compliance test. Pre-compliance is not expensive but count on the amount Siwastaja quoted earlier for a real/full compliance test.

[tszaboo]

EMC, radiated and conducted, was a much bigger deal, and you have to do it anyway, so I think for us the total difference would have been like 8K vs. 10K€ or something like that.

That's quite a bit. You should shop around, I had RED measured devices for far less, with multiple radio interfaces. In proper anechoic chamber, and R&S equipment. I think it was 2-3 hours per device.
We had prepared multiple samples, some of them were continuously transmitting (more than 50% of the time). Some were to test link budget and things like that. Some had SMA cable soldered instead of the antenna. We didn't test frequency hopping though, and only did thermal chamber/RF test when it was close to the limit.

Is this complete with a certification report?

It's with EN 300 328 and few other standard precompliance test report. I'll PM you the company.

I know the company from the PM (Kiwa, formerly Telefication). I got a quotation from them as well for pre-compliance and the actual compliance test. Pre-compliance is not expensive but count on the amount Siwastaja quoted earlier for a real/full compliance test.

There isn't RED certification. A testing house or NoBo will not provide a certificate because it's your responsibility as manufacturer to make sure the compliance exists.
It's a small subtle difference that most people will not understand, but we as engineers deciding on what to order need to be aware what's going on.
So once again, they are not going to issue Declaration of conformity, or certificate of compliance, you will. Hence there is no such thing as red "actual compliance" test.

[SiliconWizard]

That's right. All a lab can gve you is compliance with a set of standards according to another set of standards. After that, the declaration of conformity is all on the shoulders of the manufacturer.

[nctnico]

EMC, radiated and conducted, was a much bigger deal, and you have to do it anyway, so I think for us the total difference would have been like 8K vs. 10K€ or something like that.

That's quite a bit. You should shop around, I had RED measured devices for far less, with multiple radio interfaces. In proper anechoic chamber, and R&S equipment. I think it was 2-3 hours per device.
We had prepared multiple samples, some of them were continuously transmitting (more than 50% of the time). Some were to test link budget and things like that. Some had SMA cable soldered instead of the antenna. We didn't test frequency hopping though, and only did thermal chamber/RF test when it was close to the limit.

Is this complete with a certification report?

It's with EN 300 328 and few other standard precompliance test report. I'll PM you the company.

I know the company from the PM (Kiwa, formerly Telefication). I got a quotation from them as well for pre-compliance and the actual compliance test. Pre-compliance is not expensive but count on the amount Siwastaja quoted earlier for a real/full compliance test.

There isn't RED certification. A testing house or NoBo will not provide a certificate because it's your responsibility as manufacturer to make sure the compliance exists.
It's a small subtle difference that most people will not understand, but we as engineers deciding on what to order need to be aware what's going on.
So once again, they are not going to issue Declaration of conformity, or certificate of compliance, you will. Hence there is no such thing as red "actual compliance" test.

You are getting into a semantic argument here. Put differently: the paperwork from the test house is providing proof your product really complies with the limits as inferred by the law and thus your declaration of conformity has a solid legal foundation under it. But this should have been clear from the context as many test houses actually call their services CE / RED / FCC / etc certification and have certificates listed as the deliverable as a result of the compliance testing. Including the company you have used for precompliance testing.

[Siwastaja]

You are both kinda right.

Certification, by definition, is just something which produces a certificate, which is just an arbitrary document which someone decided to call a certificate. I can start selling certificates that your product uses GOTO statement in a socially responsible way.

Declaration of conformity is the only legal requirement, and it is not a certificate. This does not mean there are no such thing as certificates on RED compliance.

The only legal requirements are (1) actual conformity to standards, (2) declaration of conformity document saying this. You don't have to outsource any of it, you can do it all in-house, but there are many finely grained service levels how much and what exactly you would outsource, some may be called "certificates", some not. Generally, the more you pay, the less you have to do yourself. I'm not afraid of doing things, but I have found it is quite difficult to know what to do. And finally, of course, you can always try to push your luck and just do "something". You can, for example, pay for the measurements ("pre-compliance") alone and just look at the plots and get a confident feeling that your product likely causes no problems and thus no one will ask for your compliance documentation. If you want to build the proper documentation to support your declaration of conformity, then these fuller reports, or "certificates", simply save your time.

[nctnico]

Knowing which tests to do and how is a big question indeed. TI has a comprehensive appnote on which tests are relevant to BLE testing: swra601k (which they seem to keep up to date).

But you'd still need quite an amount of gear as well. With the RF / EMC testing gear I have accumulated over the years I can probably do a reasonable pre-pre-compliance check so the chance of surprises will be low.