Ahoi zusammen, ich habe mich damit beschäftigt, ein Funken-Kozept zu entwerfen, welches meinen Vorstellungen entspricht. Muss zugeben, ich hab keinen Schimmer, was verfügbare Systeme können. Daher will ich nicht behaupten, mein System sei sowie so besser als alles andere wo gibt. An einigen Stellen wahrscheinlich schon - aber auch das ist so - jeder Entwurf ist irgendwo besser, als ein anderer :) Motivation: Mich hat immer die Idee gestört, mir für relativ viel Geld etwas zu kaufen, wo ich mich in einem vordefiniertem Korsett bewege. Speziell auf diese Dinge habe ich meinen Fokus gelegt: 1) Tauschbares haptisches Front-End Alles außer den 4 Hebeln ist außen über einen Bus angeschlossen, dessen Teilnehmer variiert werden können. Es können Digitale Eingaben (Schalter / Taster) und numerische (Potis / Lehrer-Schüler-Systeme) gemacht werden. So kann man z.B. einen Satz Schalter anschließen, oder auch ein mit Kommunikationstechnik ausgestattete PC-Lenkrad-Pedal-Kombo. 2) Modulare Parametrierung Menu und Parametrierung basieren auf Modulen, wo manche zum definieren von Struktur verwendet werden und andere möglichst kleine Einheiten an Funktion umsetzen. Diese Module können zum Teil in einander gestapelt und wieder verwendet werden können. So lassen sich Strukturen aufbauen, für z.B. Flapperons, Mixer, Lehrer-Schüler-Systeme und alles erdenkliche andere. Die Downside ist, ich muss es aktuell selber machen, die Upside ist, es gibt keine konzeptionelle Begrenzung, - z.B. wie viele Mixer es von einem Typ gibt. Ich habe dazu ein Video erstellt. Man merkt schnell, dass ich kein geübter YouTuber bin ;> In der Beschreibung vom Video finden sich einige Timestamps. Mit am besten gefällt mir die Fake-Tip-Tronic am Lenkrad :) https://youtu.be/YBKYQv8-6wU viele Grüße!
keine neue Idee ;) https://www.rclineforum.de/forum/board72-elektronik-spezial-eigene-schaltungen-prinzipien-realisierung/board149-eigenbau-anlage bzw: OpenTx & consorten
Jasson J. schrieb: > Daher will ich nicht behaupten, mein System sei sowie so besser als > alles andere wo gibt. Der entscheidende Unterschied zwischen deiner Ideensammlung und "alles andere wo gibt" ist, daß es alles andere tatsächlich gibt. Mach erst mal, danach kannst du vergleichen. Oliver
Letztlich hab ich noch gar nicht recherchiert, was es gibt. Ich hätt´s am Ende eh selbst gemacht wegen weil - iss halt Hobby. Einige Punkte werde ich vielleicht mal an nem lauen Samstag Morgen bei ner Tass-Kaff tatsächlich schauen, was andere so tun. Eines ist mir klar - für den durchschnittlichen Modelnutzer ist das nix. Das Konzept mit stapelbaren Modulen dürfte zu komplex bulky sein. Mir gibt es halt die maximale Freiheit jeden erdenklichen Mixer beliebig oft auf zu bauen.
Das Thema interessiert mich. Mir geht es dabei um viele Sonderfunktionen, z.B. in einem Modell-Lkw. Dein Video werde ich mir reinziehen, vielleicht schon heute abend mit ner Flaschbier. Zwei Themen empfehle ich für Deinen lauen Samstagmorgen mit ner Tass Kaff: 1. OpenTX Erlaubt nach meinem Dafürhalten schon sehr viel an Funktionen und Programmierung. Was mir nicht gefällt bzw. nicht reicht: Alle Programmierung und Verarbeitung läuft auf der Senderseite, dann wird es durch den "Flaschenhals" von 16 (oder mit Tricks 32) Servo-Kanälen auf den Empfänger übertragen. Empfängerseitig kann zwar sehr universell alles mögliche kaufbare verwendet werden, aber eben nur der Betrieb von Servos, oder nachfolgender Elektronik, die die Servoimpulse wieder umständlich auswertet und in Sonderfunktionen umsetzt. 2. Blauzahn-RC Krude Seite, krudes Bastler-Produkt. Aber momentan dem, was ich suche, am nächsten. Die Verarbeitung findet hier eher auf Empfänger-Seite statt. Bis zu vier "Auswertebausteine" können an einem Bluetooth-Empfangsmodul hängen. Mit der Zahl der Auswertebausteine skaliert sich auch die Zahl der darstellbaren Servokanäle oder Sonderfunktionen. Was ein Ausgabekanal tut (Servo, Schaltfunktion, PWM) ist halbwegs frei und ohne den Einsatz nachfolgender Extra-Elektronik einstellbar. Was mir nicht gefällt: Alles basiert auf 8Bit-AVRs, nach meinem Gefühl reicht deren Mächtigkeit nicht aus, eine richtig große Anzahl von Funktionen reinzupacken. Allein die Verteilung auf mehrere Auswertebausteine rettet dieses System. Am Sender fällt die Menüführung und die Aufbereitung der Informationen im Display langsam aus der Zeit... das könnte heute, wo jeder Touchscreens mit 5" und mehr gewöhnt ist, besser sein.
Heinz schrieb: > die die Servoimpulse wieder > umständlich auswertet und in Sonderfunktionen umsetzt. Nicht zwingend. Da gibt es ja S.Bus, F.Port etc... alles serielle Daten.
Ja, den Flaschenhals habe ich auch - ich weiß noch nicht ob und wann ich das adressiere. Eine Möglichkeit währe wie du sagst nur Inputs zu schicken und die Action Empfangsseitig zu machen >oder mit Blauzahn oder Wifi das Problem einfach mit Bandbreite zu erschlagen. Vielleicht macht ein Mischbetrieb Sinn - die wichtigen Steuerfunktionen auf standard TX/RX Module geben und den fancy Blinkkram auf BLE / WIFI. >Alles basiert auf 8Bit-AVRs Deswegen hab ich hier zu stm32 BluePill gegriffen. Kanonen-auf-Spatzen-schießender-Weise hat man da einfach 10 Pins, die man auf 0 bis 100% PWM oder auf "Servo-Compliant" PWM konfigurieren kann. >>PS.: mein Video ist mehr auf der informativen Seite und hat nicht den gewohnten YouTube Glamour :>
Jasson J. schrieb: >>>PS.: mein Video ist mehr auf der informativen Seite und hat nicht den gewohnten > YouTube Glamour :> Angenehm. Find ich besser so. Solange man versteht was Du sagst. Ich hab wie gesagt nur kurz reingeschaut. Batterie leer... schrieb: > Nicht zwingend. Da gibt es ja S.Bus, F.Port etc... alles serielle Daten. Aber an den SBus kann man meines Wissens wieder nur (käufliche) Module anschließen, die daraus wieder einen Servo-Anschluss machen. Einmal hab ich einen Selbstbau-Multiswitch für SBus gesehen, der pfriemelt aber seine Informationen wieder nur aus den Informationen für einen Servokanal heraus. Senderseitig wurde mit OpenTX dann eine aufwendige Programmierung vorgenommen, die dem Servokanal für alle möglichen Schaltzustände verschiedene Werte zuweist. Ich hole mal weiter aus, was mir so vorschwebt: Senderseitig sowas wie OpenTX, müßte man aber um ein paar Funktionalitäten erweitern. Vor allem müßte man von dieser engen Sichtweise "ich übertrage parallel ca. 16-32 quasi-analoge Signale" wegkommen. Empfängerseitig ein ordentlicher 32-Bitter als "Zentrale". Der hat von mir aus auch ein paar Servo-Anschlüsse direkt drauf. Aber vor allem ein Bus-System, an das sich beliebige kleine Platinchen anschließen lassen: Welche mit 4 oder 8 Servo-Anschlüssen, welche mit 8 Schaltkanälen, Fahrtregler, Hydraulikpumpenregler, welche mit dicken Schaltkanälen, Meßmodule... Wie gesagt, die Blauzahn kommt dem am nächsten, nur ist hier die Schrittweite der Erweiterung recht groß: Ein Auswertemodul kostet 99€, ist dank DIL-ICs recht groß, kann aber auch 18 universelle Ausgabekanäle. Mir wären kleinere, verteiltere Platinen lieber.
Heinz schrieb: > Aber an den SBus kann man meines Wissens wieder nur (käufliche) Module > anschließen, die daraus wieder einen Servo-Anschluss machen. Zumindest für SBus bzw. S.Port gibt es Arduino Libs. Mit denen sollte sich eigentlich mehr machen lassen als nur eine PWM generieren. Eventuell auch mal bei Betaflight oder so reingucken - da funktionieren die seriellen Empfänger; sogar F.Port 2 (FrSky, halbduplex für Steuerdaten und Telmetrie). Heinz schrieb: > Empfängerseitig ein ordentlicher 32-Bitter als "Zentrale". Der hat von > mir aus auch ein paar Servo-Anschlüsse direkt drauf. Aber vor allem ein > Bus-System, an das sich beliebige kleine Platinchen anschließen lassen Vieleicht versteh ich Dich falsch - aber für mich klingt das fast nach einem Flight Controller für Dronen. Ausser dass da ein IMU mit drauf ist haben die nomalerweise ein paar PWM Ausgänge, I2C, mehrere UART... Eventuell kannst Du da etwas abgucken und eine bestehende OpenSoure Firmware vie Cleanflight in Deine Richtungn abändern? Kommt halt wirklich auch drauf an, was Du machen willst. Bei Bluetooth und WiFi wäre für mich die Reichweite zu gering... ... nur so eine Idee währen dem ich meinen Burger verdaue ;-)
Jasson J. schrieb: > meinen Vorstellungen entspricht. > Muss zugeben, ich hab keinen Schimmer, was verfügbare Systeme können. > Daher will ich nicht behaupten, mein System sei sowie so besser als > alles andere wo gibt. > An einigen Stellen wahrscheinlich schon - aber auch das ist so - jeder > Entwurf ist irgendwo besser, als ein anderer :) Ich denke nicht dass man ein gutes bis sehr gutes System machen kann ohne viel Erfahrung mit bestehenden Systemen und tiefe Kenntnis um die Anforderungen der Nutzer zu haben. Einfach mal loslegen, ohne Ahnung, kann man als Hobby immer machen. Es wird aber nicht gut werden. Und es wird meistens nicht nützlich sein. Heinz schrieb: > Aber vor allem ein > Bus-System, an das sich beliebige kleine Platinchen anschließen lassen: Hier kommt es dann auch auf Zuverlässigkeit und die Latenz an. Wie lange dauert es von der Eingabe bis sich das Servo bewegt? Hier machen sich schon recht kleine Latenzen gut bemerkbar. Das ist dann, abseits des Blink- und GUI Krams eine schöne Programmiertechnische Herausforderung.
>Einfach mal loslegen, ohne Ahnung, kann man als Hobby immer machen. Es >wird aber nicht gut werden Das sind die Formulierungen, die zu Auseinandersetzungen hier führen, weil sie die Tonlage eines Vorwurfs tragen. Woher willst du wissen, dass ich keine Ahnung habe? Nur weil ich nicht die vielen Hersteller recherchiert habe, heißt das nicht, dass ich nicht ein bisschen was mit bekomme. Und selbst im Eigenflug seh ich nicht, warum da nicht was gutes bei rauskommen können sollte, wenn man sich ein sinniges Konzept überlegt hat. Das es möglich ist, (für wer auch immer es braucht) mit verfügbaren Modulen eine Fake-Tiptronic zu modulieren finde ich gut. Mit dem Blinkermodul kann man z.B. dafür sorgen, dass Richtungsblinker angehen, wenn man den Lenkhebel bewegt - ohne, dass da irgendwo was fix/hart einprogrammiert währe. Find ich auch gut. Dabei müssen es keine Hebel sein. Man weist dem Blinkermodul eine Compostition zu, die als Trigger dient (Composition ist ein "Ding", wo man andere Compositions und Funktionsmodule reinpacken kann). Also statt dem Hebel kann man auch Schalter zum triggern verwenden. Oder beides - so hat man auf den Hebeln die Richtungsblinker und auf einem Schalter kann man beide Blinker triggern und hat die Warnblinke. Ich erwarte natürlich nicht, dass sich jemand ein ein Stunden langes Video reinzieht, außer man interessiert sich für genau den behandelten Sachverhalt - nur dann gibt es keinen Halt zu sagen jemand hat keine Ahnung und dazu ein Konzept an zu zweifeln, dass man nicht kennt.
:
Bearbeitet durch User
Auch wenn ich mich bei den Vorwürfen, Dir Ahnungslosigkeit zu unterstellen, nicht angesprochen fühle, habe ich trotzdem nochmal einen kleinen Blick ins Video geworfen. Mir war gar nicht bewußt, daß es wirklich EINE STUNDE dauert. Das kann ich natürlich nicht hier uff Arbeit ansehen :-) Aber ich hab nochmal willkürlich an ein paar Stellen reingeklickt und muß sagen, ich freu mich schon drauf, denn es ist doch schon einiges zu sehen. Vielleicht ist der Weg, hier ein paar Zeilen á là "ich will das bauen" zu schreiben und die Präsentation der wesentlichen, weit ausholenden Informationen in ein Video zu packen, keine schlechte Idee. Aber offensichtlich bringt es manche Leute auf den Pfad, außer der Idee wäre noch nichts vorhanden. Heute abend mehr...
So, puh, hab mich halbwegs durch das ganze Video gekämpft... Tausend Erkenntnisse und tausend Fragen. Zunächst mal (Upside!) geht an alle Zweifler und Nörgler raus: Ja, da ist tatsächlich schon ein lauffähiges System zu sehen! Aber, im großen und ganzen das Rad zum zweiten Mal erfunden. Das sag ich jetzt mal so hart weil Du schon geschrieben hast, das macht Dir nichts aus, Du hättest aus Spaß an der Freude sowieso gemacht. Und es ist ja vermutlich auch eine Leistung, das ganze von Null an noch einmal auf die Beine zu stellen. "Vermutlich" deshalb, weil ich einfach kein Programmierer bin und es nicht beurteilen kann, wieviel Arbeit und Grips dahintersteckt. Soweit ich das mitbekommen habe, steckt hinter der von mir erwähnten "Blauzahn" genau EIN kluger Kopf, eine One-Man-Show. Bei OpenTX sind in guter opensource-Manier glaube ich schon einige Leute beteiligt, aber wahrscheinlich auch nur eine Handvoll. Das "Alleinstellungsmerkmal" der aufeinander und ineinander stapelbaren Module muß ich mir noch ein zweites und drittes Mal zu Gemüte führen, bis ich es richtig kapiert habe. Es stimmt schon, ich habe mich immer gefragt, wie das denn mit den ganzen programmierbaren Funktionen programmiertechnisch eigentlich geht. Wie gesagt, ich bin kein Programmierer, auch wenn ich schon so ein paar Arduino-Sketche gebastelt habe. Bei Blauzahn habe ich so den Eindruck, es gibt eine vorgegebene Anzahl von Funktionen, die einfach über ihre Parameter aktiviert oder leer gelassen werden. Bei OpenTX scheint die mögliche Anzahl von Funktionen größer zu sein, keine Ahnung wie das läuft, ob auch hier eine große Anzahl von Funktions"rümpfen" auf ihre Paramter hin abgeklappert werden oder ob das wie Scripting funktioniert... Und wie es bei Dir funktioniert, da habe ich auch keine Ahnung, Du mußt es jetzt auch nicht genauer erklären, ich werde mir das erstmal nochmal selber ansehen. Kann dann immer noch fragen. Informationen, die mir im Video abgehen: Ok, die Hardware ist TI Launchpad und ich glaube so ein 320x240 Pixel LCD. Ist tatsächlich nicht so wichtig, welche Controller-Hardware das ist. Aber die Übertragung! Wie läuft die? Was ist da für ein Sendemodul? Sind es normale, käufliche Empfänger? Bei OpenTX scheinen die Übertragungs-Standards und Sendermodule ein wichtiges Thema zu sein, bei Dir hört man nichts darüber. Genauso das Pairing. Die anderen, die das Rad vor Dir schon mal erfunden haben, haben da auch Konzepte, versciedene Modell zu adressieren und deren Einstellungen zu speichern. Dann der Bus oder die Möglichkeiten, verschiedene Geber anzuschließen. Ist im Video genannt und gezeigt, aber nicht erklärt, oder? Das Lenkrad ist doch z.B. für den PC, also mit USB-Anschluß, oder? Wie geht das an die Fernsteuerung dran? Elemente, die mir (mir persönlich für meine Vorlieben) bei Deinem Konzept (bei den anderen übrigens teilweise auch) abgehen: Eine Geber-Normierung. Ich hätte gerne eine Einstellfunktion, mit der ich einen Geber (sei es nun ein Knüppel an der Funke oder was externes) sauber so konditionieren kann, daß er -100% bis 0 bis +100% ausgibt, am besten noch ein evtl. Totspiel um die Nullage herum bei klapprigen Knüppeln eliminieren. Und dann einen ordentlichen Klarnamen für diesen Geber einstellen, mit dem man ihn in den Funktionsbausteinen anwählen kann. Eine Ausgabekanal-Normierung. Da ist ein Servo im Modell eingebaut und hängt an einem bestimmten Empfänger-Kanal. Für diesen Servo möchte ich die Mittellage und die beiden Endlagen einstellen können, die er mechanisch machen kann/darf. Und die gelten dann als -100% - 0 - +100%. Und darauf beziehen sich dann die Ausgabewerte von Funktionen. Und der Servo/Kanal bekommt auch einen Klarnamen. Bei Dir speziell geht noch ab, was andere schon haben und offensichtlich gewünscht/gebraucht wird, auch von mir: - Ebenen (Blauzahn) bzw. Fahrzustände (OpenTX) - in der aktuellen Ebene nicht gebrauchte Ausgänge "abstellen" oder auf einen Failsafe-Wert - Modellspeicher - Ansprechen mehrerer Modelle - Exponential-Rate? - usw. usw. aber ich muß mir auch das Video bzw. die Möglichkeiten in den Funktionsmodulen noch genauer ansehen. Letztendlich wäre es schön, eine Art Referenz/Bedienunggsanleitung zu haben. Das ist übrigens ein Punkt, wo es auch bei der Blauzahn sehr hapert! So, jetzt aber genug Text für heute. Gute Nacht Tom (Heinz war mein Gastzugang, mit dem ich hier zunächst geantwortet habe - versuche ich auch beizubehalten)
> Blauzahn Das muss ich doch gerade für mich gerade ziehen meinst du damit Bluetooth oder heißt die von dir genannte Kleinfirma mit den ATMega Modulen so? >Und wie es bei Dir funktioniert, da habe ich auch keine Ahnung, Du mußt >es jetzt auch nicht genauer erklären Wahrscheinlich mach ich nochmal Videos in kleineren Häppchen >Einstellungen zu speichern Ja, da hab ich was - ist im Video nicht aufgetaucht. Ich benutze noch das 6kB EEPROM vom TI Chip. Da gehen die Daten binär kodiert rein. Wollte den Platz nicht mit einem Schnlüssel-Wert-Paar Ansatz zuballern. Der ganze De/Serialisierungs und Speicherzugriffs-Komplex war... joa... komplex eben :> >Das Lenkrad ist doch z.B. für den PC, also mit USB-Anschluß, oder? Original ja, aber ich hab das elektronische Innenleben durch eines auf Mega-Basis ersetzt, welches das "Protokoll" für die externe Daysie-Chain erfüllt. >Wie läuft die? Was ist da für ein Sendemodul? Im Moment einfach PPM auf ein JETi 2,4Ghz Modul >daß er -100% bis 0 bis +100% ausgibt, am besten noch ein evtl. Totspiel um >die Nullage herum bei klapprigen Knüppeln eliminieren. Ja, kann man machen. Es gibt ein "Dead Band" Modul. Das würde man zusammen mit dem Modul zum auswählen des Gebers in ein "Composition" packen - die kann man dann auch umbenennen. Was noch nice währe, wenn man solche selbst gebastelten Compostions als Template speichern könnte. Bisher kann man nur aus dem Compo-Pool die konkrete Referenz wieder benutzen. >Fahrzustände Muss ich googlen, was das konkret bedeutet >>in der aktuellen Ebene nicht gebrauchte Ausgänge "abstellen" oder auf >>einen Failsafe-Wert Kannst du das konkretisieren, was meinst du mit Ebene? Parametrierungsbene? >Modellspeicher hoab i - nur nicht gezeigt :) >Ansprechen mehrerer Modelle Gleichzeitig? Ginge im Prinzip auch. Man kann ja mehrer Empfänger an eine Sendemodul binden und dann müsste man die Kanäle aufteilen - das macht mit der aktuellen Technik natürlich den Flaschenhals sehr sehr eng :> >Exponential-Rate Hab so was ähnliches. Ich hab einen Teil der Kreisfunktion genommen uns als Look-Up gespeichert. Wenn man den "rechten unteren" Quadrant um x+1 verschiebt geht er ja von 0/0 bis 1/1 in einer "Halfpipe-Form". Zwischen den LUT Werten wird interpoliert. Um das Verhältnis zwischen Linear/Kreis ein zu stellen weist man (wie beim Blinker) eine Trigger-Composition zu. Deren Ausgangswert bestimmt den Anteil der Expotential bzw. Kreisfunktion. Das heißt man kann nen fixen Wert vorgeben, oder eben in der Triggercomposition einen Schalter oder Poti benutzen und das dynamisch machen. Oder nach dem Prinzip wie die Tiptronic funktioniert auch tastbar einzelne Werte einstellen.
>Der Flaschenhals
Ja Heinz :) Damit hast direkt den wundesten Punkt erwischt, der mich
noch am meisten kratzt.
Bandbreite vom PPM ist einfach mies. Wenn man da auf einem
gemultiplexten Kanal blinkend Fadings machen will, ist schnell Ende mit
der Musik.
Hab gesten in meinem Ohrensessel bei einem Cognac etwas gebrainstormt.
Technologisch am einfachsten währe vll. wirklich für die
Fancy-Funktionen WIFI zu nehmen und Empfangsseitig das was da raus kommt
im DMX512-Style einfach mit 250kBaud ins System zu blasen.
Weiß nicht, ob CAN für mich Hobbyisten zu komplex ist - wirklich, keine
Ahnung.
Jedenfalls nach Standard macht DMX512 wie gesagt 250kBaud - d.h. jedes
Byte braucht rund 250kHz / 10Bit = 4µs, bzw läuft mit 25kHz. Macht bei
256 Byte 10,24mS bzw 90 und ein paar Hz. Selbst wenn man immer 2 Byte zu
16 Bit zusammenfasst kann man immer noch 128 Teilnehmer mit fast 100Hz
Refreshrate ansteuern.
Die Frage ist, ob der Flaschenhals vll. irgendwo anders in den Modulen
in Form von Buffern oder so entsteht.
Grundsätzlich kann man die Geschäftslogik von mir auch Empfangsseitig
auf einem dicken 32 Bitter laufen lassen (den du angemerkt hattest) und
nur die Stimuli über den Airlink schicken.
Meine Architektur trennt die Geschäftslogik von der UI-Logik über ein
Visitorpattern.
Wobei auch da Tücken sein könnten. Vielleicht hängen manche Stimuli
zusammen und dann fallen vielleicht Jitter unangenehm auf.
So oder so - beide Ansätze müsste man mal gründlich durchdenken...
Das ist es wohl http://www.geier-modellbau.de/index/prog_beispiele.html Manche Nebenseiten öffnen sich bei mir leider nicht. Aber interessant, die Verkaufen Bausätze - damit kommt man um das TÜV / GS Gehampel drumrum. Das währe auch das, was mich aufhalten würde, wenn ich mein System für absolut brilliant und gamechanging halten würde und dächte jeder Jecke will das haben. Bis man diese Aufkleber auf seinen Produkten hat - vor allem bei Dingen die senden - ist man pleite.
Wenn ich von "Blauzahn" spreche, meine ich dieses Bausatz-Fernsteuersystem, genau. Wenn ich nur Bluetooth als Übertragungstechnik meine oder evtl. als Verbindung zwischen Fernsteuerung und Handy, dann Bluetooth. Blauzahn ist von Olaf Schmidt (besagte One-Man-Show) programmiert worden, Frank Geier hatte lange den Vertrieb der Bausätze und Support gemacht. Als ich das System 2015 gekauft hatte, hatte ich auch gemäkelt, Mannomann, ein paar dicke DIL-Käfer und Bausatz, das könnten die Chinesen doch als eine 4mal kleinere Platine raushauen... und bekam genau die Antwort: Zertifizierung und Elektroschrott-Entsorgungsgesetz und so weiter. Wenn man ein neues System unter die Leute bringen wollte (weil man vom Segen der Neuerungen überzeugt ist), wäre wohl ein nicht-kommerzieller Ansatz gut, einfach Open Source die Daten austauschen und jeder kann sich selbst seine Platinen machen lassen, oder man organisiert sich auf niedrigen Niveau mit Gemeinschafts-Bestellungen...
Zum Thema "Ebenen": In der Blauzahn-Welt heißt es "Ebenen", bei OpenTX "Fahrzustände", ich würde es vielleicht "Szenarien" nennen. Es geht darum, daß man am Modell oft viele Aktoren, Motoren, Servos und Lämpchen hat, aber seine Fernsteuerung nicht in der Größe eines Backblechs oder einer Kernkraftwerks-Schalttafel ausbauen kann und will. (Obwohl ich solche Ansätze schon gesehen habe) Deshalb fasst man das zu Ebenen zusammen. In einer Ebene bedienen die Kreuzknüppel den Baggerarm und das Schwenkwerk, in einer anderen kann man mit denselben Knüppeln die Stützen einzeln steuern, und in noch einer anderen Ebene fährt und lenkt man mit denselben Kreuzknüppeln. Bei Blauzahn stellt man das ein, indem man für jeden Servo-Ausgang am Modell festlegt, in welcher Ebene er aktiv ist oder passiv auf Failsave-Wert liegt. Bei OpenTX scheint es eher ein "Bündeln" der Zuordnungsfunktionen zu sein, dort geht es auch mehr um Fliegerei und die "Fahrzustände" meinen eher vielleicht Start, Landung, Kunstflug oder so. Wie dem auch sei, das mit den Ebenen finden viele Modellbauer und auch ich richtig gut, das findet sich neben OpenTX und Blauzahn meines Wissens auch bei den Fernsteuerungen von Servonaut, bei ScaleArt sowieso (das ist nämlich im Prinzip Blauzahn), und bei anderen (z.B. Brixl) weiß ich es jetzt nicht so genau.
Deine Überlegungen zu Übertragungsverfahren und "Geschäftslogik", "Visitor" usw. kann ich leider nicht richtig mitdenken, ich bin fast überhaupt kein Programmierer. Eigentlich bin ich nur Modellbauer und Fernsteuerungs-Anwender, aber ein bißchen kann ich mir halt vorstellen, was die Controller so können und was nicht. Und wenn ich was zu den Interna der Fernsteuerungssysteme lese, dann verstehe ich es halbwegs und merke es mir. Was ich gehört habe, daß viele Fernsteuerungssysteme auf dem ZigBee-Standard basieren. Die Blauzahn verwendet, wie der Name schon sagt... aber immerhin LongRange-Module. Was ich nicht machen würde: Zwei parallele Übertragungswege, einmal was schnelles flaschenhalsartiges für die wichtigsten Servo-Signale und dann einfach WiFi für alles andere... Nach meinem Verständnis kann man doch durch eine 2,4GHz-Verbindung Daten ohne Ende pressen, es kann doch kein Problem sein, mit einem selbstgemachten Übertragungsprotokoll die wichtigen Daten oft und schnell zu übertragen und die anderen langsamer. Ich meine, ein PPM-Signal für 7 Servos hat man schon durch 27MHz bekommen... Man müßte sich mal durch die bestehenden Protokolle lesen, gerade in der OpenTX-Gemeinde scheint da ja einiges an offenm Wissen zu existieren. Das von Dir momentan benutzte PPM, ist das wirklich noch genau das gute alte mit 50Hz Wiederholrate, wo mitsamt der Synchronisierungs-Pause gerade mal 7 Servosignale in den 20ms-Frame gepasst haben?
Zum Verteilen der Informationen innerhalb des Modells (also mein Traum von einem Bussystem mit mehreren kleinen Platinchen) hatte ich mir, innerhalb meiner Möglichkeiten und meines Wissensstandes, auch schon Gedanken gemacht. Blauzahn hat da einen Ansatz, den ich nicht so ganz verstehe, den ich als "unsauber" ansehe, aber er funktioniert ja offensichtlich und vielleicht habe ich es auch falsch verstanden. Hier hängen das Bluetooth-Empfangsmodul und alle Auswertebausteine irgendwie parallel an der seriellen Schnittstelle? (TTL-Level) Am naheliegendsten fände ich I2C. Oder SPI. CAN ist glaube ich Overkill, bei einem kleinen Platinchen, das z.B. 8 Lämpchen bedient, stelle ich mir eher einen ATTiny oder meinetwegen auch einen ATMega328 oder so vor. Controller mit CAN sind eher schon dicke Brocken.
Heinz schrieb: > CAN ist glaube ich Overkill, bei einem kleinen Platinchen, das z.B. 8 > Lämpchen bedient, stelle ich mir eher einen ATTiny oder meinetwegen auch > einen ATMega328 oder so vor. Controller mit CAN sind eher schon dicke > Brocken. Wäre das dann ohne die Bus Treiber? Weil die braucht man ja eigentlich nicht bei den kurzen Strecken. Aber eigentlich dürfte es ja egal sein, weil im Endeffekt sendet ja nur die Fernsteuerung zum sender richtig? Oder hat sich das mittlerweile geändert? CAN ist meiner Meinung nach nur sinnvoll, wenn viele Teilnehmer zeitkritische Informationen senden. Aber hier kommt doch alles nur vom Sender oder? Also hohe Übertragungsrate, kurze Strecken geringer Stromverbrauch, und ein paar Adressen für unterschiedliche Teilnehmer. Würde auch auf I2C setzen. Zumal du dann sogar noch irgendwelche Sensoren oder so einbinden könntest. Barometer was auch immer.
>In einer Ebene bedienen die Kreuzknüppel den Baggerarm und das Schwenkwerk, >in einer anderen kann man mit denselben... Ah, ja gute Idee. Könnte man bei mir auch parametrieren, würde aber im Moment keinen Spaß machen, weil es nur implizit durch Aufbau der richtigen Struktur ginge. Was explizites währe da viel eleganter :) >Blauzahn hat da einen Ansatz, den ich nicht so ganz verstehe >Hier hängen das Bluetooth-Empfangsmodul und alle Auswertebausteine irgendwie >parallel an Hast du nen Link dazu? Das klingt für mich ganz stark nach dem was ich mit DMX512-Style meinte. Da hängen auch alle die mithören parallel am Bus und picken sich die richtigen Bytes aus dem Stream raus. >Was ich nicht machen würde: >Zwei parallele Übertragungswege, einmal was schnelles Ich frag ganz objetiv, warum du das nicht machen würdest. Meine Überlegung hatte mit Sicherheit zu tun. Bei langsamen fahrenden/schwimmenden Multifunktionsmodellen gehe ich das mit. Da kann man bei fehlerhafter Übertragung einfach einen Failsafe aktivieren. Bei Dingen die fliegen oder schnell sind, hab ich lieber ein (hoffentlich hoch und runter getestetes) Modul von JETi als Verantwortungsträger, als "irgendeinen" WIFI oder Bluetooth RTX. Auf jeden Fall vielen Dank, für deine regen Gedanken!
>Das von Dir momentan benutzte PPM, ist das wirklich noch genau das gute >alte mit 50Hz Wiederholrate, wo mitsamt der Synchronisierungs-Pause >gerade mal 7 Servosignale in den 20ms-Frame gepasst haben? Erwischt, da bin ich noch in der Steinzeit :> Wobei ich überlege, ob ich nen externen Port an der Funke vorsehe, wo man zwischen verschiedenen Signalstandards umschalten kann.
:
Bearbeitet durch User
Zum anderen Kleingemüse: Hab mir schon gedacht, daß es schon die eine oder andere Funktion gibt, die meine Fragen erledigt, z.B. Expo, Speichern usw. Konnte natürlich nicht alles auf einmal überblicken, bzw. Du kannst beim Herzeigen nicht an jede Kleinigkeit denken. Und noch was zu Totbereich und Servoeinstellung, das ist aber jetzt meine persönliche "Philosophie" oder Wunschvorstellung, die will ich Dir nicht reindrücken, aber hier mal erzählen. Man verliert beim Einstellen dieser mächtigen Systeme leicht den Überblick. Bei der Blauzahn ist von "Totbereich" die Rede, aber es wird etwas verwirrend unterschieden zwischen dem Bereich, den die Firmware als "Knüppel wird in Ruhe gelassen" interpretiert, aber dennoch werden die um die Ruhelage tanzenden Werte weitergegeben, dann gibt es noch den Totbereich von servobetriebenen Hydraulikventilen, den man überspringen will... Bei OpenTX kann man an mehreren Stellen was drehen. Da gibt es eine "Geberverarbeitung", Funktionen und ich glaube sogar eine "Ausgangsverarbeitung". Dem Anwender wird nahegelegt, sich eine Philosophie zurechtzulegen, was er wo macht. Jetzt möchte ich gerne, daß zumindest an zwei Stellen klare Verhältnisse herrschen: Die Geber. Ich habe in meiner selbstgezimmerten Fernsteuerung ganz billige China-3D-Knüppel drin, die wackeln einfach mechanisch um die Nullpos. Sie haben sogar mehr mechanischen Weg in die Endpositionen als die Potis elektrischen Weg haben. Die Blauzahn lernt das (zumindest die Endausschläge) irgenwann beim ersten Einrichten quasi automatisch. Ich hätte aber gerne einen "Werkstattbereich" in der Firmware für die Geber, und wenn man diesen nach getaner Arbeit verläßt, kann man sicher sein, daß von jedem Geber genau 100% oder -100% bei den Endausschlägen ausgegeben werden, und daß um die Nullage sicher 0%-Werte kommen. Auf Trimmung verzichtet Blauzahn übrigens und das finde ich gut so, aber für Modellflieger mag das anders sein. Die Blauzahn ist aber auch definitiv für langsame Funktionsmodelle gedacht. Und zum anderen die Endpunkte, die Servos. Da baue ich z.B. ein Lenkservo ein und dann ist es durch die Gestänge-Geometrie vielleicht so, daß die Endausschläge nicht symmetrisch um die Geradeaus-Position sind. Oder ein Servo bedient ein Hydraulikventil, da will man auch ganz genau die Nullage einstellen und eventuell die den Positionsbereich um die Nullage, bei dem noch nichts öffnet, "überspringen". Da hätte ich gerne einen "Werkstattbereich" für die Endpunkte, wo man solche Dinge einstellt. Weil die ändern sich ja nicht mehr, außer durch Verschleiß oder Defekte. Und dazwischen ist der Zuweisungsbereich. Da darf nach Herzenslust gemischt, addiert, umgeschaltet, gekreuzt und sonst noch was gemacht werden. Aber vorne kommt von den Gebern immer -100% bis +100% rein, und hinten raus wird zu den Endpunkten immer maximal -100% bis +100% ausgegeben bzw. die Endpunkte ignorieren darüberliegende Werte. So, das war jetzt mein Traum in Prosa beschrieben.
Ach und ein letztes: Die 2,4GHz-Systeme sind meines Wissens alle bidirektional, also der "Empfänger" sendet durchaus zurück und der "Sender" empfängt was. Grundsätzlich wird fast immer ein Wert für die Empfangsqualität zurückgesendet und meistens auch die Versorgungsspannung des Empfängers. Ja, das Barometer / Variometer ist eine typische Telemetrie-Anwendung, und diverse Temperaturen, Stromverbräuche, der Funktionsmodellbauer möchte vielleicht den Hydraulikdruck wissen... usw. Also das Bussystem im Modell sollte schon auch bidirektional sein. Synchronisierung von Schaltgetrieben wäre noch so eine schöne Spielerei, wo ein paar Informationen auf dem Bus hin- und herlaufen müssen. So, jetzt muß ich aber wirklich mal was arbeiten :-)
>Synchronisierung von Schaltgetrieben wäre noch so eine schöne Spielerei, >wo ein paar Informationen auf dem Bus hin- und herlaufen müssen. An so Loop-Back Sachen dachte ich auch schon mal - da gehts schon derbe Richtung Echtzeitanforderungen. Das kann ein Grab für Arbeitszeit werden. Aber ja, da könnte man den richtig nicen Sh...t mit machen. Wenn´s um Fancy-Ness geht hab ich auch ne Idee, um die Parametrierung vom nötigen Übel in einen Genussmoment zu wandeln. Hatte schon mal weil "Because we can" angefangen die Funktionslogik mittels Qt-Creator und ausgetauschter GUI auf ein Android zu schieben. Im wesentlichen hab ich das Bedienkonzept kopiert und nur "netter" gemacht mit Drag and Drop und netten Bildchen. >richtig Richtig RICHTIG cool währe ein Ansatz, wo man in eine "Werkstatt" in der Bildschirmmitte ein Foto vom Modell laden könnte. Da kann man die vorhandenen Aktoren markieren und an diese Markierungen Graphische-Docker-Elemente anfügen und denen sagen "du bist auf Ebene "Kran" und benutzt diesen Hebel mit diesen und jenen Konventionen" und das Programm setzt das in nutzbare Parametrierung um. >Aber (das musste ja kommen^^) ich schätze das liegt außerhalb meines hobbyistischen Zeitrahmens... Und wo man schon mal dabei ist könnte man auch die Aktoren empfangsseitig von da aus gleich mit parametrieren. Das Problem ist, wenn mir solche Ideen Abends kommen, kann ich immer nicht schlafen :>
Heinz schrieb: > Also das Bussystem im Modell sollte schon auch bidirektional sein. > Synchronisierung von Schaltgetrieben wäre noch so eine schöne Spielerei, > wo ein paar Informationen auf dem Bus hin- und herlaufen müssen. Ach ja krass ich habe den Modellbau irgendwann aufgegeben. Aber im Prinzip reicht es ja wenn der Empfänger der Master ist von dem Bus. Welcher sich mit I2C Teilnehmern dann erweitern lässt.
Jasson J. schrieb: > Das Problem ist, wenn mir solche Ideen Abends kommen, kann ich immer > nicht schlafen :> Noch ist ja Vormittag :-) Ahja, die Android-App und Visualisierung, da auch noch ein Wort dazu: Bei OpenTX gibt es den "Companion" auf dem PC, damit kann man offline die ganzen Einstellungen machen und dann per USB in die Funke laden. "Online", daß gleichzeitig das eingeschaltete Modell dranhängt, geht glaube ich nicht. Dein Android-Dingens geht in die richtige Richtung, das will man heutzutage... auch wenn mir persönlich PC oder Notebook sympathischer sind. Bei Blauzahn gibt es im Display schon einige vorgefertigte Symbole für Blinker, Scheinwerfer, Sperrdifferentiale und so weiter. Wie die Anzeigen in einem Armaturenbrett. Das ist schon hübsch. Noch hübscher wäre es, wenn das konfigurierbar und editierbar wäre. Bei Servonaut gibt es ein paar Taster um das Display herum, die mit korrespondierenden Feldern im Display dynamisch beschriftet werden. Auch ne gute Idee. Prinzipiell ist natürlich auch die Zusammenarbeit mit einem Touchscreen denkbar, Bild vom Modell im Display, Tippen auf die Scheinwerfer, die gehen im Bild und am Modell an. Aber gut, so ein bißchen stilisiert dargestellt sollte es schon sein. Sonst ist man irgendwann beim Simulator und braucht gar kein Modell mehr :-) Eigentlich bin ich mit Symbolen zufrieden. Mein Problem ist, wenn mir tagsüber solche Ideen kommen kann ich nicht mehr normal arbeiten :-)
>Noch ist ja Vormittag :-)
Und wenn die 24 Stunden nicht reichen, nimmt man noch die Nacht dazu
:) Ich hatte gerade einen richtig schönen Face-Palm Moment. Es gibt ja wireless DMX512 RX/TX. Der Gedanke, der mir daran gefällt ist, dass diese Systeme es sich nicht leisten können oft auftretende Lags in der Übertragung zu haben. Nach erster flüchtiger Recherche haben die 126 Kanäle -> 126 Bytes. Selbst wenn man die immer zu 16 Bits zusammenfasst, bleiben... 63 Teilnehmer. Die sind wahrscheinlich so schnell, weil die null Datensicherung machen. Die Frage ist, ob man das braucht in diesem Fall. Also bei entweder langsamen Multifunktionsmpdellen oder eben mit der Idee für die wichtigen Steuer-Kanäle dezidiertes Modelequipment zu nehmen. https://www.amazon.de/Lixada-Wireless-Controller-Sender-Empf%C3%A4nger-B%C3%BChnenlicht/dp/B00ZQNIGQQ/ref=asc_df_B00ZQNIGQQ/?tag=googshopde-21&linkCode=df0&hvadid=232021789147&hvpos=&hvnetw=g&hvrand=7854392336280731558&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9044692&hvtargid=pla-468297391339&psc=1&th=1&psc=1 https://www.amazon.de/Eurolite-Showlite-Empf%C3%A4nger-Reichweite-geb%C3%BChrenfrei/dp/B07G45XJ7F?SubscriptionId=AKIAIZQVKWKGMRY2D3QA&tag=blu01-21&linkCode=xm2&camp=2025&creative=165953&creativeASIN=B07G45XJ7F
:
Bearbeitet durch User
Ich hab noch ein Video gemacht, wo es um das parametrieren eines Lehrer-Schüler-Systems geht. https://www.youtube.com/watch?v=x4LbPVOo8ws
Schau ich mir demnächst mal an, für Lehrer-Schüler habe ich keine
Anwendung und kein Interesse. Aber das Video beleuchtet vielleicht
nochmal das Bussystem für den Anschluß von Gebern an die Funke, wie
gesagt, schau ich mir schon noch an.
Schuldig bin ich aber noch eine Reaktion auf die Idee mit DMX-512
wireless.
Nun, ich mußte mich erst ein winziges bißchen in DMX-512 einlesen. Ok,
man haut also 512 Bytes raus, und der Empfänger fischt sich aus diesem
Broadcast sein eines richtiges oder seine mehreren richtigen Bytes raus.
Schön und gut, aber was die gezeigten Dinger in den Amazon-Links da
wireless machen, erschließt sich mir aus der google-übersetzten
Beschreibung nicht ("und es hilft ihnen, einen versauten Parteien zu
halten").
Ist es nur ein wireless-Link und hinten kommen wieder kabelgebunden die
512 Bytes raus (oder 126)?
Und dann könnte man daran wieder kleine Controllerchen hängen, die sich
aus dem Datenstrom Servopositionen oder Schaltkanal-Informationen
fischen.
Aber das ist dann doch wieder sehr nackt und "geradeaus". Dann muß ich
jeden dieser Controller-Bausteine offline/extern vorkonfigurieren,
welches Byte er empfängt und was er damit macht. So wie man DMX-Geräte
mit DIP-Switches konfiguriert.
Hm, wäre zu überlegen...
Schuldig bin ich auch noch einen Link auf das, wie bei Blauzahn die
Verlinkung der Auswertemodule gemacht wird. Nun, ich weiß da nichts
internes. Ich sehe nur auf dem Schaltplan des Auswertebausteins, daß das
Bluetooth-Empfangsmodul über irgendeinen Kleinsignal-Mosfet und
Reihenwiderstand mit TXD und RXD des UARTS des ATMega328P im
Auswertbaustein verbunden ist, während der "Link" zwischen mehreren
Auswertebausteinen darin besteht, daß jeweils die TXD und die RXD aller
beteiligten Bausteine hart parallelgeschalten sind. Somit ist es wohl
eher so, daß sich alle Bausteine denselben Informationsstrom aus dem
Bluetooth-Empfangsmodul teilen, und wie das mit dem Rücksenden von
Telemetriedaten läuft, weiß ich nicht. Da müßte ja dann ein Baustein
eine (vom Bluetooth-Modul dann vielleicht explizit erwartete) Antwort
auf TXD schicken, während die anderen Bausteine ihr TXD hochohmig
schalten...
Summa summarum, für den Bus innerhalb des Modells wäre mir nach wie vor
I2C am sympathischsten. Ein klarer Master, Daten können hin und zurück
gehen. Aber eigentlich ist der Bus auch gar nicht das Hauptthema hier...
Als Haupt-Übertragungsstrecke für die wichtigen und schnellen
Servosignale eines Fliegers oder einer Drohne würde ich nicht DMX-512
wireless nehmen, sondern was bewährtes, wie Du es jetzt ja auch schon
machst und wie es auch die OpenTX-Leute machen, an deren System man
käufliche 2,4GHz-RC-Empfänger unterschiedlicher Fabrikate verwenden
kann.
Und nur für zusätzliche Informationen für weitere Schaltkanäle und alles
mögliche, würde ich versuchen, die Übertragung der bewährten Sendemodule
irgendwie protokollmäßig zu erweitern, so daß da eine zweite Klasse von
unwichtigeren, langsameren Signalen möglich ist. Vielleicht gibts das
auch schon, keine Ahnung.
Aber nicht ein zweites, paralleles 2,4GHz-Übertragungssystem mit eigener
Antenne ins Modell setzen.
>Aber das Video beleuchtet vielleicht nochmal das Bussystem indirekt ein bisschen >"und es hilft ihnen, einen versauten Parteien zu halten" Ja, die Übersetzungen sind immer ein Schmanker´l :) Bin gerade im Fluss und hab immer mal Laune ´n Video zu machen. In diesem geht es um das Blinker-Modul am Beispiel von Richtungsblinkern. Es wird eine Parametrierung mit Totbereich in der Lenkung erstellt, so das der passende Richtungsblinker angeht, wenn man am Lenkhebel lupft - oder die Warnblinke, wenn man nen Schalter umlegt. Das Tickern vom Servo ist in der Aufnahme leider sehr markant rausgekommen... https://www.youtube.com/watch?v=nm49cqIcTdQ
:
Bearbeitet durch User
Heinz schrieb: > für Lehrer-Schüler habe ich keine > Anwendung und kein Interesse. Dazu hätte ich eine Idee: Wenn sich die Lehrer-Schüler-Funktion alternativ dazu verwenden lässt, die zweite Funke als Erweiterung zu nutzen, dann könnte das durchaus interessant sein. Zwar komme ich nicht aus dem Funktionsmodellbau, aber Ein Beispiel, das mit grad so durch den Kopf geht wäre bei einer Drone: Haupt-Funke steuert die Drone - die gekoppelte steuert Gimbal und Kamera. Zwei Personnen, mehr Steuerknüppel - und trotz dem nur ein Empfänger im Modell (notfalls also auch als Einzelperson voll nutzbar). Vielleicht etwas offtopic, aber ein Gedanke. Zumindest ich habe bei OpenTX noch keine solche Funktion gefunden.
>Wenn sich die Lehrer-Schüler-Funktion alternativ dazu verwenden lässt, >die zweite Funke als Erweiterung zu nutzen, dann könnte das durchaus >interessant sein. Klar, lässt sich so machen. Der "Host"-Transmitter weiß gar nicht, woher die externen Daten kommen und geht damit entsprechend unspezifisch um, bis man ihm sagt, was er damit machen soll. Ob das ein Lehrer-Schüler Setup ist, oder um Sonderfunktionen zu steuern ist Up to the User. >>SetKlugscheißMode(true); Genau genommen gibt es keine Lehrer-Schüler-Funktion :) Technisch ist es nur ein zusammenmischen von Inputdaten die "irgendwo her" kommen. -There is no spoon... >>SetKlugscheißMode(false);
:
Bearbeitet durch User
Hab jetzt einen ersten Wurf mit noch rumliegenden Bluetoothmodulen gemacht, um einen Eindruck von Reichweite, Risiken und Nebenwirkungen zu kriegen und ob vll. bei diesem Minimalsetup doch schon irgendwo spürbare Lags / Latenzen auftreten. https://m.youtube.com/watch?v=YceShFRL9E8
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.