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.
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.
> 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.
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
