Genormtes Übertragungsprotokoll für 2,4 GHz

Hallo,

Nachdem es bereits im RCLine Forum einen solchen Thread gibt, sollte es auch hier die Möglichkeit geben, Ideen zu sammeln und einzubringen.

Mit Erlaubnis von Bruno Eberle zitiere ich mal den dortigen Eröffnungsbeitrag:

Es geht darum, dass wir ein Zeichen setzen und unsere Vorstellungen für ein einheitliches und herstellerübergreifendes, kompatibles RC System andenken welches dieselbe Kompatibilität aufweist wie wir es von den PPM Systemen her gewohnt sind.

JEDER von Euch soll jetzt in einer Art Brain Storming hier seine Gedanken äussern was es seiner Meinung nach braucht.
Man kann dabei alles in dasselbe Protokoll integrieren ohne etwas anderes auszuschliessen.
Damit Ihr besser versteht was ich meine führe ich das Beispiel der Mehrzugsteuerungen bei den Modellbahnen an. Als Beispiel dazu soll die Anleitung des Lokempfängers MX 64 dienen.

Das PDF ist hier: http://www.zimo.at/web2007/pdf/MX620MX63MX64.pdf

Ich stelle mir vor, dass man sehr kleine Empfänger für Slowflyer bis zu grossen 10 Kanalempfängern, oder mehr, bauen kann welche alle dasselbe Grunddatenprotokoll haben.
Also Gas, Höhe, Seite, Quer und 2 bis vier weitere Propkanäle. Dann dazu 15 bis 20 einfache Schaltkanäle welche nur einen Status ausgeben.

Weitergehend sollen Empfänger mit normalen PPM (PWM) Ausgängen, solche mit PPM und einem neu zu definierenden "Servobus" sowie Empfänger nur mit Servobus möglich sein.
So kann man die bisherigen Servos weiterverwenden und auf Migrationsbasis die neue Generation Servos einführen. PPM und Servobus funktionieren parallel.
Die neu zu entwerfenden Servos wären dann von der Stromversorgung am Empfänger abgekoppelt und Spannungen bis 12 Volt würden möglich.

Die Servos wären adressierbar wie das heute mit MAC Nummern oder IP Adressen der Fall ist. Ebenso die Empfänger bei denen man die Ausgänge via USB ab PC oder RC Sender frei konfigurieren könnte wie man das von den neuen Schulze Alpha u. A. her gewohnt ist. Also Fail Safe usw.
An Funktionsvielfalt sind theoretisch keine Grenzen gesetzt weil man dann wie bei den MZS mittels CV's weitere Features implementieren könnte. Dies würde wie bei den Modellbahnherstellern einen gewaltigen Entwicklungsschub einleiten weil dann Dank genormten Datenprotokoll Alle ihre Ideen einfliessen lassen könnten. Im PC Bereich ist das mit LINUX vergleichbar.

Stellen wir also unsere Wünsche zusammen. In der zweiten Phase werden wir einen offenen Brief an Graupner, ACT, Schulze, FUTABA, Multiplex/HiTEC, SANWA usw. schicken. Das heisst, jeder schickt ein Mail mit demselben Inhalt.

Ich bitte diejenigen unter Euch welche auch in anderen Foren schreiben meine Initiative dort auch zu verbreiten. Ich bin nur hier angemeldet.

- 10 Prop Kanäle

~ 20 Schaltkanäle

- Servobus

- Servo mit BUS und PWM erkennung sowie separater Starkstromstecker für grosse Servos

-Empfänger mit BUS, PWM/BUS ode rnur PWM mit unterschiedlich vielen Kanälen

Bedenkt bitte, dass es hier darum geht ALLE Sparten des RC Modellbaus abzudecken. Man kann also dann Sender für Flugzeuge, Lastwagen, Schiffe usw. bauen.
Flugzeuge hätten 10 Propkanäle, Lastwagen vielleicht nur deren 4 aber dafür 20 Schaltkanäle usw.

Die Zeit ist mehr als reif um die RC Technik endlich auch ins neue Jahrtausend herüberzuholen.

Je mehr mitmachen, desto grösser ist der Druck. Ich bin mir aber klar, dass wir Niemand zwingen könne, zu reden wird es aber allesmal geben.

Gruß Gerd

10 Prop Kanäle
Meinst du 10 Servo ausgänge oder 10 Funktionen am Sender?
Weil 10 Sevoausgänge sind definitiv zu wenig!

Hallo,
diese Initiative ist sehr gut, ich werde die in jedem Fall per Mail /Brief unterstützen.
Bitte informiere mich, wenn ihr soweit seit, mit einer Mail oder PN, ich werde mich am Thread selbst eher sehr wenig beteiligen. Mir ist letztlich die Normung selbst egal, wichtig ist nur das die Kompatibilität bei erhaltener Flexibilität erreicht wird.

Lasst bei eurer Initiative, aber bitte nicht außer Acht, das auch die verbesserte Zuverlässigkeit mit angesprochen wird.
Die beste Norm nutzt nichts, wenn es an der ESD Festigkeit oder der Störfestigkeit des Systems happert.

Überlegt euch auch, wie sich eine möglicherweise komplexe Normung auf die Zuverlässigkeit auswirken kann.

Ich meine damit zB, das die Störneigung mit steigender Datenrate ebenfalls deutlich steigt.

Weniger kann daher auch mal mehr (Sicherheit) sein.

Zudem ist bei steigender Datenrate womöglich auch eine Störanfälligere komplexere Datenverarbeitung und elektronische Packungsdichte nötig. Auch das erhöht die Stör und Ausfallnaigung eines Systems.
Zumindest muss dann zum Ausgleich die Bereitschaft da sein, in zB. gscheite Spannungsregler und höherwertige Elektronik und MCs zu investieren. Auch da kann eine Normen oder Richtlinie als Vorgabe sehr hilfreich sein.

Anregen möchte ich noch, um sich hier nicht völlig tot zu diskutieren und den Zeitablauf zu straffen, gleich am Anfang einen allgemeiner gehaltenen offenen Brief an die Hersteller gehen zu lassen, der es denen mit einigen Eckdaten selbst überlässt, wie sie normieren, also lediglich darauf drängt zu normieren sich aber an dieser Diskussion umfassend mit zu beteiligen. Geheim ist das ja eh nicht, also lieber gleich richtig als nur Theoriegeschwafel, das meist ungehört verpufft.

Eine Antwort darauf, die ja sicherlich kommen wird, kann dann in weitere zielgerichtetere Aktivitäten mit einfließen.
Zudem halte ich das taktisch und psychologisch für klüger.
Auch erfährt man dann gleich zu Anfang viel mehr über die Geisteshaltung der Hersteller zum Thema (auch keine Antwort ist eine Antwort), und man kann entsprechend reagieren. Bei aktiver Aufnahme und Beteiligung derer werden dann uU auch Anregungen kommen.

Bei Graupner rate ich dringend dazu, ein erstes derartiges Schreiben, an Herrn Gebhard den technischen Leiter zu richten.

Sofern die/ein Hersteller insgesamt Mauern, könnte man als Alternative Prüfrichtlinien und ein Anforderungsprofil allgemeiner Art als Mindesttestkriterien erarbeiten, das zB bei den Tests der Fachzeitschriften zugrunde gelegt werden sollte.
Da sich unsere Fachbverbände mit derartigem seit Jahrzehnten nicht gerade hervor tun, können wir solches durchaus selbst ins Rollen bringen.

Daher, wendet euch gleich mit einem ersten offenen Brief auch an unsere Fachzeitschriften.
Ich bin mir ziemlich sicher, das ihr beim Winnie Ohlgart und seinen Fachkollegen offene Türen einrennt.
Also nicht an die Geschäftsleitungen adressieren, sondern zuerst an die Fachredakteure die sich selbst im Modellsport betätigen.
Dieses erhöht auch beträchtlich den Druck auf die Hersteller, denn diese müssen bei Nichtbeteiligung befürchten, das ihnen dann die Felle wegschwimmen und sie bei Nichtbeteiligung außen vor bleiben, sie aber an von uns vorgegebenen Richtlinien öffentlich sichtbar gemessen werden.

Solche Richtlinien, könnten dann zu einem späteren Zeitpunkt zu einer Normierung auch von zu erfüllenden Mindestanforderungen bzw Sicherheitskriterien führen. Wobei insgesamt die Sicherheit an erster Stelle stehen muss. das erzwingt schon unser derzeitiges negatives Gesellschaftliches Image. Der Genehmigungsfreude in Politik und bei Behörden, wäre eine deutlich erkennbar höhere Zuverlässigkeit des Modellsports wirklich sehr zuträglich.

Gruß
Eberhard

Hallo Peter,

Wir sprechen von bis zu 12 Proportionalkanälen und einer zusätzlichen Sammlung an Schaltkanälen, alle natürlich je nach Empfängergröße als Servoausgänge verfügbar.

Hallo Eberhard,

Bruno liest mit und baut alle Vorschläge gleich in den PDF-Brief ein. Hier gibt's wieder eine neue Version davon.

Du scheinst ja einige geeignete Adressaten zu kennen. Kannst Du mir deren Adressen per PN zukommen lassen?

Gruß Gerd

Wenn wir schon ein offenes Protokoll diskutieren, würde ich nicht gleich zu Anfang die Kanalzahl auf einen Wer limitieren, der für einige bereits zu tief ist.

Warum nicht das Protokoll so offen auslegen, dass die Kanalzahl eben variabel ist? Dann im ersten Teil des Protokolls das Format übermitteln. So in der Art:

"Hallo Empfänger, Du bekommst von mir jetzt 4 Propkanäle und zwei Schlatfunktionen geschickt! Ich beginne - JETZT!"

Das hat auch den Vorteil, dass die Latenzzeit-Fetischisten die Kanalzahl und damit die Telegrammlänge und die Latenz minimieren können.

Hmm, naja, du mußt ja mitteilen welche Propkanäle und welche Schaltkanäle übertragen werden. Wenn du dazu Statusworte benutzt mußt du deren Aufbau vorher festlegen und wenn davon eines verschütt geht ist der komplette Frame weg.
Wenn du die Servo oder Schaltfunktion so überträgst das die zusätzlich die Servo- oder noch besser die Funktionsnummer enthalten ist dann kannste ohne komplette Frames basteln zu müssen, und im Fehlerfall auch komplett zu verlieren, relativ frei Funktionsgruppen übertragen wenn es notwendig ist und Schaltkanäle immer dann wenn Zeit bleibt.
Transfer on demand sozusagen.
Ab und zu ein wenig Statuspingpong und die Latenz bleibt gering ohne in ein festes Framegerüst gequetscht werden zu müssen welches dann, wenn etwas auftaucht was man nicht vorhergesehen hat, zum Korsett mutiert.
Ich denke Wurpfels Ansatz sich zu entscheiden ob man servoorientiert oder funktionsorientiert arbeiten will ist schon ok.

Hi,

Wo ist das Problem?

1. Beim Pairing übermittelt der Sender dem Empfänger eine Liste von Tags und Feldgrössen, welche das Frame dann bilden. Die Tags bestimmen die Kanäle und die Feldgrössen die Genauigkeit der Fixpoint-Werte (8, 12 16 bit z.b.). Der Empfänger quitiert dies durch ein ACK. In der Deluxe-Ausführung werden mehrere Frames definiert, z.b. nur eines das die QR / SR und HR transportiert.

=>
<TAG "QR"><GRÖSSE 16 BIT>
<TAG "SR"><GRÖSSE 16 BIT>
<TAG "HR"><GRÖSSE 16 BIT>
<TAG "DR"><GRÖSSE 12 BIT> % Drossel
<TAG "GR"><GROESSE 1 BIT> % Gear
<TAG "S1"><GRÖESSE 1 BIT> % Sonderfunktion 1
...

<= <ACK>



2. Der Sender sendet nun seine Frames heraus

=> <HEADER><FRAMEID><SEQUENCENO><WERT1><WERT2><WERT3>...<CRC><TRAILER>

Empfänger quitiert asynchron mit der letzen erfolgreich empfangenen SEQUENCENO. Wird lange (im 10 ms Bereich) keine Quittung empfangen so werden volle Frames gesendet (um ein vollständiges Update zu garantieren).

BTW Anlagen ID ist im HEADER

Damit ist die Kanalzahl absolut variabel und für Änderungen von Einzelkanälen können 'optimierte' Frames gesendet werden und die Bandbreite gut ausnutzen.

Grüße

Frank

Begrüßenswerte Initiative

Begrüßenswerte Initiative

Hätte dazu aber eine Frage, wie würde dann FailSafe implementiert werden?, und zwar getrennt programmierbar für jeden einzelnen Kanal?, so wie das (S)PCM, G3 und andere Systeme bieten, für viele wär das sonst ein Ausschließungsgrund ...


Danke und Grüße

Spunki

@BZFrank

Kein Problem.
Klingt gut.
Du hast dir was dabei gedacht.

Hallo,

Großartige Idee!

Ich bin dabei. Habe aber leider nur sehr wenig Fachkenntnis im Bereich Funk.

Was mir aber spontan dazu einfällt:

Wie kann man die Kanalzahl limitieren? Die Hersteller wollen doch immer 6-, 7-, 9-, 12-, n-Kanal Anlagen anbieten.

Oder kann man das System so auslegen, dass eine festgelegte Bandbreite je nach Anforderungen für unterschiedlich viele Kanäle genutzt wird?



PS: das System sollte auch genügend "Luft nach oben" haben. Also nicht irgendwelche unnötigen Beschränkungen wo mehr möglich ist, nur weil man heute keinen Bedarf dafür sieht. Wer weiß, wie der Bedarf in 10-20 Jahren aussieht?

hi Frank

die funkmodule besitzen eigene intelligenz: wie etwas übertragen wird muss einem nicht weiter kümmern, dafür hat man bezahlt!.
gepaart wird eigentlich ein einziges mal: dem bediengerät wird mitgeteilt dass die adresseAABBZZRR ein autorisierter teilnehmer ist.

die empfangsstärke kann bei jedem modul ausgegeben werden, einige besitzen zb eine PWMausgabe der RSSI an einem pin.




ich poste hier nicht nochmals die ganze idee der sollwertübertragung, ganz kurz:

das bodengerät kommuniziert die knüppel- und schalterstellung dem anderen autorisierten teilnehmer zb alle 20ms.
im modell werden diesen stellungen die einzelnen servobewegungen zugewiesen. ebenso werden drehrichtung und wegbegrenzung hier gespeichert.



dadurch ist es völlig unabhängig vom typ der funkstrecke oder der anzahl servos!



beispiele, es wurde die GRAUPNERzuordnung gewählt, FUTABA oder völlig frei geht auch
AMIGO mit SR, flautenschieber und HR
steckplatz vier, eins und drei, los gehts!

QRtrainer
gas auf 1, HR ist 3 und SR auf 4
QR links heisst servosteckplatz2 geht auf 100% oben, stecklatz5 auf 65% runter. dieser wert kann in der luft verstellt werden..

achtklappensegler
SR 4, HR 3, radbremse, fahrwerk, vario und kupplung im rumpf
QR wirkt auf 10servos, je flügel 2stk WK, innenklappe, aussenklappe und spoiler (nur nach oben)
in jedem flügel sitzt ein "verteiler" der die fünf servos mit einem eigenen BEC versorgt. nur vier drähte leiten energie und signale vom funkmodul zum verteiler aka busknoten.




es wird nur das wichtige übertragen: die sollstellung der knüppel
der rest ist im modell festgelegt und muss nicht mit jedem frame übertragen werden.


oder ändert wer beim fliegen die zuordnung der steckplätze? zb SRservo ans HR???
das macht man vernünftigerweise am boden...



ich übertrage je 256positionen pro knüppel, insgesamt 5Byte pro übertragung. um overhead zu sparen wähle ich eine fixe reihenfolge der knüppel: SR, GAS, HR, QR und den REST (zb poti und sieben schalter im multiplex). so bleibt viel kapazität für zb telemetrie, video und bilder..

das verfahren der sollwertübertragung ist auch mit normalen 35/40MHz anlagen durchführbar!
mit meiner uralten SIMPROP SAM werden fünf infoByte plus drei absicherungsByte übertragen, mit einem 8kanalRX empfangen und durch ein aufgesteckter decoder in bewegungsbefehle für BELIEBIG VIELE servos umgewandelt.

die bewegungsgenauigkeit und -qualität sowie die trimmlage/nullposition erreichen 10bit, mit OPENSERVO sind es dann 16bit bewegungsgenauigkeit.

Die Failsafeeinstellungen können ebenso beim Pairing übermittelt werden, das ist dann nur eine kleine Erweiterung des Protokolls:

<TAG><WERTGROESSE><FAILSAFE J/N> [<FAILSAVEAUSLÖSEZEIT><FAILSAFESTELLUNG>]

Alternativ (Deluxe Ausführung) in Form eines extra FAILSAVE Frames zur Laufzeit. Aber ich denke so oft stellt man Failsave nicht um.

Wurpfel - deshalb wird das beim Pairing festgelegt. Damit ist man maximal flexibel. Wenn schon Intelligenz im System dann sollte man sie ausnutzen.

FailSafe

FailSafe

Vielen Dank Frank

Nur, wie programmiert man dann FailSafe übers Protokoll?, bei (S)PCM passiert das ja komfortabel im Sender (eigener Menüpunkt), bei Eurem System muss ja der Sender im Modus-PPM betrieben werden, im Modus-PPM bieten die Sender allerdings kein FailSafe-Menü an

Wie auch immer, auch der beste Sender kann mal ausfallen, gibt genug Beispiele hier, ich rede da jetzt gar nicht mal von einem komplexen Jet, Beispiel große kräftige Schleppmaschine: wer drosselt mir den Motor?, setzt die Landeklappen?, stellt die Ruder auf neutral und macht die Schleppkupplung auf?


Danke und Grüße

Spunki

Hallo zusammen,

Ich bin jetzt also auch hier zu treffen.

Vielen Dank erstmal für eure interessanten Inputs. Der Ansatz von BZFrank ist sehr interessant.
Wo ich aber Bedenken habe ist, wenn die Frames zu komplex werden ist deren Störanfälligkeit leider auch höher. Somit müssen wir unbedingt darauf achten, dass wir einfache und robuste Frames senden.
Die Quittierung des Empfängers kann man als Option offen halten. Wir dürfen aber nicht vergessen, dass es ein Datenprotokoll wird welches Nicht für Freaks alleine geschaffen werden kann und darf. Die kleinen 3 - Servo Sender müssen genau gleich eingebunden werden wie die Luxussender T-14 und MC 24.
Die Anzahl der Kanäle muss frei einstellbar sein und nur soviele dürfen gesendet werden wie man wirklich braucht. Der Blödsinn bei PPM wo man immer alle Kanäle sendet, selbst die wo gar Nichts angeschlossen ist, ist nicht mehr nötig da jeder Kanal seine eigene Adresse haben wird. Auch dies ist eine Grund für mich von komplexen Datensätzen, welche nur die Gesamtinformation senden,abzusehen

Ich habe im RCL einen Vergleich mit den MZS der Modellbahner gemacht. Wer will kann einmal die Anleitungen bei http://www.zimo.at studieren. Klar hinkt der Vergleich, eine Modellbahn muss 1000 Mal mehr können aber ich will die Richtung vorgeben. Dabei ist gerade Herr Dr. Ziegler von ZIMO einer der besten Fachleute überhaupt. Trotz der heute praktisch unüberschuabaren Komplexität der MZS wir immer noch an die ganz kleine Spur N gedacht wo einfachste Empfänger arbeiten welche aber dasselbe Protokoll bekommen wie die grossen Lokdecoder für Gartenbahnen mit einer schier unendlichen Konfigurationsvielfalt.

Die RC Industrie muss etwas Vergleichbares und geauso flexibles auf den Markt bringen welches ALLE Bedürfnisse abdeckt. Nur so sind grosse Stückzahlen machbar. Die Freaks unter Euch können dann Dank genormten Protokoll selber ihre raffinierten Lösungen realisieren. Bei den MZS ist das der Fall. Dort gibt es unzählige Selbstbauprojekte welche weltweit kompatibel betrieben werden können.

Ich hoffe Ihr versteht ein wenig was ich bezwecken will. Ihr könnt mir glauben, es tut sich was im Hintergrund und meine Initiative soll den Bestrebungen Auftrieb verleihen und den Leuten welche dahinterstecken den Rücken stärken.

Ich bitte Euch jetzt nicht die kompliziertesten und raffiniertesten Codierungen auszudenken. Ich bitte Euch, dass Ihr mein Vorhaben unterstützt und die Initiative per Mail an möglichst viele Hersteller und Lieferanten schickt. Am Entwurf des genormten Protokolls arbeiten gute Leute und ich bin überzeugt, dass da alle Eure Vorstellungen auch mit Drin sind.

Nur mal so nebenbei.
Eine fail safe Programmierung jedes einzelnen Kanals lässt sich sehr einfach auch bei primitiven Protokollen implementieren. Als Beispiel soll eine (luxuriöse) 16 Bit Auflösung des Servossiganls dienen. Man sendet dazu einen Wert zwischen HEX 01 und HEX FE als Daten für die Stellung des Servos. Folgt anschliessend der Wert HEX FF wird der vorhergehende Wert im Empfänger als fail safe gespeichert. Will man das fail safe aufheben sendet man HEX 00 und der Speicher wird gelöscht.
Einfach, primitiv und funktioniert. Es muss nicht so sein, aber es kann so sein.
Löst man nur mit 14 Bit auf gibt es noch viel mehr Möglichkeiten irgendwelche Funktionen in den Daten zu verstecken. Ich persönlich halte 12 bit als vollkommen ausreichend

Vor etwas mehr als 10 Jahren was das DCC Signal der MZS auch sehr einfach gehalten. Heute ist es hochkompliziert und trotzdem können ALLE bisherigen DCC Lokempfänger damit angesteuert werden. Der Vorteil bei den Modellbahnern ist, dass es die NMRA gibt wo man periodisch zusammensitzt und die Normung festlegt. Sowas fehlt bei der RC Industrie weitgehend bis ganz.
Ladet das PDF bei RCL herunter und lest es durch. Macht bitte noch Vorschläge. Grammatikalisch wird es noch korrigiert, es hat noch Fehler drin.

Ich bitte Eberhard Mauck und alle anderen nun mir die Adressen der zuständigen Leute zu schicken. Ebeso müssen wir diese Initiative an alle Fachzeitschriften schicken.

Ich bitte Euch, macht mit, wir können rein gar Nichts verlieren, wir können nur gewinnen.

Vielen Dank!

Bruno

Mit dem Konzept der Gebersollwertübertragung muss die Intelligenz (auch Failsafe) dann zwangsläufig im Empfänger sitzen; entsprechend den ACT-Empfängern. Was dann da wieder ein Programmiergerät verlangt.

Und mich als MPX Piloten gewaltig vergräzt, auf die Funktionalität kann ich in einem Empfänger lange warten...

So gesehen ist das ein radikaler Bruch mit den bisherigen Ansätzen, was dem Erfolg nicht gerade zuträglich ist.

Ausserdem macht es den Empfänger (als das mehrfach zu kaufende Teil) teuer. (Ich weiss, letzteres muss bei den heutigen Hardware-Preisen nicht sein. Die Erfahrung zeigt aber, dass sich die Entwickler solche Fähigkeiten zahlen lassen.)

Failsafe ist eigentlich eine einfache Übung.

Da man ja irgendwann dem Empfänger sagen muß welche Servos an welcher Schnittstelle er bedienen soll kann man ihm auch sagen das die derzeit eingestellten Werte, kann man ja vorher übertragen, in einer Schattentabelle abgelegt werden sollen und im Zweifelsfalle den Failsafewerten entsprechen. Das könnte man dann sogar während des Fluges machen oder halt am Boden. Da reicht dann eine spezielle Anweisung oder ein spezieller Frame.

Das geht sogar bei PPM oder PCM und wenn man eine entsprechende Taste am Sendemodul vorsieht sogar mit ganz unintelligenten Sendern. Der Empfänger ist dann der Hyperintelligente.

MarkusN schrieb:

Ausserdem macht es den Empfänger (als das mehrfach zu kaufende Teil) teuer.

Zum Vergrößern anklicken....

Eigentlich nicht. Wenn man vom Mehraufwand für die Programmierung mal absieht.

Die intelligenten Empfänger kannst du aber auch genau so betreiben wie einen dummen Empfänger. Du mußt dann halt alles am Sender managen hast aber im Gegenzug das Problem das du bei einem 4 Klappenflügel eben 4 Servos übertragen mußt um z.B. die Wölbung zu ändern oder du machst es eben so wie Wurpfel sagt und überträgst einen Wert für die Funktion Wölbung und der Empfänger kümmert sich um die entsprechende Entflechtung für die Servoausgänge.

Ehrlich gesagt, um die Programmierung mach ich mir (noch) keine Sorgen. Eher schon darum was da alles für Wünsche entstehen werden an die noch niemand dachte.

sidigonzales schrieb:

...wenn man eine entsprechende Taste am Sendemodul vorsieht sogar mit ganz unintelligenten Sendern. Der Empfänger ist dann der Hyperintelligente.

Zum Vergrößern anklicken....

Wäre es nicht besser, die Intelligenz in den Sender zu stecken und den Empfänger möglichst einfach auszulegen?

Alt-F4 schrieb:

Wäre es nicht besser, die Intelligenz in den Sender zu stecken und den Empfänger möglichst einfach auszulegen?

Zum Vergrößern anklicken....

Was dafür spricht:
Bestehende Sender und Entwicklung, die da hinein geflossen ist, können weiter verwendet werden.
Das Intelligente Gerät wird nur einmal benötigt.
Man kann das Teil mit "Bling-Bling" für jeden sichtbar vor dem Bauch herumtragen. (Der Faktor sollte nicht unterschätzt werden.)

Was dagegen spricht:
Das Übertragungsprotokoll, das über die Funkstrecke muss, wird deutlich komplexer.