Everything nRF52840

[wassfila]

@neverdie Bluetooth and zigbee have different scopes and different business models. Zigbee is targeting automation networks such as devices that are permanently available and collecting in a server, while Bluetooth is only user centric in its pairing mechanism (it's funning those bluetooth devices that collect a certain amount of data locally for download with the user's phone, they are not scalable for big systems). Zigbee is evolving towards more structured networks capabilities and I predict that the Thread is sooner or later going to replace Zigbee without users loosing functional products as the alliance is already preparing a common zigbee and Thread top layer (dot dot) that would provide a smooth transition. Thread will provide a standardised routing between the sensors local network and the internet, and that is very competitive compared to any Bluetooth or zigbee solution where every one has to reinvent the wheel for a different way of mapping the local network to global, vendor specific or custom gateways would finally tend to disappear. Even if you do not want your sensor to be shared with the world, the smooth transition from low power wireless network to ethernet (and the raspr) is something I would apreciate. Now add to that the MQTT-SN that is designed for low power wireless networks, and you get an out of the box MQTT layer for your low power wireless sensor. I do not know, but if I would bet, I'd bet on that to gain interest in the future.
And by the way, I do not think that these fancy standards compete with MySesnors, because the SW that is simple and you know is 100 times more practicle to work with, port and adapt to corner cases than a huge stack such as BT or zigbee.

[NeverDie]

@wassfila Who knows?The nRF52 chips are multi-protocol, which I suppose is one way to hedge your bets. Thread is one of them.

[NeverDie]

As of today, uLisp now works on the nRF52840. I posted a repository and build instructions on github: https://github.com/rabbithat/uLisp_nRF52840 I have moved from uPython to uLisp to facilitate over-the-air code upates.

[NeverDie]

An interesting benchmark I just did on the nRF52840: I'm able to transmit (and receive) the entire Declaration of Indepdence (roughly 8KB of text) in under 35 milliseconds. So, with that as a reference, I expect OTA code updates can be fairly low power.

[Sergio Rius]

@neverdie On platformio, what do you use for programming? A black magic probe?

And about the 255 payload, have you looked for a wrong sized variable or type? If you want me to give it a go on visual studio+resharper just send me a sample. I still don't have a programmer and still haven't received my nrfs so I would only look for programming errors.

[NeverDie]

@sergio-rius

I use the nrf52840-DK as the programmer.

Regarding the 255 payload, I'm able to get it if I send static length payloads, so that's what I'm doing now. However, variable length acts very strangely in that the maximum length before truncation seems to vary depending upon what the actual payload content is. It's 100% repeatable for the same payload content, but changing the content generally leads to a different maximum length. So, I'm not sure what's up with that. It definitely shouldn't be that way.

[Sergio Rius]

@neverdie Does it have compression or checksum of the payload? I'm not used to that library, but it seems some processing is done. First try with plain repeating characters or numbers to discard encoding issues.

[alowhum]

@neverdie #240 Time to Say Goodbye to Arduino and Go On to Micropython/ Adafruit Circuitpython? – 15:27
— Andreas Spiess

[NeverDie]

@alowhum Thanks. Not sure if you saw this: https://forum.mysensors.org/topic/9889/anyone-here-tried-mercrisp-forth-for-programming-arm-cortex-m-i-e-blue-pill-nrf5-stm32-etc

Looks as though there will be a mecrisp-stellaris FORTH release for the nRF52840 within about a week, or maybe sooner. Because of its built-in optimizing compiler to native machine code, I'll probably settle on mecrisp-stellaris.

[alowhum]

Yes I saw it. Very hardcore.

[NeverDie]

You can now run mecrisp-stellaris FORTH on the nRF52840-DK: https://github.com/rabbithat/FORTH_NRF52840-DK

[rozpruwacz]

@NeverDie did You compared somehow the range of the nrf52840 dongle with other nrf52840/nrf52832/nrf51822 modules ? I'm asking because after first test it appears that the nrf52840 dongle has worse range than core51822 module using the same radio settings.

[NeverDie]

@rozpruwacz No, I hadn't noticed that. Do note though that you can increase the tx power on the nRF52840 dongle to 8db, whereas 4db is the max for the nRF51822.

[rozpruwacz]

@neverdie said in Everything nRF52840:

@rozpruwacz No, I hadn't noticed that. Do note though that you can increase the tx power on the nRF52840 dongle to 8db, whereas 4db is the max for the nRF51822.

Yes, but with the same settings I would expect at least the same range. I will keep testing.

[NeverDie]

@rozpruwacz The nRF52840 chip itself should be better because of its greater receive sensitivity.You didn't say exactly what you're comparing it against (aside from it being an nRF51822), but the dongle has a smallish antenna and a small ground plane. Usually those don't have as good a range. It's one of the trade-offs that comes with smaller size. It may also be more directional that what you're expecting, so try rotating it and see if that makes a difference.

[rozpruwacz]

@neverdie i'm comparing it with core51822 module which also has pcb antenna

[NeverDie]

I just now posted a much easier mecrisp-starellis FORTH for the nRF52840-DK: https://github.com/rabbithat/nRF52840-DK_easy/blob/master/README.md

On this one, all you need do is upload the hex file located in that repository and you're done.

[heinzv]

@neverdie interesting research and ideas. Have you tried to get BLE 5.0 running (the S140 SD) or using the nrf52840 radio features (best with long range) so that we can consider a sensor node/actor and does the sleep properly work? There are some basic features which have to work before switching the development/runtime env.

[NeverDie]

@heinzv

I haven't been working on that per se, but I do have a REPL over radio working: https://github.com/rabbithat/nRF52_wireless_Forth_REPL
which can also be used for doing OTA code updates.

[heinzv]

@NeverDie You doing a great research! I have quickly checked your REPL code and the radio lib.
So you have implemented a OSI Layer 3+4 (Transport Layer with IP/TCP Stack).
I'm wondering if/how this can be used to complay to BLE 5.0 (long range), ZigBee and Threads which the new Nordic SDK (Zigbee and Threads 2.0) offers? Are they also using the Softdevice S140 (6.1) libs or ...?
There is a ZigBee OTA update example provided by Nordic (but I have not yet enogh time to test it).
Currently, I'm still using MySensors and the NRF5_ESP (Nordic private) protocol which works. IT would be also interesting to use a more industry standard protocol like ZigBee or THREADS which seem to be also supported by OpenHAB.
I'll certainly do further investigations in this direction. I have tried to test it with Segger Embedded studio and also with IAR Studio for ARM (the second requires some newer 32Bit version libs from Nordic and an internat request for that was raised already). Segger works fine with the J-Link adapters.

[NeverDie]

@heinzv said in Everything nRF52840:

I'm wondering if/how this can be used to complay to BLE 5.0 (long range), ZigBee and Threads which the new Nordic SDK (Zigbee and Threads 2.0) offers? Are they also using the Softdevice S140 (6.1) libs or ...?

If you specifically want those protocols, then at present the Nordic SDK is the only existing library I know of that will get you them.

[NeverDie]

It appears that Fanstel is now selling the amplified nRF52840 modules:
https://www.fanstel.com/bt840f-nrf52840-ble-5-module-secure-iot-802154-thread-zigbee-1

[alowhum]

Wait, what? The nRF52840 can now act as a Zigbee device too??

So I could make Arduino projects that talk Zigbee?

[NeverDie]

@alowhum Well, 802.15.4 for sure. I already did it, as I reported earlier. Beyond that, there's no native on-chip support for Zigbee per se. Maybe they confused it with zigbee? https://www.electronicdesign.com/what-s-difference-between/what-s-difference-between-ieee-802154-and-zigbee-wireless

That said, someone could certainly write a zigbee on top of it. It's meant for stuff like that. I imagine Thread is already written on top of it.

Anyway, I suspect that the amplified nRF52840 modules will be as good as it gets for quite some time and will remain relevant for years to come. The long wait is finally over!

[NeverDie]

By the way, I now have the wireless FORTH REPL working on the same nRF52840-dongle as in the OP of this thread: https://github.com/rabbithat/nRF52840-Dongle_hex/blob/master/README.md

I can plug the dongle into any USB port to power it, and with the wireless REPL the experience is exactly the same as if I had a wired serial connection to the dongle. I can interact with the REPL, start programs, load code or updates, and/or debug--all wirelessly. If you want to try it, I have getting started instructions in the github repository.

[blademckain]

Someone know if exist a usb nRF52840-dongle (with external antenna ) to plug into a raspberry to scan nearby tag?

[alowhum]

@blademckain The Micro:bit comes close.

[nagelc]

The new Arduino Nano 33 BLE is going to use the nrf52840. It will be interesting to see how support for the nrf52840 evolves in the Arduino environment.

https://hackaday.com/2019/05/19/new-arduino-nano-line-rolls-out-in-four-flavors-at-maker-faire-bay-area/

[monte]

This post is deleted!

[alowhum]

@nagelc that's great news!!

[nagelc]

Arduino Nano 33 BLE code is coming out. It's going to be based on MBED. Here's a discussion on the Arcuino Blog:
https://blog.arduino.cc/2019/07/31/why-we-chose-to-build-the-arduino-nano-33-ble-core-on-mbed-os/

I think it is interesting that no one has updated Sandeep Mistry's code for the NRF52840. Since it has been so long, I'm guessing this is not an easy task.

[NeverDie]

@nagelc thanks for the update. Mbed has a lot of overhead to it, but anything is better than moving mountains alone.

[simbo]

Someone may get some reuse out of this. I've made a 3d printed prototyping rig for the NRF52840 DK board as part of my MySensors adventures....

https://www.thingiverse.com/thing:3836487

[monte]

@nagelc I think Sandeep Mistry is working on new arduino core, based on mbed. As you can see he is titled as "Senior Software Engineer at Arduino" here. So I guess Mysensors community would need to move to new core eventually, or to fork Sandeep's core and develop it alone. I would prefer the first choice.

[scalz]

@monte
I remember in first place they mentioned apache mynewt a while ago, but finally they are moving to mbed.. still nice to hear. I think this new arduino/mbed core has not everything yet for running MySensors, that needs some work on proprietary rf.., whereas there are other working cores. At least for short-mid term. There are so much nice things to improve or add on todolist.
Team knows about new mcus, new cores etc what's missing is time, resources vs real life and projects!

[monte]

@scalz With official support from arduino and massive amount of chinese clone boards and much more powerful hardware I think in a year new nano board can become a new standard. Not to mention that single board which already has everything to work with mysensors is something many people where looking for for years.
I understand the time constrains, and am always thankful for a dev's work for community's good

[scalz]

@monte sure would be nice, no need to argue on this, about a standard. (still not sure imho if 2.4g would be best choice). I'm wondering if adafruit will give up on all the work they made on their custom core too (I imagine they have no hurry, and wait to see if that'll be promising).
let's see what will happen. and perhaps next year there will be new better mcus again, almost sure

[Amine Alami]

@heinzv Sorry to cut-in with an unrelated comment, but can you tell me how or from where you got this nice schematic diagram? I am looking for one that has other cards such as Raspberry Pi and TI cards for an architectural diagram

Cheers

[heinzv]

@amine-alami what nice schematic diagram are you refering to? I'm looking at this thread very sporadically.

[NeverDie]

After waiting almost a year for the dust to clear, it seems that there are now roughly two leading platforms at the moment that either have or may get good software support:

1. The Adafruit nRF52840 feather: https://www.adafruit.com/product/4062
   which Adafruit either has or is making Arduino compatible.
2. Possibly the Arduino Nano 33 BLE: https://store.arduino.cc/usa/nano-33-ble
   and/or https://store.arduino.cc/usa/nano-33-ble-sense
   for which, ironically, Arduino has chosen to adopt using mbed as the core software techology.

In other words, it appears that Adafruit has become more Arduino than Arduino!

There are also some "particle" boards that are hybrids:
https://www.cnx-software.com/2018/02/14/particle-unveils-three-nrf52840-bluetooth-5-boards-argon-wifi-boron-lte-and-xenon-particle-mesh-technology/
I had thought these would necessarily be more expensive, but right now the Xenon board is selling at $15, which is almost half the price of either the Adafruit or the Arduino boards:
https://www.amazon.com/s?k=particle+xenon&i=electronics&ref=nb_sb_noss_1
Are the particles easy to program and perform OTA updates? I have no experience with them. They're pushing a subscription service if you have more than ten or so of them, so I suppose the true cost could be higher if you go "all in" on them. On the other hand, if you happen to want/need whatever their cloud service is, at least you'd be getting some kind of value for your subscription money. I suspect that, at the moment, it may be the easier to do OTA updates with particle than the first two, if only because it needs to be good if they are to justify their service fee. Their Photon board (which is a wi-fi only device) has gotten mostly favorable reviews on Amazon. On Photon the subscription fee doesn't kick in until you have more than 100 photons, which sounds a lot less confining the the 10+ units of Argon or Xenon. Unfortunately, it sounds as though it's not low power enough for battery powered nodes: https://www.youtube.com/watch?v=68N67ZVxTZ0 A 7.5ma deep sleep sounds stupidly high to me. What were they thinking?

In summary, the Adafruit nodes sound best to me at this point in time. The Arduino nodes might catch up with the adafruit if enough people buy/develop for them. Time will tell. Sadly, Particle may be DOA unless they have a trick up their sleeve that I don't know about.

[scalz]

I think adafruit core is nice, and they added freertos which is a nice touch too. So, in case, I can easily reuse some modules I wrote for esp32 projects (which is freertos based too, out of he box)

Good to know, it's not perfect, both cores, nrf5 adafruit or arduino-mbed, unfortunately miss some sdk files..

I like Adafruit core so far, but Segger IDE with full sdk support is very convenient, because spending time in arduino cores linking missing libs etc is such waste of time, vs coding fun features..

[NeverDie]

@scalz Yes, you raise a good point about Segger.

I'll try both the Adafruit and the Arduino versions and report back my impressions afterward.

[NeverDie]

I gave the Arduino Nano 33 BLE Sense a try just now. I'd say it's beginner friendly in the sense that you can simply plug it into USB and program it that way through the Arduino IDE: no getting confused or stuck burning the flash using an st-link or similar.

Blink compiles into a roughly 80KByte binary, and I presume most of that is overhead of the included mbed platform. This isn't really a problem though, because the nRF52840 has an abundance of flash--probably more than you'll ever need, even with mbed consuming part of it.

As for the sensors that are built onto the 33 BLE Sense, you need to load libraries for each one that you want to make use of, but it appears that those libraries are available.

I get the impression that Arduino has typecast the nRF52840 as primarily a bluetooth device. I see no mention of the radio's proprietary mode. That is perhaps unfortunate, because Bluetooth per se isn't easy, and proprietary mode is actually much easier.

On the other hand, maybe easier-to-use Bluetooth libraries will eventually arise. I guess time will tell.

[alowhum]

@NeverDie This is a bit of a side-question but to what degree could Arduino's Bluetooth support fulfill the role MySensors plays?

In theory it seems Bluetooth could be a useful smart home communications platform:

• Just like MySensors, Zigbee, Z-wave, it avoids using the IP stack, and generates a separate network for smart devices. This lowers risk to user's home network.
• Lower energy than WiFi. Lower energy than NRF24 too?
• The killer app: it's built into smartphones, tablets and Raspberry Pi's already. No need for an extra dongle.

What I don't know is

• To what extent Bluetooth has useful smart home profiles
• To what extent Arduino devices could present themselves as smart home devices using those profiles.
• To what extent older Bluetooth chips can work with newer device profiles (it would seem a software upgrade should be enough?)

Maybe this should be a separate post

[mfalkvidd]

@alowhum interesting idea. Maybe add low-power features to the list. Bt-le has some very nice low-power features, but will it be possible to use them in custom sketches?

[Nca78]

@alowhum hard to say if the best would be to get rid of the gateway and program adapter for bluetooth devices, or to make a bluetooth gateway between bluetooth network and mysensors serial protocol.
In both cases we could have some custom profiles for the types of sensors used by MySensors.

[NeverDie]

@alowhum Good questions. From a distance, Bluetooth seems near ubiquitous. Closer up, the capabilities seem governed by the available "profiles" baked into a particular implementation, and that's where the apparent ubiquity seems to fall apart. There are long range modes that 5.2 Bluetooth BLE can support, but which of the profiles implement them? Those would be the set of profiles worth considering. Of those profiles, which one would be the best fit? Maybe knowing that would be a step toward answering your questions.

https://www.bluetooth.com/blog/5-videos-that-prove-thelong-range-capabilitiesof-bluetooth/

[alowhum]

Here is the datasheet of the actual Bluetooth module on the Arduino 33 BLE (PDF):
https://www.u-blox.com/sites/default/files/NINA-B3_DataSheet_(UBX-17052099).pdf

Here is a list of Bluetooth profiles:
https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles

Mesh networking profile details (PDF):
https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=429634

I'm trying to figure out:

• Can these Arduino's even present themselves as a specific Bluetooth profile? E.g. as a bicycle cadence sensor, or a smart lamp, etc.
• Can these Arduino's be programmed via Bluetooth?

the Mesh profile would be interesting:

Mesh Profile Specification[10] allows for many-to-many communication over Bluetooth radio. It supports data encryption, message authentication and is meant for building efficient smart lighting systems and IoT networks.

Application layer for Bluetooth Mesh has been defined in a separate Mesh Model Specification.[11] As of release 1.0 lighting, sensors, time, scenes and generic devices has been defined. 

The Bluetooth module documentation says it has hardware support for mesh networking. Nothing else though.

The Bluetooth mesh networking spec only seems to support very basic things like lamps though. No advanced things like thermostats.

Other interesting things:

According to this blogpost, Arduino exposes the full MBED options.

Apparently you double-tap the reset button to be able to access the bootloader. Nothing about wireless upload of sketches via bluetooth though.

Here are some examples from Arduino on what you can make:
https://github.com/arduino-libraries/ArduinoBLE/tree/master/examples/Peripheral

[rozpruwacz]

@alowhum said in Everything nRF52840:

Can these Arduino's even present themselves as a specific Bluetooth profile? E.g. as a bicycle cadence sensor, or a smart lamp, etc.

Bluetooth profiles are nothing more than just a set of rules how to structure software ofluetooth profile means that your device provides attributes to read/write described in that specific profile. You can present your device as specific prfoile but not implement its requirements, but in that case other devices will not work properly with yours. So the answer is yes - its just the mater of the software.

[alowhum]

@rozpruwacz Indeed. This example sketch of a bluetooth battery monitor looks pretty cool:

https://github.com/arduino-libraries/ArduinoBLE/blob/master/examples/Peripheral/BatteryMonitor/BatteryMonitor.ino

Lots of new Arduino functions to manage services are described here:
https://www.arduino.cc/en/Reference/ArduinoBLEBLEbegin

And here's a list of possible characteristics:
https://www.bluetooth.com/specifications/gatt/characteristics/
E.g. Gust Factor, Heart Rate Max, Last Name, Latitude, etc

Looking at that list I don't see a lot of overlap with MySensors

Also, bluetooth mesh does not seem to support BLE long range mode. The mesh aspect is technically outside of the official bluetooth spec.

[NeverDie]

@alowhum With the arrival of the Arduino nano BLE, I'm hoping that some easy-to-use Arduino BLE libraries will become available. In the meantime, Nordic's Bluetooth stack is certainly available and free to use. It didn't look especially easy the last time I looked at it, but that was quite a while ago. Maybe by now either Nordic or someone else has simplified it? For mainstream uses, it certainly should be easy to use without having to know every little detail about the Bluetooth standard. And since Arduino doesn't seem interested in the proprietary modes, I should think there would be pressure for developing such Bluetooth libraries. After all, it's very name is "nano BLE". Therefore, it's reasonable for people who buy it to expect it to be Bluetooth capable.

[NeverDie]

At the very least, I would expect Bluetooth to be a useful complement to mysensors. For example, outputting diagnostic println's to a simple Bluetooth terminal app on your tablet or cell phone. And if it can do even just that minimal amount, it could be leveraged to do a lot more too.

[monte]

There seems to be https://github.com/sandeepmistry/arduino-BLEPeripheral library. I tried it some time ago, it was working pretty straightforward. I mean it's not ideal, obviously, but it works for a start.

[heinzv]

anybody seen this new Nordic IoT MCU:
https://www.nordicsemi.com/Products/Low-power-short-range-wireless/nRF5340

So far only a DK board for 49$ is available. Has BLE 5.1 (incl. long range).
I guess it will take some time till it is supported by Arduiono, Platformio etc.

I'm still striggling with the nRF52840 and the low power sleep. So far I'm far away from the 1.5 to 5uA in sleep mode. Maybe someone has a good example for a sleep, internal timer wake-up.
The mysensors project I'm using has 1,5mA in sleep and 15mA during sensor read and send. That is not usable for battery mode.

[monte]

@heinzv try powering off all peripherals that was used before sleep.
The best source of information concerning nrf5 chips is Nordic's devzone. For example look at this thread: https://devzone.nordicsemi.com/f/nordic-q-a/45355/how-optimize-high-current-consumption-in-sleep-mode-using-nrf52840.
As far as I'm concerned nrf52 library for Arduino contains Nordic SDK, so every function mentioned in Nordic's tutorials and examples should work with Arduino IDE.

[heinzv]

@monte thanks for your hints. I have actually no peripherals attached during my test. The only external peripheral is a Sensirion sensor (not attched during the power save test) has an auto switch off, but no explicit and it gets down to nano amps.(at least far less than 1uA).
I did a lot of research in the Nordic DevZone but was not successfull. It looks like that the mySensors sleep functions for the nRF52 family does not work as I have expected (I'm using the MyBoardNRF5.h/cpp which includes some kind of Nordic power save features). It might have something doto with the UART switchoff which might not works or ...
I'll also try other nRF52840 moduls to ensure it is not because of one product. I'm using a bare nRF52840 from RFstar which has no LED or any other consumer on it.
https://www.aliexpress.com/item/32921970101.html?spm=a2g0o.productlist.0.0.33f77b08ivGnJC&algo_pvid=834cd241-fead-40dd-a423-762eeaad1e6b&algo_expid=834cd241-fead-40dd-a423-762eeaad1e6b-29&btsid=7de062ad-ecfb-4619-bea6-f9bc99c99996&ws_ab_test=searchweb0_0,searchweb201602_8,searchweb201603_52

[Nca78]

@heinzv said in Everything nRF52840:

anybody seen this new Nordic IoT MCU:
https://www.nordicsemi.com/Products/Low-power-short-range-wireless/nRF5340

Looks like NRF52832 is replaced with nrf52833 also, 128K RAM and same radio than nrf52840 allowing the same protocols (zigbee/thread), the same max input voltage (5.5V) and adding bluetooth 5.1. Interesting if it can replace nrf52832 in existing modules.

[monte]

@heinzv by peripherals I mean UART, SPI, I2C and other modules, that can be switched off in NRF52840. Going to sleep mode doesn't disable them, they will still drain current. And as you mentioned by yourself Mysensors sleep function can't be trusted either for doing this for you. I think the best practice will be writing your own sleep function using Nordic's macroses. This way you can be sure everything that needs to be turned off is turned off.
Try reading this thread: https://devzone.nordicsemi.com/f/nordic-q-a/1657/how-to-minimize-current-consumption-for-ble-application-on-nrf51822.

[NeverDie]

Andreas Spiess recently gave his review on on the two new Arduino "nano" 33 BLE offerings (which use the nRF2840):
#298 Four new Arduino Nano Boards: Test and Comparison (Every, 33 IoT, 33 BLE, 33 BLE Sense) – 22:15
— Andreas Spiess

He seems cautiously optimistic about the BLE 33s. From his perspective, now that the hardware is being sold, the onus is on Arduino to make the Arduino hardware libraries run on it in a transparent way, just like all the other Arduino's that we're all familiar with. Hopefully that does happen. In the meantime, and even if it doesn't, there are the mBed libraries.

The only reasons he gives for preferring the ESP32 over the Arduino BLE 33's are the ESP32's faster speed, larger memory, and the ability to do OTA firmware updates. As for where the nRF52840 scores big over the ESP32, the things he mentioned were that it consumes much less power and it can be a USB host.

I'm hoping that BLE 33 OTA firmware updates will be solved by somebody soon and made available as part of the Arduino IDE, just as it eventually was for the ESP8266. I mean Nordic already has a highly secure FOTA, so it just needs to be exposed in a way that people can easily use it through the Arduino IDE. If that never happens, then I'd wager the lack of it will kill the BLE 33. Likewise, if it does happen, it may very well propel BLE 33's success.

Interestingly, Andreas points to a $5 nRF52 Ebyte module as a cost equalizer, so he doesn't seem to see cost as a discriminator, especially not in the long term.

By the way, and unrelated to the above, there is now yet another radio standard vying for IOT adoption. This one, made by Radiocraft: https://www.digikey.com/en/articles/techzone/2019/sep/how-to-quickly-start-low-power-wireless-iot-sensing The energy performance specs sound maybe better than LoRa or SigFox, so who knows? It can do OTA firmware updates by the way. With the marketplace becoming more crowded, FOTA is now an important must-have for being taken seriously. Why do I say that? Any vendor who has a FOTA is devoting at least one entire slide to it in their marketing presentations.

[mfalkvidd]

I wonder how RIIoT gets 3x the range of LoRaWAN, at a speed that is 17x higher. They have about 17dB better link budget?

[alowhum]

@NeverDie Thanks for the summary

Andreas Spiess also never takes things like privacy, and to a lesser degree security, into consideration when he talks about things. For that reason I boycott anything that uses IoT and Wifi in the same sentence.

[NeverDie]

I found a good place to do range testing.... too bad I didn't bring the gear!

[NeverDie]

The nRF53840 PDK announced: https://www.mouser.com/pdfDocs/nRF5340PDKPB.pdf

However, so far I haven't seen even a preliminary datasheet for the nRF53840. The closest I've seen is what's in the above PDF. Based on that, it will be a dual processor arrangement, with the faster processor having 512K RAM. It describes the network processor as "ultra low power," which is also how it describes the 2.4ghz radio. So, it sounds as though the theme will mainly be utilizing less power than the nRF52840.

[monte]

Found this repo: https://github.com/xriss/nrfx. It has standalone nrf peripheral drivers extracted from an SDK so they can be used in any project without using actual Nordic SDK.
Now with release of a PineTime (opensource smart watch based on nrf52832) we can expect many wonderful opensource projects with our beloved MCU

[NeverDie]

@monte Is PineTime the best of the currently available nRF52 watch options? If so, since it's offered at $24.99, I think I may want to order one.

[Nca78]

@monte said in Everything nRF52840:

Found this repo: https://github.com/xriss/nrfx

Gone already ...

@NeverDie said in Everything nRF52840:

@monte Is PineTime the best of the currently available nRF52 watch options? If so, since it's offered at $24.99, I think I may want to order one.

A very interesting project, too bad they are using NRF52832 and not NRF52840, the max SPI speed on ...32 is too low (8MHz) and I'm afraid the LCD refresh will be annoyingly slow

[NeverDie]

@Nca78 Good point! I guess one could take the shell and components and insert a custom pcb that uses nRF52840... But that would be extra work. A pity they didn't go that route in the first place.

It does look perhaps a bit big:

[alowhum]

From what I heard Pine was thinking about upgrading the watch to the NRF52840?

[NeverDie]

@alowhum said in Everything nRF52840:

From what I heard Pine was thinking about upgrading the watch to the NRF52840?

Maybe so. Their website does say: "Note: Final revision may use higher powered hardware including the nRF52840 and/or 16 MB of storage rather than 8 MB."

On the other hand, what's currently on sale in their store is an nRF52832: https://store.pine64.org/?product=pinetime-dev-kit

[scalz]

@NeverDie said in Everything nRF52840:

@monte Is PineTime the best of the currently available nRF52 watch options? If so, since it's offered at $24.99, I think I may want to order one.

There is also the BangleJs/NodeWatch (52832) which is bulkier, more expensive too but with more features, than pinetime. Personally when bulky, I prefer a round shape..still it's quite big, and certainly needs care on UI (round shape vs square display).
This is a very nice project for BLE based smartwatch I think, they have done lot of work on software.

[monte]

@Nca78 said in Everything nRF52840:

Gone already ...

Strange. Yesterday this guy was mentioned in twitter by a Pine64 with regards to his firmware for PineTime. That's how i found that repo. Maybe he realized there was some problems with license?

I'm afraid the LCD refresh will be annoyingly slow

Yes full screen refresh seems to be more like a slideshow. https://www.youtube.com/watch?v=_x6B-L5KOtU
You probably would want to only partially refresh the display.
Now that's sold as a dev unit with unglued back cover so maybe they will initially upgrade to 52840, I don't think it will be that hard, if they haven't produce large batch of this revision. But for sure display with this resolution needs faster SPI.

@NeverDie said in Everything nRF52840:

Is PineTime the best of the currently available nRF52 watch options?

For this price It well may be. Anyway, for tinkering with nrf I guess it may be the best option.

@scalz didn't see this one before. Strange choice of square display in round body. There are plenty round displays available on a market.
I personally like more the approach Pine64 is taking - the lowest possible price and orientation on the opensource community to polish the product. With all the hype they are getting with PinePhone and PienBook Pro I believe they can make it all work.

[scalz]

@monte said in Everything nRF52840:

maybe they will initially upgrade to 52840, I don't think it will be that hard, if they haven't produce large batch of this revision.

well, imho switching to nrf52840 won't be a direct upgrade for them. 52840 has more pins, usb etc so not same pcb for sure, then software support (waiting after community for dev too ??). it will certainly be a new watch I think (if they are the designers of the pcb, no idea).
Still, it is cheap for playing with nrf52832 so that's a good point.

regarding the banglejs watch, yes it's too bad they chose a square display (this wastes some space).
I don't have one of these yet, but considering to play with banglejs ecosystem at some point (for watch I would prefer, but that's my preference, to use BLE for more interactions with phone etc).
In that case I will buy one at least (once it's back in stock) for supporting creator and his team.

I have my opinion on hype and long term reality. Both pinetime and banglejs/nodewatch are opensource. You could for example use banglejs framework on any nrf52832 device/watch, with some coding of course (regarding pins mapping, sensors and peripherals), but that didn't look that hard when I looked at the code.

I would prefer a better looking and more compact smartwatch, but for tinkering and playing they both seem fun.

[monte]

@scalz said in Everything nRF52840:

then software support

Is there any particular changes in software that need to be done to migrate from 52832 to 52840? Or do you mean support for additional peripherals?

[NeverDie]

It turns out that the very first solar powered watch, made by Seiko in 1969, had a side read display:

Though it gives up valuable display real estate, maybe that style would be easier to DIY in a form that wouldn't be too large to wear without embarrassment. I kinda like it myself: in theory I could check the time without having to turn my wrist.

[mfalkvidd]

@NeverDie here is an alternative that uses TEG for power https://www.indiegogo.com/projects/smartwatch-powered-by-you-matrix-powerwatch-2

[NeverDie]

This guy had an interesting idea that could probably be improved upon:

To make the watch thinner he spread the parts over different links in the wristband.
https://www.thingiverse.com/thing:718989

[NeverDie]

@mfalkvidd Dave Jones reviewed that very watch and was fairly negative about it:
EEVblog #945 - Thermal Powered Smartwatches Are GIMMICKS! – 29:53
— EEVblog

Even so, it looks as though they raised over two million dollars!

[mfalkvidd]

@NeverDie I watched a vlog (unfortunately in Swedish) about it about a week ago. The owner had used it for two months without charging it and was very enthusiastic about it. He said he used it for getting notifications, so he must be using the bluetooth feature.

Dave does have a point though that swapping the battery every 2-3 years isn't that cumbersome.

On the other hand, the charging capabilities of the Toyota Prius might have been considered a gimmick when it was introduced in 1997, and today we have electric cars with fairly long range. Technology gets better, and must start somewhere.

[NeverDie]

@mfalkvidd I'm impressed that they've pre-sold over ten thousand of them.

Changing a watch battery isn't particularly easy, especially on a waterproof watch, because AFAIK doing so generally ruins the waterproofing seals. Dave Jones may have underestimated the hassle factor.

Also, there's a watch that was made by the authors of "The art of electronics" that the authors say consumes just 1 microamp, and that was more than a decade ago.

So, bluetooth aside, a TEG should generate more than enough to run a watch like that. I don't doubt that at least some amount of bluetooth or ANT or some other kind of radio communications could be supported. Maybe not a lot, but at least something.

It's easy to forget that the original consumer LED watches would light up only when you pressed a button, and yet they sold anyway. If you did it that way, then it should be easy, and it would leave more of a budget for the radio communications.

[Nca78]

@NeverDie I think you are missing the point about the battery. Dave Jones was right as the energy produced by the watch over several years was similar to the one from a coin cell. And before those years pass we all know what happens to electronic devices: they get replaced. So the problem of battery change they pretended to fix was not a real "problem" as the product life is shorter than the battery life. It had very limited functionality and only manual synchronization with the smartphone, and a very basic app.

It's probably a similar thing with the new version, solar panel increases the available power but it's still in the uA range and functionalities are very limited, the "full color" lcd has no backlight, GPS use must be limited to a few mins per day, same for heart rate monitoring etc. So in the end a watch with similar functions and a li-ion battery would be smaller, half the price and only need a charge every 6 months. 2h of charge twice a year is far from a constraint... In addition the battery powered watch would allow you to run constant heart rate monitoring, have long GPS sessions like 2 hours of running etc etc if you accept to charge more often.

It's not as bad as before but it still feels like they made the watch because they needed a product to use the technology, and cut down the functionalities until power consumption was low enough to fit the technology. While it should be the opposite, technology should have been improved until it was able to power a smartwatch with "normal" functionalities.

I'm pretty sure many users of the new version will end up removing the watch from their wrist to expose it to the sun, and that it will last way longer than the charging time of a typical smartwatch

[NeverDie]

@Nca78 Thanks! You said it better than Dave Jones did. You've convinced me.

[xmonika]

I have read this thread, have bought a few E73-2G4M08S1C modules for experimenting, downloaded platformio and tried to flash it. I recognized I am not able to do it with my STM32 link V2 programmer in platformio. Could somebody summarize what are the current options to flash NRF52840? Is there a way how to use STM32 link V2 or we just need to IDE from Arduino to Platformio and invest into new programmer (DK/BMP)?

[NeverDie]

@xmonika I like the nRF52840 SDK. It includes an official j-link and can also be used to burn software to any attached nRF52840 by simply dropping the hex file onto the j-link virtual drive. Of all the options, I find it the easiest, but that's me. Other people use and seem to like the st-link or or black magic probe or dodgy copies of the j-link or clones of black magic probe. Different people seem to like/prefer different things. I read that Particle now has a programming tool as well for its Xenon device, which is basically their version of the nRF52840, and I think I may have read that it works with non-Particle nRF52840's as well.

There's also BLIP, which is new and sounds kinda interesting: https://www.crowdsupply.com/electronut-labs/blip

[Mishka]

@scalz said in Everything nRF52840:

@NeverDie I think you need to hold it, but it looks there is "coded" holes/slots for helping and correct positioning.

You may want to use TC clip for long-time debugging or odd boards like this:

[Mishka]

@alowhum said in Everything nRF52840:

To what extent Bluetooth has useful smart home profiles
To what extent Arduino devices could present themselves as smart home devices using those profiles.

Well, the BLE has a lot in common with REST. You have to have one or more central devices (clients) which will query peripherals with sensors and actuators (servers). Communication is P2P, but broadcasting is also supported to some extent (various beacons are well known examples).

If thinking about it like a RESTful sevice, there is a number of API which were standardized. They call it profile, like in, for example, the Heart Rate Profile. The standard just assures that any heart rate monitoring device will talk the same protocol as any other one - that's it. I don't think there is many standard profiles for smart home devices (if any). At the same time, there is the Project Connected Home IP.

Of course, there is nothing which may prevent somebody to implement his own interface. If it will be successful enough, it will be later possible to contact the SIG group and promote it to a standard.

Please also note, that for serious boradcasting there is the Mesh. In a nutshell it works similarly to Ethernet switches. Interesting side effect is that it's possible to build a Mesh network physically wide thus delivering packets over long distances. Of course, if you want to go global, the IPv6 will be the right choice to go. It will require a standalone BLE enable router though - it will connect the devices to the Internet.

To what extent older Bluetooth chips can work with newer device profiles (it would seem a software upgrade should be enough?)

As long as they support Bluetooth Low Energy - i.e. version 4.2 or above.

[Mishka]

@Nca78 said in Everything nRF52840:

A very interesting project, too bad they are using NRF52832 and not NRF52840, the max SPI speed on ...32 is too low (8MHz) and I'm afraid the LCD refresh will be annoyingly slow

It might be also interesting to employ the Sharp LS012B7DD06 which is a round 240x240 6-bit color memory display consuming 11 µW in static mode. It will be far away of the PineTime's $25, but with the CryptoCell, NFC and other stuff it might worth it.

Shall we create a repo?

[NeverDie]

@Mishka

The idea I settled on is using a micro-usb connector to make my programming connections. It's cheap and the footprint is small.

I've posted about it previously, but it got a lot of pushback over the concern that people will think it's a functional usb and plug it into a charger. However, I won't be forgetting, so it hasn't been a problem for me. I suppose that if I were to hand a device over to a layman, I'd probably plug the connector with a drop of superglue (either that or simply de-solder it), since a layman wouldn't be programming it anyway.

That said, micro-usb connectors aren't super-easy to solder, so I'd like to find something equally tiny that is.

[Mishka]

@NeverDie For something which is very generic I'd vote for the Cortex 10 pin debug connector. It is as small as Micro USB, very cheap (you may also do not install the connector itself and left that for other users), versatile (may be angled or straight) and - what's very important - it is standard. And, while in this topic, the bonus: it's compatible out of the box with the nRF52 devkits.

[NeverDie]

@Mishka said in Everything nRF52840:

I'd vote for the Cortex 10 pin debug connector

You mean like the connector on this?
https://www.openhardware.io/view/510/Multi-Sensor-TempHumidityPIR-LeakMagnetLightAccel

That's what I started with. But I really only need 5 pins: SWD, SWO, Tx, Rx, and GND, so 5 of the 10 pins are wasted.

I went with the boxed connector, which is huge, to prevent plugging it in wrong. I probably should have gone with the non-boxed connector. Even so, it's still huge.

I could probably get by with just 4 pins by dropping the Rx pin. Thinking back on it now, I don't think I ever actually used the Rx connection. I've definitely used the Tx though for serial print debugging.

I think the easiest/best idea might be just using 4 castellated pads and pressing up against those with a side connector, similar to what TC's edge connector does or what an esp8266 burner does (but ideally with closer spacing):
)

[Mishka]

@NeverDie That's right. You may want to use open version which is much smaller indeed.

Also, for nRF52 only three pins are required: SWDIO, SWDCLK, and VTref. All the three are very conveniently located in close proximity on pins 2, 4 and 1:

Such, for a tiny custom board a 2x2 pin header, 1.27 pitch can be used w/o breaking compatibility.

[NeverDie]

@Mishka How about this?
https://www.amazon.com/CQRobot-Programmer-Testing-Support-Programmer/dp/B07BWFJL31

Either 4 pads on one side or 2 pads on each side of the PCB. Very inexpensive. Not sure if they make a 4 pin clip, but if so, that would be ideal.

Maybe if instead of pads you went for 4 through-holes it would even self-align?

[NeverDie]

This is quite clever:
Connectorless 1x6 mini ISP connector without Pogo pins – 00:15
— Albert van Dalen

If you simply stagger the through-holes then a regular block of header pins will fit through and hold itself in place. No pogo pins required.

[Nca78]

@NeverDie said in Everything nRF52840:

If you simply stagger the through-holes then a regular block of header pins will fit through and hold itself in place. No pogo pins required.

I'm not so sure about the reliability of this ... It's not very difficult to make an adapter using pogo pins, you just need to use 2 similar pcbs to align them properly.

Another option is to use smaller headers (2mm or better 1.27 mm) and an adapter from selected spacing to 2.54mm header: cheap and compact connector for the board, cheap adapter and reliable connection.
For example on these adapters you can solder a SMD header on the 1.27mm spaced side and have 2.54mm connectors. You just need to have the opposite genre 1.27mm header on the board and you're done.
https://www.aliexpress.com/item/32855731928.html

[nagelc]

@NeverDie
There is an article on hackaday about this type of clamp that even has a KiCAD footprint. I bought one of the clips, but haven't tried it out yet.
https://hackaday.io/project/165917-soicbite-programmingdebug-connector-footprint

I also tried this one from Adafruit;
https://www.adafruit.com/product/4048
small, jlink-mini compatible, and polarized.

So far, my preferrred solution is a 6 pin jst-sh connector.
small. 3v3, gnd, swdio, swclk, tx, rx
and polarized.

My old eyes get tired of confirming I have the pins on in the right direction. Polarization is really nice.

[NeverDie]

@Nca78 Yup, I too would worry a bit about the long-term repeatability of the staggered pin approach: after you hook it up a few times, maybe the metal on the throughhole would have scraped off due to the friction fit?

I was thinking that on an "as small as possible" type of board like on Mishka's current project that the castellated connection would have the smallest footprint. On a larger board where space doesn't matter, then, yeah, I would go for some kind of pinned connection. For instance, on my 10 year motion detector, the board size is huge due to just the batteries, so there is plenty of free space to plunk down a connector:

https://www.openhardware.io/view/499/10-years-wireless-PIR-Sensor-on-just-one-set-of-3-AAs

Yet, when it came to mount it in a case, that connector got in the way, and I had to redesign it to use the usb connector that everybody but me seemed to hate on the backside, fitted between the batteries. I suppose I could have used some kind of edge pin connector though if it were small enough.

It would be fun to make a board the same dimensions as an esp8266 or esp32 or wroom module so that I could use one of the test/burner jigs that's designed for them to make the castellated edge connections.

[NeverDie]

@nagelc said in Everything nRF52840:

There is an article on hackaday about this type of clamp that even has a KiCAD footprint. I bought one of the clips, but haven't tried it out yet.
https://hackaday.io/project/165917-soicbite-programmingdebug-connector-footprint

I couldn't find where to buy that soic bite. Is it even for sale anymore?

[NeverDie]

On the other hand, the JST-XSR connector might not be a bad way to go. At 0.6mm pitch, a 4 wire connector is just 3mm wide:
http://www.jst-mfg.com/product/pdf/eng/eXSR.pdf?5e312adac5a05
It's seems very hard to find for sale though.

AFAIK, it's the smallest jst connector there is.

[BearWithBeard]

@NeverDie I don't think that SOICbite has ever been sold. It's just a conventional SOIC-8 test clip, that may need some modification, like filing away some of the plastic in front of the hinge or at the tip. I like the idea of this method because, apart from having a small footprint, they are super cheap (even less than 2 USD/EUR incl. shipping from China, like this one) and it doesn't require additional parts for every single PCB for a one-time job.

I'm currently designing a PCB (not nRF52840-related though) with the SOICbite connector on it and have some clips on order, to see how well it works. Might take a while until I reveice them, but I can report back as soon as I tested them.

[orhanyor]

hey guys. I'm testing couple of nrf52840 modules. so far i was able to test raytac mdbt50q ipex and e73-2G4M08S1C modules with basic rssi value.
so far ipex version looks abit better but at a cost of external cable and antenna where e73-2G4M08S1C is compact and difference is not that significant.
i later saw fanstel products, particularly interested in BT840F model because reported range is significantly better than the BT840 model and the only difference is the antenna design between them.

Considering this difference 840F might be way better than the e73-2G4M08S1C. Has anyone able to compare them or test them directly?

[NeverDie]

@orhanyor I compared the Fanstel BT840F to the Ebyte with the trace antenna, and the Fanstel was better. I expect the trace anenna is better than the chip antenna on the module that you referred to, so by the transitive property of inequality, I expect the Fanstel would be better than it.