Archiv verlassen und diese Seite im Standarddesign anzeigen : Frage zu RF Kommunikation
Hallo Freunde
Habe gerade eine Email von Microchip erhalten mit Daten zu einer neuen Controller Familie mit integrierter RF für Frequenzen unterhalb von 1GHz. Meine Frage: ist es denkbar, sinnvoll, darüber nachzudenken, ob man statt I2C Verbindungen über Entfernungen bis zu 1 Meter nicht stattdessen preiswerte, stromsparende Controller wie diese für die Kommunikation vorsehen kann?
In meinem "ewig bau" Modell habe ich den I2C bus der neuesten Generation und entsprechende Buffer eingesetzt, um die langen Verbindungsleitungen der I2C Busse mit 12 VDC der bis zu 15VDC möglichen Spannung zu betreiben. Ich setze Wärme- und Temperatursensoren von Sensirion ein, welche eine feste I2C Adresse haben. Daher verwende ich I2C Bus Multiplexer und Buffer für die Pegelwandlung an beiden Enden jedes Astes der Sterntopologie. Nun bekommt man ja von TI sehr großzügig Muster, so dass man mit geringen Kosten Prototypen aufbauen kann. Würd eman aber stattdessen solche RF Verbindungen nutzen, so könnte man viele Module über Funk verbinden und erspart sich die Verkabelung. Hier der Link zu der neuen Produktfamilie von Miucrochip:
http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en553313
Bin mal gespannt was ihr so sagt!
Meine persönliche Meinung: Meide Funk wenn du es nicht unbedingt brauchst. Kommunikation über Funk bedeutet einerseits die Nutzung eines gemeinsamen Mediums, wer diese Ressource nicht braucht sollte sie IMHO den Nutzern überlassen, die eher darauf angewiesen sind. Dann hat Funkkommunikation einen höheren Stromverbrauch und selbst wenn das vernachlässigbar ist, kommen noch Sicherheitsaspekte dazu.
mfG
Markus
Hallo Markus
Erst mal Danke für deine Antwort. was du sagst ist ja auch bisher immer gültig gewesen. Wenn jetzt die Halbleiterhersteller Controller und die zugehörige Software und Applikationsnoten herausbringen ist, so denke ich, eine Überprüfung bewährter Prinzipien sinnvoll. Meine Anwendung betreffend wäre es die Kommunikation innerhalb eines Holzrumpfes und die Datenmenge die Übertragen wird ist ja sehr gering, nur die I2C-Transaktionen zur Abfrage und Übermittlung der Temperatur- und Feuchtewerte. Mission critical sind die Daten ja auch nicht. Da die Zielapplikationen dieser Anwendungen auch auf äußerste Energiesparsamkeit und geringe Reichweiten ausgerichtet sind und die Frequenzen im 400MHz und 800MHz Bereich liegen, stören die sich mit den 2,4GHz Frequenzen sicher nicht. Bleibt die möglichen Störung von Motoren, Servos, DCDC Wandlern usw.
Ich sehe unser Hobby eben auch als ein Feld, wo man sich den Fragestellungen zuwenden kann, welche in der kommerziellen Praxis zu unbewährt wären.
Erst mal Danke für deine Antwort. was du sagst ist ja auch bisher immer gültig gewesen.
Ich erwarte auch nicht, dass sich daran etwas ändert. Funk-Frequenzbänder sind inzwischen eine teure Ressource, in den wenigen benutzbaren Bereichen ist man nur Sekundärnutzer. Das ist ein Faktum das auch weiterhin gültig bleibt.
Wenn jetzt die Halbleiterhersteller Controller und die zugehörige Software und Applikationsnoten herausbringen ist, so denke ich, eine Überprüfung bewährter Prinzipien sinnvoll.
Die Argumentation verstehe ich nicht ganz. Nur weil Hersteller Autos mit unvernünftiger Motorisierung verkaufen, heißt das noch lange nicht, dass jetzt alle mit 250 über die Autobahn rasen sollen.
Da die Zielapplikationen dieser Anwendungen auch auf äußerste Energiesparsamkeit und geringe Reichweiten ausgerichtet sind und die Frequenzen im 400MHz und 800MHz Bereich liegen, stören die sich mit den 2,4GHz Frequenzen sicher nicht.
Du störst die anderen Nutzer in deinem Frqeuenzband, die anderen Bänder sind erst Mal uninteressant.
Ich sehe unser Hobby eben auch als ein Feld, wo man sich den Fragestellungen zuwenden kann, welche in der kommerziellen Praxis zu unbewährt wären.
Das hat nichts mit Hobby vs. kommerziell zu tun, die Nutzung eines geteilten Mediums ist mit einer gewissen Verantwortung verbunden. Die meiner Meinung nach unnötige Verstopfung der Luft gehört für mich nicht zur Verantwortungsvollen Nutzung ...
mfG
Markus
Markus
In allen Ehren, aber stell deine Aussagen mal ins Verhältnis. Wir reden über Bauelemente für niedrigste Reichweiten, wir reden über den Betrieb in oder unter der Wasserspiegelebene in einem Rumpf eines Modellseglers. Trotzdem würde jeder am Einsatz eines Rauch- oder Kohlenmonoxid-Melders in einem Haus nichts zu beanstanden haben. Hier reden wir über ein Modellsegelboot auf einem See, irgendwo in der Landschaft! Den Einsatz von drahtlosen Systemen für niedrigsten Energieverbrauch mit einem Auto mit einer starken Motorisierung zu vergleichen ist hoffentlich nur ein emotionaler Ausrutscher! Ich bin an ernsthaften Antworten interessiert. Da in einem Modell Stromsparen angesagt ist reden wir hier von was anderem als unser lieber junger Freund hier schreibt!
@Niedrigste Reichweite: Mit den 10dBm sind durchaus 100m Reichweite möglich
@Rauchmelder: Das sind die wichtigen Nutzer im Frequenzband, die ich meinte. Ich weiß aber nicht, ob solch sensible Infrastruktur tatsächlich in den freien Bändern funkt.
@Modellsegelboot: Sorry, die Glaskugel war kaputt, das konnte ich nicht wissen.
@Emotionaler Ausrutscher: Nein. Nicht alles was möglich ist, ist sinnvoll. Auf offenem Gewässer ist die von mir angesprochene Problematik aber kaum von Relevanz. Für die Kommunikation innerhalb eines Roboters wäre das ganze dagegen ähnlich schwer zu begründen wie ein SUV für den innerstädtischen Weg zum Bäcker.
Zurück zum eigentlichen Thema: Du sparst dir die Signalkabel, benötigst aber dennoch Stromversorgung. Den Preis den du für den Verzicht auf die Signalkabel bezahlst, ist die potentiell höhere Störanfälligkeit der Funkverbindung sowie der bereits genannte Strom"verbrauch". Diese Vor- und Nachteile kannst letztendlich nur du für dich abwägen. Für eigene Projekte würde ich Funk aber nur zur Überbrückung größerer Distanzen einsetzen.
mfG
Markus
Google man nach "wer Funk kennt nimmt Kabel"
MfG Klebwax
@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.
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
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! :)
@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
@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
@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 :)
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.
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.
@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
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.