MySensors battey board revision 1.0

[Anticimex]

In my opinion, keeping Arduino bootloader compatibility (or rather, supporting the Arduino IDE flash protocol) is a must for a OTA bootloader. Even if it would mean some more flash need to be reserved for the bootloader.
But that of course makes it even more interesting to have some external memory support. I2C based EEPROMS have been around for quite some time :)

[Zeph]

I mentioned the Moteino, which has an optional 8 pin 4 Mbit (512KByte) SPI flash chip.

Felix has a modified Uno class bootloader, the Dual Optiboot https://github.com/LowPowerLab/DualOptiboot which takes up 1KByte (vs 512 Bytes for normal OptiBoot).

As I understand it, you send the new code OTA where it's written to the external SPI Flash memory. Then when booting, Dual Optiboot looks for a signature in the Flash memory, and if it found, burns the code into application Flash on the ATMega chip (and it obviously removes that signature). If not signature found in SPI flash, it will boot normally as a normal OptiBoot system.

The Moteino uses the RF12B or RF69 sub-GHz radios. Another cool design. I however like the 2.4GHz nRF24L01+ because it's cheap and very fast, useful in controlling Christmas lights, which take much more bandwidth. I see periodically reporting MySensor style data as another option using the same nRF24L01+ hardware, either instead of the light control function, or in addition to it.

[axillent]

OTA is a very promising thing
for the battery board selecting any external chip is also a question of power consumed

the idea with flash is good because it builds the ability of transactional while you able to safely recover from any situation.
but from other hand. you can safely recover even without flash if your second party will take care
look how upload from USB is organized. It do not have a transactional mechanism, it cannot recover by itself
if upload failed the only way to recover is to upload again
why we need OTA to be more safe than regular USB update?

but while you a thinking on this i found an issue in the board schematics. I have to add one diod and one 10k resistor to isolate D0 of the MCU from the parasite power coming from the external FTDI programmer. Otherwise the parasite power can destroy nordic chip

[axillent]

I have news

prototype of the board fully tested except radio
stepup is working fine, power switching is working
programming using external FTDI is working, schematics corrected to get rid from parasite power
al I/O is fine
battery and solar voltage measurement is working
temperature sensor is excellent
it was not simple to solder, the package is unbelievably small - 1.7 x 1.2 mm, 6 pins

next and last is radio, going to solder it today

[Zeph]

Interesting that you are choosing GROVE connectors. Are they easy to find (other than SEEEDStudio)?

This makes for an almost drop in alternative to the DevDuino's :http://www.seeedstudio.com/wiki/DevDuino_sensor_node

[axillent]

@Zeph

@Zeph said:

Interesting that you are choosing GROVE connectors. Are they easy to find (other than SEEEDStudio)?

GROVE is just a convention on pin assignment. The physical connectors are standard 4 pin 2.0mm pitch (arduino is using 2.54mm)
Two pins are used for GND + VCC and two pins for data/analogue arduino pins
I have them purchased from aliexpress

This makes for an almost drop in alternative to the DevDuino's :http://www.seeedstudio.com/wiki/DevDuino_sensor_node
we are different.

we have compact, ready to use double power sensor node
devduino is using an external radio, v1 is using low capacity CR2032, v2 is using two AAA batteries
we are using radio on board, single AAA battery with step up and a solar connector with automatic switch

CR2032 is just 80-120mAh
AAA alkiline is about 800-1000mAh

two batteries on devduino is 1600-2000mAh but it will work until discharge of a cell to 0.9-1.65V (supplying 1.8-3.3 V) depending on the frequency used
we can run until discharge to 0.7V regardless frequency used. Single cell reduces space needed and stepup allows to draws a maximum

[Zeph]

Sorry, I by "almost a drop in replacement" I meant that somebody using a DevDuino could (almost) unplug it, plug in your board, upload the code, and go, if they use the same radio and connectors. (Or vice versa). That flexibility could be good.

I didn't mean that your design was the same or had no advantages! Thanks for listing the key differences, tho.

And - it's "almost" compatible, software wise. I think the data connector has different pin numbers. Not sure about the radio pins (other than dedicated SPI).

But I think that with a change in pin defs, most code could be moved between them, and with the same connectors, a physical switch could be simple.

[axillent]

@Zeph if you have developed a sketch for DevDuino you will just need to change a pin assignment to move it to MySensors board
it is a good practice to use #define for the definition of your hardware pins and move this to abstract level, for example:

#define RADIO_CE    8
#define RADIO_CSN   9
#define PIR_SENSOR  3

to change this assignment you just need to change this few lines

[Zeph]

Yes, that's about what I thought. Thanks.

Looking forward to your board being available. I had ordered a couple DevDuinos, but now I'm holding off on ordering more since seeing yours - and for me the option of being able to swap out which is used could be handy.

Looking forward to hearing more about availability and final pricing, when you have it.

Oh, did you use the same temp sensor?

[axillent]

@Zeph

@Zeph said:

Oh, did you use the same temp sensor?

devduino is using analogue sensor with accuracy ± 2 ° C in range -40 ° C +125 ° C

we are using very low consumption digital sensor with accuracy ± 0.5 ° C with MCU wake up function on alert
range -25 ° C +85 ° C

[Zeph]

@axillent
I feel like the straight man, feeding you lines :-)

Seriously, it's great to have the differences listed for everybody to see.

[axillent]

@Zeph YAW :)

[Damme]

How's the progress with the radio?

I was thinking about the small stuff soldering, Me myself don't have that much trouble with the multi-pin chips.
For QFN (I hate them) I usually pre-solder the pads and use lot of flux and heat gun.
For TQFP I usually solder just one pin in 2 corners, and then I put a thin strip of solder along the pins and just drag my iron across. and if it's a mess, you used too much solder and to little flux :)
I hate soldering smd resistors and stuff, the smaller the more ass they get.. :P

[axillent]

@Damme I get first success on testing soldered radio, but more tests are needed

I use similar technique for QFN and TQFP
goof flux is a must

And why you hate this little friendly SMD staff?) I like them. 0603 is optimal size, easy to solder, not too little.
0402 needs much more care

[daulagari]

@axillent

Looks like a very nice board and the ability to also power it using a solar cell and the very efficient step up converter makes it quite interesting to me.

One question: Would it be possible to use a rechargeable AAA battery and if there is enough (solar) power, recharge the battery?

[axillent]

@daulagari sure you can use rechargeable AAA as power source

it is decided not to add charging function
if you will use dual power (and if your sketch will be optimal from power saving) regular alkaline can lasts for 1-2 years
at the same time rechargeable AAA because of often charging-recharging circle (every day because of solar) it can last in one year
number of recharging circles are limited and also Ni-Mh/Cd they last faster in such way because of "memory" effect

[daulagari]

@axillent: Still a bit puzzled as the combination of support operation from an external (solar) supply but no charging support seems not logical to me.

Understood that the number of recharging cycles of rechargeable batteries is limited but batteries still have about 10 times the capacity of supercaps so also if the capacity is reduced to 10% of the initial capacity because of the number of recharging cycles they are still a better choice.

On Wikipedia I read that charging at C/300 or even C/40 seems to be safe over long time and that can be done using a diode and resistor I think.

But ... also if there is no charging support, I am interested to buy a few ;-)

[axillent]

@daulagari
the logic is that none rechargeable battery can lasts for 1-2 years
rechargeable battery can lasts for 1-2 years too
and what is a reason to pay more for rechargeable one?

it is theory, but it is based on deep thinking. If we will see a practical reasoning for recharging function it will be added to revision 2

[Zeph]

Interesting analysis.

We get into a mindset that solar + battery implies recharging the battery from solar. That is, we think of the solar as the power and the battery as a buffer for dark periods.

You are using the solar as a battery extender for a primary battery. It can run for very long periods in total darkness (much less cloudy days), but when it does get solar you can go longer between battery changes.

And your point is that the rechargeable batteries need to be changed every year or two anyway, so if you can get that long with a primary cell (cheaper and bridges longer gaps without solar), why bother?

Sounds good to me - I await practical experience. Do you yet have one or more test units accumulating data and testing the approach? On cool things about JeeLabs is that with each new design he puts up some long term test units, wirelessly logging the results. Over time he gets years worth of practical results to report and analyze.

[axillent]

@Zeph thanks for the feedback
I'm wondering on triple power sources - main is solar, buffer is super capacitor and none rechargeable as back-up
super-capacitor is a best choice for night time run while charging at daylight time
super capacitors are not cheap, but while we will have a production experience I think we will manage its price down

sure it will be good to track performance. May be Henrik can think of adding some statistics logging to MyCloud service and this can be seed from the whole community in the future