Radio module off during EMC testing?

[Twistx77]

Hi everyone,

I would like to know if someone here had experience on something similar to this. I want to get CE certification for a board which has an ESP32 module (Wifi + Bluetooth). The thing is that in a first iteration, I don't plan to use the Wifi or Bluetooth. The idea is to have it so, once enough units have been sold, we can add the necessary code for Wifi or BT functions and just recertify it with that functionality.

Now my question is the following: Can I pass EMC (without doing specific rf testing) with the radios of the ESP32 disabled in firmware since we don't use them at all in the product? Or do I need to set it to emit continuously like it would be done normally if the radios were used in the product?

We have asked a testing house, and first they said that if the radios were disabled and the module was pre-certified it was not necessary to do any "special" rf-radio testing. But 2 days later they wrote to us saying that actually that was wrong and it is needed.

Can someone with experience throw some light on this?

Thank you.

Alex

[Neilm]

Personally I would do the test with the radios transmitting as if you find a problem you would not be able to enable it afterward without running the risk of having to do a recall. The additional testing would not be that much. While you would not have to do a certification test of the precertified module, you would be checking that it didn't interact with your equipment and re-radiate in weird ways.


Note - All this is my own opinion and may or may not represent the way regulators would view this. (Ass covering complete)

[Twistx77]

Personally I would do the test with the radios transmitting as if you find a problem you would not be able to enable it afterward without running the risk of having to do a recall. The additional testing would not be that much. While you would not have to do a certification test of the precertified module, you would be checking that it didn't interact with your equipment and re-radiate in weird ways.


Note - All this is my own opinion and may or may not represent the way regulators would view this. (Ass covering complete)

Hi Neilm,

Thanks for your post. I understand your point but the idea here is save the extra cost for the first testing until the product idea is proofed by the market. Then, redesigning the board if necessary is not such a big problem. But rewriting the firmware and getting an MCU that has the same features won't be that easy. Also our prototypes are already base on the ESP32.

Regards,

Alex

[MartinL]

You may need to get to grips with the legislation yourself and come up with a compliance plan, rather than relying on a test house to tell you what's needed. Their role is usually just to run whichever tests you tell them to.

There are some consultants around that specialise in helping you figure out what you need to do if you're not confident in navigating it all from scratch yourself, and a little of their time may be good value to get you started.

If you're new to this, you may not be aware that it's usual to do a round of "pre-compliance" testing before you proceed further. This is an informal process, typically done in a single day, where you take your device to the test house and work with their staff to set up some of the main test conditions and have a quick look at how your device performs. Often you will find some issues straight away, and you can then go back and fix them before coming back to try again. Then when everything looks good, you ask the test house to go ahead and work through the full suite of tests for the standards you need to hit, which is the expensive part. To do that, you need to have a full test plan ready including how your device will be set up for each test, so you're going to have to get to grips with the details sooner or later anyway.

In terms of managing risk versus expense, a potential middle ground would be to test both RED and EMCD requirements at the pre-compliance stage. You'd then have a good bet - but not a guarantee - that the device is likely to pass both, but you could choose to only spend the money on full testing for the EMCD side before going to market.

As to the question of whether RED compliance would actually be required regardless, there is some EU guidance on LVD/EMCD/RED interactions here that might be worth looking at as a starting point: https://ec.europa.eu/docsroom/documents/29121

[tszaboo]

If you are from the EU, than that's the wrong question. Anything with a radio would never pass the EMC tests, because they would fail by default, because they transmit.
You have to pass RED, the Radio Equipment Directive. And not only does your radio need to transmit, it has to do that continuously, plus reception is tested as well, link quality, things like that.
You need to prepare like 6 units with different configurations (antenna, Coax cable on output, tx, rx stuff like this)

[MartinL]

tszaboo, I think you've missed the point of the question.

Obviously if you use a transmitter in a product then it needs to satisfy RED. But if you use a component which has the potential to transmit, but is not actually set up to do so in the product as placed on the market, then it seems quite reasonable for that product to be tested to EMCD rather than RED.

It may seem like an odd thing to do, but there can be real advantages to this approach if you want to keep the option of a radio version open in the future. If you use an MCU without an integrated radio, you might save a dollar on the BOM, but you could end up spending far more on porting your firmware to a new platform later. If you go with something like ESP32, which is a pretty capable dual-core micro with some nice peripherals, then you have an easy path to a radio version later, once you're in a position to do the extra work and spend the extra certification costs.

If you're arguing that the product must satisfy RED just because it contains a component which is capable of transmission, well, how would you even apply the tests? Many of the RFMCUs out there support completely arbitrary modulations and other parameters. How would you apply the OBW tests for instance, when there is no choice of parameters that is actually used by the product?

And where would you draw the line? At the end of the day all sorts of things can be used as a radio if you try hard enough.

[2N3055]

tszaboo, I think you've missed the point of the question.

Obviously if you use a transmitter in a product then it needs to satisfy RED. But if you use a component which has the potential to transmit, but is not actually set up to do so in the product as placed on the market, then it seems quite reasonable for that product to be tested to EMCD rather than RED.

It may seem like an odd thing to do, but there can be real advantages to this approach if you want to keep the option of a radio version open in the future. If you use an MCU without an integrated radio, you might save a dollar on the BOM, but you could end up spending far more on porting your firmware to a new platform later. If you go with something like ESP32, which is a pretty capable dual-core micro with some nice peripherals, then you have an easy path to a radio version later, once you're in a position to do the extra work and spend the extra certification costs.

If you're arguing that the product must satisfy RED just because it contains a component which is capable of transmission, well, how would you even apply the tests? Many of the RFMCUs out there support completely arbitrary modulations and other parameters. How would you apply the OBW tests for instance, when there is no choice of parameters that is actually used by the product?

And where would you draw the line? At the end of the day all sorts of things can be used as a radio if you try hard enough.

Well if you PLAN to use it later or have a plan that you MIGHT use it later after sales, than you would need to write enough radio functionality to test it for it's intended usage. If you used ESP32 for instance and radio is disabled and it is planned to stay that way then you might argue it does not and won't ever have radio functionality.

But saying we don't use it now but want to leave open possibility to later on add that function with upgrades to customer, that won't fly. And it shouldn't. Otherwise you could get phones with radio disabled, and sold as personal organizers. Then you would go to manufacturer's web site, download new firmware on a MicroSD card, and upgrade the device with it and get a fully featured phone with all kinds of radio blasting into ether... And manufacturers wouldn't need to certify to RED.

Only thing that you might get away with is that you sell device with radio disabled, then develop radio software fully on exactly the same hardware platform (so you can prove the chain of device ID) and then fully certify this, and then deploy it to all the new and old devices claiming that they run same certified hardware and software platform now.

[MartinL]

I think the relevant clause on the matter is this, from Article 17(1) of the Radio Equipment Directive:

The conformity assessment shall take into account all intended operating conditions and, for the essential requirement set out in point (a) of Article 3(1), the assessment shall also take into account the reasonably foreseeable conditions. Where the radio equipment is capable of taking different configurations, the conformity assessment shall confirm whether the radio equipment meets the essential requirements set out in Article 3 in all possible configurations.

As with all such things it's going to depend on interpretation of these terms.

But it seems pretty clear to me that the extreme scenario of "phones sold as personal organizers, with firmware update on the website" is ruled out, since it would obviously be "reasonably foreseeable" that users would download the update and put the device into another "possible configuration" that should have been tested.

But at the other end of the scale, if a product is a sealed unit without any user-accessible way to change its configuration, we would normally not consider it "reasonably foreseeable" that an end user will pry it open, reverse engineer it, and modify it themselves. Even though there exist a handful individuals (like myself!) who do such things, it's just beyond any sensible definition of "reasonably foreseeable" for the manufacturer to have to consider every potential modification of the product as being a "possible configuration" that must be tested.

So in practice you'll find yourself somewhere between those two extremes, and you'll need to make an argument for being sufficiently far from the former scenario, and sufficiently close to the latter.

Which in practice might mean something like:

- The device ships with firmware that disables the radio.
- The device's normal update process will only accept signed firmware updates.
- Before releasing an update that enables the radio, you complete full RED compliance testing of the design and issue a new declaration of conformity for it.

Or a little more strict than that, or a little less. Decide what you're comfortable with, or go ask an expert to find some case law.

But at the end of the day you have to ask yourself, what scenario are you worried about if you get it wrong? Your device is going to be competing with all sorts of "CE marked" garbage that has never seen the inside of a test chamber. Enforcement is practically non-existent. If you don't take the piss you are unlikely to ever be asked about any of this, except by a test house trying to squeeze more cash out of you.

[tszaboo]

I think the relevant clause on the matter is this, from Article 17(1) of the Radio Equipment Directive:

The conformity assessment shall take into account all intended operating conditions and, for the essential requirement set out in point (a) of Article 3(1), the assessment shall also take into account the reasonably foreseeable conditions. Where the radio equipment is capable of taking different configurations, the conformity assessment shall confirm whether the radio equipment meets the essential requirements set out in Article 3 in all possible configurations.

As with all such things it's going to depend on interpretation of these terms.

But it seems pretty clear to me that the extreme scenario of "phones sold as personal organizers, with firmware update on the website" is ruled out, since it would obviously be "reasonably foreseeable" that users would download the update and put the device into another "possible configuration" that should have been tested.

But at the other end of the scale, if a product is a sealed unit without any user-accessible way to change its configuration, we would normally not consider it "reasonably foreseeable" that an end user will pry it open, reverse engineer it, and modify it themselves. Even though there exist a handful individuals (like myself!) who do such things, it's just beyond any sensible definition of "reasonably foreseeable" for the manufacturer to have to consider every potential modification of the product as being a "possible configuration" that must be tested.

So in practice you'll find yourself somewhere between those two extremes, and you'll need to make an argument for being sufficiently far from the former scenario, and sufficiently close to the latter.

Which in practice might mean something like:

- The device ships with firmware that disables the radio.
- The device's normal update process will only accept signed firmware updates.
- Before releasing an update that enables the radio, you complete full RED compliance testing of the design and issue a new declaration of conformity for it.

Or a little more strict than that, or a little less. Decide what you're comfortable with, or go ask an expert to find some case law.

But at the end of the day you have to ask yourself, what scenario are you worried about if you get it wrong? Your device is going to be competing with all sorts of "CE marked" garbage that has never seen the inside of a test chamber. Enforcement is practically non-existent. If you don't take the piss you are unlikely to ever be asked about any of this, except by a test house trying to squeeze more cash out of you.

Mostly agree, but Article 4 is better I think:

Manufacturers of radio equipment and of software allowing radio equipment to be used as intended shall provide the Member States and the Commission with information on the compliance of intended combinations of radio equipment and software with the essential requirements set out in Article 3. Such information shall result from a conformity assessment carried out in accordance with Article 17, and shall be given in the form of a statement of compliance which includes the elements set out in Annex VI. Depending on the specific combinations of radio equipment and software, the information shall precisely identify the radio equipment and the software which have been assessed, and it shall be continuously updated.

Does this mean that each software update needs to be tested? No, but technical documentation should cover why the device after software update stayed compliant. IMHO, and in my experience, writing that "we didn't change the settings" is enough, this is not FCC madness.

[Twistx77]

Hi,

Thank you all for your replies and experience. It looks like it comes down to interpretation of the articles and how much one would want to "risk" it. Protecting an ESP32 from someone to update it and turn on the radio might be harder than changing the MCU for one that has no radio and then add an external wifi/bt module. Even if we implemented signed firmware's to use through bootloader, one could always use JTAG to program it and that is it.

I'll anyway check the documents shared. That might give us more clarity buy it seems that this is no a "standard" practice and therefore will not be ever 100% clear.

Thank you!

[MartinL]

I really don't think you need to worry about what someone might do with the JTAG pins.

In practice, almost every product on the market can be reprogrammed if you unscrew the case and connect to a header or some test points that were used in the factory. That's just how the industry works, and nobody expects you to test for every outcome that could happen if someone does so - at least not unless it's some safety critical product (for which you'd be dealing with a notified body rather than self-certification anyway).

The usual approach is that you sell the product with some firmware version on it, you tested it with the same or earlier firmware version, and you keep a technical file with the test results that, for each change since, says something to the effect of "we didn't change anything that should affect the certification". In theory, the authorities may ask you to show them this file. In practice, it will gather dust and you will wonder why you bothered with all that effort.

If you don't provide the user with an obvious way of changing the configuration, other than installing an update that came from you, then I don't see a problem.

And it's not like we're talking about you hiding a 100W transmitter for some critical band in there and then planning to use it later. It's just yet another piddly little ESP32, 10mW in an ISM band, that's a pre-certified module anyway. The chance of your product causing any practical problem because of it is just absolutely negligible. I just cannot imagine a scenario in which a regulator would choose to hassle you, over all the other things they could be looking at. People seem to get paranoid when it comes to certification, but at the end of the day it all runs on common sense.