Frage zu RF Kommunikation

[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