Custom protocol vs. BLE5.2 vs. others

[Siwastaja]

Hi,

I'm fairly newbie to wireless communication and this isn't about RF itself as much, as I'm using pre-certified RF modules (or at least SoCs closely following the example antenna layout).

What I'm looking for is technical discussion of the protocol stack.

My use case is basically a sensor/actuator network. Relaying / mesh, for increased range, is more a "nice-to-have" thing than an absolute must.

I have already developed simple and well functional test cases with my own radio code, bare metal on Nordic Semiconductor nRF52833's RADIO peripheral. The MCU as a whole, and the RADIO peripheral are easy to use.

Now as might be obvious to many who have read my posts, I prefer doing my own solutions over existing libraries and stacks, but OTOH, if I need to connect to the Internet, I will just use existing TCP/IP stack and not write it from scratch, I'm not that stubborn, I'm not a fan of Not Invented Here, either.

Now that I have written some very basic frequency hopping, time windows for communication, etc., I'm starting to wonder how much work is left to actually enable reliable communication. I know I know, in ISM bands nothing is reliable by definition.

Should I be directing my effort into learning the modern BLE specification, Nordic Semi's BLE SoftDevice API, and building my projects on top of this? What do I gain if I do that? Or maybe I should use ZigBee or Thread or something completely different?

I'm thinking that if I need to custom-write a code which detects microwave ovens and times the packets on the silent half-cycle, detects usage patterns of other communication devices (including WiFi) to avoid them, possibly relay messages through multiple nodes, this is already becoming quite a task. I don't need to reinvent the wheel, right?

On the other hand, my own radio code so far has proved to be trivial to develop, works exactly like I expect - at least here in the countryside with just my own WiFi and zero bluetooth devices. Own code is always easy to extend, though. Each new feature feels manageable. But is this becoming too big?

Low power is crucial. Like really low power, a 1000mAh cell should last for years in sleep state, this is the target. So I can't afford advertising a device more than maybe once a second.

Firmware updates over the air is another basic requirement. If I implement it myself, it's again completely trivial.

But I'm afraid how well my simple frequency hopping algorithms cope when presented with a real environment - competiting sensor networks, consumer bluetooth devices, 10-20 WiFis instead of 1... And how it's going to compare to something engineered for two decades. Such scenarios are difficult to test. One could assume BLE handles them as well as humanly possible... But is that true? In other words, are the existing stacks significantly more reliable than simple implementations based on just detecting noise floor with a sweep and then hopping on a few best frequencies?

On the flipside, I also worry that if I start going BLE way, I'm possibly wasting a lot of time trying to figure out the specification, actual APIs, and how to use BLE for varying needs (replicating an example is not enough). Are there generic enough data transfer classes? Is this going to be a mess anyway, or am I worrying for nothing?

Also if I'm later to use 433MHz or whatever band, the BLE obviously goes out of the window, right away. An implementation in my own hands would be easy to adjust to work.

Any comments?

[cgroen]

Listening in here!
Currently running on 868 (CC1310/CC1101) but we are thinking about going the BLE route too, just wonder what we gain by doing so...

[Gribo]

To last 1 year on a 1000mAh cell, your average current should be ~110uA (1000mA / 8760 hours). Assuming TX/RX current of 20mA, You might want to limit advertisements to 1 per few minutes, not 1 per few seconds.