Sensebender Micro
-
I just received two sensebenders. I'm really impressed by the great engineering behind the board. I can't wait to heat up my soldering iron. I love them!
-
I just received two Sensebenders, but have problems getting the device to consume little power. I get totally different values as displayed above.
With the following sketch, I get about 5,6mA in active state and 1,6mA in sleep mode with nRF24 attached. I have compared different nRF24-chips and this one consumed the least power.
Without the nRF24, I get 4mA and 0,025mA (=25µA) during sleep mode.
#include <LowPower.h> #include "RF24.h" RF24 radio(9, 10); void setup() { } void loop() { delay(8000); LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF); }
-
@user2334 I don't think the LowPower library shuts off the radio. Use MySensor's sleep function instead.
-
A general question regarding these types of boards that are generally designed to be used on battery power. Is there a reason to not power the ATSH204A and Si7021 from AVR pins? The pins can source far more than what these devices can sink (even when using the heating on the Si7021), and it would allow squeezing a tiny bit more out of the battery life by selectively powering down the devices.
Eg., if I'm not using the ATSHA204A at all, I can save 150nA continuous current. The power saving from disabling the Si7021 is less at about 60nA, so that might just be eaten up by having to wait up to 80ms before a full conversion.I'm aware that we're talking about saving a tiny ~200nA here, but over the span of two years that adds up to about 350mAh.
So what I'm wondering is simply, is there a technical reason saying that this really isn't a Good Idea (tm)? Should I avoid doing so if I design my own similar device?
-
@ximinez said:
A general question regarding these types of boards that are generally designed to be used on battery power. Is there a reason to not power the ATSH204A and Si7021 from AVR pins? The pins can source far more than what these devices can sink (even when using the heating on the Si7021), and it would allow squeezing a tiny bit more out of the battery life by selectively powering down the devices.
Eg., if I'm not using the ATSHA204A at all, I can save 150nA continuous current. The power saving from disabling the Si7021 is less at about 60nA, so that might just be eaten up by having to wait up to 80ms before a full conversion.I'm aware that we're talking about saving a tiny ~200nA here, but over the span of two years that adds up to about 350mAh.
So what I'm wondering is simply, is there a technical reason saying that this really isn't a Good Idea (tm)? Should I avoid doing so if I design my own similar device?
I second that question. I was just thinking about a similar idea.
-
That is indeed a good question. The straight answer is that I didn't think about that when I designed the board.
In theory you could also power the radio from a digital pin on the avr, and power that down completely.
BTW. If you turn on the heating element in the si7021 at full power, I think the power drain exceeds what the avr can deliver on a digital pin. But one could just avoid that.
-
I have been thinking about this as well. But I discarded parts of the idea because I needed the IO for other stuff (MYSX in my case). Instead I designed a switched rail where one could attach sensor power sinks. It's not io powered but it is io controlled.
Though I did not attach the si or atsha to this switch function as I decided to make it an optional feature but wanted to make sure authentication and temp/hum would always be available.
-
That is indeed a good question. The straight answer is that I didn't think about that when I designed the board.
Oh, I thought it was a design decision
In theory you could also power the radio from a digital pin on the avr, and power that down completely.
I've been wondering about the radio in particular. Does the radio keep any state locally, and will it have to be reinitialized upon powerup?
BTW. If you turn on the heating element in the si7021 at full power, I think the power drain exceeds what the avr can deliver on a digital pin. But one could just avoid that.
The heating element eats a measly 3.1mA according to the datasheet, so even that would be well within the limits for a single in on a 328p.
Now, I don't have Eagle installed on this laptop, and my bandwidth is limited right now. Is there a picture of the PCB traces available? Wondering if atleast some of this can be hacked on by cutting traces.
-
Nope, there are only the eagle design files.. (Or gerbers, you could use a gerber viewer)
I have 4 sensors operating for almost a year on two AA batteries, they all report around 73% battery left. So in my opinion, it's not that necessary to do extra optimization on the power drain..
-
@tbowmo
While 73% after one year is good, it doesn't mean that it can't get better. The ATSHA204a and Si7021 draw about 350mAh from the battery over two years from idling alone. The NRF24L01+ draws around 1500mAh.
Remember, you will never get close to emptying out the battery before the voltage drops below working voltage. Using alkaline batteries, you'll get around 2000mAh before the batteries reach 2v (which, if you're using battery voltage as a pure percentage, is 66%), at which point the voltage curve drops sharply - and your sensors die. The radio and sensors have drawn more than 900mAh from your battery during the year you have run the device (and that's just idling) - close to half your battery life.Assuming your battery percentage is correct, and you started at 100% one year ago, I'm betting your sensors will die sometime during this summer. While you may think that extra optimization isn't worth it, I do. The nanoAmp draws may not seem like much, but drawn out on a timescale like this, it is a major power draw.
-
@ximinez That depend on how you define battery percentage. I have chosen to adjust my measurements to let 0% mean when voltage drops below the highest requirements of the onboard devices. Since that particular device will fail when voltage goes lower, it serves no purpose to provide a false battery percentage. 0% is when the node no longer operates according to specs. But this is of course hw/sketch-dependent.
-
@Anticimex The point still stands however. The discharge graph is far from linear, and your sensors and radio have already drawn close to half of your battery life by idling alone. A colleague of mine has had to replace the batteries in his two sensors already.
-
-
@Anticimex Ah, yes. sed /your/@tbowmo's/g. I blame lack of caffeine.
-
@ximinez makes sense. I'm sure you can cut down on power consumption by cutting power to those peripherals. I do not know how signing would be affected by this though, as I have not tested it with switching the atsha on and off between calls. I would like to hear from you on that topic if you choose to try it though
-
Ok, I've been looking at the image and my spare sensor. It looks like:
Power to the NRF can be cut between C3 and VCC pin.
ATSHA204a power can be cut on the trace that goes from the atsha and beneath the flash.
Si7021 power can be cut at the trace that goes from C4.I just might have to dig out my scalpel and iron for this. If the components magically work without any extra initialization on powerup, modifying the code looks easy.
I'll report back with my findings
-
For my battery reporting, I have set 1.9V as 0%, 3.3V is 100%..
While you're at it, also power down the external flash, as it might also contribute a bit..
-
Well that went south pretty fast. Was wondering why my sensebender was acting up. Took a while to see that I had plugged in an ESP8266 module instead of one of my NRF24 modules. Those modules look far too much alike
Serial output now looks like this: "Sånsebåndåò Micro FW 1.3" with random characters corrupted. I think I've killed it
I can still flash firmware to it via serial, so it's not completely dead.I can however confirm that both the SHA204A and SI7021 self-tests OK being powered on in-sketch:
(Flash seems to randomly fail or test OK, not sure why yet)þSånseâånder Micòo F× 1.3 - TesôÍoäe
Tåstiîg påòipheraló!
-> ÓÉ7021 : ok!
-> Æìasè : æailed!
-> SÈA204 : Ïk (seòéal : 01234ÂBAÅ259E8AÄÅE)
Tåót fiîésheä
----> Óelftest æaiìåä!
-
@ximinez If possible, try to check if signing and verification of signatures work as well. I have tried to implement the use of the ATSHA to be atomic in nature, but it could be that some state is retained which is cleared on power down which might break the calculations.
-
What is the easiest and fastest way to sign and verify? I don't have a gateway set up quite yet.
(And, is any part of setting this up dependent on serial integrity? If so I might have to adjust baud quite a bit)
-
@ximinez Well, without a gw the only option is to use node peer to peer transmissons to test signing. How to do it is described in the signing documentation, assuming you use development branch, you can see here. For master, look here.
-
I have an Uno with an ethernet shield and nrf24 hooked up, so I will have to get around to write a sketch for that purpose.
But to get signing to work, I'll have to personalize the atsha? That sketch doesn't compile for me.
-
Yes, you have to personalize it. What is failing? I don't have an Uno myself, but according to Jenkins the personalizer compiles ok for Uno on both master and development. You don't have any local changes?
-
The personalization fails to compile for my sensebender micro. There's a few undeclared:
Personalizer:225: error: 'EEPROM_SIGNING_SOFT_HMAC_KEY_ADDRESS' was not declared in this scope
Personalizer:225: error: 'hwReadConfigBlock' was not declared in this scope
Personalizer:236: error: 'EEPROM_SIGNING_SOFT_SERIAL_ADDRESS' was not declared in this scope
Personalizer:247: error: 'EEPROM_RF_ENCRYPTION_AES_KEY_ADDRESS' was not declared in this scope
Personalizer:697: error: 'hwMillis' was not declared in this scopeI'm trying to compile this against master however. Do I have to have dev branch to compile that sketch?
-
Fails with the same errors on Uno for me.
-
@ximinez and you are certain you have no local changes to the code? Jenkins builds both master and development branches every night for both the SenseBender and the uno and it builds all examples, including the personalizer without issues.
-
Pretty sure.
I'll wipe my library dir and redownload master.
-
If memory serves me, some of the errors you get seem to originate from code on development branch. The eeprom addresses are to my knowledge not yet available on master.
-
Ok, moved from master to dev. Sketch compiled. Not quite the output I expected however.
EEPROM configuration:
SOFT_HMAC_KEY | FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
SOFT_SERIAL | FFFFFFFFFFFFFFFFFF
AES_KEY | FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
-
@ximinez it is the output I expected. You have gone for soft signing, and you see the reset values of the eeprom. You need to pick atsha settings. The link I gave you gives the exact settings to personalize both for software and atsha backends.
-
Got it now
I had two different sketches and had edited the wrong one. Now I have actual values.
Is there an example GW sketch that I can load quickly to my Uno/W5100 shield/NRF24?
-
I'm rusty on the gateways. But on development branch, configuring signing is easier than on master branch. My link gives the details on signing configuration for both nodes and gateways with examples.
-
Yeah, I'm struggling a bit with those instructions. I've set up my gateway with soft signing, and got sane values written to EEPROM.
Now, do I need any of the three values to personalize the sensebender?
SOFT_HMAC_KEY?
-
@ximinez the SenseBender you have patched/cut needs atsha personalization, so no SOFT anything. But you need to have the same hmac key stored on the atsha on the SenseBender as you have picked as soft hmac key in eeprom of your gateway (the node you have personalized for soft signing).
-
@Anticimex Yeah, that's what I asked
I get:
Writing key to slot 0...
Data lock failed. Response: D3
-
@ximinez locking data is a very bad idea. It will prevent you from changing the hmac key. You only need to (and should) lock configuration. Only lock data if you really know what you are doing.
-
Writing key to slot 0...
Data not locked. Define LOCK_DATA to lock for real.Personalization is now complete.
Configuration is LOCKED
Data is UNLOCKED
-
@ximinez looks good. You should be done with personalization. Remember to require signatures from the SenseBender in addition to "enabling" it. You can also require signature on the GW, thus forcing all communications between them to be signed. The serial console will reveal how it goes. You can enable verbose debug (MY_DEBUG_VERBOSE_SIGNING) for the signing if you want more details on the signing parts.
-
I have the sensor sketch mostly done, but I'll have to do some soldering again tomorrow. It looks like D7 got burnt when I plugged in my ESP8266, giving ~0,5v out on that pin. Will have to work around that:
Sôártinç óensor (RÎONA-, 2.0.0-beta)
Raäio init æáiìåd. Ãèeck wiring.When that is OK, I'll look at the GW sketch.
-
Sounds good. Bedtime here too.
-
D3, D4 and D7 are all funky, and do not give ~3v when set high. So I'm back to the radio being on all the time.
D5 and D6 mysteriously work just fine.Radio is now OK, but the sensebender reboots before it gets to setup().
Stárting óensor (ÒÎONA-, 2.0.0-beôá)
Ráäio init suããessæuì.
æéîä parenô
send: 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,óô=bc:
[reboot and repeat]
-
Sounds like it's on its way to the "other side"..
-
Yup. Setting up my other sensebender as a proper signing sensor and my uno as a gateway. This will have to wait until I get a couple more working sensors.
-
Ok. I set up my GW, and set up my healthy sensebender as an outdoor sensor. The zombie sensor is now a working indoor sensor.
I have enabled signing and set up whitelisting, but enabling signing debugging makes the sketch oversize, so I can't actually check if signing works - but atleast now I have two sensors.
-
You will still be notified without verbose logging. And if you have enabled and require signing, you won't get any data if something fails (assuming signing is properly activated).
-
@user2334 said:
I just received two Sensebenders, but have problems getting the device to consume little power. I get totally different values as displayed above.
With the following sketch, I get about 5,6mA in active state and 1,6mA in sleep mode with nRF24 attached. I have compared different nRF24-chips and this one consumed the least power.
Without the nRF24, I get 4mA and 0,025mA (=25µA) during sleep mode.
#include <LowPower.h> #include "RF24.h" RF24 radio(9, 10); void setup() { } void loop() { delay(8000); LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF); }As a follow-up to my previous posting, I can confirm, that using original nRF24-modules (best source seems to be https://www.itead.cc/nrf24l01-module.html), I get 0,023mA (=23µA) with nrf24 attached during sleep mode (no difference between the libraries JeeLib->Sleepy::loseSomeTime or LowPower->LowPower.powerDown).
It is quite interesting, that so many nRF24 Modules (bought from eBay, from Amazon UK) are clones with higher power consumption. Some of them use 3mA, some have electrical short, ...
-
@Anticimex I've set MY_SIGNING_SOFT, MY_SIGNING_REQUEST_SIGNATURES and MY_SIGNING_NODE_WHITELIST on the GW, and reenabled (normal) debug but not signing debug since that is too big.
With those enabled, if the sending node does not sign, I should not get this?0;255;3;0;9;read: 2-2-0 s=1,c=1,t=0,pt=7,l=5,sg=0:6.3
0;255;3;0;9;read: 2-2-0 s=2,c=1,t=1,pt=2,l=2,sg=0:59
-
@ximinez The GW will only require signatures from a node that in turn require signatures.
It is the sg-flag that indicate if a message is signed, in your case, both messages are unsigned.
If you only have node->gw communication, both gw and node has to require signatures for you to see signed messages.
If you have gw->node communication, it is enough that the node require signatures, the gw will then sign them, no matter if the gw require signatures or not.
-
0;255;3;0;9;read: 3-3-0 s=1,c=0,t=6,pt=0,l=0,sg=0:
0;255;3;0;9;read: 3-3-0 s=2,c=3,t=16,pt=0,l=0,sg=0:
0;255;3;0;9;send: 0-0-3-3 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:57ACB4BD46843BFCC7ABA693CC5AA527F7724531F525338E8A
0;255;3;0;9;read: 3-3-0 s=2,c=0,t=7,pt=0,l=0,sg=0:I feel more secure now
-
@ximinez Hm, good, but I still see no signed message. But at least a nonce was sent
-
@Anticimex Sensor values are getting through though. And signing is requested on both ends (for one sensor so far). I can't see any other #defines that should be set to enable signing. I get the same result on both the zombie sensor and the unmodded one.
I get three "sign fail" (showing up as verify fail on gw) before the sketch reaches setup(), where the ATSHA gets powered up. I will need to power the ATSHA somewhere in the mysensors library. However, once setup() is reached, the ATSHA seems to handle powering down and up just fine.
I can however say that it the Si7021 doesn't like being powered off and back on again after sleep. That causes the MCU to reset.
-
@ximinez Ah, yes, on development branch the signing backend clear the sign flag when it verifies the message. so it will always show as 0 without verbose signing debug enabled.
I know there have been discussions about a "pre setup" to be used for early sketch init. You probably want to power the atsha for early handshaking as well to get the sketch name and such to propagate properly. @hek perhaps has the latest on such features.
-
I've built a nicer-looking serial gateway instead of the rather large ethernet gateway. I thought that would basically be a "slot-in" as long as I personalize the GW it with the same SOFT_HMAC_KEY, SOFT_SERIAL and AES_KEY as the original GW. Are there more steps that need to be taken to get the sensors to connect?
-
No matter what I do now, this is what I get:
send: 2-2-0-0 s=1,c=3,t=16,pt=0,l=0,sg=0,st=fail:
sign fail
send: 2-2-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,st=fail:26.0
send: 2-2-0-0 s=2,c=3,t=16,pt=0,l=0,sg=0,st=fail:
sign fail
send: 2-2-0-0 s=2,c=1,t=1,pt=2,l=2,sg=0,st=fail:34
send: 2-2-0-0 s=255,c=3,t=16,pt=0,l=0,sg=0,st=fail:
sign fail
-
You must not use the same serial across nodes. Serial have to be unique. HMAC have to be identical.
-
Yes, I know serial must be unique. Serials go in the whitelist for the corresponding node ID. It turned out to be the NRF24L01+-modules with antennas. Replaced it with a regular module and it worked fine.
(Which is strange, because one of those modules worked fine on the ethernet gw. It doesn't eat that much power does it?)
-
@ximinez The signing failing is due to messages not arriving (st=fail). So it is not signing that is your problem here.
However, with signing, messages are now "full size" which strains the RF link so if it is "weak" fewer messages get through if they are "longer". I suspect that is the problem here. Basically the usual stuff; adding caps, using a dedicated regulator and so on...
-
Looks like it works now, but what's the deal with the initial failed signs? Look at http://pastebin.ca/3585005 (GW side) and http://pastebin.ca/3585014 (Sensor side. Not the same powerup). It starts by failing a lot, then after a while everything looks OK.
-
@ximinez difficult to say. Maybe a long stabilization period for the regulator. You could try to add a delay in early init in the library to see if it makes a difference.
-
@Anticimex and again, it is not failed signature errors per se. It is st=fail (transmission errors) that cause the signing backend to timeout. So it is not the performance of the atsha (or sw) that cause the issue here, it is the radio.
-
@tbowmo said:
While you're at it, also power down the external flash, as it might also contribute a bit..
I forgot about the flash. That would require bootloader support though? Or is the OTA done by jumping to the bootloader while running, keeping pin states?
I'm waiting for some SOIC breakouts in the mail. When I get them, I'll scavenge the ATSHA and flash module from my zombie sensor and build my own sensebender with blackjack and hookers.
-
Yes.. bootloader should probably by modified, if you decide to switch off the flash as well..
-
I did update the Arduino IDE and now I don't see the Sensebender Micro in the device list.
I'm using 1.6.5 and did copy the content to the boards.txt.Is there something else I have to do?
# See: http://code.google.com/p/arduino/wiki/Platforms menu.cpu=Processor ############################################################## yun.name=Arduino Yún yun.upload.via_ssh=true yun.vid.0=0x2341 yun.pid.0=0x0041 yun.vid.1=0x2341 yun.pid.1=0x8041 yun.vid.2=0x2A03 yun.pid.2=0x0041 yun.vid.3=0x2A03 yun.pid.3=0x8041 yun.upload.tool=avrdude yun.upload.protocol=avr109 yun.upload.maximum_size=28672 yun.upload.maximum_data_size=2560 yun.upload.speed=57600 yun.upload.disable_flushing=true yun.upload.use_1200bps_touch=true yun.upload.wait_for_upload_port=true yun.bootloader.tool=avrdude yun.bootloader.low_fuses=0xff yun.bootloader.high_fuses=0xd8 yun.bootloader.extended_fuses=0xfb yun.bootloader.file=caterina/Caterina-Yun.hex yun.bootloader.unlock_bits=0x3F yun.bootloader.lock_bits=0x2F yun.build.mcu=atmega32u4 yun.build.f_cpu=16000000L yun.build.vid=0x2341 yun.build.pid=0x8041 yun.build.usb_product="Arduino Yun" yun.build.board=AVR_YUN yun.build.core=arduino yun.build.variant=yun yun.build.extra_flags={build.usb_flags} ############################################################## uno.name=Arduino/Genuino Uno uno.vid.0=0x2341 uno.pid.0=0x0043 uno.vid.1=0x2341 uno.pid.1=0x0001 uno.vid.2=0x2A03 uno.pid.2=0x0043 uno.vid.3=0x2341 uno.pid.3=0x0243 uno.upload.tool=avrdude uno.upload.protocol=arduino uno.upload.maximum_size=32256 uno.upload.maximum_data_size=2048 uno.upload.speed=115200 uno.bootloader.tool=avrdude uno.bootloader.low_fuses=0xFF uno.bootloader.high_fuses=0xDE uno.bootloader.extended_fuses=0x05 uno.bootloader.unlock_bits=0x3F uno.bootloader.lock_bits=0x0F uno.bootloader.file=optiboot/optiboot_atmega328.hex uno.build.mcu=atmega328p uno.build.f_cpu=16000000L uno.build.board=AVR_UNO uno.build.core=arduino uno.build.variant=standard ############################################################## diecimila.name=Arduino Duemilanove or Diecimila diecimila.upload.tool=avrdude diecimila.upload.protocol=arduino diecimila.bootloader.tool=avrdude diecimila.bootloader.low_fuses=0xFF diecimila.bootloader.unlock_bits=0x3F diecimila.bootloader.lock_bits=0x0F diecimila.build.f_cpu=16000000L diecimila.build.board=AVR_DUEMILANOVE diecimila.build.core=arduino diecimila.build.variant=standard ## Arduino Duemilanove or Diecimila w/ ATmega328 ## --------------------------------------------- diecimila.menu.cpu.atmega328=ATmega328 diecimila.menu.cpu.atmega328.upload.maximum_size=30720 diecimila.menu.cpu.atmega328.upload.maximum_data_size=2048 diecimila.menu.cpu.atmega328.upload.speed=57600 diecimila.menu.cpu.atmega328.bootloader.high_fuses=0xDA diecimila.menu.cpu.atmega328.bootloader.extended_fuses=0x05 diecimila.menu.cpu.atmega328.bootloader.file=atmega/ATmegaBOOT_168_atmega328.hex diecimila.menu.cpu.atmega328.build.mcu=atmega328p ## Arduino Duemilanove or Diecimila w/ ATmega168 ## --------------------------------------------- diecimila.menu.cpu.atmega168=ATmega168 diecimila.menu.cpu.atmega168.upload.maximum_size=14336 diecimila.menu.cpu.atmega168.upload.maximum_data_size=1024 diecimila.menu.cpu.atmega168.upload.speed=19200 diecimila.menu.cpu.atmega168.bootloader.high_fuses=0xdd diecimila.menu.cpu.atmega168.bootloader.extended_fuses=0x00 diecimila.menu.cpu.atmega168.bootloader.file=atmega/ATmegaBOOT_168_diecimila.hex diecimila.menu.cpu.atmega168.build.mcu=atmega168 ############################################################## nano.name=Arduino Nano nano.upload.tool=avrdude nano.upload.protocol=arduino nano.bootloader.tool=avrdude nano.bootloader.unlock_bits=0x3F nano.bootloader.lock_bits=0x0F nano.build.f_cpu=16000000L nano.build.board=AVR_NANO nano.build.core=arduino nano.build.variant=eightanaloginputs ## Arduino Nano w/ ATmega328 ## ------------------------- nano.menu.cpu.atmega328=ATmega328 nano.menu.cpu.atmega328.upload.maximum_size=30720 nano.menu.cpu.atmega328.upload.maximum_data_size=2048 nano.menu.cpu.atmega328.upload.speed=57600 nano.menu.cpu.atmega328.bootloader.low_fuses=0xFF nano.menu.cpu.atmega328.bootloader.high_fuses=0xDA nano.menu.cpu.atmega328.bootloader.extended_fuses=0x05 nano.menu.cpu.atmega328.bootloader.file=atmega/ATmegaBOOT_168_atmega328.hex nano.menu.cpu.atmega328.build.mcu=atmega328p ## Arduino Nano w/ ATmega168 ## ------------------------- nano.menu.cpu.atmega168=ATmega168 nano.menu.cpu.atmega168.upload.maximum_size=14336 nano.menu.cpu.atmega168.upload.maximum_data_size=1024 nano.menu.cpu.atmega168.upload.speed=19200 nano.menu.cpu.atmega168.bootloader.low_fuses=0xff nano.menu.cpu.atmega168.bootloader.high_fuses=0xdd nano.menu.cpu.atmega168.bootloader.extended_fuses=0x00 nano.menu.cpu.atmega168.bootloader.file=atmega/ATmegaBOOT_168_diecimila.hex nano.menu.cpu.atmega168.build.mcu=atmega168 ############################################################## mega.name=Arduino/Genuino Mega or Mega 2560 mega.vid.0=0x2341 mega.pid.0=0x0010 mega.vid.1=0x2341 mega.pid.1=0x0042 mega.vid.2=0x2A03 mega.pid.2=0x0010 mega.vid.3=0x2A03 mega.pid.3=0x0042 mega.vid.4=0x2341 mega.pid.4=0x0210 mega.vid.5=0x2341 mega.pid.5=0x0242 mega.upload.tool=avrdude mega.upload.maximum_data_size=8192 mega.bootloader.tool=avrdude mega.bootloader.low_fuses=0xFF mega.bootloader.unlock_bits=0x3F mega.bootloader.lock_bits=0x0F mega.build.f_cpu=16000000L mega.build.core=arduino mega.build.variant=mega # default board may be overridden by the cpu menu mega.build.board=AVR_MEGA2560 ## Arduino/Genuino Mega w/ ATmega2560 ## ------------------------- mega.menu.cpu.atmega2560=ATmega2560 (Mega 2560) mega.menu.cpu.atmega2560.upload.protocol=wiring mega.menu.cpu.atmega2560.upload.maximum_size=253952 mega.menu.cpu.atmega2560.upload.speed=115200 mega.menu.cpu.atmega2560.bootloader.high_fuses=0xD8 mega.menu.cpu.atmega2560.bootloader.extended_fuses=0xFD mega.menu.cpu.atmega2560.bootloader.file=stk500v2/stk500boot_v2_mega2560.hex mega.menu.cpu.atmega2560.build.mcu=atmega2560 mega.menu.cpu.atmega2560.build.board=AVR_MEGA2560 ## Arduino Mega w/ ATmega1280 ## ------------------------- mega.menu.cpu.atmega1280=ATmega1280 mega.menu.cpu.atmega1280.upload.protocol=arduino mega.menu.cpu.atmega1280.upload.maximum_size=126976 mega.menu.cpu.atmega1280.upload.speed=57600 mega.menu.cpu.atmega1280.bootloader.high_fuses=0xDA mega.menu.cpu.atmega1280.bootloader.extended_fuses=0xF5 mega.menu.cpu.atmega1280.bootloader.file=atmega/ATmegaBOOT_168_atmega1280.hex mega.menu.cpu.atmega1280.build.mcu=atmega1280 mega.menu.cpu.atmega1280.build.board=AVR_MEGA ############################################################## megaADK.name=Arduino Mega ADK megaADK.vid.0=0x2341 megaADK.pid.0=0x003f megaADK.vid.1=0x2341 megaADK.pid.1=0x0044 megaADK.vid.2=0x2A03 megaADK.pid.2=0x003f megaADK.vid.3=0x2A03 megaADK.pid.3=0x0044 megaADK.upload.tool=avrdude megaADK.upload.protocol=wiring megaADK.upload.maximum_size=253952 megaADK.upload.maximum_data_size=8192 megaADK.upload.speed=115200 megaADK.bootloader.tool=avrdude megaADK.bootloader.low_fuses=0xFF megaADK.bootloader.high_fuses=0xD8 megaADK.bootloader.extended_fuses=0xFD megaADK.bootloader.file=stk500v2/stk500boot_v2_mega2560.hex megaADK.bootloader.unlock_bits=0x3F megaADK.bootloader.lock_bits=0x0F megaADK.build.mcu=atmega2560 megaADK.build.f_cpu=16000000L megaADK.build.board=AVR_ADK megaADK.build.core=arduino megaADK.build.variant=mega ############################################################## leonardo.name=Arduino Leonardo leonardo.vid.0=0x2341 leonardo.pid.0=0x0036 leonardo.vid.1=0x2341 leonardo.pid.1=0x8036 leonardo.vid.2=0x2A03 leonardo.pid.2=0x0036 leonardo.vid.3=0x2A03 leonardo.pid.3=0x8036 leonardo.upload.tool=avrdude leonardo.upload.protocol=avr109 leonardo.upload.maximum_size=28672 leonardo.upload.maximum_data_size=2560 leonardo.upload.speed=57600 leonardo.upload.disable_flushing=true leonardo.upload.use_1200bps_touch=true leonardo.upload.wait_for_upload_port=true leonardo.bootloader.tool=avrdude leonardo.bootloader.low_fuses=0xff leonardo.bootloader.high_fuses=0xd8 leonardo.bootloader.extended_fuses=0xcb leonardo.bootloader.file=caterina/Caterina-Leonardo.hex leonardo.bootloader.unlock_bits=0x3F leonardo.bootloader.lock_bits=0x2F leonardo.build.mcu=atmega32u4 leonardo.build.f_cpu=16000000L leonardo.build.vid=0x2341 leonardo.build.pid=0x8036 leonardo.build.usb_product="Arduino Leonardo" leonardo.build.board=AVR_LEONARDO leonardo.build.core=arduino leonardo.build.variant=leonardo leonardo.build.extra_flags={build.usb_flags} ############################################################## micro.name=Arduino/Genuino Micro micro.vid.0=0x2341 micro.pid.0=0x0037 micro.vid.1=0x2341 micro.pid.1=0x8037 micro.vid.2=0x2A03 micro.pid.2=0x0037 micro.vid.3=0x2A03 micro.pid.3=0x8037 micro.vid.4=0x2341 micro.pid.4=0x0237 # If the board is a 2341:0237 use 2341:8237 for build and set # other parameters as well micro.vid.4.build.vid=0x2341 micro.vid.4.build.pid=0x8237 micro.vid.4.build.usb_product="Genuino Micro" micro.vid.4.bootloader.file=caterina/Caterina-Genuino-Micro.hex micro.vid.5=0x2341 micro.pid.5=0x8237 # If the board is a 2341:8237 use 2341:8237 for build and set # other paramters as well micro.vid.5.build.vid=0x2341 micro.vid.5.build.pid=0x8237 micro.vid.5.build.usb_product="Genuino Micro" micro.vid.5.bootloader.file=caterina/Caterina-Genuino-Micro.hex micro.upload.tool=avrdude micro.upload.protocol=avr109 micro.upload.maximum_size=28672 micro.upload.maximum_data_size=2560 micro.upload.speed=57600 micro.upload.disable_flushing=true micro.upload.use_1200bps_touch=true micro.upload.wait_for_upload_port=true micro.bootloader.tool=avrdude micro.bootloader.low_fuses=0xff micro.bootloader.high_fuses=0xd8 micro.bootloader.extended_fuses=0xcb micro.bootloader.file=caterina/Caterina-Micro.hex micro.bootloader.unlock_bits=0x3F micro.bootloader.lock_bits=0x2F micro.build.mcu=atmega32u4 micro.build.f_cpu=16000000L micro.build.vid=0x2341 micro.build.pid=0x8037 micro.build.usb_product="Arduino Micro" micro.build.board=AVR_MICRO micro.build.core=arduino micro.build.variant=micro micro.build.extra_flags={build.usb_flags} ############################################################## esplora.name=Arduino Esplora esplora.vid.0=0x2341 esplora.pid.0=0x003C esplora.vid.1=0x2341 esplora.pid.1=0x803C esplora.vid.2=0x2A03 esplora.pid.2=0x003C esplora.vid.3=0x2A03 esplora.pid.3=0x803C esplora.upload.tool=avrdude esplora.upload.protocol=avr109 esplora.upload.maximum_size=28672 esplora.upload.maximum_data_size=2560 esplora.upload.speed=57600 esplora.upload.disable_flushing=true esplora.upload.use_1200bps_touch=true esplora.upload.wait_for_upload_port=true esplora.bootloader.tool=avrdude esplora.bootloader.low_fuses=0xff esplora.bootloader.high_fuses=0xd8 esplora.bootloader.extended_fuses=0xcb esplora.bootloader.file=caterina/Caterina-Esplora.hex esplora.bootloader.unlock_bits=0x3F esplora.bootloader.lock_bits=0x2F esplora.build.mcu=atmega32u4 esplora.build.f_cpu=16000000L esplora.build.vid=0x2341 esplora.build.pid=0x803c esplora.build.usb_product="Arduino Esplora" esplora.build.board=AVR_ESPLORA esplora.build.core=arduino esplora.build.variant=leonardo esplora.build.extra_flags={build.usb_flags} ############################################################## mini.name=Arduino Mini mini.upload.tool=avrdude mini.upload.protocol=arduino mini.bootloader.tool=avrdude mini.bootloader.low_fuses=0xff mini.bootloader.unlock_bits=0x3F mini.bootloader.lock_bits=0x0F mini.build.f_cpu=16000000L mini.build.board=AVR_MINI mini.build.core=arduino mini.build.variant=eightanaloginputs ## Arduino Mini w/ ATmega328 ## ------------------------- mini.menu.cpu.atmega328=ATmega328 mini.menu.cpu.atmega328.upload.maximum_size=28672 mini.menu.cpu.atmega328.upload.maximum_data_size=2048 mini.menu.cpu.atmega328.upload.speed=115200 mini.menu.cpu.atmega328.bootloader.high_fuses=0xd8 mini.menu.cpu.atmega328.bootloader.extended_fuses=0x05 mini.menu.cpu.atmega328.bootloader.file=optiboot/optiboot_atmega328-Mini.hex mini.menu.cpu.atmega328.build.mcu=atmega328p ## Arduino Mini w/ ATmega168 ## ------------------------- mini.menu.cpu.atmega168=ATmega168 mini.menu.cpu.atmega168.upload.maximum_size=14336 mini.menu.cpu.atmega168.upload.maximum_data_size=1024 mini.menu.cpu.atmega168.upload.speed=19200 mini.menu.cpu.atmega168.bootloader.high_fuses=0xdd mini.menu.cpu.atmega168.bootloader.extended_fuses=0x00 mini.menu.cpu.atmega168.bootloader.file=atmega/ATmegaBOOT_168_ng.hex mini.menu.cpu.atmega168.build.mcu=atmega168 ############################################################## ethernet.name=Arduino Ethernet ethernet.upload.tool=avrdude ethernet.upload.protocol=arduino ethernet.upload.maximum_size=32256 ethernet.upload.maximum_data_size=2048 ethernet.upload.speed=115200 ethernet.bootloader.tool=avrdude ethernet.bootloader.low_fuses=0xff ethernet.bootloader.high_fuses=0xde ethernet.bootloader.extended_fuses=0x05 ethernet.bootloader.file=optiboot/optiboot_atmega328.hex ethernet.bootloader.unlock_bits=0x3F ethernet.bootloader.lock_bits=0x0F ethernet.build.variant=ethernet ethernet.build.mcu=atmega328p ethernet.build.f_cpu=16000000L ethernet.build.board=AVR_ETHERNET ethernet.build.core=arduino ############################################################## fio.name=Arduino Fio fio.upload.tool=avrdude fio.upload.protocol=arduino fio.upload.maximum_size=30720 fio.upload.maximum_data_size=2048 fio.upload.speed=57600 fio.bootloader.tool=avrdude fio.bootloader.low_fuses=0xFF fio.bootloader.high_fuses=0xDA fio.bootloader.extended_fuses=0x05 fio.bootloader.file=atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex fio.bootloader.unlock_bits=0x3F fio.bootloader.lock_bits=0x0F fio.build.mcu=atmega328p fio.build.f_cpu=8000000L fio.build.board=AVR_FIO fio.build.core=arduino fio.build.variant=eightanaloginputs ############################################################## bt.name=Arduino BT bt.upload.tool=avrdude bt.upload.protocol=arduino bt.upload.speed=19200 bt.upload.disable_flushing=true bt.bootloader.tool=avrdude bt.bootloader.low_fuses=0xff bt.bootloader.unlock_bits=0x3F bt.bootloader.lock_bits=0x0F bt.build.f_cpu=16000000L bt.build.board=AVR_BT bt.build.core=arduino bt.build.variant=eightanaloginputs ## Arduino BT w/ ATmega328 ## ----------------------- bt.menu.cpu.atmega328=ATmega328 bt.menu.cpu.atmega328.upload.maximum_size=28672 bt.menu.cpu.atmega328.upload.maximum_data_size=2048 bt.menu.cpu.atmega328.bootloader.high_fuses=0xd8 bt.menu.cpu.atmega328.bootloader.extended_fuses=0x05 bt.menu.cpu.atmega328.bootloader.file=bt/ATmegaBOOT_168_atmega328_bt.hex bt.menu.cpu.atmega328.build.mcu=atmega328p ## Arduino BT w/ ATmega168 ## ----------------------- bt.menu.cpu.atmega168=ATmega168 bt.menu.cpu.atmega168.upload.maximum_size=14336 bt.menu.cpu.atmega168.upload.maximum_data_size=1024 bt.menu.cpu.atmega168.bootloader.high_fuses=0xdd bt.menu.cpu.atmega168.bootloader.extended_fuses=0x00 bt.menu.cpu.atmega168.bootloader.file=bt/ATmegaBOOT_168.hex bt.menu.cpu.atmega168.build.mcu=atmega168 ############################################################## LilyPadUSB.name=LilyPad Arduino USB LilyPadUSB.vid.0=0x1B4F LilyPadUSB.pid.0=0x9207 LilyPadUSB.vid.1=0x1B4F LilyPadUSB.pid.1=0x9208 LilyPadUSB.upload.tool=avrdude LilyPadUSB.upload.protocol=avr109 LilyPadUSB.upload.maximum_size=28672 LilyPadUSB.upload.maximum_data_size=2560 LilyPadUSB.upload.speed=57600 LilyPadUSB.upload.disable_flushing=true LilyPadUSB.upload.use_1200bps_touch=true LilyPadUSB.upload.wait_for_upload_port=true LilyPadUSB.bootloader.tool=avrdude LilyPadUSB.bootloader.low_fuses=0xff LilyPadUSB.bootloader.high_fuses=0xd8 LilyPadUSB.bootloader.extended_fuses=0xce LilyPadUSB.bootloader.file=caterina-LilyPadUSB/Caterina-LilyPadUSB.hex LilyPadUSB.bootloader.unlock_bits=0x3F LilyPadUSB.bootloader.lock_bits=0x2F LilyPadUSB.build.mcu=atmega32u4 LilyPadUSB.build.f_cpu=8000000L LilyPadUSB.build.vid=0x1B4F LilyPadUSB.build.pid=0x9208 LilyPadUSB.build.usb_product="LilyPad USB" LilyPadUSB.build.board=AVR_LILYPAD_USB LilyPadUSB.build.core=arduino LilyPadUSB.build.variant=leonardo LilyPadUSB.build.extra_flags={build.usb_flags} ############################################################## lilypad.name=LilyPad Arduino lilypad.upload.tool=avrdude lilypad.upload.protocol=arduino lilypad.bootloader.tool=avrdude lilypad.bootloader.unlock_bits=0x3F lilypad.bootloader.lock_bits=0x0F lilypad.build.f_cpu=8000000L lilypad.build.board=AVR_LILYPAD lilypad.build.core=arduino lilypad.build.variant=standard ## LilyPad Arduino w/ ATmega328 ## ---------------------------- lilypad.menu.cpu.atmega328=ATmega328 lilypad.menu.cpu.atmega328.upload.maximum_size=30720 lilypad.menu.cpu.atmega328.upload.maximum_data_size=2048 lilypad.menu.cpu.atmega328.upload.speed=57600 lilypad.menu.cpu.atmega328.bootloader.low_fuses=0xFF lilypad.menu.cpu.atmega328.bootloader.high_fuses=0xDA lilypad.menu.cpu.atmega328.bootloader.extended_fuses=0x05 lilypad.menu.cpu.atmega328.bootloader.file=atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex lilypad.menu.cpu.atmega328.build.mcu=atmega328p ## LilyPad Arduino w/ ATmega168 ## ---------------------------- lilypad.menu.cpu.atmega168=ATmega168 lilypad.menu.cpu.atmega168.upload.maximum_size=14336 lilypad.menu.cpu.atmega168.upload.maximum_data_size=1024 lilypad.menu.cpu.atmega168.upload.speed=19200 lilypad.menu.cpu.atmega168.bootloader.low_fuses=0xe2 lilypad.menu.cpu.atmega168.bootloader.high_fuses=0xdd lilypad.menu.cpu.atmega168.bootloader.extended_fuses=0x00 lilypad.menu.cpu.atmega168.bootloader.file=lilypad/LilyPadBOOT_168.hex lilypad.menu.cpu.atmega168.build.mcu=atmega168 ############################################################## pro.name=Arduino Pro or Pro Mini pro.upload.tool=avrdude pro.upload.protocol=arduino pro.bootloader.tool=avrdude pro.bootloader.unlock_bits=0x3F pro.bootloader.lock_bits=0x0F pro.build.board=AVR_PRO pro.build.core=arduino pro.build.variant=eightanaloginputs ## Arduino Pro or Pro Mini (5V, 16 MHz) w/ ATmega328 ## ------------------------------------------------- pro.menu.cpu.16MHzatmega328=ATmega328 (5V, 16 MHz) pro.menu.cpu.16MHzatmega328.upload.maximum_size=30720 pro.menu.cpu.16MHzatmega328.upload.maximum_data_size=2048 pro.menu.cpu.16MHzatmega328.upload.speed=57600 pro.menu.cpu.16MHzatmega328.bootloader.low_fuses=0xFF pro.menu.cpu.16MHzatmega328.bootloader.high_fuses=0xDA pro.menu.cpu.16MHzatmega328.bootloader.extended_fuses=0x05 pro.menu.cpu.16MHzatmega328.bootloader.file=atmega/ATmegaBOOT_168_atmega328.hex pro.menu.cpu.16MHzatmega328.build.mcu=atmega328p pro.menu.cpu.16MHzatmega328.build.f_cpu=16000000L ## Arduino Pro or Pro Mini (3.3V, 8 MHz) w/ ATmega328 ## -------------------------------------------------- pro.menu.cpu.8MHzatmega328=ATmega328 (3.3V, 8 MHz) pro.menu.cpu.8MHzatmega328.upload.maximum_size=30720 pro.menu.cpu.8MHzatmega328.upload.maximum_data_size=2048 pro.menu.cpu.8MHzatmega328.upload.speed=57600 pro.menu.cpu.8MHzatmega328.bootloader.low_fuses=0xFF pro.menu.cpu.8MHzatmega328.bootloader.high_fuses=0xDA pro.menu.cpu.8MHzatmega328.bootloader.extended_fuses=0x05 pro.menu.cpu.8MHzatmega328.bootloader.file=atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex pro.menu.cpu.8MHzatmega328.build.mcu=atmega328p pro.menu.cpu.8MHzatmega328.build.f_cpu=8000000L ## Arduino Pro or Pro Mini (5V, 16 MHz) w/ ATmega168 ## ------------------------------------------------- pro.menu.cpu.16MHzatmega168=ATmega168 (5V, 16 MHz) pro.menu.cpu.16MHzatmega168.upload.maximum_size=14336 pro.menu.cpu.16MHzatmega168.upload.maximum_data_size=1024 pro.menu.cpu.16MHzatmega168.upload.speed=19200 pro.menu.cpu.16MHzatmega168.bootloader.low_fuses=0xff pro.menu.cpu.16MHzatmega168.bootloader.high_fuses=0xdd pro.menu.cpu.16MHzatmega168.bootloader.extended_fuses=0x00 pro.menu.cpu.16MHzatmega168.bootloader.file=atmega/ATmegaBOOT_168_diecimila.hex pro.menu.cpu.16MHzatmega168.build.mcu=atmega168 pro.menu.cpu.16MHzatmega168.build.f_cpu=16000000L ## Arduino Pro or Pro Mini (3.3V, 8 MHz) w/ ATmega168 ## -------------------------------------------------- pro.menu.cpu.8MHzatmega168=ATmega168 (3.3V, 8 MHz) pro.menu.cpu.8MHzatmega168.upload.maximum_size=14336 pro.menu.cpu.8MHzatmega168.upload.maximum_data_size=1024 pro.menu.cpu.8MHzatmega168.upload.speed=19200 pro.menu.cpu.8MHzatmega168.bootloader.low_fuses=0xc6 pro.menu.cpu.8MHzatmega168.bootloader.high_fuses=0xdd pro.menu.cpu.8MHzatmega168.bootloader.extended_fuses=0x00 pro.menu.cpu.8MHzatmega168.bootloader.file=atmega/ATmegaBOOT_168_pro_8MHz.hex pro.menu.cpu.8MHzatmega168.build.mcu=atmega168 pro.menu.cpu.8MHzatmega168.build.f_cpu=8000000L ############################################################## atmegang.name=Arduino NG or older atmegang.upload.tool=avrdude atmegang.upload.protocol=arduino atmegang.upload.speed=19200 atmegang.bootloader.tool=avrdude atmegang.bootloader.unlock_bits=0x3F atmegang.bootloader.lock_bits=0x0F atmegang.build.mcu=atmegang atmegang.build.f_cpu=16000000L atmegang.build.board=AVR_NG atmegang.build.core=arduino atmegang.build.variant=standard ## Arduino NG or older w/ ATmega168 ## -------------------------------- atmegang.menu.cpu.atmega168=ATmega168 atmegang.menu.cpu.atmega168.upload.maximum_size=14336 atmegang.menu.cpu.atmega168.upload.maximum_data_size=1024 atmegang.menu.cpu.atmega168.bootloader.low_fuses=0xff atmegang.menu.cpu.atmega168.bootloader.high_fuses=0xdd atmegang.menu.cpu.atmega168.bootloader.extended_fuses=0x00 atmegang.menu.cpu.atmega168.bootloader.file=atmega/ATmegaBOOT_168_ng.hex atmegang.menu.cpu.atmega168.build.mcu=atmega168 ## Arduino NG or older w/ ATmega8 ## ------------------------------ atmegang.menu.cpu.atmega8=ATmega8 atmegang.menu.cpu.atmega8.upload.maximum_size=7168 atmegang.menu.cpu.atmega8.upload.maximum_data_size=1024 atmegang.menu.cpu.atmega8.bootloader.low_fuses=0xdf atmegang.menu.cpu.atmega8.bootloader.high_fuses=0xca atmegang.menu.cpu.atmega8.bootloader.file=atmega8/ATmegaBOOT-prod-firmware-2009-11-07.hex atmegang.menu.cpu.atmega8.build.mcu=atmega8 ############################################################## robotControl.name=Arduino Robot Control robotControl.vid.0=0x2341 robotControl.pid.0=0x0038 robotControl.vid.1=0x2341 robotControl.pid.1=0x8038 robotControl.vid.2=0x2A03 robotControl.pid.2=0x0038 robotControl.vid.3=0x2A03 robotControl.pid.3=0x8038 robotControl.upload.tool=avrdude robotControl.upload.protocol=avr109 robotControl.upload.maximum_size=28672 robotControl.upload.maximum_data_size=2560 robotControl.upload.speed=57600 robotControl.upload.disable_flushing=true robotControl.upload.use_1200bps_touch=true robotControl.upload.wait_for_upload_port=true robotControl.bootloader.tool=avrdude robotControl.bootloader.low_fuses=0xff robotControl.bootloader.high_fuses=0xd8 robotControl.bootloader.extended_fuses=0xcb robotControl.bootloader.file=caterina-Arduino_Robot/Caterina-Robot-Control.hex robotControl.bootloader.unlock_bits=0x3F robotControl.bootloader.lock_bits=0x2F robotControl.build.mcu=atmega32u4 robotControl.build.f_cpu=16000000L robotControl.build.vid=0x2341 robotControl.build.pid=0x8038 robotControl.build.usb_product="Robot Control" robotControl.build.board=AVR_ROBOT_CONTROL robotControl.build.core=arduino robotControl.build.variant=robot_control robotControl.build.extra_flags={build.usb_flags} ############################################################## robotMotor.name=Arduino Robot Motor robotMotor.vid.0=0x2341 robotMotor.pid.0=0x0039 robotMotor.vid.1=0x2341 robotMotor.pid.1=0x8039 robotMotor.vid.2=0x2A03 robotMotor.pid.2=0x0039 robotMotor.vid.3=0x2A03 robotMotor.pid.3=0x8039 robotMotor.upload.tool=avrdude robotMotor.upload.protocol=avr109 robotMotor.upload.maximum_size=28672 robotMotor.upload.maximum_data_size=2560 robotMotor.upload.speed=57600 robotMotor.upload.disable_flushing=true robotMotor.upload.use_1200bps_touch=true robotMotor.upload.wait_for_upload_port=true robotMotor.bootloader.tool=avrdude robotMotor.bootloader.low_fuses=0xff robotMotor.bootloader.high_fuses=0xd8 robotMotor.bootloader.extended_fuses=0xcb robotMotor.bootloader.file=caterina-Arduino_Robot/Caterina-Robot-Motor.hex robotMotor.bootloader.unlock_bits=0x3F robotMotor.bootloader.lock_bits=0x2F robotMotor.build.mcu=atmega32u4 robotMotor.build.f_cpu=16000000L robotMotor.build.vid=0x2341 robotMotor.build.pid=0x8039 robotMotor.build.usb_product="Robot Motor" robotMotor.build.board=AVR_ROBOT_MOTOR robotMotor.build.core=arduino robotMotor.build.variant=robot_motor robotMotor.build.extra_flags={build.usb_flags} ############################################################## gemma.vid.0=0x2341 gemma.pid.0=0x0c9f gemma.name=Arduino Gemma gemma.bootloader.low_fuses=0xF1 gemma.bootloader.high_fuses=0xD5 gemma.bootloader.extended_fuses=0xFE gemma.bootloader.tool=avrdude gemma.bootloader.lock_bits= gemma.bootloader.unlock_bits= gemma.bootloader.file=gemma/gemma_v1.hex gemma.build.mcu=attiny85 gemma.build.f_cpu=8000000L gemma.build.core=arduino gemma.build.variant=gemma gemma.build.board=AVR_GEMMA gemma.upload.tool=avrdude gemma.upload.maximum_size=5310 menu.cpu=Processor ###################################### ## Sensebender Micro MysensorsMicro.name=Sensebender Micro MysensorsMicro.upload.tool=arduino:avrdude MysensorsMicro.upload.protocol=arduino MysensorsMicro.upload.maximum_size=30720 MysensorsMicro.upload.maximum_data_size=2048 MysensorsMicro.upload.speed=57600 MysensorsMicro.bootloader.tool=arduino:avrdude MysensorsMicro.bootloader.unlock_bits=0x3F MysensorsMicro.bootloader.lock_bits=0x0F MysensorsMicro.bootloader.low_fuses=0xE2 MysensorsMicro.bootloader.high_fuses=0xD2 MysensorsMicro.bootloader.extended_fuses=0x06 MysensorsMicro.bootloader.file=DualOptiboot/optiboot_atmega328_pro_8MHz.hex MysensorsMicro.build.board=AVR_MICRO8 MysensorsMicro.build.core=arduino:arduino MysensorsMicro.build.variant=micro MysensorsMicro.build.mcu=atmega328p #MysensorsMicro.build.f_cpu=8000000L MysensorsMicro.menu.cpu.8Mhz=Atmega328 8Mhz MysensorsMicro.menu.cpu.8Mhz.build.f_cpu=8000000L MysensorsMicro.menu.cpu.1Mhz=Atmega328 1Mhz MysensorsMicro.menu.cpu.1Mhz.build.f_cpu=1000000LI'm using a Mac if it is important.
-
Is it possible to use the ftdi or isp vcc / gnd to connect a pir ?
or do i need to source separate power and gnd for pir ?
-
@gloob
Maybe a little late, but the Sensebender is now available to be downloaded directly in the IDE using board manager.
https://github.com/mysensors/ArduinoBoards@alexeinz
You can use the same power/ground plane (and any of the digital inputs). Also note that the pir might need to be modified to handle 3v3.
https://forum.mysensors.org/topic/1088/battery-powered-pir
-
@hek ...so to clarify , I can use the VCC and Ground of the ISP portion to power the sensor?
( my pir already modded for 3.3 )
-
Yes, it doesn't matter. GND/VCC is the same no matter where you pull it on the board.
-
@Anticimex
@ximinez said:Looks like it works now, but what's the deal with the initial failed signs? Look at http://pastebin.ca/3585005 (GW side) and http://pastebin.ca/3585014 (Sensor side. Not the same powerup). It starts by failing a lot, then after a while everything looks OK.
I have exactly the same problem with Ethernet GW (Mega + Ethernet shield) + Sensebender:
GW:
0;255;3;0;9;Starting gateway (RNNGAS, 2.0.0-beta) 0;255;3;0;9;Radio init successful. IP: 0.0.0.0 0;255;3;0;9;Init complete, id=0, parent=0, distance=0 0;255;3;0;9;Skipping security for command 3 type 16 0;255;3;0;9;read: 3-3-0 s=255,c=3,t=16,pt=0,l=0,sg=0: 0;255;3;0;9;Signing backend: ATSHA204Soft 0;255;3;0;9;SHA256: 86DEAE1DAF50D577A4E2262B33ABF9DEE05DD8FAF84F94F50900000000000000 0;255;3;0;9;Transmittng nonce 0;255;3;0;9;Skipping security for command 3 type 17 0;255;3;0;9;send: 0-0-3-3 s=255,c=3,t=17,pt=6,l=25,sg=0,st=fail:86DEAE1DAF50D577A4E2262B33ABF9DEE05DD8FAF84F94F509 0;255;3;0;9;Message is not signed, but it should have been! 0;255;3;0;9;verify fail 0;255;3;0;9;Skipping security for command 3 type 16 0;255;3;0;9;read: 3-3-0 s=255,c=3,t=16,pt=0,l=0,sg=0: 0;255;3;0;9;Signing backend: ATSHA204Soft 0;255;3;0;9;SHA256: 5D009DC0245C411DABE519AB62E32B24333CA92BE1BA9EC1CBAAAAAAAAAAAAAA 0;255;3;0;9;Transmittng nonce 0;255;3;0;9;Skipping security for command 3 type 17 0;255;3;0;9;send: 0-0-3-3 s=255,c=3,t=17,pt=6,l=25,sg=0,st=fail:5D009DC0245C411DABE519AB62E32B24333CA92BE1BA9EC1CB 0;255;3;0;9;Message is not signed, but it should have been! 0;255;3;0;9;verify fail 0;255;3;0;9;Skipping security for command 3 type 16 0;255;3;0;9;read: 3-3-0 s=1,c=3,t=16,pt=0,l=0,sg=0: 0;255;3;0;9;Signing backend: ATSHA204Soft 0;255;3;0;9;SHA256: EF67FAAED617A07C4EFC978F44BD41B77A4834BB83581C19FFAAAAAAAAAAAAAA 0;255;3;0;9;Transmittng nonce 0;255;3;0;9;Skipping security for command 3 type 17 0;255;3;0;9;send: 0-0-3-3 s=255,c=3,t=17,pt=6,l=25,sg=0,st=fail:EF67FAAED617A07C4EFC978F44BD41B77A4834BB83581C19FF 0;255;3;0;9;Message is not signed, but it should have been! 0;255;3;0;9;verify fail 0;255;3;0;9;Skipping security for command 3 type 16 0;255;3;0;9;read: 3-3-0 s=2,c=3,t=16,pt=0,l=0,sg=0: 0;255;3;0;9;Signing backend: ATSHA204Soft 0;255;3;0;9;SHA256: 41D57E19D687AC4EBCC59179C6ADC1E155A252315EB1DF4F89AAAAAAAAAAAAAA 0;255;3;0;9;Transmittng nonce 0;255;3;0;9;Skipping security for command 3 type 17 0;255;3;0;9;send: 0-0-3-3 s=255,c=3,t=17,pt=6,l=25,sg=0,st=fail:41D57E19D687AC4EBCC59179C6ADC1E155A252315EB1DF4F89 0;255;3;0;9;Message is not signed, but it should have been! 0;255;3;0;9;verify fail 0;255;3;0;9;Skipping security for command 3 type 16 0;255;3;0;9;read: 3-3-0 s=3,c=3,t=16,pt=0,l=0,sg=0: 0;255;3;0;9;Signing backend: ATSHA204Soft 0;255;3;0;9;SHA256: FEBB9B588209F4FAAB95A64FCAD9F4B0E5025356AC4E0935DDAAAAAAAAAAAAAA 0;255;3;0;9;Transmittng nonce 0;255;3;0;9;Skipping security for command 3 type 17 0;255;3;0;9;send: 0-0-3-3 s=255,c=3,t=17,pt=6,l=25,sg=0,st=fail:FEBB9B588209F4FAAB95A64FCAD9F4B0E5025356AC4E0935DD 0;255;3;0;9;Message is not signed, but it should have been! 0;255;3;0;9;verify fail 0;255;3;0;9;Verification timeout 0;255;3;0;9;Skipping security for command 3 type 16 0;255;3;0;9;read: 3-3-0 s=1,c=3,t=16,pt=0,l=0,sg=0: 0;255;3;0;9;Signing backend: ATSHA204Soft 0;255;3;0;9;SHA256: B1E3C1C0EA9829F4B0240246C91DB8B7C29EBB3255D4F6117CAAAAAAAAAAAAAA 0;255;3;0;9;Transmittng nonce 0;255;3;0;9;Skipping security for command 3 type 17 0;255;3;0;9;send: 0-0-3-3 s=255,c=3,t=17,pt=6,l=25,sg=0,st=fail:B1E3C1C0EA9829F4B0240246C91DB8B7C29EBB3255D4F6117C 0;255;3;0;9;Message is not signed, but it should have been! 0;255;3;0;9;verify fail 0;255;3;0;9;Skipping security for command 3 type 16 0;255;3;0;9;read: 3-3-0 s=2,c=3,t=16,pt=0,l=0,sg=0: 0;255;3;0;9;Signing backend: ATSHA204Soft 0;255;3;0;9;SHA256: 92BAB2A723258EA923048423F81DA245F3F932AF64F22C5F40AAAAAAAAAAAAAA 0;255;3;0;9;Transmittng nonce 0;255;3;0;9;Skipping security for command 3 type 17 0;255;3;0;9;send: 0-0-3-3 s=255,c=3,t=17,pt=6,l=25,sg=0,st=fail:92BAB2A723258EA923048423F81DA245F3F932AF64F22C5F40 0;255;3;0;9;Message is not signed, but it should have been! 0;255;3;0;9;verify fail 0;255;3;0;9;Skipping security for command 3 type 16 0;255;3;0;9;read: 3-3-0 s=3,c=3,t=16,pt=0,l=0,sg=0: 0;255;3;0;9;Signing backend: ATSHA204Soft 0;255;3;0;9;SHA256: B5D717D5B8F0F93A030B0125F273C002AED8DB29AC175C80E4AAAAAAAAAAAAAA 0;255;3;0;9;Transmittng nonce 0;255;3;0;9;Skipping security for command 3 type 17 0;255;3;0;9;send: 0-0-3-3 s=255,c=3,t=17,pt=6,l=25,sg=0,st=fail:B5D717D5B8F0F93A030B0125F273C002AED8DB29AC175C80E4 0;255;3;0;9;Message is not signed, but it should have been! 0;255;3;0;9;verify fail 0;255;3;0;9;Skipping security for command 3 type 16 0;255;3;0;9;read: 3-3-0 s=255,c=3,t=16,pt=0,l=0,sg=0: 0;255;3;0;9;Signing backend: ATSHA204Soft 0;255;3;0;9;SHA256: B2D64F2C3EB1CCBA1250FF88120A8877E3414546D1B209C2AEAAAAAAAAAAAAAA 0;255;3;0;9;Transmittng nonce 0;255;3;0;9;Skipping security for command 3 type 17 0;255;3;0;9;send: 0-0-3-3 s=255,c=3,t=17,pt=6,l=25,sg=0,st=fail:B2D64F2C3EB1CCBA1250FF88120A8877E3414546D1B209C2AE 0;255;3;0;9;Message is not signed, but it should have been! 0;255;3;0;9;verify fail 0;255;3;0;9;Skipping security for command 3 type 15 0;255;3;0;9;read: 3-3-0 s=255,c=3,t=15,pt=0,l=2,sg=0: 0;255;3;0;9;Mark node 3 as one that require signed messages 0;255;3;0;9;Mark node 3 as one that do not require whitelisting 0;255;3;0;9;Informing node 3 that we require signatures 0;255;3;0;9;Informing node 3 that we do not require whitelisting 0;255;3;0;9;Skipping security for command 3 type 15 0;255;3;0;9;send: 0-0-3-3 s=255,c=3,t=15,pt=0,l=2,sg=0,st=ok: 0;255;3;0;9;Verification timeout 0;255;3;0;9;Skipping security for command 3 type 16 0;255;3;0;9;read: 3-3-0 s=255,c=3,t=16,pt=0,l=0,sg=0: 0;255;3;0;9;Signing backend: ATSHA204Soft 0;255;3;0;9;SHA256: 04C65FB99F798197CD5474AE7CC8625595B49655D311173412AAAAAAAAAAAAAA 0;255;3;0;9;Transmittng nonce 0;255;3;0;9;Skipping security for command 3 type 17 0;255;3;0;9;send: 0-0-3-3 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:04C65FB99F798197CD5474AE7CC8625595B49655D311173412 0;255;3;0;9;Signature in message: 010017891177284094289CCA41F5E3 0;255;3;0;9;Message to process: 0300560011FF322E302E302D62657461 0;255;3;0;9;Current nonce: 04C65FB99F798197CD5474AE7CC8625595B49655D311173412AAAAAAAAAAAAAA 0;255;3;0;9;HMAC: 37A3D7AFFCD292EAFD64017F9845DD4AD49624C37348B63B87699D273CA5F27F 0;255;3;0;9;Signature bad: 01A3D7AFFCD292EAFD64017F9845DD 0;255;3;0;9;Signature verification failed! 0;255;3;0;9;verify fail 0;255;3;0;9;Skipping security for command 3 type 16 0;255;3;0;9;read: 3-3-0 s=255,c=3,t=16,pt=0,l=0,sg=0: 0;255;3;0;9;Signing backend: ATSHA204Soft 0;255;3;0;9;SHA256: 66CC761B15338987ABA7DDEB567F78EFA6E32BD0A6895A8EDDAAAAAAAAAAAAAA 0;255;3;0;9;Transmittng nonce 0;255;3;0;9;Skipping security for command 3 type 17 0;255;3;0;9;send: 0-0-3-3 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:66CC761B15338987ABA7DDEB567F78EFA6E32BD0A6895A8EDD 0;255;3;0;9;Signature in message: 0127D1050EA18AC0EE1FD1C5C1496AE3772D390F25E4D6B5 0;255;3;0;9;Message to process: 03000E2306FF00 0;255;3;0;9;Current nonce: 66CC761B15338987ABA7DDEB567F78EFA6E32BD0A6895A8EDDAAAAAAAAAAAAAA 0;255;3;0;9;HMAC: 69E44BF99E8E4842A47D14C11B849C059B9AD62B40FF8B3BC8F41FE419C032D8 0;255;3;0;9;Signature bad: 01E44BF99E8E4842A47D14C11B849C059B9AD62B40FF8B3B 0;255;3;0;9;Signature verification failed! 0;255;3;0;9;verify fail 0;255;3;0;9;Skipping security for command 3 type 16 0;255;3;0;9;read: 3-3-0 s=255,c=3,t=16,pt=0,l=0,sg=0: 0;255;3;0;9;Signing backend: ATSHA204Soft 0;255;3;0;9;SHA256: B588F20DC0FFBCCE5B40563F5618901E1F46F5996A90146687AAAAAAAAAAAAAA 0;255;3;0;9;Transmittng nonce 0;255;3;0;9;Skipping security for command 3 type 17 0;255;3;0;9;send: 0-0-3-3 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:B588F20DC0FFBCCE5B40563F5618901E1F46F5996A90146687 0;255;3;0;9;Signature in message: 01C32806F6BA82E2BA08D8BC47AEAE 0;255;3;0;9;Message to process: 030056C400FFFFFFFFFFFFFFFFFF0300 0;255;3;0;9;Current nonce: B588F20DC0FFBCCE5B40563F5618901E1F46F5996A90146687AAAAAAAAAAAAAA 0;255;3;0;9;HMAC: B532A92B09B8A52F01630B4FCD29CD4C380317D14FFCEDE34284BDF61C13953D 0;255;3;0;9;Signature bad: 0132A92B09B8A52F01630B4FCD29CD 0;255;3;0;9;Signature verification failed! 0;255;3;0;9;verify failSensebender:
Starting sensor (RNONAA, 2.0.0-beta) Radio init successful. Sensebender Micro FW 1.5 - Online! Skipping security for command 3 type 16 send: 3-3-0-0 s=255,c=3,t=16,pt=0,l=0,sg=0,st=ok: Nonce requested from 0. Waiting... Timeout waiting for nonce! sign fail send: 3-3-0-0 s=255,c=3,t=11,pt=0,l=17,sg=0,st=ok:Sensebender Micro Skipping security for command 3 type 16 send: 3-3-0-0 s=255,c=3,t=16,pt=0,l=0,sg=0,st=ok: Nonce requested from 0. Waiting... Timeout waiting for nonce! sign fail send: 3-3-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=ok:1.5 Skipping security for command 3 type 16 send: 3-3-0-0 s=1,c=3,t=16,pt=0,l=0,sg=0,st=ok: Nonce requested from 0. Waiting... Timeout waiting for nonce! sign fail send: 3-3-0-0 s=1,c=0,t=6,pt=0,l=0,sg=0,st=ok: Skipping security for command 3 type 16 send: 3-3-0-0 s=2,c=3,t=16,pt=0,l=0,sg=0,st=ok: Nonce requested from 0. Waiting... Timeout waiting for nonce! sign fail send: 3-3-0-0 s=2,c=0,t=7,pt=0,l=0,sg=0,st=ok: Skipping security for command 3 type 16 send: 3-3-0-0 s=3,c=3,t=16,pt=0,l=0,sg=0,st=ok: Nonce requested from 0. Waiting... Timeout waiting for nonce! sign fail send: 3-3-0-0 s=3,c=0,t=13,pt=0,l=0,sg=0,st=ok: isMetric: 1 TempDiff :127.32 HumDiff :141.00 T: 27.32 H: 41 Skipping security for command 3 type 16 send: 3-3-0-0 s=1,c=3,t=16,pt=0,l=0,sg=0,st=ok: Nonce requested from 0. Waiting... Timeout waiting for nonce! sign fail send: 3-3-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,st=ok:27.3 Skipping security for command 3 type 16 send: 3-3-0-0 s=2,c=3,t=16,pt=0,l=0,sg=0,st=ok: Nonce requested from 0. Waiting... Timeout waiting for nonce! sign fail send: 3-3-0-0 s=2,c=1,t=1,pt=2,l=2,sg=0,st=ok:41 Skipping security for command 3 type 16 send: 3-3-0-0 s=3,c=3,t=16,pt=0,l=0,sg=0,st=ok: Nonce requested from 0. Waiting... Timeout waiting for nonce! sign fail send: 3-3-0-0 s=3,c=1,t=38,pt=7,l=5,sg=0,st=ok:3.20 Skipping security for command 3 type 16 send: 3-3-0-0 s=255,c=3,t=16,pt=0,l=0,sg=0,st=ok: Nonce requested from 0. Waiting... Message to send could not be signed! sign fail send: 3-3-0-0 s=255,c=3,t=0,pt=1,l=1,sg=0,st=ok:92 OTA FW update enabled Signing required Skipping security for command 3 type 15 send: 3-3-0-0 s=255,c=3,t=15,pt=0,l=2,sg=0,st=ok: Waiting for GW to send signing preferences... Skipping security for command 3 type 15 read: 0-0-3 s=255,c=3,t=15,pt=0,l=2,sg=0: Mark node 0 as one that require signed messages Mark node 0 as one that do not require whitelisting Skipping security for command 3 type 16 send: 3-3-0-0 s=255,c=3,t=16,pt=0,l=0,sg=0,st=ok: Nonce requested from 0. Waiting... Skipping security for command 3 type 17 read: 0-0-3 s=255,c=3,t=17,pt=6,l=25,sg=0:AC862B6EC2DC2CD7EEF32DD146F7D57DA738137D592460D5E5 Nonce received from 0. Proceeding with signing... Signing backend: ATSHA204 Message to process: 0300560011FF322E302E302D62657461 Current nonce: AC862B6EC2DC2CD7EEF32DD146F7D57DA738137D592460D5E5AAAAAAAAAAAAAA HMAC: 65C59C709F8B194B4005D830F86D1F502C0707090C131C5A15356A26C3D72C8E Signature in message: 01C59C709F8B194B4005D830F86D1F Message signed Message to send has been signed send: 3-3-0-0 s=255,c=0,t=17,pt=0,l=10,sg=1,st=ok:2.0.0-beta Skipping security for command 3 type 16 send: 3-3-0-0 s=255,c=3,t=16,pt=0,l=0,sg=0,st=ok: Nonce requested from 0. Waiting... Skipping security for command 3 type 17 read: 0-0-3 s=255,c=3,t=17,pt=6,l=25,sg=0:99C1B06E9EA6E561D7089ECA5AECAD47247C3966848FDA3669 Nonce received from 0. Proceeding with signing... Signing backend: ATSHA204 Message to process: 03000E2306FF00 Current nonce: 99C1B06E9EA6E561D7089ECA5AECAD47247C3966848FDA3669AAAAAAAAAAAAAA HMAC: 357966889DA8D9414C49B4AF9AACEDF786D05722F50DEE43CE05559514938EB7 Signature in message: 017966889DA8D9414C49B4AF9AACEDF786D05722F50DEE43 Message signed Message to send has been signed send: 3-3-0-0 s=255,c=3,t=6,pt=1,l=1,sg=1,st=ok:0 Skipping security for command 3 type 16 send: 3-3-0-0 s=255,c=3,t=16,pt=0,l=0,sg=0,st=ok: Nonce requested from 0. Waiting... Skipping security for command 3 type 17 read: 0-0-3 s=255,c=3,t=17,pt=6,l=25,sg=0:A45F00D4D8F06B269F8D09928663D2088313BF36C2DCCC78B6 Nonce received from 0. Proceeding with signing... Signing backend: ATSHA204 Message to process: 030056C400FFFFFFFFFFFFFFFFFF0300 Current nonce: A45F00D4D8F06B269F8D09928663D2088313BF36C2DCCC78B6AAAAAAAAAAAAAA HMAC: 3A6645A45367626C11E5FCA20C19B6430DD840300ED79CB7B25097B5FED0897D Signature in message: 016645A45367626C11E5FCA20C19B6 Message signed Message to send has been signed send: 3-3-0-0 s=255,c=4,t=0,pt=6,l=10,sg=1,st=ok:FFFFFFFFFFFFFFFF0300 Init complete, id=3, parent=0, distance=1 TempDiff :0.12 HumDiff :0.50 TempDiff :0.00 HumDiff :0.50 TempDiff :0.00 HumDiff :0.00There is a lot of "Nonce requested from 0. Waiting..."messages
-
@alexsh1
I am afraid I have to repeat what I have also said to other on the forum having problems with signing;
you do not have problems with signing, you have problems with radio (st=fail). As long as you have st=fail, signing will not work reliably. It will not be less secure, but it will not let messages through.It is easy to suspect singing, because it might very well work better with signing off, but the reason for this is that signing uses the entire maximum message payload, and this makes it "harder" for the radio to send all the bits correctly, thus increasing the chances of a st=fail in case the link is not reliable.
-
@Anticimex I agree with you, but I find it interesting that sending a message fails exactly 9 times every time the node starts. I have changed different nrf24l01+ modules, put the transceivers close / far - it made absolutely no influence at all. 9 times st=fail and then everything works as expected.
-
@alexsh1 yes, it seem an odd coincidence. But I see nothing that signing can do about it I am afraid. st=fail means a message was not confirmed to get delivered properly and signing can't handle message drops. For security reasons, I have decided to not support retransmissions of nonces. If it can't be delivered, the entire signing session is considered compromised and have to be restarted with the exchange of a new nonce.
-
@Anticimex said:
@alexsh1 yes, it seem an odd coincidence.
It is even more interesting that I have zero st=fail after nonce is received .
I can probably change the GW settings and the channel to make sure this is not causing any issues, but 9 st=fail in the beginning every time is a strange coincidence.@ximinez Did you manage to get it sorted? How many st=fail do you have in the beginning?
Anyone else is having similar issues?
-
@alexsh1 Perhaps a long stabilization time for a power supply or clock on the node or gw cause it. You could try to add some delays and see if it is time-after-power-on that is the issue or whatever it might be. It is not signing in any case, because it is the node sending that reports st=fail. That is a rf issue. It always is. The nonce has been generated as it should, and the signing backend trusts the transport layer to handle the transmission of the databuffer, and in this case the transport layer reports back that it could not.
-
@Anticimex Just an idea - could it be that nonce is not generated in the beginning and requires some time? I'll do some testing tonight
-
@alexsh1 No, nonces are being generated:
0;255;3;0;9;SHA256: 86DEAE1DAF50D577A4E2262B33ABF9DEE05DD8FAF84F94F50900000000000000 0;255;3;0;9;Transmittng nonce 0;255;3;0;9;Skipping security for command 3 type 17 0;255;3;0;9;send: 0-0-3-3 s=255,c=3,t=17,pt=6,l=25,sg=0,st=fail:86DEAE1DAF50D577A4E2262B33ABF9DEE05DD8FAF84F94F509and the generated nonce is not transmitted correctly (st=fail) due to some transport issue.
-
@Anticimex said:
@alexsh1 No, nonces are being generated:
Than I am out of guesses - I cannot explain why st=fail comes up.
FYG, I tried it without signing and it works just fine. No st=fail.
There must be something between signing and transportation or transportation after signing?
-
@alexsh1 like I said, signing is not in itself the problem. The problem is that big messages are failing. You can just try by generating big messages yourself and you will get the same problem. I know this by looking on what generates st=fail and it is the transport layer. Signing generates the data to be transmitted, and this data is printed and shown to be correct. Bigger messages require more reliable communications. Shorter messages has a better chance of being transmitted correctly. It is that simple. Many have reported the sake issue and have solved it by improving radio power decoupling, rearranging the sensor placement or improve the power supplies.
-
@Anticimex said:
Many have reported the sake issue and have solved it by improving radio power decoupling, rearranging the sensor placement or improve the power supplies.I tried
-
powering GW/Sensobender from a different source (battery, USB, PSU - 12V in case of GW, 5v in case of sensebender via LDO)
-
swapped a few radios. Most of these are from working nodes with caps soldered. Maybe I should try completely different ones from a different batch? I mixed up three batches with no improvement.
-
Tried to place GW and the sensebender 1m/5m/10m apart
-
GW radio is powered via the AMS1117 3.3v
So far it is the same result. Not sure I can come up with anything obvious unless you can suggest
-
-
@alexsh1 sorry, I have not much else to suggest except experimenting with delays to see if the issue with failed transmissions at node startup can be avoided. I am no specialist on the radio. I'm the security guy and I see no wrong with the behaviour of those parts so I am short of any more useful suggestions I am afraid.
-
When did you last update the library (on the gw)? @Yveaux recently added a irq-based de-queuing from the radios FIFO. It could help on improving things.
Otherwise the only advice I have is to skip any amplified radio on gateway (if you have) and tweak powering of radio power on gw.
-
@Anticimex Well, at least we are fine on the security part
I'll experiment more on the radio part when I have time - why there are only 24h in a day? (rhetorical question)
-
@hek said:
When did you last update the library (on the gw)? @Yveaux recently added a irq-based de-queuing from the radios FIFO. It could help on improving things.
Otherwise the only advice I have is to skip any amplified radio on gateway (if you have) and tweak powering of radio power on gw.
@hek
I downloaded the dev on 26/05 so it is very recent.
I have normal radios both ends, but the idea is to have amplified one on the GW as well and change rf24_pa_max. Additionally, I'll try to mix as many radios as I can have. Who knows?To be honest, things were working OKish before as I took it seriously decoupling radios etc. This voodoo dance around radios really irritates me. Life is too short to waist it - I am now thinking seriously switching to RMF69W or probably to RFM95* (Lora)
-
@alexsh1 yesh i have bashed my head on rf24 stability myself and have decided to base my network on rfm69:s instead. Too much chatter @2.4ghz. I hope the 69:s have better range and they also have the bonus of AES encryption in hw if you want to obfuscate the communication some. Signing adds netter security, but the paranoid can combine signing with encryption
(yes rf24 can use AES encryption in software, but that cost memory and some overhead instead)
-
Whatever I did, did not help to solve st=fail
When I disable signing I have got the following (not a signle st=fail):
Starting sensor (RNONA-, 2.0.0-beta) Radio init successful. Sensebender Micro FW 1.5 - Online! send: 3-3-0-0 s=255,c=3,t=11,pt=0,l=17,sg=0,st=ok:Sensebender Micro send: 3-3-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=ok:1.5 send: 3-3-0-0 s=1,c=0,t=6,pt=0,l=0,sg=0,st=ok: send: 3-3-0-0 s=2,c=0,t=7,pt=0,l=0,sg=0,st=ok: send: 3-3-0-0 s=3,c=0,t=13,pt=0,l=0,sg=0,st=ok: isMetric: 1 TempDiff :125.61 HumDiff :150.00 T: 25.61 H: 50 send: 3-3-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,st=ok:25.6 send: 3-3-0-0 s=2,c=1,t=1,pt=2,l=2,sg=0,st=ok:50 send: 3-3-0-0 s=3,c=1,t=38,pt=7,l=5,sg=0,st=ok:3.09 send: 3-3-0-0 s=255,c=3,t=0,pt=1,l=1,sg=0,st=ok:85I am going to try different channels now with signing
-
@alexsh1 yes, without signing your messages are significantly shorter, and thus have a better chance of getting through. You can try experimenting with amplification as well.
-
@Anticimex just a noob question: do you have an idea of the performance penalty of (software) signing? Any benchmark figures?
-
@Yveaux no, sorry have not got around to compare them. But software signing is actually quicker due to the single write bit banging for the atsha204a. One way to see the difference is measuring the delay for an ACK to come back from a node that require signed messages. I have no figures, but a node with software signing responds slightly faster.
-
@Anticimex But is it significantly slower than without any signing?
-
@Yveaux yes. But I know that significant improvements can be made in the nonce whitening. It incrementally calculates a hash which is which is far less efficient than calculate the hash of a buffer. So there are room for improvements. I just wish there were more time, and now my arduinos are packed down so I wont be able to test. But volunteers are welcome, I can still code
-
@Anticimex said:
@alexsh1 yes, without signing your messages are significantly shorter, and thus have a better chance of getting through. You can try experimenting with amplification as well.
Do you think a message size has anything to do with st=fail?
-
@alexsh1 yes, like I have said here and in other topics, signing often gets the blame for transmission problems because with signing the maximum message buffer is used, and larger messages are more difficult to transmit than short ones. So if you have a poor connection, odds are that a larger message will fail more often than a short one.
-
@Anticimex said:
@alexsh1 yes, like I have said here and in other topics, signing often gets the blame for transmission problems because with signing the maximum message buffer is used, and larger messages are more difficult to transmit than short ones. So if you have a poor connection, odds are that a larger message will fail more often than a short one.
I do not think its signing, but I think it is implementation of signing and sending.
I do not get st=fail after the initial 9 messages not even once. Something is just very-very odd.
-
I'm seeing the same failed signings when the device powers up, but it doesn't fail after those.
-
@ximinez said:
I'm seeing the same failed signings when the device powers up, but it doesn't fail after those.
Did you manage to get it sorted?
-
I just ignore the first fails. It works after that, and has done so for close to a month.
-
Well, if you think the signing implementation cause initial radio transmissions to fail I am afraid I will need your help in explaining how. Because I fail to see any connection between signing and radio behaviour. st=fail is a transmission problem, and signing implementation require flawless transmissions. I also suspect you both use nrf24 and I also suspect you will not see this if you use rfm69 although I use nrf24 myself for testing and I have not seen what you report. But I am sure you really experience this strange behaviour. But I maintain that it is due to some startup problems of the radio. I am afraid I cannot find anything I can change in the signing codebase to have an influence on st=ok or st=fail. But I am all ears to suggestions of course if you see something suspicious.
-
@Anticimex Interesting observation - another node with the same rf24l01+ radio from the sensebender with the same GW and signing works without st=fail. This is now clear that this is not a rf24l01+ hardware issue.
-
@alexsh1 Indeed. And also that it is not a signing issue since I take it you use the same FW?
I still think it is a HW issue. You have a new node, right? So the radio has a new power source?
-
@Anticimex said:
@alexsh1 Indeed. And also that it is not a signing issue since I take it you use the same FW?
I still think it is a HW issue. You have a new node, right? So the radio has a new power source?Yes, I tried to compare apples with apples:
- it is the same distance / FW
- the code is different to the expend that the sensebender has got Si7021/ATSHA204a and the other sensor did not. I may try to upload a simplified code to the sensebender just to test it to make it a more equal comparison.
- the power source is the same - 5V 500mA via AMS1117 + cap
-
@alexsh1 You could also try soft signing on the sensebender and see if that makes a difference. Perhaps the atsha device interferes with the radio (this depends on routing and such things). I have no sensebender myself and I have not noticed the behavior you describe with nrf24 and atsha204a.
