I was able to disable the nrf autoack feature; it is strange why I have to enable autoack prior to disabling it….but it looks like these modules like it this way ;) I’ve noticed a weak soldering in the sensor device - i’ve tried to fix it (without soldering) ; it went well enough to finish the current measurement for sizing the fuse; but its another minor showstopper ;) Next day or so I’ve added a diode and a 200mA polyfuse to the led driver board; to create some protecton for these circuits.
Lately i’ve finished the ota related software components…its still ugly; but at least it now uploads & swaps the new firmware with a success rate of around ~90%…sometimes the mega messes something up; and avrdude timeouts…but its fine for me for now at least. There were a very strange problem…sometimes the otad behaved strangely or just seemingly lost contact with the mega….it took for me a while to realize that i might be facing some memory issues; fixing all valgrind errors and warnings uncovered that i’ve forgot to initialize a buffer offset variable…I should definetly turn on -Werror and its friends… I will record a video about it - to show how cool it is to have all these devices accessible from eclipsearduino thru the ota infrastructure ;) Having almost everything ready for preliminary deployment…i went forward to add the base functionalities for the devices; cleaned up some apis a bit - and fixed issues which almost entirely prohibited normal operations - i’ve made a choice of duplicating the some parts of the rx/tx channel methods…this decision have kicked back a few times already..
I’ve already evaluated what i would really need to protect my comms from 3rd parties; but i still miss the stream alike controllers on both ends to maintain the channels between the devices. remote writing (arduino – arduino) With the local self writing capability ready for use, i started adding some sequence based retrasmission capable stuff (i wasnt sure where i will end up with it eventually)… After creating the prototype for a single one directional channel I was surprised that the encryption part will just fit into the playfield by adding it behind the seq handler later on.
Earlier i’ve found the optiboot project, which looked like a great candidate to reshape into the key instrument to enable remote firmware upgrades for the pro minis. The idea is to have the flash split logicaally in two: first section running the current firmware second section is reserved for the new firmware The bootloader is the only “trusted” part of the flash from within flash write commands are accepted. So: i will add an upgrade service to the bootloader to provide the flash programming feature to the main application.
Moving the existing breadboard application to a soldered one was easier than before…the hardest was to find a suitable timeframe when I can start working on it. drilling holes I’ve ordered a small box earlier(and was hanging around without any purpose); because I don’t really had strict size contrains or ergonomical requirements for it - I decided to use it. I decided to use 3 dc jacks to connect: the upstream ac/dc converter the other arduinos power the controlled led strip I’ve ordered some pcb mountable plugs..
During the last week I was able to build the breadboard version of the kitchen2 device. Learning from my previous problems with just partially prototyping the circuit. I’ve built it fully …i’ve connected the “production” power supply to it and the ledstrip too. The led strip is dimmed by a fet…because this was new for me I’ve consulted with some experts on the arduino irc channel about what i want to build and they have taught me the simplest cases of using Fets: Fet is under pwm control?
I’ve been struggling with it for days now…maybe if I write it down, it gets a clearer picture for me too ;) So…I will have multiple devices with the ability to communicate to each-other via radio. Possible challenges/problems: the system itself should be able to withstand partial crash of the infrastructure…so in case of catastrophic failure; all functioning parts should sustain their function as much as possible. this means that the control logic will be distributed and the nodes should behave in a mesh network like manner it might be possible that the RF24 modules would need multiple hops to reach the target this might not be the case, I will check this fact later - having a real mesh network is cool, but in case I dont need it at all… unauthorized 3rdparties should not interfere with the operation of the system communication protocol must be resilient to replay attacks I can’t do anything to prevent an adversary to flood the radio channels with noise… the nrf’s design is very limited…1 channel out; 5 channel in.
Creating the box After fixing the power related issue I encountered…I designed a box for the device; which could be 3d printed. I’ve started working with some nightly FreeCad version (v0.16) - I ended up using a the nightly version because I encountered some issue with its spreadsheet usage - I worked a lot to be able to enter all my data thru the spreadsheet page. So later I can come back, and this way I don’t have to be absolutely right at the first time - just change the parameter and I’m done - at least that’s the idea…FreeCad is designed for heavy use of constraint based modelling - it takes a lot of effort do design things in it.
I’ve ordered a bunch of capacitators and other gadets…to fix the problem. After my order arrived…i’ve moved the stepdown module to a prototyping board; and wired it up from there. I wanted the check that the problem still exists: so i didn’t added any capacitator…and for my biggest surprise: it worked. I thinked that: because of the different conditions…longer cabels…the noise is not that close to the other parts. I added the capacitators to the proto board…that went well to… I soldered 100uF capacitators under the stepdown…I was happy that I have enough space to put them in…I added one for the input and one for the output..just in case.
Last week all needed parts arrived to start with the assembly of the first member of my home automation infrastructure. This will be the kitchen sensor - i picked this because it involves many sensors and no control. Imagined operation If i walk into the kitchen…it should be aware of my presence; if the light condition are too dim - the two lamps should turn on…to supplement lighting to the specified level.