Posts made by ximinez

@hek said:

@ximinez

You can add a before()-method.

It's that easy? I'll give it a try when I get around to it, unless @alexsh1 feels like trying it first

Is there a "pre setup" available yet? The failed transmits are before sensor values are transmitted, so they aren't in the actual sketch but somewhere in the library. I'd like to try just sleeping the sensor 5-10 seconds before the initial data is transmitted and see if that makes a difference.

I just ignore the first fails. It works after that, and has done so for close to a month.

I'm seeing the same failed signings when the device powers up, but it doesn't fail after those.

@FotoFieber said:

@Anticimex said:

@FotoFieber with a SenseBender, there is no reason for soft signing. It should have a ATSHA204A chip. But nice that you have working setup

Yes, but encryption and ATSHA204A is to big for the SenseBender...

Old thread, but... In the dev branch, there's a RF24 refactor that is much smaller. With that, and removing test-mode, there's plenty of space on the sensebender:

#define MY_RADIO_NRF24
#define MY_SIGNING_ATSHA204
#define MY_SIGNING_REQUEST_SIGNATURES
#define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {0xBO,0xGU,0xSK,0xEY,0xZZ,0xFC,0xAD,0x04,0xD1}}}
#define MY_OTA_FIRMWARE_FEATURE
#define MY_RF24_ENABLE_ENCRYPTION

Sketch uses 23,196 bytes (75%) of program storage space. Maximum is 30,720 bytes.
Global variables use 1,386 bytes (67%) of dynamic memory, leaving 662 bytes for local variables. Maximum is 2,048 bytes.

Even with debug it's only at 91%.

My W5100 gateway ends up at 107% with AES though, but it fits (with 592 bytes to spare) if I use a static address instead of DHCP.
Serial Gateway ends up at only 65%.

Both soft and hard SPI work on my cheap W5100 clone shield (with SD).

@tekka said:

@ximinez Just tested your setup/settings using an Arduino UNO + W5100 shield and I can confirm, that SOFTSPI (A2=MISO, A1=MOSI, A0=SCK, D6=CSN, D5=CE) and HWSPI (D12=MISO, D11=MOSI, D13=SCK, D6=CSN, D5=CE + #define MY_W5100_SPI_EN 4) work with the refactored RF24 driver.

Please double check you are using the most recent MySensors 2.0.0-beta lib and GatewayW5100 sketch.

I just did (for the second time), and lo and behold it works. Absolutely no clue why, but I'm sorry I've wasted your time.

My gateway can finally have DHCP and signing at the same time

#define MY_DEBUG
#define MY_RADIO_NRF24
#define MY_DEBUG_VERBOSE_RF24
#define MY_GATEWAY_W5100
#define MY_SIGNING_SOFT
#define MY_SIGNING_REQUEST_SIGNATURES
#define MY_RF24_CE_PIN 5
#define MY_RF24_CS_PIN 6

Using an UNO with an ethernet shield, wired up like this: https://www.mysensors.org/build/ethernet_gateway
A2 MISO
A1 MOSI
A0 SCK
6 CSN
5 CE

Yes. When I say that I haven't changed the pins, I mean that I haven't changed the physical pins (or the CE/CSN numbers in my sketch) compared to when the same setup worked with the previous RF24 driver.

I love the difference in available space the new driver gives, but I'd love it even more if the radio continued to work

I updated to dev branch yesterday, and on my W5100 gateway the radio now fails to initialize:

0;255;3;0;9;Starting gateway (RNNGA-, 2.0.0-beta)
0;255;3;0;9;write register, reg=0, value=6
0;255;3;0;9;write register, reg=3, value=3
0;255;3;0;9;write register, reg=4, value=95
0;255;3;0;9;write register, reg=5, value=76
0;255;3;0;9;write register, reg=6, value=35
0;255;3;0;9;read register, reg=6, value=255
0;255;3;0;9;read register, reg=6, value=255
0;255;3;0;9;Sanity check failed: RF_SETUP register=255 instead of 35, check wiring, replace module or non-P version
0;255;3;0;9;Radio init failed. Check wiring.

I've tried three different (confirmed working on my sensebender micro) radios, I've quadruple-checked my wiring, and I haven't changed the pins. So something is funky after the RF24 refactor.

@tbowmo said:

@ximinez

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.

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.

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?)

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

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?

@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.

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

@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

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.

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.

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]

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.

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

@Anticimex Yeah, that's what I asked

I get:
Writing key to slot 0...
Data lock failed. Response: D3

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?

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?

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

Pretty sure.
I'll wipe my library dir and redownload master.

Fails with the same errors on Uno for me.

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 scope

I'm trying to compile this against master however. Do I have to have dev branch to compile that sketch?

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.

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)

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ìåä!

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

@Anticimex Ah, yes. sed /your/@tbowmo's/g. I blame lack of caffeine.

@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.

@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.

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.

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?