Frage zu RF Kommunikation

[Hellmut]

@Klebwax: Habe wie empfohlen gegoogelt und die Treffer gelesen. Leider hier nicht anwendbar. Maus und Tastatur über Funk zu betreiben ist ja auch nicht unüblich und eher mit dem zu vergleichen wovon ich spreche! Datenmengen und Entfernungen passen ja ebenfalls. Leute, Platitüden von sich zu geben ohne wirklich auf das einzugehen was diese neuen Bauteile ausmacht versperrt die Sicht für neues. Gerade das Argument Stromverbrauch zeigt, dass du dich nicht mit dem genannten bauteil beschäftigt hast. Auch die Aussage, nur für größere Distanzen ist, wenn man an Tastatur und Maus denkt, nicht unbedingt zutreffend.

[markusj]

Leute, Platitüden von sich zu geben ohne wirklich auf das einzugehen was diese neuen Bauteile ausmacht versperrt die Sicht für neues. Gerade das Argument Stromverbrauch zeigt, dass du dich nicht mit dem genannten bauteil beschäftigt hast. Auch die Aussage, nur für größere Distanzen ist, wenn man an Tastatur und Maus denkt, nicht unbedingt zutreffend.

Du vergreifst dich im Ton. Hast du schon im letzten Post gemacht, aber zweimal in Folge ist kein Ausrutscher mehr.

Wenn du bereits eine Meinung hast und alle davon abweichenden nicht akzeptieren willst, warum fragst du dann?

@Distanzen: Sorry, im Datenblatt stehen 10dBm. Ich hatte nur geschrieben was damit möglich ist. Kurzdistanzkommunikation über Funk erachte ich für in vielen Fällen einfach nicht als sinnvoll.
@Bauteil beschäftigen: Stimmt und stimmt auch wieder nicht. Einerseits habe ich im Datenblatt nach den Eckwerten gesehen, andererseits basierten meine Aussagen auf Physik. Und Physik hat die schöne Eigenschaft, für alle gleich zu sein. Das wirkt sich unter anderem auf den Stromverbrauch aus ...
@Tastatur und Maus: Ein ganz wunderbares Beispiel. Es gibt Fälle in denen Funk hier sinnvoll ist. Oft genug wird hier aber einfach nur aus Bequemlichkeit heraus Funk gewählt. Von der bereits angesprochenen Frequenzbandnutzung abgesehen bringt das auch Umweltaspekte (Batterien/Akkus) mit sich. Außerdem: Tastaturen und Mäuse unterscheiden sich von deinem Anwendungsfall durch ein wichtiges Merkmal: Sie sind frei beweglich. Schiebst du deine Sensoren auch durch die Gegend? Mitten im See? Nein? Dann fällt das Mobilitätsargument wohl weg.

Du bist übrigens immer noch nicht darauf eingegangen, dass du dir der Wechsel auf Funk das Verlegen von Stromkabeln immer noch nicht erspart.

mfG
Markus

[Hellmut]

Sorry when du den Ton als verkehrt erachtest. Aber das sagen von Gemeinplätzen nennt man nun so. Trotzdem, will ich auf deine Argumente eingehen. Ich Suche aber nach Argumenten welche die Besonderheiten dieser neuen Produkte berücksichtigen. Mit WLAN und ähnlichem zu kommen ist einfach fernab dieser Anwendung, meiner Frage und der Neuartigkeit. Wie geschrieben werden hier nur die Daten z.B. von Sensoren abfragt. was die Verkabelung angehrt ignorierst du ebenfalls die von mir gelieferten aussagen. Es werden hier I2C Multiplexer und Buffer eingesetzt. Diesen Aufwand und die zugehörigen Kabel mit den 2 Leitungen für eine Versorgung mit der Betriebsspannung für autarke über Funk kommunizierende Module zu vergleichen...
Auch wie du den Hinweis auf die Maus und Tastaturanwendungen eingehst erweckt den starken Eindruck, dass du nur recht haben willst! Was hat die Mobilität hier zutun, genauso die absurde Bemerkung betreffend der Battereien und Akkus und den Hinweis auf Umweltaspekte! Beides, Tastatur und Maus sind Anwendungen wo nur geringe Datenmengen über kurze Entfernungen, meiner Anwendung vergleichbare Datenmengen ausgetauscht werden.
Also Markus, entweder schweige oder bringe stichhaltige Argumente, ansonsten iss lieber ein Snikers!

[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!