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 User
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.
@ 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 ;-)
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...
@ 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.
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.
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.
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-cortex-m4-lpc4300-ohne/dp/2217598
@ 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.
> 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.
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.
Arc N. schrieb: > wir wissen ja weder etwas über Mit den Sensoren sollen vermutlich Temperaturen gemessen werden ;-)
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.
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 ;-()
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?
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.