💬 MySensors NRF5 Platform

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:

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

[32m2018-04-18 18:27:35 INFO (Thread-2) [mysensors.gateway_tcp] Closing socket at ('10.0.50.100', 2323).
[32m2018-04-18 18:27:35 INFO (Thread-2) [mysensors.gateway_tcp] Socket closed at ('10.0.50.100', 2323).
[32m2018-04-18 18:27:35 INFO (Thread-2) [mysensors.gateway_tcp] Trying to connect to ('10.0.50.100', 2323)
[32m2018-04-18 18:27:35 INFO (Thread-2) [mysensors.gateway_tcp] Connected to ('10.0.50.100', 2323)
[32m2018-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. :)

NeverDie

@d00616 I guess this is what you mean by Zephyr? http://docs.zephyrproject.org/boards/arm/nrf52840_pca10059/doc/nrf52840_pca10059.html?highlight=nrf52840

d00616

@neverdie said in 💬 MySensors NRF5 Platform:

@d00616 I guess this is what you mean by Zephyr? http://docs.zephyrproject.org/boards/arm/nrf52840_pca10059/doc/nrf52840_pca10059.html?highlight=nrf52840

With Zephyr, I mean the Zephyr OS. This board definition is part of a newer Zephyr Version, I had used to compile mcuboot. This was ~7 Month ago.

scalz

@NeverDie I think you might have no problem at getting blink working. On this pic, the nrf52840dk was running mysensors https://forum.mysensors.org/post/79460 (it was a simple counter test).
But sure nrf52840 is "new", and each new mcu always needs time to get all features working..+the maintenance..the more the merrier, not sure :smile:

NeverDie

@scalz said in 💬 MySensors NRF5 Platform:

nrf52840dk

You're sure it was the nrf52840dk? I didn't think it had been released until fairly recently, whereas your post was 10 months ago. Maybe it was the pre-dk? I guess either way it would support your point. I just want to be sure you didn't mean the nrf52832dk?

I guess since the MCU seems to be the same (?), there's a good chance it may work.

💬 MySensors NRF5 Platform

13

11.7k

11.2k

113.1k