Minimal design thoughts
-
@tbowmo
Yes, that would be the most reliable option to allow updates un normal running mode.I discussed this with @Anticimex earlier today and how to combine it with signing without totally flood the network with nonce requests etc.
Neither of us have the flash memory though ;)
-
if we are going to use the external flash for OTA, then it should be included in the library? So the libraray handles the OTA packets, putting data into the external flash etc.
@tbowmo Yep. The way I understand how things work, I suggest the following:
Library initiates OTA transfer stream and transmit all FW for storage in external flash. Both sender and transmitter calculates some checksum of the FW and the checksum is sent finally, as a separate command.
The stream data is sent with a special command that bypasses signature. The checksum is sent with a type that is included with other signed types (currently only the singing handshake commands are excluded from signing).
That way, if receiver require it, FOTA will also be signed since the checksum packet is signed.
If the receiver accepts the signature (and the checksum is valid) receiver writes the bootloader specific indicators and restarts, so bootloader can transfer the received firmware to PROGMEM, and "Bob's your uncle". Secure FOTA to your difficult-to-reach node somewhere in the house :) -
@tbowmo
Yes, that would be the most reliable option to allow updates un normal running mode.I discussed this with @Anticimex earlier today and how to combine it with signing without totally flood the network with nonce requests etc.
Neither of us have the flash memory though ;)
-
@tbowmo
Yes, that would be the most reliable option to allow updates un normal running mode.I discussed this with @Anticimex earlier today and how to combine it with signing without totally flood the network with nonce requests etc.
Neither of us have the flash memory though ;)
-
@tbowmo you can sign me up too however I can handle the component side of it if you share the mouser BOM.
@blacey said:
@tbowmo you can sign me up too however I can handle the component side of it if you share the mouser BOM.
The BOM should be available at
http://www.mouser.com/ProjectManager/ProjectDetail.aspx?AccessID=a509f9ca59It should match the current PCB layout for the major number of parts. I haven't looked at the crystal yet, to see if that fits, as I have changed the footprint to the one provided by the manufacturer in china when going with rev. 2.
At the moment I'm considering if the crystal should be dropped from the BOM, kind of missing a real purpose for it at the moment, as I don't think that "precise timing" is necessary for a node that repports in at a regular interval.. I (for one) don't care if it reports temperature / humidity "exactly" every 60 seconds, or if it's every 55 or 65 seconds.. But others might have another priority?
Schematics / PCB layout is available on github : https://github.com/tbowmo/MySensorMicro (please double check BOM from mouser, and the eagle files. I might have missed something :))
-
@blacey said:
@tbowmo you can sign me up too however I can handle the component side of it if you share the mouser BOM.
The BOM should be available at
http://www.mouser.com/ProjectManager/ProjectDetail.aspx?AccessID=a509f9ca59It should match the current PCB layout for the major number of parts. I haven't looked at the crystal yet, to see if that fits, as I have changed the footprint to the one provided by the manufacturer in china when going with rev. 2.
At the moment I'm considering if the crystal should be dropped from the BOM, kind of missing a real purpose for it at the moment, as I don't think that "precise timing" is necessary for a node that repports in at a regular interval.. I (for one) don't care if it reports temperature / humidity "exactly" every 60 seconds, or if it's every 55 or 65 seconds.. But others might have another priority?
Schematics / PCB layout is available on github : https://github.com/tbowmo/MySensorMicro (please double check BOM from mouser, and the eagle files. I might have missed something :))
-
So, a small update on the rev.2 board status.
I am verifying the rest of the board now, before we kick of an initial testrun of 5 boards at the manufacturer. Everything seems to be working, electrically..
Unfortunately something has happened in the SPI library in arduino, so the external flash, is now crashing the arduino sketch, while initializing. Someone else has already reported it to lowpowerlabs github repo https://github.com/LowPowerLab/SPIFlash/issues/8
Having had the above issues, I have already build, and disassembled two nodes, trying to debug things :s
Oh the fun of debugging embedded things...
update
I found a solution, someone else had made the necessary changes to lowpowerlabs spiflash library (check the issue comments in the link above)
I also read in the release notes for arduino 1.6.0, that they have changed the SPI library to support transactions. Will this have any effect on MySensors? (@hek, any comments?)
-
@tbowmo : if the connections are fine when can we expect he board for production ?? looks everything is fine
-
We are getting closer to a launch. A production partner has been found. All on-board hardware have been verified as OK! And I'm verifying the last bits (Want to have a complete node running, before giving a GO..) Also finishing the software that should be preloaded on the atmega.
Depending on how things are going, we should be able to make the first trial batch within the next couple of weeks (I hope!) which we then need to verify before starting the big machine.
Going to be an exiting spring this year :)
-
To where will you be able to ship the nodes ? I live in France. I don't know where you are located...
-
A case already was on my short-list and we could very well provide it.
Depending on demand it could be 3d-printed or for larger quantities done with mold injection by our partner.
But I would really need some help from a (talented) 3d modeller for this. Do we have anyone here that can help out?
The box must have a battery compartment for 2XAA. A big question is if it also should have space for an extra sensor?
Would be great if we could provide a couple of cover-options for things like motion (HC-SR501) and another for light/uv/ir sensor. Hope we can get creative together here. -
A small update from the workbench here :)
The first rev.2 node is transmitting like it has never done anything else right now.
Next up is programming the bootloader, I am having some troubles in that area.. It seems that it is programmed, but I can't get it to accept any downloads from the arduino IDE.
Anyone got any hints for me to follow?
-
A small update from the workbench here :)
The first rev.2 node is transmitting like it has never done anything else right now.
Next up is programming the bootloader, I am having some troubles in that area.. It seems that it is programmed, but I can't get it to accept any downloads from the arduino IDE.
Anyone got any hints for me to follow?
-
I have checked, and double checked fuses :) I'm using avrdude to program the bootloader directly, and it seems that it is starting up (the LED is lighting up as it is supposed to). Also when I program a sketch via ISP (using jtagice3) serial is working fine, so it seems that fuse settings is right for oscillator (at least)
But I might have missed something with the fuse settings.
I get these fuses
AVRDUDE -U lfuse:w:0xE2:m -U hfuse:w:0xDA:m -U efuse:w:0xFE:m -U lock:w:0xFF:mfrom http://eleccelerator.com/fusecalc/fusecalc.php?chip=atmega328p&LOW=E2&HIGH=DA&EXTENDED=FE&LOCKBIT=FF
-
I have checked, and double checked fuses :) I'm using avrdude to program the bootloader directly, and it seems that it is starting up (the LED is lighting up as it is supposed to). Also when I program a sketch via ISP (using jtagice3) serial is working fine, so it seems that fuse settings is right for oscillator (at least)
But I might have missed something with the fuse settings.
I get these fuses
AVRDUDE -U lfuse:w:0xE2:m -U hfuse:w:0xDA:m -U efuse:w:0xFE:m -U lock:w:0xFF:mfrom http://eleccelerator.com/fusecalc/fusecalc.php?chip=atmega328p&LOW=E2&HIGH=DA&EXTENDED=FE&LOCKBIT=FF
@tbowmo I am just taking wild guesses and the one thing that came to my mind if you seem to have bootloader running but cannot download is that the serial line is out of sync for some reason. But I have not dissected the arduino bootloader or the protocol so I am in deep murky waters making assumptions now :)
