5ADBEEF

I don’t think most have this experience. Zephyr is the future.

Zephyr provides an open source implementation of all layers of the BLE stack. The radios of some devices are documented extensively, Nordic nRF5 devices are probably the best example.

The Bluetooth SIG requires that you qualify your device if you advertise that you use Bluetooth IP, similar to what is required for the cellular space. Do you have to do this if you’re just “Bluetooth compatible?” Maybe not. Whatever the case you have to conduct FCC part 15C testing (intentional radiator).

the average defense job is the exact opposite of fulfilling and meaningful

Be aware, per erratum 9, that you’ll need to include external pull-downs instead of using the internal ones

Anybody notice that the example for their shell is using the Zephyr shell subsystem? Very cool that it's using Zephyr!

anybody doing new BLE products has a 50/50 shot of using Zephyr in current year. I think the real benefit of Zephyr is that the wheel has already been invented, no need to do it yourself

the pi pico is 100% supported in Zephyr. https://github.com/zephyrproject-rtos/zephyr/tree/main/board... Did the author not check the docs? https://docs.zephyrproject.org/latest/boards/raspberrypi/rpi...

Additionally, you aren't intended (for many situations) to use a single "main" Zephyr install, but to include what external modules you need in your project's west.yml. If you have a number of projects sharing the same Zephyr install that's a separate discussion but installing every possible toolchain/HAL is not the only way to do things.

RF dongles almost always are Nordic Semiconductor parts and they use their proprietary (but open) protocol called Enhanced Shockburst. The minimum latency of BLE is 7.5ms (fastest connection interval in the spec) while ESB can be in the 100s of microseconds. Not sure about power savings but latency is better.

https://www.popsci.com/deadly-splinter-antibiotic-resistance...

Zephyr would also be well suited for something like this. Anyone aware of any projects that do something similar with Zephyr?

I am not certain that this provides a lot of benefit. Worth discussion. Feels like most engineers just copy the application circuit nowadays though. https://www.signalintegrityjournal.com/articles/1589-the-myt...

This is what Wirepas is doing with their mesh network. They have a DECT version coming soon

Not an unauthenticated mesh. This will be up user implementation iirc

Best option is PoE and battery back up (if they elect to pull the meter)? I guess they could also cut your cable. Or forget all of that and get a nice pup

the crustier EEs among us have been burned by downloaded symbols. It’s often better to make your own symbols and footprints unless you have a high quality source from the manufacturer. Even then, some symbols are not organized in a logical way. I personally make all symbols/footprints not in the kicad standard library.

Why just accept that time passes?

If you’re into electronics and can sweep aside some crusty EE opinions, the EEvblog forums are quite fun and informative.

I warn you that much of controls is very very boring. PLCs w/ ladder logic in most places. Embedded devs have better devex than controls engineers…

I’ve watched all of the skibidi toilet episodes. It’s really the same as 2000s or 2010s gmod YouTube poop, it just managed to find a larger audience.

Juniors are hyper-online, accustomed to COVID classes etc. Maybe it is methods of training that need to shift.

Yes, this fix was mentioned in IN-142 from Nordic.

Nordic announced a processor w/ Arm + RISC-V cores on the same die. It's already happening!

There is a companion chip, the nRF7002 which supports Wi-Fi. Not integrated into a SoC though but probably way lower power consumption than an ESP. Not sure on the difference in performance between the two competitors Wi-Fi solutions

There is a Zephyr BLE stack that can be used as well as a SoftDevice stack but SoftDevice isn't a huge binary anymore, much more modular to save code space.

The famous APProtect bug was patched in a silicon rev IIRC. Unless you're thinking of another exploit

You don't hear as much about LoRa as other wireless protocols because the use cases are less "sexy," in my opinion. The people who grew excited about LoRa or LoRaWAN are...electric and water metering engineers. Cool stuff, very necessary for the proper function of society, a better + more efficient solution, but kind of boring. The pros/cons of LoRa are apparent when compared to using other bands/protocols. BLE cannot be used over long distance very effectively because it is in the 2.4 GHz band. Cellular products are expensive to certify, complicated, and generally require higher power consumption (although some of our Norwegian brethren have closed that gap quite significantly for IoT applications). LoRa sits in a niche where it has long range, quite low data rate, minimal certification cost, and relatively low power.

Another technology that is just beginning to emerge as a direct competitor to LoRa/LoRaWAN is DECT-NR+. LoRa suffers because it uses a patented keying method and radios can only be produced by Semtech. DECT-NR+ is open and may make a dent in LoRa's market share in the future.

it is the fault of freer money for education and greater expectations for amenities at colleges. higher education should be a measured decision where you literally calculate ROI on the cost of your degree

that's just your subjunctive opinion ;)

praying for Zephyr to succeed

fair point. thankfully gcc will compile c++