Minimal design thoughts
-
But you would still need to set the keys...
@hek Well, not really. If you like, you can FOTA down the personalizer with your PSK and execute it by remote on a "virgin" unit Then FOTA down your application FW. It is only when your application tells the GW that it require signing, signing actually kicks in.
-
Yes, I have a bootloader, that copies external flash, to internal. It's also verified as working, with a local firmware update where I downloaded a sketch to the micro, which put another sketch into the external flash, so no OTA in the verification phase. I used DualOptiboot from lowpowerlabs (There is a copy on my github account.)
The bootloader looks for a signature in the first couple of bytes of the external flash, if present it copies data and erases the external flash.
I just don't know what direction things are going at the moment, as there also exists the standard MySensors bootloader. If we use dualoptiboot, we need to have FOTA code in the default application that is loaded into the device, before shipment from china.
-
@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?
