Lieber Besucher, herzlich willkommen bei: RCLine Forum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

Space

RCLine User

  • »Space« ist der Autor dieses Themas

Wohnort: Hasloh b. Hamburg

  • Nachricht senden

1

Mittwoch, 31. Oktober 2007, 13:01

Open2.4: Fragestellungen zur XBEE Konfiguration

Moin,

um den Haupthread nicht zu unübersichtlich werden zu lassen, sollten hier alle Fragen zu XBEE Übertragung reinlaufen. Ich fange mal an:


Ich bin im Moment etwas unschlüssig, ob es Sinn machen könnte dem properitären XBEE MAC MODE zu verwenden. Der Vorteil währe ein einfacheres Binden von 2 Modulen (Node Discover auf speziellen Networ Identifier).
Nicht einsetzbar ist der MAC Mode allerdings, wenn man das Pflicht Ack der Pakete und damit die mindestens 3 Retries ( erster Retrie erst nach 200ms 8( ) der XBEE im MAC Mode nicht ausschalten kann. Die Anleitung tut so als wenn die ACKs ausgeschaltet werden können, aber den Befehl dazu haben die vergessen oder ich bin zu blind ==[]
Wörtlich heisst es:

XBEE MAC MODE
.....MaxStream Mode is enabled and the module adds an extra header to the data portion of the 802.15.4 packet. This enables the following features:
• ND (Node Discover) and DN command support
• Duplicate packet detection when using ACKs

Auch sind Angaben (Größe/Inhalt) über den zuätzlichen MAxStream Header nicht zu finden. Wenn der einen wesentlichen Overhead erzeugt, ist der MacMode auch tot.
Gruß

Thomas

wurpfel1

RCLine User

Wohnort: CH-rheintal

  • Nachricht senden

2

Mittwoch, 31. Oktober 2007, 13:07

Hi Space

das ACK ist ein features des ZigBee-protokolls..
ich nutze das nur um die MAC der XBEE auf sendung rauszufinden.


dann wird in den APImode gewechselt :evil: da gibts keine ACKs mehr :w
bin schon zu alt zum spielen.. macht aber gleichwohl spass ;-)

Space

RCLine User

  • »Space« ist der Autor dieses Themas

Wohnort: Hasloh b. Hamburg

  • Nachricht senden

3

Mittwoch, 31. Oktober 2007, 18:43

Zitat

Original von wurpfel1
das ACK ist ein features des ZigBee-protokolls..

..scheint mir auch so, MAC Mode ohne Ack gib et net. Ist einfach unsauber im Datenblatt definiert.
Gruß

Thomas

Space

RCLine User

  • »Space« ist der Autor dieses Themas

Wohnort: Hasloh b. Hamburg

  • Nachricht senden

4

Mittwoch, 31. Oktober 2007, 18:49

Ich habe mich gerade mit der Fragestellung beschäftigt, "Wie bekomme ich die XBEE ETS 300 328 1.7.1 100mW e.i.r.p" konform.
Gleich der Hinweis, dies soll kein weiterer dieser viele emotionalen Thread über 2.4GHz und deren Konformität werden. Wenn hier jemand anfängt sein seine Ideologisch motivierte Meinung zu äußern, wird er sofort "gebeten" die Unterhaltung woanders weiter zu führen. Hier geht es nur um die Realisierung des Open2.4 Projektes und deren technische Abstimmung!

Die ETS 300 328 17.1 beschäftigt sich hauptsächlich mit der Definition des FHSS (frequency hopping spread spectrum modulation) Verfahrens. Bei dem FHSS handelt es sich um ein DSSS Verfahren (<-XBEE), welches als Basis ebenfalls das DSSS verwendet, bloss hierbei in rascher Reihenfolge die Kanäle wechselt. Alles was nicht der Definition vom FHSS entspricht, also ein XBEE Modul im Alleinbetrieb, gehe ich weiter unten drauf ein.
FHSS Anforderungen:
Variante a)
Es müssen 15 Kanäle in 1,6sec. (max Verweildauer 0,4sec pro Kanal) durchlaufen/gewechselt werden.
Alternativ geht auch b)
90% der Gesamt Bandbreite des ISM Bandes (83,5MHz) müssen in 1,6sec. durch Kanalechsel durchlaufen werden. Hierbei müssen mindesten 20 Kanalwechsel (Kanalwechsel, nicht 20 unterschiedliche Kanäle!) in 1,6 sec statfinden.

Medium Access Protokoll
Desweiteren wird ein medium access protocol (MAC) verlangt. Die Definition des MAC ist offen, auch der Nachweis der Konformität ist hier nicht definiert. Es steht hier also nicht, das vor dem Versenden eines jeden Paketes eine Medium Abfrage erfolgen muss.
Umkehrschluss:
Um die Bedingung nach dem MAC zu erfüllen kann es in meinen Augen schon ausreichend sein, bei der Inbetriebnahme der XBEE den Energy Scan der XBEE durchzuführen, und die "belegten" Energiehaltigen Channels nicht zu verwenden. Das ganze sollte man sowieso tuhen....
Desweiteren scheint in den XBEE's bereits ein Verfahren etabliert (Clear Channel Assessmen ) zu sein, welches bei belegtem Chanell ein Aussenden verhindert. ATCA setzt den Threshold, was als belegt gilt) Wer hat die 802.15.4 Papiere gelesen und weiss genaueres?(ALOHA CSMA-CA)

Frequenz Hopping (FHSS)
Stellt sich die Frage, kann ich mit dem XBEE innerhalb von 1,6sec. 15 Kanalwechsel Prozessorgesteuert durchführen?
Ich habe bisher keine Angabe zum XBEE gefunden, wie lange ein Kanalwechsel dauert. Weiss da jemand eine Quelle?
Gilt ein geschlossenes System welches 2 (4) XBEE Module enthält welche nur abwechselnd senden als ein ISM System laut ETSI?


Ein weiterer Punkt lässt micht stutzig werden.
Definiert ist im Papier für nicht FHSS Systeme (also XBEE standalone) unter 4.3.2.2 eine maximaler e.i.r.p pro Spectrum von 1MHz von 10mW.

Orginalton:
For wide band modulations other then FHSS (e.g. DSSS, OFDM, etc.), the maximum e.i.r.p. spectral density is limitedto 10 mW per MHz.

Das XBEE verwendet eien Kanalbandbreite von 2MHz. Ergo sollten auch 20mW legal sein, ohne zusätzlich Massnahmen.
Gruß

Thomas

5

Mittwoch, 31. Oktober 2007, 20:06

Mal eine gaaaanz dumme Frage. ;)

Wo steht in der 1.7.1 oder der derzeit gueltigen EN etwas darueber wie die 100 mW auf die einzelnen Kanaele bei FHSS aufgeteilt sein muessen? Ich finde es zumindest nicht auch nach vielemaligem durchlesen.

Vielleicht ist das jetzt hier mal der Zeitpunkt um genau das zu Fragen:

Es ist immer nur von maximaler Verweildauer auf einem Kanal die Rede. Nie aber davon was man in der Zeit machen soll. Wenn ich nun die Verweildauer auf den durchhopsten Kanaelen minimiere. Sagen wir mal so im µS Bereich als Beispiel und dafuer die restliche Zeit (90% z.B.) auf einem einzigen Kanal verweile habe ich doch die FHSS Vorgaben erfuellt. Oder? ;)
Haette also auf diesem Kanal mehr als genug Zeit.

Damit waere ich doch FHSS. Oder? :evil:

Honi soit qui mal y pense :w
Gruss
Thomas

🖖
So long, and thanks for all the fish.


Space

RCLine User

  • »Space« ist der Autor dieses Themas

Wohnort: Hasloh b. Hamburg

  • Nachricht senden

6

Mittwoch, 31. Oktober 2007, 20:32

Zitat

Original von Thomas_R.
Es ist immer nur von maximaler Verweildauer auf einem Kanal die Rede. Nie aber davon was man in der Zeit machen soll. Wenn ich nun die Verweildauer auf den durchhopsten Kanaelen minimiere. Sagen wir mal so im µS Bereich als Beispiel und dafuer die restliche Zeit (90% z.B.) auf einem einzigen Kanal verweile habe ich doch die FHSS Vorgaben erfuellt. Oder? ;)
Haette also auf diesem Kanal mehr als genug Zeit.

Damit waere ich doch FHSS. Oder? :evil:

Honi soit qui mal y pense :w


..witzig, die Frage habe ich mir eben beim Abendbrot auch gestellt. Wenn ich bedingt duch die 22ms des PPM eben nur alle 22ms ein Sendeereignis habe, wie weise ich dann nach das ich bei ms 1 -> 15 in Kanal 1 -> 15 hätte senden können :angel: , bzw. warum warum muss ich den Kanal wechseln, wenn ich den neuen Kanal nicht nutzen werde ?
Gruß

Thomas

7

Mittwoch, 31. Oktober 2007, 20:36

Glaub mir, diese Frage bewegt mich (und nicht nur mich) schon seeeeehr lange.

In der Norm finde ich keinerlei Antwort darauf.

Patent von Graupner/JR ich hoer dir trapsen. :evil:
Gruss
Thomas

🖖
So long, and thanks for all the fish.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Thomas_R.« (31. Oktober 2007, 20:38)


Bruchflieger

RCLine User

Wohnort: 18km südl. der Lutherstadt Wittenberg

Beruf: Energieelektroniker / HWK-Meister E-technik

  • Nachricht senden

8

Donnerstag, 1. November 2007, 18:33

Hi,

sorry, wenn ich nicht ganz im Topic liege - liegt wohl aber daran, daß ich es nicht ganz verstehe... ;)

Ich habe 2 Xbee-Pro, habe sie aus der Schachtel genommen, die Adressen abgefragt und dann als Destination-Adress die des jeweils anderen Moduls eingetragen - Mehr nicht (OK, ich hab die Baud noch auf 38400 eingestellt)...
Seit dem benutze ich diese Module, um damit meine Fugmodelle zu steuern - hab ich da jetzt irgendwas vergessen? - Die Teile kommen doch mit einer EU-Zulassung...
Grüße Dani.

wurpfel1

RCLine User

Wohnort: CH-rheintal

  • Nachricht senden

9

Freitag, 2. November 2007, 09:17

Hi Dani

die konfiguration ist nicht gerade schwierig, die dinger funzen aus der packung :D
eigentlich müsstest du noch den EUpowerlevel einstellen, meine senden meistens zu stark :angel:



@all
ZigBee ist ein DSSS mit frequenzhopping, um 600mal pro sekunde.
es wurde zum auslesen von sensoren angedacht, mit niedriger netzwerklast und vielen teilnehmern. es deckt die bedürfnisse für RC fast ideal ab..
was vergleichbares gibt es in EUland noch nicht, das verfahren erfüllt die ENnormen fast, aber nicht ganz :dumm:
darum darf das verfahren in der EU nur mit 10mW senden ;(

BLUETOOTH ist für hohe datenrate optimiert und für unsere zwecke VIEL zu leistungsfähig.

es ist *denkbar (und von GRAUPNER vermutlich gemacht worden) das ZigBee-protokoll zur erfüllung der ENnormen zu modifizieren und dadurch legal mit voller leistung senden zu dürfen. diese funkmodule sind dann nicht mehr wirklich ZigBee-kompatibel..


*vermutung/spekulation
die ENnorm ist für hohen datendurchsatz mit wenigen teilnehmern gedacht: sie fordert hopping UND eine datenrate über 250kB/s für 100mW-devices.
bei ZigBee liegt das schon in der obersten ecke der spez, es ist eigentlich für niedrige datenrate und viele teilnehmer gedacht.
damit im nahbereich das XBEE die 250kB/s schafft wird einfach uf einen teil des ZigBee-protokolles verzichtet, das gerät darf dann mit 100mW senden :evil:
nach der zulassung setzt man die datenrate wieder auf sinnvolle werte (38 oder 19kB/s) und freut sich an gut 1,6km bodenreichweite...


Aussicht
die nächste generation funkmodule verbindet hohe datenrate (>1`000kB/s) bei niedriger sendeleistung. zb wird BLUETOOTH über 1`000m bald wirklichkeit.
heute mit dem EN5042-käfer bereits möglich: mit 10mW bei niedriger datenrate über 10km weit ist , im nahbereich sind über 600kB/s machbar..

die käfer werden zudem immer billiger, es ist durchaus wirtschaftlich JEDES servo mit einem 2G4modul auszurüsten ;)
bin schon zu alt zum spielen.. macht aber gleichwohl spass ;-)

Space

RCLine User

  • »Space« ist der Autor dieses Themas

Wohnort: Hasloh b. Hamburg

  • Nachricht senden

10

Freitag, 2. November 2007, 10:35

Zitat

Original von wurpfel1
ZigBee ist ein DSSS mit frequenzhopping, um 600mal pro sekunde.
es ist *denkbar (und von GRAUPNER vermutlich gemacht worden) das ZigBee-protokoll zur erfüllung der ENnormen zu modifizieren und dadurch legal mit voller leistung senden zu dürfen. diese funkmodule sind dann nicht mehr wirklich ZigBee-kompatibel..

Sorry das stimmt so nicht. Bei den ZIG Bees wird von alleine nicht gehopst. Es sei denn ich lass sie über einen extra Prozessor manuell hopsen.

In dem normalen Auslieferungsmode wird pures DSSS gemacht und mit 10mW gesendet. Damit ist man (Dani) ETSI konform.

Graupner wird keine Veränderung an der XBEE Firmware vorgenommen haben, sondern nur die ungenaue Formulierung der ETS 300 328 ausnutzen und sich darauf beschränken nur zu bestimmten Zeitintervallen über die XBEE zu senden. In den anderen Zeitintervallen, wo das XBEE um FHSS (100mW) konform zu sein, eigentlich in anderen Kanälen aufhalten sollte, wird einfach kein Sendevorgang ausgelöst und auch nicht benötigt.

Das ganze ist in meinen Augen auch kein Problem aus Sicht der ETS. Die ETS 300 328 möchte eigentlich nur erreichen, daß das ISM Band von einzelnen Devices komplett ausgenutzt wird um Gleichkanalprobleme zu vermeiden in dem sich die Sendeenergie einzelner Devices für längere Zeit auf einen schmalen Bereich des ISM konzentriert.
Aufgrund der (vermutlich) kurzen Sendedauer in "langen" (PPM bedingten) Abständen ( duty cycle 0,xx%), ist der Sinn und Zweck der Die ETS 300 328 eigentlich erfüllt.
Um in das Hoppingraster von 15Kanälen in 1,6sec. und max. 0,4s auf einem Kanal zu fallen, muss auch Graupner mal hopsen. Aber dafür lange nicht so häufig wie eigentlich gefordert/gedacht.
Gruß

Thomas

11

Freitag, 2. November 2007, 17:37

Hallo,

leidige Diskussion mit der Sache, aber muss wohl sein...

@Space: Graupner/XPS hat eine eigene Firmware (ist auch im US-Forum und anderswo nachzulesen). Schon allein aus dem Grund, das wir Hansel nicht auf die Idee kommen, einen Empfänger zu basteln, der zu deren System Kompatibel ist.

Auch du kannst die Firmware des Xbee umprogrammieren, glaube da gibts sogar ein SDK auf der Maxstream-Seite. Dann müsstest du allerdings eine eigene Konformitätserklärung machen, da du dich nicht mehr auf die von Maxstream berufen kannst (was Graupner ja wohl auch nicht macht).

Das wird dann wohl auch der Grund sein, warum mehr als 10mW für uns ofiziell nicht drin ist. Wir berufen uns auf Maxstream und die schreiben für EU 10mW vor.

Sollte ich da jetzt was verdreht haben bitte ich um Aufklärung...

Ok, jetzt wieder produktiv:
Mir gefällt die Sache mit den Mac-Modes usw. nicht so. Umschalten, warten, zurückschalten... :no:
Meine Idee war, das ganze über Broadcast-Frames zu lösen. Über diesen Weg dann die Adressen übergeben und schon ist der Empfänger an den Sender gebunden (das ganze nur einmal, danach stehts im EEPROM des Senders). Geht mit dem API-Mode. Vielleicht schaff ich am Wochenende mal ne Demo zu proggen.

Bis dann

Gruß

Marc

Space

RCLine User

  • »Space« ist der Autor dieses Themas

Wohnort: Hasloh b. Hamburg

  • Nachricht senden

12

Freitag, 2. November 2007, 22:10

Zitat

Ok, jetzt wieder produktiv:
:ok:

Zitat


Mir gefällt die Sache mit den Mac-Modes usw. nicht so. Umschalten, warten, zurückschalten...
Meine Idee war, das ganze über Broadcast-Frames zu lösen. Über diesen Weg dann die Adressen übergeben und schon ist der Empfänger an den Sender gebunden (das ganze nur einmal, danach stehts im EEPROM des Senders).
Bin mir da nicht sicher, was du da meinst. Zwischen verschieden Modes umzuschalten macht eigentlich nur kurz nach dem Start des Empfängers Sinn, um in den Äther zu horchen ob ein paarungswilliger Sender vorhanden ist.

Ich würde allerdings die MAC des Senders an den Empfänger binden und nicht die MAC des Empfänges an den Sender. Anders ausgedrückt: Im EEPROM des Empfängers liegt die MAC des Senders, welche er beim Pairing gelernt hat.
Hintergrund, ich habe einen Sender und n Empfänger.
Als den Initiator des Pairings halte ich den Sender auch für sinnvoll. Meine Empfänger sind in den Rümpfen teilweise so verbaut, so das ein Schalterdrücken am Empfänger meist nich mal eben möglich ist.


Meine Vorstellung für ein Pairing, also dem einmalig notwendigen Verheiraten von Sender mit Empfänger:

Pairing Sendersicht
Am Sendermodul befindet sich ein Pairingtaste. Wird diese gedrückt, wird auf einem fest definierten Kanal (Verheiratungskanal z.B Kanal 1 ) an die Brodcast-MAC permanent Daten gesendet.
-Dier Frame enthält folgende Daten:
-Die MAC des Senders
-Die L3 Adresse des Senders (1 Byte)
-ein Schlüsselwort für das Pairing
-und den nächsten Kanal für den darauf folgenden Unicast Mode (AT MM=1).

Pairing Empfängersicht
Nach dem Einschalten lauscht der Empfänger für kurze Zeit auf dem "Verheiratungskanal" auf Broadcast Pakete, welche wie unter Sender beschrieben aufgebaut sind. Erkennt er solche Pakete schreibt der Empfänger die MAC und die L3 Adresse seines Senders ins Flash.


Der Findungsvorgang von 2 bereits verheirateten Sende/Empfängermodulen kann ich mir so vorstellen:

Auch beim Einschalten sollten beide Module sich erst mal auf einem festen Kanal treffen.
Andernfalls müsste im Sender eine Map im Flash angelegt werden, auf welchem Kanal er mit welchem Empfänger zuletzt gesprochen hat, und die periodisch abscannen ob er irgendwo eine bekannte MAC aus seiner Tabelle findet.

Einschalten Sendersicht
Der Sender führt beim Einschalten einen Energiescann durch das ISM Band durch.
Es wird hierbei der Kanal identfiziert, welcher für die spätere Übertragung genutzt werden soll.
Danach wird auf dem festen Verheiratungskanal solange gebroadcastet, bis sich hier ein Empfänger meldet und meint den Sender zu kennen (Verheiratungsdaten liegen im Empfänger). Nach der Kontaktaufnahme durch den Empfänger meldet der Sender den Kanal dem Empfänger, welchen er beim Energiescan für beide heraus geguckt hat. Nach dem Wechsel in den MM=1 Mode, finden sich nun beide hier wieder.

Einschalten Empfängersicht
Der gleiche Vorgang wie beim Verheiraten, bloss wegen der bereits gelernten MAC und dem anderen Schlüsselwort im Frame, kann es nach dem Hallo gleich in den vorgeschlagenen Kanal und den MM=1 Mode gehen.

Nachdenke könnte man auch noch über den 16Bit Mode, um Bytes zu sparen.

Was haltet ihr davon?
Gruß

Thomas

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Space« (2. November 2007, 22:16)


wurpfel1

RCLine User

Wohnort: CH-rheintal

  • Nachricht senden

13

Samstag, 3. November 2007, 00:28

hi leutz


man kann das paaren so kompliziert machen wie man will, es ist aber nicht unbedingt notwendig so rumzudrucksen ;)


im APImode wird das ziel benötigt, mehr nicht.
normalerweise kennt man seine hardware und notiert sich die MAC-
adresse.
nun gibt man die an der vorgesehener stelle ein und gut ist.
das macht man bestenfalls ein mal :w



falls zb ein einheitliches protokoll genutzt wird besteht vermehrter bedarf das ziel zu wechseln um das modell vom kumpel zu steuern.
sowas ist aber mit einer SDcard irgendwie einfach zu lösen..



es ist ein weiterer vorteil des alles-im-modell ansatzes: man kann die adresse für alle modelle gleich wählen ;) obwohl verschiedene HW verwendet wird:
das XBEE kann getauft werden, man muss nicht unbedingt die HW-MAC verwenden :evil:



PS
wenn knöpfe am modul gedrückt werden müssen ist das ein zeichen altertümlicher HW.. oder konfiguriert einer von euch den ADSLmodem/router mit tasten???


PSPS
man muss sich nicht unbedingt einen kopf über die funktechnische seite machen:
es funzt einfach :shy:
bin schon zu alt zum spielen.. macht aber gleichwohl spass ;-)

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »wurpfel1« (3. November 2007, 00:33)


Space

RCLine User

  • »Space« ist der Autor dieses Themas

Wohnort: Hasloh b. Hamburg

  • Nachricht senden

14

Sonntag, 4. November 2007, 01:51

Also ehrlich gesagt drücke ich lieber einmalig einen Knopf, um den neuen Empfänger in Betrieb zu nehemn. Eine SD Card beschreiben und in den Sender/Empfänger stecken ist sicherlich nichts für die Masse der Modellflieger :w .

Der Ansatz die MAC's der Module zu überschreiben ist nicht schlecht, birgt allerdings irgendwann die Gefahr das es zu MAC Doppelbelegungen am Hang kommen kann, wenn diese manuell vom User eingegeben werden können.
Meiner Meinung nach sollte man aber gleich mit den 16Bit MAC's arbeiten um Bytes zu sparen. Die 64Bit MAC vs 16 BIT MAC spart 6Bytes. Diese 6 Bytes sind ja schon die Nutzdaten von 6 (3 bei 1024) Servokanälen.


Gruß

Thomas
Gruß

Thomas

Dante

RCLine User

Wohnort: Rheinknie

  • Nachricht senden

15

Sonntag, 4. November 2007, 11:20

Space:
Scheuklappen ablegen!
Es gibt nicht nur Modellflieger. Rennautos, LKWs, BAufahrzeuge, Rennboote, Funktionsboote, UBoote und übrigends auch Lokomotiven können mit 2G4 ferngesteuert werden. Und die alle haben ernstes Interesse an XBees, weil die x Servos und x Schaltfunktionen benötigen und die XBees entsprechend bieten...

Leo
Trollfilter: Ein

Space

RCLine User

  • »Space« ist der Autor dieses Themas

Wohnort: Hasloh b. Hamburg

  • Nachricht senden

16

Sonntag, 4. November 2007, 13:17

Die Scheuklappen sind selbst auferlegt :w

Es geht im ersten Step um die Ablösung der herkömmlichen Sendermodule/Empfänger.
Wenn ich gleich versuche alle technisch möglichen Spielereien hierbei mit einzuplanen, so werde ich nie anfangen etwas praktisches zu realisieren.
Die Istaufnahme der Wunschliste als auch die Überlegung wie ich die vielen Wünsche unter einen technischen Hut bekomme, lassen so ein Vorhaben sofort scheitern.

Aber auch hinter den Scheuklappen ist ein gewisser Weitblick 8) . Das Datenformat wird darauf ausgelegt das es nicht nur Fernsteuerdaten transportiert. Über die vorgesehenen Layer3 Adressierung kann so über die Funkstrecke direkt adressierte Daten zu einem Erweiterungsfunktion übertragen werden. Der Empfänger ist als Router zu begreifen.
Beispiel:
Daten welche an die L3 Adresse 13 adressiert werden, könnten dann vom Empfänger transparent an die I2C ID 3 durchgeroutet werden. Das ganze auf Wunsch mit Empfangsbestätigung (Ack, ich vermeide jetzt mal den Begriff (TCP) oder ohne Ack.

Es sind so ziehmlich an allen mir bisher bekannten Hardwareentwürfen freie I2C oder RS232 Schnittstellen am Sender als auch am Empfänger vorgesehen (Ausnahme zB Slowflyer-RX). Hier sind spezielle Erweiterungen, jederzeit ankoppelbar. Übrigends auch SD Karten....

In meinen Augen ist der beste Weg erstmal die Grundanforderung (sicher fernsteuern) zu erfüllen und hierbei Schnittstellen für individuelle Wünsche vorzusehen, sich aber nicht abhängig von diesen zu machen.
Gruß

Thomas