💬 MySensors NRF5 Platform

[Nca78]

Hello,

has someone successfully used VisualMicro with the MySensors NRF5 boards ?
In the board selector dropdown list I can select any board, including NRF5 boards like "Generic NRF51" or "BBC Microbit", except when I select MySensors NRF51 or NRF52 boards, then it's not doing anything and keeping the previous selected board. I have a message in the status bar saying "the first available board has been selected" and that's all, I don't find anything related to VisualMicro with this error message in Google.
I have tried with both 0.1 and 0.3 versions of the boards, and with both "Arduino 1.6/1.9" and "Visual Micro (No IDE)" IDE selections.

[nagelc]

I like VisualMicro and think I got this to work but was mostly using plain Arduino to keep things simple while figuring it out. I haven't worked on an NRF5 board for a few weeks. I will check my setup. Might be a day or two before I can get back to it.

[nagelc]

@nca78
No. I was mistaken. I have the same issue as you. I used the arduino program with the MySensors NRF5. I would like to get this to work also. Please post if you find a solution.

[Nca78]

@nagelc thank you for taking the time to check, I'll go with Arduino for NRF5 at the moment and keep that for a moment when I'll be more keen on fixing technical problems :)

[Shodney]

What are people using for a gateway with these?

I'm currently using this from @NeverDie , which seems to work for the most part, but I'm getting a lot of connection errors:

2018-04-18 18:27:35 ERROR (Thread-2) [mysensors.gateway_tcp] Receive from server failed.

2018-04-18 18:27:35 INFO (Thread-2) [mysensors.gateway_tcp] Closing socket at ('10.0.50.100', 2323).
2018-04-18 18:27:35 INFO (Thread-2) [mysensors.gateway_tcp] Socket closed at ('10.0.50.100', 2323).
2018-04-18 18:27:35 INFO (Thread-2) [mysensors.gateway_tcp] Trying to connect to ('10.0.50.100', 2323)
2018-04-18 18:27:35 INFO (Thread-2) [mysensors.gateway_tcp] Connected to ('10.0.50.100', 2323)
2018-04-18 18:27:52 INFO (Thread-2) [mysensors.gateway_tcp] Closing socket at ('10.0.50.100', 2323).

They seem to come up about 75% of the time when the gateway receives a message from a node.

I thought it might be a power thing, so I messed around with a few caps and a separate power source for the hat but nothing seems to have made a difference.

Everything seems to work despite this, but I don't really want my log to be filled with these errors if I can help it.

Has anyone attempted to build a wired gateway or anything similar?

[Omemanti]

@shodney i used this one for a couple of tests. I resoldered the caps near the top and connected a new antenna. Works pretty well for testing purposes. I expect some pcb's a week ago😏 for some further testing.

[NeverDie]

The gateway I've used has been:
https://www.openhardware.io/view/491/PA-LNA-nRF52832-ESP-LINK-Shield-for-Wemos-D1-Mini-ESP8266
I haven't noticed any problems.

[nagelc]

@nca78 I posted to the VisualMicro forum. They responded right away. They are going to fix it in the next release. Something to do with internal naming conventions.

[alowhum]

I've created a BME280 node along the lines of the NRF5 beginners guide I posted.

But something odd is happening. The node works great for about 8 hours.. and then it stops working.

I already changed the power supply, but the same thing happens.

Could it be a memory leak?

[NeverDie]

@alowhum I'm not sure the function call that reveals that amount of free memory available, but I'm sure there must be one. Logging that as a diagnostic would reveal whether you have a memory leak in your code.

[nagelc]

@nca78 I downloaded the latest update to VisualMicro last night and had mixed success. I can now pick the MyboardNRF5 boards, but run into a compile error where it cannot find the build directory. Have you tried it yet?

[Nca78]

@nagelc not yet I will give it a try tomorrow.

[NeverDie]

@d00616 Will everything work the same on the nRF52840?

Has anyone tried it?

[d00616]

@neverdie said in 💬 MySensors NRF5 Platform:

@d00616 Will everything work the same on the nRF52840?
Has anyone tried it?

Yes. At the moment, I have no time to finish my work on supporting the nrf52840. In my Repository https://github.com/d00616/ArduinoHwNRF5 you can find my last state. All 840 ports P0 (0-31) and P1 (62-64) should be usable as GPIO but there is no support using the P1 ports with any pin mapping component like UART, I2C....

The second change in my last commit is mcuboot. A bootloader compiled with Zephyr. Firmware can be upgraded OTA using MYSController with some enhancements (ask @tekka about the correct version). Firmware transmision works well but, at the moment my mcuboot port don't work. The memory layout between zephyr and arduino is different. The application cashes after start. I think it's a problem with different memory layout between Arduino and Zephyr.

For NRF52 MCUs the memory problem can be solved by moving the interrupt vector register to the IV location in the image and setting the SP register to the correct value. Maybe the starting code of ArduinoHwNRF5 is the correct position, so this mcuboot version can be used for Arduino and Zephyr Software.

If moving the SP to the correct position doesn't help, for NRF51 the Arduino linker scripts must be changed. I think there is only a small change required, but I have no idea about how to do this.

It's welcome if someone can finish this work.

[NeverDie]

@d00616 Argh, that's a pity if the pin mapping doesn't yet work, because it means I won't be able to do the drop-in upgrades from the Fanstel nRF52832 to the Fanstel nRF52840 as I had hoped to do. It means I would have to re-do all the PCB's if I want to upgrade to nRF52840. :( I guess I would have to figure out some other way to remap the pins.

[nagelc]

I have a couple of BT840s on order, also hoping for the easy upgrade. It looks like the pins have the same functionality as the BT832 except for pins 11, 12, and 13 (and 14 if you weren't using it for reset). I wonder why they did not just keep them all the same.

[d00616]

Sorry wrong wording. All P0 ports can be mapped. But to map P1 ports there is additional code required which does'n exists in the Arduino port.

[d00616]

If someone try to work on mcuboot compatibility. Maybe only the IV is the problem. For NRF52 the IV can be moved to the beginning of the image, but the nRF51 IV is in the mcuboot rage.

[NeverDie]

@nagelc According to the Fanstel documentation, "Except the 19 pins in solid black dots, BT840F and BT832F is hardware pin to pin compatible. " So, if I'm understanding correctly, it appears that the the castellated pins should be exactly the same, and those are the only ones I'm able to solder anyway.

This is quoting from their v1.1 datasheet, which is dated August, 2018: https://static1.squarespace.com/static/561459a2e4b0b39f5cefa12e/t/5b75e95daa4a99c02bbce364/1534454116506/BlueNor_BT840F_datasheets.pdf

[NeverDie]

Oh, I see now. p18 is the reset pin on the nRF52840 now, not p21 as on the nRF52832. However, both share the same physical location on the Fanstel modules. OK, so in that case, I guess it only matters if you want to use the reset pin as an gpio pin instead. Likewise, the LED has the same physical pin location on the module, but it's pin 020 on the nRF52832 and pin p13 on the nRF52840.

Well, if we can just somehow manage to upload a simple blink sketch to the nRF52840 from the Arduino IDE, then I suppose I can live with wherever else is different. It's getting some kind of "hello world" compiled, uploaded, and running that's always the hardest part with these things. Once that's in place, one can chip away at the rest of it. i.e. it looks like I can re-use my same PCB's with the nRF52840 and just make some software changes to make it work. I'd still count that as good news. :)