Moin µC.net! ich habe eine Idee für ein Projekt, und wollte mal nachfragen, wie aufwändig das in euren Ohren klingt - bevor ich anfange ;) Ich habe hier einen von diesen günstigen 3-Kanal-Hubschraubern herumliegen, die man fast überall für etwa 20€ bekommt. Allerdings stimmt die Trimmung nicht, er dreht sich immer um die eigene Achse. Das Trimm-Rädchen kann ich nicht weiter drehen, das macht das Bauteil dahinter nicht mit - ich kann aber nach Aufschrauben auch nicht erkennen, was das genau ist - vermutlich ein Poti oder ein Dreko. Aber all das hat noch nicht mit meinem eigentlichen Vorhaben zu tun :) Nun habe ich mir überlegt, die Fernsteuerung genauer unter die Lupe zu nehmen - es sind drei IR-Dioden darin, die für Empfang überall in einem normalen Raum sorgen. Ich will gern herausfinden, wie die Signale genau aussehen, und wie die 3 Steuerkanäle darin codiert sind. Im zweiten Schritt will ich meine eigene Fernsteuerung dafür bauen - ein tiny13-AVR und ein paar Dioden zzgl. übliches Hühnerfutter sollten da vielleicht schon ausreichen...? Ansteuern will ich diese per UART von einem PC aus - allerdings nicht autonom, sondern per Gamepad ;) Also, meine Fragen. - Gibt es Leute, die sich damit schonmal beschäftigt haben und Beispiele für solche IR-Protokolle kennen? - Wie kann ich am besten die Signale aus der Fernsteuerung auslesen und grafisch darstellen? Ich habe leider kein Labor-Oszi weil zu teuer. Auswertung würde ich selbstverständlich selbst übernehmen, und auch gern mit euch teilen. - Ich habe einmal von einem Chip gehört, den ich auf einer Seite an den UART anschließen kann, und auf der anderen Seite an USB. Ist da was dran? Was kostet der Spaß, und wie aufwändig und zuverlässig ist das in der Praxis? Joa, das wär's, was vorab unklar ist! Danke im Voraus für schnelle, aber auch reichhaltige und überlegte Antworten ;) euer LDer
Jörn-michael M. schrieb: > - Wie kann ich am besten die Signale aus der Fernsteuerung auslesen und > grafisch darstellen? Ich habe leider kein Labor-Oszi weil zu teuer. Wenn die Modulation des IR-Signals relativ langsam ist (hoffen wir es mal): Nimm einen fertigen IR-Empfänger (lassen sich prima aus alten weggeworfenen Sat-Receivern und sonstiger Unterhaltungselektronik auslöten). Da hängst 5V Versorgung dran, evtl einen Pullup/Pulldown (Datenblatt lesen!), den Ausgang per Spannungsteiler und evtl. Kopplungs-C an die Soundkarte (braucht man eigentlich nicht, da die Soundkarten meist eh AC-gekoppelt sind) und fertig! Ein sehr minimalistisches Beispiel hier: http://www.lirc.org/ir-audio.html
Hallo Jörn, ohne jetzt die Idee im Keim ersticken zu wollen: Das lohnt den ganzen Aufwand nicht. Selbst wenn jetzt schon alle Übertragungsprobleme gelöst wären: Mit einem Gamepad lässt sich ein solcher Hubi noch viel weniger exakt steuern als mit der mitgelieferten "Fernsteuerung". Wenn Du es trotzdem probieren möchtest: Mit Hilfe der Soundkarte in deinem PC sollte es, wenn du Glück hast, möglich sein, das IR-Protokoll auf zu nehmen und dann zu analysieren. Such mal im INet oder auch hier in diesem Forum nach "Soundkarte Oszi". Da findest du jede Menge dazu. Hier jemanden zu bitten dies mit seinem Hubi+Oszi zu machen, macht nicht wirklich Sinn, da dieser Jemand ja genau den selben Hubi haben müsste. Wenn du dann das Protokoll hast, dann mach eine schöne Grafik draus und komm wieder hier ins Forum damit. Es werden sich Leute finden, welche es gerne analysieren. Um den Chip für die Umsezung von USB auf UART kümmern wir uns dann später. MfG Ulli-B
--> IRMP bau das mal auf dem Steckbrett auf und schau, ob ein Protokoll erkannt wird. wenn nicht mach mal ein paar scans und schick die Frank. wenns einfach ist, dann baut er das vielleicht ein.
hier im Forum hat mal jemand das ganze für einen PiccoZ gemacht, eventuell findest Du da ein paar Anregungen : Beitrag "Silverlit Heli IR Fernsteuerung mit AVR"
Sender aufmachen und an die IR-Sende Dioden gehen. Für den Rest: Du hast einen Tiny mit dem man Signale auch aufnehmen kann. (Oder eben mit einer Soundkarte auf ein PC-Oszi gehen)
Karl Heinz Buchegger schrieb: > Sender aufmachen und an die IR-Sende Dioden gehen. > Für den Rest: Du hast einen Tiny mit dem man Signale auch aufnehmen > kann. Dachte ich auch zuerst dran, aber: An der Dioden misst man die Trägerfrequenz, und dafür wird die Soundkarte wahrscheinlich zu langsam sein. An einem IR-Empfänger wie "IdeeIdee" vorschlägt, kommen nur die "Bits" raus, --> also eher eine Chance dass die Soundkarte es schafft. Das stimmt natürlich nur, wenn es auch eine Trägerfrequenz gibt ... wer weiss das schon ... MfG Ulli-B
>Sender aufmachen und an die IR-Sende Dioden gehen. >Für den Rest: Du hast einen Tiny mit dem man Signale auch aufnehmen >kann. >(Oder eben mit einer Soundkarte auf ein PC-Oszi gehen) Ja, klar. Jemand der nicht mal weiss was ein USB-Seriell Wandler ist macht mal Aufnahmen mit der Soundkarte, bewertet diese und findet das Protokoll raus. Träumt weiter Leute. Das ist ein 16 jähriger Penäler der von nix ne Ahnung hat.
:
Wiederhergestellt durch Moderator
Ulli B. schrieb: > Das stimmt natürlich nur, wenn es auch eine Trägerfrequenz gibt ... ... und du deren Frequenz kennst :-) Und solange du die nicht kennst wirst du dir schwer tun, den richtigen Empfänger dafür einzukaufen.
holger schrieb: > Ja, klar. Jemand der nicht mal weiss was ein USB-Seriell > Wandler Der war allerdings wirklich gut, wenn man bedenkt dass dir so ein Teil fix fertig bei jedem Elektronikhändler nachgeschmissen wird, wenn du eine Rolle Klebeband einkaufst :-)
Karl Heinz Buchegger schrieb: > Und solange du die nicht kennst wirst du dir schwer tun, den richtigen > Empfänger dafür einzukaufen. Uuups ... stimmt auch wieder ! Es ist ganz schön schwer, jemandem ohne Equipment Tips zu geben, wenn man selbst das nötige Equipment rum stehen hat. Da sieht man erst, wie man sich selbst mit Messtechnik verwöhnt. MfG Ulli-B
Ulli B. schrieb: > Karl Heinz Buchegger schrieb: >> Und solange du die nicht kennst wirst du dir schwer tun, den richtigen >> Empfänger dafür einzukaufen. > > Uuups ... stimmt auch wieder ! > > Es ist ganz schön schwer, jemandem ohne Equipment Tips zu geben, wenn > man selbst das nötige Equipment rum stehen hat. > Da sieht man erst, wie man sich selbst mit Messtechnik verwöhnt. :-) Aber: Wo ein Wille, da auch ein Weg. Manchmal muss man sich seine 'Messgeräte' dann eben selber 'improvisieren' Er hat doch einen Tiny und einen C-Compiler ..... Und plötzlich wird es dann zu einem richtigen Eigenbauprojekt und nicht nur zu: Ich will xyz machen. Ich hab von einer Web-Seite die Schaltung und das Programm geholt. Was soll ich denn jetzt tun? Hiiiiiiilfeeeeee!
holger schrieb: >>Sender aufmachen und an die IR-Sende Dioden gehen. >>Für den Rest: Du hast einen Tiny mit dem man Signale auch aufnehmen >>kann. > >>(Oder eben mit einer Soundkarte auf ein PC-Oszi gehen) > > Ja, klar. Jemand der nicht mal weiss was ein USB-Seriell > Wandler ist macht mal Aufnahmen mit der Soundkarte, > bewertet diese und findet das Protokoll raus. > > Träumt weiter Leute. Das ist ein 16 jähriger Penäler > der von nix ne Ahnung hat. Ich find's echt traurig und irgendwie auch ziemlich "arm" in jeder Hinsicht, dass manche Leute es echt nötig haben, andere wegen Unwissenheit runterlaufen zu lassen, anstatt einfach ruhig zu sein oder gar zu helfen. Die Sinnhaftigkeit der Ideen seien dahingestellt und - zugegeben - manche Projekte haben keinen Sinn, aber muss denn alles irgend einen Sinn haben? Oder kann es nicht nur wegen seiner selbst gemacht werden? Jeder hat mal klein angefangen... Man kann alles kontruktiv äußern, aber andere so runterlaufen zu lassen finde ich einfach nur arrogant. Jetzt zum Projekt ;) Idee an sich finde ich interessant. Wenn kein Messgerät da ist, könnte man - wie Karl Heinz Buchegger schon sagte - selbst improvisieren (µC+MAX232, Display an µC, Soundkarte,...) oder das INet durchforsten. Vielleicht ist es auch ein einfaches 38kHz-Protokoll und lässt sich relativ verarbeiten, aber da kann man was tun und vor allem lernen!
Whoa, hier gehts ja heiß her! ### Zu den bisherigen "Beiträgen" ### 1. Ich bin nicht 16 - sondern 19. Und mein Alter hat mich noch nie wirklich an etwas gehindert. 2. Ich weiß, was ein USB-Seriell-Wandler ist - zumindest habe ich so ein Teil lange Zeit dafür eingesetzt, meine AVRs zu flashen. Allerdings fertig verbaut in einem Adapterkabel mit beigelegtem WIN-Treiber. Ich fand nur diese Gelegenheit toll, an einem echten Beispiel mal so einen Chip selbst verwenden zu können. 3. Ich habe auch Ausrüstung - allerdings kein High-End-Oszilloskop oder Logic-Analyzer. Ich bin Informatikstudent im 4. Semester und habe leider nicht genug Geld, das ich für solche Dinge aufwenden kann. Ich habe mehrere AVR-Controller(Mega8, Mega644, Tiny13, Tiny2313 ...), ein umgebautes PC-Netzteil als Stromquelle, eine Ausrüstung zum Ätzen von Platinen und eine ganze Kiste voll sonstiger Bauteile, die allesamt nützlich sind. Ich bin halt ein Sparfuchs, was das angeht - mein teuerstes Teil ist das EvalBoard samt Erweiterungsplatine von Pollin zusammen mit einem AVRISP-Clone für 20€ von Ebay. Und das benutz ich auch nur weiter, weil ich etwas zu spät gesehen habe, dass sich mein eigener JTAG-Clone (habe das Layout vom Aquaticus JTAG auf SMD umgestellt und gebaut) zwar funktioniert, aber zB nicht mit dem Mega644 zusammenspielt, der das Betriebssystem laufen lässt, das ich zurzeit im Zuge einer Uni-Veranstaltung implementiere. Also schwebt doch bitte von eurem Berg von Ausrüstungsgegenständen hernieder und spart euch eure Geringschätzigkeit für die, die sie verdienen. Danke. ### An alle Anderen ### Zuerst mal, ja, man mag diese Ganze Sache anzweifeln. Finde ich auch legitim. Aber mir geht es weniger darum, eine Supertolle Steuerung für mich und den Rest der Welt zu entwickeln, sondern eher darum, praxisnahe Erfahrungen abseits der strengen Lehrpläne der Uni zu sammeln, und den ein oder anderen "Kniff" zu lernen ;) Der Ansatz mit der Soundkarte klingt schonmal gut - und sieht nach einer Gelegenheit aus, mir mal wieder Windows zu installieren, weil Linux bei meiner digitalen Soundkarte keinen analogen Eingang unterstützt :( Zufälligerweise hab ich einen TSOP1736 auf dem Pollin-Board - aber auch noch nicht damit gearbeitet. Dann erinnre ich mich gerade an meine schöne Einstiegszeit in die AVRASM-Programmierung - in meinem Buch (da gings um den Tiny13*) steht was zur Benutzung des Speicheroszilloskops auf dem Viech, das schau ich mir nochmal an; klingt nützlich - damit könnte ich ja auch an die IR-Dioden direkt gehen...? Den Beitrag zum Silverlit hab ich noch nicht ganz gelesen (Ihr macht mir Angst. So einen hab ich seit 1 Jahr auch hier. Ist aber nicht der besagte 3-Kanal-Hubi). Klingt aber in den ersten Zeilen schonmal schick, lässt sich vielleicht als Grundlage nehmen! So viel dazu, ich klinke mich für heute mal aus und gehe schlafen. Grüße, euer LDer * Hatte dann auch direkt eine tolle Projektidee, und wollte ganz viele von den Teilen vernetzen um mehr Pinouts zu bekommen... deswegen liegen jetzt hier 50 Stück davon, deswegen will ich ja auch hier ein oder zwei davon verwursten ;)
Jörn-michael M. schrieb: > Tiny13* Jörn-michael M. schrieb: > * Hatte dann auch direkt eine tolle Projektidee, und wollte ganz viele > von den Teilen vernetzen um mehr Pinouts zu bekommen... wie kommt man auf die idee 8-Pin-Controller zu benutzen, wenn man viele Outputs haben will? vor allem diese dann zu vernetzen. Entweder gleich nen größeren µC oder einfach 74X595 oder irgendwelche per SPI fütterbaren Treiber ICs als Porterweiterung. > deswegen liegen > jetzt hier 50 Stück davon, deswegen will ich ja auch hier ein oder zwei > davon verwursten ;)
Vlad Tepesch schrieb: > wie kommt man auf die idee 8-Pin-Controller zu benutzen, wenn man viele > Outputs haben will? > vor allem diese dann zu vernetzen. > Entweder gleich nen größeren µC oder einfach 74X595 oder irgendwelche > per SPI fütterbaren Treiber ICs als Porterweiterung. Auch wenn ich eigentlich schlafen gehen wollte: Das lasse ich mir nicht gefallen. Mit Verlaub: Wie kommt man auf die Idee, einen riesigen Beitrag nach der sinnlosesten Stelle zu durchsuchen, diese aus dem Zusammenhang zu reißen und den Trollen zum Fraß vorzuwerfen? Ich finde es nicht zu weit hergeholt, das als eine Frechheit zu bezeichnen. Richtigstellung: Besagte Pläne sind schon lange zerrissen. Ich schrieb von meinem Einstieg in die AVRASM-Programmierung, kannte damals nur den Tiny13 und hatte nur dafür die Ausrüstung - und hatte irgendwie Blut geleckt und dann vorschnell gehandelt. DESHALB hab ich 50 Stück von den Teilen. Und vielleicht bekommen sie ja bald einen Sinn. Mehr nicht, nur eine kleine Anekdote... Grüße an alle, die mich ernsthaft beraten wollen und bestimmt auch mal Fehler gemacht haben, euer LDer
Wenn das Ding einen Heckrotor hat, dann mal den Anstellwinkel der Blätter verändern- steiler oder halt flacher(evtl. mit Feuerzeug). Wenn koaxial, dann bei einem der beiden Rotoren das oben gesagte machen. Danach die Trimmung, die dann wieder im einstellbaren Bereich ist, justieren. guude ts
Vielleicht ist der Heckmotor auch einfach am Ende. Die Dinger werden ständig im Überlastbereich betrieben und sterben deshalb relativ schnell. Man kann die aber als Ersatzteil nachkaufen. Die Frage ist nur, ob das inklusive Versand dann noch soviel billiger ist als ein kompletter Heli.
Jörn-michael M. schrieb: > Wie kommt man auf die Idee, einen riesigen Beitrag nach der sinnlosesten > Stelle zu durchsuchen, die Stelle ergab halt keinen Sinn, deswegen habe ich nachgehakt > diese aus dem Zusammenhang zu reißen und den > Trollen zum Fraß vorzuwerfen? war auch nicht bös gemeint und wollt eauch nicht trollen. Jörn-michael M. schrieb: > Ich finde es nicht zu weit hergeholt, das als eine Frechheit zu > bezeichnen. diese Meinung gestehe ich dir zu Jörn-michael M. schrieb: > Grüße an alle, die mich ernsthaft beraten wollen und bestimmt auch mal > Fehler gemacht haben, Nebenbei bemerkt, habe ich das auch versucht, nur ist bisher keiner auf meinen Vorschlag eingegangen.
Vom Lernfaktor des Projektes mal abgesehen, wird die Aktion nicht viel bringen, da sich das Teil auch mit einer Eigenbau-Funke nicht besser fliegt. Koax-Helis, die man für um die 100,-€ kaufen kann, sind die Untergrenze, wenn das Fliegen auch ein kleines bißchen Spaß machen soll. Von Steuerbarkeit kann man eigentlich erst bei richtigen RC-Helis reden, die sich in der Klasse 450 aufwärts bewegen. Alternativ das Gamepad im Originalzustand am PC anstecken und virtuell fliegen. Den Simulator Heli-X gibts in der Version 0.9 kostenlos: http://www.heli-x.net/download.shtml#DownloadHeliX Auch für alle wärmstens zu empfehlen, die vor dem Einstieg in die reale Fliegerei ihre Reflexe materialverlustfrei trainieren wollen. Der Realitätsgrad ist in Bezug auf das Flugverhalten recht nah an der Wirklichkeit.
Moin Moin, Leute, was war gleich die Frage? Ich glaube das war (zusammengefasst): Wie kann ich am besten das Protokoll auf der IR Schnittstelle ausmessen wenn ich keinen Oscar habe? Bisherige Vorschläge: - Soundkarte als "Oscar" oder "SIgnalrecorder" benutzen. - IRMP (Anleitung hier im Board) - Tiny als LogicAnalyser @LDer Auch wenn ich keine eine der benötigten Komponenten hier habe stehe ich gerne für etwas Hirnsparring zur Verfügung. Auch wenn es etwas her ist, habe ich mal das gleiche Problem gehabt: Keine Kohle und viele (verrückte) Ideen. Eigentlich habe ich das gleiche Problem noch heute ;-) Sag an welche Richtung Du gehen möchtest und welche Fragen Du hast. Grüße Frank
Vlad Tepesch schrieb: > Nebenbei bemerkt, habe ich das auch versucht, nur ist bisher keiner auf > meinen Vorschlag eingegangen. Alles klar, T'schuldigung. Meine Aussage bezog sich natürlich nur auf den einen Post - nicht böse sein ;) Frank Sander schrieb: > (zusammengefasst): > Wie kann ich am besten das Protokoll auf der IR Schnittstelle ausmessen > wenn ich keinen Oscar habe? > > Bisherige Vorschläge: > - Soundkarte als "Oscar" oder "SIgnalrecorder" benutzen. > - IRMP (Anleitung hier im Board) > - Tiny als LogicAnalyser Danke schonmal dafür. "Oscar" ist ein Oszilloskop? Okay :D > Sag an welche Richtung Du gehen möchtest und welche Fragen Du hast. Interessant finde ich den IRMP, aber nach wie vor auch meine eigene Idee mit dem Tiny. Sobald ich am Montag wieder etwas Zeit(und mein Buch zurück) habe, kann ich mich mal an mein Steckboard setzen. Genauere Fragen ergeben sich dann schon... Icke ®. schrieb: > Vom Lernfaktor des Projektes mal abgesehen, wird die Aktion nicht viel > bringen, da sich das Teil auch mit einer Eigenbau-Funke nicht besser > fliegt. Koax-Helis, die man für um die 100,-€ kaufen kann, sind die > Untergrenze, wenn das Fliegen auch ein kleines bißchen Spaß machen soll. Das sind alles Dinge, die ich schon weiß - meine Mini-Helis habe ich geschenkt bekommen, und eigentlich fliege ich sowieso lieber Flächenmodelle ;) Grüße, euer LDer
Aus den 50 tinys könnte man doch nen neuronales Netzwerk basteln (Die einzelnen tinys seriell vernetzen mit Adressierung wo die daten hinsollen. Oder man Teilt Seine Software in mehre Threads bzw. Prozesse auf und Synchronisiert über Mutexe oder Semaphore indem man einfach nen paar Portpins miteinander verbindet und ne Datenleitung legt. Lustige sache einfach zu basteln und hey 50 x 8MIPS = 400MIPS.
Hallo LDer, denn mal los ;-) Einfach hier die Fragen rein tickern. Grüße Frank P.S. Auch wenn ich das mit den Flächenmodellen nicht ganz verstehen will... ;-)
Frank Sander schrieb: > P.S. Auch wenn ich das mit den Flächenmodellen nicht ganz verstehen > will... ;-) Gut. Deutch: Flugzeuge - mit TragFLÄCHE also :D
Auch wenn es jetzt gerade etwas OT wird: Hat den ein Rotor am Heli keine Fläche? lol Sorry, net böse sein bitte. Ich fliege halt beides gerne ;-) Bin jetzt still und schaue was Du mit den Helis anstellst ;-) Grüße Frank
Um den Thread nicht sterben zu lassen: Mir fehlt immer noch ein Board - das werde ich aber am Mittwoch zurück haben - Muss es zurzeit noch bei nem Kommilitonen lassen, damit der eine Testplattform hat...
Noch ein Tipp vom Helipiloten: Nimm dir mal eine gute Lupe, ( Am besten eine 8x Uhrmacherlupe ) und kontrolliere die Achse des Heckrotors. Du wirst erstaunt sein, was sich da Alles drumgewickelt hat und den Motor bremst.
Bernd Funk schrieb: > Noch ein Tipp vom Helipiloten: Nimm dir mal eine gute Lupe, > ( Am besten eine 8x Uhrmacherlupe ) und kontrolliere die > Achse des Heckrotors. > Du wirst erstaunt sein, was sich da Alles drumgewickelt hat > und den Motor bremst. Ähnliche Ratschläge kamen ja schon ein paar Mal in diesem Thread, deshalb: - Es ist ein Koax. Der Heckrotor hat also nix damit zu tun. - Das Gerät ist fabrikneu - frisch aus der Packung. - Es liegt nicht an der Trimmung, die ist schon komplett bis zum Anschlag gedreht. - Es geht mir nicht primär darum, den Heli zu reparieren - sondern darum, etwas Interessantes zu tun und was dabei zu lernen. - Diese Ratschläge sind echt gut gemeint, und ich respektiere das. Nur leider sind die irgendwie fehl am Platze hier, tut mir echt leid. Grüße, euer LDer
Hallo, wenn du das Pollin Board mit der Erweiterung hast, kannst du mal folgendes probieren. Auf der Erweiterung ist doch ein TSOP drauf, verbinde mal den IR mit dem Verstärker auf dem Board. Wenn man nun beim Senden was hört, scheint der Sender im Standardbereich zu senden.
Ich schrieb: > Wenn man nun beim > Senden was hört, scheint der Sender im Standardbereich zu senden. Ich hab das Board heute mitnehmen können - wird erstmal nirgends dringender gebraucht :) Den Empfänger erstmal direkt an eine LED angeschlossen - und wahrlich - ich bekomme gar feine, sogar deutlich sichtbare Signale! In den nächsten paar Tagen sollte ich ein kleines Programm geschrieben haben, was die Signale auch recht deutlich darstellt. Dann kann ich erste Ergebnisse, bereit zur Analyse, vorzeigen :) Grüße, euer LDer
Ja, ich hab was!
Allerdings muss wohl noch etwas getweakt werden. Schaut euch das mal
bitte an!
Der Anhang ist wie folgt:
- IRLog.c - das Programm auf dem µC. Hier wird mit einem Timer die Zeit
als 64b-Int gemessen, und sobald ein PCIRQ am Infrarotempfänger
ausgelöst wird, wird der Wert im SRAM zwischengespeichert. In den Pausen
zwischen den Pin-Interrupts wird einfach der Inhalt des SRAM über den
UART an dem PC gesendet und die "Queue" geleert.
- uart.c - Ein (Linux-)C-Programm, um die Daten zu parsen. Hier wird der
Port ttyUSB0 geöffnet und ein Byte empfangen ("Reset"-Byte 0xFF). Dann
werden 8-Byte-Blöcke empfangen, geparst und ausgegeben.
- test.out - eine Ausgabe vom uart.c (Allerdings mit dem
"Ausschalten"-Signal meiner Fernseherfernbedienung als Testdaten)
Nun zu meinen Fragen:
1. Wie kann es zu den 0er-Ausgaben im test.out kommen?
Übertragungsfehler, oder eher ein Denkfehler bei meinem Pointerkrieg in
der IRLog?
2. Die Daten werden meiner Meinung nach chronologisch richtig gesendet.
Warum kommen sie dann trotzdem scheinbar in völlig zufälliger
Reihenfolge am Linux an? Ich vermute hier eine Eigenart von Linux, weil
meine Windows-VM (zum allergrößten Teil) die richtige Reihenfolge
anzeigt.
Kann ich Linux dazu bringen, das genauso zu tun? Außer die Ausgabe zu
sortieren, das kann ich auch :)
3. Gibt es rein zufällig irgendwen, der schonmal etwas geschrieben hat,
mit dem ich diese Zahlen automatisch in eine Signalkurve umwandeln kann?
Interpretation: Wenn das Programm als erstes "x" und dann "x+1" sendet,
heißt das: "Steigende Flanke an Zeitpunkt x, fallende Flanke an
Zeitpunkt x + (nahezu) 250 nSec"
Grüße - und ich freu mich auf eure Beiträge,
euer LDer
Jetzt bin ich offiziell beeindruckt. gcc -o uart uart.c ./uart (Reset, Testeingabe mit Fernbedienung) (cat my.out | sort -n | uniq) > my2.out rm my.out; mv my2.out my.out; mkdir parse gcc -o interpret interpret.c ./interpret gab mir die Ausgaben, die ich im zip angehängt habe. Leute... "Das hier ist der Wahrheit!" :) Ich nähere mich der Lösung des eigentlichen Problems! Grüße, euer LDer
Moin LDer, und ich sach noch "...denn mal los..." Ich habe zwar irgendwie die Frage mit dem Sortieren noch net verstanden, aber das liegt evtl. am Schlafmangel auf meiner Seite ;-) Bin schon gespannt was Du raus bekommst wenn Du die Heli"fernbedienung" versuchst. Grüße Frank
Hier hab ich mal 10 Wiederholungen des Idle-Signals (Nur Anschalten der Fernsteuerung). Vielleicht hat ja jemand eine brauchbare Idee, wie ich das in eine Kurve umwandeln kann? Die Angaben sind in Sekunden. Grüße, euer LDer
Wenn der Koax neu ist --> Umtauschen und nicht verbasteln. Zum Thema Sender. Ein gewisser b-konze(Quax) hat ein Sendemodul für Silverlit Modelle gebaut damit er eine normale Fernbedienungen verwenden kann. http://home.versanet.de/~b-konze/uni_fb/uni_fb.htm Eventuell hilft es dir weiter.
Den ersten Kanal (Hauptrotor Gas) hab ich geknackt. Zu finden als 13-bit Binärcode von Flop 5 - 17. Ich finde Signalblöcke zu jeweils 68 Flops mit einer bestimmten zeitlichen Abfolge. Durch eine zeitliche Abweichung eines Flops wird eine 1 codiert. Was ab Flop 49 passiert, kann ich noch nicht sagen - vielleicht hat die Trimmung einen Einfluss darauf. Ich war also erstmal wieder erfolgreich^^ Bei Gelegenheit gehts hier weiter - so wie ich mich kenne, ist das schon morgen ;). Dann stelle ich auch die aktuelle Version meiner Decoder-Suite hier rein und schreib was dazu. Grüße, euer LDer
Jörn-michael M. schrieb: > so wie ich mich kenne, ist das schon morgen ;). Schneller sogar! Anbei ist der "Graph" der Folgenden Eingabe: (Trimmung 0%, nicht mit in den Daten) Gas auf 100%. Steuerhebel vorwärts, vorwärts rechts, rückwärts rechts, rückwärts links, vorwärts links, vorwärts, Mittelstellung (Drehung im Uhrzeigersinn). Trimmung 100%. Selbe (annähernd) Drehung im Uhrzeigersinn. Gas auf 0%. Eine Zeile entspricht hier einem 68-Flop-Datensatz (bzw. 67 Bit). Es wär natürlich toll, wenn jemand hier mal drüberschauen könnte! Ich blicke nämlich nicht ganz durch... Grüße, euer LDer
... ich vergaß fast: Zumindest durch die letzten paar Bits blick ich absolut nicht durch. Mein Verstand sagt mir, dass da eine Prüfsumme hintendranhängt... Ansonsten hab ich den Code: - 4 Synchro-Bit "0" - 13 Bit Z-Achse (Gas Hauptrotor) - 1 Bit "0" - 7 Bit X-Achse (Gieren) - 1 Bit "0" - 7 Bit Y-Achse (Nicken) - 1 Bit "0" - 1 Bit Vorzeichen X-Achse - 1 Bit "0" - 1 Bit Vorzeichen Y-Achse - 3 Bit "0" - Was auch immer. Prüfsumme? Maske: 0000-GAS---------0-GIER--0-NICK--0X0Y000????????????????????????????? Grüße!
Hallo µC-Gemeinde!
Ich bin bereit, meine gesammelten Erkenntnisse über den "Copter V-MAX
Hypersonic" Helikopter vorzustellen. Auch die letzten Bits des Codes
habe ich dechiffrieren können - hier ist keine Prüfsumme versteckt,
sondern tatsächlich die Trimmung.
Die gesamte Flopmaske sieht wie folgt aus:
0000202020202020202020202020202020101020202020201010202010202020200
(Form **)
------S------ ---G--- ---N--- g n t ------------T------------
Links steht der Flop 1, rechts der letzte. Der nullte Flop ist das erste
Einschalten der Sende-LEDs, findet bei 0 Sekunden statt, dient nur der
Synchronisation und ist hier nicht dargestellt.
Die nächsten Flops finden bei x Sekunden statt, wobei x der angehängten
Datei "x.txt" entnehmbar ist; ein 68-Flop-Signal dauert demnach etwa
32ms.
Nur alle zwei Flops ist ein Bit codiert.
=> Bereinigt: 0022222222222222211222221122122220 (Form *)
Eine 1 in der Bitmaske bedeutet, dass dieser Flop verzögert werden muss,
um vom Heli als Highbit ausgewertet zu werden - eine 2 bedeutet, dass
der Flop verfrüht als high interpretiert wird - "verfrühen" oder
"verzögern" steht hier für eine zeitliche Verschiebung um (vermutlich)
mindestens 400ms.
Folgende Variablen sind hier zu finden:
S - Schub des Hauptrotors (7 bit)
G - Achse Gieren/Drehen (4 bit)
g - Vorzeichen Gieren (0/-: links, 1/+: rechts)
N - Achse Nicken/waagerechter Schub (4 Bit)
n - Vorzeichen Nicken (0/-: Nase aufwärts/Rückschub, 1/+:
Abwärts/Vorschub)
T - Trimmung für Gierachse (13 bit)
t - Vorzeichen Trimmen (0/-: Richtung rechts, 1/+: Richtung links)
Soll ein Befehl codiert werden, geht das wie folgt:
Befehl: S = 60, gG = +7, nN = -2, tT = -30
=> etwa: "Höhe halten, Flug nach vorne links"
Binär: S = 0111100, gG = 1 0111, nN = 0 0010, tT = 0 0000000011110
Konkatenation: 0001111000111001010000000000111100
Anwenden: 0022222222222222211222221122122220
=> 0002222000222002010000000000122200 (Form *)
=> 0000002020202000000020202000002000100000000000000000000010202020000
(Form **)
Diese Flopfolge kann gesendet werden.
Achtung: Sämtliche Experimente wurden (bisher) nur mit Kanal "B" der
IR-Fernbedienung durchgeführt!
Viele Grüße,
euer LDer!
##################### ÜBER DEN ANHANG #####################
x.txt - Oben schon angesprochen - enthält die Standardflopfolge (34
Nullen für den Heli) in Sekunden
package.zip - enthält einige C-Dateien:
- uart.c - Zur Rohdatenerfassung - erstellt (Linux, Eingabegerät
einstellbar, z Zt. /dev/ttyUSB0) eine Datei uart.out mit Sämtlichen
Werten, die der µC sendet.
- interpret.c - Zur Aufteilung der Rohdaten in 67-Werte-Blöcke (68 Werte
mit Nullsetzen des ersten Werts). Erstellt im Unterverzeichnis parse/
eine Datei out.*** für jeden Werteblock.
- median.c - Liest sämtliche out-Dateien aus dem Parse-Ordner und legt
eine median.out an, die die Mediane über alle 67 Werte enthält. Mit
uart, interpret und median lässt sich die "Standardflopfolge" quasi
perfekt berechnen. Dazu muss nur der Epsilon-Wert (siehe unten) bekannt
sein, mit dem die Zahlen in Zeitwerte umgerechnet werden können.
- diff.c - Liest auch die out-Daten ein, aber erzeugt für jede out-Datei
eine Signaldarstellung nach (Form **) in einer neuen Zeile der Datei
parse/diff.out. Benötigt median.out.
- uart_diff.c - Eine Live-Ansicht des Signals auf /dev/ttyUSB0
(anpassbar, aber nicht bugfrei - muss regelmäßig neugestartet werden, da
in zufälliger Abfolge gravierende Messfehler auftauchen). Benötigt
median.out.
- IRLog.c - Das Programm für den µC - bei mir ein ATmega644. Per Timer
wird ein Zähler inkrementiert und bei PinChange im RAM
zwischengespeichert, bis er auf das UART ausgegeben wird. Eine einfache,
schnelle, aber speicherintensive Queue. Über das Define "Epsilon" lässt
sich die Zeit (in Sekunden) zwischen zwei Timerinterrupts einstellen.
ein Rundungsfehler bleibt allerdings wird hier allerdings nicht
automatisch erkannt, aber lässt sich durch Anpassen der Werte von
µC-Takt, Epsilon und dem Define PS ausbügeln.
Hallo Jörn Michael, ordentlich und gut beschrieben!! Sehr schön gemacht. Jetzt fehlt noch ein Flugvideo vom "Rechner" gesteuert ;-) Ne mal im ernst das gefällt mir was Du da machst. Frage: willst DU so weit gehen den Heli vom tiny aus zu steuern? Grüße Frank
Jörn-michael M. schrieb: > Die gesamte Flopmaske sieht wie folgt aus: > > 0000202020202020202020202020202020101020202020201010202010202020200 > ------S------ ---G--- ---N--- g n t ------------T------------ (...) > > Folgende Variablen sind hier zu finden: > S - Schub des Hauptrotors (7 bit) > G - Achse Gieren/Drehen (4 bit) > g - Vorzeichen Gieren (0/-: links, 1/+: rechts) > N - Achse Nicken/waagerechter Schub (4 Bit) > n - Vorzeichen Nicken (0/-: Nase aufwärts/Rückschub, 1/+: > Abwärts/Vorschub) > T - Trimmung für Gierachse (13 bit) > t - Vorzeichen Trimmen (0/-: Richtung rechts, 1/+: Richtung links) Ich muss mich doch noch einmal korrigieren; eine Sache fiel mir auf: Der IR-Kanal ist scheinbar gar nicht kodiert, obwohl er ja enthalten sein muss - komisch...? Sehr. 0000202020202020202020202020202020101020202020202010102020101010100 ------S------ ---G--- ---N--- g n t ----T---- -C- -----?----- (...) Folgende Variablen sind hier zu finden: S - Schub des Hauptrotors (7 bit) G - Achse Gieren/Drehen (4 bit) g - Vorzeichen Gieren (0/-: links, 1/+: rechts) N - Achse Nicken/waagerechter Schub (4 Bit) n - Vorzeichen Nicken (0/-: Nase aufwärts/Rückschub, 1/+: Abwärts/Vorschub) T - Trimmung für Gierachse (5 bit) t - Vorzeichen Trimmen (0/-: Richtung rechts, 1/+: Richtung links) C - Kanalumschalter: 00 - A, 01 - B, 10 - C ? - Wieder mal unbekanntes Territorium. Ich tippe mal wieder vorsichtig auf zwei Checksummen zu 2 bzw. 4 Bit (seht ihr das Muster nicht auch? finde ich sehr auffällig :D) Im Anhang das Übliche. Einzige Neuerung: uart_diff erkennt Fehler nun automatisch und bricht ab. Frank Sander schrieb: > ordentlich und gut beschrieben!! > Sehr schön gemacht. Jetzt fehlt noch ein Flugvideo vom "Rechner" > gesteuert ;-) > > Ne mal im ernst das gefällt mir was Du da machst. Danke! Freut mich, dass es gefällt (und vielleicht auch als Basis für Weiteres dienen kann?) > Frage: willst DU so weit gehen den Heli vom tiny aus zu steuern? Nur als "Verbindungsglied", und bei einem tiny wird wahrscheinlich der RAM nicht reichen. Ich werde einen PC per UART die Steuerbefehle an den mega senden lassen, und von dort die Übersetzung nach IR machen. Ich brauche nur noch den Algorithmus hinter der Checksumme, ein paar Stunden, um einen Übersetzer zu schreiben... und ne fette Infrarotdiode. Grüße, euer LDer
Nabend µC! Inzwischen hab ich zwar die hashes knacken können:
1 | unsigned char hashX(unsigned char S, unsigned char N, unsigned char G, unsigned char T, unsigned char t) {
|
2 | unsigned char ret = G; |
3 | if(S > 0) |
4 | ret += (S / 16) + 1; |
5 | if(N > 7) |
6 | ret++; |
7 | if(T > 10) |
8 | if(T > 25) {
|
9 | ret += 2; |
10 | } else ret++; |
11 | if(t) |
12 | ret += 2; |
13 | return (ret & 3); |
14 | } |
15 | |
16 | unsigned char hashY(unsigned char S, unsigned char N, unsigned char T) {
|
17 | return -(S + N + T) & 15; |
18 | } |
mit (...)02020101010100
-X- ---Y---
und S, N, G, T, t wie oben.
########################################################################
#
Aber... Ich werde hier gerade wieder wahnsinnig. Da das Fluggerät echt
nicht das Gelbe vom Ei war, habe ich mir kurzerhand was schickeres
gekauft - auch in der lowCost-indoor-InfraRot-Klasse, aber bitte mit
Gyro. Also werde ich hier demnächst noch das Phantom/Helicox
6010-Protokoll entschlüsseln und vorstellen wollen.
Leider hat es mir in der Zwischenzeit (während einer anderen Anwendung)
meinen Mega644 zerrissen, für den ich IRLog geschrieben habe - also
ausgetauscht gegen einen Mega8 - übrigens hab ich mir nun das
Eclipse-AVR-Plugin installiert, statt immer die doofe VM laufen zu
lassen. Bis jetzt läufts auch erstaunlich gut! Aaaaaber...
Zum Problem: Irgendwas mach ich bestimmt falsch. Den Timer2 will ich für
eine "Systemzeit" (halfMillis - 32 Bit) benutzen, die alle 50µs
inkrementiert wird. Normal müsste ich mit dem Wertebereich ja fast
zweieinhalb Tage lang zählen können, aber diese Systemzeit läuft trotz
allem alle paar Sekunden über.
Beim Mega644 war das irgendwie... logischer ~.~
Ich habe die neue IRLog.c mal einfach angehängt und hoffe, dass jemand
da mal reinschauen kann...
Danke im Voraus!
euer LDer
Am µC liegt's auch nicht - mit mega16 und tiny2313 dasselbe Problem. Auch mit AVR Studio dasselbe - das Eclipseplugin/Linux ist auch nicht die Ursache. Was mach ich also falsch? Hab ich da einen riesigen Logikfehler drin? Auch wenn ich den Prescaler auf 1024 einstelle und OCR2 auf 255 - läuft meine Systemzeit noch immer mehrmals in der Sekunde über. Super, jetzt fangen schon Maschinen an, mich zu mobben :D Grüße, LDer
Ich würd schon mal die cli und sei aus den ISRs rausnehmen. Das sollte ja der Compiler selbst machen. Du erlaubst im Moment mit dem sei() am Ende, dass der nächste Interrupt ausgeführt wird, bevor im gerade aktiven die Register wieder hergestellt wurden. Du hast da ja die festen Adressen TPL und TPH, aus deren Bereich deine Pointer sind. TPH-TPL sind ca. 1000Byte, so viel RAM hat der Tiny eher nicht, beim Mega16 wirst du garantiert alles mögliche überschreiben :) So hundert prozentig versteh ich noch nicht was insgesamt passiert. Ich seh da so ne Art FIFO, in dem du den Zeitpunkt eines Ext. Int. (Tastendruck?) speicherst und anschließend per UART rausschickst. Kommt das hin? Wenn ja, warum machst du das dann nicht über n ganz schnödes Array? Viel langsamer sollte das nicht sein und der Compiler kann sich das Array da hin legen wo er meint und sich im Zweifel beschweren. Hoffentlich hilfts :) Gruß, Alex
Alexander v. Grafenstein schrieb: > Ich würd schon mal die cli und sei aus den ISRs rausnehmen. Das sollte > ja der Compiler selbst machen. Du erlaubst im Moment mit dem sei() am > Ende, dass der nächste Interrupt ausgeführt wird, bevor im gerade > aktiven die Register wieder hergestellt wurden. Okay, klingt logisch. ~ausprobier~ Keine Veränderung > Du hast da ja die festen Adressen TPL und TPH, aus deren Bereich deine > Pointer sind. > TPH-TPL sind ca. 1000Byte, so viel RAM hat der Tiny eher nicht, beim > Mega16 wirst du garantiert alles mögliche überschreiben :) Ja, auf dem Tiny passe ich die Adressen schon an - ich will das Programm ja nicht verkaufen ;) Aber was soll ich da besonderes überschreiben? Für die globalen Vars hab ich einen Offset von 10B, der reicht mir. Und der Stack ist hier sowieso vernachlässigbar - die einzigen Funktionsaufrufe ohne inline sind in der Initialisierung. ~RAMleerungsschleife ans ende pack~ Keine Veränderung. Leider. > So hundert prozentig versteh ich noch nicht was insgesamt passiert. Ich > seh da so ne Art FIFO, in dem du den Zeitpunkt eines Ext. Int. > (Tastendruck?) speicherst und anschließend per UART rausschickst. Kommt > das hin? Exakt. Nur dass der Interrupt ein IR-Empfänger ist. Würde ich den Zeitpunkt direkt in der ISR übers UART schicken, verfälsche ich mir alles... > Wenn ja, warum machst du das dann nicht über n ganz schnödes Array? Viel > langsamer sollte das nicht sein und der Compiler kann sich das Array da > hin legen wo er meint und sich im Zweifel beschweren. Richtig - das stört mich an der Sache. Bei nem Array weiß ich nie genau wo's liegt - und wenn er dann auf die Idee kommen sollte, mir irgendwas mit Reallokation einzuflechten, hab ich erst recht keine Kontrolle mehr, was genau passiert (auch wenn das echt unwahrscheinlich is). Ach, ich seh schon. Dieses zeitkritische Zeug sollte man am Besten ASM'en... > Hoffentlich hilfts :) Ich hab's auch gehofft. Aber so wie's aussieht, werd ich wohl nen neuen Mega644 brauchen - der 8er und 16er ist offenbar... eigensinnig. > Gruß, Alex Grüße zurück! PS: Ich hab den Mega16 hier mal vor einiger Zeit versehentlich etwas elektrisch gequält. Kann das irgendwas verschmort haben und sich gleichzeitig auf meinen Tiny2313 und den Mega8 übertragen haben, die beide zu dem Zeitpunkt mehrere 100 Kilometer von mir entfernt waren?
Autsch - ich habs. Ich erkläre feierlich: "LDericher ist ein Vollidiot". Alles läuft perfekt. ich habe nur die 32-Bit-Werte falschrum übertragen - das HighByte muss zuerst, dann das LowByte. Irgendwie dachte ich, die Pointer drehen es um - tun sie aber natürlich nicht. Im Anhang: IRLog, passend für Mega16, und wahrscheinlich auch Mega8 und Tiny2313 (mit TPL/TPH anpassen an Ramgröße) und wohl auch für Mega644, wenn man die Interrupts entsprechend anpasst. Übrigens nochmal uart.c für Linux - hab ich aber eigentlich nix dran geändert... Grüße, LDer
Jörn-michael M. schrieb: > Aber was soll ich da besonderes überschreiben? Für die globalen Vars hab > ich einen Offset von 10B, der reicht mir. Naja, z.B. halfmillis :-P Hast du im map-file mal geschaut, wo der Compiler die Variablen hinlegt? Aber könnt sich natürlich schon ausgehn. Schöner Stil ists nMn auf jeden Fall nicht, wenns nicht unbedingt notwendig ist. Du könntest zumindest ein Array anlegen, und dann mit Pointern arbeiten, die mit arrayname[0] initialisiert werden. was mir noch aufgefallen ist: - SP = RAMEND; sollte überflüssig sein, evtl. auch schädlich? - #define COMP (EPSILON * CPUFREQ / PS) da würd ich noch nen cast auf uint8_t davorsetzen, auch wenns wohl nicht notwendig ist. Jörn-michael M. schrieb: > Und der Stack ist hier sowieso vernachlässigbar - die einzigen > Funktionsaufrufe ohne inline sind in der Initialisierung. Und wo sichern die ISRs die Register hin? Kennst du den Compiler ansonsten so genau, dass du sicher sagen kannst, dass er den Stack nicht verwendet? Woran siehst du denn eigentlich, dass die Systemzeit überläuft? Weil du das per UART empfängst, oder hast du's dir im Simulator/Debugger angeschaut? Bei ersterem kann ja im Prinzip das komplette Programm schuld sein. Jörn-michael M. schrieb: >> So hundert prozentig versteh ich noch nicht was insgesamt passiert. Ich >> seh da so ne Art FIFO, in dem du den Zeitpunkt eines Ext. Int. >> (Tastendruck?) speicherst und anschließend per UART rausschickst. Kommt >> das hin? > Exakt. Nur dass der Interrupt ein IR-Empfänger ist. Würde ich den > Zeitpunkt direkt in der ISR übers UART schicken, verfälsche ich mir > alles... Ich würde das Versenden eher über einen Ringpuffer lösen. Schau dir mal die Bibliothek von Peter Fleury an (interupt-basierter UART-versand mit integrierten Puffern). Ich hatte bei meinem aktuellen Bastel-Projekt Bedenken, weil ich da auch sehr zeitkritische ISRs habe, die dann evtl. von den UART-ISRs aufgehalten werden, aber die ISRs sind wirklich sehr sehr kurz gehalten. Da weißte dann, dass zumindest die UART-Übertragung zuverlässig funktioniert. die Routine zum Puffer füllen kannst du ja auch noch inline machen, wenns nötig is. Wie schnell erwartest du denn eigentlich die Signale am INT0? Wenn du eh ASM-Erfahrung hast, dann schau dir das ganze doch mal im Simulator genau an. Ich glaub immernoch, dass es nicht am Timer sondern am Rest drumherum liegt. Gruß, Alex
Aehm verzeihung, aber das ist einfach nur schrott... Klar glaube ich dir, dass du in diesem Miniaturbeispiel den Speicher überblicken kannst, jedoch hast du deinem Linker vermutlich nichtmal mitgeteilt, dass der Speicher von 0x70 aufwärts dein eigener ist und er den nicht verwenden darf? Es gibt keinen Grund das nicht als
1 | #define TIME_SPACE_SIZE (((0x045F-20) - (0x0060 + 10))/4)
|
2 | volatile uint32_t timeSpace[TIME_SPACE_SIZE] |
zu deklarieren! Statt dem externen Interrupt würde ich den InputCapture zum Einlesen vorschlagen - aber so gehts natürlich auch. Sobald du in der ISR erkennst, dass dein Zeiger aus deinem Speicher rausläuft (statt Zeiger doch einfach nen Index nehmen, ist beim Zugriff 1 takt langsamer aber deutlich schöner), entweder die ISR abschalten oder den Zeiger zurücksetzen (& Flag zum Senden in der Main) Ah Moment, das sieht in der Main so aus, als wäre das schon eine Ringpufferimplementierung? Ich muss sagen: Ich verstehe sie nicht. Warum nicht eine "übliche" Implementierung mit dauerhaften Schreib- und Lesezeigern? Ein Problem hast du, wenn der Puffer voll ist. Die Infrarotsignale sind eventuell schneller als dein UART. Dort ist es vermutlich sinnvoll, bei vollem Puffer den einfach erst wieder leerzulesen, solange alle Zeichen zu droppen und dann erst den Puffer wieder zu füllen. Sagtest du nicht du studierst Info im 4. Semester? Da solltest du diesen Zeigerquatsch eigentlich nicht verzapfen. Deine "Timingprobleme" von denen du sprichst hast du dir auch garantiert selbst eingebaut. Dein Problem ist an keiner Stelle so zeitkritisch, das man irgendwie tricksen muss. Das kann man einfach in schönem C runterschreiben.
Joa, dann lag's wohl nicht am Timer ;) aaaaalso, Erste Erkenntnis über das Protokoll: Es handelt sich um ein Protokoll, bei dem 48 An/Aus-Flops die Daten bestimmen. Nach erster Sichtung vermute ich, dass hier ähnlich gesendet wrd wie beim Silverlit-Protokoll: 0: x1 ms an, x2 ms aus 1: y1 ms an, y2 ms aus Die kleinste Zeiteinheit im Protokoll scheint 5ms zu sein. Und @Alex - ich kenne den Compiler einigermaßen gut - und weiß auch, dass der Stack zum Kontextsichern benutzt wird. Deshalb hab ich auch einen Puffer am Ende vom RAM eingerichtet. Wenn meine FIFO schneller gefüllt wird, als ich sie über UART leeren kann, stoppe ich einfach sämtliche Ausführung. Nicht die schönste Methode, aber meiner Meinung nach sehr laufzeitfreundlich. Bisher reicht mir der Speicher dicke aus - nicht einmal ist das Ding angehalten. Sobald das passiert, muss ich halt umdenken, und vielleicht ein bisschen Performance für Stil opfern. Grüße, LDer
Matthias Larisch schrieb: > Aehm verzeihung, aber das ist einfach nur schrott... Danke! Ich habe mich auch nicht um den Preis für den am Besten gestalteten oder lesbaren Code beworben. Ich will erstmal nur, dass es funktioniert und kann mich dann doch immer noch um den Stil kümmern ;) > Klar glaube ich dir, dass du in diesem Miniaturbeispiel den Speicher > überblicken kannst, jedoch hast du deinem Linker vermutlich nichtmal > mitgeteilt, dass der Speicher von 0x70 aufwärts dein eigener ist und er > den nicht verwenden darf? 0x6A, aber das nur am Rande. Die Bytes davor darf der Linker gern haben. Aber ich richte mich danach, was der Linker anfordert (siehe gcc-Ausgabe) und möchte nicht andersrum hier anfangen, den Linker einzuschränken. Fänd ich hier etwas Overkill, ansonsten gebe ich dir recht. > Es gibt keinen Grund das nicht als >
1 | > #define TIME_SPACE_SIZE (((0x045F-20) - (0x0060 + 10))/4) |
2 | > volatile uint32_t timeSpace[TIME_SPACE_SIZE] |
3 | >
|
> > zu deklarieren! okay, das sieht doch einfacher aus, als mein Hirn es glauben wollte. Werd ich ändern - da es jetzt ja läuft ;) > Statt dem externen Interrupt würde ich den InputCapture zum Einlesen > vorschlagen - aber so gehts natürlich auch. Habe ich mich noch nicht mit auseinandergesetzt - macht aber vielleicht Sinn. Gibt es zu InputCapture (außer Datenblatt) noch ausführlichere Quellen? > Sobald du in der ISR erkennst, dass dein Zeiger aus deinem Speicher > rausläuft (statt Zeiger doch einfach nen Index nehmen, ist beim Zugriff > 1 takt langsamer aber deutlich schöner), entweder die ISR abschalten > oder den Zeiger zurücksetzen (& Flag zum Senden in der Main) Hmmmm, ja. Hab den Satz nur angelesen, aber wie gesagt: Ich mach noch schön. Dann bist du auch zufrieden :) > Ah Moment, das sieht in der Main so aus, als wäre das schon eine > Ringpufferimplementierung? Ich muss sagen: Ich verstehe sie nicht. Warum > nicht eine "übliche" Implementierung mit dauerhaften Schreib- und > Lesezeigern? Ein Ringpuffer ist das nich. Eher ein normaler Puffer. Wenn ich in der Main erkenne, dass der Puffer nicht mehr leer ist, schicke ich den Inhalt einfach per UART raus - und sobald er wieder leer ist, setze ich den Ende-Zeiger wieder auf den Start. > Ein Problem hast du, wenn der Puffer voll ist. Die Infrarotsignale sind > eventuell schneller als dein UART. Dort ist es vermutlich sinnvoll, bei > vollem Puffer den einfach erst wieder leerzulesen, solange alle Zeichen > zu droppen und dann erst den Puffer wieder zu füllen. Richtig. Darauf reagiere ich auf "windowsmanier" - einfach alles anhalten. Ist aber bisher noch alles gut gegangen ;)
Inputcapture: Konfigurieren kannst du, wann er "auslösen" soll. Typisch ist das steigende oder fallende Flanke. Dann bekommst du einen Interrupt (ICP für InputCapture) und im ICP Register steht der genaue Zählerstand, bei dem das Ereignis aufgetreten ist. Damit kannst du also das Timing noch genauer bestimmen, ist aber bei deinem Anwendungsfall total egal :) 5ms für die Zeiteinheiten erscheint mir zu lang. Ich kenne das Protokoll nicht (werde heute abend mal meinen Heli aufzeichnen), aber es sollte eher im Bereich 0,5-2ms pro Bit sein. Im Anhang hab ich mal nen kleinen Ringpuffer zusammengeklatscht. Überlauferkennung hat er nicht, getestet ist er auch nicht. Bei genügend Speicher (sind ja immerhin 256/4 = 64 Zeiten) sollte aber zumindest ein IR Code reinpassen. Es wird bereits während dem Einlesen gesendet, daher dürfte das reichen, erst recht bei 115200 baud. Den cbi Befehl in Zeile 113 mochte mein Compiler nicht. Was ist denn DDD3? Dein Timer schien mir außerdem mit 50 µs zu laufen, habe es nicht überprüft und stillschweigend auf 10µs gesetzt.
Matthias Larisch schrieb: > Inputcapture: > Konfigurieren kannst du, wann er "auslösen" soll. Typisch ist das > steigende oder fallende Flanke. Dann bekommst du einen Interrupt (ICP > für InputCapture) und im ICP Register steht der genaue Zählerstand, bei > dem das Ereignis aufgetreten ist. Damit kannst du also das Timing noch > genauer bestimmen, ist aber bei deinem Anwendungsfall total egal :) Aha, klingt... nützlich. Für irgendwas. Mal schauen, nicht jetzt. > 5ms für die Zeiteinheiten erscheint mir zu lang. Ich kenne das > Protokoll nicht (werde heute abend mal meinen Heli aufzeichnen), aber es > sollte eher im Bereich 0,5-2ms pro Bit sein. Ja, stimmt schon. Aber ich bin eh noch am wursteln. > Im Anhang hab ich mal nen kleinen Ringpuffer zusammengeklatscht. > Überlauferkennung hat er nicht, getestet ist er auch nicht. Bei genügend > Speicher (sind ja immerhin 256/4 = 64 Zeiten) sollte aber zumindest ein > IR Code reinpassen. Es wird bereits während dem Einlesen gesendet, daher > dürfte das reichen, erst recht bei 115200 baud. Danke, aber ich habe gerade selbst eine Aufhübschung gemacht - vielleicht gibts aber immer noch Dinge, die ich besser machen sollte...? > Den cbi Befehl in Zeile 113 mochte mein Compiler nicht. Was ist denn > DDD3? Es gibt eigene Defines für die Pins in den DDR's - also ist DDD3 == PIND3 == 3. Wusste ich auch noch nicht, bevor ich die Datei geschrieben habe, Eclipse hat's vorgeschlagen. CBI geht nicht? Ist doch oben definiert?! > Dein Timer schien mir außerdem mit 50 µs zu laufen, habe es nicht > überprüft und stillschweigend auf 10µs gesetzt. Siehe oben. Im Anhang meine schönere Version. Grüße, LDer
Zurück zum eigentlichen Thema: Ich habe mir mal so einen Signalverlauf aufgezeichnet (ganz analog auf Papier...). Sieht irgendwie nach Manchester aus - Manchester hat aber keine Takte völlig ohne Flanke und ist (bei gleicher Bitzahl) zeitlich immer gleich lang! Der Code besteht immer aus der gleichen Anzahl Flops bzw. aufgezeichneter Interrupts, nämlich 48 Stück - bei variabler Zeitdauer. Am Anfang findet sich immer ein Sync-Bit der Länge 3ms. Dann kommen 23 Low-High-Paare, wobei jede Low/High-Phase entweder 0.5 oder 1ms dauert. Also ist das ganze Signal vermutlich mindestens 26ms und höchstens 49ms lang. Es ist jede Kombination dabei: (0.5ms low, 0.5ms high) (0.5ms low, 1ms high) (1ms low, 0.5ms high) (1ms low, 1ms high) Wenn t = 0.5ms, dann lese ich (t, t) erstmal unverbindlich als 0 - kommt sehr häufig im Ruhezustand vor. Das ist offensichtlich ein taktloses (hihi), quaternäres Signal mit zwei Pegelzuständen. Grüße, LDericher PS: Jetzt muss ich nur noch mein C-Programm so formulieren, dass es diesen Code liest - da kann ich meine Toolchain verkleinern^^
Es ist einfacher. Ein Signal besteht aus einem Sync-Bit (high/LED an) mit 3ms, und 46 Bit Daten. Dabei ist eine 0 als 0.5ms codiert, eine 1 als 1ms - nach jedem Bit wird die LED getogglet. Ich bin bereit, alles zu entschlüsseln! Grüße, LDer
Hallo, falls jemand Interesse an einer Analyse des Graupner Nano Star 2 Codes und Fernsteuerung über einen WEB-Browser hat (Kamera ist noch in Arbeit)-> http://www.voxsoft.de/fprojekt.htm
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.