boxtec Forum
Microcontroller => Sensors => : MathiasW May 08, 2017, 06:49:55 PM
-
Salut,
ich habe aufgrund einiger Artikel und Diskusionen im Netz die Idee, ein Sensor-Shield oder Breakout zu bauen. Dabei habe ich aber mimmer wieder das Problem, dass ich auf dem Prozessor die jeweiligen Protokolle des Sensors implementieren muss und mir dann recht schnell die Puste ausgeht. Ausserdem hätte ich gerne eine einheitliche Art, die Sensoren auszulesen.
Nun bin ich auf die Idee gekommen, ein SensorNode zu definieren, welches folgende Eigenarten hat:
- Eine SensorNode für jeden Messbereich (z.B. SensorNode-Temperatur)
- EEPROM für Datenspeicherung und Analyse
- definierte IO Ports (RX,TX,SCK,MOSI,MISO,SS,SDA,SCL,Vcc,GND => 10pol Wannenstecker?) - 5V tolerant
- PIC32MX250 prozessor (28-SSOP) mit SensorNode Firmware
- update nur über PICKIT Schnittstelle
- I2C, SPI und UART interface/API
- Messwertanalyse auf dem Prozessor
- API zur Messwertauslese
Wenn jemand Lust hat, dabei mitzuwirken, dann ist er herzlich eingeladen. Meine Idee ist noch ganz am Anfang, bin also bereit, alles komplett umzuändern.
(SensorNode -> HelveVeSens ;) )
Ciao, Mathias
-
Hallo Mathias,
Sehr spannende Idee. Ich bin an einem ähnlichen Projekt, möchte aber IP-Netzwerke zum Transport nutzen, Sicherheit von Anfang an einplanen und die Möglichkeit von Updates "over-the-air" oder "over-the-wire" haben.
Ich brauche daher eine etwas leistungsfähigere Plattform und hab mich für den wireless Teil für den ESP8266 entschieden. Ein erstes Board mit dem ESP8266-ESP01 arbeitet hier bereits recht gut (aber wacklig), leider ist mein Sketch nun bereits zu gross für Flash Updates über das Netzwerk und ich musste auf den ESP8266-ESP12 umsteigen. Da hab ich grad eben meine bestellten PCBs erhalten die nun in den nächsten Tagen getestet werden sollen:
(http://forum.boxtec.ch/index.php?action=dlattach;topic=3272.0;attach=1140;image)
In einem zweiten Schritt möchte ich mich an ein Board mit Ethernet Schnittstelle wagen, da hat Microchip die letzten Wochen einige interessante Produkte rausgebracht die ich mir noch näher ansehen möchte:
http://www.microchip.com/design-centers/ethernet/ethernet-devices/technology/gigepack (http://www.microchip.com/design-centers/ethernet/ethernet-devices/technology/gigepack)
Am Ende werde ich aber wohl den Weg des geringeren Widerstands mit einer minimalen openWrt Plattform gehen, die Verlockung des schnellen Erfolgs (und des tiefen Preises für ein minimales Modul) sind da wohl zu gross.
Bin aber auch sehr gespannt auf die HelveSense Idee und werde gerne wo ich kann mithelfen.
Viele Grüsse - Christoph
-
Salut Christoph,
die Idee des SensorNode ist es, die gesamte Messwertverarbeitung zu übernehmen und über eine einheitliche API anzubieten. Das hindert Dich nicht daran, diese dann über einen ESP32 (daher UART Schnittstelle) auszulesen. Inzwischen denke ich an zwei Wannenstecker mit 2x3 Pins: Einen mit rx,tx,sda,scl,GND,Vdd und einen mit Mosi, Miso, SCK, SS, GND, VDD in der Anordnung wie beim Arduino ISP.
Es gibt übrigens auch einen chipKIT bootloader, der statt USB den UART verwendet, so dass man auch darüber die Firmware des SensorNode vom ESP32 aus updaten könnte.
Ciao, Mathias
-
Hallo
finde die Idee damit sehr gut. Vielleicht ist auch was für mich dabei. Bin auch gerade am ESP12 dran. Möchte aber die Version NodeMCU nutzen. Ist schon von 5V auf 3V gesetzt und hat einen USB Anschluss. Die Daten vom ESP12 sind richtig gut. Bin gespannt
achim
-
Salut,
weiteres Grübeln hat mich nun dazu bewogen, nur zwei Interfaces zu unterstützen: I2C und UART. Der Grund liegt darin, dass in der 28-pin Version des PIC32 die beiden UART und der SPI einen gemeinsamen Pin haben. Das kann ich am Chip lösen, wenn ich die Kontrolle habe, nicht aber, wenn ich einen UART zur Kommunikation frei haben muss. Die Alternative wäre, dass ich den 44-pin Chip verwende, der aber schwerer zu löten ist. Zum Start daher erst einmal die I2C/UART Variante.
Als ersten Sensor will ich Temperatursensoren verwenden. Hat jemand eine guten Vorschlag? Auf dem SensorNode-T will ich mehrere Sensoren vorsehen.
Ciao, Mathias
-
Hallo Mathias,
Als ersten Sensor will ich Temperatursensoren verwenden. Hat jemand eine guten Vorschlag? Auf dem SensorNode-T will ich mehrere Sensoren vorsehen.
Ich denke für Temperatur alleine kommt man um den bewährten DS18B20 fast nicht herum. Wenns genauer werden soll ist wohl immer noch der traditionelle PT100 die erste Wahl. Wenn Feuchte ins Spiel kommt sind die Si7021 chips recht populär, aber auch die oberen der DHT-Reihe (33 und 44) leisten bei mir seit Jahren sehr gute Arbeit.
Grüsse - Christoph
-
Hallo Mathias
Nun bin ich auf die Idee gekommen, ein SensorNode zu definieren, welches folgende Eigenarten hat:
Eine SensorNode für jeden Messbereich (z.B. SensorNode-Temperatur)
EEPROM für Datenspeicherung und Analyse
definierte IO Ports (RX,TX,SCK,MOSI,MISO,SS,SDA,SCL,Vcc,GND => 10pol Wannenstecker?) - 5V tolerant
PIC32MX250 prozessor (28-SSOP) mit SensorNode Firmware
update nur über PICKIT Schnittstelle
I2C, SPI und UART interface/API
Messwertanalyse auf dem Prozessor
API zur Messwertauslese
Das Projekt hört sich gut an.
Für mich stellen sich folgende Fragen:
-Zielanwendungen
-Baugrösse
-Wie sieht es mit der Spannungsversorgung aus? Batterie, Lipo oder doch via USB?
Sensor Nodes baue ich bekanntlich schon seit etlichen Jahren. Dabei müssen die Nodes klein und sparsam mit Stromverbrauch sein.
Dein Sensor Node hört sich fast wie eine "eierlegende Wollmilchsau" an ;)
Für einen Temperatursensor ist die Lösung zu komplex.
In der Praxis liegen die Messpunkte für Temperatur-Sensoren meist weiter auseinander. So ist es auf jeden Fall in meinem Haus/Garten.
Ich würde auf einen kleinen, schlanken Sensor Node tendieren der maximal 2 oder 3 Eingänge hat, die auch unterschiedlich sein können. Ich habe beispielsweise in meinem Keller einen Sensor Node mit PIR, Temp und LDR.
Bei deinem Projekt beteilige ich mich aber gerne und bringe meine Ideen und Erfahrungen ein.
Gruss
Thomas
-
Als ersten Sensor will ich Temperatursensoren verwenden.
Ich empfehle die DS18B20 oder dann integrierte Umweltsensoren wie DHT33 oder einen SHT3x von Sensirion.
Diese integrierten Sensoren messen Temperatur und Luftfeuchtigkeit.
Neu ist auch der BMP280 ein spannendes Bauteil das zusätzlich noch Luftdruck messen kann.
PT100-Sensoren sind im Maschinenbau weit verbreitet und kosten natürlich etwas mehr.
Gruss Thomas
-
Hallo Mathias,
die Idee des SensorNode ist es, die gesamte Messwertverarbeitung zu übernehmen und über eine einheitliche API anzubieten.
Wieso machst du nicht einfache und kompakte Sensor Nodes und ein zentrales Gateway-Board für die Messwertverarbeitung?
Das Gateway könnte auch ein HAT für RPi oder ähnlich sein. Mit einem RPi kannst du dann auch Node-Red und MQTT nutzen.
Mit diesem Ansatz kann man unterschiedliche Sensor Node, auch solche mit ESP12 verwenden. Das habe ich so bei mir im Einsatz. Sensor Node mit RFM12B, RF-Modulen inkl. den Empfängermodulen. Meine Raspi empfangen die Daten und verarbeiten diese mit MQTT. Zusätzlich Emoncms und eine Instanz der Homeautomation-Lösung Home Assistant.
Gruss
Thomas
-
Salut Thomas,
der aktuelle Entwurf des PCB läuft langsam darauf hinaus. Der generische Teil gruppiert sich auf einer Seite und kann problemlos abgetrennt werden und als eigenes Gateway mit Anaylsefunktion programmiert werden. Wenn ich es als Hat aufsetzen will komme ich aber langsam nicht mehr um den TQFP-44 Chip herum, was ich aber vermeiden wollte. Es wird dann wohl darauf hinaus laufen, dass der SensorNode nur via UART und I2C angesprochen werden kann, da SPI und UART sich Pins teilen.
Ein Pi-Hat wird viel PCB-Fläche für den Anschluss verbrauchen. Wäre gerne innerhalb von 5x5 cm geblieben.
Ciao, Mathias
-
Hallo Mathias,
der aktuelle Entwurf des PCB läuft langsam darauf hinaus. Der generische Teil gruppiert sich auf einer Seite und kann problemlos abgetrennt werden und als eigenes Gateway mit Anaylsefunktion programmiert werden.
OK, Trennung von Node-und Gateway-Funktion macht Sinn.
Wenn ich es als Hat aufsetzen will komme ich aber langsam nicht mehr um den TQFP-44 Chip herum, was ich aber vermeiden wollte. Es wird dann wohl darauf hinaus laufen, dass der SensorNode nur via UART und I2C angesprochen werden kann, da SPI und UART sich Pins teilen.
Wie willst du Daten von einem Sensor-Node einlesen wenn dieser im Keller oder im Garten platziert ist. Ist da ein Buskabel mit seriellem Bus die beste Lösung?
Planst du den alle Sensor Nodes über serielle Bus abzufragen?
Ein Pi-Hat wird viel PCB-Fläche für den Anschluss verbrauchen. Wäre gerne innerhalb von 5x5 cm geblieben.
50x50mm ist nicht wirklich die optimale Lösung für ein Pi-Hat.
Ich würde für das Gateway die PCB-Grösse nutzen die Sinn macht. Bei 50x50mm geht es wohl um die PCB-Kosten.
Gruss
Thomas
-
Ich bin an einem ähnlichen Projekt, möchte aber IP-Netzwerke zum Transport nutzen, Sicherheit von Anfang an einplanen und die Möglichkeit von Updates "over-the-air" oder "over-the-wire" haben.
Ich brauche daher eine etwas leistungsfähigere Plattform und hab mich für den wireless Teil für den ESP8266 entschieden.
Drahtlose Sensor Nodes mit ESP8266 ermöglichen auch viele Anwendungen. Ich habe auch einige drahtlose Nodes, die über USB-Netzteil versorgt werden und spezifische Sensoraufgaben übernehmen. Die Daten können dabei direkt an mein Emoncms oder an einen MQTT-Broker übermittelt werden.
Dazu verwende ich die kleinen Wemos D1 Mini - Module (https://www.wemos.cc/product/d1-mini.html (https://www.wemos.cc/product/d1-mini.html)).
Die Module sind so günstig, da lohnt sich fast kein eigener Aufbau eines PCB. Ich nutze für die Wemos eigene Shields für die saubere und stabile Anschlusstechnik.
Gruss
Thomas
-
Ich bin an einem ähnlichen Projekt, möchte aber IP-Netzwerke zum Transport nutzen, Sicherheit von Anfang an einplanen und die Möglichkeit von Updates "over-the-air" oder "over-the-wire" haben.
Ich brauche daher eine etwas leistungsfähigere Plattform und hab mich für den wireless Teil für den ESP8266 entschieden.
Drahtlose Sensor Nodes mit ESP8266 ermöglichen auch viele Anwendungen. Ich habe auch einige drahtlose Nodes, die über USB-Netzteil versorgt werden und spezifische Sensoraufgaben übernehmen. Die Daten können dabei direkt an mein Emoncms oder an einen MQTT-Broker übermittelt werden.
Dazu verwende ich die kleinen Wemos D1 Mini - Module (https://www.wemos.cc/product/d1-mini.html (https://www.wemos.cc/product/d1-mini.html)).
Die Module sind so günstig, da lohnt sich fast kein eigener Aufbau eines PCB. Ich nutze für die Wemos eigene Shields für die saubere und stabile Anschlusstechnik.
Gruss
Thomas
Hi Thomas,
Die ESP8266 und darauf basierende Produkte wie die Wemos sind grade für zuhause hervorragend geeignet. Einzig die etwas geringe Reichweite ohne externe Antenne begrenzt den Spass etwas.
Da mein Projekt in einem professionellen Umfeld arbeiten soll, gewinnen auch Dinge wie eine CE Zertifizierung an Stellenwert. Daher hab ich mich nach langem Überlegen für den Dragino MS14S entschieden und bin nun dran eine eigene OpenWrt basierende Firmware zu braten. Diese soll unter anderem auch Zugriff auf verschiedene Firmware Images für den integrierten ATmega haben, so dass an den Schraubklemmen so gut wieder jeder Sensor für den ich eine Firmware vorbereitet habe angeschlossen werden kann und es nicht nur auf Temperatur begrenzt bleibt.
Aber für meine eigenen kleinen Projekte bleibe ich bei dem ESP8266, jedoch nur noch bei den grösseren oder anders gesgt nicht mehr ESP01.
Grüsse - Christoph
-
Salut,
ich habe mit "SensorNode" wahrscheinlich den falschen Namen gewählt, da "Node" wohl Netzwerk/WLAN etc assoziiert. Die Platine soll in direktem Weg via I2C/UART mit einem Verbraucher reden. Ziel ist es, eine einheitliche SensorAPI zu bieten. An den I2C oder UART kann ich dann Arduino, chipKIT, Raspberry, ESP32, PC, "The Machine" hängen. Die Rechenkraft des Prozessors will ich nutzen, um den Sensor zu kalibrieren, Analysen laufen zu lassen etc. Dazu werde ich auch ein EEPROM einbauen, was dann auf dem zweiten I2C Bus liegt, damit es keine Überschneidungen gibt, wenn mehr als eine Node auf einem I2C bus liegen. Den Prozessor kann ich auch auf eine freie I2C Addresse programmieren, so dass ich recht viele Nodes auf den Bus legen kann.
Über UART kann ich natürlich jederzeit einen ESP zum senden anhängen...
Für I2C und UART brauche ich eigentlich nicht den ganzen PI-bus, was wieder eine kleinere Platine ermöglicht. Wenn ich Grove Kabel verwende, kann ich auch einen einfachen PI-Adapter bauen.
Ciao, Mathias
-
Hallo Mathias,
ich habe mit "SensorNode" wahrscheinlich den falschen Namen gewählt, da "Node" wohl Netzwerk/WLAN etc assoziiert.
Unter Sensor-Node verstehen die meisten wohl etwas anderes. So auch ich.
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
Gruss
Thomas
-
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
-
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 ;)
(https://c1.staticflickr.com/5/4157/34678888296_20fcb7e3cf_d.jpg)
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
-
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
-
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
-
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.
-
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
-
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
-
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:
#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
-
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
-
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
-
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
-
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.. ;D
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
-
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
-
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
-
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
-
Hallo Mathias
danke für die Blumen. War mir gar nicht bewusst das ich solche Fragen stelle. Hatte eher gedacht das ich dich nerve.
Werde dann mal weiter zu dieser regen Diskussion beitragen.
Thomas fragt nach analogen Sensoren. Kann dazu einen Vorschlag machen. Habe ein Board gebaut, das mit 0(4)-20mA und 0-10V arbeitet. es beinhaltet die komplette Erzeugung der Spannungen und Ströme, die Auswertung, die Eichung in sehr engen Grenzen, Umrechnung und Anzeige, Umsetzung auf den I2C Bus und Ausgabe von 0-20mA und 0-10V. Es kann bis zu 4 verschiedenen Industriesensoren gleichzeitig bearbeiten. Durch die Ausgabe kann ich auch externe Ausgaben ansteuern.
Zur Trennung. Wozu über Optokoppler gehen. Habe auch eine Platine dazu gebaut. Es verwendet einen ADUM15?? und trennt den I2C Bus total ab, z.B. (soll) Netzspannungsfest. Es geht in beide Richtungen. Zusätzlich hat die Platine noch eine Trennung für 5V und 12V und einen Int als Rückgabe. Das gleich müsste es auch für UART geben. Damit müsste es möglich alles zu trennen. Meine Platine ist erprobt (ausser 230V - habe schiss davor) und funktioniert ohne Probleme.
Zur Betriebsspannung. Habe schon mit Christoph darüber diskutiert. Bleibe als Bus bei 5V. Damit ist der Strom einiger massen beherschbar. Verwende ich einen 3,3V Sensor kommt ein Pegelwandler mit den BSS138 dazu. Mehrfach verwendet und geht sehr gut.
Das einzige Problem was ich so sehe, sind die gleichen Adressen bei einigen ICs. Es gibt dazuauch ICs die das Trennen. Habe ich zu liegen aber noch nicht angewendet.
Vergest die Stromversorgung nicht. Soll nicht gerade 230V frei auf der Platine liegen, aber trotzdem genug Strom bringen. Habe SNT mit 1,5A, 3A, 5A und 10A zu liegen
Das wars erstmal von mir. Vielleicht was bei für euch.
achim
-
Hallo Mathias,
nach der grossen Diskussion bei der Vorstellung des Projektes ist es nun wieder etwas ruhiger
;)
Gibt es schon erste Bilder oder Prototypen?
Welche Boards/PCB wirst du zuerst erstellen?
Gruss
Thomas
-
Salut Thomas,
ich habe das Wochenende erst einmal in Garten verbracht, der dringend unserer Fürsorge bedurfte.
Ich arbeite derzeit an der API Definition und plane als erstes einen einfachen Sensor (Temperatur) und einen komplexen Sensor aufzubauen. Als komplexen Sensor habe ich mir den TCD1304 ausgesucht, der nicht so der schon tausendmal genutzte Sensor ist.
Parallel bau ich derzeit meine Flotte an Robotern weiter aus und kämpfe gegen das wachsende Chaos (2. Hautpsatz der Thermodynamik) an ...
Ciao, Mathias
-
Hallo Mathias,
ich habe das Wochenende erst einmal in Garten verbracht, der dringend unserer Fürsorge bedurfte.
Ja, das muss auch sein.
Aber anschliessend kann man ja wieder mit dem Notebook auf die Terrasse sitzen und codieren oder PCB entwickeln ;)
Ich arbeite derzeit an der API Definition und plane als erstes einen einfachen Sensor (Temperatur) und einen komplexen Sensor aufzubauen
Hört sich gut an.
Wirst du für das Sensor Management Board ein bestehendes Board verwenden oder wird dieses auch neu entwickelt?
Dann bin ich gespannt auf die ersten Resultate ;)
Gruss
Thomas
-
Hallo Mathias,
wie entwickelt sich dein Projekt? Bist du schon ein Stück weitergekommen?
Gruss
Thomas
-
Salut Thomas,
ich bin derzeit in den USA im Urlaub und erst ab Mitte September wieder zurück.
Beim Design muss ich zwei Optionen abwägen, was ich mir im Moment in Ruhe durch den Kopf gehen lasse.
Ciao, Mathias