Author Topic: Looking at BLE SOCs, nRF52  (Read 8059 times)

0 Members and 1 Guest are viewing this topic.

Offline robca

  • Frequent Contributor
  • **
  • Posts: 257
Re: Looking at BLE SOCs, nRF52
« Reply #50 on: November 27, 2023, 05:03:10 pm »
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.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26907
  • Country: nl
    • NCT Developments
Re: Looking at BLE SOCs, nRF52
« Reply #51 on: November 27, 2023, 05:08:53 pm »
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?
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: Siwastaja

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 8173
  • Country: fi
Re: Looking at BLE SOCs, nRF52
« Reply #52 on: November 27, 2023, 05:31:11 pm »
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.
 

Offline DannyTheGhost

  • Contributor
  • Posts: 49
  • Country: ua
Re: Looking at BLE SOCs, nRF52
« Reply #53 on: November 27, 2023, 07:33:10 pm »
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.
 
The following users thanked this post: Siwastaja

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 828
Re: Looking at BLE SOCs, nRF52
« Reply #54 on: November 27, 2023, 07:49:45 pm »
Quote
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?

 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26907
  • Country: nl
    • NCT Developments
Re: Looking at BLE SOCs, nRF52
« Reply #55 on: November 27, 2023, 08:05:32 pm »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14481
  • Country: fr
Re: Looking at BLE SOCs, nRF52
« Reply #56 on: November 27, 2023, 09:47:04 pm »
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.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26907
  • Country: nl
    • NCT Developments
Re: Looking at BLE SOCs, nRF52
« Reply #57 on: November 27, 2023, 09:59:11 pm »
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.
« Last Edit: November 27, 2023, 10:17:37 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline JPorticiTopic starter

  • Super Contributor
  • ***
  • Posts: 3461
  • Country: it
Re: Looking at BLE SOCs, nRF52
« Reply #58 on: November 28, 2023, 06:05:21 am »
Quote
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")
« Last Edit: November 28, 2023, 06:08:13 am by JPortici »
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 8173
  • Country: fi
Re: Looking at BLE SOCs, nRF52
« Reply #59 on: November 28, 2023, 06:59:39 am »
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.
« Last Edit: November 28, 2023, 07:27:20 am by Siwastaja »
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26907
  • Country: nl
    • NCT Developments
Re: Looking at BLE SOCs, nRF52
« Reply #60 on: November 28, 2023, 09:59:14 am »
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).
« Last Edit: November 28, 2023, 10:08:19 am by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: Siwastaja, JPortici

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 8173
  • Country: fi
Re: Looking at BLE SOCs, nRF52
« Reply #61 on: November 28, 2023, 10:04:24 am »
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.
« Last Edit: November 28, 2023, 10:06:23 am by Siwastaja »
 
The following users thanked this post: nctnico

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 7390
  • Country: nl
  • Current job: ATEX product design
Re: Looking at BLE SOCs, nRF52
« Reply #62 on: November 29, 2023, 05:15:10 pm »
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.
 

Offline bookaboo

  • Frequent Contributor
  • **
  • Posts: 729
  • Country: ie
Re: Looking at BLE SOCs, nRF52
« Reply #63 on: November 29, 2023, 06:58:40 pm »
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.
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 8173
  • Country: fi
Re: Looking at BLE SOCs, nRF52
« Reply #64 on: November 30, 2023, 06:28:07 am »
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.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26907
  • Country: nl
    • NCT Developments
Re: Looking at BLE SOCs, nRF52
« Reply #65 on: December 01, 2023, 12:29:48 am »
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?
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 7390
  • Country: nl
  • Current job: ATEX product design
Re: Looking at BLE SOCs, nRF52
« Reply #66 on: December 01, 2023, 01:12:52 pm »
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.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26907
  • Country: nl
    • NCT Developments
Re: Looking at BLE SOCs, nRF52
« Reply #67 on: December 01, 2023, 02:00:01 pm »
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 are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 7390
  • Country: nl
  • Current job: ATEX product design
Re: Looking at BLE SOCs, nRF52
« Reply #68 on: December 01, 2023, 11:49:50 pm »
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.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14481
  • Country: fr
Re: Looking at BLE SOCs, nRF52
« Reply #69 on: December 02, 2023, 12:34:13 am »
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.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26907
  • Country: nl
    • NCT Developments
Re: Looking at BLE SOCs, nRF52
« Reply #70 on: December 02, 2023, 01:34:49 am »
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.
« Last Edit: December 02, 2023, 01:45:49 am by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 8173
  • Country: fi
Re: Looking at BLE SOCs, nRF52
« Reply #71 on: December 02, 2023, 07:11:18 am »
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.
« Last Edit: December 02, 2023, 07:13:45 am by Siwastaja »
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26907
  • Country: nl
    • NCT Developments
Re: Looking at BLE SOCs, nRF52
« Reply #72 on: December 02, 2023, 11:06:33 am »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf