MYSBootloader 1.3pre2 testing
-
@jmkhael MYSController will reboot the node as soon as it wakes up, sends and processes incoming messages.
@tekka my node wakes up every two minutes (or on pir movement) sends some messages (temperature, light level...) and sleeps right away. will MYSController be able to do that in this small time window? is there something i can code to help it? (heartBeat, wait, smartSomething?)
(as i saw during my few tests, i had to powercycle my node, maybe i wasn't patient enough :)) -
@tekka my node wakes up every two minutes (or on pir movement) sends some messages (temperature, light level...) and sleeps right away. will MYSController be able to do that in this small time window? is there something i can code to help it? (heartBeat, wait, smartSomething?)
(as i saw during my few tests, i had to powercycle my node, maybe i wasn't patient enough :)) -
Just tried with this release, works great (had no problem with previous release)
The only drawback is the packet bitrate, around 40 per minute with 45 bytes each.
It takes 1h to flash a node.few minutes, just make sure of your wiring as this is a very intensive process compared to node's standard radio use.Here is a flash running on a test network:

Can we update many nodes at the same time ? haven't tried
-
Just tried with this release, works great (had no problem with previous release)
The only drawback is the packet bitrate, around 40 per minute with 45 bytes each.
It takes 1h to flash a node.few minutes, just make sure of your wiring as this is a very intensive process compared to node's standard radio use.Here is a flash running on a test network:

Can we update many nodes at the same time ? haven't tried
-
I can now gets dozen of packets at once, then hold, continues...depending of how I press the wires on radio side :sweat:
It's a wiring problem, will try this weekend with a soldered node.Thank you
-
I have also problem with speed of the upload. I get about 1 packet per 3 seconds. Is there a something in the code for the bootloader that has a waitingtime of 3 seconds? And if so, because of what? From that info we might be able to tell if it's a reception problem of the node or the gateway.
-
@tekka Thank you for great job on MYSBootloader. It works fine for me. Currently I'm testing it and have few questions.
- Please can you provide source code? Maybe then I can answer my questions myself :)
- Software signing doesn't work after firmware is uploaded. EEPROM is cleared. Is it possible to restore shared key HMAC after firmware is stored?
- Is possible to send firmware with signing to prevent loading from fake gateway? I thing signing of available firmware version and firmware CRC is enough ..?
Thank you for answers.
-
I have changed the fuse settings for my setup. I don't know if it makes any difference but there is a fuse for "Preserve EEPROM memory through the Chip Erase cycle". Was noticing that my sensors was getting a new id every time I did some changes in my sketches and flashed using "Upload with programmer". I have not succeeded with OTA flashing yet.
I also use the external crystal present on the Pro Mini. Using 0xFF, 0xD2 and 0xFE.
Probably only used when programming using ICSP.MYSBL13.menu.cpu.8MHzatmega328=ATmega328 8MHz (XTAL, BOD1V8) MYSBL13.menu.cpu.8MHzatmega328.upload.maximum_size=30720 MYSBL13.menu.cpu.8MHzatmega328.upload.maximum_data_size=2048 MYSBL13.menu.cpu.8MHzatmega328.upload.speed=38400 MYSBL13.menu.cpu.8MHzatmega328.bootloader.low_fuses=0xFF MYSBL13.menu.cpu.8MHzatmega328.bootloader.high_fuses=0xD2 MYSBL13.menu.cpu.8MHzatmega328.bootloader.extended_fuses=0xFE MYSBL13.menu.cpu.8MHzatmega328.bootloader.file=MYSBootloader/MYSBL13pre_atmega328_8Mhz.hex MYSBL13.menu.cpu.8MHzatmega328.build.mcu=atmega328p MYSBL13.menu.cpu.8MHzatmega328.build.f_cpu=8000000L -
I have changed the fuse settings for my setup. I don't know if it makes any difference but there is a fuse for "Preserve EEPROM memory through the Chip Erase cycle". Was noticing that my sensors was getting a new id every time I did some changes in my sketches and flashed using "Upload with programmer". I have not succeeded with OTA flashing yet.
I also use the external crystal present on the Pro Mini. Using 0xFF, 0xD2 and 0xFE.
Probably only used when programming using ICSP.MYSBL13.menu.cpu.8MHzatmega328=ATmega328 8MHz (XTAL, BOD1V8) MYSBL13.menu.cpu.8MHzatmega328.upload.maximum_size=30720 MYSBL13.menu.cpu.8MHzatmega328.upload.maximum_data_size=2048 MYSBL13.menu.cpu.8MHzatmega328.upload.speed=38400 MYSBL13.menu.cpu.8MHzatmega328.bootloader.low_fuses=0xFF MYSBL13.menu.cpu.8MHzatmega328.bootloader.high_fuses=0xD2 MYSBL13.menu.cpu.8MHzatmega328.bootloader.extended_fuses=0xFE MYSBL13.menu.cpu.8MHzatmega328.bootloader.file=MYSBootloader/MYSBL13pre_atmega328_8Mhz.hex MYSBL13.menu.cpu.8MHzatmega328.build.mcu=atmega328p MYSBL13.menu.cpu.8MHzatmega328.build.f_cpu=8000000L@NiklasO I'm using Arduino Mini 5V, 16Mhz with fuses as you have. Except BODLEVEL 2.7V and EEPROM Cleared. OTA works fine, 21kB hex file is sent in cca 2-5 minutes (very depends on count of wrong packets, without 47uF capacitor on NRF24 or with low power supply it takes about 2 hours :) ). I started with MYSController and small and easy Blink.ino.hex from MYSController distribution. Now I use MyController and own firmwares...
-
@tekka Thank you for great job on MYSBootloader. It works fine for me. Currently I'm testing it and have few questions.
- Please can you provide source code? Maybe then I can answer my questions myself :)
- Software signing doesn't work after firmware is uploaded. EEPROM is cleared. Is it possible to restore shared key HMAC after firmware is stored?
- Is possible to send firmware with signing to prevent loading from fake gateway? I thing signing of available firmware version and firmware CRC is enough ..?
Thank you for answers.
@pku if your keys are in the sketch everything will work for signing.
#define MY_SOFT_HMAC_KEY XXX... //signing key
#define MY_AES_KEY XXX... // if you use encryption
Of course if you want to use whitelisting then you need to compile each node sketch separately with it's serial.@NiklasO
Personally I set the node ID manually to avoid this
#define MY_NODE_ID 30 // Sets a static id for a node
And I group tens so all my 3X nodes are in kitchen, 4X in office, 11X in bedroom 1 and so on.I would love to see a proxy mode in MYSController, in order to interface between a controller that doesn't support OTA and an Ethernet gateway :heart_eyes:
Let say your LAN is the following:
- MySensors gateway 192.168.0.1
- controller (raspberry + Domoticz or else) 192.168.0.2
- PC with MYSController 192.168.0.3
Whenever you need to update a node, you launch MYSController but don't connect to the gateway, then you tells Domoticz .2 to connect to MYSController .3 instead of the gateway .1, at this point MYSController starts relaying everything between Domoticz and the gateway + provides you the ability to update a node.
When you want to get back to normal operations, you set back 192.168.0.1 on Domoticz, MYSController receives a TCP reset and ends it's session with Domoticz and stop the session with the gateway.
We would get a minimum downtime and can could use MYSController to update nodes and debug traffic while letting the normal controller...controlling
-
@pku if your keys are in the sketch everything will work for signing.
#define MY_SOFT_HMAC_KEY XXX... //signing key
#define MY_AES_KEY XXX... // if you use encryption
Of course if you want to use whitelisting then you need to compile each node sketch separately with it's serial.@NiklasO
Personally I set the node ID manually to avoid this
#define MY_NODE_ID 30 // Sets a static id for a node
And I group tens so all my 3X nodes are in kitchen, 4X in office, 11X in bedroom 1 and so on.I would love to see a proxy mode in MYSController, in order to interface between a controller that doesn't support OTA and an Ethernet gateway :heart_eyes:
Let say your LAN is the following:
- MySensors gateway 192.168.0.1
- controller (raspberry + Domoticz or else) 192.168.0.2
- PC with MYSController 192.168.0.3
Whenever you need to update a node, you launch MYSController but don't connect to the gateway, then you tells Domoticz .2 to connect to MYSController .3 instead of the gateway .1, at this point MYSController starts relaying everything between Domoticz and the gateway + provides you the ability to update a node.
When you want to get back to normal operations, you set back 192.168.0.1 on Domoticz, MYSController receives a TCP reset and ends it's session with Domoticz and stop the session with the gateway.
We would get a minimum downtime and can could use MYSController to update nodes and debug traffic while letting the normal controller...controlling
@NiklasO
Personally I set the node ID manually to avoid this
#define MY_NODE_ID 30 // Sets a static id for a node
And I group tens so all my 3X nodes are in kitchen, 4X in office, 11X in bedroom 1 and so on.Ah, yes. Setting static id sound like a solution to my problem. Thanks.
-
@pku if your keys are in the sketch everything will work for signing.
#define MY_SOFT_HMAC_KEY XXX... //signing key
#define MY_AES_KEY XXX... // if you use encryption
Of course if you want to use whitelisting then you need to compile each node sketch separately with it's serial.@NiklasO
Personally I set the node ID manually to avoid this
#define MY_NODE_ID 30 // Sets a static id for a node
And I group tens so all my 3X nodes are in kitchen, 4X in office, 11X in bedroom 1 and so on.I would love to see a proxy mode in MYSController, in order to interface between a controller that doesn't support OTA and an Ethernet gateway :heart_eyes:
Let say your LAN is the following:
- MySensors gateway 192.168.0.1
- controller (raspberry + Domoticz or else) 192.168.0.2
- PC with MYSController 192.168.0.3
Whenever you need to update a node, you launch MYSController but don't connect to the gateway, then you tells Domoticz .2 to connect to MYSController .3 instead of the gateway .1, at this point MYSController starts relaying everything between Domoticz and the gateway + provides you the ability to update a node.
When you want to get back to normal operations, you set back 192.168.0.1 on Domoticz, MYSController receives a TCP reset and ends it's session with Domoticz and stop the session with the gateway.
We would get a minimum downtime and can could use MYSController to update nodes and debug traffic while letting the normal controller...controlling
@JCLB said:
@pku if your keys are in the sketch everything will work for signing.
#define MY_SOFT_HMAC_KEY XXX... //signing key
#define MY_AES_KEY XXX... // if you use encryption
Of course if you want to use whitelisting then you need to compile each node sketch separately with it's serial.but that would give a listener your full MY_SOFT_HMAC_KEY and signing would be useless in future. Therefor it is better to write the key in eeprom with cable and later only update firmware without key via OTA.
-
@JCLB said:
@pku if your keys are in the sketch everything will work for signing.
#define MY_SOFT_HMAC_KEY XXX... //signing key
#define MY_AES_KEY XXX... // if you use encryption
Of course if you want to use whitelisting then you need to compile each node sketch separately with it's serial.but that would give a listener your full MY_SOFT_HMAC_KEY and signing would be useless in future. Therefor it is better to write the key in eeprom with cable and later only update firmware without key via OTA.
- I agree, keys located in sketch can be used as workaround only, because the security is broken.
- But I'm interesting in key located in EEPROM. How it is work during flashing? If Clear EEPROM fuse is not set then everybody can take my outside node, put his own firmware and it will work with keys from EEPROM. It is again a security issue (of course he must have physical access to my node).
I thing it should work with this scenario:
- reguest for new firmware
- copy key, serial and rsa into RAM
- flash new firmware (with fuse clear EEPROM)
- copy key, serial and rsa back into EEPROM
What do you thing?
-
For a node that is physically accessable it is realy hard. First: does this node needs signing? For sensor data you don't need in most cases. Maybe you should use the hardware chip, there you can't read out the key and if it was locked you also can't change it.
If you still need to use softsigning you could use whitelisting and revoke the whitelist-entry in case of corruption. -
Hello,
I am trying to use MYSController with MYSBootloader 1.3pre2 to reassign a node's ID, and I cannot make it work.
I've tried to check/uncheck the Auto ID toggle/tried to use the MYSBootloader CMDs/Assign ID and setting a new one to no avail.After that, when it reboots, the node reask for it's firmware, and MYSController re-uploads it, but the node keeps the old ID from the EEProm. (note that the sketch don't hardcode the node's ID).
I'd like to keep the ID management free (i.e. do not hardcode all my node's IDs of course)
How can I do that?
[2016-10-21 13:41:33.318 Info] CLICK Reassign ID from 1 to 20 [2016-10-21 13:41:33.319 Info] TX 1;0;3;0;13;0 [2016-10-21 13:41:33.364 Info] RX 0;255;3;0;9;!TSP:MSG:SEND 0-0-1-1 s=0,c=3,t=13,pt=0,l=1,sg=0,ft=0,st=fail:0 [2016-10-21 13:41:37.886 Info] RX 0;255;3;0;9;TSP:MSG:READ 4-4-0 s=255,c=3,t=22,pt=5,l=4,sg=0:155561124 [2016-10-21 13:41:37.886 Info] RX 4;255;3;0;22;155561124 [2016-10-21 13:41:42.855 Info] RX 0;255;3;0;9;TSP:MSG:READ 2-2-0 s=1,c=1,t=16,pt=0,l=1,sg=0:0 [2016-10-21 13:41:42.857 Info] RX 2;1;1;0;16;0 [2016-10-21 13:41:46.623 Info] RX 0;255;3;0;9;TSP:MSG:READ 8-5-0 s=2,c=1,t=16,pt=0,l=1,sg=0:0 [2016-10-21 13:41:46.625 Info] RX 8;2;1;0;16;0 [2016-10-21 13:41:47.899 Info] RX 0;255;3;0;9;TSP:MSG:READ 8-5-0 s=3,c=1,t=23,pt=2,l=2,sg=0:80 [2016-10-21 13:41:47.901 Info] RX 8;3;1;0;23;80 [2016-10-21 13:41:50.491 Info] RX 0;255;3;0;9;TSP:MSG:READ 4-4-0 s=1,c=1,t=0,pt=7,l=5,sg=0:22.0 [2016-10-21 13:41:50.494 Info] RX 0;255;3;0;9;TSP:MSG:ACK msg [2016-10-21 13:41:50.540 Info] RX 0;255;3;0;9;!TSP:MSG:SEND 0-0-4-4 s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=fail:22.0 [2016-10-21 13:41:50.540 Info] RX 4;1;1;0;0;22.0 [2016-10-21 13:41:50.570 Info] RX 0;255;3;0;9;TSP:MSG:READ 4-4-0 s=255,c=3,t=22,pt=5,l=4,sg=0:155562401 [2016-10-21 13:41:50.570 Info] RX 4;255;3;0;22;155562401 [2016-10-21 13:41:57.014 Info] RX 0;255;3;0;9;TSP:SANCHK:OK [2016-10-21 13:42:02.832 Info] RX 0;255;3;0;9;TSP:MSG:READ 4-4-0 s=255,c=3,t=22,pt=5,l=4,sg=0:155563404 [2016-10-21 13:42:02.832 Info] RX 4;255;3;0;22;155563404 [2016-10-21 13:42:20.453 Info] RX 0;255;3;0;9;TSP:MSG:READ 1-1-0 s=255,c=3,t=22,pt=5,l=4,sg=0:4712 [2016-10-21 13:42:20.453 Info] RX 1;255;3;0;22;4712 [2016-10-21 13:42:20.453 Info] CHILD New child discovered, node id=1, child id=internal [2016-10-21 13:42:20.951 Info] RX 0;255;3;0;9;TSP:MSG:READ 1-1-0 s=2,c=1,t=16,pt=0,l=1,sg=0:0 [2016-10-21 13:42:20.953 Info] RX 1;2;1;0;16;0 [2016-10-21 13:42:20.953 Info] CHILD New child discovered, node id=1, child id=2 [2016-10-21 13:42:21.954 Info] RX 0;255;3;0;9;TSP:MSG:READ 1-1-0 s=3,c=1,t=23,pt=2,l=2,sg=0:42 [2016-10-21 13:42:21.956 Info] RX 1;3;1;0;23;42 [2016-10-21 13:42:21.956 Info] CHILD New child discovered, node id=1, child id=3 [2016-10-21 13:42:27.773 Info] RX 0;255;3;0;9;TSP:MSG:READ 4-4-0 s=255,c=3,t=22,pt=5,l=4,sg=0:155565680 [2016-10-21 13:42:27.774 Info] RX 4;255;3;0;22;155565680 [2016-10-21 13:42:40.382 Info] RX 0;255;3;0;9;TSP:MSG:READ 4-4-0 s=255,c=3,t=22,pt=5,l=4,sg=0:155566954 [2016-10-21 13:42:40.382 Info] RX 4;255;3;0;22;155566954Starting sensor (RNNNA-, 2.0.0) TSM:INIT TSM:RADIO:OK TSP:ASSIGNID:OK (ID=1) TSM:FPAR TSP:MSG:SEND 1-1-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc: TSP:MSG:READ 5-5-1 s=255,c=3,t=8,pt=1,l=1,sg=0:1 TSP:MSG:FPAR RES (ID=5, dist=1) TSP:MSG:PAR OK (ID=5, dist=2) TSP:MSG:READ 0-0-1 s=255,c=3,t=8,pt=1,l=1,sg=0:0 TSP:MSG:FPAR RES (ID=0, dist=0) TSP:MSG:PAR OK (ID=0, dist=1) TSM:FPAR:OK TSM:ID TSM:CHKID:OK (ID=1) TSM:UPL TSP:PING:SEND (dest=0) TSP:MSG:SEND 1-1-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=ok:1 TSP:MSG:READ 0-0-1 s=255,c=3,t=25,pt=1,l=1,sg=0:1 TSP:MSG:PONG RECV (hops=1) TSP:CHKUPL:OK TSM:UPL:OK TSM:READY TSP:MSG:SEND 1-1-0-0 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=ok:0100 TSP:MSG:SEND 1-1-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=ok:2.0.0 TSP:MSG:SEND 1-1-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=ok:0 TSP:MSG:READ 0-0-1 s=255,c=3,t=15,pt=6,l=2,sg=0:0100 TSP:MSG:READ 0-0-1 s=255,c=3,t=15,pt=6,l=2,sg=0:0100 TSP:MSG:READ 0-0-1 s=255,c=3,t=6,pt=0,l=1,sg=0:M TSP:MSG:SEND 1-1-0-0 s=255,c=3,t=11,pt=0,l=12,sg=0,ft=0,st=ok:Multi Sensor TSP:MSG:SEND 1-1-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=ok:1.0 TSP:MSG:SEND 1-1-0-0 s=2,c=0,t=1,pt=0,l=0,sg=0,ft=0,st=ok: TSP:MSG:SEND 1-1-0-0 s=0,c=0,t=7,pt=0,l=0,sg=0,ft=0,st=ok: TSP:MSG:SEND 1-1-0-0 s=1,c=0,t=6,pt=0,l=0,sg=0,ft=0,st=ok: TSP:MSG:SEND 1-1-0-0 s=3,c=0,t=16,pt=0,l=0,sg=0,ft=0,st=ok: Request registration... TSP:MSG:SEND 1-1-0-0 s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=ok:2 TSP:MSG:READ 0-0-1 s=255,c=3,t=27,pt=1,l=1,sg=0:1 Node registration=1 Init complete, id=1, parent=0, distance=1, registration=1 TSP:MSG:SEND 1-1-0-0 s=2,c=1,t=16,pt=0,l=1,sg=0,ft=0,st=ok:0 TSP:MSG:SEND 1-1-0-0 s=3,c=1,t=23,pt=2,l=2,sg=0,ft=0,st=ok:54 -
Hi! Great work!
I have a small question: How does your Bootloader know which channel to listen on? -
Hello,
I am trying to use MYSController with MYSBootloader 1.3pre2 to reassign a node's ID, and I cannot make it work.
I've tried to check/uncheck the Auto ID toggle/tried to use the MYSBootloader CMDs/Assign ID and setting a new one to no avail.After that, when it reboots, the node reask for it's firmware, and MYSController re-uploads it, but the node keeps the old ID from the EEProm. (note that the sketch don't hardcode the node's ID).
I'd like to keep the ID management free (i.e. do not hardcode all my node's IDs of course)
How can I do that?
[2016-10-21 13:41:33.318 Info] CLICK Reassign ID from 1 to 20 [2016-10-21 13:41:33.319 Info] TX 1;0;3;0;13;0 [2016-10-21 13:41:33.364 Info] RX 0;255;3;0;9;!TSP:MSG:SEND 0-0-1-1 s=0,c=3,t=13,pt=0,l=1,sg=0,ft=0,st=fail:0 [2016-10-21 13:41:37.886 Info] RX 0;255;3;0;9;TSP:MSG:READ 4-4-0 s=255,c=3,t=22,pt=5,l=4,sg=0:155561124 [2016-10-21 13:41:37.886 Info] RX 4;255;3;0;22;155561124 [2016-10-21 13:41:42.855 Info] RX 0;255;3;0;9;TSP:MSG:READ 2-2-0 s=1,c=1,t=16,pt=0,l=1,sg=0:0 [2016-10-21 13:41:42.857 Info] RX 2;1;1;0;16;0 [2016-10-21 13:41:46.623 Info] RX 0;255;3;0;9;TSP:MSG:READ 8-5-0 s=2,c=1,t=16,pt=0,l=1,sg=0:0 [2016-10-21 13:41:46.625 Info] RX 8;2;1;0;16;0 [2016-10-21 13:41:47.899 Info] RX 0;255;3;0;9;TSP:MSG:READ 8-5-0 s=3,c=1,t=23,pt=2,l=2,sg=0:80 [2016-10-21 13:41:47.901 Info] RX 8;3;1;0;23;80 [2016-10-21 13:41:50.491 Info] RX 0;255;3;0;9;TSP:MSG:READ 4-4-0 s=1,c=1,t=0,pt=7,l=5,sg=0:22.0 [2016-10-21 13:41:50.494 Info] RX 0;255;3;0;9;TSP:MSG:ACK msg [2016-10-21 13:41:50.540 Info] RX 0;255;3;0;9;!TSP:MSG:SEND 0-0-4-4 s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=fail:22.0 [2016-10-21 13:41:50.540 Info] RX 4;1;1;0;0;22.0 [2016-10-21 13:41:50.570 Info] RX 0;255;3;0;9;TSP:MSG:READ 4-4-0 s=255,c=3,t=22,pt=5,l=4,sg=0:155562401 [2016-10-21 13:41:50.570 Info] RX 4;255;3;0;22;155562401 [2016-10-21 13:41:57.014 Info] RX 0;255;3;0;9;TSP:SANCHK:OK [2016-10-21 13:42:02.832 Info] RX 0;255;3;0;9;TSP:MSG:READ 4-4-0 s=255,c=3,t=22,pt=5,l=4,sg=0:155563404 [2016-10-21 13:42:02.832 Info] RX 4;255;3;0;22;155563404 [2016-10-21 13:42:20.453 Info] RX 0;255;3;0;9;TSP:MSG:READ 1-1-0 s=255,c=3,t=22,pt=5,l=4,sg=0:4712 [2016-10-21 13:42:20.453 Info] RX 1;255;3;0;22;4712 [2016-10-21 13:42:20.453 Info] CHILD New child discovered, node id=1, child id=internal [2016-10-21 13:42:20.951 Info] RX 0;255;3;0;9;TSP:MSG:READ 1-1-0 s=2,c=1,t=16,pt=0,l=1,sg=0:0 [2016-10-21 13:42:20.953 Info] RX 1;2;1;0;16;0 [2016-10-21 13:42:20.953 Info] CHILD New child discovered, node id=1, child id=2 [2016-10-21 13:42:21.954 Info] RX 0;255;3;0;9;TSP:MSG:READ 1-1-0 s=3,c=1,t=23,pt=2,l=2,sg=0:42 [2016-10-21 13:42:21.956 Info] RX 1;3;1;0;23;42 [2016-10-21 13:42:21.956 Info] CHILD New child discovered, node id=1, child id=3 [2016-10-21 13:42:27.773 Info] RX 0;255;3;0;9;TSP:MSG:READ 4-4-0 s=255,c=3,t=22,pt=5,l=4,sg=0:155565680 [2016-10-21 13:42:27.774 Info] RX 4;255;3;0;22;155565680 [2016-10-21 13:42:40.382 Info] RX 0;255;3;0;9;TSP:MSG:READ 4-4-0 s=255,c=3,t=22,pt=5,l=4,sg=0:155566954 [2016-10-21 13:42:40.382 Info] RX 4;255;3;0;22;155566954Starting sensor (RNNNA-, 2.0.0) TSM:INIT TSM:RADIO:OK TSP:ASSIGNID:OK (ID=1) TSM:FPAR TSP:MSG:SEND 1-1-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc: TSP:MSG:READ 5-5-1 s=255,c=3,t=8,pt=1,l=1,sg=0:1 TSP:MSG:FPAR RES (ID=5, dist=1) TSP:MSG:PAR OK (ID=5, dist=2) TSP:MSG:READ 0-0-1 s=255,c=3,t=8,pt=1,l=1,sg=0:0 TSP:MSG:FPAR RES (ID=0, dist=0) TSP:MSG:PAR OK (ID=0, dist=1) TSM:FPAR:OK TSM:ID TSM:CHKID:OK (ID=1) TSM:UPL TSP:PING:SEND (dest=0) TSP:MSG:SEND 1-1-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=ok:1 TSP:MSG:READ 0-0-1 s=255,c=3,t=25,pt=1,l=1,sg=0:1 TSP:MSG:PONG RECV (hops=1) TSP:CHKUPL:OK TSM:UPL:OK TSM:READY TSP:MSG:SEND 1-1-0-0 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=ok:0100 TSP:MSG:SEND 1-1-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=ok:2.0.0 TSP:MSG:SEND 1-1-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=ok:0 TSP:MSG:READ 0-0-1 s=255,c=3,t=15,pt=6,l=2,sg=0:0100 TSP:MSG:READ 0-0-1 s=255,c=3,t=15,pt=6,l=2,sg=0:0100 TSP:MSG:READ 0-0-1 s=255,c=3,t=6,pt=0,l=1,sg=0:M TSP:MSG:SEND 1-1-0-0 s=255,c=3,t=11,pt=0,l=12,sg=0,ft=0,st=ok:Multi Sensor TSP:MSG:SEND 1-1-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=ok:1.0 TSP:MSG:SEND 1-1-0-0 s=2,c=0,t=1,pt=0,l=0,sg=0,ft=0,st=ok: TSP:MSG:SEND 1-1-0-0 s=0,c=0,t=7,pt=0,l=0,sg=0,ft=0,st=ok: TSP:MSG:SEND 1-1-0-0 s=1,c=0,t=6,pt=0,l=0,sg=0,ft=0,st=ok: TSP:MSG:SEND 1-1-0-0 s=3,c=0,t=16,pt=0,l=0,sg=0,ft=0,st=ok: Request registration... TSP:MSG:SEND 1-1-0-0 s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=ok:2 TSP:MSG:READ 0-0-1 s=255,c=3,t=27,pt=1,l=1,sg=0:1 Node registration=1 Init complete, id=1, parent=0, distance=1, registration=1 TSP:MSG:SEND 1-1-0-0 s=2,c=1,t=16,pt=0,l=1,sg=0,ft=0,st=ok:0 TSP:MSG:SEND 1-1-0-0 s=3,c=1,t=23,pt=2,l=2,sg=0,ft=0,st=ok:54 -
Hi! Great work!
I have a small question: How does your Bootloader know which channel to listen on?