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

Montag, 19. November 2007, 22:38

2,4 GHZ RC-Line: Protokolldefinition

ich habe hier den ersten Wurf der Definitionen für ein universelles und offenes Datenprotokoll abgelegt:


DOC
HTML

Empfohlen wird das Doc Format, da die eingebetteten XLS hier direkt editierbar sind.

Meine Hoffnung ist alle Ideengeber und bisherigen Eigenetwickler mit ihren bisher probrietären Formaten (open2.4 ist ja auch noch probrietär), mit dem Format anzusprechen und hinter den selben Strang zu bekommen.

Anderungs/Verbesserung -Wünsche sind ausdrücklich erwünscht. Aber bitte hierbei die Prämisse nach Abwärtkompatiblität zur vorhanden Fernsteuerkomponenten nicht vergessen :w andernfalls sind sicherlich 90% aller poteziellen Anwender schon bei der Konkurenz. Auch beachten sollte man das nicht alles was technisch geht, auch wirklich benötigt/akzeptiert wird.



Thomas
Gruß

Thomas

wurpfel1

RCLine User

Wohnort: CH-rheintal

  • Nachricht senden

2

Dienstag, 20. November 2007, 09:51

Hi Thomas

schöne arbeit!


da sind wir uns einig:

kernaufgabe
bei flugmodellen sind das vier achsen und eine handvoll schalter die zeitkritisch rauf müssen sowie einige einstellpoties/sonderfunktionen die etwas mehr trödeln dürfen.


bei autos und schiffen ist das verhältnis zeitkritisch/unkritisch noch ausgeprägter :nuts:



nebenaufgaben
die funkstrecke, der bordakku und das antriebssystem soll überwacht werden.
ev. sind die position, speed, höhe und beschleunigungen interessant.
die daten werden ins openformat konvertiert, mit zeitstempel versehen und gesendet.





nun einige vorschläge:

:w trenne struktur- von infodaten, trenne dich vor allem von den einschränkungen der xxMHz-welt :angel:



halte das protokoll frei von funkkäferspezifischem: frequenzwechsel, binding usw. definiert man besser woanders ;)
der nächste funkkäfertyp wartet bereits an der nächsten ecke..

gehe davon aus dass die info vom funkmodul korrekt geliefert wird. das ganze handling mit hoppen, FEC, binding und validierung wird im busmaster/funkmodul erledigt.

mit FEC kann info gezielt verworfen und auf neue gewartet werden. spätestens nach 20ms kommt ja die neue, wieso den rückkanal belasten??
nichts ist überflüssiger als die zeitung von gestern :wall:







wenn du den ansatz "alle intelligenz im modell" verfolgst müssen keinerlei strukturdaten hoch, das modell verändert sich (meistens :evil: ) nicht wärend der laufzeit.
es werden nur infos hochgesendet die sich ändern! die werden dann im modell zu den einzelnen funktionen/servos/taster verteilt. ich habe die form einer routertabelle gewählt, sie bildet die struktur des modells ab.
bin schon zu alt zum spielen.. macht aber gleichwohl spass ;-)

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »wurpfel1« (20. November 2007, 09:53)


Space

RCLine User

  • »Space« ist der Autor dieses Themas

Wohnort: Hasloh b. Hamburg

  • Nachricht senden

3

Dienstag, 20. November 2007, 13:09

Hallo Wurpfel, vielen Dank für deine Anmerkungen.

Ich denke aber du siehst derzeit schon zuviel in dem Dokument.
Die Protokolldefinition geht (bisher) aber noch gar nicht auf den/die von dir angesprochene Punkte ein. Was du ansprichst spielt sich Hauptsächlich in den DATA Bytes ab.

Welche Servodaten, ob diese inkrementell, also nur Deltas gegenüber dem letzten bestätigten Datenpaket übertragen werden, mit oder ohne ACK versendet werden ist (noch) gar nicht definiert.
Ich bin hier deiner Meinung, dass man „alte Zeitungen“ nicht noch mal drucken sollte. Wohl aber kann ja schneller reagieren, wenn ich merke das meine „alte Zeitung“ nicht angekommen ist, das ich eine „neue Zeitung“ schneller Drucke und in den Vertrieb bringe. ---> schneller Resend mit neuen „frischen“ inkrementellen Daten seit dem letzten sauberen ACK Paket

Bisher ist lediglich die Hülle für den Transport definiert, mit der ich die Sender/Empfänger Hardware steuern als auch Fernsteuer oder Logdaten ungesichert oder gesichert übertragen können.

Das es nur eine Hülle ist, trifft genau so auf die Funkkäferspezifischen Dinge zu, wo die selbe Hülle für die hardwarebedingten spezifischen Notwendigkeiten zum Einsatz kommen soll.

Eine Hardwarespezifische Definition ist allerdings immer erforderlich. Was nützt sonst das schönste genormet Protokoll, wenn es in der Physik schon hakelt. Individuelle Dinge für jedes zum Einsatz kommende Funkmodul müssen also auch festgezurrt werden.
Dies wird in dem Abschnitt RX/TX Binding nur für das XBee versucht. Wenn Morgen das YBee zum Einsatz kommen soll, dann ist ein neuer Abschnitt einzufügen mit der Überschrift „Binding der YBee Module der Firma SodaStream“

Warum sollte ich denn aber die Hülle für Hardwaredinge verlassen, wenn sie mir hier alle Möglichleiten bietet?

Zitat

wenn du den ansatz "alle intelligenz im modell" verfolgst
Das lasse ich in Definition offen, welcher Ansatz gefahren werden soll. Wohl aber kann ich gezielt Strukturdaten an den Empfänger adressieren und übertragen. Übrigends auch dynamische Routingtabellen für die Adressen > 126. Das Verfahren hierfür spielt sich rein in den DATA Bytes ab und ist nicht Gegenstand der Definition und somit (erstmal) frei. Nur eben Proprietäre Bitmuster über die Line zu schicken muss vermieden werden weil sonst jeder Protokoll Stak ein Problem bekommt.

Zitat

mit FEC kann info gezielt verworfen und auf neue gewartet werden. spätestens nach 20ms kommt ja die neue, wieso den rückkanal belasten??
Wenn ich die Hardwarefunktion für Resends oder nicht Resends verwende muss ich vor jedem Datenpaket die Hardware umkonfigurieren.
Finde ich zu umständlich und zu sehr wieder mit einer speziellen Hardware verknüpft welche sich überhaupt umsteuern lässt und beide Mode unterstützt.
Auch das Verhalten der Module beim Umsteuern zwischen Resends/not Resend dürft schwer vorhersehbar werden. Oder wiesst du wie sich ein XBee verhält wenn das erste mit Resend angeforderte Paket noch nicht fehlerfrei übertragen wurde aber bereits die Umkonfiguration für das nächste Loggerdatenpaket erfolgen soll?
Den Grund warum es sinnvoll ist möglichst rasch zu erfahren ob mein letztes Datenpaket ev. nicht sauber empfangen wurde, habe ich ja schon bei dem alten Zeitungsbeispiel erläutert. Das währe sonst eben auch ein Nogo für inkrementelle Fernsteuerdaten, wenn ich nicht sicher weiss auf welchem Stand der Empfänger ist muss ich alle 20ms immer alle Daten senden.

Gruß

Thomas
Gruß

Thomas

4

Dienstag, 20. November 2007, 14:30

Hi Thomas,

viel Arbeit steckt da drin... klasse!

Leider ist meine Zeit gerade beschränkt... :wall:
Komme bei meiner Fernsteuerung nur seeeehr langsam weiter.

Trotzdem mal ein paar Anmerkungen:

Warum ein Framesync? normalerweise sollten wir doch davon ausgehen, dass wir nur Daten vom passenden Gegenüber bekommen. Außer in 3 Möglichkeiten:
- Broadcast Frame von anderem Xbee -> Wird im Betrieb ignoriert
- Zufällige Frames von anderem Xbee (seeehr unwahrscheinlich, oder?) -> sollten aufgrund ihrer Struktur bei der Überprüfung "durchfallen"
- Mutwillige Störung :no: -> Da könnte dann auch ein Framesync drin sein...
Deshalb würde ich diese 2 bytes weglassen.

Zu den Adressen:
Schon sehr weit gedacht :ok: , leider sind viele Basisfunktionen sehr allgemein gehalten und man braucht dann noch ein zusatz ID-Byte. Zum Beispiel für Signalstärke-Rückmeldung oder die wohl oft verwendete Rückmeldung Akkuspannung.
Ein paar von diesen Sachen spezifiziert, die oft vorkommen und schon hat man wiede r einige Bytes gespart.

Zusatz bei "Sequenznummer":
Bei Frames ohne ACK (Servowerte...) jeweils um eines erhöhen (oder immer?) um Paketverluste zu erkennen.

Checksummen und co:
Ich denke, dass die XBee-Module intern schon eine Art FEC oder wenigstens CS haben (weiß jemand genaueres?). Ich gehe bisher davon aus, dass ein Frame, das aus dem Modul kommt auf Funk-Übtertragungsfehler kontrolliert ist. Deshalb nur eine einfache CS (aufaddieren in 8 bit, Rest fällt weg), um mögliche Fehler auf dem Weg Xbee->Atmega abzufangen. Müsste man aber genau wissen...

Zum Binding:
Steht hier fast identisch auf einem meiner Schmierzettel :D , scheint also vom Gedanken her das logischste zu sein...
Noch eine Idee zur Adressierung: 16 Bit sind zwar viel, aber nicht so viel, dass man "unendlich" viele Adressen hat. Meine Idee war, die PAN (Personal Area Network) als zusätzliche Adressierung zu verwenden. Das sind auch nochmal 16 bit. Die bei allen gleich zu lassen wäre ja Verschwendung... Und ein Broadcast kann man auch da machen. ergibt dann 32 bit, das sollte reichen 8)

In die Kanalwechselgeschichte muss wohl noch etwas Denkzeit und Experimente fließen, da das ja leider nicht im XBee vorgesehen ist...

Also denn

Fröhliches Basteln

Gruß

Marc

Bruchflieger

RCLine User

Wohnort: 18km südl. der Lutherstadt Wittenberg

Beruf: Energieelektroniker / HWK-Meister E-technik

  • Nachricht senden

5

Dienstag, 20. November 2007, 17:37

Hi Space,

nach einem langen Arbeitstag muß ich gestehen, daß ich nicht alles sofort verstanden habe, aber es sieht vielversprechend aus...


Dieses Protokoll kann 93 Nutzbytes übertragen - davon abgesehen, daß das wahrscheinlich zu lange andere Funktionen blockieren könnte, wenn man das wirklich machen würde
- Ich würde mir nur eine Sache Wünschen: Eine Möglichkeit, dem Gegenüber mitzuteilen was für Nutzdaten das Paket enthält. Da ich gern weiterhin nach dem Konzept "Alle Intelligenz im Modell" arbeiten würde, benötige ich eine Basis wie ich meine Modellspezifischen Konfigurationen im Modell vom Sender aus bearbeiten kann. Das heißt: Wenn nach dem Einschalten des Senders das Konfigurationsmenü aufgerufen wird, muß der Sender vom Modell die aktuelle konfig abfragen können. Während des editierens müssen neue Konfig.-Werte übertragen werden um die Auswirkungen zu sehen.
Daher wäre es notwendig, dem jeweiligen Empfänger mitteilen zu können, was für Nutzdaten folgen.

Ich gehe im Folgenden mal von meiner Lösung mit Datensenden und Befehle senden aus - >
Wenn ich bestimmte Aktionen im Modell oder im Sender auslösen will, muß ich ja nicht immer ein unendliches Datenpaket senden - könnte man eine Möglichkeit zum einfachen Senden von Steuerbefehlen implementieren - z.B. Datensatztyp Befehle und dann 4 "Datenbytes", bei denen jedes Bit für spezielle Befehle steht - wie Konfig in EEprom sichern! oder die Rückmeldung Eeprombrennen erfolgreich! bzw EEprombrennen fehlgeschlagen! oder was auch immer an Steuerbefehlen zu übertragen nötig werden könnte.
Da solche Befehle meist einzeln gesendet werden, würde wahrscheinlich 1 Byte reichen, wobei 254 verschiedene Befehle möglich wären (0 bzw. 255 würde ich nicht nutzen)

OK. Das erstmal von mir - muß nochmal weg...
Grüße Dani.

wurpfel1

RCLine User

Wohnort: CH-rheintal

  • Nachricht senden

6

Dienstag, 20. November 2007, 19:11

Hi Dani

benutze duch zum ändern der konfiguration einen extra-mode ;)

der wird durch einen code freigeschaltet.



man kann mehrere codes verwenden, den zum mischer in der luft verstellen ist zb sinnvollerweise ein anderer als der für die drehrichtungsumkehr und wegbegrenzung :evil:



der ablauf:
code senden (schalter 2 drücken)
nun kann mit schalter3 und 4 der mischwert der differenzierung in 1/256schritten verstellt werden
wenn fertig drückt man schalter 2
der wert ist im SRAM als variable mischerQR_dif gespeichert

nach der landung wird der brenncode gesendet, die werte landen im EEPROM :shy:
bin schon zu alt zum spielen.. macht aber gleichwohl spass ;-)

Bruchflieger

RCLine User

Wohnort: 18km südl. der Lutherstadt Wittenberg

Beruf: Energieelektroniker / HWK-Meister E-technik

  • Nachricht senden

7

Dienstag, 20. November 2007, 19:37

Hi Claude,

OK, aber auch du brauchst einen Platz im Protokoll, um den Code an das Modell auch übertragen zu können. Ob du einen "Code" überträgst oder das Kennbyte "Nutzdatentyp" nennst, ist egal... nur muß es eben irgentwie mit rauf...
Grüße Dani.

Space

RCLine User

  • »Space« ist der Autor dieses Themas

Wohnort: Hasloh b. Hamburg

  • Nachricht senden

8

Dienstag, 20. November 2007, 21:20

Zitat

Original von FunFlightMarc
Warum ein Framesync? normalerweise sollten wir doch davon ausgehen, dass wir nur Daten vom passenden Gegenüber bekommen.

Mhhh, je mehr ich über das Syncwort nachdenke, desto mehr bin ich deiner Meinung. Der Framesync ist wohl nicht zwingend erforderlich.
Eigentlich bräuchte man eine klare Erkennmarke eines Frameanfangs wohl nur bei dem ersten Frame, welchen RX/TX miteinander austauschen oder aber wenn verstümmelte Datenpakete empfangen werden. Es ist nur in diesem Fällen denkbar, das die Frameauswertung nicht ab dem ersten Byte erfolgt ---> gestrichen.

Zitat


Zu den Adressen:
Schon sehr weit gedacht :ok: , leider sind viele Basisfunktionen sehr allgemein gehalten und man braucht dann noch ein Zusatz ID-Byte. Zum Beispiel für Signalstärke-Rückmeldung oder die wohl oft verwendete Rückmeldung Akkuspannung.
Ein paar von diesen Sachen spezifiziert, die oft vorkommen und schon hat man wieder
Gute Idee, für die "most wanted" Funktionen direkte Adressen zu vergeben.
Ich war auch am überlegen ob man dem Protokoll noch eine L4 Diensteadressierung mitgibt. Das zusätzliche Byte wollte ich aber sparen. Es ist nicht ausformuliert, aber im Grunde ist es so gedacht, dass das erste DATA Byte praktisch nochmal den Dienst/Funktion,vergleichbar mit einem TCP/UDP Port im IP, definiert, welcher angesprochen wird.
Magst du dir trotz Zeitmangel mal Gedanken über eine Routingtabelle inkl. "most wanted"Dienste machen? Schickst du mir es dann per PN/MAIL, ich pflege es dann in das Masterdokument ein.

Zitat


Zusatz bei "Sequenznummer":
Bei Frames ohne ACK (Servowerte...) jeweils um eines erhöhen (oder immer?) um Paketverluste zu erkennen.
Jep, Sequenznummer sollte immer weiter gezählt werden, unabhängig vom PSACK.

Ich möchte aber hier auch noch mal zur Diskusion stellen ob es nicht doch sinnvoll ist Servodaten mit PSACK zu versenden? Der Gedanke dahinter ist der:
Wenn nach 10ms das ACK vom Sender ausbleibt, sende ich die Daten nochmal. und ich habe mir 10ms "Blindflug" :angel: erspart. Wenn das Ack noch immer ausbleibt, fange ich an die Servodaten welche sich seit dem letzten bestätigten Frame verändert haben im 10 ms Rytmus zu senden.
Wie ich finde ein Sicherheitsgewinn und eine einfache Möglichkeit der Fehlererkennung von gestörten Frames ohne das die RX -->TX Verbindung überhaupt noch funktionieren muss.
Anders betrachtet, wenn ich nur permanent nur Servodaten ohne PSACK transportiere, muss mit mittels Keepalive Paketen/RSSI Abfragen ermitteln ob der RX mich überhaupt noch versteht.
Und, in den ACK Paketen des RX kann ich ja auch gleich noch Loggerdaten transportieren.
Die Diskusion über Servodaten mit/ohne ACK ist aber losgelöst von der eigentlichen Protokolldefinition. Ist mein RX + TX das Protokoll sauber definiert arbeitet jeder RX mit jedem TX zusammen. Egal ob mit oder ohne PSACK in den Servodaten.

Zitat


Checksummen und co:
Ich denke, dass die XBee-Module intern schon eine Art FEC oder wenigstens CS haben (weiß jemand genaueres?). Ich gehe bisher davon aus, dass ein Frame, das aus dem Modul kommt auf Funk-Übtertragungsfehler kontrolliert ist. Deshalb nur eine einfache CS (aufaddieren in 8 bit, Rest fällt weg), um mögliche Fehler auf dem Weg Xbee->Atmega abzufangen. Müsste man aber genau wissen...
Ich habe mit den XBEee's noch nicht wirklich rumgespielt. Mir ist derzeit auch nicht ganz klar ob im API Mode der XBee nur Daten aus seinem Dout raussendet welche die Funkstrecke fehlerfrei passiert haben. Im XBee Transparentmode sind die Daten auf jeden Fall Checksumm gesichert, aber der Mode mach für uns ja keinen Sinn.
Ich plädiere aber trotzdem für eine zusätzliche Cklecksumme. Allein aus dem Grunde weil nicht sichergestellt ist, ob zukünftige Funkmodule eigenen Checklayer mitbringen.
Deinen Vorschlag "aufaddieren in 8 bit, Rest fällt weg" finde ich schon nicht schlecht. Um die Pariti Bits in den Servodaten nutzen zu können bräuchte man ein Verfahren welches Singlebitfehler erkennt. Kennt da jemande ein Verfahren?

Zitat


Noch eine Idee zur Adressierung: 16 Bit sind zwar viel, aber nicht so viel, dass man "unendlich" viele Adressen hat. Meine Idee war, die PAN (Personal Area Network) als zusätzliche Adressierung zu verwenden. Das sind auch nochmal 16 bit. Die bei allen gleich zu lassen wäre ja Verschwendung... Und ein Broadcast kann man auch da machen. ergibt dann 32 bit, das sollte reichen 8)

Mein Gedanke war die beiden letzten Bytes der orginal 64 Bit MAC zu nutzen. Bei der Herstellung der Funkmodule werden die ja in der Serie immer meist sequenziell vergeben..... Ab nach Murphy reicht 1/65535 nich als Sicherheit aus, als das sich nicht doch mal 2 mit der selben MAC am Hang treffen.

Ich dachte aber PAN geht nur mit Coordinator? Wenn es geht das zu nutzen währe es super :ok:

Zitat


In die Kanalwechselgeschichte muss wohl noch etwas Denkzeit und Experimente fließen, da das ja leider nicht im XBee vorgesehen ist...
Lass von dir höhren, wenn du was funktionierendes hast. Lösungsmöglichkeiten spiele auch schon seit einigen Tagen gedanklich durch. Der Durchbruch fehlt mir hier aber auch noch...

Zitat

Dieses Protokoll kann 93 Nutzbytes übertragen - davon abgesehen, daß das wahrscheinlich zu lange andere Funktionen blockieren könnte, wenn man das wirklich machen würde
Zeitbestimmend für die Bytesübertragung ist hier eher nicht die Funkverbindung der XBees sondern die UART Kommunikation zwischen XBee und dem Prozessor. Bei einer UART Geschwindigkeit von 115200 werden ~0,009sec benötigt. Das finde ich ist nicht so viel. Auf der RF Seite sollen es 250.000 Bit/s sein.

Zitat

Ich würde mir nur eine Sache Wünschen: Eine Möglichkeit, dem Gegenüber mitzuteilen was für Nutzdaten das Paket enthält.
Der Wunsch ist doch schon erfüllt. Einfach im Adressbyte des Protokolls eine Adresse für jede Funktion verwenden, welche bei dir implementiert ist. Die Routingtabelle ist ja gerade mal erst "andefiniert". Wenn als Beispiel die Adresse 123 der Funktion Trimmspeicherdaten entsprechen soll, und du auf der Welt nicht der einzige bist des so etwas nutzen möchte (den Eindruck habe ich nicht), legen wir die 123 in der Routingtabelle für die Funktion Trimmspeicherdaten fest. Möchtest du eigenen Experimente machen, ist auch ein Adressrange zur freien Verwendung noch vorhanden.

Für das Aufrufen von Funktionen, in deinem Beispiel "Speichern in EEPROM", wird dann eine Adresse definiert welche als Ansprechpartner für Funktionen der Softwarefunktion "Mischer im Empfänger/Alle Intelligenz im Modell" entspricht. Alle Bytes in den DATA Feldern des Frames werden dann dieser Softwarefunktion übergeben. Hier ist es nun dein Geschick dein eigenes Anwendungsspezifisches Protokoll zu entwerfen, welches du ja auch schon angefangen hast. eine Dezimale 88 heisst dann eben "Speichern im EEPROM"

Die Sache bekommt durch das darunter liegende Protokoll eine Struktur, wodurch ermöglicht wird das du mit deinem Sender auch das Modell von deinem Kumpel fliegen kannst, welche seine Modellintelligenz nicht in den RX ausgelagert hat.

Ups, schon wieder so lang..by

Thomas
Gruß

Thomas

Bruchflieger

RCLine User

Wohnort: 18km südl. der Lutherstadt Wittenberg

Beruf: Energieelektroniker / HWK-Meister E-technik

  • Nachricht senden

9

Dienstag, 20. November 2007, 22:53

Zitat

Original von Space
Zeitbestimmend für die Bytesübertragung ist hier eher nicht die Funkverbindung der XBees sondern die UART Kommunikation zwischen XBee und dem Prozessor. Bei einer UART Geschwindigkeit von 115200 werden ~0,009sec benötigt. Das finde ich ist nicht so viel. Auf der RF Seite sollen es 250.000 Bit/s sein.


Mhh - weiß nicht - hast du schon ausprobiert mit so hoher Datenrate?
Ich hab mein System momentan nur auf 38400 Baud (oder so ähnlich - müßte erst nachschauen aber die 38 vorn stimmt ;) ) und hatte dabei schon einige Timingprobleme, weil die Mainloop die in den Buffer übertragenen Daten nicht schnell genug verarbeiten konnte, bevor neue Daten ankamen. - Das 2,1" Grafikdisplay hat ein paar Routinen, die doch etwas bremsen, wodurch die Häufigkeit der Loop-durchläufe herabgesetzt wurde. Es ist immer noch schnell genug, aber man Merkt den Unterschied zum stinknormalen 20*4 Zeichen-Display...
Wenn ich Pech habe, muß ich meine Hardware im Sender nochmal so umstricken, daß ich 2 Prozessoren einsetze: 1* Normale Aufgaben und 1* nur für die Displayausgaben - der letztere kann sich dann ja so viel Zeit lassen, wie er will, da das Modell seine daten vom anderen µC erhält... - vielleicht mach ich das auch so, obwohl alles funzt...
Grüße Dani.

^____

RCLine User

  • »^____« wurde gesperrt

Wohnort: anonymisiert

Beruf: anonymisiert

  • Nachricht senden

10

Mittwoch, 21. November 2007, 00:36

Hallo,

Alles schön und gut. Dein Vorschlag wird mit garantierter Sicherheit aber Niemand umsetzen, ausser dir selber vielleicht. Da Du das schon alles definiert hast, liegen die Urheberrechte bei Dir. Somit kann und darf kein Hersteller Deine Vorstellungen übernehmen. Du erreichst damit genau das Gegenteil von dem, was Du eigentlich willst
Solche Ansätze sind schon oft gemacht worden und meine Initiative soll genau in diese Richtung weisen. Wie dieses standardisierte Signal aber aussehen soll, muss man den Herstellern überlassen.
Lies dazu einmal den Text meiner Initiative. Hätten wir die die rund 10'000 Unterschriften welche theoretisch möglich gewesen wären, könnte man schon etwas bewirken.

Gruss Bruno

wurpfel1

RCLine User

Wohnort: CH-rheintal

  • Nachricht senden

11

Mittwoch, 21. November 2007, 10:34

Hi Bruno


ich habe unterschrieben..

vermutlich werden wir hier etwas schneller am ziel sein:
mir reicht ein HWtyp um alles abzudecken.
und der stützt sich auf ein sehr preiswertes teil..


für sonderaufgaben nimmt man seinen grösseren, ebenso preiswerten bruder.






@Dani
die trennung in zeit (und un-)kritische prozesse verfolge ich auch im sender ;)
ich habe für telemetriedaten ebenso eine routertabelle aufgebaut. damit ist es einfach den output der sensoren zum displayknoten umzuleiten.
die daten werden bereits im modell durch den I2Csensorknoten normiert und adressiert, das display kriegt die daten vom XBEE und muss nur noch die fenster füllen..
damit reicht am boden ein prozzi aus, für analogfunkenumbauten kann man natürlich auch einen *ATt15-PPM-umwandlerXBEEdongle und ein angeflanschtes ATmXXX-GUIboard nutzen :D


*das ist eigentlich nur ein umprogrammierter modell-I2Cmasterknoten :evil:

mit dem ATt15, einem optokoppler, einer LED, einer 3V3-Zdiode, einem 3V3 spannungsregler, einigen widerständen und zwei tastern liesse sich ein 2G4-LSdongle bauen. das ist mein nächstes projekt:
ein kumpel möchte seine funke umrüsten und stellt sich als betatester zur verfügung :ok:
bin schon zu alt zum spielen.. macht aber gleichwohl spass ;-)

Bruchflieger

RCLine User

Wohnort: 18km südl. der Lutherstadt Wittenberg

Beruf: Energieelektroniker / HWK-Meister E-technik

  • Nachricht senden

12

Mittwoch, 21. November 2007, 10:38

Nix für Ungut Bruno,

Aber glaubst du wirklich, daß die Hersteller jemals ein Übertragungsprotokoll offenlegen würden - und das selbst wenn sie sich wirklich alle auf ein gemeinsames Protokoll einigen, könnten wir es auch wieder nur durch Reverse Engineereing herausfinden...
Grüße Dani.

13

Mittwoch, 21. November 2007, 10:45

Hallo Bruno,

kann deine Kritik nicht ganz nachvollziehen...

Was hier gerade läuft hat ja eine etwas andere Zielsetzung als die Initiative. Hier gibt es einige Aktive, die aus Spaß mit 2,4GHz basteln. Einige fliegen schon damit.

Jetzt reden sie miteinander und versuchen, einen gemeinsamen Nenner zu finden. Dass dabei detaillierte technische Specs erstellt werden, ist Grundvoraussetzung für das Ziel, dass nachher die verschiedenen Projekte vielleicht kompatibel werden. Das ist dann nämlich wirklich interessant, wenn Hard- und Software austauschbar sind und man voneinander lernen kann.

Was die Urheberrechte angeht, ist das ganze wohl eher unkritisch. Da jeder hier beiträgt ist das, was hier gepostet wird in meinen Augen "frei"...
Dass die Hersteller es nachher anders machen werden, ist schon klar, aber hier gehts auch nicht um eine Vorlage für was Kommerzielles. Vielleicht schauen sie aber zu und finden es interessant...

Meine Meinung zur Zielrichtung der Initiative hatte ich ja mal irgendwo hinterlassen... Leider ist die jetzige Darstellung weder für den "normalen" Modellbauer (zu technisch) noch für die Hersteller (zu sehr detailliert) gut. Aber das hatte ich ja auch schonmal gesagt...


Also ich werde hier weiter mitbasteln und grübeln. Das macht nämlich Spaß!

Thema ACK:
Wie bei den Bytes bin ich auch bei den ACK´s eher der Schwabe (schon zu lange hier :D ) Mein System sendet momentan alle 10 Fernsteuerpakete eine Rückmeldepaket. Man sollte auch immer bedenken, dass im Falle einer schlechten Verbindung ja sowohl Uplink wie Downlink betroffen sind...

Zitat

Ich dachte aber PAN geht nur mit Coordinator?

Gute Frage... muss mal jemand probieren... (oder nachlesen)

Was die "most wanted" Dienste angeht ist halt die Sache, dass man sicher was vergisst ;( Lass uns da mal sammeln.

Zum Hopping:
Hat schonmal jemand die Zeit gemessen, die ein Modul zum Wechseln des Kanals braucht?

Bis dann

Grüße

Marc

wurpfel1

RCLine User

Wohnort: CH-rheintal

  • Nachricht senden

14

Mittwoch, 21. November 2007, 12:28

Hi Marc

sichere deine info einfach mit FEC ab, ich nutze für mein 5Byte-protokoll einen 5,3-Hammingcode..

das XBEE fügt dann den 8Byte noch seinen overhead hinzu und hoch damit!



im modell kann der code vollständig aufgelöst werden oder nur bis zum gut/nichtgut bearbeitet werden :w







PS
das XBEE treibt einige mA am pin: ein pullup oder tiefpassfilter sorgt für ruhe.. es muss nicht mit HFverseuchung durch leitungseinstreuungen gerechnet werden.

den timertakt für die servoimpulserzeugung kann zum pollen/pushen des XBEE-RX/TXpins verwendet werden, einen UART dafür zu verwenden wäre verschwendung.. je nach vorteiler hat ein gültiges byte 2-100 gleiche vorgänger ;)

der anfang eines paketes ist im APImode klar erkennbar: nach einer präambel kommt die eigene adresse!

im APImode steht an nächster stelle die länge des pakets. da ich mit konstanter paketlänge operiere ist das ein sicheres kriterium eine info zu verwerfen.

das letzte Byte am schluss des APIpakets ist eine checksumme. die könnte man auswerten, ich vertraue aber auf das viel sichere FEC :shy:
bin schon zu alt zum spielen.. macht aber gleichwohl spass ;-)

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »wurpfel1« (21. November 2007, 12:31)


^____

RCLine User

  • »^____« wurde gesperrt

Wohnort: anonymisiert

Beruf: anonymisiert

  • Nachricht senden

15

Mittwoch, 21. November 2007, 12:30

Hallo Dani,

Nun, ich habe dies alles schon ausführlich und umfassend begründet. Ich lehne meine Initiative an das Chaos der Modellbahnindustrie mit ihren inkompatiblen Mehrzugsteuerungen vor 15 Jahren an. Dort hatte auch jeder Hersteller seine eigene Suppe im Topf. Dank dem Normungsgremium NMRA wurde dann das von LENZ entwickelte DCC zum Quasistandard erklärt und von vielen Firmen übernommen. Selbst der Gigant MOTOROLA, welcher für Märklin lieferte, musste mehr oder weniger das Handtuch werfen. Auch die deutsche Firma welche einen Grossbahnhersteller in Nürnberg belieferte musste notgedrungenermassen sein System an DCC anpassen.

Leider fehlt bei den RClern so etwas wie eine NMRA.

Die Initiative und das Know How von Dir Wurpfel steht ausser Frage. Das Problem ist nur, dass auch Du keinen offenen Standard festlegen kannst der dann übernommen würde, leider sozusagen.

@ Dani

Das DCC Protokoll ist für jedermann offen und frei verfügbar. Es gibt tausende von Bastlern welche sich selber ihre Komponenten bauen. Dank DCC lassen sich die dann weltweit untereinander gemischt betreiben.
Es geht schon, aber man muss wollen. Die RC Branche hat leider nicht so einen Zugzwang wie das die Modellbahnindustrie hatte.
Dann kommt, dass es unter den RClern genügen Leute gibt welche sich immer gleich sofort auf jedes neue System wie die Geier auf Aas stürtzen. So sehen die Firmen natürlich nie einen Handlungsbedarf. Erste wenn einmal alle diese Geräte wie XPS, IFS, FASST und dergleichen bleischwer in den Regalen liegen bleiben und die Käufermasse mittels solchen Initiativen Druck ausüben wird sich etwas ändern.
Genau DIES ist aber eine Illusion, nicht das offene Protokoll an sich.

Zitat

Hier gibt es einige Aktive, die aus Spaß mit 2,4GHz basteln.


Dagegen habe ich rein gar Nichts, im Gegenteil. Leider hilft das aber der Masse an RClern nicht.
Bei einer Normung könntet Ihr alle sogar kompatibel basteln, siehe DCC. Dort gibt es dermassen viel Freiraum, dass jeder seine Idenn komptibel (!) mit allen anderen kombinieren kann. Was will man mehr?

Gruss Bruno

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »^____« (21. November 2007, 12:32)


Space

RCLine User

  • »Space« ist der Autor dieses Themas

Wohnort: Hasloh b. Hamburg

  • Nachricht senden

16

Mittwoch, 21. November 2007, 13:28

@Bruno

Es steht nirgendwo geschrieben das die Verwendung des zu noch entwickelnden Protokolles einem kommerziellen Hersteller untersagt ist. Der Verweis auf deine Alternative in dem Doc. zeigt doch ganz deutlich was das Ziel der Eigenentwicklung ist. :shake:

Ich möchte dich bitten diesen Thread nicht durch eine Grundsatzdiskusion über deine Initiative zu verwässern. Dies soll ein technische Thread bleiben.
Gruß

Thomas

Space

RCLine User

  • »Space« ist der Autor dieses Themas

Wohnort: Hasloh b. Hamburg

  • Nachricht senden

17

Mittwoch, 21. November 2007, 14:00

Zitat

Zum Hopping:
Hat schonmal jemand die Zeit gemessen, die ein Modul zum Wechseln des Kanals braucht?
Die Frage habe ich auch schon mal gestellt, und ist leider ohne Antwort geblieben.
//genervt an
Hat mich ein wenig gewundert, da hier doch einige von der Darstellungen ihrer Lösung suggerieren sie hätten alles durchblickt. Wir werde wohl mal selber Versuche starten müssen bevor auf eine konkrete Frage wieder die Antwort kommt: Also meine Lösung sieht ja ganz anders aus....
//genervt aus

Zitat

Was die "most wanted" Dienste angeht ist halt die Sache, dass man sicher was vergisst
@All, was sind euere Meinung nach die Funktionen welche in der Routingtabelle hart verankert werden sollen, welche dann über eine Adresse direkt angesprochen werden sollen? (Beispiel: Die RSSI Abfrage)


Zitat

Thema ACK: Bei bei den Bytes bin ich auch bei den ACK´s eher der Schwabe (schon zu lange hier ) Mein System sendet momentan alle 10 Fernsteuerpakete eine Rückmeldepaket. Man sollte auch immer bedenken, dass im Falle einer schlechten Verbindung ja sowohl Uplink wie Downlink betroffen sind...
.....achherjee du bist ein Schwabe 8( , das erklärt natürlich die Weigerung gegen "unnötige" Aussendung von ACK Paketen ;) .
Wie gesagt, der Gedanke mit dem PSACK für Servodaten ist eben der, das ich trotz gestörtem Rückkanal das Wackeln der Verbindung (wenn Rückkanal wackelig, wird der Hinkanal auch sicher kippelig sein) erkenne und meine Servodaten Aussenderate daraufhin erhöhen möchte.


Gruß

Thomas
Gruß

Thomas

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Space« (21. November 2007, 14:02)


wurpfel1

RCLine User

Wohnort: CH-rheintal

  • Nachricht senden

18

Mittwoch, 21. November 2007, 15:09

Hi leutz

ein kanal wird für 64ms besetzt.
steht hier

das ding hoppt 15mal pro sekunde falls ich das richtig interpretiere :evil:
bin schon zu alt zum spielen.. macht aber gleichwohl spass ;-)

Bruchflieger

RCLine User

Wohnort: 18km südl. der Lutherstadt Wittenberg

Beruf: Energieelektroniker / HWK-Meister E-technik

  • Nachricht senden

19

Mittwoch, 21. November 2007, 15:29

Zitat

Original von Space
//genervt an
Hat mich ein wenig gewundert, da hier doch einige von der Darstellungen ihrer Lösung suggerieren sie hätten alles durchblickt. Wir werde wohl mal selber Versuche starten müssen bevor auf eine konkrete Frage wieder die Antwort kommt: Also meine Lösung sieht ja ganz anders aus....
//genervt aus


Also meine Lösung sieht zwar ganz anders aus - klar, weil ich mir erstmal noch keine Gedanken über sowas gemacht hatte - es sollte nach über 3 Jahren Basteln nun endlich irgendwie funzen... :O
Die XBees hab ich aus dem Briefumschlag genommen aufs DK-Board gesockelt, als Ziel die Adresse des jeweilig anderen Moduls eingegeben und danach an den Sender bzw. das Modell angestöpselt - hurra, es fliegt... -> Kanalwechsel etc. hab ich null Ahnung, ob die Module so was können, geschweige denn, wie man sowas auslöst/beeinflußt... Mir war nur wichtig, daß die Dinger ne Zulassung haben und meine Daten sicher und simpel übertragen...
Das als Begründung, warum ich auf die Frage nach solchen Details keine Antwort geben konnte...

Zitat

@All, was sind euere Meinung nach die Funktionen welche in der Routingtabelle hart verankert werden sollen, welche dann über eine Adresse direkt angesprochen werden sollen? (Beispiel: Die RSSI Abfrage)

Ich weiß nicht, ob ich das korrekt verstanden habe, darum nur grob, was ich für wünschenswert halte:

1. Servodaten
zuerst die 4 Hauptfunktionen in einer festgelegten Reihenfolge je 1 Byte - 8Bit Auflösung reichen bei herkömmlichen Servos
danach 1 Byte für 8 Schaltfunktionen
Danach können weitere Proportional- / Schaltfunktionen folgen
(Meine derzeitige Reihenfolge lautet: Seite, Motor, Höhe, Quer, Schalter, welche alle ca. 60ms übertragen werden)

2. Konfigurationsdaten
bisher handle ich Trimmung und Servoreverse gemeinsam, dann nochmal Failsafe und wenn implementiert noch die Mixer für sich - wären schon allein 3 Datentypen weil ich es für unsinnig halte, jedesmal bei bearbeitung eines Bytes den gesamten Konfig-Satz zu versenden. Es reicht dann ja, wenn man nur die Konfigurationsgruppe sendet. - Wenn mit checksumme geprüft wird, kann das Rücksenden zum überprüfen ja dann wegfallen, wodurch noch weitere 3 Datentypen fürs Rücksenden gespart werden...

3. Meßdaten
hier wäre eine festgelegte Reihenfolge bei der Bedeutung der einzelnen Datenbytes ebenfalls wichtig.
(RSSI 1 Byte; Akkuspannung 1Byte; Motorstrom 1 Byte; Flughöhe 2 Byte - mehr hab ich selbst momentan noch nicht, da mein Protokoll zur Zeit nur 5 Byte Nutzdaten in einem Paket überträgt. - Diese Beschränkung fällt ja dann weg... )

RSSI gewinne ich per ADC-Wandlung des vom XBee am Pin 6 abgegebenen PWM-Signals nach einem RC-Glied, da ich meine Module noch so verwende, wie sie aus der Box kommen....



Ich halte es für möglich, daß wir wieder aneinander vorbei geredet haben, daher bitte ich um Nachsicht... :dumm:
Grüße Dani.

^____

RCLine User

  • »^____« wurde gesperrt

Wohnort: anonymisiert

Beruf: anonymisiert

  • Nachricht senden

20

Mittwoch, 21. November 2007, 15:36

Hallo Thomas,

Zitat

Es steht nirgendwo geschrieben das die Verwendung des zu noch entwickelnden Protokolles einem kommerziellen Hersteller untersagt ist.


Ja, das behauptet ja auch Niemand. Es steht aber umgekehrt auch nirgends geschrieben, dass man es darf und dass Du damit einverstanden bist.
Das Problem ist, dass es aus rechtlicher Sicht nicht geht wenn es nicht offiziell so kommuniziert und publiziert wird. Genau dies macht die NMRA als unabhängige im Modellbahnbereich.

Du hast aber Recht, man soll das hier nicht mit OT verwässern. Ich wollte nur noch einmal die Parallelen zu DCC kurz aufzeigen.

Gruss Bruno