nRF5 action!

scalz

840 is pretty new, and if i'm not wrong, final version is planned in few month for end of year (it's a bga package, and preview version), there are a very few modules actually, but expensive to order, for a beta though. So if there is a support for it in Arduino, it could be not complete yet. i'll tell you more when i'll get mine :)

NeverDie

OK, so if we wanted to make something today (or, at least before the end of the year), what module should we use now such that the nRF52840 will be an easy upgrade when it arrives later and sells for (hopefully) cheap on Aliexpress? Would it be the nRF51422 (which I don't believe does long range)? In fact, I'm not sure whether Nordic has anything long range before this nRF52840. That's kinda why I was looking at the cypress or silicon labs product lines, not knowing that Nordic had something in the wings already.

When it does become available, it looks as though it will be around $7 for quantity 1: http://www.mouser.com/ProductDetail/Nordic-Semiconductor/nRF52840-QIAA-R7/?qs=sGAEpiMZZMve4%2FbfQkoj%252bGh7uW9JJ8VYnj7XFjezTdQ%3D

Actually, it says 16 week lead time, so that's more or less consistent with what Scalz said.

NeverDie

This whole topic has been brewing in the back of my mind for a couple years now:
https://forum.mysensors.org/topic/1788/nrf51822-as-an-all-in-one
and
https://forum.mysensors.org/topic/3836/anyone-besides-me-looking-into-long-range-bluetooth-for-their-wireless-nodes

With the nRF52840, it looks as though the moment has finally arrived to tie it all together and give it a try. :)

I just have no idea where to even begin though. Just order the nRF52840 preview DK? Is it fairly quick to get something up and running, or is it a fairly steep learning curve?

NeverDie

@Terrence said in Minimalist SAMD21 TQFP32 Pro Mini:

@NeverDie I love the new 51840 (the one that does the long distance, the 832 is the High throughput chip) Please work with the 840.

I have the nRF52840 Preview DK, but have not fired it up yet. Still trying to understand how to code Bluetooth.
http://www.nordicsemi.com/eng/Products/nRF52840-Preview-DK.

SiLabs has an interesting Gecko BT5 chip as well.
http://www.silabs.com/products/wireless/bluetooth/blue-gecko-bluetooth-smart-socs

Even though you said 840 rather than 832, might the 832 yet still be a decent way to get started?
https://www.adafruit.com/product/3406
And then transition to the 840 when it becomes more available? At least the 832 is in the same nRF52 samily as the 840.

My hunch is that bluetooth long range is going to win, because regular bluetooth is already baked into everything.

Terrence

@NeverDie I think the 832 would be a good start until the 840 is available. I think all programming will be the same for when we switch over the 840. I am not 100% sure though.

I have been looking at the AdaFruit 832 since it came out, but have not pulled the trigger yet, as I have not yet opened my 840 dev kit.

We can definitely program the AdaFruit 832 with Arduino.

I agree with you that BT5 long range is the way to the future due to it's low energy, great built in security, long range and no additional chip required.... and >>because regular bluetooth is already baked into everything.

scalz

I agree with @Terrence ;)
For end users, i think you won't see a big diff in Arduino when 840 will be released. but they are not really the same inside..
Also 840 is Nordic flagship, so it won't be as cheap as nrf51 series soon. And the same applies to 832 which is still affordable regarding specs. That's why they've released the 810, for lower cost, same RF perf as 832, but less memory.

Terrence

@scalz said in Minimalist SAMD21 TQFP32 Pro Mini:

same RF perf as 832, but less memory

but no long range right?

So scalz it is your understanding that the coding will be the same on the 832 and when we start getting the 840, but the distance will just increase?

NeverDie

I tried looking at the description on Mouser for the nRF52840 Preview Development Kit,

http://www.mouser.com/ProductDetail/Nordic-Semiconductor/nRF52840-PDK/?qs=%2Fha2pyFadujrE9AVVmPVBpOa%252bRshwNjVw0YuauBixIIKnbHMaxozcw%3D%3D

and it's not obvious as to whether it even comes with any of the modules. So, I guess I could get it to do mcu tricks, but I'm wondering now whether it can even communicate with anything wirelessly until 16 weeks from now?

Also, it's not clear to me yet whether the Nordic modules are truly "long range" rather than just better range. I get the impression they do some coding gain without actually increasing transmit power. That's fine, I suppose, although the datasheet (http://www.mouser.com/ds/2/297/nRF52840_OPS_v0.5-1074816.pdf) does describe the link budget (with coding gain?) as being only 104dB, which isn't exactly awesome.

Terrence

@NeverDie
The nRF52840 PDK is a versatile single board development kit for Bluetooth 5, Bluetooth low energy, ANT, 802.15.4 and 2.4GHz proprietary applications using the nRF52840 SoC. This kit supports development for the nRF52840 SoC.

http://www.nordicsemi.com/eng/Products/nRF52840-Preview-DK
https://devzone.nordicsemi.com/blogs/1093/

Cool drone video of 840 long range.
https://www.youtube.com/watch?v=w4PbxVwg83M

tbowmo

@Terrence

That's pretty impressive..

NeverDie

A better test would have been to test the range while still maintaining a sufficiently low packet error rate. Their test criteria was just "still receiving packets," which could have meant a very high packet error rate, which isn't really useful information.

At the end of the day, it's the link budget that seems to matter most in comparing different radios. The higher the link budget, the better the range (in apples to apples comparison, where a particular packet error rate is what determines practical "range").

So, for comparison, a LoRa radio has a link budget as high as around 156dB (that's with the lowest bitrate and the highest coding gain). It's arguably far more than you need for home automation, but then again, I'd rather have overkill than underkill.

Nca78

@NeverDie said in Minimalist SAMD21 TQFP32 Pro Mini:

A better test would have been to test the range while still maintaining a sufficiently low packet error rate. Their test criteria was just "still receiving packets," which could have meant a very high packet error rate, which isn't really useful information.

I think at the moment the guy says he doesn't see a single drop, or something like that. I understood "all packets arrived".

NeverDie

I notice though that they show the link budet for the 840 is 111dB. Well, that's encouraging. The datasheet says "104 dB link budget for Bluetooth low energy," so I guess they're using a different mode.

NeverDie

I was really keen to try the nrf52832, in lieu of the nRF52840 until it became available, because of the OTA wireless update capability. Then I dug a bit further, and on the Adafruit website (https://learn.adafruit.com/bluefruit-nrf52-feather-learning-guide/using-the-bootloader) it says "This option is not actively support nor recommended by Adafruit, and we are still working on making this as safe as possible for users via our Bluefruit LE Connect application. Use OTA DFU at your own risk knowing you can brick your device and may need a Segger J-Link or similar device to regain control of it!"

NeverDie

I have the Adafruit Feather M0 RFM69 nominally working doing Blink plus a little more. Adafruit appears to provide zero demo code for the LowPowerLab library, though it does for the RadioHead library. Therefore, I haven't yet figured out what I need to change in my code to make it talk to the Radio, but that's next.

So far I'm not at all liking the "two in one" usb connection: one for programming it and one for the serial console. The transition and sharing between them only rarely goes smoothly. Not sure if that will ever get ironed out over time or whether two physically different usb connections (as some of the other arduino boards provide) would be better.

NeverDie

OK, I've got the Adafruit Feather M0 RFM69 radio working now. To make it work with the LowPowerLab library, you need to delete the following from the RFM69.h file:

#elif defined(__arm__)//Use pin 10 or any pin you want
  #define RF69_IRQ_PIN          10
  #define RF69_IRQ_NUM          10

and replace it with:

#elif defined(ARDUINO_SAMD_FEATHER_M0) // Feather M0 w/Radio
  #define RF69_SPI_CS              8
  #define RF69_IRQ_PIN             3
  #define RF69_IRQ_NUM             3
  #define LED                      13

That's all there is to it! :)

scalz

@NeverDie
all you have to do is set your defines for mysensors and this should work out of the box :)
about the usb, weird, i've no problem here. what problem do you have? here it works smoothly (with custom board, but i have also an adafruit m0 proto, worked well too)

NeverDie

@scalz
Well, first, for the benefit of others who may be reading this but who aren't familiar with the two USB paradigm, this is how it looks on the Arduino Due:
alt text
There are two physically distinct USB connections, but you can have both connected to your computer at the same time. The "Native USB Port" lets you read the console output, and the "Programming port" is for uploading new sketches. It works fine. I like it.

So, with that as background, on both the Adafruit Feather M0 SamD21 and the Sparkfun M0 SamD21, there is the same concept, but only one physical USB port. So, let's say I just uploaded a sketch and then want to immediately switch to the "Native USB Port" so that I can read debugging information. Well, that doesn't happen automatically (as it should really). Instead, I get an error message which reads, "Couldn't find a Board on the selected port. Check that you have the correct port selected. If it is correct, try pressing the board's reset button after initiating the upload.
processing.app.SerialException: Error opening serial port 'COM45'."
Then, I have to go to the Tool menu and manually select Com44 and then open the serial console. Well, by then, the debug info would have already passed by, because it doesn't reboot upon opening the serial console. So, I've added a delay countdown to give me time to do this.

And, by the way, every single time I upload a new sketch, it always reports, "An error occured while uploading the sketch," even though if I look at the details, it shows that it uploaded and even verified the upload, and even--sure enough--it really did upload. So, that part is really beginning to bother me, even though maybe it shouldn't. It's true for both the Adafruit and the Sparkfun Samd21 boards.

Anyhow, it looks like the Hackaday guy did a board with two physical USBs, and maybe that's a good idea? alt text
Or maybe it's still just one USB connection and three different connector types? Not really sure.

NeverDie

Anyhow, I guess what I could do is simply write my serial debug output to a pair of Rx and Tx pins, and then I could side-step the whole mess without getting entangled in it. Not very elegant, but it would serve the purpose until I learn the ins-and-outs better.

tbowmo

@NeverDie

You will always have the issue of USB connection, when using a native USB device, because it will re-enumerate on the USB bus whenever you reset the device.

That's also why you have to put the following code

while(Serial) {}

In the setup routine of sketches with native usb devices, if you expect to catch all debug messages from the start. This behavior does not change if you have both native and a programming port.

nRF5 action!

14

11.7k

11.2k

113.0k