EEE here with 16 years experience and having to deal with compliance from day 1 of my career. I now consult on product compliance. Author you are welcome to contact me.
Disclaimer: Nothing below is meant as legally relevant compliance advice. This is just my opinion on the matter.
Going to snark:
"The testing and certification industry is odd"
Except, outside the software world, the real world, where there are real consequences, it's not really.
"The line about CES, in particular, made my hair stand up."
Why? Absolutely the unauthorised device at CES is should NOT be allowed. What if said device caused too much interference on cell phone frequencies and suddenly nobody at CES can dial the local emergency number?
If that made "your hair stand up", here's one from personal experience that will freeze your blood:
I worked as a teen for a certain electronics chain. Said chain was selling a wireless weather station imported from China. A government department that monitored the country for Earthquakes noticed that this device impinged on their frequencies. After the spectrum regulator confirmed the finding, a nice gentleman from them visited us a told us the following:
1) As of this moment this device can no longer be sold. Move it off the floor immediately (he stayed and made sure we did exactly that).
2) That we will immediately issue a recall of said device at your own cost and issue full refunds to the customers.
3) He will return when we decide on further enforcement action which may include punitive fines and recommendations for further remedial action you will need to undertake.
"In theory, it exists to serve the public good and uphold consumer protection laws."
Well here's a (very simplistic) tidbit for the author: In the US, part of the gestation and formation of standards bodies and testing was "market forces", not for the public good. It was to help protect companies from litigation. If you followed the standards, tested and certed to them, paid the fees etc you then had the standards entity bat for you in court (UL is short for Underwriters Laboratory. That name was not chosen for funsies).
"However, in reality, the labs are “too busy” to respond or reply very late and generally sound less than eager to work with you."
Well you don't sound like a serious customer. AND the Labs are not there to give you advice. They're there to do INDEPENDENT testing.
"Variations of the FCC exist in pretty much every developed economy. Putting a poorly tested hardware product on the market immediately puts a target on your back. Maybe you’ll get lucky, but chances are that someone somewhere will report you. And, unless you are operating entirely out of China, it will hurt. A lot. Both your company and maybe even you, personally."
As it should. The electromagnetic spectrum is a very precious and very limited commodity and IMO, the best regulated "commons" in human civilisation (though still not perfect). So no, you are not welcome to just urinate in it willy nilly with your hustler start up product.
"I did not want to spend so much money on testing before I validated the market or gathered a community of believers."
And there it is.
"This way, the electronic device liability will fall on the manufacturer, and the magic of friendship EULA should afford me enough protection to make this a pure software play."
No. That's not how this works.
1) I assume the author is from the US (as they speak about the FCC). I had a 30 second look at these dev boards and their instructions. There is no FCC conformity declarations or markings, so US customers can't use it.
2) It has CE and UKCA though, so customers from EU+UK (and some other countries) can buy them but the certs only cover the dev boards AS SOLD. (i.e without the authors software)
3) Author is modifying the product behavior with their software. So yes author. You are still liable. Technically, your customers are first in the line of fire. But the likely sequence of steps is: Friendly Spectrum Representative will visit them first, have a chat, ask them to stop using the device, then leave them a lone and then come for YOU.
4) What the author has actually done is "buy down" their risk. It is simply less likely that the product will become non-compliant when their software is loaded. But it is still possible. At second glance, those dev boards don't come with a power supply. What is your recommended power supply to use Author? Have you tested your setup with said power supply and have test reports at the ready for when Friendly Spectrum Person comes knocking?
5) Sure it seems clever but Friendly Spectrum Agencies actually have quite far reaching and scary powers. Don't think that your little sleight of hand here is clever and protects you. Fundamentally: You are repackaging + modifying an existing product. The steps you are taking in between to "launder" your liability are irrelevant.
Frankly, it's shit like this, that makes it harder for everyone else playing by the rules. It did actually used to be easier. There used to be exemptions for "low volume" products. But all of those were seen as loopholes and HEAVILY abused. Now these toys have been taken away, with more to follow.
Thank you for this. It's possible that you've saved me and others a lot of pain by heading off ignorant mistakes.
I'm currently building a product that makes use of an ESP32 module with a built-in antenna. I've been operating under the naive assumption that since the modules are certified, the product I build with the module is certified (perhaps pending an EMF certification or something equally trivial). You've certainly put this issue on my radar.
That said, while I actually enjoyed the snark in your reply, there are those of us who actually do want to get this right and do the right thing, despite lacking years of experience and an infinite budget.
If you have any go-to resources to share that might qualify as accessible and perhaps written to an indie maker audience, I'll diligently consume anything you recommend.
The go-to resources are the FCC regulations and guidance documents. Be very careful with anything written to an indie maker audience. FCC regulations have the force of law and you are ultimately responsible for compliance: not the guy you read on the internet, not even your test laboratory.
There are a number of things you could conceivably be doing that would complicate your compliance situation beyond simply using the module's certification, getting test data from a certified lab for unintentional radiation for the Supplier's Declaration of Conformance procedure, appropriate labeling, and so on. (You're right that's a reasonable assumption about your situation but it may not always be true). They include but are not limited to, say, using more than one pre-certified transmitter in your device.
The certification testers will give a definitive answer, but most manufacturers will pre-test their products before sending them out for testing to improve the chances of passing the first time. You can rent some of the testing tools if necessary.
It sounds like you are actually doing some things right :) FCC, for example, have scope for "modular approval". Order a radio module (with modular approval), do exactly as the datasheet tells you and you can "piggy back" off the radio modules radio certs. But you will still need to test and cert for things like your own "unintentional emissions", maybe ESD and other things (NOT actual compliance advice btw, this is just to give a rough picture).
"That said, while I actually enjoyed the snark in your reply, there are those of us who actually do want to get this right and do the right thing, despite lacking years of experience and an infinite budget."
Oh I absolutely know you people are out there :) (I've consulted for them. I've also consulted for the ones who are learning the hard way...)
I don't intend to be mean with posts like this on HN, but some reality on these posts is just needed IMO. Especially given how much software dominates product development these days and people just don't know.
I think it's difficult for new comers, but I don't know how you fix that other than asking a consultant. The earlier the better. You can certainly make early feature and design choices to make your certs simpler (and cheaper) down the road.
That said, I think a good place to start for anyone is the following:
1) Find a product that is broadly similar to yours. Is it like a small computer? Is it a wired network device like a router? Maybe it's like a bluetooth dongle or smartwatch? Find one from a large reputable company and search said company's website for their "EU Declaration of Conformity". On these docs (even though it is not required) many companies list the standards that the device is compliant with. They have names like: EN 55022, EN 60950, IEC 61000-3-3.
NOTE - This is for EU only, but they have massive regulatory reach. Also many FCC and EU standards are very similar or even the same. Over time they have been converging more and more.
2) Do this for a few different devices of the same or similar category and you will notice many which are always there and some that are sometimes there. Now you have a starting template of standards that you might need.
3) With this starting template, you can now look up the standards names and often download the first few pages free to get an idea for what they are for.
4) Get a quote from a lab. They often do a lot of testing for product importers (as onus is also on said importers), so they can have "non-engineer friendly" forms that you can fill in. This will give you a price but also some information on what they think you need (they have to be careful though because they have to maintain their independence). Tell them you want CE (Europe) and FCC (North America). This covers much of the world for you. Many countries, even those with their own standards, also simply accept CE and FCC (again this is all in very very broad strokes). Many standards are also just copy and pasted between different regulatory domains but they change the name. So the original standards body will have their name for it. When the EU recognises it, it'll get an "EN" number for it's name (for example).
4b) Consider a hiring consultant for a short chat to "downsize" the standards you need and maybe they can point out any you might be missing. Good ones can also advise you on things you can do to avoid standards (and this is not in an illegal way). If you understand the rules well, you can sometimes make small changes and avoid whole sets of rules and testing (classic one IMO is a radio device. In VERY GENERAL TERMS, if it's going to be used more than 40cm from a human, then you don't need to test for human absorption of RF energy. My Chromecast, for example, has a disclaimer on it so that they can claim exactly this (IMO of course) ). How to find a good consultant? Well that's hard and I don't have a sure fire way sorry. Some labs have business cards of small local consultants.
5) Source copies of the standards and read them (Yes it'll likely be heavy reading). Most standards sellers (including the national ones) are crooks. Don't use them. Instead go to the Estonian Centre for Standardisation and Accreditation: https://www.evs.ee/en . They are the cheapest source I know of for standards in English (and only English matters). Further details in an old comment of mine here: https://news.ycombinator.com/item?id=36452660
These above steps are the same steps that I myself use.
Sources to read ... sadly I've not found many good ones. I think the best one that I would recommend is https://incompliancemag.com/
It's dry and does what it says on the tin. But their archives have some great articles by experts. They cover new standards, certing particular devices, testing technology etc. Even the ads can be kind of informative I think. It's good for learning the general layout of the field. Not a shallow learning curve but not steep either IMO (It's also free in digital form).
You left out Canada. IC certs are kind of a pain because some of their rules are very slightly different plus you need a representative in Canada.
UL standards can be read (but not downloaded) for free on UL's standard store. These don't include IEC standards adopted by UL, but do include national differences for those standards for the US.
The specific procedures your test lab will use in the US for typical part 15 devices include procedures covered by ANSI C63.4 (unintentional radiators) and C63.10 (intentional radiators). These you can't get from the Estonians. You probably won't need them but they can be helpful if you get serious about pre-compliance testing or if you are puzzled by what the lab is doing. IEC CISPR standards overlap here. There is a list of measurement procedures on the FCC web site:
https://www.fcc.gov/general/equipment-authorization-measurem...
You should have an engineer or "directly responsible individual" on site at the test lab during testing for all kinds of reasons, from building capability and understanding of the process to having someone there to clear up any misunderstandings. If you have a consultant do this for you, you or someone from your company should be there also.
For transmitters (intentional radiators) you can look up test reports and submittal information for competing products on the FCC's web site. That's one way to get an idea of what your test requirements and setups will look like. For unintentional radiators, you can find some test reports with a web search - companies are not required to make these public.
Excellent additions.
Sadly for Canada, some companies I worked with didn't bother because of these differences. "US market is big enough for launching. Maybe we'll come back to Canada later." They rarely did.
In practice the guy was planning to sell piece of software, on an SD card, that is compatible with a piece of hardware, and it's up to the customer to actually combine those two. The plan is exactly not to sell the hardware at all—granted they SD cards are piece of hardware, but what if that too was just an image to download off a site?
If the customer cannot legally use that SD with their boards, which SD can they use?
Is this not exactly equivalent how I might buy a Raspberry Pi and install a non-Raspberry-authorized OS on it? Or equivalent on how I might buy a PC and install Linux on it? Or Android and LineageOS? Are those devices certified not only as SOLD but also as modified by the end-user with software, making them somehow different?
That was not my read on it. My interpretation was that they wanted to sell a product, but didn't want to pay for an engineer who understands all this, labs for testing and doing all the paper work that it entails. So the plan became: "Customer buy this software, buy that hardware and put it together" => not liable => profit.
"Is this not exactly equivalent how I might buy a Raspberry Pi and install a non-Raspberry-authorized OS on it? Or equivalent on how I might buy a PC and install Linux on it? Or Android and LineageOS? Are those devices certified not only as SOLD but also as modified by the end-user with software, making them somehow different?"
Yes and no :) Very very succinctly:
When you test and cert, it is best practice to create the worst case scenario for your product and pass like with healthy margins. Especially for something like a smartphone or PC, when it's in the test chamber (for something like radiated emissions), you run it at "full noise" (even if it's not a realistic use case). So all your clocks: maximum (don't use all of the clocks? Turn them all on anyway); Power draw: Maximum or more; Play seizure inducing video to exercise that screen; Connect peripherals that are likely to be used to make sure those don't screw you etc. PCs and phones, especially, are tested at these extremes so that the manufacturer can be confident that despite what software the end-user loads, the device will remain compliant (this is also why the radio firmware is kept locked down hard).
Now in the case of this article, sure, the dev boards have CE, but what does that mean? How did they test it? Where all the peripherals running? What did the physical test setup look like? Under CE they are required to keep a compliance folder and to provide the information on request.
My experience with, dev boards that are "compliant". They just powered it up and maybe ran a simple program. Low effort, low noise, easy pass, because the reality is that they don't need it and time is money.
So now you a third party integrator takes that dev board, and runs something that wasn't exercised or puts it into a state that is non compliant. That's on you. Just like it's on the Author of this article.
I might be wrong in this case. Maybe the dev boards have excellent test setups. I might look at the test docs and think: "oh we should be fine". And just do a pre-compliance test and self-certify. You have to evaluate the risk each time and make a call.
If Microsoft released a patch tomorrow that somehow caused a sizable percentage of PCs to start stepping on the cell phone bands they would VERY quickly be told (I emphasise told NOT asked) to fix it. Just like any software this Author could load. They have not sidestepped any responsibility.
I was actually under the impression that PC motherboards have the spread spectrum clock available exactly for compliance reasons, and indeed it's the default as well. But you can turn it off.
Maybe they do indeed test without it, and it's only for the benefit of integrators to make use of (and perhaps disable other options altogether), if they find their complete system emissions somehow exceed limits.
Now that I'm in position to ask ;), I've wondered about the glass/plastic window PC cases.. Surely a PC case itself would not be required to have any emission tests done on it, or would it? On the other hand, might the PC motherboard emissions be certified with the assumption that it will be placed inside a case?
And then finally comes a consumer (or even a small integrator) and sticks in a PC motherboard inside a windowed case—but in this case the case might not be doing much on the RF side. Or maybe the cases provide better RF protection than they look like or the MBs don't need a case for that reason in the first place :).
You are correct on the spread spectrum clocks. Outside of military, they really soley exist for compliance (specifically unintended electromagnetic emissions) and are increasingly everywhere out of necessity. If an integrator needs spread spectrum locked on, there is no doubt a BIOS available that does just that.
"Now that I'm in position to ask ;)"
Ask away :) This is boring for 99.99999% of the population so I don't get to talk about it often :)
"I've wondered about the glass/plastic window PC cases.. Surely a PC case itself would not be required to have any emission tests done on it, or would it?"
You're right, a PC case itself does not need EMC compliance, but a PC case that's sold with a power supply does. So does one with built in fans and lights or anything electronic. IMO and very much off the cuff, certing the case + lights and fans without a whole computer inside is probably reasonable. But I would personally try cert with a whole PC (defence in depth).
"On the other hand, might the PC motherboard emissions be certified with the assumption that it will be placed inside a case?"
Yes it can be certed that way. Generally if it is, the details have to be in the manual.
But also, legally, you don't really need to cert a motherboard because it will always be integrated into another thing. However the reality of the PC architecture is that it is extremely modular and reach module is extremely complex. It's simply not at all practical for any systems integrator to try to modify those modules to try and make a whole PC compliant so that they can sell it. Even sticking the whole thing in a metal case might not be enough because the case has cables attached to and unwanted emissions and get out via those.
So for practical purposes manufacturers of motherboards, graphics cards, PSUs, hard drives etc vigorously test and cert their products with decent margins so that no matter what cards are used or how a PC is put together, the sum will be compliant. And this rule holds pretty well in general at all scales, from the individual parts and submodules that come together to make a product up to several products wired together in your house with power and network cables.
And system integrators can demand these requirements because it's necessary for the industry to function. I found a few years ago on Dell's website their manual for part suppliers. It listed every standard they required, made stricter and even had additions of their own so that they could sell with your module everywhere in the world, because they sell everywhere. It basically a thick manual on making a computer "world compatible".
"And then finally comes a consumer (or even a small integrator) and sticks in a PC motherboard inside a windowed case—but in this case the case might not be doing much on the RF side. Or maybe the cases provide better RF protection than they look like or the MBs don't need a case for that reason in the first place :)."
And the consumer benefits from everything I explained earlier. They can buy parts and assemble a computer that will be compliant. It's also why computer shops can build you a PC and sell without a cert and it'll be fine. Just the sheer effort of all these manufacturers so that they have a market to sell into means that the problem is solved for small players in the traditional PC world. The traditional PC industry is quite unique in that way actually.
That bit about PCs and phones was surprising, but I guess not unexpected. I have built many "EMI test versions" of code so various products can be taken to the test house. We don't go to those extremes: typically, we'll run as close to worst case as we can get, but nothing unrealistic. Then again, no one but us is loading code onto our devices, so it's not like a PC where you have no control over what it's running.
One company I have worked with had an internal rule for "radiated emissions": You had to be 10dB (1 order of magnitude) underneath the limits before going for a formal cert. Non-negotiable.
Part of the reason for this rule was that they:
1) OEMed their products.
2) Sold products that could be used in complex and bespoke CAN networks with goodness knows what else.
3) There was a chance of interfering with Marine VHF radio which is used for emergencies. The EU rules were (still are) not actually strict enough for preventing interference with that band.
>> 3) Author is modifying the product behavior with their software. So yes author. You are still liable. Technically, your customers are first in the line of fire. But the likely sequence of steps is: Friendly Spectrum Representative will visit them first, have a chat, ask them to stop using the device, then leave them a lone and then come for YOU.
Few questions related to this.
- Does this meant that recertification is required every time we load a different version of the software ?
- How does this work for Computers and mobile phones ? The hardware is certified but you are loading different software daily.
In the purest theoretical sense yes, in practice no. So that you don't have to recert everytime, you
1) test and exercise your product to extremes so that you can say with high certainty that: no matter what the customer loads, it won't breach the rules.
2) As pjc50 mentioned: Lock down the parts which the user could potentially cause the most damage with. i.e lock down that radio firmware (why is why none of it is open source).
If you do (1) and (2) and a few other things, you buy down your risk sufficiently that you can confidently demonstrate that re-certs are not needed.
The Author of the parent article IMO is doing the exact opposite.
There are also half-way houses: Just doing "pre-compliance testing". So not a formal cert, your just doing a quick test in an anaechoic chamber or even on a table top scanner. Of course this only applies to things you can self-certify. Some things, like radios (WiFi, Bluetooth etc.), you cannot self-certify. That's why almost everyone buys the radio as a module (To buy down their risk). By consequence: That's why those radio module manufacturers have the firmware locked down hard and engineer and cert the radios to have big margins.
There are a lot of rules yes, but there is actually a lot of flexibility and common sense in the system too (but it is still imperfect, absolutely). But that flexibility does not allow for horsing around. If you can demonstrate to Friendly Spectrum Agency all this due diligence, you are going to have a MUCH better time.
The "software" in these cases is localized to the drivers/firmware. This is why you basically can't get a RF peripheral for Linux with truly open firmware and they all use binary blobs: to prevent you modifying it.
If it's not a transmitter, then it's not certified (this has a meaning), you just need to have acceptable data on hand for your Supplier's Declaration of Conformity (SDoC). Then if you make any changes to your product after test, it is a judgement call whether you need to retest. Ultimately you are responsible for compliance, so this is not a free pass. In principle your computer or cell phone manufacturer could get fined if it is possible to operate their device with new user software in a way that emits RF above allowable levels.
If it is a transmitter and you-the-manufacturer make changes to software that operates the transmitter, the FCC has specific rules. Look at the KDBs for permissive changes and for Software Defined Radio Applications. Note that the FCC has a somewhat unique idea of what constitutes an SDR. Some software changes to radio firmware will require recertification but some just will require a permissive change. Some permissive changes are handled in a way similar to SDoCs, where you just get yourself a report with acceptable data, some require filing that data with the FCC.
"Author is modifying the product behavior with their software."
I would say that the end user is modifying the behavior of the hardware, that they own and are fully in control of, by choosing to run software that they purchased. But I'm fully aware that regulatory agencies probably have their own way of thinking about that.
Point taken about how we need some regulations, but isn't everyone sitting in an MBA program right now being trained to identify this exact kind of workaround?
As for displaying a device that isn't certified yet, who's the victim? What's wrong with saying "We can't take orders on this yet, but we're working on getting cool new product certified as fast as possible"? The article said displaying a device, not turning it on.
From your post, it seems like you're painting this guy as a malicious bad actor who going to destroy society when, to me, he seems like someone who's trying to find an efficient way to sell a solution to people who might find it valuable.
> I assume the author is from the US (as they speak about the FCC). I had a 30 second look at these dev boards and their instructions. There is no FCC conformity declarations or markings, so US customers can't use it.
Just order it off Aliexpress.
It's fine to have a really expensive compliance regime, so long as you understand how that drives the small end of the business offshore.
Then it's on you as the importer. This is part of why lots of stuff on AliExpress and dodgy Amazon 3rd party supplies is cheap. It's non compliant stuff that is not even sold in China. It's export only, and for the wrong reasons.
I think that both sides (SW and HW) can learn to coexist better, and tbh, there is really a necessity for them to.
The reality is that the reason software is currently the top industry/value creator when it comes to revenue is an artifact of an open ecosystem where the barriers to entry are low, and where there is space for many to experiment.
Traditionally, the engineering world doesn't see things the same way. Part of this is culture, and that's hard to change - engineers see what they do as an art, and this is fine,and it's a good thing as some engineering systems do have a disproportionate impact, but I think the tone of the response also does reflect an attitude of perfectionism and "this at any cost" that I think holds the field back.
I think the solution is not rather to "just let people run amok" (though as it happens, this is the strategy China is testing for us and it appears to not have broken too much yet - the land of trillions of SOIC-8 Bluetooth MCUs with no shielding and a 5-line BOM) but rather for the engineering world to embrace the software developers and provide a happy path to compliance.
If you want North America to compete with China on having ubiquitous technologies everywhere (this is the only way to build out the supply chain), we have to come up with a way to fix certification and part of the attitude has to be "we're going to teach you how to cheaply get your product to market in a way that respects the spectrum", and not "it's expensive, deal with it". This one is tough for people to accept but we cannot ever go back to stuff being expensive, as the floodgates have already been opened.
This is something that the government has to do, probably - provide funding to run (at least, cut down versions of the labs for precompliance) cheaply, put out good resources. Encourage or fund the creation of low-cost and easy to understand paths to compliance. As anyone knows, if you try to hold your nose to stop a nosebleed, the blood just goes down your throat. Same with all of the stuff from China. If you want to meaningfully improve device compliance, making the process hard and painful will just increase the number of random Amazon/Temu Bluetooth nonsense with a total lack of attention to design at all. If we made the process more accessible, it's possible that this would drive the industry to create solutions that might not even cost more, but are more compliant - which would be a win overall.
EMC compliance rules are needed so that all our electronic devices (running software mind you) can continue to function. Part of the rules are about squeezing as much "performance" as possible out of the "thing" that is the electromagnetic spectrum. It's simple physics.
The other part of the rules are for human safety. Devices can directly hurt people (like a microwave) or indirectly (like a crappy device that prevented ambulance phone calls going through).
It's as simple as that (and not perfectionism or being mean to the poor software people).
""we're going to teach you how to cheaply get your product to market in a way that respects the spectrum"
I'm available to do exactly that for you at my hourly rate :D
hard agree, it sucks immensely that I can design a cool 4 layer PCB with multicore processor in an afternoon, throw on a standard bluetooth module, and have it manufactured and shipped to me in a week for like $100, but heaven forbid I want to sell five of them to fellow nerds on a niche forum without breaking multiple laws, and the path to compliance is, uh, find a consultant with EMI testing experience and industry connections and/or spend $5000?
and then amazon is full of absolutely noncompliant untested stuff with no consequences
Don't forget having to spend $X000 for the privilege of being allowed to read the standards you're required to follow, and needing a consultant to tell you which standards you have to follow in the first place.
Hard agree that pricing for standards is generally insane. IMO if the law requires it, it should be free + maybe a $10 admin. Anything else is BS. Standards bodies already make a killing off their membership fees. There are alternatives and workarounds though, here is one: https://news.ycombinator.com/item?id=36452660
If you don't want to hire a consultant then don't. You can do it yourself. Go get a EEE degree and then spend 5-15 years working as a EEE in product development and certification. Then you'll be good to go :)
Or just blind self certify and pay the lawyers, Friendly Spectrum Agency and other spectrum users (like cell phone companies) when they come knocking and asking for damages from you.
Amazon absolutely requires sellers to supply FCC certification and Suppliers' Declaration of Conformity documentation for FCC regulated devices. You can report any noncompliant products to them and they do remove them.
Just wait till you learn about say, product liability, CPSC regulations, "voluntary" safety standards, and so on
> The reality is that the reason software is currently the top industry/value creator when it comes to revenue is an artifact of an open ecosystem where the barriers to entry are low, and where there is space for many to experiment.
The reason software has more pay is because it scales really well. You write software once and then sell it, and your costs per copy is low. That means if you write software that increases productivity 20% that can sell for $$$$$$ while your costs are essentially fixed.
>"Author is modifying the product behavior with their software."
If this were a real concern, then every programmer everywhere would need FCC certification for any program they ever write. But that isn't the case so far as I know.
Disclaimer: Nothing below is meant as legally relevant compliance advice. This is just my opinion on the matter.
Going to snark:
"The testing and certification industry is odd"
Except, outside the software world, the real world, where there are real consequences, it's not really.
"The line about CES, in particular, made my hair stand up."
Why? Absolutely the unauthorised device at CES is should NOT be allowed. What if said device caused too much interference on cell phone frequencies and suddenly nobody at CES can dial the local emergency number?
If that made "your hair stand up", here's one from personal experience that will freeze your blood:
I worked as a teen for a certain electronics chain. Said chain was selling a wireless weather station imported from China. A government department that monitored the country for Earthquakes noticed that this device impinged on their frequencies. After the spectrum regulator confirmed the finding, a nice gentleman from them visited us a told us the following:
1) As of this moment this device can no longer be sold. Move it off the floor immediately (he stayed and made sure we did exactly that).
2) That we will immediately issue a recall of said device at your own cost and issue full refunds to the customers.
3) He will return when we decide on further enforcement action which may include punitive fines and recommendations for further remedial action you will need to undertake.
"In theory, it exists to serve the public good and uphold consumer protection laws."
Well here's a (very simplistic) tidbit for the author: In the US, part of the gestation and formation of standards bodies and testing was "market forces", not for the public good. It was to help protect companies from litigation. If you followed the standards, tested and certed to them, paid the fees etc you then had the standards entity bat for you in court (UL is short for Underwriters Laboratory. That name was not chosen for funsies).
"However, in reality, the labs are “too busy” to respond or reply very late and generally sound less than eager to work with you."
Well you don't sound like a serious customer. AND the Labs are not there to give you advice. They're there to do INDEPENDENT testing.
"Variations of the FCC exist in pretty much every developed economy. Putting a poorly tested hardware product on the market immediately puts a target on your back. Maybe you’ll get lucky, but chances are that someone somewhere will report you. And, unless you are operating entirely out of China, it will hurt. A lot. Both your company and maybe even you, personally."
As it should. The electromagnetic spectrum is a very precious and very limited commodity and IMO, the best regulated "commons" in human civilisation (though still not perfect). So no, you are not welcome to just urinate in it willy nilly with your hustler start up product.
"I did not want to spend so much money on testing before I validated the market or gathered a community of believers."
And there it is.
"This way, the electronic device liability will fall on the manufacturer, and the magic of friendship EULA should afford me enough protection to make this a pure software play."
No. That's not how this works.
1) I assume the author is from the US (as they speak about the FCC). I had a 30 second look at these dev boards and their instructions. There is no FCC conformity declarations or markings, so US customers can't use it.
2) It has CE and UKCA though, so customers from EU+UK (and some other countries) can buy them but the certs only cover the dev boards AS SOLD. (i.e without the authors software)
3) Author is modifying the product behavior with their software. So yes author. You are still liable. Technically, your customers are first in the line of fire. But the likely sequence of steps is: Friendly Spectrum Representative will visit them first, have a chat, ask them to stop using the device, then leave them a lone and then come for YOU.
4) What the author has actually done is "buy down" their risk. It is simply less likely that the product will become non-compliant when their software is loaded. But it is still possible. At second glance, those dev boards don't come with a power supply. What is your recommended power supply to use Author? Have you tested your setup with said power supply and have test reports at the ready for when Friendly Spectrum Person comes knocking?
5) Sure it seems clever but Friendly Spectrum Agencies actually have quite far reaching and scary powers. Don't think that your little sleight of hand here is clever and protects you. Fundamentally: You are repackaging + modifying an existing product. The steps you are taking in between to "launder" your liability are irrelevant.
Frankly, it's shit like this, that makes it harder for everyone else playing by the rules. It did actually used to be easier. There used to be exemptions for "low volume" products. But all of those were seen as loopholes and HEAVILY abused. Now these toys have been taken away, with more to follow.