Everything nRF52840
-
@heinzv
what do you mean by full zigbee vs incomplete zigbee then ? :)
a rf transceiver+some PHY settings VS an rf stack/framework. not the same. MySensors, zigbee, ble etc are stacks (software logics with different layers) that can run on different mcus/socs
MySensors used in non-arduino platform? which one? (esp32 idf is included in arduino, and you can add arduino module in esp-idf but that's all.. still arduino)
For the moment there are still conflicts in nrf5 hw resources for ble+mysensors.
d00616 started some work for nrf5 support, but it's not finished yet, and as usual team members do this in their very limited spare time. It's not in plan of MySensors (others members can correct me) to switch to a different stack
Sorry to not have a better answer, but it's hard to say -
@heinzv
what do you mean by full zigbee vs incomplete zigbee then ? :)
a rf transceiver+some PHY settings VS an rf stack/framework. not the same. MySensors, zigbee, ble etc are stacks (software logics with different layers) that can run on different mcus/socs
MySensors used in non-arduino platform? which one? (esp32 idf is included in arduino, and you can add arduino module in esp-idf but that's all.. still arduino)
For the moment there are still conflicts in nrf5 hw resources for ble+mysensors.
d00616 started some work for nrf5 support, but it's not finished yet, and as usual team members do this in their very limited spare time. It's not in plan of MySensors (others members can correct me) to switch to a different stack
Sorry to not have a better answer, but it's hard to say@scalz "Full Zigbee Stack": Maybe my phrasing was not ideal, I wanted to say: if we use not only the IEEE802.15.4 Standard but also the complete stack with ZigBee.
I know that mySensors is done by (most likely a few) people in their spare time and adding a new HW stack is extra work which is not just initial work but also remaining maintenance effort. On the other hand, isn't that also the intention of a community project to discussing new possibilities and significant improvement potentials and having experts and enganged people providing pros, cons, inpust (thus also your inputs are important :-)
-
@heinzv
oki ;)
that's what I meant. your pic shows it. Mysensors is already "full" stack with different layers, and afaik it's not in plan to replace its PHY+MAC layers by 15.4 . This would imply lot of work too and most of features are already present except slotted time rf which needs quite some work..
And changing these layers won't solve nrf5 resources, softdevice accessibility in arduino.
The others solutions- d00616 work for mysensors : help to fix issues and finish the code
- fork mysensors to another non arduino platform supporting these stacks -> lot of work non supported by mysensors team (and still redundant, worth the effort? as you could directly use your favorite stack)
Like you I tried a lot of different roads too (I'm not new on the bleeding edge like I said)..full of dilemmas, no perfect solution, still working on it!
-
@heinzv
oki ;)
that's what I meant. your pic shows it. Mysensors is already "full" stack with different layers, and afaik it's not in plan to replace its PHY+MAC layers by 15.4 . This would imply lot of work too and most of features are already present except slotted time rf which needs quite some work..
And changing these layers won't solve nrf5 resources, softdevice accessibility in arduino.
The others solutions- d00616 work for mysensors : help to fix issues and finish the code
- fork mysensors to another non arduino platform supporting these stacks -> lot of work non supported by mysensors team (and still redundant, worth the effort? as you could directly use your favorite stack)
Like you I tried a lot of different roads too (I'm not new on the bleeding edge like I said)..full of dilemmas, no perfect solution, still working on it!
@scalz just let me/us know or please share your findings.
I'm also exploring different roads for different cases. Not just MCU, radios, sensors, displays (TFT, LCD, ePaper) etc.
So far I've got some overview on the possibilities and limitations.
I'm quite satsified with the ESP family (8266/8285 and ESP32), but I see also the limitations of the Atmega families as well as the old STM32 families.
I like the LoRa radio as best option for long range and energy efficiency use cases, but see the potential of BLE 5.0 and ZigBee but have not yet experience with it and I'm at the beginning of the nRF5x learning, but it looks at least promising.
Any other option on the radar? ... I'll follow your inputs/discussions and of course observe the market as well by myself ... -
Although it's hard to predict the future, I'd wager that Bluetooth 5 will greatly overshadow 802.15.4 when it comes to wireless sensors. Why do I say that? Because Bluetooth 5 is already included in some of the leading phones: https://www.gizbot.com/mobile/features/10-latest-smartphones-which-come-with-bluetooth-5-0-to-buy-in-inida-2018-047304.html
For instance, I have a Samsung Galaxy S8 phone, and up until just now I wasn't even aware that it actually contains Bluetooth 5. Does that mean my phone can communicate with a Nordic nRF52840 using the 125kbps long range settings? I don't know, but I'm now curious to find out. Anyone know?
According to Nordic, the 500kbps mode will have twice the range of the 1mbps datarate, and the 125kbps datarate will have 4x the range of the 1mbps datarate:
I guess they're comparing it to the 1mbps proprietary mode of the same radio? Part of the reason for the 2x or 4x range increase can be attributed to the coding gain, which, AFAIK, the 250kbps 802.15.4 mode doesn't have. Unfortunately, the article doesn't say what kind of range increase to expect from the 802.15.4 mode, but I'm guessing (?) it will not be a lot. Maybe, what, 10% or 20% better? Any guesses?But range of the 125kbps mode should be even more impressive if comparing against the nRF24L01, which has a link budget of 86dbm:
https://www.eetimes.com/document.asp?doc_id=1276396&page_number=2
as compared to 111dbm for the 125kbps mode of the nRF52840 (as quoted by the same Nordic blog as above). Part of that is from the greater Tx power and receive sensitivity of the nRF52840. In the end, all those details get reduced to a single link budget number, which is apparently how a proper comparison is made.[Edit: https://devzone.nordicsemi.com/b/blog/posts/taking-a-deeper-dive-into-bluetooth-5]
-
@NeverDie I also own a Galaxy S8 and interested in that study.
I especially like the idea to have a very energy efficient MCU which contains already a very energy efficient radio. That saves a lot of energy in total, soldering, wiring, complexity of multi chip handling (sleep, wake, sync) and saves also space (makes PCB's and devices smaller).
If the range is sufficent and we get the development environment satisfying established, what else are we missing?
Price and MCU performance is also ok, Flash and RAM is ok. Availability of internal peripheral and sleep/wakeup behaviour is ok. The only small drawback I've seen is that there is no internal EEPROM.
Once I have my dongles and or breakout PCB's (for the "inconvinient" 1.1mm pinouts and soldering pads below the module), I'll start with the sensor communication, radio transmission and ePaper display. If the range is satisfying with BLE then I also need to decide how I integrate with my controller OpenHAB (a mySensors binding if we get that added, ZigBee, MQTT which a MQTT gateway ...). Would be interested what your plans for integration are (which is also releated to the comment from @scalz) -
about indoor range, if you didn't try the TI range estimator excel sheet link, I extracted list of absorption material, if it interests anyone
about using multi protocols in same band, a while ago I modified a graph I found on internet, for comparing wifi less crowded channels VS nrf24/52 channels in MySensors.
Note: zigbee also uses same channels, some implementation can do frequency hopping too, making harder to predict PER packet error rate etc. If I remember Zigbee channel 1 = nrf24/52 channel5. Last zigbee channel being nrf24/52 channel 80.
maybe I'll try to make an article about all this rf stuff (missing time atm).
Still good to know, what possible issues with coexistence of multiple protocols used in same band without good device placement or "time slots" for switching protocols and avoiding "potential collisions". But this would need same synced software for all devices.
I would say, I can be wrong, it's not a great idea to use too many protocols in same band without these precautions, can get messy in air. (not mentioned neigboors playing with different endproducts in same band, antenna detuning, efficiency due to hw designs, ->shifting center freq, bandwitdth etc..). -
Sadly, at least as of June 2018, none of the smartphones supported the long range capabilities of Bluetooth 5, only just the 2mbps Bluetooth 5 capability. :(
Bluetooth 5 features in smartphones
Bluetooth 5 includes capabilities for faster speed and longer range. It’s fairer to say, however, that developers must choose between speed or range.
Read more: The Bluetooth 5 trade-off
In smartphones, however, you don’t even have that choice. To date none of the smartphones support the Coded PHY that extends the range of Bluetooth 5. Instead you can have the 2mbps speed. For most applications this is likely to be fine. Most consumers are looking for ways to connect to devices that are within a few feet of them. The longer-range features are more useful for lower bandwidth applications such as sensor networks.
https://blog.nordicsemi.com/getconnected/bluetooth-5-in-smartphonesI don't know if that's an android limitation which might improve, or whether the radio chips in the phones are missing the required hardware to do coded 125kbps Bluetooth 5 long range. I can understand that there's a chicken and egg dilemma holding things back, and that right now there's probably not any reason for phone manufacturers to give long range priority in their phones, since at present there's very few, if any, devices for the phones to connect with using Bluetooth 5 long range.
Nonetheless, this post has links to demo code for long-range bluetooth on the Nordic: https://devzone.nordicsemi.com/f/nordic-q-a/38267/long-range/148485#148485 :)
-
Sadly, at least as of June 2018, none of the smartphones supported the long range capabilities of Bluetooth 5, only just the 2mbps Bluetooth 5 capability. :(
Bluetooth 5 features in smartphones
Bluetooth 5 includes capabilities for faster speed and longer range. It’s fairer to say, however, that developers must choose between speed or range.
Read more: The Bluetooth 5 trade-off
In smartphones, however, you don’t even have that choice. To date none of the smartphones support the Coded PHY that extends the range of Bluetooth 5. Instead you can have the 2mbps speed. For most applications this is likely to be fine. Most consumers are looking for ways to connect to devices that are within a few feet of them. The longer-range features are more useful for lower bandwidth applications such as sensor networks.
https://blog.nordicsemi.com/getconnected/bluetooth-5-in-smartphonesI don't know if that's an android limitation which might improve, or whether the radio chips in the phones are missing the required hardware to do coded 125kbps Bluetooth 5 long range. I can understand that there's a chicken and egg dilemma holding things back, and that right now there's probably not any reason for phone manufacturers to give long range priority in their phones, since at present there's very few, if any, devices for the phones to connect with using Bluetooth 5 long range.
Nonetheless, this post has links to demo code for long-range bluetooth on the Nordic: https://devzone.nordicsemi.com/f/nordic-q-a/38267/long-range/148485#148485 :)
@neverdie I read an article regarding BLE 5.0, ANdroid and the Samsung Galaxy S8 HW (the used SoC from Qualcom/Snapdragon or from Samsung varying on the model/region).
The article is in German but it says: BLE 5.0 was introduced with Android 8.0 but the S8 HW does only support the 2x data rate (2MBps) but not the 4x range. So it seem that it is a HW limitation similar to the nRF52832 in comparison to the nRF52840. Only the 840 support both, the 832 only the higher data rate. Strange, that this is so bound to the HW and thus so limiting and unflexible. -
It's worth noting that Texas Instruments has a $29 launchpad which demonstrates its flavor of Bluetooth Long Range: http://www.ti.com/tool/launchxl-cc2640r2
It uses a Cortex M3 rather than an M4.
I think it might be worth looking into to see whether it's any easier to use than SES.Cypress Semiconductor has its version, with kits starting at $49.
http://www.cypress.com/products/ble-bluetoothLikewise, silicon labs has its version, but the starter kit is $99: https://www.silabs.com/support/getting-started/bluetooth/bluetooth-low-energy
https://www.silabs.com/products/wireless/learning-center/bluetooth/bluetooth-5?gclid=EAIaIQobChMIodewu8PR3QIVXrXACh2IZwE5EAAYASAAEgI3OfD_BwEAre there other manufacturers worth noting?
I wish at least one of them had an official video course. That would speed up the learning process. I think Nordic has made the mistake of not making it easier to learn how to develop for their product. It wouldn't be hard for them to do a high quality video tutorial, and yet it appears they've done just the bare minimum. I have some hope that TI may be better in this regard, but I haven't yet looked more closely to say for sure.
-
@NeverDie I think you need to hold it, but it looks there is "coded" holes/slots for helping and correct positioning.
@monte
@monte said in Everything nRF52840:haven't you noticed that mysensors' community which is represented mostly by this forum has become more than just an arduino library?
Hmm, I haven't.. so what's more? Has MySensors been forked to another platform?
@monte said in Everything nRF52840:
People share on this forum many projects that has only mediate connection to mysensors, if any. And many of users of the library in it's current form have outgrowing some of it's limitations, so naturally they will try to find a solution to overcome them and then share with others on this forum.
I'm not the last on bleeding edge, but I didn't notice many mediate connections..Which limitations have been hacked? maybe on the forum, not same on git I think. Thx to PR contributors. But apart from mysensors team, especially one very active contributor that we can thx ;) it's rather rare.
@monte said in Everything nRF52840:
I don't see nothing wrong for mysensors platform to evolve and adopt modern standards and/or protocols. And even if 15.4 is not suitable or just a replacement of mysensors protocol
Not in scope and not supported by mysensors team to switch to a standard, as mysensors is still about its own stack. It's like if you wanted to mix zigbee&mysensors logics (doesn't make sense). So 15.4 is a replacement. Maybe read about it. I'm telling this because I played and playing with 15.4+another mcu, and comparing stacks.. whether switching stack or not. If not, what could be improved, logics to add to mysensors etc.
@monte said in Everything nRF52840:
I think there are people here that will find it useful to read about it. Correct me if I'm wrong but there is no rule against discussing other protocols than mysensors on this forum.
you're right. no rule on this, free to talk. But I preferred to be precise for newcomers who may get confused when reading about nrf52840 in mysensors, that there is no support from team for others stacks, and non-arduino.
Lot of "noobs" don't know what means a rf stack exactly, what logics inside etc, they simply want to use MySensors because it's easy to use, especially when non former dev. That's what would expect someone discovering nrf52840 is supported in MySensors. So this gets completely confusing, external toolchains and using others rf stacks etc.. might end in hundreds of posts with just a few mysensors relevant infos (good luck for newcomers)wasting my time, I won't disturbe your experiments anymore ;)
Good luck and feel free to improve MySensors of course!@scalz said in Everything nRF52840:
Hmm, I haven't.. so what's more? Has MySensors been forked to another platform?
I mean people discuss all things here on forum that are in common interest including 3d printers, CNC's and work place arrangement. No wonder they will discuss other wireless protocols and platforms as well.
@scalz said in Everything nRF52840:
Lot of "noobs" don't know what means a rf stack exactly, what logics inside etc, they simply want to use MySensors because it's easy to use, especially when non former dev. That's what would expect someone discovering nrf52840 is supported in MySensors. So this gets completely confusing, external toolchains and using others rf stacks etc.. might end in hundreds of posts with just a few mysensors relevant infos (good luck for newcomers)
Those newcomers will just pass by these threads and find the answer on their topic. And then when they will learn (as many of us did thanks to this forum) they will come back to threads like this and get useful information for their further education. And those noobs, you mentioned who just wants to make "smart socket" or humidity sensor probably won't even come to the forum section as they have plenty information in tutorials on the main page. Why do you consider newcomers so dumb?
-
Guys, let's move on from this tempest in a teapot. The way I see it: at this point in history what we individually want or don't want won't make any difference to the ultimate outcome in the big picture, because there are now much larger forces at work. Our best bet is to help each other identify the best trend to ride. If that's mysensors, then great, but if not, let's try to figure out just exactly what else might reasonably win so that we can avoid dead-ends and hopefully ride the trends with the wind at our backs. :)
To my mind, the following have traction (in no particular order)
- LoRa (because it's simple and it just plain works)
- Bluetooth 5 Long Range (because smart phones, eventually, will make it so) with an integrated ARM MCU. That said, bluetooth per se has always seemed cumbersome to me, and I never really liked it. I'd probably be happier using a barebones version of it.
- MQTT
Maybe Thread will happen or maybe it won't. I'm not sure what will catalyze it, so I'd have to see meaningful uptake before I bet on Thread.
-
Guys, let's move on from this tempest in a teapot. The way I see it: at this point in history what we individually want or don't want won't make any difference to the ultimate outcome in the big picture, because there are now much larger forces at work. Our best bet is to help each other identify the best trend to ride. If that's mysensors, then great, but if not, let's try to figure out just exactly what else might reasonably win so that we can avoid dead-ends and hopefully ride the trends with the wind at our backs. :)
To my mind, the following have traction (in no particular order)
- LoRa (because it's simple and it just plain works)
- Bluetooth 5 Long Range (because smart phones, eventually, will make it so) with an integrated ARM MCU. That said, bluetooth per se has always seemed cumbersome to me, and I never really liked it. I'd probably be happier using a barebones version of it.
- MQTT
Maybe Thread will happen or maybe it won't. I'm not sure what will catalyze it, so I'd have to see meaningful uptake before I bet on Thread.
@neverdie I have no problem with this discussion (actually I like it :-). We're just lookig for an alternative to the "aged" and "limited" Atmega 328p platform. And at the end, I can/should also benefit for the MySesnors project/community.
At least, I'll do it anyway but having some other experts opinins is always helpful.I have taken a look at the TI CC1352P which supports multiprotocols UHF (868) and BLE 5 (ZigBee, Threads etc.). It has similar features as the nRF52.
Has less Flash/RAM but still sufficient.So still to investigate BLE 5/ZigBee long range or LoRa + MQTT and Nordic nRF52 or TI CCxxx :-)
-
@neverdie I have no problem with this discussion (actually I like it :-). We're just lookig for an alternative to the "aged" and "limited" Atmega 328p platform. And at the end, I can/should also benefit for the MySesnors project/community.
At least, I'll do it anyway but having some other experts opinins is always helpful.I have taken a look at the TI CC1352P which supports multiprotocols UHF (868) and BLE 5 (ZigBee, Threads etc.). It has similar features as the nRF52.
Has less Flash/RAM but still sufficient.So still to investigate BLE 5/ZigBee long range or LoRa + MQTT and Nordic nRF52 or TI CCxxx :-)
@heinzv said in Everything nRF52840:
I have taken a look at the TI CC1352P which supports multiprotocols UHF (868) and BLE 5 (ZigBee, Threads etc.). It has similar features as the nRF52.
Wow, almost everything but the kitchen sink!
The CC1352P device is a multiprotocol Sub-1 and 2.4-GHz wireless MCU targeting Wireless M-Bus, IEEE 802.15.4g, IPv6-enabled smart objects (6LoWPAN), Thread, Zigbee®, KNX RF, Wi-SUN®, Bluetooth® 5 low energy, and proprietary systems. The device contains a +20-dBm integrated high-power amplifier with best-in-class efficiency for long-range applications.
http://www.ti.com/product/CC1352P/descriptionImpressive. What will TI make next? A software defined radio? :laughing:
-
@NeverDie that's what I'm going to use for my ha. I have TI launchpad and sensortag for testing, already played a bit with previous cc1350 and their framework. I have designed a few different cc1352x rf modules (shielded), childboard for sensors, pcb or ceramic antennas footprints for nodes etc..I'm just waiting to receive pcbs, vna and I'll tune. when enclosed too. for compliance. Lot of fun coming
-
Interesting! I watched this video and learned that it lets you do both Bluetooth and sub-gigahertz simultaneously. :)
https://www.youtube.com/watch?v=xplG21wJsPkI like it. :)
-
@NeverDie that's what I'm going to use for my ha. I have TI launchpad and sensortag for testing, already played a bit with previous cc1350 and their framework. I have designed a few different cc1352x rf modules (shielded), childboard for sensors, pcb or ceramic antennas footprints for nodes etc..I'm just waiting to receive pcbs, vna and I'll tune. when enclosed too. for compliance. Lot of fun coming
@scalz So that was a good hint :-) It would be nice if you would share your PCB's and and where you ordered it and I hope also your code! I have not yet seen many boards (good layout and price) with the CC1352P/R but maybe you can help us here?
Of course I mean beside the TI Lunchpad for develoment.@NeverDie what do you think? Finally we might come closer :-)
-
@scalz So that was a good hint :-) It would be nice if you would share your PCB's and and where you ordered it and I hope also your code! I have not yet seen many boards (good layout and price) with the CC1352P/R but maybe you can help us here?
Of course I mean beside the TI Lunchpad for develoment.@NeverDie what do you think? Finally we might come closer :-)
@heinzv said in Everything nRF52840:
what do you think?
I've pretty much said what's on my mind. I just want to make sure I'm taking the easiest/fastest path possible for getting projects done. IMHO, Nordic would benefit from a more friendly API (more like Arduino or MBED). Nordic's code is largely undocumented in-line. Instead, virtually all the documentation is in Wiki's or the datasheet. It's just not geared toward quick learning, although once you learn something it does seem easy in retrospect.
Therefore, I think TI is worth a closer look. If TI is easier than SES/Nordic, or at least has better learning materials, then I'd probably switch to TI, even though I would sorely miss Nordic's Programmable Peripheral Interface (PPI). As far as I know, PPI is not a part of ARM, and only Nordic has a it (?).
Also, having a wireless bootloader that works and is easy to use would be a real bonus. I'd much prefer to wirelessly upload sketches. Does TI have that? Anyone know?
-
@heinzv said in Everything nRF52840:
what do you think?
I've pretty much said what's on my mind. I just want to make sure I'm taking the easiest/fastest path possible for getting projects done. IMHO, Nordic would benefit from a more friendly API (more like Arduino or MBED). Nordic's code is largely undocumented in-line. Instead, virtually all the documentation is in Wiki's or the datasheet. It's just not geared toward quick learning, although once you learn something it does seem easy in retrospect.
Therefore, I think TI is worth a closer look. If TI is easier than SES/Nordic, or at least has better learning materials, then I'd probably switch to TI, even though I would sorely miss Nordic's Programmable Peripheral Interface (PPI). As far as I know, PPI is not a part of ARM, and only Nordic has a it (?).
Also, having a wireless bootloader that works and is easy to use would be a real bonus. I'd much prefer to wirelessly upload sketches. Does TI have that? Anyone know?
@neverdie said in Everything nRF52840:
Also, having a wireless bootloader that works and is easy to use would be a real bonus. I'd much prefer to wirelessly upload sketches. Does TI have that?
Answering my own question, it would appear the answer is yes:
Supports Over-the-Air Upgrade (OTA)
http://www.ti.com/product/CC1352P/descriptionand it appears to be true for the CC2642R2 launchpad also:
http://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_1_30_00_25/docs/blestack/ble_sw_dev_guide/html/oad/oad.html:) :)
