Mein Chef hat einen abenteuerlichen Auftrag "an Land gezogen" (naja, noch nicht ganz, aber er möchte dem Auftraggeber, einem Verein, "etwas gutes tun"). Es gibt 8 Sensoren, verteilt auf etwa 60x30 Meter, die sollen Daten an einen zentralen PC/SBC schicken (alle 15 Sekunden), der stellt sie per SMB bzw HTTP anderen Rechnern des Auftragsgebers (die sind nicht unser Bier) zur Verfügung. Projektdauer knapp 1 Jahr, also keine Dauerlösung. Probleme: Die Sensoren haben als Schnittstelle I2C, das ist nicht veränderbar. I2C geht nicht über diese Distanzen. Zudem muss der "zentrale" PC in einem Gebäude an der Schmalseite und nicht im Zentrum stehen. Also lange Leitungen. Das ganze in einer Stadt mit etwa 30-40 WLANs im Umfeld, fällt also aus. Meine Idee dazu: Jeder Sensor bekommt einen eigenen SBC, der die Umsetzung von I2C zu Ethernet macht und SMB (Samba) und HTTP (Lighttpd) zur Verfügung stellt. Als SBC habe ich den Orange Pi Zero ausgeguckt, der hat on board die Möglichkeit, die Pins 4/5 und 7/8 aus der RJ45-Buchse zum auszuleiten. Kostet incl. Einfuhrumsatzsteuer um die 10 Euro, plus Spannungswandler unter 1 Euro, plus eine kleine microSD-Karte, plus ein kleines einfaches regendichtes Gehäuse. Zentrale Stromversorgung über PoE; damit die Spannungsverluste über die grosse Entfernung nicht zu gross sind, bekommt jeder SBC einen eigenen Spannungswandler. Die zentrale Einspeisung der Spannung über ein einfaches 8-er Patchfeld: Pins 1,2,3,6 werden auf Ethernet gelegt, Pins 4,5,7,8 auf die Versorgung. Ein kleines Python-Programm, das alle 15 Sekunden aus den RAW-Werten human-readable macht und zentral abspeichert. Die Leitungen legt der Auftraggeber, wegen der niedrigen Datenraten reicht Telefon 4x2 bzw. Cat5 o.ä. je nach Meter-Preis. Ist zwar draussen, aber das wird für 1 Jahr schon halten. Alternativen: WLAN fällt aus (s.o.), RS232 etc ebenso. Ein PIC18F97J60 kann zwar Ethernet, die Entwicklung und Programmierung eines Boards wäre wesentlich aufwändiger und teurer. Hat jemand von Euch dazu Ideen bzw eine preiswertere Lösung?
> ich den Orange Pi Zero ausgeguckt
Kennst du nichts anderes oder kannst du nichts anderes?
Im Aussenbereich wuerde ich nur LWL benutzen.
Oder wenn der Datendurchsatz so laecherlich gering ist:
433 MHz oder 868 MHz.
Harald schrieb: > I2C geht nicht über diese Distanzen. Sagt wer? https://www.nxp.com/docs/en/application-note/AN10658.pdf http://www.nxp.com/documents/data_sheet/PCA9600.pdf
Harald schrieb: > Ein PIC18F97J60 kann zwar > Ethernet, die Entwicklung und Programmierung eines Boards wäre > wesentlich aufwändiger und teurer. Schwer vorzustellen, schlimmstenfalls halt Arduino oder ähnliches nehmen. Harald schrieb: > Hat jemand von Euch dazu Ideen bzw eine preiswertere Lösung? https://www.nxp.com/docs/en/data-sheet/PCA9615.pdf
> I2C geht nicht über diese Distanzen. ... > Hat jemand von Euch dazu Ideen bzw eine preiswertere Lösung? Es ist kein Problem den bidirektionalen I2C-Bus mittels des schon erwähnten PCA9600 in zwei unidirektionale Übertragungskanäle zu konvertieren und diese dann z. B. über CAN-Transceiver (als differentielle Signale) zu übertragen. Je nach Kabelqualität (unshielded/shielded), Länge und Geschwindigkeit kann man die Flankensteilheit der Signale gezielt reduzieren um Abstrahlung zu vermeiden. Ich nutze CAN-Tansceiver um I2C Kommunikation über längere Strecken zu übertragen. 400 kBit/s bei 100 m mit recht primitiven Kabeln gehen ohne Probleme. Für deine Anwendung reichen wahrscheinlich 10 kBit/s - da kannst du - bei verringerter Flankensteilheit - 2x2 Telefonkabel nehmen (+ ein paar Adern als Spannungsversorgung). An Kosten für diese "I2C-Konvertierer" sollten 20-25 Euro (mit Platine) je Gerät reichen. Du brauchst dann 8 Konvertierer für die Sensoren und einen an der Zentrale. An der Zentrale hat dein Raspi oder Orange Pi Zero oder was auch immer I2C und gut ist. Aus meiner Sicht eine einfache, robuste Lösung.
Harald schrieb: > RS232 etc ebenso Was spricht gegen die Verwendung von Bussen und Protokollen, die genau dafür gemacht wurden? MODBUS und CAN, oder für Zweidraht (Strom + Kommunikation auf einer Leitung) dann HART, KNX oder Power-LAN?
:
Bearbeitet durch User
peta schrieb: > lorawan? Mit einem eigenen Gateway und der dann erforderlichen autarken Stromversorgung für die Sensoren, dürfte das deutlich aufwendiger werden.
Orange Pi Zero: Also ich hätte etwas bekannteres genommen, wo man auch einfach Software und Support (z.B. hier) bekommen kann. Und das ist eigentlich nur eine Raspi-Bauform. Ich habe auch auf einen normalen Arduino ein Wiznet Ethernet Shield. Das reicht für UDP Datagramme. Damit könnte dann der Arduino die I2C Sensoren lesen und über Ethernet weiter verschicken. Und Ethernet-Kabel sollen bis 90 Meter gehen.
Wolfgang schrieb: > Mit einem eigenen Gateway und der dann erforderlichen autarken > Stromversorgung für die Sensoren, dürfte das deutlich aufwendiger > werden. Wozu Gateway? Wenn man nur LoRa nimmt (ohne WAN/Sigfox/TTT etc.), kann man zwei Arduinos miteinander reden lassen. Einer liest die Daten vom Sensor, der andere gibt sie über serial an den PC aus.
Radiocrafts RC232, auf PC Seite gibt es den in Form eines USB-Sticks. Zahlreiche Frequenzbänder, gibt es auch als selbstorganisierende Mesh-Module (einen macht mach als Master, der Rest dockt sich quasi „automatisch“ an das Netzwerk an.
Für eine Quick&Dirty Lösung scheint mir dein Ansatz mit dem Orange Pi Zero und Python angemessen. Allerdings könnte die Länger der zu vernetzenden Strecke ein Problem werden. War da nicht was mit max. 100 Meter? Solch lange Strecken sind mit RS422 (auf dem gleichen Kabel) allerdings problemlos machbar. CAN würde in die selbe Richtung gehen und bringt zudem noch automatische Lösung von Kollisionen mit sich. Vielleicht nimmst du doch besser einen CAN fähigen Mikrocontroller. Es gibt dazu fertige Boards samt Treiber.
Ich habe mir mal die Lösungen mit PCA9600 und CAN angesehen, und auch mit den Leuten vom Förderverein bzw dem Institut telefoniert. Aber: 1. PCA9600 plus CAN etc ist zwar auf den 1. Blick schön (denb PCA9600 kannte ich noch nicht), aber alles zu umständlich, da muss ich Platinen bauen und testen, das kostet Zeit und damit Geld und 2. der fest vorgegebene Sensor hat gleich 2 I2C-Adressen, die nicht veränderlich sind. Da ist ein Sensor für "Bodenkapazität" drin (was auch immer es ist, ich habe es nicht kapiert) sowie ein Sensor für Temperatur, Luftfeuchte und Luftdruck, ich vermute mal ein BME280 weil der so klein ist (es wird im Projekt aber nur die Temperatur ausgewertet). Wir machen das nur, weil mein Chef ein Kumpel von dem Vorsitzenden des Fördervereins ist und das Angebot einer Spezialfirma für ein "Auswerte- und Speichermodul" pro Stück über 1500 + Märchensteuer für jeden einzelnen Sensor ! liegt, insgesamt also knapp 15000 Euro, das Geld hat der Verein für dieses kleine Projekt nicht locker. Also Q&D wie stefanus schrieb durch uns. Einen Orange Pi Zero sowie einen passenden Buck-Konverter habe ich zuhause, da werde ich mal einen Prototypen zusammenklopfen, das Python-Progarmm dürfte um 30-40 Zeilen haben, I2C habe ich damit schon mal gemacht, da dürfte schnell erldigt sein. Der Zero hat eben den Vorteil, dass man PoE (allerdings nicht normgerecht) machen kann. Sorge macht mir wegen der Länge nicht die Ethernet-Verbindung sondern die Energieversorgung, da werde ich mal 70m Kabel abrollen den Orange Pi dranhängen und den Spannungs-Abfall bzw. -Verlauf messen. Trotzdem vielen Dank an alle. Harald
Es gibt Leitungstreiber für I2C die für so was geeignet sind. Ansonsten gäbe es die Option auf RS422 oder RS485 zu wandeln. Damit kann man ein paar 100 m Überbrücken. Bei RS485 könnten sogar alle Sensoren auf einen Bus gepackt werden, es wäre also keine Point-to-Point Verkabelung notwendig.
Harald schrieb: > Ich habe mir mal die Lösungen mit PCA9600 und CAN angesehen, und auch > mit den Leuten vom Förderverein bzw dem Institut telefoniert. > > Aber: 1. PCA9600 plus CAN etc ist zwar auf den 1. Blick schön (denb > PCA9600 kannte ich noch nicht), aber alles zu umständlich, da muss ich > Platinen bauen und testen, das kostet Zeit und damit Geld... Falls du doch nochmal über diese Lösung nachdenken willst oder musst: Platinen bauen brauchst du nicht unbedingt. Ich nutze diesen LongRange-I2C (also PCA9600+CAN-Transceiver+Steuerung der Flankensteilheit) auf Modulen mit den MCP23017 und 16 Eingängen mit OKs bzw. 32 Ausgängen schon seit Jahren - das funktioniert prächtig. Den Schaltungsteil, der aus I2C den LongRange-I2C macht, habe ich (zusammen mit einem Spannungsregler) jetzt mal separat auf ein kleines Platinchen gepackt. Leerplatinen könntest du von mir bekommen - zumindest wenn es nicht sehr eilig ist. Das Thema der I2C-Adressierung deiner Sensoren musst du natürlich davon unabhängig lösen. Du weißt, dass es 8-fach I2C Multiplexer gibt? TCA9548A - der wird schon mal gerne zusammen mit den BME280-Sensoren (eben wegen der Adressierungsproblematik) genommen. Damit hast du 8 einzelne I2C auf denen du jeweils die gleichen Adressen haben kannst und fragst die 8 I2C einen nach dem anderen ab. Da deine Anwendung nicht zeitkritisch ist passt das vermutlich ganz gut. Der TCA9548A ist als TSSOP-24 recht klein - aber man bekommt ihn auf einem Breakoutboard für rund 10 EUR.
:
Bearbeitet durch User
Man muss ja I²C nicht unbedingt mit 100kHz oder mehr betreiben. Das ist ja der Witz, das man das so langsam machen kann, wie man möchte. Gut, statischen Betrieb habe ich noch nicht probiert, aber 10 oder 25kHz wie beim SMBus gehen immer. Der Haken bei I2C ist immer, das da null Fehlerkorrektur oder -erkennung stattfindet, da der Bus ja nur innerhalb des Philips Fernsehers funktionieren sollte. Schwierig wird es m.E., einen MC mit so vielen I²C Schnittstellen zu finden. Da wird man wohl multiplexen müssen.
Harald schrieb: > Sorge macht mir wegen der Länge nicht die Ethernet-Verbindung sondern > die Energieversorgung, da werde ich mal 70m Kabel abrollen den > Orange Pi dranhängen und den Spannungs-Abfall bzw. -Verlauf messen. Der Spannungsabfall auf der Leitung kann dir ziemlich Schnuppe sein, wenn du mit ausreichend hoher Spannung auf die Leitung gehst und direkt beim Orange Pi einen Step-Down DC/DC-Wandler für ein paar Cent hinsetzt, der für stabile Spannung sorgt.
Weitere Stichworte für mögliche IoT-Ansätze dieser Art: - Linkit Smart Duo (WLAN und auf Kanal 14 funken. Don't ask, don't tell) Oder ein Ethernet-Shield ranbacken. - CC430-Plattformen und sich mit dem TI Simpliciti rumärgern, oder das SWAP-Protokoll nutzen - Mit einem msp430 o. Atmel über RS485 einen einfachen Wandler bauen (kann man vom Bus powern). Gleich mit Linux draufhauen kann ein schnelles Erfolgserlebnis liefern, im Feld dann aber gehörige Ausfälle haben. Wenn der i2c buggy ist wie auf div. Broadcom-Chips, macht das Ganze schon mal keinen Spass, wenn man zuverlässig Messwerte braucht und das Zeug sich aufhängt.
Mach Dir unbedingt auch Gedanken über die Gehäuse und die Kabeleinführung. Wenn ich das richtig verstehe ist das im Freiland. Das heißt Regen, Tau, Hitze,... So ein Raspi oder ähnliches erzeugt einiges an Temperatur und kann nur in einem eng beschränkten Temperaturbereich betrieben werden. Wenn im Sommer die Sonne direkt drauf scheint wird das schnell eng. Auch gegen Wasser in Vergussmasse eingießen etc. dürfte bei Raspi und Co. schwierig werden (läuft in Verbindung zur SD-Karte). Da ist eine Mikrocontroller-Lösung wesentlich robuster machbar. Auch wenn der Raspi vielleicht auf den ersten Blick schneller aussieht, kann Dich das hinterher im Feld ganz schnell beißen. Ich würde für sowas eine einfache Mikroncontroller-Lösung mit CAN-Bus und Stepdown-Spannungsregler an jedem der Sensoren verwenden.
:
Bearbeitet durch User
Gerd E. schrieb: > So ein Raspi oder ähnliches erzeugt einiges an Temperatur alte PI1 bekommt man ja fast nachgeworfen und der Takt kann locker fix runtergesetzt werden wenn es nur um I2C geht!
> Ich würde für sowas eine einfache Mikroncontroller-Lösung mit CAN-Bus > und Stepdown-Spannungsregler an jedem der Sensoren verwenden. Ja ein kleiner 8 Pinner handelt lokal am Sensor das I2C ab und schickt seine Ergebnisse ueber einen 2. 8 Pinner namens 75176A die Ergebnisse auf einen Bus. Das kann dann ein einfaches asynchrones Datenformat sein. Auf der Empfangsseite braucht man dann nur noch einen 75176A, um daraus wieder ein unsymmetrisches Signal zu machen und einen MAX232 um es einer ueblichen COM-Schnittstelle anzudienen. Dazu evtl. einen kleinen Controller der das ganze arbitriert und Schrott aus den Daten fischt. Aber die (Mess-)Clients sollten schon selber den Bus arbitrieren koennen. Den koennen sie ja immerhin mitlesen. Ein Spannungsregler per Modul ist sicher auch eine gute Idee. Das sollte in der Summe deutlich robuster sein als jede RPI-Frickelloesung.
Joachim B. schrieb: > alte PI1 bekommt man ja fast nachgeworfen und der Takt kann locker fix > runtergesetzt werden wenn es nur um I2C geht! Bloss Finger weg von sowas. Das hängt sich irgendwann auf, da reicht ein Glitch. Der HW-Bug in den BCM* wurde erst in neuern Chip-Steppings behoben. Für robuste Lösungen ist der RPi nix.
Harald schrieb: > RS232 etc ebenso. Ein µC der I2C spricht und RX/TX ist eigentlich recht einfach. Ob das ganze dann als Stern, Bus, Ring oder so verdrahtet wird, ob 2 oder 4-Draht, ist dann schon fast egal, solange man jeweils weiss, was man tut.
Lest euch den Thread nochmal durch. Es ging genau genommen nur um die Vorstellung der festgelegten Idee, Alternativen wurden nicht ernsthaft in Erwägung gezogen.
Matthias S. schrieb: > Man muss ja I²C nicht unbedingt mit 100kHz oder mehr betreiben. Niedrigere Geschwindigekt vereinfacht die Signalaufbereitung. Ohne Aufbereitung bringt niedrige Geschwindigkeit auf langen Leitungen nicht viel, wie die Taktflanken zu sehr verzerrt werden.
> > ich den Orange Pi Zero ausgeguckt > Kennst du nichts anderes oder kannst du nichts anderes? > Alternativen wurden nicht ernsthaft in Erwägung gezogen. Er kennt nichts anderes und ob er es kann ist noch nicht raus. Aber die Vorstellung das promovierte Eierköpfe alle paar Tage fluchend durch den Matsch waten müssen, um den Kram wieder zum laufen zu bringen, ist irgendwie auch erheiternd.
Harald schrieb: > Die Leitungen legt der Auftraggeber, wegen der niedrigen Datenraten > reicht Telefon 4x2 bzw. Cat5 o.ä. Also wenn das gilt, dann frage ich mich warum man katgorisch erstmal Harald schrieb: > WLAN fällt aus (s.o.), RS232 etc ebenso. auschließt. IMO ist doch RS232 bzw. dessen Derivate (nen UART vielleicht sogar direkt) bei diesen Strecken schon nahezu ideal. 100 m sind doch nix wenn einem ne Datenrate von 1200 BD genügt und mir scheint die würde hierbei genügen. Einfacher und preiswerter ists doch kaum umsetzbar.
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.