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 19 days 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 18 days 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.
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.
ost-ing 18 days ago [-]
Thats been my experience also. The tooling for Zephyr is pretty lousy, especially configuration. Kconfig hell.
mikewarot 19 days 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.
ahartmetz 18 days 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.
pajko 12 days ago [-]
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.
GeorgeTirebiter 19 days 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 ?
trelliscoded 18 days 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.
hcadam 18 days 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 18 days ago [-]
Ok... we're in agreement.... no analog TX.
That's some amazing detective work! Congratulations on pulling it off.
Neywiny 18 days ago [-]
Maybe there's a misconception, but analog != IQ. Some have IQ interfaces but already digitized and you need to put in the work
nimish 19 days 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.
bri3d 19 days 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 19 days 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 19 days 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.
nimish 18 days 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.
19 days ago [-]
19 days ago [-]
andoma 19 days 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 19 days 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 19 days ago [-]
Nordic supports this explicitly I thought.
(Others I agree but they often have crappy stuff anyway)
zh3 18 days 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.
Anyone have experience with NimBLE (the mentioned open source BLE implementation https://github.com/apache/mynewt-nimble ), how it compares to nordics implementation?
DannyBee 19 days 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
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…
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!
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/
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.
I'd recommend the EFR32xG23 if you would like to give it a go.
That's some amazing detective work! Congratulations on pulling it off.
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).
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.
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.
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...
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