Ämne: Fuktgivare för 1-wire

[pi.r]

Svårt var ordet...

Den fuktgivare som är klassisk i kombination med 1-wire loggning, Honeywell HIH-4000, är nog bra vid "normal" användning, men jag har inga positiva erfarenheter av dom vid höga fuktigheter. Jag vet dock inte om det är den som sitter i Rickards logger 2020.

När jag kört den sensorn i min kalibreringskammare på konstant 95%, har dom aldrig stabiliserat sitt mätvärde. Dom driver konstant uppåt. När dom drivit över 20% och passerade 110% gav jag upp (jodå dom kan ge utsignal som motsvara såna värden). Det tog visserligen flera dagar att nå dit. Sen återhämtade dom sej inte efter "torkning" vid låg fuktighet. I alla fall inte på en vecka.
Jag har även haft en tidigare variant av samma givare, minns inte typnummret, som bara mätt rumsluft i nåt år eller 2. Den gav upp helt när jag försökte kalibrera den (vid 95%).

Så att begränsa dom till ca 85% verkar vettigt. Kortvarigt kan dom nog klara 100%. Jag har inte försökt utvärdera var övre gränsen går för jag hade velat ha dom permanent i cellodlings-skåp (inkubatorer) med 37°C och ca 90%, men det sprack...

Nu har Honeywell kommit med ytterligare en ny variant, HIH4010 (/4020/4021). Den kanske är bättre, men dom har i princip identiska data som tidigare varianter, och det finns ingen beskrivning på om det skiljer något mellan dom. Jag ska köpa in några och testa...

[Rickard]

Vi har byggt en egen givare.
Nu är den ju så pass ny att man inte vet hur många år man kan lita på den, men än så länge verkar de fungera bra i alla fall.

[pi.r]

Vi har byggt en egen givare.
Nu är den ju så pass ny att man inte vet hur många år man kan lita på den, men än så länge verkar de fungera bra i alla fall.

Ni gör väl inte själva fuktsensor-elementet..? Det var det jag pratade om.

Jag undrar om jag har set någon fuktgivare för 1-wire som inte är gjord av en Honeywell HIH-4000, eller en av dess varianter, kopplad till en DS2438. Det finns tredjeparts-tillverkare som har tagit fram ett egna chip för 1-wire, med mikroprocessor-lösning gissar jag, som kanske finns med en annan fukt-sensor.

[Rickard]

Vi använder inte honeywells givare, utan har byggt en givare från grunden, men fuktsensorelementet är inköpt.

[vbkvbk]

Har du provat denna?
http://www.farnell.com/datasheets/63149.pdf

Dock har jag inte provat den i väldigt fuktig miljö under lång tid.
Den har ju iofs inte 1-wire interface, men det går väl ordna på egen hand.

//Micke

[pi.r]

Nej jag har inte provat den eller några andra sesnsorer. Jag föredrar sensorer med analog utsignal, som Honywells. Dom är extremt enkla att mäta med befintliga 1-wire-kretsar.

Jag har förvisso en egen PIC-baserad 1-wire "slav", som skulle kunna prata med sensorn du föreslår. Problemet är den behöver strömförsörjning (bortsett från att den är dyrare o mer komplex). Den klarar sej inte på "parasit-power", dvs. strömförsörjas av energin i data-ledningen. Och vi har ingen lust att införa strömförsörjning i "onödan"... Fast det kanske inte är onödigt - om man vill få det att funka.

[vbkvbk]

Tjena!

Det är som jag ser det inga problem att köra sensorn på parasit power.
30uA i snitt förbrukning enligt databladet.

//Micke

[pi.r]

Tjena Micke..!

Jo, men den tar 0,5 mA när den mäter... En (1) sån' kan man klara, i alla fall med lite fix (strong pull-up). Och man kan ju se till att mäta dom en i taget...

Men det är inte sensorn som är problemet - det är mikroprocessorn - som man behöver för att prata med sensorn och 1-wire-bussen. Jag kör med en PIC som kanske inte är av modernaste snitt. Men oavsett vad man väljer för processor så måste den snurra med ca 10-20 MHz klocka - hela tiden. 1-wire-kommunikationen kräver att man har timing med upplösning ner till någon µs. Och den måste lyssna på bussen hela tiden.

Vet du nån processor som klarar att gå på 10 MHz eller mer, på mindre än 100 µA, så är jag intresserad. Jag har bara tagit för givet att det inte finns, så jag har inte ens försökt leta...

[vbkvbk]

En kondensator löser tillfälliga laster.
1-wire kommunikationen kan kanske köras via inbyggd HW-support i processorn och därmed kunna gå på låg hastighet för låg strömförbrukning?
Varför måste den lyssna hela tiden?
Nyttjar man powersave funktionerna i moderna PIC:ar i kombination med en smart mät/kommunikations algoritm, så är det nog inga problem att komma ner i 100uA förbrukning.
Spara ström är alltid en liten utmaning, men tänker man till lite extra så brukar det inte vara en omöjlighet, snarare tvärt om...

//Micke

[purjo__]

Tjena Micke..!

Jo, men den tar 0,5 mA när den mäter... En (1) sån' kan man klara, i alla fall med lite fix (strong pull-up). Och man kan ju se till att mäta dom en i taget...

Men det är inte sensorn som är problemet - det är mikroprocessorn - som man behöver för att prata med sensorn och 1-wire-bussen. Jag kör med en PIC som kanske inte är av modernaste snitt. Men oavsett vad man väljer för processor så måste den snurra med ca 10-20 MHz klocka - hela tiden. 1-wire-kommunikationen kräver att man har timing med upplösning ner till någon µs. Och den måste lyssna på bussen hela tiden.

Vet du nån processor som klarar att gå på 10 MHz eller mer, på mindre än 100 µA, så är jag intresserad. Jag har bara tagit för givet att det inte finns, så jag har inte ens försökt leta...

Finns det inga mikrokontrollrar med inbyggd 1-wire slav, eller nån separat 1-wire slav som kan sköta signaleringen och buffra datat så att mikrokontrollern kan läsa det via nåt av de protokoll som vanligtvis finns implementerade i hårdvaran (i²c, rs232, etc)?

[Rickard]

Jag har delat upp ämnet.

[pi.r]

Kände åxå att ämnet började "flumma ut" lite väl...  Så det var ju bra.
(Även om jag fick leta lite för att hitta hit)

Varför måste den lyssna hela tiden?

Den vet aldrig när bus-mastern tänker börja fråga efter mätvärden...

Vad är rekordet i snålaste förbrukningen vid 10 MHz? Nån som har koll? Eller vet på ett ungefär? (Hmmm... kanske fel forum det här... men ändå.)

[vbkvbk]

Du kan nog lätt få processorn att sova 99.99% av tiden som den ska lyssna efter att mastern ska börja sin förfrågan.
Den mesta av tiden så väntar man på att något ska ske (det är få instruktioner som det verkligen sker en förändring).
Denna väntan gäller att göra på smartaste sätt så processorn kan sova under tiden.
En gissning är dessutom att du ganska lätt kan komma under 100uA i snittförbrukning för processor och givare.

//Micke

[pi.r]

Hade börjat fundera i dom banorna. Med en hårdvaru-baserad detektor som väcker processorn vid recet-pulsen på bussen skulle man nog kunna får till det.

Men lätt..?  - hmm...

Det är nog inte värt besväret förrän jag vet att det finns en sensor som är bättre än den jag har i alla fall...

[vbkvbk]

Allt som behövs är bara en smart algoritm.
Lägg ut en lång "startbit"  från mastern som sedan slaven vaknar upp och kontrollerar status på pinnen och om den inte finns där gå och sov igen (timer avbrott). Kanske 31khz klockan räcker till det och när den hittat startsekvensen och vet att nått är på gång så kan den gå upp i hastighet. Vad har du för bithastighet? Du kan sova med processorn medan du väntar på nästa bit i datat. Har du tex 1kbit så är det ju bara 1 instruktion av ca 2500 som det verkligen händer nått på bussen. Så du kan med andra ord teoretiskt sova 2499 av 2500 instruktioner vid väntan på nästa databit.
Eller kanske det finns HW i processorn som stödjer kommunikationen i HW så behöver man bara vakna upp en gång per byte.
Som sagt man får tänka till och aldrig loopa för att vänta på något utan istället sova.

Nyttja inbyggd HW stöd i processorn fullt ut och powerdown/sleep funktionalitet i kombination med smarta algoritmer så blir strömförbrukningen mycket låg.
Det man kan göra i mjukvara ska man inte göra i hårdvara med undantaget om hw finns inbyggd redan då ska man nyttja den tex processorns inyggda HW stöd för olika funktioner.

//Micke

Edit: 2499 istället för 2599