Table of Contents
BrmHive
~~META: status = suspended &relation firstimage = :project:beehive-generic.jpg ~~
We would like to research the temperature distribution in a beehive during winter season. This is useful for general primary research about bees, but also whether it is better to have thin-walled beehive or well insulated thick-walled beehive. The data should provide 3d grid model of the beehive with temperature sampled several times a day. The data will also provide information on outside temperature and the momentary weight of both beehives.
Our measurement will be the first scientifically rigorous study (known to us) comparing insulated and uninsulated beehives. The data should suggest distribution of the bee cluster in the hive during winter, and the speed of consumption of honey for heating. One argument against insulated beehives is that bees cannot detect short outside temperature spikes to fly outside and excrete; a possible counter-argument is that excretion need of bees in insulated beehive is much lower due to lower honey consumption. The hypothesis for our data is that weight of insulated beehive decreases much slower than of the uninsulated one, and that temperatures within are on average higher and more evenly spread.
The measurement will be done in a garden where (i) mostly everything will be covered by snow (ii) it cannot be expected that the operator will regularly check more often than once per month (iii) there is no AC current connection.
Most of this page is in Czech, sorry! It is cut'n'pasted from various mails and was written originally in this way.
Status
We have the circuitry designed and built on a real PCB. Firmware is also mostly written. The actual temperature sensor bus still needs to be soldered during the summer, and a better solution for weight monitoring should be devised.
The software processing the collected data is in much less hurry and should not be too troublesome to do.
Implementation
Circuitry
Blokove schema:
baterie1
|
-------------Atmega168---------------
D8 D11 D13 D2 A4 A5 D10 D5 D3
| | | | | | | | |
-SD SPI- [PCF8583P] +DS18B20 led btn
| +DS18B20
[baterie2] ..xN
Na pinu D10 bude zapojena one-wire sbernice s teplomery. Jak nazev nenapovida, jde o dvouvodicovou sbernici - napajeni/data a zem; v pripade velmi dlouheho vedeni (nad 30m? hlavne zalezi na odporu dratu) by melo byt pro teplomery zvlast jeste dalsi napajeni. Jako teplomery zda se nejlepsi pouzit DS18B20.
Jsou siroce pouzivane, maji celkem vysokou presnost a kus stoji 50Kc. Jsou tripinove, pro kratsi sbernice lze ale napajeci a datovy propojit. Pro nas ale bude bezpecnejsi radeji vest vsechny tri vodice, preci jen sbernice nebude nejkratsi, napeti z baterie muze kolisat a predratovavat to… Neni je potreba predem kalibrovat. Zda se, ze pocet teplomeru na jedne sbernici je prakticky neomezeny.
Krom toho bude na pinu D10 LEDka indikujici aktivitu a na pinu D3 synchronizacni tlacitko (ktere na SD kartu zapise aktualni casovou znamku s informaci o stisku tlacitka).
Optional mod: Napojit napajeni baterie take pres odporovy resistor na A3, abychom mohli sledovat, jake napeti baterie ma.
Specifikace funkcionality
Jednou za dany casovy interval se ATMega probere, rozsviti LEDku, postupne se zepta vsech teplomeru na sbernici na teplotu, zapne a zmeri odpor silocitlivych rezistoru a vysledne pole udaju spolu s casovou znamkou zapise na SD kartu. Pak zhasne LEDku a ceka na dalsi probuzeni, behem toho se snazi zrat co nejmene proudu a udrzuje si cas.
Jednou za cas navstivi zarizeni vcelar-operator, zmackne dvakrat synchronizacni tlacitko, vymeni SD kartu, jednou zmackne synchronizacni a odveze SD kartu domu ke kontrole a zaloze; to same pri vymene baterii (doporucuji alespon 1x za mesic). Behem bezne inspekce ulu muze tlacitko mackat sem tam jen tak. Kazde zmacknuti tlacitka vsak musi zaznamenat spolu s presnym casem do deniku. Mackani tlacitka tak slouzi jednak k urceni, kdy doslo k pripadne zavade, ale take ke svazani interni casove znamky zarizeni a skutecneho casu a data.
V pripade spravneho chodu LEDka po stisku tlacitka pet sekund nepretrzite sviti. V pripade zavady pri poslednim cteni (problem zapisu na kartu, preruseni sbernice) se LEDka na nejakou dobu zoufale rozblika (typ blikani muze indikovat druh zavady).
Teplomery by mely pokryt skorokrychli ulu v matici 3x3x3, na jeden ul tedy potrebujeme 27 senzoru. Porovnat budeme chtit dva uly ruzne konsturkce, tzn. 54 teplomeru. Jeste jeden dalsi teplomer bude snimat pro srovnani venkovni teplotu. Zaroven budeme merit vahu; vahove senzory nebudeme mit moc moznost realne testovat a zaroven musime rozlozit velkou vahu ulu, takze pod kazdym ulem budou na protilehlych stranach dva.
Weight Measurement
Bude uzitecne zaroven snimat vahu ulu a jeji vyvoj v case, ktery by mel korespondovat s tim, jak vcely postupne spotrebovavaji zasoby. (Jestli chapu dobre, ul bude pod strechou a snezit na nej nebude.) Senzory se museji sehnat. (Taky by asi slo si senzor postavit sam, na to ale pasky tenhle rok urcite uz cas mit nebude.)
Co vypada celkem rozumne je treba za 238Kc: http://shop.conrad.cz/websale7/?shopid=conrad-cz&act=product&prod_number=503369
Je to krouzek o prumeru 2cm (plocha PIcm^2) a snese zatez 10g..10kg. Tzn. meri zatez v rozsahu dejme tomu od 3g/cm^2 do 3kg/cm^2. (Pry v trochu jinem zapojeni by mel umet i vetsi, ale to si nejsem jisty, jestli plati i pro tenhle model.)
Kdyby se dal pod ul, dejme tomu, ze ul ma 70x50cm (fakt nevim?) a sirka hrany nastavku je 2cm (taky netusim) - pak doseda na zem plochou 464cm^2. Dejme tomu, ze ul vazi mezi 5kg a 50kg. To dava zatez na senzor 10g/cm^2 az 100g/cm^2, coz by melo byt uplne v pohode. Ale neni to v pohode, pokryvame totiz dost malou cast senzoroveho rozsahu a samotna tolerance kalibrace toho senzoru je 2%, tzn. 60g/cm^2 - to je pres pulku naseho celkoveho rozsahu (ktery ve skutecnosti bude mensi - jaky?). Je ale treba prepocitat ty vahy s realnymi rozmery ulu a hran, a mozna vymyslet nejakou mechanickou metodu, jak na senzor poslat vice vahy ulu (nebo koupit za 300Kc senzor 5x5cm). Presnejsi senzory jsou sehnatelne, ale asi radove drazsi.
RTC Clock
Na schematu je jeste svab PCF8583 (D2 A4 A5). To je obvod pro RTC hodiny, ktery umi dve veci: udrzovat cas (dokud je napajen) a probouzet ATMegu v dany cas. To znamena, ze pokud bychom ho meli, pohodlneji by se asociovaly casove znamky a prodlouzili zivotnost baterii cca na dvojnasobek (procesor muze naprogramovat alarm a uplne se vypnout).
PCF8583 potrebuje krystal a je v klasickem DIL formatu, tzn. bude trochu otrava to pajet. Zere malicko (50uA bezne, 200uA pri cteni casu), ale napeti (2.5V-6V) potrebuje stale. Proto je asi nejlepsi ho napevno pridelat ke 3V cockove baterii, ktera ho zvladne napajet nekolik let.
Power Draw
Pocitejme 40mA pro procesor, cca 120mA na SD (pomalu teoreticke maximum), 1.5mA na teplomer, 5mA dohromady na LEDku a PCF8583P I2C komunikaci: cca 170mA bez teplomeru (spis mnohem mene, vetsina techto veci nebude brat proud zaroven).
Mikroprocesor v rezimu hlubokeho spanku (probudi je jen interrupt od tlacitka nebo RTC hodin) bere jen 1uA. Dalsi soucastky si muzou take neco brat, i kdyz nejsou aktivni, nemam moc jasnou predstavu, kolik, ale snad 1mA celkovy odber behem spanku je bezpecny odhad. Predpokladejme probouzeni kazdou hodinu. To znamena celkovou prumernou spotrebu 1.486mAh, takze s 2500mAh bateriemi by to melo cele opet vydrzet 70 dni.
Mikroprocesor si umi poradit s jakymkoliv napetim od 2.8V vyse, teplomery potrebuji minimalne 3V (nepocitaje odpor draty a pull-up). Vychazi mi, ze tri akumulatorova AAcka by mela celou dobu zivotnosti (az na temer uplne vybiti) davat rozumne napeti (4.5V-3.75V).
Da se tedy koupit jen samotna ATMega168 a primo na jeji piny pripojit ruzne veci. ATMega se musi nejak naprogramovat, ale na to ji muzeme proste docasne strcit do jednoho z ostatnich Arduin, ktere mame.
Potiz je, ze SD potrebuje napeti 2.8V-3.6V. Zaroven FSR (silocitlive odpory na vazeni) potrebuji stabilni napeti, jinak se meni jejich citlivost na vahu (mensi napeti = mensi citlivost, ale vetsi rozsah). Proto (na doporuceni jv) napeti z baterii budeme regulovat na 3.3V nejakym low-drop stabilizatorem - naprosto klicove je, aby I_q bylo nekde hluboko pod 1mA, jinak nam behem spanku stabilizator vycucne celou baterii. Zda se, ze z dostupnych soucastek nam zdaleka nejlepe vyhovuje LF33CV. Ma I_Q kolem 0.5mA (s malym vstupnim napetim jeste mene) a voltage drop jen kolem 0.3V.
Current draw measured - with guard transistor for FSR and SD card, the power draw is around 395uA when asleep; between 2mA and 40mA when active. 1 or 3 sensors on temperature bus do not seem to make any difference, so practical I_q of those is probably in the order of nA.
Parts List
vypocetni jadro:
http://www.gme.cz/cz/atmega168-20pu-p432-192.html 103Kc
DIL28-3 15Kc
http://www.gme.cz/cz/q-16mhz-p131-019.html 11Kc
http://www.gme.cz/cz/ck-22p-100v-rm5-p120-180.html x2 2Kc
http://www.gme.cz/cz/ck-100n-100v-x7r-p120-276.html 2Kc
pinove headery, propojovaci draty ?
=118Kc
ukladani dat:
http://www.gme.cz/cz/slot-sd030-p823-034.html 22,50Kc
SD karta TODO
=42Kc + ?
ovladani, indikace:
http://www.gme.cz/cz/l-483gdt-p511-112.html 4Kc
http://www.gme.cz/cz/p-b1715-green-p630-067.html 13Kc
http://www.gme.cz/cz/mpr-1k-p119-116.html x2 12Kc
resetovaci mikrospinac + pull-down ?
=29Kc
teplomery:
http://www.gme.cz/cz/mpr-4k7-p119-244.html 5,50Kc
http://www.gme.cz/cz/elektronicke-soucastky/ds18b20-p530-067.html x55 2706Kc
=2711Kc
vaha (optional):
FSR sensor x4 ~1000Kc?
NPN BC546 (jinak by FSR teklo neustale az 0.5mA)
odpory na delic
napajeni:
http://www.gme.cz/cz/akumulator-ni-mh-aa-2500mah-gp-batteries-p540-287.html x3 189Kc
http://www.gme.cz/cz/a306331-p819-022.html 11Kc
http://www.gme.cz/cz/lf33cv-p330-165.html 23,50Kc
dioda (ochrana proti prepolovani) 1Kc
=225Kc
RTC hodiny:
http://www.gme.cz/cz/pcf8583p-p433-039.html 61Kc
http://www.gme.cz/cz/q-32-768khz-40k-p131-210.html 9Kc
http://www.gme.cz/cz/baterie-zncl-4-5v-gp-batteries-greencell-p543-034.html 25Kc
=95Kc
Celkem: =3185Kc
+ sd karta
SD karta: “Kingston Micro Secure Digital 2GB + 2x adaptér + USB čtečka” za 284Kc
Scheme and PCB
Eagle files: http://rover.ms.mff.cuni.cz/~pasky/tempmonlog/
Comments
The SD card will be on the opposite side of PCB than the rest of controls, since the PCB is designed as single-sided (it is my first PCB ever and I just want to feel comfortable and take it slowly). For the same reason, we try to avoid any other SMD parts.
SD card's I_q is about 2.5mA. Also needs to have ground guarded by the aux power transistor.
Originally we also planned to have a battery voltage monitor by connecting VCC-GND resistor divider to one A/D input. But now, all of them are fully occupied. In the future, we might try to set up a trivial resistor-capacitor voltage to frequency converter and use a digital input.
For debugging purposes, we try to keep RX/TX pins unused.
Construction
In the first iteration, we just sticked all the interesting stuff in a breadboard to test the basic functionality. We are connected to the Arduino for power (stable +3.3V) and the ICSP programming interface (using ArduinoISP - with the auto-reset fixup, 120ohm resistor between +5V and Arduino reset!). The info LED, alert button, reset button are connected. I2C (RTC) and OneWire (tempsensors) buses are connected. SD is connected. FSR needs to be tested and we need to decide between opamp and voltage divider.
Software on the microcontroller: sketch
- [DONE] ICSP programming works!
- [DONE] Switching from +5V to +3.3V works!
- [DONE] Test blinking info led.
- Using stock ATMega168, the led is blinking, but 16x slower than it should. Probably need to adjust fuses and possibly Wiring library? I probably cannot go with full 16MHz on 3.3V anyway, and do not need to, either.
- Seeing that lfuse value was 0x62 before,
avrdude -c avrisp -p atmega168 -P /dev/ttyUSB0 -b 19200 -U lfuse:w:0xe2:mturns off the CKDIV8; now, 8MHz internal oscillator is used. - In the Arduino GUI, it is neccessary to select a board that uses 8MHz inst. of 16MHz crystal, to get the correct timing for delays. Select e.g. “Arduino Pro 3.3V 8MHz ATMega168” from the Tools-Board menu.
- The Arduino is uploading the binary too fast. For now, just uploading it manually:
avrdude -c avrisp -p atmega168 -P /dev/ttyUSB0 -b 19200 -e -U /tmp/build6625025781879237180.tmp/Blink.cpp.hex
- [DONE] Test checking alert button.
- [DONE] Test talking to the temperature sensors. Note down all their addresses (and labeling them).
- I used a standalone OneWire interface and example program to do the labeling.
- [DONE] Test talking to the RTC clock.
- [DONE] Test the sleep modes and wakeups.
- [DONE] Hook up the SD card.
- Soldered wires to the slot smd package. Urgh. ;)
- Operating a bit unreliably, but that is most likely due to long ratsnest wires, SPI is apparently not designed for these at all.
- Had to upgrade to ATMega328 to get bigger RAM! Might be possible to optimize everything for ATMega168, but probably just won't bother.
- [DONE] Switch to using on-board 3.3V regulator.
- Did not test battery run but should be fine.
- [IN PROGRESS] Hook up the FSR sensors.
- Resistor divider seems to work somehow. We have not tried calibrating them yet.
- [DONE] Make the PCB!
- [IN PROGRESS] Debug everything on the final PCB.
- We have a lot of trouble here.
Everything worked on the breadboard but the PCB just won't work properly and we do not know why. - Finally, SD card I/O +- works now, though there is still an occassional hiccup.
- Temperature communication does not work currently, no idea why.
- [IN PROGRESS] Solder all temperature sensors to a single bus.
- [TODO] Check the battery for temperature problems! I'm not sure with battery capacity dependence on the temperature.
Hacking Point
The beehives are provided and operated by pasky's father and located at Ceskomoravska Vysocina. He will also do the final temperature bus setup, possible boxing, installation in beehives and regular operation.
David Silhan is also buiding this in parallel, in a smaller version.