according to the datasheet the precision on temperature is +/- 0.4 degrees celcius, and +/- 3% RH.

They did however release a new chip revision (Si7021-A20) just after I bought mine (which is A10), they had some problems where the chip didn't enter standby correctly. Maybe that is the problem (also battery drain has been quicker than what I expected on the new node)

and yes, it's about an hour handsoldering things, and also programming the sensor, which also caused some troubles. Had to reprogram a lot of times, because of checksum errors. This could be caused by the fact that I have both eeprom, and nrf24l chip hanging on the SPI bus on the atmega, this is the same bus that is used by my ISP programmer (jtag ice3).

Think I have to get a proper bootloader into the device, so I can use the serialport to download instead.

and now the external SPI flash is verified as working, just with a simple program, reading out the manufacturer ID, and writing / reading data to/from the device.

Next step I wanted to get a bootloader working, so I could use standard arduino to download firmware, and also (at some point in time) utilize the flash for OTA updates. However, I can't seem to get bootloader support working..

I have tried to get DualOptiboot from lowpowerlabs working now, with several rebuilds etc., it seems like it is running fine (LED is blinking a couple of times, when it boots) but arduino wont sync to the bootloader, so either it runs on a wrong baudrate, or something else is wrong in the setup. But so far I haven't suceeded in figuring out what it is..

(Anyone else that has some knowledge on bootloaders, that could have an idea to what to look at?)

I am almost ready for a second prototype spin of the PCB, but before doing that I could use some input from the community,

If this board was going into "mass production", is there any features that I should consider adding? Any missing parts? Anything that you think that I have forgotten?

The schematics for revision 2 is a couple of posts back in the thread.

I have considered adding a ATSHA204 for future security purposes, but can't seem to find a suitable spot for it (maybe I'm just too tired to see things clearly at the moment :)).

I would work on trying to get the ATSHA204 included, even if it means the dims get a little larger. The one thing that I really don't like about MySensors is the lack of any wireless security.. Would love to see this implemented.

I would work on trying to get the ATSHA204 included, even if it means the dims get a little larger. The one thing that I really don't like about MySensors is the lack of any wireless security.. Would love to see this implemented.

For one second, I thought you where danish :), as the word "dims" usually refers to a small gadget like device, that you don't have a name for at the moment (or even components, screws, bolts, anything small could be a "dims")

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.

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)

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?

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?

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.

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

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.

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

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

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)

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.

@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 ...

@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).

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.

@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 myself

Btw, have you measured the actual power consumption? Sleep vs temp/hum measurement?

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

@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.

@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

@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..

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.

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.

@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.

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.

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 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)?

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 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