Sensor Node

[MathiasW]

Salut,

da ein gutes Bild mehr verwirrt als 1000 Worte, hier eine Darstellung meiner Idee. (Probleme mit der Forumssoftware - daher alsi Zip)

Die Sensor Breakouts sind einfache Sensoren, die mit dem Sensor Management Board verbunden sind. Ursprünglich hatte ich die Idee, diese beiden zu vereinen, inzwischen sehe da eher die Trennung. Andererseits hindert die Trennung niemanden daran, ein Breakout mit einem Management Board fest zu verheiraten.

Ein Sensor Management Board kann so viele Breakouts aufnehmen, wie der I2C Bus her gibt oder GPIO Pins verfügbar sind und einen UART Sensor.

Mit einem Fremdboard kommuniziert das Management Board via I2C oder UART, wobei ein einheitliches API verwendet wird, das noch zu definieren ist. (der PIC hat zwei I2C Busse, einen für die Kommunikation, einen für die Breakouts)

Idee: Der Code zur Auslese und Analyse des Sensors liegt im Sensor Management board. Das Fremdboard liest nur die Ergebnisse über I2C oder UART aus, braucht also kein Memory oder CPU für Auslese (einzeln oder periodisch) und Analytik. Die Auslese und Analytik eines Sensors hat einen entkoppelten Lebenszyklus als die Software des Fremdboards.

Alternativ kann das Management Board auch mit einem Seriellem Modem (Bluetooth, WiFi, LoRa) reden und Daten verschicken (nicht im Bild dargestellt)

Letztlich ist es die Realisierung eines abgewandelten V-Modells: Datenerfassung, Datenanalyse und Datennutzung sind logisch wie physisch getrennt.

Ich hoffe, ich konnte zur Verwirrung beitragen

Ciao, Mathias

[arduinopraxis]

Hallo Mathias,

vielen Dank für die graphische Darstellung deines Projektes.

Jetzt verstehe ich wie du die Sensor Boards und das Management Board verdrahten willst. Als Sensoren kannst du, falls du Grove-Stecker verwendest, viele Grove-Sensoren einsetzen. Und Sensoren mit I2C-Schnittstelle gibt es auch viele.

Ich habe kürzlich einen LDR mit I2C-Schnittstelle realisiert, inklusive Grove-Anschluss 


Mit deiner Lösung kann man jeden Sensor anschliessen solange man ein geeignetes Sensor Board hat.

Trotzdem sind noch Fragen unbeantwortet:
-Zielpublikum
-Anwendungsbeispiel
-Lösung wenn Sensoren weit entfernt

Bei der Realisierung von Sensor Breakouts kann ich dich gerne mit Ideen unterstützen.

Gruss
Thomas

[MathiasW]

Salut Thomas,
zu den Fragen:
- Zielpublikum: ich sehe zwei Gruppen:
  - die eine will sich nicht mit der low-level Firmware herumschlagen, sondern Messwerte nach einem bekannten Schema (API) auslesen

• Zielpublikum: ich sehe drei Gruppen:
   
  • die eine will sich nicht mit der low-level Firmware herumschlagen, sondern Messwerte nach einem bekannten Schema (API) auslesen. Auch hat man die Analyse hinreichend oft programmiert und will einfach die Ergebnisse ohne den Programmieraufwand. Auch sollen die Analysen immer mit der gleichen Mathematik errechnet worden sein
  • die andere will schlicht die Sensorsteuerung aus dem eigentlichen Hauptprozessor heraus halten. So kann man problemlos Sensoraktivitäten wie die zeitliche Steuerung der Auslese des Sensors in das Sensor Management Board auslagern
  • die dritte Gruppe (dazu zähle ich mich) will sich mit der Erstellung einer API beschäftigen. Generalisierte API sind eine recht interessante Aufgabe, die heutzutage stärker gefordert ist und leider in vielen Bereichen aus meiner Sicht aus dem Ruder läuft, da die Resourcen im Überfluss vorhanden sind. Beim Microcontroller muss man das effizienter gestalten
• Anwendungsbeispiel: Messwert Schulungs-Kit - warum liefern drei Temperatursensoren nicht den gleichen Wert? Wie genau misst mein Sensor - mehr die physikalische Seite als die Informatik
• Lösung, wenn Sensor weit entfernt: Das Sensor Management Board hat zwei UART ports. Wenn ich die I2C Schnittstelle zum Fremdboard als Konfigurations-Master nehme, kann ich diese beiden UARTs für Kommunikation frei konfigurieren. Ich kann also über Bluetooth auf kurze Distanz die Daten senden, via ESP32 WiFi nutzen und über LoRa Distanzen im km Bereich überbrücken.

Die GPIO Pins des Sensor Management Boards wollte ich als normale Stiftreihe auslegen und dann in der Grove-üblichen paarweisen Verbindung auf Grove Stecker legen mit gesondert markierten Grove Steckern für I2C und UART

Ciao, Mathias

[arduinopraxis]

Hallo Mathias,

vielen Dank für deine Erklärungen.

Dein Lösungsansatz mit der Trennung der einzelnen Funktion hört sich gut an und macht sicher Sinn, wenn man die Bedürfnisse der erwähnten Zielgruppen betrachtet.

Eine generalisierte API erleichtert dem Anwender den Einsatz seiner Sensoren.

Mit den drahtlosen Übertragungsmöglichkeiten Bluetooth, Wifi und LoRa stehen alle Möglichkeiten offen.

Die GPIO Pins auf Grove Stecker führen, erlaubt das sichere Anschliessen der Sensoren. Mein I2C LDR Board ist somit auch schon mit deinem System kompatiblel :-)

Ich kann dich gerne bei der Realisierung von Sensor-Boards unterstützen. Sobald ein PCB-Template für Sensoren besteht, kann die Community Breakout Boards realisieren 

Gruss Thomas

[achim]

Hallo Mathias
habe mir dein Bild angesehen. Wenn ich s richtig verstanden habe, nimmst du ein Board mit einem Prozessor drauf. Dieses Board wird mit dem I2C Bus mit dem Sensor Board verbunden. Je nach Typ der Sensoren oder Ankopplung kann man auch UART nehmen. Der Aufbau kommt mir sehr bekannt vor. Im Grunde mache ich es doch genauso. Habe eine Platine mit dem Prozessor drauf und viele andere Platinen mit Sensoren, Displays, LEDs oder anderes. Die Übertragung der Daten erfolgt mit dem I2C Bus. Führe noch zusätzliche Spannung (12V) und ein Int mit. Vcc und GND mehrfach. Entfernung bis 300m sind kein Problem. Bin auch an der Einbindung von WLAN und anderes dran. Eine einheitliche Lib ist noch das Problem. Wie stellst du dir das vor? Jeder Sensor hat unterschiedliche Adresse. Bei einigen sind sie auch gleich. Bei einigen müssen relativ viele Register gesetzt werden. Andere haben eine komplizierte Ansteuerung. Jeder Sensor und besonders Display ist teilweise sehr unterschiedlich.
Da ist noch einiges unklar bei mir.
Wahrscheinlich ist das wichtigste daran, einen Prozessot mit hoher Geschwindigkeit (als jetzt) zu nehmen, mehr Speicher und eine Anbindung an den PC. Klingt nach viel Arbeit.

achim

PS verwende lieber die deutschen Begriffe, mit den englischen komme ich mir immer so hilflos (dumm) vor.

[MathiasW]

Salut Achim,

der Sensor wird an das Sensor Management Board so angeschlossen, wie es der Sensor braucht. Dort wird auch die sensorspezifische Ausleselogik programmiert. Deren Lebenszyklus, also Programmanpassung etc. ist mit dem Sensor verbunden. Wenn I2C verwendet wird, dann  ist es der I2C Bus, der für die Sensoren reserviert ist.
Die Anbindung an das auslesenden Fremdboard geschiet über den zweiten I2C Bus oder UART (auf hat der PIC hier zwei UART).

Die Neuereung ist die API: Im Prinizip kann man das Sensor Management Board mit der jeweiligen Firmware des angeschlossenen Sensors laden und muss ishc nicht darum kümmern, wie dieser ausgelesen wird. AM Fremdboard setze ich dann nur die immer gleichen Befehle ab, um die Sensoranalysedaten abzufragen, nicht aber den Sensor selbst. Das macht das Sensor Management Board. Daher hatte ich urprünglich die Idee, dass jeder Sensor sein dediziertes Management Board hat. Das ist aber nicht sehr effizient und daher ist die aktuelle Idee, ein generalisiertes Management Board zu haben.

Der Aufwand ist die API und die Analysesoftware, die Sensorauslese ist meist gegeben.
Ciao, Mathias

[achim]

Hallo Mathias
sorry, verstehe wieder einiges nicht. Der Sinn des I2C Bus ist doch, das mehrere (bis ca. 115) Sensoren, Displays usw. an einem Bus betrieben werden können. Um einen Unterschied zu haben, hat (meistens) jeder Sensor eine eigene Adresse. Vom Prozessor oder wie du es nennst "Management Board" erfolgt das Auslesen der einzelnen Sensoren und die Ansteuerung von Displays, usw. Der BUS ist doch nicht für einen einzelnen Sensor reserviert, da ich ja verschieden Sachen mit dem BUS betreiben kann.
Mit einem "Fremdboard" kann ich verschiedene Daten auslesen oder verarbeiten, z.B. über HTERM auf dem Monitor darstellen.
Was bezeichnest du als "Sensoranalysedaten abfragen und nicht den Sensor selbst"? Mit dem Bus muss ich doch die Adresse des Sensors angeben und die Daten aus den Registern auslesen. Dadurch braucht doch jeder Sensor nicht ein eigenes Management Board. Dazu verwende ich die verschiedensten Sensoren und Anzeigen und nur ein Management Board. Muss dem Prozessor sagen wie er es machen soll oder welche Eigenheiten jeder Sensor hat. Kann mir zur Unterstützung auch noch andere Prozessoren nehmen, die einen Teil der Arbeit verrichten. Auch bei dieser Art muss ich für jeden Sensor spezielle Software (API ?) schreiben um es korrekt auszulesen und zu verarbeiten. Mit dem Bus kann ich auch verschiedene unterschiedliche Prozessoren koppeln. Das Sensorauslesen muss für jeden Sensor erstellt werden, mit allen Eigenheiten.

achim 

[MathiasW]

Salut Achim,

wir haben ein grundsätzliches Missverständniss:

Fremdboard: Das Board, das das ganze Sensorsystem nutzt. Das kann ein Arduino, ein chipKIT, ein Raspberry PI, PC oder irgendetwas anderes sein, was I2C oder UART spricht.

Sensor Management Board: Dieses Board beantwortet Sensoranfragen entsprechend der API Befehlsdefinitionen und führt diese aus. Zu den Aufgaben gehören die Auslese des eigentlichen Sensors, die Periodizität der Auslese und die Datenaufbereitung (Mittelwert über bestimmt Zeiträume, beschreibende Statistik wie Standardabweichung, Perzentile etc). Das Sensor Management Board kann (wird wahrscheinlich) ein EEPROM und/oder ein SD Kartenslot haben, um Daten und Einstellungen zu speichern. Alles das ist aber dem Fremdboard herzlich egal, da es nur die Informationen über den Befehlssatz der API abfragt. Das hat den Vorteil, dass ich mich am Fremdboard weder um die Auslese des Sensors noch um die Analyse der Daten kümmern muss. Daher ist die Programmierung des Sensor Management Boards eine Firmware, die ich am besten nicht anfasse und wenn, dann nur um Fehler zu korrigieren oder falls ich den angeschlossenen Sensor ändere.

Der PIC32MX hat ZWEI I2C Busse.
- DTWI0 (der erste I2C-Bus) redet mit dem Fremdboard. der Adressraum diese Busses wird nur von der Masteradresse des Fremdboards und den Slaveadressen des oder der Sensor Management Board(s) sowie weiterer an das Fremdboard angeschlossenen I2C Geräte genutzt
- DTWI1 (der zweite I2C-Bus) redet mit Sensoren, die über I2C ausgelesen werden. Hier ist das Sensor Management Board der Master und alle I2C-Sensoren sind Slaves

Der PIC32MX hat zwei UART Anschlüsse.
- UART0 redet mit dem Fremdboard
- UART1 redet mit Sensoren, die über UART ausgelesen werden

Was soll das Ganze? Nehmen wir eine Analogie: Ich will eine Datenbank benutzen um darin eine Reihe von Tabellen abzulegen. Ich will aber die Tabellenwerte bearbeiten und nicht in die Tiefen der Datenbank abtauchen. Dazu greife ich auf eine generische Datenbank-API zurück, die generalisierte Tabellenzugriffe erlaubt. Die Umsetzung dieser virtuellen, generischen Datenbank auf MS_SQL, ORACLE, MySQL, SQLite, DB2 wird von eben dieser API ausgeführt. So führt die Anforderung einer neuen Tabelle dazu, dass unter Oracle ein Tablespace generiert oder erweitert wird und die Tabelle dort abgelegt wird, während in DB2 die Tabelle in ihrem eigenen File abgelegt wird.
Genauso gehst Du auch vor, wenn Du in einem Programm den Befehl File->New ausführst. Auch hier verwendest Du ein einfaches API um eine komplexe Aktion im Hintergrund auszuführen. Und dabei interessiert es Dich nicht, wie die Datei angelegt wird, dass der Befehl auf SSD anders ausgeführt wird als auf HDD oder Cloud. An deinem Ende der API ist immer das gleiche Ergebnis: Ein Datei neu geöffnet und bereit.

Analog will ich das auf der Welt der Sensoren realisieren: Ich arbeite mit meinem Fremdboard und habe einen Satz von Sensor Management Boards mit angeschlossenen Sensoren, z.B. Temperatur, CCD-Lichtsensor, x/y/z Beschleunigungssensor). Wenn ich diese Sensoren an mein Fremdboard direkt anschließe, muss ich nun alle notwendigen Libraries für mein Fremdboard finden und auf die jeweilige Anschlussart anpassen. Dann muss ich die Auslese programmieren und die Werte speichern. Alles das frisst Speicher und CPU auf meinem Fremdboard. Und mit dem Wechsel auf ein anderes Fremdboard (von Arduino auf MSP430 Launchpad) beginnt alles von neuem.

Mit der API könnte das ganze aber so aussehen:

Code: [Select]

#include SensorManager.h
SensorManager SMB(I2C, 99); // baue ein Objekt SMB, verwende I2C und Adresse 99
temp = SMB.query(TempSens, SingleQuery); // Anfrage, den aktuellen Temperaturwert zu liefern
result = SMB.set(TempSens, Period, Millis, 1000, 20); // Setze die Messperiode auf 1 Sekunde (1000 Millis), Auslese alle 20 Millis), Fehler werde mit negativen Werten übergeben
tempavg = SMB.query(TempSens, PeriodAvgQuery); // Mittelwert der Messungen
tempstd = SMB.query(TempSens, PeriodStdQuery); // Standardabweichung der Messung
result = SMB.set(XYZaccel, getValues); // Synchrones Auslese der x,y,z Werte
xVal = SMB.query(XYZaccel, xValue); // Abfrage des x Wertes
yVal = SMB.query(XYZaccel, yValue); // Abfrage des y Wertes
result = SMB.set(CCDlight, BinWidth, 100); // Setze die Binweite des Spektrums auf 100 ns
rgbPeak = SMB.query(CCDlight,  BinValue, 123); // Lese den Binwert für Bin 123 aus
Diese Befehle kann ich dann auf jedem Fremdboard verwenden. Ich könnte (werde wahrscheinlich) auch die API parallel in Python aufbauen, wäre also nicht mehr an C++ gebunden.

Das Beispiel CCD zeigt besonders die Vorteile der API: Ein CCD (Charge Coupling Device) besteht aus eine Reihe von Lichtsensoren, typischerweise 128-4096. Dieser werden nach dem "Eimerkettenverfahren" ausgelesen. Diese Auslese erfordert ein sehr präzises Timing und muss für jedes Ausleseboard genau eingestellt werden und hängt vom Prozessor und seiner Taktfrequenz ab. Wenn ich das auf meinem Fremdboard realisiere, stehen mir heimelige Stunden im fahlen Licht des Oszilloskops bevor. Dann will ich den Arduino gegen einen MSP430 tauschen - und den gibt es dann auch noch in 8MHz, 16MHz und 25MHz. Mit dem Sensor Management Board interessiert mich das nicht, der Befehl ist der gleiche.

Als Analyse kann ich zum Beispiel einen FFT auf das Frequenzspektrum anwenden oder andere komplexe Analysen programmieren, bis der Speicher von 128 bzw. 256 kB des PIC voll ist. In der Zukunft kann ich mir auch aufwändiger Sensor Management Boards vorstellen, die auf der PIC32MZ Serie aufgebaut sind (200 MHz, 2 MB Speicher) aber das ist ferne Zukunftsmusik.

Für einen einfachen Temperatur-NTC ist die API und das Sensor Management fast schon Overkill. Sobald die Sensoren etwas anspruchsvoller werden, spielt die API ihre Vorzüge aus. Wenn dann noch die Statistikfunktionen dazu kommen, ist selbst ein einfacher Temperatursensor besser über die API ausgelesen. Außerdem  möchte ich gerne meine Zeit auf mein Programm  verwenden, statt herauszufinden wie ich den allseits bekannten LM75 auslese.

Ich hoffe, diese (leider recht lange) Exkurs hat Dir etwas geholfen. Es ist immer schwer, seine Ideen so zu formulieren, dass sie von Anderen verstanden werden. Diese Bringschuld liegt bei mir.

Ciao, Mathias

[achim]

Hallo Mathias
langsam kann ich deinen Gedanken folgen. Wahrscheinlich liegt ein Unverständniss von mir vor. Ich betrachte die Sache als reinen Bus mit I2C Sensoren und Prozessor. In dieser Ausführung muss alles angepasst und programmiert werden. Du machst mehr die andere Seite. Musst du dabei nicht auch das Auslesen betrachten? Man muss doch angeben mit welchem Sensor man arbeitet. Danach kommt die Verarbeitung in Form von Speichern, Auswertung und Berechnung auf verschiedenen Boards. Es kann auch eine graphische Darstellung oder andere Anbindung z.B. in ein Netz oder WLAN sein. Ist denn nicht die Anwendung am PC besser? Nehme als Beispiel das HTERM sehr gern. Das Programm ist nicht schlecht, leider gefühlte 10 Jahre als und nicht weiter entwickelt. Kann mir die verschiedensten Werte (als HEX) anzeigen lassen, und weiter? Ist nicht eine Maske besser die ich programmieren kann als Anzeige wie es brauche? Auf dem Handy wird es und bereits vorgemacht, nennt sich dort App. Bekomme Daten angezeigt, kann verschiedenes schalten usw.
Wo würdest du dein Fremdboard einordnen? Oder bleibst du beim Sensor Management Bord? Kommt nicht die Anbindung mit dem ESP8266 bzw. ES12 auch sehr gut, eignet sich doch sehr gut als Anbindung zum WLAN bzw. Router.
Da bin ich gespannt wie das weiter geht. Im Grund klingt es aber nach viel Arbeit.
Mache gern mit meinen Sensoren mit.

achim   

[MathiasW]

Salut Achim,

Deine Fragen sind mir lieber als ein einfaches "Alles klar" - denn sie zwingen mich dazu, die Idee zu hinterfragen und zu beschreiben, was mich inzwischen zu mehreren Änderungen bewogen hat.

Das Fremboard nenne is bewusst so, weil es ein Board ist. welches mir vollkommen fremd ist. Dem Anwender meines Sensor Management Boards ist es natürlich alles andere als fremd, denn es ist das Board, mit dem er arbeitet.
Fremdboard auch deshalb, welch ich gar nicht wissen will, was das für ein Board ist. Es muss nur entweder über I2C oder UART mit mir reden und damit nichts zu heiß wird, werden beide Schnittstellen 5V tolerant ausgelegt.
Die Firmware meines Sensor Management Boards muss natürlich wissen, was für ein Sensor an das Board angeschlossen ist. Im API habe ich auch vorgesehen, dass das Fremdboard anfragen kann, was denn für ein Sensor am SMB angeschlossen ist.

Vielen Dank für die Fragen - das hjat mir sehr viel geholfen

Ciao, Mathias

[arduinopraxis]

Hallo Mathias,

im Prinizip kann man das Sensor Management Board mit der jeweiligen Firmware des angeschlossenen Sensors laden und muss ishc nicht darum kümmern, wie dieser ausgelesen wird. AM Fremdboard setze ich dann nur die immer gleichen Befehle ab, um die Sensoranalysedaten abzufragen, nicht aber den Sensor selbst ...

Wirst du im Sensor Management Board jeweils die Firmware laden, die für den angeschlossenen Sensor nötig ist oder planst du einen Satz von "Bibliotheken" für die bekanntesten Sensoren mitzuliefern?

Wie wird ein Sensor abgefragt, der keine I2C-Schnittstelle hat? Bspw. ein DHTx oder ein analoger Sensor.

Gruss
Thomas

[boxtec-support]

Hi Thomas,

Wo dein Board, ich nenn es mal Sensor-Board, konkret eingesetzt wird, habe ich noch nicht verstanden.
Vielleicht kannst du mal einen konkreten Anwendungsfall schildern wo du z.Bsp einen Temperatursensor einsetzen willst. Ein Blockdiagramm würde vielleicht auch helfen.

Augenblicklich sehe ich nicht wer wo am Bus was machen soll

Soweit ich es verstanden habe, ist der Sensor Node ein PIC Mikro, an dem der Sensor angeschlossen ist und der dann von einem - nennen wir es Hostsystem - über I2C/UART über eine definierte API-Schnittstelle abgefragt wird.

Wiederum soweit ich es verstehe geht es darum, den eigentlichen Sensor mit Hilfe des Mikroprozessors gegenüber dem Hostsystem zu abstrahieren, sprich egal ob ich einen PT100, einen DS18B20 oder einen 10k Thermistor am Sensor Node dran habe, ich sende vom Hostsystem via UART z.B. Befehl 0x01 und erhalte die Antwort dass der angeschlossene Sensor der Art Temperatur ist (z.B. 0x20 oder 0x21 für einen kombinierten Feuchte/Temp Sensor) mit dem Befehl 0x02 erfrage ich dann einen Messwert in Grad Celsius vom Sensor Node.
Mir als Hostsystem Programmierer sind dabei die feinen Unterschiede der Abfrage zwischen PT100 und DS18B20 egal, ich kriege via UART/I2C auf den gleichen Befehl eine Temperatur in Celsius. Das verstehe ich hier als zentrale Idee.
(Die Befehle, Antworten u.s.w. oben sind natürlich frei erfunden und dienen nur der Erklärung, nicht dass ich den Eindruck erwecken will, ich hätte hier Insider Kenntnisse)

Sorry @Mathias wenn ich hier was falsch verstanden habe und Mist verzapft hab, das ist das was ich aus dem bisher diskutierten ableite/verstanden habe.

Aus der Erfahrung mit den (meist auf DS18B20 und DHTx1 basierten) Lösungen die ich betreibe sehe ich sowohl Vorteile wie Nachteile mit der Lösung von Mathias.
Einerseits machen z.B. die DS18B20 ganz selten mal Probleme auf dem Onewire-Bus und dann kommen krumme Messwerte raus. Das lässt sich mit Software auf dem Sensor Node sicher besser bekämpfen, als auf dem Hostsystem erstmal jeden Messwert auf Plausibilität prüfen zu müssen (z.B. wie weit ist die Distanz zum Median von anderen Messwerten). Hier kann der PIC im Sensor Node den Onewire Bus neu initialisieren und solange den letzten gültigen Messwert liefern bis der Sensor wieder mit dem Sensor Node reden kann. Das ist als Fähigkeit des Sensors (vom Hostsystem oder effektiv die Daten verarbeitenden System aus gesehen) nicht zu unterschätzen. Ist blöd wenn ein Innensensor -85.0°C liefert und die Heizung auf 100% anläuft obwohl draussen 37°C sind... Das gibt unangenehme Familiensitzungen in überhitzten Wohnzmmern.. 

Andererseits, bei Betrachtung eines Sensors der eh schon mit I2C läuft, hab ich dann zwei I2C Busse die über keinerlei Fehlererkennung (bei UART wenigstens rudimentäre) resp. Fehlerkorrektur verfügen und eine Platine mehr dazwischen die kaputtgehen kann. Ich implementiere auf dem Hostsystem die I2C Befehle des Sensor Node statt des Sensors - macht jetzt die Sache nicht wirklich einfacher. Klar man könnte auch UART verwenden und das ist auch überspitzt formuliert.

Wenn ich hier zuhanden Mathias zwei Anregungen anbringen dürfte, wären dies:
- (Optionale) Fehlererkennung/-korrektur - z.B. einen API Befehl der eine Checksumme des letzten gelieferten Messwerts sendet.
- Optische Isolation gegenüber dem Hostsystem (ich weiss Du hast hier eher kleinere Kaliber wie ein ESP8266 im Auge, aber ich sehe da eher einen ARM/MIPS Rechner à la RPi oder grösser und da wärs ev. schön die entsprechenden Ports zu schützen)
 
Grüsse - Christoph

[MathiasW]

Salut Christoph,

ich sehe meine Idee recht gut wiedergegeben. Zu den Kommentaren:
Ein Sensor, der jetzt schon I2C macht ist gut als Beispiel, um das System zu erklären. Aber leider auch die Tautologie an sich, so dass man sich fragen kann, was a das soll. Letztlich werde ich die I2C Sensoren einfach deshalb dabei haben, damit ich mit einer API alle Sensoren auslesen kann und nicht für einen I2C Sensor umstellen muss. Aber es hindert Dich nichts daran, neben dem Sensorboard einen I2C Sensor auf den Bus zu legen.
Fehlerkorrektur und anderes: Das ist genau der Punkt, wo ich die Stärke des SonsorNode sehe (bzw. SMB, wie ich ihn derzeit nenne): Ich kann Prüf- und Analyseroutinen definieren und damit den Sensor kalibrieren und prüfen. So kann ich mir vorstellen, dass ich einen Wertebereich übergebe und der SMB liefert einen Fehler, wenn der Sensor aus dem Bereich heraus wandert und eine andere Fehlermeldung, wenn er das mehrmals macht. Das alles fällt unter beschreibende Statistik und da habe ich eine 1200 Seiten Schwarte bei mir stehen vom Studium

Optische Isolation: Das erinnert mich an einen Sensor, den wir mal in der Physik gebaut haben: Da wurden Ströme im nA Bereich gemessen wobei die Messapparatur auf 30 kV lag. Da heben wir die Versorgungsspannung über IR-Laser eingestrahlt. Meinst DU Optokoppler oder richtig galvanische Trennung, also Lichtleiter?

Ciao, Mathias

[arduinopraxis]

Wiederum soweit ich es verstehe geht es darum, den eigentlichen Sensor mit Hilfe des Mikroprozessors

Aus der Graphik von Mathias hat das Sensor Breakout keine CPU integriert onboard.

Ich nehme aber an dass ein LDR, ein PT100 oder sonst ein analoger Sensor mittels kleinem Microcontroller oder einem passenden Wandlerbaustein "digital gemacht" werden und anschliessend über den I2C-Bus abgefragt werden.

Ein DS18B20 wird dann vermutlich über einen digitalen GPIO des Sensor Management Boards eingelesen.

Gruss
Thomas

[boxtec-support]

Hi Mathias,

Freut mich, dass ich der Sache soweit folgen konnte 

Optische Isolation: Das erinnert mich an einen Sensor, den wir mal in der Physik gebaut haben: Da wurden Ströme im nA Bereich gemessen wobei die Messapparatur auf 30 kV lag. Da heben wir die Versorgungsspannung über IR-Laser eingestrahlt. Meinst DU Optokoppler oder richtig galvanische Trennung, also Lichtleiter?

Ich meinte Optokoppler (die auch ganz schön galvanisch trennen, aber leider bei max 7kV versagen). Eigentlich hatte ich den typischen 4N25/4N35 im Sinn, aber ich sehe grad es gibt mittlerweile auch spezialisierte Logik-Optokoppler die vermutlich vieles einfacher machen. Ist auch nicht zwingend, aber wenn der Sensor an ein teures System drankommt kann das durchaus Sinn machen.

Grüsse - Christoph