nRF5 action!

[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:

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

[NeverDie]

By the way (and it's just an as yet an unverified first impression), but it seems like the RSSI received on the Feather RFM69 is much better than on an atmega328p RFM69 combo. If that bears out, then all by itself it might be reason to switch. Anyone else get this impression, or not?

[NeverDie]

@tbowmo said in Minimalist SAMD21 TQFP32 Pro Mini:

while(Serial) {}

Cool. I just tried it. It turns out it's actually

while(!Serial) {}

but it works great. Thanks!

[scalz]

about rfm69 and better rssi, it could also be related to ground plane size of the board.
and for mcu, yep no need of the programming port. native is enough if there is the bootloader.

[NeverDie]

@scalz said in Minimalist SAMD21 TQFP32 Pro Mini:

@NeverDie
all you have to do is set your defines for mysensors and this should work out of the box :)

I just now noticed that @Sweeman already did: https://forum.mysensors.org/topic/6908/adafruit-feather-m0-rfm69hcw-with-mysensors/6