Everything nRF52840
-
For those who haven't yet tried it, platformio has an "arduino" mode where it can program an nRF52840 very much along the lines that you would an arduino. Since it supports the nRF52840, I'd say it's a natural upgrade from the Sandeep Mistry library, which you don't really need to use anymore if you don't want to (though maybe it's still relevant for mySensor's compatability). At least to me, platformio seems much easier to use and much less of a learning curve than Segger Embedded Systems, Eclipse, or MBed. For anyone used to Arduino, it will seem very familiar.
-
Has anyone been able to send a packet with a payload of greater than 85 bytes using an nRF52832/nRF52840? According to the datasheet, a 255 byte payload should be possible. Yet, even if I set MAXLEN to 255, the payload seems to be truncated at 85 bytes. So, I'm curious as to why I'm not able to get a larger payload transmitted, and thus I'm wondering whether anyone else here has succeeded at it.
Anyone?
-
Sorry for cross-posting.
I started with nRF52 a few days ago. I have the Nordic nRF52 SDK board (PCA10056) with a nRF52840 operational as a MySensors serial gateway together with Home Assistant on a RaspberryPI (with Hass.io). I am using the Arduino nRF5 and the sandeepmistry nRF5 board libraries.
Some issues:
- It looks like it only works in debug mode. But in debug mode, both debug messages and gateway messages appear on the usb port. Homes Assistant is not confused by the debug messages.
- Leds are not working.
- The programmer on the Arduino IDE is not working for me ("No J-Link" error, while there is a J-Link interface available), so I export a HEX fle form Arduino IDE and program the board with the nRFConnect tool from Nordic.In order to solve the issues above, I installed the Segger environment. With the board you get a free license from Nordic and you can do some fancy debugging. I also looked at Keil but that is a no-go for me. With Segger, I can upload a simple Blink example from Nordic to the board an debug it. I am now struggling with importing the MySensors library sources in Segger. If someone did this before, please let me know (!). Once this is done, I can debug the code on the hardware. May be I could fix the issues, like non blinking leds, by inspecting the code and watch for configuration issues of the ports (the addressing of the ports seems to be OK). But being able to debug would be a big plus in future development.
Off course, once the gateway is working with blinking leds, I want to replace the development board with something cheaper from E-Bay et al. I want to give this one a try:
https://www.aliexpress.com/item/Nordic-nRF52840-module-Bluetooth-low-energy-long-range-500-meters-bluetooth-5-0-PCB-IPX-Antenna/32953759053.html
The plus of this board is that you can use an external 2.4 Ghz antenna. And it has the newest 52840. If you are creating a gateway, I suppose your budget will not depend on $3 price difference.Once all that is done, I want to turn my Nordic Thingy (https://www.nordicsemi.com/eng/Products/Nordic-Thingy-52) into a MySensors device. Seems like doable. But someone has to do it.
-
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 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 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. -
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.
-
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. :)
-
For those who haven't yet tried it, platformio has an "arduino" mode where it can program an nRF52840 very much along the lines that you would an arduino. Since it supports the nRF52840, I'd say it's a natural upgrade from the Sandeep Mistry library, which you don't really need to use anymore if you don't want to (though maybe it's still relevant for mySensor's compatability). At least to me, platformio seems much easier to use and much less of a learning curve than Segger Embedded Systems, Eclipse, or MBed. For anyone used to Arduino, it will seem very familiar.
@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 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.
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.
-
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.
@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 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.
-
Yes I saw it. Very hardcore.
-
You can now run mecrisp-stellaris FORTH on the nRF52840-DK: https://github.com/rabbithat/FORTH_NRF52840-DK
:)
-
@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 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.
@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 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.
@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 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.
@neverdie i'm comparing it with core51822 module which also has pcb antenna
-
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. :-)
