Tipps analoger Datenlogger

Was kannst/willst/darfst du für den Logger bezahlen?

Schau dich mal hier um:
https://www.mikrocontroller.net/search?query=Datenlogger&forums[]=2


Wenn du einen PC zur Hand hast, kann der die Messung mithilfe eines 
USB-Multimeters übernehmen. Dieses muss allerdings schnell genug sein.

Für fertige Lösungen kannst du mal bei http://www.elv.de suchen.

Jan schrieb:
> ~100Eur, Gehaeuse etc mache ich selber, also im Prinzip sowas wie der
> hier:
> http://www.sparkfun.com/products/10216
> Nur bei dem bekomme ich nicht meine 1kSps/s in 4 Kanaelen...

Das Ding hat primär ein "Softwareproblem". 4*1Khz auf SD-Karte darf bei 
der Hardware kein Problem sein.
Auf den ersten Blick verwendet es zwei 512Byte Schreibpuffer in denen 
die ASCII kodierten Daten auf die SD Karte warten. Die kann im Worst 
Case 42,5ms zum Schreiben einer Seite brauchen, daraus ergeben sich 
deren Limits. Das passiert aber nur sporadisch, im Schnitt ist die Karte 
deutlich schneller als 512Byte/42,5ms (~12kB/s).

Wenn genug RAM frei ist, kann man einfach noch ein paar zusätzliche 
Schreibpuffer für 512B große Seiten einführen. Falls der RAM eher knapp 
ist, wäre es schlauer Rohdaten zu puffern, dann kommt man mit 5kB eine 
ganze Sekunde aus.

Gruß
Reinhard

gk schrieb:
> Alexander Schmidt schrieb:
>> mithilfe eines USB-Multimeters übernehmen.
> Das schafft weder Keithley noch HP und schon gar nicht für roundabout
> 100€.

Keithley oder HP schaffen das locker. Natürlich nicht für 100€.

http://www.meilhaus.de/index.php?id=22&user_produkte[PR]=226&L=0&cHash=f5a55f028a
Agilent 34411A
50 kS/s bei 4,5 Digits
1800€

Günstiger gehts hiermit:

http://www.reichelt.de/ME-REDLAB-1208LS/?ARTICLE=114235
8 single-ended oder 4 differentielle A/D-Kanäle
12 bit A/D-Wandlung
1,2 kS/s kontinuierlich (für alle Kanäle)
140€

https://www.distrelec.de/ishopWebFront/search/luceneSearch.do?dispatch=find&keywordPhrase=917235
16 single-ended A/D-Kanäle
12 bit A/D-Wandlung
100 kS/s kontinuierlich
250€

@  Jan (Gast)

>Vielen Dank fur eure Antworten! Das sieh schon alles ganz gut aus,
>leider muss es klein sein und batteriebetrieben, max.
>Zigarettenschachtelgroesse. Im Prinzip brauche ich nur ein paar Minuten,
>da muesste doch ein SPI-RAM
> and einem uC mit vier Wandlern doch
>einfacher und schneller sein als die Loesung mit SD-Karte,

Ja. 4x12Bitx3min*60*1ksps= 8,6 Mbit ~ 1Mbyte. Das kriegt man locker in 
einem SPI-Flash, die gibt es für 3-fuffzich. Wenn 10 Bit reichen tut es 
ein AVR mit seinem ADC, wenn man mit dem zeitversetzten Sampeln leben 
kann, sonst ein externen mit vier S&R Stufen, SPI-Anbinndung, fertig. 
Dazu bissel Software. Naja, keine große Kunst, aber an einem Tag ist das 
auch nicht gemacht.

Naja, uLog von 3 auf 4 Kanäle aufzubohren und den Timerwert von 50Hz auf
1Khz einzustelle, und die Pinzuweisung umzuändern dürfte 15 Minuten 
nicht
übersteigen inkl der paste/copy von VUSB wenn denn usb sein sollte.
VUSB mit RS232 Emulation, kein Filesystem, auch wenn dies möglich wäre.

Ansonsten gibt es ein 12bit ADC welcher 3diff oder 6 ADC Messungen 
gleichzeitig macht, wird über SPI angesteuert.

Ja, die HW kann 15ksps. Bei 3 Kanälen sind es max 5 Samples,
oder besser gesagt 1x weggeworfen und 4x integriert.
Es besteht auch die Möglichkeit eine externe Vref zu verwenden und 2 ADC
zu haben. Wenn man jedoch eine andere Pinbelegung macht (Hardware 
Änderung)
dann bekommt man auch 4 Kanäle + eventuell USB (VUSB).
Bei der HW von Sparkfun(Watterott) braucht man in der SW
nur den Timer (  TCNT1 ) zu ändern. Es fehlt zwar das integrieren, aber
ein einfaches "TCNT1 += -1000" sollte genügen anstelle von
  TCNT1 = 46965;//50Hz
um die Samplerate auf 1000µs (1Khz) zu setzen.
Wenn du 2ksps brauchst, dann sind es anstelle von -1000 eben -500 weil
2ksps eben ein Interval von 500µs sind. Wenn der Speicher dann voll ist
(theoretisch nach 11 Minuten) hört der Logger auf, bei den Angaben von
2 Stunden wären es aber nur 5 Minuten, kann aber sein daß die Angabe
von 2 Stunden auf eine 100 Hz Rate basiert (auskommentiert im Source)
und dann würde 10-11 Minuten bei 1Khz Samplerate wieder stimmen.

Im Sourcecode des uLog finden sich solche Zeilen:

1

void buffer_to_main(short page)

2

{    

3

//...

4

    PORTB |= (1<<CS);//CS hi   //buffer is written after this, takes 14mS

5

6

    delay_ms(14);

7

8

    PORTB &= 0xFE; //stat on

9

    delay_ms(20);

10

    PORTB |= 0x01; //stat off

11

}

Das kann man in der Form nicht stehen lassen, sonst läuft bei 1kHz der 
Puffer über, wenn im Flash eine Seite voll wird.

Wenn es wirklich 14ms dauert eine Seite zu beschreiben, laut Datenblatt 
sollten dem Flash 6ms reichen, muss der Puffer trotzdem noch ein wenig 
vergrößert werden. Der braucht aber jetzt schon 66B von 128B RAM.

Die HW schafft 1kHz sicher ohne Probleme, aber die FW braucht noch 
diverse Anpassungen.

Gruß
Reinhard

@  Reinhard R. (reinhardr)

>Wenn es wirklich 14ms dauert eine Seite zu beschreiben, laut Datenblatt
>sollten dem Flash 6ms reichen,

typisch oder maximal?

> muss der Puffer trotzdem noch ein wenig
>vergrößert werden. Der braucht aber jetzt schon 66B von 128B RAM.

Flash sollte/muss man sowieso seitenweise beschreiben, da braucht es 
Puffer für mindestens eine Seite.

>Die HW schafft 1kHz sicher ohne Probleme, aber die FW braucht noch
>diverse Anpassungen.

Ja, denn die ist nur Qick % Dirty zusammengestrickt, mit diversen 
Schönheitsfehlern und Stolperfallen. Und bei 1 Mbyte Daten sollte man 
sich auch über eine gescheite Formatierung bei der Ausgabe Gedanken 
machen. Wenigstens sowas ala CSV Format.

Falk Brunner schrieb:
> @  Reinhard R. (reinhardr)
>
>>Wenn es wirklich 14ms dauert eine Seite zu beschreiben, laut Datenblatt
>>sollten dem Flash 6ms reichen,
>
> typisch oder maximal?

Maximal; typisch waren es glaube ich 3ms.


>> muss der Puffer trotzdem noch ein wenig
>>vergrößert werden. Der braucht aber jetzt schon 66B von 128B RAM.
>
> Flash sollte/muss man sowieso seitenweise beschreiben, da braucht es
> Puffer für mindestens eine Seite.

Der Flashbaustein hat zwei 512B/528B große Schreibpuffer, von denen nur 
einer verwendet wird. Wenn man beide verwendet kann man die Daten 
kontinuierlich wegschreiben und kann dadurch auf "große" interne Puffer 
und Schreibdelays verzichten.


Gruß
Reinhard

Ich habe noch eine  Version von uLog.c gefunden. Ob sie kompilierbar 
ist,
keine Ahnung, eher nicht.
Ich habe den A25L016 Baustein genommen und dieser hat ganz
andere Commandocode als der von Sparkfun verwendete Atmel.
Es ist der modifizierte Sparkfun Code und war die Basis des aktuellen
Logger Implementation für den A25L016, bei dieser Version sind die
Codes aber noch für den Atmel Flash enthalten.