4 ms·

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 implem

by 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

by 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