@neverdie thanks for the info, I appreciate your effort and investigations. I'll use my gateway and the sensor nodes at least in 1,5m height from the ground.
Today I got my nrF52832 and also the nRF52840. The E73..C modules are tiny (around 11x16mm). I can't use it without a breakout board. CDBYTE promised me to send me at least reference PCB design which I can then order from any PCB company.

The Skylab moduls are promising, but I see some deficiencies: No pinout, less pins (don't know what was skiped), no 32kHz low power quart for sleep timer ... I have ordered some other modules ... lets see, so far I can't test a lot without the carrier PCB's.
Then I join you with testing (range/transmisson test, sensor readout, battery measurement, ePaper ...)

I seem to be getting noticeably better coverage when receiving with a BT840F than with an nRF52840-DK. That's a bit surprising, as the ground plane is smaller. The are several possible explanations, but I'm guessing the metal can around the radio, which the BT840F has but the nRF52840-DK lacks, probably helps reduce the effective noise floor and thereby improve the S/N ratio. So, if you're picking a module, you may want to pick a module which has that. Most of them don't, but there are a few that do.

So, because of ease of use and that I'm already started with it, I'm going to stick with mbed a bit longer. I have run across one inconvenient bug relating to send serial communications, but I've reported it, and I've devised a workaround to it until it gets fixed.

Meanwhile, with all the above tweaks, I'm getting pretty good home coverage with just a single gateway mounted centrally on the second floor. It's not yet at LoRa's near perfect transmission/reception for a every conceivable nook and cranny in a home environment, but I suspect it may approach that once the amplified modules becomes available. And that's all transmitting at 1mbps, without the benefit of BLE Long Range which it is capable of doing.

I tried to get started with eclipse, and I immediately got lost. I just couldn't find a good tutorial for its C++ IDE. Segger looks as though it may be simpler.

In order to be able to run the 802.15.4 demo code, which I refer to above, I need to be able to use an IDE that can utilize the Nordic SDK. I'm not sure that mbed can do that. So, unless someone knows of anything simpler, maybe segger embedded studio is it.

It's clear from this that all the Nordic SDK examples directly support SES, because there are preconfigured files within the Nordic SDK for building each example on Segger Embedded Studio. I don't see the same for mbed.

Also, as an aside, it's worth noting that the SDK's after 12.3 no longer support the nRF51. The current nordic SDK is version 15.2. Make of that what you will.

@neverdie I've read about this standard after reading nrf52 page on nordic's site. Please keep posting if it is not difficult for you. I think some time in the future many of current members of mysensors community will look at nrf51/52 MCU's as a replacement and further development of the platform. Seeing someone like you digging deep into the cause will encourage others.

@monte I don't know what to think about this, but just in case, to avoid confusion for newcomers, you can't really use MySensors AND 802.15.4 stacks. it would be redundant. these are two different projects with same goals: providing a RF stack with their own logic (state machine). I mean it's a choice to make : using MySensors or a standard like 15.4 (zigbee etc)

@scalz , If it's an either/or choice, why would anyone not pick 802.15.4? It's a rock solid IEEE standard that has been thoroughly vetted because it has been used for a long time already. Especially if the hardware itself directly supports it... it has intrinsic efficiencies.

The only reason I can see for not picking it would be the difference in transmit rate. At least on this chip, 802.15.4 won't be doing 1mbps or 2mbps, but only 250kbps. So, there is an argument for using mysensors at those higher transmit rates, and perhaps switching to 802.15.4 at the lower rate. Also, there would still be a need for something to manage that.

@NeverDie
of course I'm not saying to not use 15.4. I just meant it's redundant with MySensors.
It's just like if you were on a controller forum, says openhab, and were doing ads/howtos about another controller e.g. domoticz. It's free to talk about this, but still a bit off MySensors topic.
MySensors is an arduino library. That's the big difference with using others more "technical" frameworks/ide..

So it's more than just a bitrate question (a bit overhead to switch bitrates the way you said, especially with 2.4g, maybe you would gain some range but not that much indoor, depends on the wall absorption which can be huge for this band, see excel sheet..)

others stack (15.4 etc) + Arduino. Not complete core for all mcus. Not as complete as MySensors with all connectors. Often code are old. More technical framework than MySensors. Less easy for non-programmer/noob

others stacks + others non-Arduino toolchains. The most technical from a newbie point of view for coding (you need to know C in a better way than using Arduino + examples). But in this case, you get better mcu support for using features.

The code size generated by SES for a "hello world" is 11KB, versus more like 430KB for mbed, so, I suppose, yet another reason to switchover to SES. And that's 11KB non-optimized. If I turn on the optimized settings, it should be smaller.

@scalz haven't you noticed that mysensors' community which is represented mostly by this forum has become more than just an arduino library? 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 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 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.

It's not clear to me whether you need to hold it against the module while doing the programming, or whether some of the pins somehow grab on to the pcb so that you don't have manually hold it up against the board while doing the programming.

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.

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.

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 I think you're right to some extent if the full Zigbee stack is used.
On the othe hand, my understanding was, that mysensors provides more than an RF protocol and it supports already more than one protocol (nRF24, RFM60, RFM95/LoRa) and also partially other MCU's not just the default Arduino's e.g. ESP32 - but not for battery powered nodes. It also support a couple of sensors, voltage etc.
For battery powered sensors, I have only seen only full support for the Atmega 328p and that is for me a big limitation, as it has a couple of HW limitations such as Flash/RAM etc. and I got stuck as I want to use battery powered sensors with a low power display like ePaper.
Looking for alternatives brought up the discussion on MCU alternatives which are very engergy efficient and dont have that limitations. The nRF5 is in my eyes a good alternative with either the bluetooth, ZigBee protocoll or even if both do not provide the required range, I would just use them with a RFM95 LoRa module (why not?) it will then just replace the MCU and not the radio.
The mainy question is still open: Will there be a "full" mySensors project support for another MCU like the nRF5 or will it become another project (ZigBee, Bluetooth etc.).

@NeverDie In any case, I appreciate the work done by you, because I see the nRF5 currentyl as the most promising platform for low engergy sensor nodes. I also like the ESP32 and will continue using them, but they are complementary.
BTW: I have ordered 5 dongles via Mouser.at at (10€) with no shipping cost (above 50€, thus the 5 x 10€ order).
I'll also get my nrf52832 min Breakout-PCB's soon (https://www.openhardware.io/view/586/E73-2G4M04S-Breakout)

@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!

@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 ...

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.

@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-smartphones

I 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.

@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.

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.

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.

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.

@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 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.

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 I have ordered the Launchpad LAUNCHXL-CC1352P1 from Mouser.at and registered at TI and downloaded all SDK's and the IDE(s).
Now I need plenty of time to test my nRF52832, nRF52840 (breakout/USB dongles) as well as the TI CC1352P ...

I like Mouser, although here it may in this instance be less expensive to order from TI directly.

The main downside at the moment is that both the CC1352P and the CC2640 are so new that there are not as yet any inexpensive modules to use on projects, and I doubt I would be good at DIY reflowing these chips onto PCBs. So, I'm not sure what to do about that. Anyone have any ideas?

@neverdie I have ordered the Launchpad LAUNCHXL-CC1352P1 from Mouser.at and registered at TI and downloaded all SDK's and the IDE(s).
Now I need plenty of time to test my nRF52832, nRF52840 (breakout/USB dongles) as well as the TI CC1352P ...

To kick start your development, we offer two LaunchPads with optimized external RF components, one for Sub-1GHz PA and another for 2.4GHz PA wireless operations:

@neverdie I have seen that only the P1 version was "unavailable" directly @TI. And yes they have different signal strength on 1GHz and >2,4GHz. I found that also strange.
I wanted to order @TI directly but it looks like you have to be a company or a school and they enforce you to provide a valid URL (you could fake that but I'm not sure if they would ship then).
However buying it at Mouser in Austria is faster and you don't pay shipping cost (above 50€) and don't have to take cate about tax as Mouser has an Austrian order address . The Launchpad cost about 50€.

Regarding the non dev modules: That is what I mentioned to @scalz that I have not yet seen cheap modules, but he said that he made some PCB's for the MCU as well as sensor add-ons and they are on the way, so I hope he will share the PCB files with us or we can order them via his page.
I have a SMD hot air soldering station and solder paste. So I have no fear to solder the MCU But of course having ready soldered bare modules which work out of the box and less or around than 10€/US$ would be preferred.

Argh. Why, oh why, didn't TI make a launchpad with a PA on both the sub-1ghz and the 2.4ghz?

because it's a very new mcu, and they have some work in progress regarding PA paths. (from what I read). So I think they wanted to quickly provide a few usable&different launchpad designs for customers.

Like I said above (but it's in nrf52840 thread arghh), I designed my own shielded modules that I'll tune regarding an ideal gnd plane. I'll test a few antennas (still have a few favorites, but there are some nice chip antennas I would like to test too). And I'll also tune it regarding a sensor daughter board I made, and again check once it's enclosed too. Once that's done I'll provide some comparison, infos, with tuning results (smith charts, vswr etc), tips and help if I can for assembly or to get my modules (PM, or tindie etc, I have a reflow oven to help me, and at my job we're talking about pick&place in shortterm future, not for iot, but handy for extra projects) but 1st step 1st
Still for the moment, as some others new mcus (with erratas), it's not arduino.. but TI mcus are close as it's possible to use, with some limitations, Energia/Arduino project (and sketches are import-able to TI ide).
Our plan (another team member might be interested, he played with cc135x too) is to use MySensors lib (or a part). The main reason : MySensors API is compatible with lot of controllers.

Our plan (another team member might be interested, he played with cc135x too) is to use MySensors lib (or a part). The main reason : MySensors API is compatible with lot of controllers.

Yes that's the big advantage of MySensors, having something you can use on many controllers. So even if the RF stack/network is completely different it's still nice to have a gateway that pretends to be a MySensors gateway to the controller.

@heinzv (or anybody) Do you happen to know what the Tx power and Rx sensitivity is on the bluetooth that's in the Samsung Galaxy S8? I'm guessing that it's relatively weak, in which case I suppose launchpad P1 might make more sense than P2.

It seems that Nordic just hasn't developed easy to use abstraction layer for Bluetooth 5. The question is: has TI? I guess maybe before ordering the launchpad, I should download TI's software and have a look.

Also, is it better to have a single awesome radio that does everything at 2.4Ghz or two humdrum radios, one with great range at sub 1ghz and the other with limited range at 2.4ghz? The two radio solution will always have a higher hardware cost and a bigger footprint, so getting cheap modules might (?) be difficult even down the road. I just don't know.

@neverdie I have not found any hint on BLE Rx Tx sensitivity (Rx) or signal strength (Tx), but I assume that it's not that high as after a few meters the device connections are lost (SmatGear S3), Headphone etc. I would say less than 10m.

My TI CC1352P1 is ordered and I guess it will arrive by end of the week. Meanwhile the Nordic USB dongles are also on the way, so I'll start with the nRF52840 latest at the next weekend and I assume I will have the first experience with the Nordic MCU's.

Regarding the TI MCU: Although in the advertisment video it was explained why you would have two radios at the same time on the same chip, but I rather see it as a possibility to use one or the other best fitting the usage it is built for without attaching another modul. But I'll wait for the first set of real live tests under different conditions (for both nRF52 and TI CC1352). And also how convinient the IDE's and libraries can be used.

Looking at the TI homepage, the CC1352(p) is not even yet available but announved for Q3/2018 which should be now or soon. Thene I hope we can get first modules. I wonder where @scalz will get the MCU's (even the raw chip's)?

Presently the nRF52840 and all the TI Bluetooth 5 launchpads have a receive sensitivity of -103 at 2.4Ghz. None of them are using an LNA at this time.

I think my interest in these chips is mostly tied to doing very power efficient remote control wakeups, which I previously proved I could do using the PPI on an nRF52832. I used the PPI to wake up every 100ms and check for received packets without waking up the mcu, thereby saving power. I could do the same thing with the nRF52840, but with the advantage of its greater receive sensitivity. I'm not sure that TI has anything equivalent to PPI, but even if it did, it would have no advantages for this use case.

For everything else, I'm happy using LoRa modules, because their range/coverage are just fantastic, and at around $3 the Ra-01 LoRa modules are very inexpensive.

Meanwhile, I'll track developments at TI and see what becomes available. It looks like TI is doing good work.

@NeverDie they have sort of equivalent for processing IOs, sensors, i2c etc without waking up the mcu. it's called Sensor Controller (accessible by code or they also provide a small ide for it).
about LORA I've never been really interested in it, I prefer to have my own "micro" network than being a part of a larger network. I would also prefer narrowband.
Sure if you use LORA nodes, maybe narrowband is maybe not the best bet for you. in some cases, widespectrum LORA can have range issues, not heard, when narrowband is used (they made a video+appnote about coexistence)
My need is subghz for long range reliable delivery + BLE for shorter range stuff.., using one broadband antenna or two differents of any kind, to be able to use a module or a bare ic (sometimes a module doesn't fit well in design regarding placement of the module or the antenna orientation&keepout area, so with two modules it's "worse"), and I've been very disappointed to see Nordic changed its mcu footprint (needs premium pcb, and more soldering care). That's why TI picked my curiosity (it ticked all my checkboxes, all in one).
But you're right if you feel more confortable with nrf, it's nice mcus too. Both needs some work anyway (one mcu needs BLE/MySensors, the other needs to get its dualmode compatible with MySensors messages&serial api)

@NeverDie yes. SC is also accessible from app, it can be independant. If goal would be for sort of lowpower listenmode, there are code examples too, not the goal of SC, sure (no link with rf). I don't think I tried it, but will take a look once I've other stuff ok.
I guess, even if PPI doesn't wake up mcu, the task function with a timer still uses somes power.

Maybe you should keep on nrf if you feel more familiar with these. Truth is I have played too with it, but I stopped on my side, a while ago..and started to take a look at TI (so I could say I'm as familiar or maybe "more" with TI now,..). And perhaps, I already said it, but I'm not interested to pay 12$ for bt840f (limited accessible IOs), or less money but with 840 ceramic antenna. When for the same price I can assemble myself a dualband mcu and pick antennas I need. Like people says, pick what fits best your needs (and the application)

@scalz regarding LoRA (RFM95), I think you might confuse LoRa with LoRaWAN. LoRa is a protocol and you can have your own "mico network" (so do I). It is the most efficient and easy to use 868MHz radio (in my opinion) and has long range and high energy efficiency and cost is low (a little bit more than RFM69).
The nRF52840 has a good amount of Flash/RAM (1MB/256kB) and good sleep current even keeping RTC and RAM up or even using radio Rx.

But the TI MCU's like the CC1352P is certainly a very interesting new candidate and it look very very promising with it's BLE 5.0, ZigBee AND 868MHz radio. And I like the SC coprocessor. No doubt that look very attractive. Thus I ordered the CC1352P1 Lunchpad. But that seem to be the only available option to get this MCU and this is for learning purposes only.
When I look at the TI product page it says Status: PREVIEW, no stock: http://www.ti.com/product/CC1352P/samplebuy
I have also seen anounced prices with 10 US$ for the chip itself.
Not sure when it will be really available, get a reasonable price and modules offered (such as for any other MCU's like nRF52).
Same story for the CC2652R, also in PREVIEW.
If you have sources or even PCB's (designed by you) for this MCU's, I would be eager to order and test it.

@heinzv
yes you're right about lora, and that they're using some juice too (they can even be compatible with a rfm69 when you take a look at the datasheet. TI's too though).
I know about nrf52840 power modes, I just replied about PPI feature (depending what you implement, it can't be completely free).
About Ti mcus, they are new and available at their store only. about sharing my work.. when I'll get time. for the moment I'm very busy (with my job too). In the meantime, you still can play with their devboard and try their courses, or energia.

@scalz and @NeverDie today I got my nRF52840 dongles (6 pieces) as well as the TI CC1352P1 launchpad. Now the fun will begin (latest at the weekend)
See the picture below (the dongle in blue and the launchpad in red).
If you have already some more code to share for testing (send/receive, I2C sensor read etc.) please post it (some code was postetd by NeverDie) other wise I'm looking at the Nordic pages, they provide a lot of examples (I will probably use/try Segger).
For the TI part, I only have one launchpad, so I have to verify, if I can use BLE 5.0 to communicate with my mobile or between TI CC1352 and nRF52 ...
Not sure if the TI can also communicate with the CC1101 at 868MHz (using the Sub 1GHz capabilities) using the same modem settings. So a lot to find out.

@NeverDie okay, a very first testing yesterday late-night when setting up the Segger / nRF52(840) tool chain and a very quick dongle testing
I used the nRFconnect and uploaded all 5 demo/test applications which worked. No big achievement but just a very basic testing (maybe not even worth to mention)
Here is the result of the BLE app test: I did the BLE scan with the dongle and it found some devices around such as the BLE WiT power plug with the energy meter. Thene I did the oposite and installed the nRF connect on the Android Galaxy S8 phone and scanned for the nRF dongle.
Attached the two results (one from the dongle and one from the mobile phone)
As you see the Galaxy S8 finds all BLE WiT smart plugs in the flat (also the ones which are in other rooms) while the nRF dongle sees only the one which is close in the same room.
I would assume, that the Galaxy S8 has a much better BLE antenna than the dongle (which has almost no antenna), but what I interpret the RSSI, the dongle reports a better signal strength of the WiT powermeter in the room?!

Today I received also the breakout PCB's for the nRF52832, thus I'll probably try to do a sender/receiver test with them using one as mySensors Gateway and one as mySensors Node (both in nRF24 mode). Not sure if the compile/build will work, because I have to also provide the proper pin-map (as the E73 module is not mapped in the Arduino IDE).

Regarding the Nordic gear, I'm hoping that micropython, if installed, might prove to be easiest for OTA updates, since, in theory, a micropython app should be able to update itself through its inherent REPL process. It turns out that maybe because of the BBC micro bit, micropython runs on the nRF51. In general, though, it seems like the ESP8266 has a lot more micropython support.

@NeverDie I'm still at the basics (where you have been probably one year ago). I have now soldered my nRF52832 modules (the E73...B from EBYTE) to the breakout boards and tried to find the best way to program and flash them.
I started with Segger Studio and with ST-Link upgraded to Black Magic Probe but as far as I have understood it supports only their own J-Link HW for flashing (at least the J-Link EDU is required). I also converted a ST-Link Dongle to a J-Link dongle but that can only flash STM MCU's (license restrictions).

I have then tried to use Aruino Studio with all 3 dongle types (Black Magic, J-Link and ST-Link). I was only successful by using ST-Link. It does flashes the sketches and it runs (just used a simple blink example for flash testing).
But using the ST-Link (V2), there is no serial devices and thus no Serial Windows for log output (Serial.println()).
I've also tried to use the Black Magics with the GDB but it did not work either and I found it also not convinient with the commandline.

So what are you using for flashing with Arduino Studio (with it's limited nRF52 support) and flashing with Segger Studio an what are you using for debugging and logging (print lines to output/serial ...)?

@heinzv For the NRF52832, try using the MySensors MyBoardNRF5 board type. In MyBoardNRF5.h, there is a section for the serial interface. Set PIN_SERIAL_TX to the pin you want to get serial output from. Set PIN_Serial_RX to some unused pin. It isn't used anyway. (A tip I got from @NeverDie).
I like the Black Magic Probe because it has both the SWD and Serial in one device, but you could program with the ST-Link and listen to Serial with an FTDI. I hear J-Link is the best, but have not used it. Might try it now that I know there is an educational version.

@neverdie and @Nca78 thanks for the quick response, I have ordered the nRF52840 DK from Nordic (via Mouser). That works with Segger and also with Arduino Studio too (for the simple and existing 52832 projects like mySensors)?
And fo the Arduino Studio (or VS Code) is there a serial terminal for debug output too?
How to you flash then the bare nRF52 modules which have only the SWD interface (I have plenty of them)?

@nagelc I have again tried my Black Magic Probe Dongle with Arduino IDE, but it does not yet work for me (maybe I still have not understood it). In Arduino Studio I have tge GDB serial port but neither the upload works properly nor I have understood how to use it with the GDB debug window.

I attach the devices (Windows 10) and the output from Arduino IDE. Maybe you can give me further hints:

I used a simple blink sketch which works with ST-LInk V2 upload but not with BMP. Here is the output from the upload:

@heinzv I haven't ever used BMP, but I'm guessing that maybe you need to bulk erase your target device first. That would remove any read-only protection. If so, you only need to do it once. After that, it should upload OK.

@neverdie I can do upload with the standard ST-Link V2 Dongle on the same bare E73 module but for the BMP it is read-only?
How do you flash the bare modules (not the DK)?

Not sure I understand your question. I can flash bare modules using the DK. I'll let others comment how they do it without using the DK, as that's about all I know. One final tip though: Generally it's important to power your target module independently of whatever programmer you're using. For instance, on the DK, it will detect the voltage level on the target and adjust accordingly, but it isn't meant to power the target.

@neverdie To my first statement: I was just wondering why I can upload sketches with teh ST-Link V2 dongle (but no serial output/debug windows) but the BMP might face read-only protection (I thin kthe upload script should have some kind of mass erase before upload)?
Regarding my question: I think I you understood my question right and I also read the nRF DK features and it says it features a SEGGER J-Link OB Debugger with debug out functionality. So I guess it's a flasher/debugger not only for it's on-board nRF52840 MCU but also for external nRF modules connected to the DK right?

Are you're also using the DK with the Arduino IDE (though with restrictions like no full nRF52840 support) and the mySensors project?

Meanwhile I'm exploring the nRF52840 USB dongles. And maybe I'll get along with the BMP modules and understand how the work with the Arduino IDE (so far I spent many hours with Google und no success).

Regarding my question: I think I you understood my question right and I also read the nRF DK features and it says it features a SEGGER J-Link OB Debugger with debug out functionality. So I guess it's a flasher/debugger not only for it's on-board nRF52840 MCU but also for external nRF modules connected to the DK right?

Right.

Are you're also using the DK with the Arduino IDE (though with restrictions like no full nRF52840 support) and the mySensors project?

Not presently. I made a weak attempt recently but something is broken (probably on my end) to where I couldn't get it to compile anymore, whereas previously I could. So, I decided to see what else was available, which led me to mbed, and then now to SES, which has no trouble compiling. As long as I can directly manipulate the nRF52 registers and have access to serial output for debugging, I can do pretty much do whatever I need to do.

The easiest way to get started with NRF5 might actually be the BBC Micro:bit

Yes! From what I can tell, a lot of development work has gone into the micro bit to make it easily programmable using any of a handful of different languages including C, C++, and micropython. Apparently it's somehow possible to do a hybrid of C and micropython, where the time sensitive parts can be written in C/C++ and the rest in micropython. Not sure how that works exactly, but it sounds interesting.

Originally I thought the BBC micro bit was purely a toy, but when I saw it could scroll text across its 5x5 matrix of LED's I realized that it could be more than that. Very clever!

What I'd prefer, obviously, is doing the OTA update from a computer (maybe using a dongle of some kind?) If that were possible, then nRF51 modules are so cheap you could imagine putting them in almost anything, even if it's to control a different kind of radio.

There are a couple of differences.
" Sketch uses 17856 bytes (3%) of program storage space. Maximum is 524288 bytes."
Not sure why my maximum storage space would be higher than yours.
"Start address 0x2fa0, load size 18080"
Different sketch, so I would not expect the load size to match, but not sure why the Start address would be different.

@nagelc Thanks for your response and trying to get me further.
I'm trying to get you as much infos as possible:
I made a couple of screenshots and picture of my environment. Maybe that helps to trace down to the problem.
I followed exactly the instructions from sanseeps Arduino/nRF5 configuration/installation.
Uploading the bkink example with the ST-Link V2 works, but there is no serial print, no debug, thus I'm trying the BMP way.

Here some setttings from my Arduino IDE (Tools section)

Here are my different BMP modules I have used
and the COM devices in Win 10
I have tried all kind of driver (using Zadik 2.4), but WInUSB, lisbusbK, libusb ... they all create USB devices only but no COM devices, which Arduino IDE does not "like") only the usbser driver gives me COM devices

and the target device I'm using (which works, when I load the sketch with the ST-Link and select ST-Link in Arduino IDE)

@neverdie good discussion, but in order to get my desired solution which is sensor nodes with E-Paper and working with OpenHAB I need I either get the nRF52 modules running with mySensors (ideally just using the Arduino porject and IDE) using the nRF option (I think there is some initial nRF5 support) and using the older nRF24 protocol, or using LoRa with an RFM95 module (which is also supported) or I switch completly to Segger and make a ZigBee V3.0 solution (requiring a ZigBee gateway for OpenHAB). With my new Philips Hue HW version and the new SW firmware upgrade. It is claiming to support ZigBee V3.0 devices which includes also Temp/Hum sensors.

Probably soon I'll take a crack at doing an OTA DFU with an nRF52840. The good news is that Nordic is reasonably responsive to questions with about a 24 hour turnaround, so that means any sticking points should be resolvable. Failing that I may try writing my own basic OTA uploader.

@heinzv For Softdevice, pick None. MySensors doesn't use the Softdevices and I don't think you want it for Generic NRF52 either.
The Low Frequency Clock depends on your board. If it has an external crystal outside the NRF 52, use Crystal Oscillator. Otherwise pick RC Oscillator to use the internal oscillator.
Your BMP ports look correct. In your setup, 58 for the programmer. Use the UART port , 51, to listen to serial debug.
The Black Magic Firmware Upgrade is for use with DFU Util to upgrade the firmware on the probe. I'm not sure what the Trace Capture is.

@nagelc I have tested both w/ and w/o softdevice, it doesnt make a difference but yes I'll remove it again.
My boards (the E73 module) have an external 32kHz crystal osci for RTC.
In Arduino, you can only select one port. If COM58 is set (for the programmer) then it would open the serial monitor also on that port. However I have tried to use port 51 with another terminal (putty) and it does not connect (I've tried with different baud rates).
I'm not sure but I think (and read) that the second port is only for the SW update of the BMP and not for debugging. Debugging is most likely also on port 58 but for the GDB and not for Arduino, but if it is used (initiated) via Arduino, I could not connect to GDB with a command terminal, so I think the programm has to be started with the command windows and GDB. I've also tested that from that direction and was also not succesfull (I spnt many hours with Google and BMP docu and GDB).
I also don't know how to use the non COM (USB only) devices like the "Trace Capture" as thery are not visible/offered in Arduiono IDE.

You're using BMP with Arduino IDE? How are you doing the serial output?
How can you used two different ports in Arduino (there is only one port setting)?

@heinzv Yes. I'm using with Arduino IDE, but I connect a terminal program (TerraTerm) to the UART com port. You need to do more setup to get the serial out from NRF52832. The easiest way is to use the MyBoardNRF5 board type to select a pin to be TX. But that is a bit much for a blink sketch.
There is yet another usb driver for the Trace and Firmware Update ports. I forget how that is loaded (zadig I think), but you can safely ignore it.
Seems like your setup should just work uploading the sketch on your COM58.

For the GDB connection. There is a syntax difference for ports higher than 9. Try this. I had it in my notes, but haven't tried it since my ports are less than 9.

@nagelc So everything works now with the BMP using the MyBoardNRF5. At least it supports the nRF52832 (if I'm lucky also the nRF52840) but I started with my barebone 832 modules.
So it upload the sketch and it does also reset and start.
I could also do the connection to the second serial port now with Terra Term and get the Serial.println. Cool.
The secret was, that I created another BMP for my blackpills (I did a couple of tweaks) and connect now the HW serial of the nRF52 to the BMP serial (UART2) and it forwards it via the USB of the BMP to the COM port.

So, the idea for doing OTA code updates is simple enough: you transmit each line of code and the target assembles it into a string. Then the target executes the string, which updates the code on the target. QED

@NeverDie great job! I'll definity try it on my holyiot bare modules, but I'm still fighting with the flashing via either the Nordic DK and/or ST-Link v2SO far I was not successfull (I only got it to run with Arduino IDE and BMP, but that is not usable in that case). DK seem not recognize my external nRF52840 and the ST-Link wants some address ranges so I'm trying to get it run with openocd, but that also returns errors. So I'm stuck and wasting many evenings/nights (with Google).

@heinzv Using the DK should be easy. If you want to post how you're wiring your connections to the target, maybe I could help you identify what mistake you are making. Or, if you prefer, you could post to the Nordic support forum, as they would be obligated to help since it's a Nordic product. Or, better yet, do both, because then you'll at least get the ball rolling with Nordic in case you have a defective DK (unlikely, but who knows).

@neverdie I admit that I also powered the module via the DK because it takes less than 20mA. I used this connection description:
But I'll try to use a complete an external PS next time and see if it makes a difference.

@NeverDie thanks, appreciate your help as you are far ahead.
Here is my update: I have build 4 nRF52832 boards with the E73 EBYTE modules and two nRF52840 board with the tiny holyiot modules (see picts below).
It seems that by using the wiring shown in my last post, I can flash the 840 boards. I'll also try again one of the working 832 boards later (I'm in business trip the next few days).
But I have a couple of questions to you:
1.) I don't know how to identify which MCU will be flashed. I only see the J-Link adapter in Segger or the board with the Segger Serial in nRFgo Studio. How can I know, that I'm not flashing the DK onboard MCU? Where is this shown, indicated where the flashing will go? That is strange to me. Another example is my sel build Black Magic Probe: It shows which devices are connected to it and you can select one (if multiple are shown in a select - select target 1,2 ...)
2.) How can I make use of any bootloader (DFU, Serial, USB, OTA, ANT etc.) so that flashing with the DK is not always required? I have not found a good way so far to flash any useful bootloader (I have tried some of the examples). The onyl one which creates a serial devices is the example for the PCA100059 (the USB dongle) which shows a serial device: nRF52 SDFU USB (COM75). HOw to make use of that (I have tried all of the offered programmer als oin Arduino IDE but could not upload/flash my blink sketch)
3.) How to you flash the USB dongle beside using the nRFconnect which requires the compiled image?
Are you also soldering the SWD pins and use them with the Segger and the DK?
4.) When I flashed your micropython (or circuitpython?) for the 840 (my board). How to I connect and use it? My 840 boards have it's own USB port (see topic 2, which shows the nRF52 SDFU port when I flash the one bootloader). When I flash the MP, the ports are gone (how to connect via USB, Serial, Terminal etc.)?

I've also tried a couple of other things like a DFU bootloader with a S140 softdevice (as it was recommended by Nordic) but was not sucessful to combine them (the S140 was flashed, but then?)

I have many more questions but I hope we can sort out some of the 1-4. I hope I have described them so that you can follow my thoughts and questions

@NeverDie thanks, appreciate your help as you are far ahead.
Here is my update: I have build 4 nRF52832 boards with the E73 EBYTE modules and two nRF52840 board with the tiny holyiot modules (see picts below).
It seems that by using the wiring shown in my last post, I can flash the 840 boards. I'll also try again one of the working 832 boards later (I'm in business trip the next few days).
But I have a couple of questions to you:
1.) I don't know how to identify which MCU will be flashed. I only see the J-Link adapter in Segger or the board with the Segger Serial in nRFgo Studio. How can I know, that I'm not flashing the DK onboard MCU? Where is this shown, indicated where the flashing will go? That is strange to me. Another example is my sel build Black Magic Probe: It shows which devices are connected to it and you can select one (if multiple are shown in a select - select target 1,2 ...)

If it's wired corectly, then only the external board gets flashed.

2.) How can I make use of any bootloader (DFU, Serial, USB, OTA, ANT etc.) so that flashing with the DK is not always required? I have not found a good way so far to flash any useful bootloader (I have tried some of the examples). The onyl one which creates a serial devices is the example for the PCA100059 (the USB dongle) which shows a serial device: nRF52 SDFU USB (COM75). HOw to make use of that (I have tried all of the offered programmer als oin Arduino IDE but could not upload/flash my blink sketch)

I don't know.

3.) How to you flash the USB dongle beside using the nRFconnect which requires the compiled image?
Are you also soldering the SWD pins and use them with the Segger and the DK?

Yes.

4.) When I flashed your micropython (or circuitpython?) for the 840 (my board). How to I connect and use it? My 840 boards have it's own USB port (see topic 2, which shows the nRF52 SDFU port when I flash the one bootloader). When I flash the MP, the ports are gone (how to connect via USB, Serial, Terminal etc.)?

So far I've only flashed MP to the 832 and 840 DK's. In those instances, you can do serial IO over the USB connection using putty or similar terminal.

I've also tried a couple of other things like a DFU bootloader with a S140 softdevice (as it was recommended by Nordic) but was not sucessful to combine them (the S140 was flashed, but then?)

I have many more questions but I hope we can sort out some of the 1-4. I hope I have described them so that you can follow my thoughts and questions

Howdy y'all first off thanks @NeverDie for this thread, I spent a good time lurking at these NRF52 posts and learned and re-learned a few things here and there.

I've built an E73 NRF52832 PCB and successfully did a blink using Espruino and Adafruit's Bluefruit FW for Arduino and just noticed the $10 CAD E73-2G4M08S1C (NRF52840) back in-stock (as of October 8). I am in the process of designing a pcb board layout for it but in the meantime thought that the community might find the following useful if you plan on designing/using these modules:

Library.io allows you to convert '.pcblib' / altium files to an Eagle Library format, you just need to specify the Symbol and Package, from here you can convert to KiCad or similar I'd reckon but have not used KiCad enough to verify this. This saved me a lot of time.

In case someone was wondering: I've had no issues using the J-Link Edu Mini with the NRF52832, will update here when I get to the NRF52840.

Just starting my own NRF journey and thought to add this here in case someone is looking for E73 module specifics WRT NRF52832/NRF52840 .

Big thanks to @sandeepmistry, @lpercifield, @jeremypoulter and all others contributing to the NRF Arduino development effort. I have borrowed a lot and forked off another project for adding support for the NRF52840 dongle (PCA10059). If you are using PlatformIO and have access to a NRF52840 you can take it for a spin here PCA10059. I have tested UART, TWIM, SPIM and the BLE Led toggle example works.

@NeverDie I never liked the Arduino IDE, so I think PlatformIO is next logical step, it is very easy to get going and it opens up for advanced usage. Your own choice of editor, has great debugging capabilities with VSCode integration.

If you build the PCA10059 example I linked you should have GPIO (digital) access to all 47 pins. I've made it simple in the pca10059 variant so that D0 (0) is p0.00 -> D47 (47) is p1.15.

@redferne thanks for your effort spent to support nRF52840 for VS Code/Platform.io. I'll certaily give it a try. The good thing with platform.io is that it's easier to use/import existing arduino (ino) projects than in e.g. Segger Studio which only supports licensed J-Link flash/debug adapters.

Two questions:
1.) Does your "port" support also the 15.2 SDK features of the 840 (Softdevice S140, BLE 5.0 long range, ZigBee, Thread ...)
2.) What flash method is supprted/used or you're using? Just plug the USB dongle in and it can be uploaded?

Oh, a third question: If I use bare nrf840 Modules, what flash adapter/mode would you recommend or have you tested (I have the 840 DK board, a ST-Link v2 and a Balc Magic Probe adapter)?