5 ms·

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

111 points by hcadam 2y ago

nimish 2y ago
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.
- andoma 2y ago
  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.
  - BertoldVdb 2y ago
    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.
    - DannyBee 2y ago
      Nordic supports this explicitly I thought. (Others I agree but they often have crappy stuff anyway)
      - zh3 2y ago
        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/examples_esb.html https://docs.nordicsemi.com/bundle/sdk_nrf5_v17.1.0/page/exa...
- tjoff 2y ago
  Anyone have experience with NimBLE (the mentioned open source BLE implementation https://github.com/apache/mynewt-nimble https://github.com/apache/mynewt-nimble ), how it compares to nordics implementation?
  - DannyBee 2y ago
    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
- bri3d 2y ago
  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).
  - nimish 2y ago
    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.
    - bri3d 2y ago
      > 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.
      - deleted 2y ago
        [deleted]
      - nimish 2y ago
        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.
    - deleted 2y ago
mikewarot 2y ago
It's unfortunate that there's no analog (I/Q) transmission built into the TI chips. They could make fairly useful SDR transceivers otherwise.
- GeorgeTirebiter 2y ago
  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 ?
  - hcadam 2y ago
    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.
    - mikewarot 2y ago
      Ok... we're in agreement.... no analog TX. That's some amazing detective work! Congratulations on pulling it off.
  - trelliscoded 2y ago
    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.
- Neywiny 2y ago
  Maybe there's a misconception, but analog != IQ. Some have IQ interfaces but already digitized and you need to put in the work
- ahartmetz 2y ago
  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.
ElizabethVio52 2y ago
[dead]
atVelocet 2y ago
For SiLabs Si4xxx (e.g., Si4463) chips there is also this wonderful repo: https://github.com/astuder/Inside-EZRadioPRO 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…
- GeorgeTirebiter 2y ago
  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!
  - zh3 2y ago
    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/index.html https://docs.nordicsemi.com/bundle/sdk_nrf5_v17.1.0/page/ind... [1] https://www.zephyrproject.org/ https://www.zephyrproject.org/
ngcc_hk 2y ago
Any these details on LoRa?

111 points by hcadam 2y ago

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.

andoma 2y ago
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.
- BertoldVdb 2y ago
  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.
  - DannyBee 2y ago
    Nordic supports this explicitly I thought. (Others I agree but they often have crappy stuff anyway)
    - zh3 2y ago
      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/examples_esb.html https://docs.nordicsemi.com/bundle/sdk_nrf5_v17.1.0/page/exa...
tjoff 2y ago
Anyone have experience with NimBLE (the mentioned open source BLE implementation https://github.com/apache/mynewt-nimble https://github.com/apache/mynewt-nimble ), how it compares to nordics implementation?
- DannyBee 2y ago
  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
bri3d 2y ago
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).
- nimish 2y ago
  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.
  - bri3d 2y ago
    > 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.
    - deleted 2y ago
      [deleted]
    - nimish 2y ago
      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.
  - deleted 2y ago

mikewarot 2y ago

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

GeorgeTirebiter 2y ago
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 ?
- hcadam 2y ago
  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.
  - mikewarot 2y ago
    Ok... we're in agreement.... no analog TX. That's some amazing detective work! Congratulations on pulling it off.
- trelliscoded 2y ago
  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.
Neywiny 2y ago
Maybe there's a misconception, but analog != IQ. Some have IQ interfaces but already digitized and you need to put in the work
ahartmetz 2y ago
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.

ElizabethVio52 2y ago

[dead]

atVelocet 2y ago

For SiLabs Si4xxx (e.g., Si4463) chips there is also this wonderful repo: https://github.com/astuder/Inside-EZRadioPRO 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…

GeorgeTirebiter 2y ago
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!
- zh3 2y ago
  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/index.html https://docs.nordicsemi.com/bundle/sdk_nrf5_v17.1.0/page/ind... [1] https://www.zephyrproject.org/ https://www.zephyrproject.org/

ngcc_hk 2y ago

Any these details on LoRa?