Hi everyone,

I've just discovered MySensors a few weeks ago and I find it a very interesting project.
As I like to understand it before trying to setup a MySensors network myself, I have been looking at the code on GitHub.

ARM mbed is a programming environment aimed at enabling easy programming for embedded systems, just like Arduino, but with an approach closer to standard programming (use of actual main function and use of object oriented programming for managing I/O).

My question is : do you think porting MySensors to the ARM mbed platform would be a good idea ?

There are lot of dev boards like the STM32 Nucleo board or the TI TIVA Launchpad that can be programmed using ARM mbed but not with Arduino. As they can all be basically programmed with the same C programs (the device specific functions are managed in the mbed core), porting the project to the mbed platform would enable lots of dev board to be compatible with MySensors at once.

Regards

Solved!

I fixed it by connecting the radio directly to the battery without using the DCDC boost I use for powering the Arduino Pro Mini.

Hi,

I currently have a couple of MySensors boards with Arduino Pro Mini + nRF24 radios communicating with a Raspberry Pi Gateway.

Today, I wanted to add a new sensor to my network (moisture level sensor). I placed on my protoboard the Arduino Pro Mini, a DCDC boost, a connector for the 2xAA battery and the nRF24L01+, connected as described here: https://www.mysensors.org/build/connect_radio

When I power my sensor, messages seem to be transmitted to the gateway but the sensor seems stuck at the find parents state (from my understanding). As I already have running sensors, I assume the gateway is working fine.

Here is the logs on the sensor side :

108560 ?TSF:MSG:SEND,40-40-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
110569 !TSM:FPAR:NO REPLY
110571 TSM:FPAR
110575 ?TSF:MSG:SEND,40-40-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
112584 !TSM:FPAR:NO REPLY
112586 TSM:FPAR
112590 ?TSF:MSG:SEND,40-40-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
114601 !TSM:FPAR:NO REPLY
114604 TSM:FPAR
114608 ?TSF:MSG:SEND,40-40-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
116617 !TSM:FPAR:FAIL
116619 TSM:FAIL:CNT=7
116621 TSM:FAIL:DIS
116623 TSF:TDI:TSL
176627 TSM:FAIL:RE-INIT
176629 TSM:INIT
176635 TSM:INIT:TSP OK
176640 TSM:INIT:STATID=40
176642 TSF:SID:OK,ID=40
176644 TSM:FPAR
176650 ?TSF:MSG:SEND,40-40-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
178659 !TSM:FPAR:NO REPLY
178661 TSM:FPAR
178665 ?TSF:MSG:SEND,40-40-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
180674 !TSM:FPAR:NO REPLY
180676 TSM:FPAR
180680 ?TSF:MSG:SEND,40-40-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
182689 !TSM:FPAR:NO REPLY
182691 TSM:FPAR
182695 ?TSF:MSG:SEND,40-40-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
184705 !TSM:FPAR:FAIL
184707 TSM:FAIL:CNT=7
184709 TSM:FAIL:DIS
184711 TSF:TDI:TSL
244715 TSM:FAIL:RE-INIT
244717 TSM:INIT
244723 TSM:INIT:TSP OK
244727 TSM:INIT:STATID=40
244729 TSF:SID:OK,ID=40
244731 TSM:FPAR
244738 ?TSF:MSG:SEND,40-40-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
246747 !TSM:FPAR:NO REPLY
246749 TSM:FPAR
246753 ?TSF:MSG:SEND,40-40-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
248762 !TSM:FPAR:NO REPLY
248764 TSM:FPAR
248768 ?TSF:MSG:SEND,40-40-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
250777 !TSM:FPAR:NO REPLY
250779 TSM:FPAR
250783 ?TSF:MSG:SEND,40-40-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
252792 !TSM:FPAR:FAIL
252794 TSM:FAIL:CNT=7
252796 TSM:FAIL:DIS
252798 TSF:TDI:TSL

And here are the logs on the gateway side :

!TSF:MSG:SEND,0-0-40-40,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
TSF:MSG:READ,26-26-0,s=1,c=1,t=0,pt=7,l=5,sg=0:25.8
TSF:MSG:READ,40-40-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
TSF:MSG:BC
TSF:MSG:FPAR REQ,ID=40
TSF:PNG:SEND,TO=0
TSF:CKU:OK
TSF:MSG:GWL OK
!TSF:MSG:SEND,0-0-40-40,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
TSF:MSG:READ,40-40-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
TSF:MSG:BC
TSF:MSG:FPAR REQ,ID=40
TSF:CKU:OK,FCTRL
TSF:MSG:GWL OK
!TSF:MSG:SEND,0-0-40-40,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
TSF:MSG:READ,40-40-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
TSF:MSG:BC
TSF:MSG:FPAR REQ,ID=40
TSF:PNG:SEND,TO=0
TSF:CKU:OK
TSF:MSG:GWL OK
!TSF:MSG:SEND,0-0-40-40,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
TSF:MSG:READ,40-40-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
TSF:MSG:BC
TSF:MSG:FPAR REQ,ID=40
TSF:PNG:SEND,TO=0
TSF:CKU:OK
TSF:MSG:GWL OK
!TSF:MSG:SEND,0-0-40-40,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
TSF:MSG:READ,40-40-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
TSF:MSG:BC
TSF:MSG:FPAR REQ,ID=40
TSF:CKU:OK,FCTRL
TSF:MSG:GWL OK
!TSF:MSG:SEND,0-0-40-40,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
TSF:MSG:READ,40-40-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
TSF:MSG:BC

Using https://www.mysensors.org/build/parser, it seems that the gateway received the find_parent request and send its response. The sensor however does not seem to get it.

I tried adding a 4.7uF capacitor on the VCC / GND pins of the radio but nothing changed.

Do you have any idea ?

Hi everyone,

I have a couple of old dev boards with weird microcontrollers (old ARM7TDMI from NXP) lying around.
I would like to use some of them for very basic nodes like door sensor with only presentation message and set value messages.
As porting the complete MySensors library on my MCU does not really make sense, I am looking at the way to build the actual data frames that mysensors is using when passing messages through the radio.
The only informations I was able to find on the website is a description of the serial API but nothing on the actual data that's transmitted through the radio.

Would anyone have any resources or any more details on that ?

Regards,

Personally I would very much be interested in this support as I have an old Due on my shelf sitting there doing nothing.

As the SAM and SAMD are both ARM Cortex-M processors from the same manufacturer, I would assume that enabling MySensors for the Arduino Due should be possible without too much trouble.

Have you had any luck with the nrf24 ? As you said, it's 3.3V like the Due so it should work without too much trouble either.

I have ordered some nrf24 and will receive them in the next few weeks. As I have never used MySensors until now, I'll first be playing around with a bunch of Arduino Nano but then in a few weeks I might try the Due.

Hi everyone,

I've just discovered MySensors a few weeks ago and I find it a very interesting project.
As I like to understand it before trying to setup a MySensors network myself, I have been looking at the code on GitHub.

ARM mbed is a programming environment aimed at enabling easy programming for embedded systems, just like Arduino, but with an approach closer to standard programming (use of actual main function and use of object oriented programming for managing I/O).

My question is : do you think porting MySensors to the ARM mbed platform would be a good idea ?

There are lot of dev boards like the STM32 Nucleo board or the TI TIVA Launchpad that can be programmed using ARM mbed but not with Arduino. As they can all be basically programmed with the same C programs (the device specific functions are managed in the mbed core), porting the project to the mbed platform would enable lots of dev board to be compatible with MySensors at once.

Regards