While it's not hard to find a 100% somewhere, they've become much less common for mechanical keyboards. I just checked the most recent two dozen keyboard releases on drop. Not a single 100 (or larger) in the lot. Mostly TKL, with some 60s, a couple 75s, and a plank kit.

If you don't want just any 100%, and instead want certain less common key switches or a specific theme or other less common features, it can be hard to find a 100% that has them.

The model F AT, which immediately preceded the model M, had control next to A. So did the model F XT before it. I think the case can be made that the traditional position for control on a computer keyboard was on the home row and capslock was on the bottom.

While key codes can be remapped, it's pretty much impossible to get the correct keycaps to swap control and capslock. The ellipse model F is one of the only ones I know of.

The goal would be to make the leaders care about security issues in the first place.

Right now, they can choose to spend less on engineering and then give the money saved to themselves to buy a bigger super yacht. The consequences of only using the cheapest possible labor and cutting every possible corner is that their routers get hacked easily. But this doesn't hurt the CEO in any way. They keep their super yacht. So why shouldn't they do it?

I've designed many devices that are like this. Bluetooth especially is quite cheap now and it often comes with hardware chosen for other reasons. It wouldn't save any money to remove it. And if there's no money to be saved, there's no option to do it.

I'm at a trade show right now where we've built a device, functioning prototypes at this point, with an unused BT interface. It's got a cell modem, which was intentional and is used. And there's wifi, which isn't really an intended user facing product feature but was very desirable for the development of the product. And there's bluetooth because it comes with the wifi module. I actually went to the trouble to lean down the system and the custom kernel config doesn't include bluetooth support. I imagine most engineers wouldn't bother with that. But the hardware is there. Antenna is even connected because it's the same port as the primary wifi antenna.

To me, the difference is that the ref doesn't know to the inch where the line is when he spots the ball. So he doesn't know which team he's giving it to. When they measure they know who will get it, but the chains are a very accurate and objective device. The chain crew has no power to influence the decision.

We understand that there's no way the ref can tell where the ball was to the inch when the runner went down or forward progress stopped. So really, it's "too close to call" and we'll just flip a coin to decide the outcome. If we let the ref look at flag on the side of the field and directly announce if the yardage was made, it might not be any less "accurate" than the current system.

But to me at least, there is very big difference between, "too close to know for sure, flip a coin," and "too close to know for sure, the ref arbitrarily picks a team to win."

It's all for speed. There's nothing in the press release about it making better calls. The only advantage described is that it can measure 10 yards faster than a chain crew can.

If anything, there is less show, since there is no chain crew to bring up and they won't have that close up shot of the ball and the stick, where we see if they made 1st down or not, that often comes after the measurement. And the 30 seconds of waiting they can fill with ad talk but the audience doesn't tune out since a critical call will be announced momentarily.

Now the offense will know they didn't make before they even get back to area the ball was spot at and will go directly off the field.

You mean like command 0x0003 in Analog Devices BLE controller? https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fanalog-devices-msdk.gi...

That's a write memory command. They gave it the wrong name. Must be part of a backdoor, being so weird and hidden with the wrong name. You should go write a click-bait article on it full of your made up crap.

And TI's 0xFC0A command is a Non-Volatile write. That means to flash.

If you had any experience actually using HCI commands or writing a BLE host, you'd know all BLE controllers have commands like this.

You aren't nearly as knowledgeable as you think you are. I doubt you've ever programmed any microcontroller on your own outside of a class room. Maybe, if you thought about what those with experience said instead of attacking them for not parroting your fantasy, you would learn something.

While this is entirely true, it's also true for most or all other BT devices. I've developed products with Nordic and ST chips that have BLE, in addition to Espressif, and both those companies' products also ship the BLE controller as a binary only component of the software stack. They are actually more obfuscated than Espressif's binary code. ST's is fully encrypted so you can't even disassemble it. Espressif's isn't encrypted and even has an unobfuscated symbol table in the library.

I'm not aware of any device on the market with a fully open source BLE controller.

The NimBLE project does have an open source controller, in addition to a host which is the part of NimBLE Espressif uses, but don't know of a chip on the market that uses NimBLE's controller.

What commands are so weird?
How about this one: 0xFC0A Write NVDS Parameter
Or maybe: 0xFC12 Read memory info

Here's a list of TI's CC13x2 Vendor Specific Commands: https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fsoftware-dl.ti.com%2Fsim...
TI has better documentation than Espressif.

And in that list we see 0xFE82 UTIL_NV_Write and 0xFE87 UTIL_GetMemStats

I fail to see what is so strange about these vendor specific HCI commands. TI has some of the same ones in their controller.

That's not true. I've actually developed products that use ESP32s. I've even done some reverse engineering on those binary blobs to implement RF coexistence between BLE and another RF system, since none of the documented APIs support any of the necessary features.

FreeRTOS is open source and part of the code included in ESP-IDF. The controller is a task that runs under FreeRTOS. Though I think there is a mode where one dedicates a CPU core to the controller, on those ESP32 devices with two cores, and FreeRTOS doesn't manage the controller.

Depending on the ESP32 device, the controller code is either in the mask ROM and/or as a binary library file shipped with ESP-IDF. The older ESP32 appears to have more in the ROM while the newer chips like the ESP32-C6 have less ROM and use more libraries.

There's a performance issue with code in flash memory (which a library compiled into the FW would be), since the ESP doesn't have built in flash on the processor's data bus. It's an external SPI flash chip in all cases, which means possible long latencies when a cache miss causes the flash controller to need to read a block over SPI. Not something a timing critical part of the BLE controller can tolerate. The way around this is to copy the code that can't tolerate flash cache misses from flash into RAM, but there is very little RAM, especially on the OG ESP32. So they add ROM that doesn't have a cache miss issues to hold some of the code. ROM is much cheaper than RAM in a microcontroller.

No, bluedroid or nimble run as a task under the open source FreeRTOS kernel. They talk to the binary blob using a virtual HCI interface. It's not even a binary blob. They ship .a libraries that don't even have symbols stripped for the non-open-source code.

The HCI spec includes an OGF for vendor specific commands, 0x3f, which is what Espressif has used. I fail to see what is strange about vendor specific commands using an opcode set aside in the spec for purpose of adding said commands.

If the controller has some kind of RF triggered backdoor, there would be zero reason to create an HCI command to implement it. The controller code would just do the secret thing when triggered. You wouldn't add a customer facing command called "TriggerSecretBackdoor", which has no purpose other than to let customers activate the backdoor, if you wanted to add a backdoor that was secret from your customers.

No, the host won't do that. Unless the person who wrote it has chosen to do that. What you're missing is that the host is entirely open source. ESP-IDF has two choices, Bluedroid or NimBLE, neither of which is written by Espressif. When you make something with an esp32, you compile it from source.

It's certainly possible for the binary BLE controller to do things on its own. But the controller receives HCI commands from the host. That's what HCI stands for, host controller interface.

The host has full source. It's not even written by Espressif. You can use bluedroid or nimble.

So what would be the point of adding commands to let the host tell the controller to do things as part of a backdoor hidden in the controller? The controller doesn't use the HCI commands to do things. It acts on them when the host tells it to.

And if you actually know how to take a train across the Alps and give an answer, your answer will be down voted, because the rabid group-think echo box insists that one must buy a plane ticket to Rome and nothing else may be mentioned.

And think, those snowflakes in the Alps compute all those angles instantly! How long would it take a super computer to generate all those angles? Snowflake Supremancy!!