[milesvp]

> ditch binary blobs entirely

I agree there is not much of a clear call to action. As a firmware engineer who has worked with bluetooth amd wifi, this is a key phrase. It’s also a big fantasy. FCC compliance is a big headache, and part of why people buy a given chip is the FCC certification comes with it. For instance, if I throw an ESP32 into a product and use wifi, I don’t need further certification. That can only happen if “there is no way” you can make the radio do what the FCC doesn’t allow. A general stategy for this is for the company to give a binary blob for radio related functions that limits the radio capabilities that you need to link to in your final build.

So that means there is almost zero chance the chip makers will ever publicly move away from binary blobs. At best they might quietly support reverse engineering efforts by open source driver projects.

That said, I would love it if all the chips I worked with had a battle hardened non vendor alternative. One major downside to these binary blobs is that they can be buggy. We were recently able ro rewrite our Bluetooth firmware to use an opensource version which greatly sped up the data throughput since it didn’t have a bug that killed byte transfer. But we don’t use this code lightly. FCC violations are crazy expensive and not something you take lightly.

[JacobKfromIRC]

Would you happen to know where the requirement that "“there is no way” you can make the radio do what the FCC doesn’t allow" comes from? I found an FCC compliance guide [1] but it's very long and not easily searchable as far as I can tell.

If there has to be no way to change the radio's functionality, would that mean that simply using a binary blob wouldn't be enough. Wouldn't device vendors have to sign it as well?

Also, that makes me wonder about the one Wi-Fi chip I know of that does have free firmware: AR9271 [2]. I wonder what makes that situation different. Maybe I'm misunderstanding and there's firmware on a separate chip stored in ROM.

[1] http://www.fcc.gov/documents/compliance-guide [2] https://wiki.postmarketos.org/wiki/AR9271

[milesvp]

I'm far from an expert, but from what I understand the FCC cares most about consumer electronics is devices that stomp on the spectrum. And so frequency, antenna power, and signal band matter a lot. So you need to make sure that your antenna is only ever emitting in the band it's allowed, and that the total power never exceeds some amount, where the allowed amount is a function of the area under the curve of bandwidth vs antenna strength.

So when I say "there is no way", what I'm referring to, are the functions that configure drivers don't accept out of bounds values. And functions that ultimately drive the antenna can't drive them hard enough to be in violation. The main reason I know any of this, was that I found a function when working on firmware for the ESP32 on a commercial device, and I thought I could set the power to a level that I thought was too high. Well, that's when I learned what the binary blob that Espressif supplies was for. The guardrails are baked into the API for that blob.

So, does that mean you can't go out of your way to subvert those guardrails? No, but you would be incredibly foolish to knowingly create a device that will get the attention of the FCC. Similarly, there's nothing stopping you from building a circuit that amplifies the signal the device sends to the antenna. But when you're potentially talking about fines per event, and fines per device, it's wise to make sure you play nice.

If the wi-fi chip you're using has free firmware, where none of it is obfuscated, it's very likely that the limitations are baked directly into the chip, such that there is no register combination that would allow it to be out of compliance. Also, I'm not sure that all chips have transitive FCC licensing, so it might be wise to look into that before releasing the device commercially.

And keep in mind, I'm not even talking about creating accidental radios from poorly designed analog circuits, or unshielded high frequency digital circuits. That's a whole other can of worms.

[nullc]

> if I throw an ESP32 into a product and use wifi, I don’t need further certification

Sounds like nonsense to me, at least from past reading of the regulation. These devices are supposed to be type-accepted-- your entire product is supposed to be certified.

Is the FCC really allowing this? (not that I'm complaining, the FCC certification burden is outrageous).

[milesvp]

Sorry, I was using imprecise (and possibly incorrect language). There are intentional radiators, and unintentional radiators. Using a given chip/SOC/module can greatly reduce the burden of dealing with the FCC for the purposes of intentional radiators. It's why you see products using Espressif's WROVER module have markings similar to

Contains FCC ID: 2AC7Z-ESP32WROVERE.