mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik 16bit 1kSPS 150Ch Datalogger gesucht


Autor: Norbi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich suche einen oder mehrere Datenlogger die man triggern kann. Diese(r) 
sollte(n) insgesamt 150 separate 16bit Kanäle über I²C aufnehmen und mit 
einem Zeitstempel indizieren können.
Und eben nicht mehr als 1000€ kosten.

Ich habe bislang leider nichts geeignetes gefunden. Somit habe ich 
folgende Fragen:

- Kennt jemand eine Fertiglösung, mit der man auf SD-Karten schreien 
kann
- Wenn nein, wie geht man ran, es selbst zu machen?

Ich habe schon ein paar FPGAs und DRAM-Bausteine gesichtet. Aber 
vielleicht kann mir jemand ein Kochrezept geben, damit ich das Rad nicht 
neu erfinden muss.

: Verschoben durch Moderator
Autor: Ghast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
6,66€ pro Kanal, dann mal viel erfolg.

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Norbi schrieb:
> ich suche einen oder mehrere Datenlogger die man triggern kann. Diese(r)
> sollte(n) insgesamt 150 separate 16bit Kanäle über I²C aufnehmen und mit
> einem Zeitstempel indizieren können.

Und diese 150 Kanäle laufen über wieviele I²C-Busse rein?

Kommt jeder Datenstrom auf einem Kanal oder wie ist dein insgesamt 
2.4MBd (+Protokoll-Overhead) Rohdatenstrom aufgeteilt?

Um den Datenstrom auf einer SD-Karte mitzuschreiben, wirst du einen 
Pufferspeicher benötigen, der schon mal größenordnungsmäßig 100ms 
überbrückt.

Autor: Falk Brunner (falk)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
@ Norbi (Gast)

>ich suche einen oder mehrere Datenlogger die man triggern kann. Diese(r)
>sollte(n) insgesamt 150 separate 16bit Kanäle über I²C aufnehmen und mit
>einem Zeitstempel indizieren können.

Was heißt das GENAU? Soll der Logger nur digitale I2C EIngänge haben und 
über diese von externen ICs die Daten mit 1ksmps auslesen und speichern?
Bei einer konstanten Abtastrate braucht man keine Zeitstempel, da reicht 
es, einmalig die Startzeit zu speichern.

>Und eben nicht mehr als 1000€ kosten.

Wird eng.

>- Kennt jemand eine Fertiglösung, mit der man auf SD-Karten schreien
>kann                                                        ^^^^^^^^

NEINNNNN!!! ;-)

>- Wenn nein, wie geht man ran, es selbst zu machen?

Man nehme einen uC mit ausreichend (externem) Speicher, denn eine 
SD-Karte kann mehrere hundert Millisekunden Pausen einlegen. Der 
Speicher sollte den vollen Datenstrom für mindesten 500ms puffern 
können. Der uC liest die Sensoren aus und schreibt die Daten in den 
Speicher, der als FIFO arbeitet. Eine andere Funktion im uC liest 
diese Daten und schreibt sie auf die SD-Karte. Bei den Datenraten ist 
ein 32 Bit uC mit Hardware SD-Interface (SDIO) sinnvoll.

Sind das WIRKLICH 150 einzelne I2C Busse oder nur 150 Sensoren, die an 
deutlich weniger als 150 I2C Bussen angeschlossen sind?

>Ich habe schon ein paar FPGAs und DRAM-Bausteine gesichtet.

Und ich hab schon mal die Queen Marry II gesehen, bin aber trotzdem noch 
eine totale Landratte ;-)

Autor: Norbi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Antworten.

Es sind 150 einkanalige bzw. 50 dreikanalige digitale Sensoren, die 
direkt den I²C-Bus nutzen. Für 16 bit bei 1 kSample bedeutet das für die 
dreikanaligen Sensoren einen Datenstrom von 46 kbps je Sensor und 
insgesamt 2,4 Mbps.

Ich habe schon mal mit einem Teensy 3.2 größere Datenströme auf eine 
SD-Karte geschrieben, und weiß grob um die Tücken, die damit verbunden 
sind...

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Norbi (Gast)

>Es sind 150 einkanalige bzw. 50 dreikanalige digitale Sensoren, die
>direkt den I²C-Bus nutzen.

Schön, aber sind die allen an EINEM I2C Bus angeschlossen? Eher nicht, 
denn der schafft die Datenrate sicher nicht.

Eine Handvoll I2C Busse kann man vielleicht noch in Software emulieren, 
bei mehr geht auch einem schnelleren uC irgendwann mal die Puste aus 
bzw. der Bus ist einfach zu langsam. Dann braucht man ein FPGA, das kann 
sehr viele I2C Busse echt parallel einlesen.

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Norbi schrieb:
> ... den I²C-Bus nutzen.
> ... insgesamt 2,4 Mbps.

Zu den 2,4 Mbps kommt noch der Protokolloverhead dazu.
Selbst im High speed mode (3.4 Mbit/s) wird das auf einem Bus wohl 
kaum etwas.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Norbi schrieb:

> ich suche einen oder mehrere Datenlogger die man triggern kann. Diese(r)
> sollte(n) insgesamt 150 separate 16bit Kanäle über I²C aufnehmen und mit
> einem Zeitstempel indizieren können.

Welche Datenrate erwartest du?

Komisch dass immer diese komischen "Suchenden" den entscheidenden 
Knackpunkt nicht selber finden und gleich im ersten Posting 
mitspezifizieren können.

Ich habe da immer den starken Verdacht, dass es sich dabei nur um 
TrafficGenerator-Droiden handelt.

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Norbi schrieb:
> Kennt jemand eine Fertiglösung

Nicht billig aber gibt es:

http://sine.ni.com/nips/cds/view/p/lang/de/nid/212723

> wie geht man ran, es selbst zu machen

Falls 14-Bit reichen gäbe es eine sehr günstige Lösung:

EFM8LB12F64E-QFP32 hat 20 Channel mit je 40 kSPS und I2CF+ mit 3.4 Mbps 
und kostet 1,50

Davon also 8 Stück

Für das SD Card Loggen kann man z.B. ein billiges Dual-Core Board 
nehmen. Ein Core holt über I2CF+ die Daten ins RAM und der andere Core 
loggt:

http://de.farnell.com/nxp/om13027-598/eval-board-c...

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Lothar (Gast)

>Nicht billig aber gibt es:

>http://sine.ni.com/nips/cds/view/p/lang/de/nid/212723

Der OP will nicht 150 analoge Eingänge messen sondern die Sensordaten 
von 150 ICs auslesen.

Autor: ягт ден троль раус (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> 150 Kanaele zu 16Bit
> Und eben nicht mehr als 1000€ kosten.

Sportlich.
Du arbeitest die 200+ Stunden Entwicklung gratis, ist schon klar, aber 
von welcher Stueckzahl reden wir denn ?
Bei einem Einzelstueck waere ich von minestens einer Null hintendran 
mehr ausgegangen, mit bezahlter Arbeit allerdings.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> @ Norbi (Gast)
>
>>Es sind 150 einkanalige bzw. 50 dreikanalige digitale Sensoren, die
>>direkt den I²C-Bus nutzen.
>
> Schön, aber sind die allen an EINEM I2C Bus angeschlossen? Eher nicht,
> denn der schafft die Datenrate sicher nicht.
>
> Eine Handvoll I2C Busse kann man vielleicht noch in Software emulieren,
> bei mehr geht auch einem schnelleren uC irgendwann mal die Puste aus
> bzw. der Bus ist einfach zu langsam. Dann braucht man ein FPGA, das kann
> sehr viele I2C Busse echt parallel einlesen.

Aktuelle Controller ala STM32F4/F7/L4, Renesas RX oder PIC32MZ schaffen 
bei weitem genug Durchsatz. Die RX63 hätten bspw. bis zu 13 + 4 I²C. Da 
bräuchte es mit genügend PCA9548A 8:1-I²C-Multiplexern gerade mal zwei 
Controller (nicht nachgeschaut, ob die I²Cs ohne Überschneidungen an die 
Pins gemappt werden können) ohne (falls das der Bus mitmacht) die 
Multiplexer kaskadieren zu müssen...
Anderer Ansatz wäre vielleicht, wir wissen ja weder etwas über den 
Gesamtaufbau, die Buslängen, noch ob alle Sensoren gleichzeitig 
messen/abgefragt werden sollen, n Sensoren an einen Controller mit 
Software-I²C zu hängen und die Daten von dort über was anderes als I²C 
zur "Zentrale" zu schicken.

Autor: m.n. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Arc N. schrieb:
> wir wissen ja weder etwas über

Mit den Sensoren sollen vermutlich Temperaturen gemessen werden ;-)

Autor: so ein Gast (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Nun, bei Temperaturen braucht man wohl kaum sinnvoll 16 Bit und vor 
allem keine Messrate von ... hast noch nicht gesehen!
Zeig mir mal eine einzige sinnvolle Anwendung, wo Temperaturen derart 
dynamisch sind und dann der Sensor nicht das Messergebnis komplett 
verfälscht.

Autor: so ein Gast (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
so ein Gast schrieb:
> Nun, bei Temperaturen braucht man wohl kaum sinnvoll 16 Bit und
> vor
> allem keine Messrate von ... hast noch nicht gesehen!
> Zeig mir mal eine einzige sinnvolle Anwendung, wo Temperaturen derart
> dynamisch sind und dann der Sensor nicht das Messergebnis komplett
> verfälscht.

Ok, sorry, dee OP schrieb nichts von schnell, sorry!
Da sind wohl die Gäule mit mir durchgegangen ;-()

Autor: m.n. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
so ein Gast schrieb:
> Nun, bei Temperaturen braucht man wohl kaum sinnvoll 16 Bit und vor
> allem keine Messrate von ... hast noch nicht gesehen!

Doch, habe ich gesehen. Aber kennst Du alle Einwohner von Pappenheim?

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so ein Gast schrieb:
> so ein Gast schrieb:
>> Nun, bei Temperaturen braucht man wohl kaum sinnvoll 16 Bit und
>> vor
>> allem keine Messrate von ... hast noch nicht gesehen!
>> Zeig mir mal eine einzige sinnvolle Anwendung, wo Temperaturen derart
>> dynamisch sind und dann der Sensor nicht das Messergebnis komplett
>> verfälscht.
>
> Ok, sorry, dee OP schrieb nichts von schnell, sorry!
> Da sind wohl die Gäule mit mir durchgegangen ;-()

Nicht im ersten Text, aber später
> Für 16 bit bei 1 kSample bedeutet das für die dreikanaligen Sensoren einen
> Datenstrom von 46 kbps je Sensor und insgesamt 2,4 Mbps.

1 kS/s ist noch relativ langsam, je nach Anwendung...

http://www.dantecdynamics.com/hot-wire-and-hot-film-probes
Constant Temperature Anemometry

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.