Datalogger för långa perioder

[Zajber]

Jag och en vän har en förfrågan på att göra ett exjobb tillsammans;
Det vi ska göra är en datalogger som kan logga 4-20mA signaler under väldigt långa perioder (minst 1 månad åt gången). Ev. ett enklare grafiskt interface och möjlighet att ändra samplingsfrekvens, dela upp loggningar och lite annat "lull lull"..

Tänkte dela med mig av våra tankar och ev. få lite feedback på grundidén:
* Mikroprocessor som huvudenhet så klart. Hade tänkt oss kanske någon av de lite enklare 32bitars enheterna. ARM, PIC32 eller nått sådant.

* Strömavläsningen sker m.h.a. någon extern krets som sedan skickar detta via SPI eller I2C till huvudenheten. Helst ska den enkelt kunna byggas ut med fler kanaler genom att hänga på fler enheter (I2C/1WIRE?).

* USB -flashminne för lagringen, mest p.g.a. priset/MB. FAT32/filsystem.

* Enkel grafisk display med en enkel knappsats.


Kom gärna med feeback kring idén, om det är något som ni tror inte funkar eller tips på system som är enkla och stabila nog att klara så långa körningar utan att riskera att data går förlorat.

[sodjan]

Svarar kanske inte på frågorna men i alla fall...

> (minst 1 månad åt gången)

När jag såg rubriken så tänkte jag, typ, "5-10 år"...

[blueint]

Va.. menar du att du saknar kunskap om hur långt ett snöre är!?

[jesse]

Svarar kanske inte på frågorna men i alla fall...

> (minst 1 månad åt gången)

När jag såg rubriken så tänkte jag, typ, "5-10 år"...

haha, allt är relativt... Jag tänkte "mer än 10 minuter"....

Idén verkar ju bra. Ser inga direkta problem. Givetvis använder ni RTC (Real-time-clock) med backupbatteri så att processorn kan fortsätta lagra data korrekt även efter en oavsiktlig reset.

Enda svårigheten om det hade varit jag som skulle bygga den hade varit hur man interfejsar USB-minnet?
Personligen hade jag föredragit mini-SD eller micro-SD-kort eller liknande som i princip kör SPI.
Jag hade även lagt till möjligheten att kommunicera med controllern via USB (FT232) för att via PC enkelt ändra parametrar , ladda ner nya loggscheman etc.

När det gäller minnesanvändningen är det flera faktorer som spelar in:
hur ofta samplas data, hur mycket data, hur packas data?

[chille]

MicroSD är enklare att interface:a än ett USB-minne. Däremot har nog FTDI färdiga kretsar för att använda sig av USB-minnen. Jag skulle för övrigt också föredra ett FTDI-chip för USB-kommunikationen mot datorn.

Att mäta på en 4-20mA ingång är inte speciellt svårt. Oftast sätter man ett 250 Ohms motstånd och mäter spänningsfallet över detta. Då bör man få 1-5V (eller 0-5V om man kör 0-20mA). Med en högupplöst DA (typ 16bit) och en multiplexer borde ni kunna få fritt antal ingångar.

[AndLi]

mtp att µC ska göra så lite andra saker hade jag nog satsat på någon med inbyggd usb för datorinterfacet (säg en atmega32U4) och låtit den komma upp som en lagringsenhet för att få ut loggen från minneskortet och en serieport för att konfigurera den. Färdig kod för USB hittar du i LUFA projektet.

Datan hade jag, som jesse, lagrat på ett SD kort, de kan köra lite olika standarder, men enklast och utan licens är att köra via SPI. För att du via µC ska kunna skriva ner data i ett riktigt filsystem (fat32) som PC sen kan läsa, tar du hjälp av FatFS.

Sen ser du bara till att PC via USB inte skriver på minneskortet samtidigt som loggersnurran i µC vill göra samma sak.

Det du får är alltså en USB-minneskortsläsare som också kan skriva loggvärden till kortet standalone.

[TomasL]

Använder man en PIC32 får man USB2GO och färdiga USB-stackar från uChip, vilket ger en "problemfri" kommunikation med USB, uChip har även färdiga FAT-drivers för minneskort (dock ej CF i IDE mode)

[limpan4all]

Och se till att motståndet som ni använder som shuntmotstånd har en så låg Tc som bara kan köpas för pengar hela er praktiska noggranhet kommer att ligga i Tc (temperaturkooficienten) eller så måste ni se till att ni har aktiv kylning av motståndet (läs fläkt och konstant rumstemperatur).

[Zajber]

Ok, "längre perioder" är relativt . Men minst 1 månad iaf. Börjar man räkna på datamängden som krävs för 10 kanaler samplade med 8bitar i 1Hz blir det ganska mycket data. Men jag hade inte skrivit samplingshastigheten heller ...
Men

SD-kort var en bra idé, verkar inte allt för svårt att komma igång. Ska försöka läsa på lite om FAT32.

Inställningar via RS232 är nog inget för slutkunden så det mesta måste gå att göra via interface. Enkelhet för användaren och stabilitet är det viktigaste.

Apparaten kommer att stå i en ganska "jobbig" miljö med bitvis väldigt höga magnetfält och ojämn temperatur. Så därav rädslan för oavsiktliga resets.
Detta ska givetvis skyddas på bästa sätt under designen..

Ett senare bekymmer kommer bli att göra detta system GPRS-baserat också.
Där datan kan skickas via någon 3g/GPRS-modul med jämna mellanrum. Så slipper man åka för att kolla datan på plats, då det kan vara över 100mil enkel resa för att läsa av enheten.

[Nerre]

Beroende på hur värdena varierar så kan ju kanske datat komprimeras. Är värdena ganska stabila så kan ju nån form av RLL-kodning få ner mängden ganska mycket (är värden "17" 30 sampel i rad så talar man om att det är 30x17 (3-4 bytes beroende på hur man väljer att koda) istället för att lagra "17" 30 gånger (30 bytes).

Det går ju också kanske att välja att lagra "diffen" mot föregående sampel istället för värdet (om det är små variationer kring ett stabilt medelvärde).

[Zajber]

Också en bra idé. Värdena kommer dock att variera ganska mycket på ett dygn. Men inte så mycket under korta perioder (1-60sek) så då funkar nog "komprimeringen".
Jag tror dock vi ska börja den enkla vägen först och sedan bygga vidare med detta, alltså först lagra rå-data. Men det ska ju även läsas in i ett datorprogram (matlab, daisylab) så då funkar nog rådata enklast.

Jag måste dra iväg och skriva en rapport nu, jag återkommer på kvällen med några fler idéer.

[Nerre]

Ett annat sätt att komprimera om de varierar långsamt är ju att bara lagra när värdet ändras, och då lagra det med en tidsstämpel. Det blir lite som att få en vektorbild istället för en bitmapbild.

[sodjan]

I båda föreslagna metoderna för komprimering så är det ju enkelt
att i efterhand de-komprimera och skapa en kontinuerlig tidsserie.
Så att man lagrar på ett sätt i processorn betyder inte att Matlab
inte kan få en komplett serie.

[Nerre]

Om man komprimerar med tid och värde bara vid förändringar så blir det ju ett X-Y-diagram i princip och då får man ju fram en full kurva ändå.

Jag använder det rätt regelbundet i Excel (inte så mycket för att komprimera, utan för att manuella avläsningar ofta är svåra att göra med exakta intervall). Där får man då göra det som heter punktdiagram istället för det som heter linjediagram.

[Zajber]

Roligt med lite feedback!

Helt korrekt. Att bara ändra värdet när det skiljer sig från tidigare är ju ett enkelt sätt, och absolut inte något problem i matlab/daisylab senare. Nu blir storleken på filerna i första hand inte det jobbigast i detta projekt då vi förmodligen kommer köra ganska billiga SD-kort. Så vi tar storleksproblemet vartefter grundstommen har börjat byggas.

Vet någon vart man kan köpa PIC32 demo-boards billigt? Kanske med lite basic-moduler klara för att interfacea med koden. Typ, LCD, SD/MMC, RS232/USB och liknande. Så vi kan börja koda och sedan designa eftersom ser att saker funkar ihop på rätt sätt..
Jag skulle vilja komma igång så fort som möjligt så vi får grepp om hur mycket vi kommer att hinna och vilka extrafunktioner vi hinner implentera.
Såg att Olimex hade ett enkelt hyffsat billigt kort som heter PIC32-MX460. Men tittar gärna på alternativ för att hitta något lämplig start-plattform.