Beyond BLE: Cracking Open the Black-Box of RF Microcontrollers [video] | Hacker News Reader

Beyond BLE: Cracking Open the Black-Box of RF Microcontrollers [video]

media.ccc.de

111 pointshcadam25 comments

For SiLabs Si4xxx (e.g., Si4463) chips there is also this wonderful repo:

https://github.com/astuder/Inside-EZRadioPRO

There are basically four main OEMs for SubGHz radios (hobby projects): - Analog Devices (ADF7xxx) - SiLabs (Si4xxxx) - Semtech (SX1xxx) - Texas Instruments (CCxxxx)

If i remember correctly the Analog Devices and the Semtech radios share the same internal core (blackfin?). Please correct me if i am wrong. For the Semtech and ADF702x there are firmware patches and/or ROMs available. The most interesting part would be to unlock the internal test mode which some of those chips have…

Which open source stacks work with Infineon CYW43439 (used on Pico w and Pico 2W)? I know about BTstack, but apparently NimBLE is not ported to this chip.

I'm also curious, of all the available BLE chips, which one has the "most sane" development environment? I had the misfortune of using the SiLabs BLE chips, and it seems like the Dev Environment was meant for Web dudes or something -- it seemed very foreign to me, an embedded guy. It was like 5 layers to go from their SDK down to the machine instruction that would set the value of a GPIO pin hi or lo. Confused documentation, spread out over dozens of not-related sections, weird configuration wizards, etc. Now, the Hardware seemed just fine, but gosh, the Dev Environment?

I've heard good things about Nordic's environment, but haven't used it. I also know nothing about TI's or AD's.

Opinions appreciated!

The older Nordic SDK wasn't too bad (once you get over the learning curve). Trying to start a project from scratch is challenging though, so much easier to pick the closest example, get that going and modify from there.

However, they've deprecated the old SDK [0] in favour of Zephyr [1] and quite a number of people struggle with it (check the forums and general internet). I have less experience with Zephyr, but both of them use a lot of python support tools which seem to suffer from versioning amd compatibility problems (even trying to keep a stable platform has been difficult here, what works one time doesn't work a few months later). YMMV.

[0] https://docs.nordicsemi.com/bundle/sdk_nrf5_v17.1.0/page/ind...

[1] https://www.zephyrproject.org/

There are good reasons for depreciating the nrf5 sdk. However, I’m not sure how long the Nordic Semi lead is going to last.

Previously if there was a project that came up that didn’t strictly need BLE, I’d recommend the nrf5 sdk because it was reliable and stable. Now with the new sdk they are encouraging people to write firmware that’s much easier to port to other mcus (with zephyr) and the development experience has much higher cognitive load.

Thats been my experience also. The tooling for Zephyr is pretty lousy, especially configuration. Kconfig hell.

It's unfortunate that there's no analog (I/Q) transmission built into the TI chips. They could make fairly useful SDR transceivers otherwise.

They demo analog (narrowband FM voice) reception in the talk. With all the uncovered control and creative digital to analog tricks, is it really not possible to transmit "analog"? I'm not sure, you might want to watch the talk.

Do you mean getting the IQ samples? On the SiLabs EFR32 chips that's possible and well documented. I've created an on-chip mono FM radio receiver, and working on getting stereo.

I'd recommend the EFR32xG23 if you would like to give it a go.

I would not be at all surprised if some "test mode" allows access to the I/Q signals. Do you have any friends at TI ?

The “CC” in the TI part numbers stands for “ChipCon”, who TI acquired for these wireless products. The CC1100, one of their earliest parts, has a documented but unsupported debug mode which dumps raw quadrature samples out some of the I/O pins. Later parts do not mention such a feature in their documentation, but it’s not proven it was removed.

Author here, it’s totally possible to get IQ samples from the RX chain! Unfortunately, the design of the TX chain is in such a way that it does not work off of IQ DACs, and is more limited in what the silicon can generate.

Ok... we're in agreement.... no analog TX.

That's some amazing detective work! Congratulations on pulling it off.

Maybe there's a misconception, but analog != IQ. Some have IQ interfaces but already digitized and you need to put in the work

Some microcontrollers have much better documented rf subsystems. Onsemi has a well documented RSL15 radio. Nordic has docs and there's an open source ble implementation from apache too.

I don't think you're talking about the same thing as this talk when you discuss "documented."

For example, NimBLE (the Apache BLE implementation for Nordic) interfaces with the radio using a high-level, documented register interface to the PHY. It basically constructs a BLE frame and passes a pointer to it into some registers (which trigger DMA). Then a magic black box modulates and transmits that frame.

This talk goes one level deeper, into the magic black box. These are sometimes traditional fixed-function hardware but usually they are some kind of obscure DSP architecture which is ROM-coded with a patch capability (or just has blob firmware).

No, I mean rf mcus that let you do all the way down to IQ sampling or pulse shaping. It's up to the developer to decide what level you let the hardware handle.

This is how those proprietary rf protocols work for mice and such.

> This is how those proprietary rf protocols work for mice and such.

In my experience these usually use Cypress/TI chips and FSK, rather than going all the way down to IQ.

> No, I mean rf mcus that let you do all the way down to IQ sampling or pulse shaping.

Do Nordic chips let you do this? I've never seen it documented.

If they support aoa and other ultra modern ble features they have to expose the raw IQ samples to a higher layer for dsp.

That's not the same as full control since you have to trigger it using gfsk anyway but there's other MCUs with granular radio control (RSL15 for example) that do allow for direct iq manipulation at the cost of skipping the hardware MAC which apparently everyone buys from CEVA as far as I can tell.

Yup, Rolled my own BLE Peripheral stack on NRF52 relying on nothing but Nordic's docs and the BLE specification. It's not fully feature complete but works well enough for me to communicate with the mcu from my MacBook using l2cap connections.

The people in these talks go quite a bit further than just BLE packet TX/RX (which you can do with the documentation on most chips). In theory this work allows implementing a totally different protocol.

Nordic supports this explicitly I thought. (Others I agree but they often have crappy stuff anyway)

Yes, though sharing BLE with other protocols is challenging (even with first-class citizens like ANT+ there are various caveats). The proprietary protocols are Shockburst/Gazelle [0] which are based of the ancient nrf24 setup.

Having said that, the radio peripheral on the chip is dead simple to drive bare-metal. Create a packet (with the convenience function), put its address in a register and hit the 'send' bit (more or less, glossing over waiting for ready bits here). Receiving is as easy - point to where you want packets to land, go into RX mode and wait for the "packet received" bit to be set.

[0] https://docs.nordicsemi.com/bundle/sdk_nrf5_v17.1.0/page/exa...

Anyone have experience with NimBLE (the mentioned open source BLE implementation https://github.com/apache/mynewt-nimble ), how it compares to nordics implementation?

Me. I've used both heavily. Both are great.

NimBLE is the only sane stack I found that can handle multiple threads and periodic advertising.

I use PA in my machine sensors to avoid having to use high advertising rates on primary channels and still get usable latency from turning the machine off and the dust collection system noticing

Any these details on LoRa?

Reply on news.ycombinator.com