Minimal design thoughts
-
@Anticimex , did you have any spare atsha204 left?
-
@tbowmo Have you looked on AliExpress. A quick search seems to suggest that could be a viable alternative. Try some different search combinations though ... their search engine sucks. "ATSHA204" wont find "ATSHA204A" for instance when I try.
Wont be quick though, and the Chinese New Year is coming up ...
-
I can part with a SOT23 ATSHA204A if necessary. They can also be sampled from Atmel in small quantities for free (that's what I did).
-
-
@hek It took three days from order confirmation to shipment notification. I don't recall the transit times but it went out with DHL WW Express so it should be pretty fast. Say 5-10 working days tops.
-
@Anticimex said:
@hek It took three days from order confirmation to shipment notification. I don't recall the transit times but it went out with DHL WW Express so it should be pretty fast. Say 5-10 working days
hmm what is the sample quantity limit?
-
@tbowmo I don't remember. But I got at least three (don't think I requested more since at the time I was not sure it would meet my personal demands, nor if the MySensors community would accept it). Since it is now kind of "official" I guess it has
-
@Anticimex said:
@tbowmo I don't remember. But I got at least three (don't think I requested more since at the time I was not sure it would meet my personal demands, nor if the MySensors community would accept it). Since it is now kind of "official" I guess it has
ok, I'll try and get some samples then.
Has there been any work done to support easy initialization of the keys on new devices?
-
@tbowmo That's already done. Available in development branch. I will update it to support devices without UART in the near future. Check libraries/sha204/examples/sha204_personalizer
Auto-generation of keys is supported as well as manually contributed ones (all devices in the same environment needs to share a key). All necessary personalization for MySensors usage is done (default settings are fine) and locking of both configuration and data sections are suppored (only configuration section is mandatory to lock).
-
It's wit a separate sketch, right? Can we do anything in the protocol for key initialization? So when a device asks for a node Id it could also get the shared key supplied via radio?
I am thinking about creating a plug and play ready unit, with a preloaded sensor sketch from the factory in China, would be nice if people had an easy method of initializing things without reloading other sketches
-
@tbowmo short answer: no. Sending the key in clear text is out of the question. That is totally not secure. The whole idea with that circuit is that the key is prestored and hidden. Technically it is possible but then one also has to work around the payload size limitation in the rf protocol.
-
I know that there are some gotcha's with cleartext key transfer.. But I thought thata if output power is set to lowest value in the GW, and key transfers only could be done while in discovery mode. Then the risk of anyone snooping it, is lower..
Going into "easy initialize thinking mode" :d
-
@tbowmo I do understand what you seek. However.
- If we do accept the added cost in memory use and component cost (and development effort) of using a strong authentication hardware, it makes no sense throwing it all away by implementing its use in an insecure way (although the common man probably won't be able to compromise it).
- I have already made one big sacrifice in allowing truncated signatures (or we would have to implement a framing protocol for sending >32 byte messages).
- I am not going to implement a signing scheme which I would be able to hack myself.
Basically, my ambition with the signing is not a "low risk" of hacking. it is a "no" risk of hacking. (with the reservation of the truncated signature as mentioned above). Signatures will be inversely proportional to the complexity of the message. Signature size = 32-7-<payload size>-1 byte. In other words, the maximum possible signature size for a 1-byte message is 23 bytes. But I do think HMAC-256 is still a bitch to hack even if a portion of it is sliced off.
Also, how do you prevent an attacker from issuing its own keys by resetting the HW in some way? And besides, all users have to program their devices for them to do anything at all. Doing the ATSHA204 personalization is a one-time effort, and adds quite little work and I see no reason why it would not be possible to do this by OTA either if one preferred to do that. The configurations and keys are permanently stored on the devie in EEPROM. So the personalization is only executed once on every security-enabled device.
I think we need to save as much space as possible so having all nodes drag around the logic to do key replacement will add a memory cost in itself. And if you take security really seriously, you do want to lock down the fused key as well. Atmel is quite fuzzy about what security can be guaranteed if the data section is not locked so I am not sure if key readout is prevented with data unlocked even if configuration forbids it. The datasheet is not clear on that.The idea is:
You deploy a gateway that has the ability to sign (and verify) messages. You personalize the ATSHA device on your gateway with some personal secret key. The personalization sketch allows you to randomize that key if desired.
You take the sketch and store the generated key in it and tucks it away. For every node you want to add, you download and execute the personalization once. And then your done with that. It will from there on be able to exchange signed messages with your gateway until you either revoke the key in the gateway (reprogram it if data is unlocked or replace it and change the key in the new device).
In my opinion, a one-time initialization is not that difficult. But perhaps my sketch is complex, I welcome feedback on that topic. I have tried to explain the expected usage in the comments in the sketch header.My personal opinion on the security matter: We do it properly or we skip it. Every user ultimately decides by them self if they want security in their sensor network. And if they do go for it, it should be trustworthy.
-
Let's continue the discussion in the security thread.
-
@hek
Yes.. forgot about that..
-
sample order is sent for the atsha204 chips.. Hope it will go through at atmel..
I could only order 3 samples in total.. But that should be enough for checking that everything is working, and for sending one off to manufacturer in China.
-
Figners crossed that the chinese dont muck it up
Let me know if you need assistance in verifying the ATSHA on the prototype. I have one hooked up to my PC for debugging purposes, prepared and confguration locked for MySensors usage.
-
My plan is to just run your test code, to verify that i can talk to the device. Just like i did with the external Flash chip.
-
@tbowmo
Alright. Just so you know, I have not adapted it for your board pinout yet. I will change my breadboard prototype accordingly and retest when I implement the non-UART support in the personalizer. I hope to be finished with that before you get your samples.
-
Hmm.. I like dirtypcbs "honest" approach to things:
Hey Thomas Mørch,
Your PCB order number xxxxx has been shipped.
If you used DHL/FEDEX/UPS a tracking number will be sent later. We hope it is provided within 48hours, but our logistics company is being painfully slow with updates and provides incorrect numbers. We fired them, and will start working directly with DHL October 1st, 2014.
-
I'm going to enjoy this ^^
-
The whole site of dirtypcbs are made up like that, trash talking their own product.. But so far the service has been ok from them. This is first time I ordered with express shipment, hopefully they'll arive later this week..
-
@tbowmo said:
dirtypcbs
Well, for a site that in their website footer prints
"No bull, just crappy PCBs"
what can possibly go wrong
-
@Anticimex said:
@tbowmo said:
dirtypcbs
Well, for a site that in their website footer prints
"No bull, just crappy PCBs"
what can possibly go wrongLOL
-
Just received the tracking number.. (so it took them 2 days to go from the factory to the shipping company :))
Anyway, now I have a tracking number, so I can keep an eye on things
-
@tbowmo Since Domoticz (home automation software) got support for MySensors i have been looking for cool sensors. I want to place a MySensor node in every room in my house with temp/humidity motion and reed contact, run directly from battery. Your board looks very promising. I only have one question. Is it possible to have two interrupts (for the motion sensor and reed contact)?
-
D2 is connected to radio socket IRQ pin.
But as it currently not used by the library you could just cut the leg on radio and connect it to whatever you want.
-
it is also possible to use PCINT interrupt on mostly any digital or even analog pin
-
What bootloader should I go for, for the prodcution run? (that is preload a bootloader into the atmega) ?
I am also thinking about preloading a default sketch as well, so it's almost plug'n'play.
(@hek, this default sketch should probably be included in the mysensors git repo, right ?)
/ Thomas
-
Yep, a default sketch would be nice that reports temp/hum. Think it should be added to examples-folder like the others.
Would be fun to test the flash as well... Haven't seen @ToSa (the bootloader developer) around here for a while. Ideally a new bootloader should be adopted and MySensors library store bootloader update messages (in flash) at normal "runtime".
-
I have been trying to get DualOptiboot from lowpowerlabs to run.. because it's able to use the external flash. It also seems like it is starting up as it flashes the LED during bootup, but it doesn't respond when I try to download via serial port using arduino. I might be blind or something, as I can't seem to figure out what the *beep' is going on
I have a sketch now, that is running on the first prototype here.. Should I make a pull request, to add it?
Btw. I have tested the external flash, by writing "random" bytes to it, and read it back again.. So I know it is working.
-
@tbowmo said:
Should I make a pull request, to add it?
Yep, do that.. And include the libraries for flash/hum/temp if needed.
-
@tbowmo which flash ic are you using?
-
It's an adesto AT25DF512C-SSHN-B. Chosen because supply range is 1.8 - 3.6V (It's a bit hard finding flash chips that cover the whole range)
-
@tbowmo
Regarding bootloader I stumbled upon this:
http://hallard.me/ulpnode-bootloader/
http://hallard.me/ulpnode-bootloader-1/
-
I don't have problems with bootloaders in general, I tried the standard arduino bootloader, and it works ok. It's just the DualOptiboot from lowpowerlab I can't get to work.. And it drives me crazy
Think I need to figure out some way of debugging the bugger, to figure out what it is doing, but it's hard to find time for it, when I only have one hour every now and then for debugging..
-
@tbowmo yup, debugging these things is a pain in the neck - I've been working on the OTA bootloader for a while (mainly optimizing size, speed and additional features). What works best for me, is using debugwire in atmel studio...but sometimes quite cryptic and not straight forward
-
Well, i have thought about that as well (Avr studio route) but then i have to start up my wimdows machine, too much work at the moment
-
Bugger.. DHL tried to deliver the package with PCB's from dirtypcbs, while I was at work today. So they only left me a note, that they couldn't deliver it. Have to wait untill monday, before they will try to deliver it again.. :s
Anyway, I now know that the boards are in DK somewhere
The other day I also have received 3 pcs of ATSHA204A (samples). so I can verify that part of the HW design.
And last but not least. I have a uCurrent waiting at the post office, that I can pick up later today.. So I can also start measuring supply currents to the device!
Hope that I'll get some time to look at that part during the weekend
-
Good news..
On a saturday evening, where nothing is on TV, but a danish pre- european song contest program, I decided that I should have a look at the bootloader (amongst other stuff)
I actually succeeded in getting the bootloader into the device, and I can reprogram using serial now. Next step is to verify that I can use the spi flash to reload the unit.
I have thought of a strategy for testing the flash for reprogramming. It involves making a very basic sketch that I could compile and put into another sketch, which writes the first one to the flash, and reboots the device, and thus reprograms itself with the first sketch :). But it's going to take a while for that to happen (if anyone have a better idea, then please let me know :))
I also have tried the uCurrent, and tried to do some measurements on current consumption. When it's a sleep, it uses arround 60uA, and while awake it's up to 22mA for 60m seconds.
-
Sweet!
-
That current draw seems a bit high.
A modified 3.3V pro mini draws ~100nA in "deep" sleep without watchdog timer (pretty much everything disabled). The nrf24l01+ draws ~900nA in power down. If you wake up the 328 using its watchdog timer (i.e. sleep != 0), then that watchdog will draw around 5uA, but it wakes up every 8 sec, so the average "extra" current consumption caused by the watchdog is closer to 6uA. According to the si7021 datasheet* it draws 60 nA standby current, and 150 uA active current.
In other words, you should see a current consumption < 10uA in sleep mode. When active, the si7021 is negligible compared to the nrf and 328's current consumption, but the total consumption for nrf and 328 should still be less than 22mA... The 60ms you see probably indicates that the nrf is not able to get a hardware ("link-level") ACK, so it retries up to 15 times. Also, disabling DEBUG in MyConfig.h will save a few extra milliseconds. You should also make sure node.send() is the last thing you do before node.sleep(), or else the NRF will countinue to draw ~13mA until sleep() or RF24::powerDown() is called.This should not be too far from the theoretical current consumption profile for your board when reading hum+temp at given INTERVAL:
(Assuming the nrf, 328 and si7021 has already been "booted")sleep(INTERVAL): ~7uA on average
awake time 2+12+10.8+8 = 32.8ms
- 328 wakeup: 3.6mA for 2ms
- si7021 conversion hum: 3.6mA + 150uA for 12ms
- si7021 conversion temp: 3.6mA + 150uA for 10.8ms
- nrf24 send: 3.6mA + 13.4mA for 8ms (assuming no message retries)What components are actually mounted on the board you tested?
The ATSHA204 should draw max 3mA active, and <150nA sleeping.
The 25aa080sn*- Write current: 3 mA maximum
- Read current: 500uA typical
- Standby current: 500 nA typical
You probably already know all this, but I thought I might mention it anyway
http://www.silabs.com/Support Documents/TechnicalDocs/Si7021.pdf
http://www.atmel.com/Images/Atmel-8740-CryptoAuth-ATSHA204-Datasheet.pdf
http://ww1.microchip.com/downloads/en/DeviceDoc/21230E.pdf
-
I haven't done anything to optimise things yet. The sketch I'm running is in the examples section on Mysensors github repro so you could have a look there.
The board is without external flash (didn't mount it on board #1 that i used last night) and without atsha204, as it's still the first prototype board. The new version should arrive tomorrow, where I can mount the atsha204.
-
WUUUHUU! What a great sunday
Just verified bootloader is working with external flash! Verified with dumping a small sketch to the external flash (By use of another sketch).
So external flash is verified as functional, for the bootloader part...
-
forgot an update last week, I received rev2 boards last monday (9/2). but was on vacation with the family (They have priority above "nerd" projects ;))
Will see if I can get a couple of pictures of the new boards when I get home from daytime job today.
And hopefully, I'll get a couple of boards mounted during this week, so I can get it verified, and we can start preparing for "production to the masses"
-
@tbowmo
Nice! I have updated the ATSHA204 personalizer to work without UART and I will try to push it to github tonight or tomorrow so you can use it to verify the ATSAHA (if you need to). I am not completly finished to release signing support to the masses yet, but things are moving along nicely and I hope to be able to do that will full documentation and HW independency by the end of the month.
-
Nice! I have updated the ATSHA204 personalizer to work without UART and I will try to push it to github tonight or tomorrow so you can use it to verify the ATSAHA (if you need to).
Is there any status messages sent to the UART, in case communication with ATSHA204 fails? Or is there any other method of indicating success/failure?
-
@tbowmo
No, I am afraid you have to have a serial debug port to get any status. My updates merely "permits" you to personalize a ATSHA without UART input (something I have added as a "are you sure, this cant be undone" precaution).
However, it is possible to check connectivity by downloading my example "secure actuator" sketch and use a gateway sketch from the same "repo". The "secure actuator" will inform the GW that it require signing, and when GW asks the actuator for a nonce, actuator will ask ATSHA for a random number. A "virgin" ATSHA will give a fixed value which is recognizable and can therefore be seen by the GW. And if pattern shows, you will know that the actuator can talk to the ATSHA. A bit cumbersome, but that can be done without any hacking using existing examples (from my personal signing haxxor-branch for the moment).
The alternative is to make your own simple read-and-transmit sketch to test of course.
-
@tbowmo said:
forgot an update last week, I received rev2 boards last monday (9/2). but was on vacation with the family (They have priority above "nerd" projects ;))
Will see if I can get a couple of pictures of the new boards when I get home from daytime job today.
And hopefully, I'll get a couple of boards mounted during this week, so I can get it verified, and we can start preparing for "production to the masses"
Say what?? I take offense to that.. I'm a geek....
Epic Rap Battle: Nerd vs. Geek – 03:44
— Rhett & Link’s Wonderhole
-
@ServiceXp
Haha! That was fun!
-
@ServiceXp
Ahh, in Denmark we don't distinguish that hard between nerds and geeks..
-
A couple of days ago I promised pictures of the new boards. Unfortunately I have been busy with some other projects :s (I hate it, when work related projects take too much of the spare time..).
Anyway, here are a couple of pictures, not the best quality, as it was a couple of quick snaps I took when I received the boards last week..
The front one is a bit blurry, sorry about that, but that is what I have at the moment..
@bjornhallberg as you can see it seems that it works quite well with adding the break tabs
-
@tbowmo Looks great! I hope my regulators turn out as nice. They should hopefully arrive next week.
Best thing about the panelizer is obviously if you mass produce different sized boards, and use 10x10 cm PCBs (that are almost half the price / square cm), not only fitting a ton of boards in one space, but beating the freeware limitation in Eagle.
-
So almost finished the first two boards of the new revision..
I changed the footprint of all the SMD capacitors, and resistors, to footprints recomended by the manufacturer we are in dialog with for the mass production. Only problem is, that it's a nightmare soldering the 0402 smd components now, because the footprints are much smaller than what was used on the first revision.
Anyway, only missing decoupling capacitors now, so I'm going to power it up, just to see if everything works like it should.
The two first is also with atsha204 mounted! Hope that everything is connected as it should be
First powerup seems to be ok. no excessive power ussage, and bootloader is successfully dumped into the first board. So it seems like a success sofar. (Even LED lights up during bootloader startup.. So that's also a success :))
Also ATSHA204 is confirmed working on the first prototype!
-
Properly done!
-
so @tbowmo when can we order em ? just waiting to get a may be around 10 to start with
-
To my best knowledge at the moment, it will be Q2 this year.
It should work, as the extra components added in rev. 2, have been verified as working (it's the atsha204 chip, for signing purposes). Everything else should be working, as I haven't altered in the schematics, so connections should be the same as the previous version.
-
@tbowmo Looking at the placement, I have a few questions regarding connectivity. With the RF-board mounted (looks like it goes in on the bottom layer), will it be possible to access the other holes?
Essentially, I wonder about the mounting possibilities. As there are no holes for screws, I am guessing the board is intended to be mated to a backplane using the IO-pins as interconnects? But will that be possible when the RF board is mounted? The programmer and FTDI-headers I suppose go up from the top layer so they are out of the way, but my concern is that the RF board will cover the IO-rows on the other side.
Or is the intention to have a board that is wire-soldered directly and RF module is mounted last? I worry a bit on maintenance then
-
main thought was that it was only going to be used with wires connected to the board (that's the way I wanted to use it). the FTDI header, was only intended for downloading software, and debug purposes.
The radio will cover the FTDI header, and the pinheader on one of the sides of the board. So you have to mount the board to another board "upside down", that is with the atmega facing down to the other board. In this case the micro sensor is sandwitched between the radio module, and the extension board.
There are tradeoffs when trying to make things as small as possible (which was my initial goal of this board).
-
@tbowmo Sure, no problems. I was just wondering about the intended usecase. I think it should be possible to mount both the programming and the FTDI header on the same side though. This leaves the RF board free to use all needed space. And direct wires to all other IO. A "ugly" approach is also to simply not solder FTDI at all. Just put the pin header in and press it against the side when programming (if bootloader exists). Same could be done for the programming header (if you want a really thin board topology).
But since batteries will create some "height" I think it should be possible to keep both headers pointing up from the AVR-side of the board. Might I suggest for future revisions a 3mm mounting hole/point up center between the nice silk screen grafitti? But perhaps it will be obscured by the RF board. It will be tricky to get the board mounted through that hole in that case if it has to be done before the board is soldered I guess. Oh well, you can't get everything
Good work on the routing. The I2C pullups must have been painful.
-
@Anticimex said:
Just put the pin header in and press it against the side when programming
This is what I do with the Pro Mini, have not had any problems yet.
-
@tbowmo what might be the cost we are talking of here for the complete assembled board ?
-
-
I don't solder any pinheaders for the serial port, just putting the pins from the ftdi module in the holes on the micro board, and then holding it in place. Done the same thing for the ISP port, but it's a bit more problematic. The last two boards that I have assembled, is with pins in the ISP port.
I expect to have a "standard" bootloader in the boards (Together with a standard sketch for reading / reporting sensor values), when we receive them from China, so the ISP port is not necessary for the average user. only serial port for reprogramming (if not going for OTA).
But it might be an option for a future module, to have better access to the headers. Also might go with the nrf24 smd modules. But that's another project at the moment
-
btw. the only painfull thing about the current layout, is handsoldering it
it's a nightmare.. Almost regret that I used the new footprints for resistors / capacitors, as it makes things a lot more difficult.
-
@tbowmo Sure. But after a chat with @hek I believe you have dabbled with a bootloader that can flash in new FW from the external SPI flash. This is to me very interesting because that means we can deploy FW updates OTA using the MySensor library to flash the external flash, write some EEPROM byte to inform bootloader that new firmware is available, reboot to have the FW transferred by the bootloader and then boot the new FW. And this in turn means that we can transfer the new firmware signed, therefore support signed FOTA and THAT is very much interesting to me
So for me, the ideal would be that the board was preflashed with that bootloader (patched to be triggered by MySensors logic if necessary). Then there would be no requirement to have any extra headers, as you can push whatever you want, and signing can be implemented without actually changing the bootloader (headers will probably be needed during development, but that could just as well be done on breadboard).
-
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.
-
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
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 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
-
@hek said:
Neither of us have the flash memory though
Hmm we should do something about that at som point in time
I could send you a couple of bare boards, you could practice your soldering skils on ?
-
@hek said:
Neither of us have the flash memory though
Maybe we could figure something out.. I could send a couple of empty rev. 2 boards, and you could practice your soldering skills and assemble one yourself
-
That might be a good idea. Just hope I won't mess it up too much. Which components do I have to order in the meantime.
-
I have a BOM at mouser, but need to double check it.. (Also, might have some of the capacitors/resistors in my "private" stock, so you don't need to order them)
-
@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 :))
-
@tbowmo Awesome! I'm on it
-
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...
-
It will be shipped directly from the producer to any location.
-
@hek Thank you for your reply. I'm going to deploy may be like 5/6 nodes. Another question, By any chance, did you think about a case which accept module+battery ?
-
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?
-
@tbowmo have you checked that the fuse configuration matches the HW with respect to frequencies and such?
-
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
-
Yeah, but it's hard to debug things in the bootloader.
-
@tbowmo Tell me about it. It's what I do for a living
You don't have means to pick up the serial line after the FTDI adapter by any chance? It perhaps reveals garbage or signs of non-matching BAUD rates.
-
The fuse settings say 8Mhz internal, 2kb bootloader. Which bootloader are you using and did you adjust the baud settings in the boards.txt for the IDE (i.e. upload.speed=57600)? Also, do you get serial output at the set baud rate when uploading a simple serial output sketch via isp? Alternatively, I recommend recompiling the bootloader at 8Mhz for correct baud settings.
-
It's DualOptiboot that I'm using, compiled for 8Mhz (internal RC oscillator).
-
@hek Hello, I have a friend who is working with 3D modeling. i can study it. I do not guaranty for the moment, as it doesn't rely on me directly. however I can do the best, and try to move forward.
If I understand correctly, we need the place for the sensor+antenna+AA battery...
On the PCB, is there some hole to place some screws ?
How should we close the case ? by putting some screw or just putting a cover ? make sense ?
-
The board has humidity/temperature build in. So we only need space for maybe one extra sensor (question is how large volume this would need?).
Punch out holes for wires to external things like permanent power, buttons or reed-switches.Click on cover would be nice but requires more accuracy in the making. A screw wouldn't be a big problem.
Many variables...
-
Bootloader is working now.. I tried to compile for another target, atmega328_pro8, which worked.. (used "pro8" the other day, which also compiles for atmega328.. Hmm.. go figure)
-
@hek I know , yes for the T/H sensor. As we put 2 AA battery, we have to know if we want to stack sensor/battery or not...otherwise, battery and sensor will be on the same plan.
I think that we can start without extra sensor, and add it in function of request, I'm going to buy a 3D printer, It will be my first tests.
-
Today the production files have been sent off to China, for the first batch of 5 prototypes build by them. We then need to verify them, and if they are found OK, we start a larger production run.
Feeling like Christmas is comming up
-
I'm too late for my suggestion, but maybe it can be implemented in future versions if considered. Just in order to simplify connectivity with sensors, spare pins could be accessible via grove connectors. However the board looks amazingly small!
