Minimal design thoughts
-
@Dirk_H said:
@tbowmo I don't see a Load Capacitor on the crystal. Especially if you need a precise clock you should use some. Have a look at https://www.adafruit.com/blog/2012/01/24/choosing-the-right-crystal-and-caps-for-your-design/ for example about Load Capacitors.
I know that normally the crystal require load capacitors, but for the low freq. oscilator (32Khz) its not necessary (as far as I have read), that's why I omitted them from the design. I'll try and dig out the datasheets when I'm at home and double check things.
-
@Tibus said:
@tbowmo said:
ATSHA204
This module is verry interesting but how it work? What you have to do in code to make it work, crypting messages,...?
There are other threads about the ATSHA204 around in the forum. It's basically just a method for signing messages between units, not encryption. I haven't made any code for it myself, just thinking about implementing it for future plans (and for others to pick up on)
-
@tbowmo said:
@Tibus said:
@tbowmo said:
ATSHA204
This module is verry interesting but how it work? What you have to do in code to make it work, crypting messages,...?
There are other threads about the ATSHA204 around in the forum. It's basically just a method for signing messages between units, not encryption. I haven't made any code for it myself, just thinking about implementing it for future plans (and for others to pick up on)
Ah but from what I've read it can indeed encrypt the data stream. Did I completely get it wrong?
-
@ServiceXp said:
@tbowmo said:
@Tibus said:
@tbowmo said:
ATSHA204
This module is verry interesting but how it work? What you have to do in code to make it work, crypting messages,...?
There are other threads about the ATSHA204 around in the forum. It's basically just a method for signing messages between units, not encryption. I haven't made any code for it myself, just thinking about implementing it for future plans (and for others to pick up on)
Ah but from what I've read it can indeed encrypt the data stream. Did I completely get it wrong?
It's a crypto authentication device, datasheet is at
http://www.atmel.com/devices/ATSHA204A.aspxFor sensor data it should be enough, it help to prevent replay attacks, so an intruder can't switch of the lights for example, because the attacker don't have the presharred keys available
-
It's a crypto authentication device
As discussed in the security thread I think authentication alone can be useful but encryption is providing both security and a reasonable form of authentication so why not go for an encryption IC instead of the ATSHA204A.
Atmel has a nice IC doing AES:
http://www.atmel.com/devices/ATAES132.aspx
A bit larger (8 pins SOIC), but reasonable cheap € 0,782 (@10)
It is also part of CryptoCape, so there should be some software support for it.
-
That chip is still only for authentication, only it's with aes-128 message auth instead of sha 256
Also another thing i noted, is that the supported supply range is from 2.5 to 5v, whereas the atsha204 could operate down to 2.0v.
-
That chip is still only for authentication, only it's with aes-128 message auth instead of sha 256
If I have a look at the datasheet I see:
Opcode Name Description 0x06 Encrypt Encrypts 16 or 32 bytes of plaintext data provided by the Host. 0x07 Decrypt Decrypts 16 or 32 bytes of data provided by the Host after verifying the integrity MAC.So it does encrypt/decrypt.
The CryptoCape board has both ATSHA204A and ATAES132 where the ATAES132 can "Encrypt up to a 32 byte packet at a time with AES-128-CCM"
Not sure if it is handy to have the integrity MAC combined as that does require 16 additional bytes, but that is the same story for SHA-256.
-
Hmm I was tricked by the "crypto-authentication" note on atmel site, so thought it only did auth.
Still, lowest vcc is 2.5v. If they could make a device that could operate down to 1.8v instead instead, it would be more interesting.
-
@tbowmo Yeah the 2.5v would be a problem, unless we can build an extremely efficient boost...
-
@ServiceXp
Yes, but I am trying to avoid booster circuits at all costs in this design. Also the main function is to collect temperature and humidity values from around the house. So for my part encryption is not a must have for this device.
btw I'm almost there with rerouting rev 2 to make room for the atsha204 (in sot23 housing)
-
Just reading through the datasheet of ATAES132, and realise that I already have support for it on the board. It uses a standard I2C / SPI eeprom footprint, and that is already on the board. So if anyone would like to use it, they only need to replace the flash.
Anyway, I have finished re-routing things.. and the ATSHA204 is now incorporated in the design, so challenge/response authentication could be implemented.
Just need to do the last couple of reviews, before I press the order button for a new set of pcb's
-
Is it not possible to just encrypt the entire packet with an AES library on both ends?
-
@tbowmo Does your design support both I2C and single-write ATSHA204?
-
It's single wire atsha204, it's connected to A3. I couldn't fit in the 8 pin variants of the atsha204, so that ruled out the full I2C bus version. It even took me a couple of hours of re-routing to make enough room for the sot23 housing of the ATSHA204.
Anyway, schematic / pcb layouts are as follows
-
@tbowmo Excellent.
-
@tbowmo Once again,... Well Done!
-
And for the fun of it.. Just made a github repository of the design
https://github.com/tbowmo/MySensorMicro
Just in case anyone would like to have a closer look in eagle.
-
I wonder what kind of "hit" on battery life authentication/encryption will have?
-
I do not think it is a big issue. Authentication is normally only needed on nodes that have actuators. And this implies that they always have to listen for incoming data and are therefore inherently non-battery friendly The ATSHA has a very low power consumption, so the added cost for message signing procedures is probably negligible compared to the cost of running the radio continuously.
-
Hmm thinking about it, authentication could be valuable on sensors as well.
If you use the sensor readings to control another actuator, then an attacker could send in his own bogus sensor values in order to trigger system events. He does need to know the specifics about your setup though, so the question is if it's affordable to the mischief to do anything like that
-
Yep. This is true, and something I eventually have to add support for.
-
@tbowmo said:
@Dirk_H said:
@tbowmo I don't see a Load Capacitor on the crystal. Especially if you need a precise clock you should use some. Have a look at https://www.adafruit.com/blog/2012/01/24/choosing-the-right-crystal-and-caps-for-your-design/ for example about Load Capacitors.
I know that normally the crystal require load capacitors, but for the low freq. oscilator (32Khz) its not necessary (as far as I have read), that's why I omitted them from the design. I'll try and dig out the datasheets when I'm at home and double check things.
Got around to check up on datasheet for atmel328p, when using lowfrequency oscilator, it has internal load capacitors. If you look at page 33 in the datasheet. So it's not necessary for external capacitors
-
very soon the next prototype pcb revision will be ordered from China. Gonna be exciting. Almost like Christmas, where the kids just wanna open their gifts
-
And pcb's are ordered.. Again, using dirtypcbs.com, for the order..
I have used a panelizer tool from http://blog.thisisnotrocketscience.nl/ to panelize the boards this time, so it should be easier to depanelize it when they get here..
-
@tbowmo Looks great!
Haven't actually ordered anything produced by the panelizer yet, but the results look really amazing:
I was planning to finally get around to some boost regulators. But I need to design mine from scratch (these are just scavenged from other places) so they follow the same design guide lines and can be plugged in seamlessly to the main pcb.
Would be great if there were some sort of common design to follow for designing shields and such.
-
As you all probably have noticed, there is an mysensor logo on the boards, that I just ordered..
I have been cooperating with @hek for a while, and this is going to be an "official Mysensor pcb"
We have been in discussions with a vendor in china, for doing SMT assembly as well.. We are currently waiting for the pcb's to arrive and get them populated, to verify that everything is as it should be, before we start up production in China.
For a batch of 100 units, the price is about 13$ per unit, plus shipping/handling fee, this is without any profits to the project
One question though, I made room for an ATSHA204 chip on the board, that could be used for authentication purposes, we want to know if this should be mounted as default on the board, as it will add arround 1$ to the unit price.
Also how many would be interested in ordering one (or 10, 20, 50?) of them?
(just so that we get an indication if we should make a batch of 100 units, or 500 units)
-
That's 2 questions...
- Yes, It's worth it to me (Hopefully there will be MySensors software support down the road)
- I would probably start off with 3 to 5.
Will there be a "kit" price for those who want to populate and reflow themselves?
-
I would also be interested in at least 5 boards (initially) if they were populated, not ready for smt soldering yet.
-
@ServiceXp said:
That's 2 questions...
I edited it a couple of times while talking with @hek last evening, so it slipped. Hope you can forgive me
- Yes, It's worth it to me (Hopefully there will be MySensors software support down the road)
- I would probably start off with 3 to 5.
Will there be a "kit" price for those who want to populate and reflow themselves?
No kit version, the pcb will be released under oshw so you could order it yourself, and source the components. However my unit price for the initial units will hit 11-12$, so it's only 1 or 2$ extra to get it smt assembled in China.
The more units we can order the cheaper it will become.
-
@tbowmo I might be interested in a few, seeing as this PCB has some pretty unique features, but I'm still in the market for a board with an on-board regulator that will give me a bit more flexibility.
The problem (for me) is that while waiting for any official hardware, I've bought a lot of other stuff. I had another 10x Arduino Pro Mini arrive just yesterday for instance. Plus the booster project above. I ordered a couple of hundred brand inductors and capacitors as well as ltc3525 ICs. So basically now I don't have a choice but to go it alone for the most part
What we could need right now is some clear direction, like whether the ATSHA204 is the way to go. Or some common form factor that would allow future shields or whatnot.
Also, for something really small like this, to be put into production, I would have liked to have tried with the "smd / mini nrf24" version that is also available on Ebay, just to keep the size down even further. I just got three of those yesterday and they are indeed very tiny (pin header spacing is 1.27mm). Whether they work ok or not I do not know. I do know that some people on the forum have posted project pictures with these mini nrf24. I guess what I'm saying is that lowpowerlabs already invented the wheel here: http://lowpowerlab.com/moteino/
Would be great to hang a mini nrf24 flat off of the back if at all possible. But given what we know of the nrf24 it would probably blow up in our faces compared to the RFM12B/RFM69 that the moteino uses. Of course, they also use a wire antenna while we still trust the pcb antenna ...
-
@bjornhallberg said:
@tbowmo I might be interested in a few, seeing as this PCB has some pretty unique features, but I'm still in the market for a board with an on-board regulator that will give me a bit more flexibility.
The problem (for me) is that while waiting for any official hardware, I've bought a lot of other stuff. I had another 10x Arduino Pro Mini arrive just yesterday for instance. Plus the booster project above. I ordered a couple of hundred brand inductors and capacitors as well as ltc3525 ICs. So basically now I don't have a choice but to go it alone for the most part
What we could need right now is some clear direction, like whether the ATSHA204 is the way to go. Or some common form factor that would allow future shields or whatnot.
Also, for something really small like this, to be put into production, I would have liked to have tried with the "smd / mini nrf24" version that is also available on Ebay, just to keep the size down even further. I just got three of those yesterday and they are indeed very tiny (pin header spacing is 1.27mm). Whether they work ok or not I do not know. I do know that some people on the forum have posted project pictures with these mini nrf24. I guess what I'm saying is that lowpowerlabs already invented the wheel here: http://lowpowerlab.com/moteino/
Would be great to hang a mini nrf24 flat off of the back if at all possible. But given what we know of the nrf24 it would probably blow up in our faces compared to the RFM12B/RFM69 that the moteino uses. Of course, they also use a wire antenna while we still trust the pcb antenna ...I forgot about the mini nrf24 modules. But I don't think that we could have squeezed it that much more in size, we could probably save 2-3mm in stack height, but that's about it.
Also, this board was designed from the beginning to be a battery operated node. That is why there is no regulator on board (besides the fact that there is no room for it). I selected the components for their ability to work on low voltages all, except the atsha204, is able to work on a VCC as low as 1.8V)
I have seen lot's of questions asking about battery operation of 3.3V arduino mini pro, with DHT22 sensors attached. People cut LED's and regulators on the arduino, in order to get the power consumption as low as possible. This is where this particular board fits in. It's ready for battery operation, and has the temperature / humidity sensor build in.
It started out because I wanted an "easy" clean option for sensor nodes for my own application, without any wire nests between arduino and nrf24 modules. I hope that it will be useful for others as well, and might be able to get others going with the mysensor project.
For my own part, I could use up to 20 of these, for measuring temperature / humidity in every room in the house (and out side as well)
Btw. all those arduinos you've bought, could be turned into something else
-
I snapped some pictures just so everyone can see the difference between the nrf24 modules.
Of course, like I said, I don't even know if the "mini" works in a satisfactory manner. I'm gonna get some smaller pitch headers so I can make a prototype. But the PCB antenna actually seems to be the exact same size so I have high hopes for that aspect at least.
-
The antenna still needs to hang over "free air" (or an unrouted PCB area), this is the area where the logo is located on the current design. It could be moved to the opposite end of the pcb (where the nrf24 pinheader is located).
If we switch to the mini module, then the pinheader for the radio is removed, but then you need a "larger" area where there is no components at all, in order to mount the nrf module flat to the sensor pcb. So in theory it will not be that much smaller, only the pinheader distance between the two pcbs can be removed.. lenght /width will be almost the same, maybe a bit longer as there is not that much room to give, with the current number of components (Si7021, eeprom, atsha204 etc).
-
@tbowmo Yeah, you're probably right. It would take some re-design and you might not save all that much space, given all the other components as you say.
Still, it'd be great to achieve something ... flatter ... like:
http://harizanov.com/2014/07/diy-internet-of-things-fire-alarm/
Runs an attiny84 though, but still.
-
Could you measure the mini pcb? the width of the module, and lenght of the area with gnd, and the length of the antenna area (and total length of the module, should be the two lengths added together)
-
@tbowmo I found an old post I made here:
http://forum.mysensors.org/topic/413/is-there-a-schematic-of-the-nrf24-board/2
I checked the measurements and they seem right. In addition, the antenna-area is about 8mm long.
-
made a mockup of the nrf24 mini module, and tried to place it on the sensor board.. If I should use it, I have to remove the ISP pinheader from the board, as there is no room for it.
Also, it is filling up almost half the populated pcb area on the sensor board, which means that there is not enough space for the components, and we have to make a bigger pcb, in order to have room for everything.
-
@tbowmo Yeah, better to save it for a future project. I mean, there will never be a one size fits all and that is what is so great about MySensors. All the PCBs designed so far have a purpose and a market. And ideally, we'd want a few of each in the sensor network to complement each other.
The reason I brought up the "mini", aside from wanting a flatter sensor node, is that the module seems to be getting more common on Ebay as well as cheaper. I've seen some sellers that sell them for the same price as the regular NRF24 now (in 10pcs). Four months ago, they were rare and many times more expensive. So if they work as advertised they could soon replace the NRF24 module we've all come to use.
In this context, and knowing very little of antennas, it is too bad they don't have a version without the PCB antenna altogether. We could add our own antennas and more easily fit the module on miniscule sensor nodes such as yours.
-
I would be interested in 5 units. I lean towards including ATSHA204 and smt assembled, but I would buy without and unassembled.
-
So you would just buy the PCB, and source all components yourself?
-
@tbowmo
Sorry I was a bit unclear. I would like to buy all components as a package from you/mysensors. Preferably assembled, but I would also accept if you sell it unassembled (pcb+components). I would rather not have to source the components myselfBtw, have you measured the actual power consumption? Sleep vs temp/hum measurement?
-
I haven't measured supply current, as I don't have the equipment to do that. I am looking at getting the uCurrent gold from eevblog, but it's expensive to import it to Denmark.
It will probably not be offered as a kit. Too much work from my/our part
-
-
Hello, I'd be in for at least 5 assembled boards.
-
Soo .. this like a breadmix ?
All we have to add is the sensors ?
-
You already got an ucurrent? I had planned to import an extra one from Australia for you
(thought that we might be able to save some $ if we ordered 4-5 units).But as so many other things i got away from it again
Unfortunately I only come to Copenhagen these days, visiting a client.
-
@JimmyH
There is a temperature / humidity sensor on it already. But more can be added
-
Ok, pushed a product page to the main site just now. Hope the page is selling enough.
-
"ATSHA204A sot23 footprint on board"
So does that mean this run will not have the ATSHA204A populated?
-
@ServiceXp
We haven't started production yet, I'm still waiting for the latest prototype pcb to arrive from China, before I can make the (hopefully) last prototype before "mass production". Which also means I have to find the atsha204 somewhere, so I can test it.
And yes I know mouser has it, but I don't need that much more from them, so will have to pay a big handling/shipping fee to them
-
@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!
