Frage zu RF Kommunikation

[markusj]

@WLAN: Ich rede nicht von WLAN
@Besonderheiten: Es gibt keine Besonderheiten. Das Teil ist einfach nur ein Mikrocontroller der den Funkchip bereits integriert hat. Das ist übrigens auch nichts neues, entsprechende Mikrocontroller gibt es schon länger. Gegenüber einer Mikrocontroller-Funkmodul-Kombination sparst du dir einfach nur ein zusätzliches Bauteil, sonst ändert der von dir genannte PIC nichts an der Situation. Damit gibt es keine Argumentation die für oder gegen den Einsatz dieser PICs sprechen kann ohne die grundlegenden Aspekte zu berücksichtigen.

Um noch näher auf den Chip einzugehen. Wenn ich mir die Application-Note zu besagtem PIC ansehe, bekomme ich stark den Eindruck, dass da wirklich nur ein bereits vorhandenes Funkchip-Design mit auf den Die des Mikrocontrollers gepackt wurde. Die Kommunikation mit dem Funkteil läuft immerhin über eine Art synchrone Schnittstelle bei der man die Bits noch selbst rausschieben muss.

@Maus/Tastatur: Ich will damit einfach nur sagen, dass es hier um eine mobile Anwendung geht. Deine Sensoren sind Ortsfest. Ortsfeste Dinge kann man (mehr oder weniger einfach) verkabeln, Bewegliche dagegen je nach Mobilitätsgrad weniger gut bis gar nicht!

Zu deiner aktuellen Busstruktur: Momentan hast du ja wohl einen (mehr oder weniger) durchgehenden I2C-Bus. Du hast also ein einheitliches Basisprotokoll, über das dann die Sensorkommunikation läuft. Diese Situation ist nicht direkt mit Funk vergleichbar, da Funk ja noch ein weiteres Basisprotokoll erfordert, über das du dann die Funkknoten dazu bringst, die Sensoren nach Wunsch anzusteuern. Du hättest meiner Ansicht nach zwei Möglichkeiten:
1. Einpacken des I2C-Datenstroms in Funkpakete. Hier würden einfach nur die Kabelwege durch die Funkschnittstelle ersetzt. Du hättest aber immer noch die von dir Eingangs erwähnten Probleme mit der Busstruktur und dem eingeschränkten Adressraum. Insgesamt würde ich diese Option als weniger attraktiv beurteilen. (Für Netzwerker: Das wäre eine Brücke auf Schicht 2)
2. Direkt bei einem oder mehreren Sensoren sitzt ein Knoten der die Kommunikation mit diesen übernimmt und alles in ein eigenes Protokoll übersetzt. Die Kommunikation würde dann über dieses eigene Protokoll erfolgen. Von I2C abstrahiert dieser Ansatz vollständig, du kannst deine Sensoren entsprechend einem eigenen Protokoll adressieren.

Jetzt kommt aber der interessante Teil: Variante 2 geht auch mit Kabeln. Die Knoten übersetzen zwischen dem eigenen Protokoll und dem der Sensoren, worüber du die Knoten ansprichst steht dir vollkommen frei. Ob die Schnittstelle dafür Funk oder ein anderes Medium ist, ändert nichts daran, dass genau diese Variante die Vereinheitlichung der Sensoransteuerung ermöglicht. Du könntest hier sogar wieder I2C als Grundlage verwenden und müsstest dabei dann keine Multiplexer mehr einsetzen. Natürlich könntest du auch einen beliebigen anderen geeigneten Bus zu diesem Zweck verwenden, RS485 genießt einen ziemlich guten Ruf, CAN wäre vermutlich übertrieben.

mfG
Markus

[Klebwax]

@Hellmut

Da dir die Kurzfassung zu kurz war, hier eine längere.

Daß die Chips nicht wirklich was neues sind, ist schon gesgt worden, die Kombination von RF Frontend und µC gibts schon von anderen Herstellern. Ob es wirklich ein Chip ist oder ob zwei in einem Gehäuse weiß ich nicht. Für die Funktion ist es auch egal. An der ganzen Sache ist überhaupt nichts neu, außer das Microchip jetzt auch so was hat.

Eine Funkübertragung ist vom Prinzip störanfälliger als eine über Draht, gegenteiliges wirst du nicht nachweisen können. Jeder kann in den benutzten Kanal hineinfunken, bewußt und auch unbeabsichtigt. Und das ganze nun auch noch in der Nähe von geschalteten Induktivitäten, wo häufig auch schon Kabel zu empfindlich sind. Außerdem sind sowohl Sender als auch Empfänger in diesem Störfeld.

Jetzt kommen die Probleme eines, wenn auch kleinen, Netzes dazu. Die Übertragungen müssen synchronisiert und Kollisionen aufgelöst werden.

Das lässt sich alles natürlich lösen. Man kann PWM-Frequenzen anpassen, Filter einbauen, Einbauorte optimieren und das dann testen, verbessern und weiter testen. Und man kann Software schreiben um das Sensornetz zu kontrollieren und zu steuern. Die Übertragung kann überwacht werden und Fehler korrigiert.

Nur: in jedem zusätzlichen Bauteil und in jeder Zeile Code steckt ein potentieller Fehler. Und das Suchen von Fehlern wird dadurch erschwert, daß dein Funknetz im wirklichen Einsatz irgendwo auf dem Wasser ist, wo man schlecht mit Debugger oder HF-Sonde hinkommt. Daß selbst die aufwändigsten Trockentests manchmal nicht helfen, sieht man z.B. bei der Ariane 5. An den Tests haben die bestimt nicht gespart. Am Boden hatte alles funktioniert, aber beim Ersteinsatz ...

Also, warum sollte man eine einfache Lösung, die funktioniert, durch eine komplexe Lösung, von der man weiß, daß sie problematischer ist, ersetzen.

MfG Klebwax

[Hellmut]

@Markus and Klebax: Modellbau ist die Tätigkeit, bei welcher man den höchsten Aufwand und die niedrigste Wirtschaftlichkeit verfolgt. Insofern die Antwort auf Klebwaxes letzten Satz!
Die zusätzliche Integration und der extrem niedrige Leistungsbedarf sind die Argumente die der Hersteller promoted und eine Tendenz die ich interessant finde. Mein gedanklicher Ansatz folgt deiner Option 2 Markus. Das I2C Protokoll wird ja nicht mehr benötigt, nur die Daten müssen übertragen werden. Die Info zu Temperatur und Feuchte und eine ID für jeden Sensor, der Empfänger kann dann durch Plausibilität Fehler abfangen. Wieviel Aufwand wegen der Fehler getrieben werden muss kann dann durch Protokollierung erfasst werden.
Im Hinblick auf das Ariane 5 Beispiel, die Daten sind nicht mission critical! Einerseits dienen sie der Diagnostik und andererseits beim Dimmen der Vermeidung von Ausfällen wegen Überhitzung. Das geplante System begrenzt das Hochdimmen der LEDs auf eine Grenztemperatur. Wird diese erreicht, sollte normalerweise nicht passieren, da ich grossen Aufwand beim Abführen der Wärme betreibe, definiert sich durch das Erreichen der gewählten Grenztemperatur, z. B. 85 Grad Celsius der maximale beim Dimmen zulässige Strom. Gleichzeitig lässt das Erreichen dieser normaler Weise nicht erreichten Temperatur als Info der Diagnostik nutzen um die betreffende LED zu überprüfen, da so der Hinweis vorliegt, dass die Wärmeabfuhr unzulässig schlecht geworden ist. Ähnlich bei der Feuchte, eine Feuchte die höher ist als üblich gibt der Diagnostik den Hinweis, dass ich die Wasserdichtigkeit der LED überprüfen muss.
Tritt also ein Fehler bei der Übertragung auf, so kann bei der nächsten Abfrage der Wert, der von den bis dahin übermittelten Daten abweicht, wieder geprüft werden. Sobald ich meine Funke auf der Basis eines Andoid Tablets gebaut habe wird das in dem entsprechenden "Fenster" angezeigt, bis dahin kann ich die Info aus einer Speicherkarte und Logview auf dem PC erfassen.
Wenn dann Erfahrungswerte vorliegen kann man an Verwendungen höherer Relevanz denken. Die letzten beiden Beiträge haben die Qualität die ich mir erhofft hatte! Geht doch! Danke

[Klebwax]

Nicht richtig zugehört mit der Ariane. Es geht mir nicht um "mission critical" sondern um die Möglichkeit oder besser Unmöglichkeit zu Testen, Messen und Debuggen unter Einsatzbedingungen. Wenn es da nicht funktioniert, weiß man nicht mal warum.

MfG Klebwax

P.S. Ich hab mir den Anfang deiner Nachricht ausgedruckt und lass das Rahmen.

[Hellmut]

Hallo Klebemax

Der Satz stammt nicht von mir, er wurde in der Sendung Modellbauer von einem Modellbauer gesagt und ist mir im Gedächtnis geblieben. Hab schon richtig zugehört, daher mein Exkurs. Habe aber über deine Aussagen im Hinblick auf meine mögliche Verwendung dieser Bauteile das Thema durchdacht. In dem es nicht mission critical ist passiert auch nichts wenn ein Fehler auftritt. Dadurch das es Daten sind die mit etwa 1Hz abgefragt werden, kamm man alten und neuen Wert immer vergleichen und eine Plausibilitätsbetrachtung machen. Großes Wort dafür, das innerhalb einer Sekunde bei unverändertem Strom keine Verdoppelung der temperatur zu erwarten ist. Sollte der nächste Wert den 2. bestätigen, nun ja, dann kann man immer noch fail safe machen. da die Daten protokollierbar sind kann man das Ganze problem und folgenlos am Abend zuhause überprüfen. Nochmals, danke für die Hinweise, genau darauf hatte ich gehofft. Die Amis nennen es "educated decision". In dem ich auf solche gedanken eingehe und meine Überlegung überprüfe wird eine Entscheidung, egal wie sie ausfällt, das Durchdenken deiner Hinweise enthalten.

[markusj]

@Integration/Leistungsbedarf: Promoten kann man viel, Fakt ist, dass ich da kein Novum erkennen. Im Normalbetrieb ist die Stromaufnahme vergleichbar mit anderen Mikrocontrollern, der Strombedarf des Funkteils birgt auch keine besonderen Überraschungen.
@Fehlererkennung: Das sollte nur das Auffangnetz/der doppelte Boden sein. Viel wichtiger ist, dass du für das Funkprotokoll eine leistungsfähige Fehlererkennung vorsiehst. Normalerweise ist es die Aufgabe der unteren Schichten im Netzwerkstack, die Korrektheit der übertragenen Daten zu gewährleisten und beschädigte Pakete auszusondern. Eine zusätzliche Prüfung der Daten auf ihre Plausibilität schadet nicht, sollte aber die letzte Bastion sein (und eher auf Ausreißer der Sensordate abzielen).

mfG
Markus

[Hellmut]

Dank an Alle!