Wo gibts denn Bu-Link denn und ist denn nun bestätigt das man damit ins Innere vorstossen kann?
Den Bulink gibts bei Aliexpress. Da hab ich den zumindest gefunden überall anders (dx,goodluckbuy,tmart) gabs den wohl nicht. Ob es geht weiß man noch nicht.. Aber ich hoffe das einer mal die gesendeten Bytes rausbekommt. Möchte ungern dann nochmal 4 Wochen warten müssen und noch weniger mir extra nur fürs unlocken so ein dingen kaufen. Und außerdem hab ich dann nochmal was rumfliegen....
No y. schrieb: > Aber ich hoffe das einer mal die gesendeten Bytes rausbekommt. > Möchte ungern dann nochmal 4 Wochen warten müssen und noch weniger mir > extra nur fürs unlocken so ein dingen kaufen. Und außerdem hab ich dann > nochmal was rumfliegen.... Wenn es mit dem Bulink funktioniert, wird sich wahrscheinlich keiner dir Arbeit antun, das unlock/erase Protokoll nachzubauen. Das zahlt sich dann nicht wirklich aus.
Ehe das Wiki auf mikrocontroller.net nicht existiert, macht es imho wenig Sinn, das entstehende Schaltbild hier immer wieder neu an zu hängen. Ich habe unter http://df2au.nordlink.org/fuerma/ eine Ablage eingerichtet. Der Lesezugriff ist für alle frei. Falls jemand schon Schaltungsteile aufgenommen hat, kann er sie mir per Mail schicken. Auch Scans von handschriftlichen Zeichnungen sind willkommen. Ich baue das dann ein.
Georg G. schrieb: Hallo Georg, > Ehe das Wiki auf mikrocontroller.net nicht existiert, macht es imho > wenig Sinn, das entstehende Schaltbild hier immer wieder neu an zu > hängen. Ich habe unter http://df2au.nordlink.org/fuerma/ eine Ablage > eingerichtet. Der Lesezugriff ist für alle frei. Zur Datenablage habe ich auf Github eine "Organization" angelegt. Wenn Du bei Github angemeldest bist, kann ich Dich dort mit aufnehmen: https://github.com/hackocopter Zur Dokumentation gibt es konkret ein Repository: https://github.com/hackocopter/Documentation > Falls jemand schon Schaltungsteile aufgenommen hat, kann er sie mir per > Mail schicken. Auch Scans von handschriftlichen Zeichnungen sind > willkommen. Ich baue das dann ein. Hattest Du meine Liste mit den Pinzuordnungen gesehen? http://www.mikrocontroller.net/attachment/197062/pinout.txt Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter"
:
Bearbeitet durch User
Rudolph schrieb: > Hier mal ein paar Bilder vom Innenleben meines rosa Quadro-Taumlers. > > Das ist ja noch weniger komplex, Clon des Clons? Vielen Dank! Die Platine ist die gleiche wie vom "Frankfurt"-copper weiter oben. MCU und IMU sind identisch. Allerdings kann man Unterschiede in der Schaltung erkennen. Es werden andere PWMs für die Motoren verwendet, und die INT-Ausgang vom MPU6050 ist nicht verbunden. Merkwürdig ist auch, dass es zusätzliche Leitungen zum Tranceiver gibt. Evtl. ist das gar kein BK2423? Da auch der Hersteller ein anderer ist, ist anzunehmen dass es sich um andere Firmware handelt. Das erklärt vielleicht auch die schlechtere Performance. Immerhin ist der SWD-Port auch herausgeführt, so dass man den MCU neu flashen kann.
Github ist bestimmt was schönes. Ich bevorzuge die Schildkröte und CVS. Da liegt die Info dann auf meinem eigenen Server. Mag sein, ich bin altmodisch. Die Liste habe ich ausgedruckt. Die Info auf Github werde ich auch aufsaugen und umsetzen.
Du kannst Dir auch Git auf einem eigenen Server aufsetzen :) CVS ist inzwischen schon etwas antik. Ich werde Deine Daten dann ins Repository Spiegeln, wenn Du nichts dagegen hast.
Georg G. schrieb: > Github ist bestimmt was schönes. Ich bevorzuge die Schildkröte und CVS. Dann nutze doch die Schildkröte für Git: https://code.google.com/p/tortoisegit/ ;) > Da liegt die Info dann auf meinem eigenen Server. Mag sein, ich bin > altmodisch. Mit git liegt sie überall, das ist ja das schöne daran. Jeder hat die komplette History, auch Offline, und falls jemand sich entscheidet sein Repo zu schließen ist nichts verloren.
Philipp E. schrieb: Hallo Philip, > Konkret geht es um den Crazyflie [1]. Ist vermutlich einigen hier schon > ein Begriff. Da der Copter auch auf einer ARM-CPU aufbaut, scheint mir > die Adaption der Crazyflie Firmware ein sehr vielversprechender > Ausgangspunkt für die Entwicklung einer eigenen Firmware. Den Crazyflie habe ich mir auch schon angeschaut (es liegt einer hier!). Leider ist die Qualität der Hardware und die Flugtauglichkeit nicht mit dem JXD385 zu vergleichen. Dafür hat er natürlich mehr Rechenleistung. Die Software sollte eine gute Vorlage für viele Features liefern. Eine Schwierigkeit ist allerdings, dass sie deutlich zu groß ist. Sehr nützlich ist auch das Crazyradio, was man für einen Telemetrie-Link verwenden könnte. Im Multiwii-Forum hat mich jemand auf Bradwii verwiesen. Das ist eine noch relativ unverbastelte Firmware, die gut strukturiert ist: http://www.rcgroups.com/forums/showthread.php?t=1922403 Es gibt von Bradwii auch schon einen ersten Cortex-M3 Port: https://github.com/trollcop/bradwii Dieser lies sich mit Keil relativ einfach bereits auf 17kb Codegröße compilieren. Mit ein paar weiteren Optimierungen sollte sich die Software auf den MINI54ZAN quetschen lassen. Der MPU6050 wird bereits unterstützt.
Georg G. schrieb: > Ehe das Wiki auf mikrocontroller.net nicht existiert, macht es imho > wenig Sinn, das entstehende Schaltbild hier immer wieder neu an zu > hängen. Der Artikel ist ja bald da. Aber darauf muss niemand warten. http://www.mikrocontroller.net/articles/Spezial:Hochladen Datei hochladen und Link hier posten, ich füge das Bild dann auch ins Wiki ein. Man kann hier auch alte Versionen mit neuen überschreiben. Ich schlage vor, den "Zielnamen" immer mit dem Präfix HOC_ zu versehen, also z.B. "HOC_Schaltplan". Heute war bei mir die Hölle los, hatte nicht mal Zeit, einen Kaffee zu trinken. Aber bis Freitag/Samstag bin ich so weit.
:
Bearbeitet durch User
Tim schrieb: > Evtl. ist das gar kein BK2423? Den garstig verklebten Uhrenquarz finde ich ein wenig seltsam. Und bald noch seltsamer, dass das der einzige Quarz ist. > Immerhin ist der SWD-Port auch herausgeführt, so dass man den MCU neu > flashen kann. Wo ist da irgenwas herausgeführt? :-) Die ganzen Pads in den Ecken?
Rudolph schrieb: > Wo ist da irgenwas herausgeführt? :-) > Die ganzen Pads in den Ecken? Die runden Pads auf der Rückseite. Ich würde mal raten: D=Data C=Clock G=Ground R=Reset Tx=Uart RX
:
Bearbeitet durch User
Rudolph schrieb: > Hier mal ein paar Bilder vom Innenleben meines rosa Quadro-Taumlers. > > Das ist ja noch weniger komplex, Clon des Clons? Hier übrigens ein Review des "Mould King X6" http://www.rcgroups.com/forums/showthread.php?t=2023579 Er scheint weniger wendig als der JXD385 zu sein und nutzt ein inkompatibles RC-Protokoll.
Martin Schröer schrieb: > Thorsten, zur 808 tendiere ich nur deswegen, weil … der Copter > fliegt damit noch anständig [hoch]. > > Die Y3000 müsste ich mir mal als Alternative ansehen. Heute ist meine Y3000 angekommen, hatte aber noch keine Zeit zum testen. Aber dieses Video ist recht vielsagend. Da werden beide verglichen: http://www.youtube.com/watch?v=CgtTg62GDfs Zur Flughöge: Die Y3000 wiegt mit Akku und Gehäuse 17,6 Gramm. Auseinander gebaut habe ich sie noch nicht.
Tim schrieb: > Hier übrigens ein Review des "Mould King X6" Ah nett, da war auch die Bedienungsanleitung auf Englisch zu finden. Blöderweise bekomme ich das Teil damit auch nicht zum Fliegen, trotz jetzt eingestelltem "Easy" Modus und dem Wissen mit was man wofür trimmt. Meiner zieht immer nach Links weg, wenn ich das Trimming maximal auf Rechts drehe und den Richtungshebel voll nach Rechts drücke, dann fliegt der immer noch nicht einfach nur nach Oben. Wenn man den auf den Boden legt und langsam Gas gibt sieht man die Rechte Seite leichter abheben. Mit dem Müll kann ich bestenfalls unsere Katze erschrecken.
Noobi schrieb: > geht der mit funk ? Wie meinst Du das? Willst Du ein Videosignal (CVBS o.ä.) funken? Oder nur per Funk den Ausöser drücken? Für Letzteres müsste man das Kamera-Gehäuse öffnen, z.B. über "Pin 9" ^^ die Taste überbrücken und eine Auslöse-Funktion in die Firmware programmieren.
Den Aufwand per Funk den Auslöser zu drücken kann man sich wohl sparen. Auf eine xGB-Karte gehen sicher längere Filme drauf als der Quad-Akku Laufzeit hat.
Oliver Stellebaum schrieb: > Den Aufwand per Funk den Auslöser zu drücken kann man sich wohl sparen. Bei Kameras, wo die Key-Frames die gleiche Qualität haben, wie die Fotos oder falls man keine Fotos will, hast Du Recht. Ansonsten braucht die Kamera einen Intervall-Modus, wenn man per Funk den Auslöser nicht drücken kann.
Martin Schröer schrieb: > Würdest Du die zum Laufen bringen, wäre das natürlich ideal Ich bestelle Montag über oekel diese Stecker: http://de.mouser.com/ProductDetail/?qs=sGAEpiMZZMvffgRu4KC1R%2fGUjS92B21yank88RdbjuM%3d Die müssten m.E. passen. Dann sehen wir weiter ...
Timmo H. schrieb im Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter" > Also selbst die kleinen GPS Module die ich verwende (Maestro A2235-H) > sind mit 4g zwar noch relativ leicht Ein Größenvergleich. Meiner wiegt 5,8 Gramm. [[Datei:HOC_GPS_Groessenvergleich.jpg]] http://www.mikrocontroller.net/articles/Datei:HOC_GPS_Groessenvergleich.jpg Manuel Steiner schrieb im Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter" > Wir müssen mal schauen > wo wir die auflöten. Die sind nämlich wirklich ziemlich klein und QFN > Pads, also da muss irgend ein PCB oder so her, sonst glaub ich bekommt > man die nicht ordentlich wo aufgelötet. Ist halt teuer, aber ich war zu faul: [[Datei:HOC_IR-Entfernungsmesser-Testplatine.jpg]] http://www.mikrocontroller.net/articles/Datei:HOC_IR-Entfernungsmesser-Testplatine.jpg Mal sehen, ob ich am Wochenende zum testen komme. BTW:
1 | [[Titel]] - Link zu Artikel |
Das scheint nicht für den Namensraum "Datei" zu funktionieren. Trotzdem: Alles was ins WIKI soll, bitte ruhig schon hochladen! Spezial:Hochladen
:
Bearbeitet durch User
Meiner kam gestern an. Konnte ein paar mal fliegen. Wirklich cooles Teil. Heute ist er mir auf die Propeller gestürzt. Dabei ist ein Motor kaputt gegangen =(. Sowie es manchen weiter oben auch schon passiert ist. Deshalb will ich mir einen zweiten kaufen. Ist dies hier der selber wie im Starterpost? hubsi schrieb: > Hm, es gibt in der auch einen JD-185, hier etwa für 30 aus .uk > http://www.ebay.co.uk/itm/6-Axis-2-4Ghz-4CH-RC-Remote-Radio-Control-Helicopter-GYRO-UFO-Flying-JD-185-Mini-/231065258307 Grüsse Edit: Ich konnte es reparieren. Da ich eh nichts mehr zu verlieren hatte, habe ich den Motor einfach in den Schraubstock gespannt und anschliessen mit einer Zange an der Welle nach oben gezogen. Da kam er wieder ein paar mm nach oben und siehe da er läuft wieder.
:
Bearbeitet durch User
Ich hab Ersatzmotoren hier bestellt: <http://www.tmart.com/search.html?q=385>;, allerdings noch nicht ausprobiert.
Die Motoren konnte ich flicken. Nun habe ich jedoch das Problem das plötzlich gar nix mehr geht. Nichteinmal mehr die Leds leuchten. Also auseinander gebaut und die Spannung gemessen. Ich habe 0.6V an VCC bei den 4 Löchern gemessen. Kann es sein das der Spannungsregler hin ist? Weiss per Zufall jemand von welchem Typ der ist?
Das Datenblatt ist hier verlinkt. Glaube nicht, dass der regler hin ist. Die Elektronik verbraucht ja kaum Strom vermute ich... Wird jedenfalls schwer den Regler oder einen Ersatz zu finden, ist so ziemlich fast der einzige in sot32.
Marius S. schrieb: > Das Datenblatt ist hier verlinkt. Glaube nicht, dass der regler hin ist. > Die Elektronik verbraucht ja kaum Strom vermute ich... Wird jedenfalls > schwer den Regler oder einen Ersatz zu finden, ist so ziemlich fast der > einzige in sot32. Der "Frankfurter" nimmt entweder 35 mA (keine Verbindung mit der Fernbedienung) oder 40 mA (Verbindung mit der Fernbedienung)auf. Beide Werte bei stehenden Motoren.
Meiner nimmt 0mA auf wenn ich ihn anhänge. Ein Kurzschluss ist auch nicht vorhanden. Ich denke ich bestelle einfach mal einen MCP1700. Der scheint das gleiche Pinout zu haben und kostet fast nichts. Er ging kaputt als ich den Akku angschlossen habe. Die Leds haben ganz kurz aufgeleuchtet und dann war er Tot. Von daher denke ich schon das der Regler hin sein könnte.
Hat jemand gute, scharfe Fotos der Fernbedienung (Leiterplatte vorn/hinten)?
Georg G. schrieb: > gute, scharfe Fotos der Fernbedienung STOP! Mache ich, nicht dass das unnötig doppelt gemacht wird.
Torsten C. schrieb: > STOP! Mache ich, nicht dass das unnötig doppelt gemacht wird. Danke für die Warnung :) (legt Schraubenzieher wieder aus der Hand)
Georg G. schrieb: > Fotos der Fernbedienung Sendemodul: http://www.mikrocontroller.net/articles/Datei:HOC_Fernbedienung_Sendemodul.jpeg Gesamte Platine: http://www.mikrocontroller.net/articles/Datei:HOC_Fernbedienung_Platine_total.jpeg Ausschnitt mit µC: http://www.mikrocontroller.net/articles/Datei:HOC_Fernbedienung_Platine_Ausschnitt.jpeg
Der Chip im Tranceiver ist dieser hier http://www.szmeilai.com/admin/pdf/RFX2402.pdf oder ein Clone davon. Da hat man zumindest in der Fernbedienung nicht gespart. Es hätte ja auch ein einfacher BK2423 mit PIF sein können. Hier auf der Herstellerseite: http://www.rfaxis.com/our_products/Wi-Fi-rfx2402e
:
Bearbeitet durch User
Georg G. schrieb: > Leiterplatte vorn/hinten Ich sollte erstmal zum Mittag kommen. So, nun kann ich weiter machen. Was ist nun vorn und was ist nun hinten? Egal, hier die andere Seite: http://www.mikrocontroller.net/articles/Datei:HOC_Fernbedienung_Platine_B-Seite.jpeg Ein LCD-Modul C0802-04 passt gut in das Gehäuse der Fernbedienung: http://www.mikrocontroller.net/articles/Datei:HOC_Fernbedienung_mit_C0802-04.jpeg Das Die 95ct passen gut zum Preis des Hack-O-Copters: http://www.pollin.de/shop/dt/NzczOTc4OTk-/
Torsten C. schrieb: > Das Die 95ct passen gut zum Preis des Hack-O-Copters: Da fehlt nur noch ein kleiner AVR, der das serielle Protokoll der Fernbedienung in die 4 Bit des Displays übersetzt. Und das Display will 5V haben, am Stecker liegen aber nur 3.3V. Da finden wir bestimmt noch was, was besser passt.
Ist über P2 nicht ein Anschluss für ein SPI-Display herausgefuhrt? Man müsste mal mit einem LA schauen, ob dort auch etwas ausgegeben wird.
Georg G. schrieb: > Da finden wir bestimmt noch was, was besser passt. Aber bitte nicht für 5 Euro oder mehr. Tim schrieb: > BK3423 - 2.4 Ghz tranceiver, anscheinend voll kompatibel zum nrf24L01 Ist das "geraten" oder wie wahrscheinlich ist es, dass das stimmt? Ich brauche eh ein neues Protokoll um Bilder zurückfunken und DGPS-Daten zum HOC senden zu können. Ich weiss nicht, ob es sich lohnt, auch noch die Fernbedienung zu hacken. Tim schrieb: > Man müsste mal mit einem LA schauen, ob dort auch etwas ausgegeben wird. Ich persönlich lege darauf keinen Wert, da ich aus o.g. Gründen eh 'ne neue Sender-Firmware brauche. Wenn das mit den Fotos irgendwann klappt, wäre natürlich ein buntes TFT schöner, dann von mir aus auch über 5€. So, wer macht denn nun einen Stromlaufplan vom Sender? Hier noch das letzte Bild, ein zweiter Ausschnitt: http://www.mikrocontroller.net/articles/Datei:HOC_Fernbedienung_Platine_Ausschnitt2.jpeg
:
Bearbeitet durch User
Torsten C. schrieb: > So, wer macht denn nun einen Stromlaufplan vom Sender? Gaaaaaaanz ruhig... ich bin dran. Leider bisher nur an Hand der Fotos. Aber es gibt schon einen Verdächtigen für die CPU. Und das wäre die halbe Miete. Frage: Ist SDA vom unbestückten LCD Anschluss mit dem Prozessor Pin 9 verbunden und SCL mit Pin 10? Wenn dann noch Pin 4, 16 und 17 irgendwie gut kontaktierbar wären, wäre es gegessen.
Torsten C. schrieb: > ein buntes TFT ... von mir aus auch über 5€. http://www.aliexpress.com/item//964508863.html Ist sogar unter 5€, nur mal als Beispiel.
Georg G. schrieb: > Und das Display will > 5V haben, am Stecker liegen aber nur 3.3V. Da finden wir bestimmt noch > was, was besser passt. Es tut auch wunderbar mit 3.3V und einer kleinen Ladungspumpe für die 5V Kontrast. Den notwendigen Takt kann man ja beim Konvertierungs-µC mit abziehen.
Torsten C. schrieb: > Tim schrieb: >> BK3423 - 2.4 Ghz tranceiver, anscheinend voll kompatibel zum nrf24L01 > > Ist das "geraten" oder wie wahrscheinlich ist es, dass das stimmt? Man kann die Signale der Fernbedienung mit einem nrf24L01 empfangen. Code dafür habe ich weiter oben gepostet*. Die Chips sind Pinout- und Registerkompatibel. Der BK2423 hat allerdings noch eine weitere Registerbank, die mit "magischen" Konstanten initialisiert werden muss. Ziemlich merkwürdig. * hier: Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter"
:
Bearbeitet durch User
Tim schrieb: > Man kann die Signale der Fernbedienung mit einem nrf24L01 empfangen. Danke, sorry falls überlesen. Dann werd' ich das gleich mal ausprobieren wenn die Dongles da sind, ebay 300975449625.
Torsten C. schrieb: > Dann werd' ich das gleich mal ausprobieren wenn die Dongles da sind, > ebay 300975449625. Der hat aber keinen LNA - wahrscheinlich also eine geringere Reichweite als die normale Fernbedienung. Aber egal, werde auch mal eins bestellen.
:
Bearbeitet durch User
Tim schrieb: > eine geringere Reichweite Mit Sicherheit, 0dBm = 1mW. Die Angabe "10-20M or so" habe ich so auch noch nie in einem Datenblatt gelesen. Egal, mir geht es darum, wenn der Hack-O-Copter neben dem Notebook auf dem Tisch fliegt, dass ich dann Variableninhalte auf dem Bildschirm verfolgen kann und Regel-Parameter verändern kann. Auch die Bildübertragung würde ich erstmal mit dem PC machen. Ich habe so'ne USB-Trainings-Fernbedienung für Flugsimulatoren. Dann nehme ich die erstmal.
:
Bearbeitet durch User
Torsten C. schrieb: > Dann werd' ich das gleich mal ausprobieren wenn die Dongles da sind, > ebay 300975449625. Ich frage mich, ob der Stick mit Bootloader kommt, oder ob man noch einen programmer braucht?
Tim schrieb: > ob der Stick mit Bootloader kommt Torsten C. schrieb im Beitrag "Re: China SUPER Bauteile-Schnäppchen Thread" : > Mit Etwas Glück haben die die "usb-to-uart.hex firmware" schon fertig > drauf. Ich werd's sehen, wenn der da ist. PS: Mit PA + LNA habe ich keine gefunden. Aber das kann ja noch kommen.
:
Bearbeitet durch User
Georg G. schrieb: > Gaaaaaaanz ruhig... ich bin dran. Leider bisher nur an Hand der Fotos. > Aber es gibt schon einen Verdächtigen für die CPU. Und das wäre die > halbe Miete. > > Frage: Ist SDA vom unbestückten LCD Anschluss mit dem Prozessor Pin 9 > verbunden und SCL mit Pin 10? > > Wenn dann noch Pin 4, 16 und 17 irgendwie gut kontaktierbar wären, wäre > es gegessen. Welchen Controller vermutest du? Sieht aus wie 8051 Derivat.
Ursus schrieb: > Welchen Controller vermutest du? N79E825A (oder ein andere aus der Familie mit weniger Flash)
Georg G. schrieb: > N79E825A Hmmm. Ich habe mal mit meiner dienstlichen E-Mail-Adresse den "Sales Support Inquiry" angeschrieben. Ich hab' noch einen neuen Thread aufgemacht. Den von Hubsy kannte ich nicht und habe ihn erst hinterher gefunden, siehe Beitrag "Nuvoton Datenblatt - wir finden's nicht."
:
Bearbeitet durch User
Tim schrieb: > Ich frage mich, ob der Stick mit Bootloader kommt, oder ob man noch > einen programmer braucht? Ich habe den folgenden Link schon im China Thread zusammen mit dem USB-nrf-Dongle gepostet. Da es hier auch einige Relevanz haben könnte anbei: http://wiki.bitcraze.se/projects:crazyradio:index Die Jungs haben sehr gut dokumentiert, wie die den Chip verwenden. Inklusive Open Source USB-Flash Tool, etc. Viele Grüße
Ach so, ganz konkret ist hier die Firmware von den Bitcraze Entwicklern: https://bitbucket.org/bitcraze/crazyradio-firmware/src Dort gibt es sowohl Code um das Dongle via SPI zu Flaschen als auch USB-Flash Tool. Ach ja, die benutzen den Nordic Bootloader. Ich habe mal ins Datenblatt geschaut, dort steht, dass der Bootloader von Haus aus auf dem Chip ist.
:
Bearbeitet durch User
Ich hab mir nochmal den jd185 bestellt gibt es da einen unterschied?
Turbonator schrieb: > Ich hab mir nochmal den jd185 bestellt Wo denn? Turbonator schrieb: > gibt es da einen unterschied? Nein, das_ist der Hack-O-Copter.
Danke für die info Hier hab ich es bestellt: http://www.ebay.de/itm/JD-185-MINI-Quadcopter-6-axis-2-4ghz-4-Kanal-Gyro-UFO-MINI-RC-Helikopter-/171097513221?ssPageName=ADME:X:AAQ:DE:1123
Turbonator schrieb: > Hier hab ich es bestellt 2,4GHz. Gut. Frage: Warum steht hier eigentlich "Infraread"? http://www.tmart.com/JXD-385-4-Channel-Infrared-Remote-Control-Helicopter-with-Gyro-Black-Red_p216504.html Das kann doch nicht sein, oder?
Nochmal kurz zum Nordic USB Dongle. Habe das System hinter dem Bootloader soweit durchdrungen. Alles sehr einfach und übersichtlich umgesetzt. Interessanter Text dazu: "Hi, I just want to chime in that the chips do ship with the USB bootloader, which I was able to use to reprogram it over USB. The USB bootloader is stored at the upper 2KB of the flash (starting at 0x7800), so it shouldn't be overwritten by normal program. However, the code execution starts at the lowest address (0x0000) and therefore normal programming will overwrite the 3-byte long absolute jump instruction, and thus would cause the bootloader to stop being functional after program and reset." http://forum.diyembedded.com/viewtopic.php?f=5&t=647
Ja deswegen hab ich ja gefragt ir scheint wohl die über-billig Variante zu sein ..... Ich hab glaube ich ein Problem ich hab 2 bestellt und muss dank der bewertungen festellen das von dem Händler aus Asien geliefert wird , hilfe der zoll.
Turbonator schrieb: > Ich hab glaube ich ein Problem Warte es ab. Oft hat man Glück. Ansonsten: Versankostenfrei immer im Abstand von mehreren Tagen bestellen! Sonst gibt es keine "gesparten" Versandkosten, die man gegen die Einfuhrumsatzsteuer aufrechnen kann. BTW: Ich habe gerade diverse Chinamänner angeschrieben, was die für 30 Stück ohne Fernbedienung und Zubehör haben wollen. Mal sehen, was da kommt. PS: Turbonator schrieb: > IR scheint wohl die über-billig Variante zu sein Das sieht mir eher nach einem Dreckfuhler aus.
:
Bearbeitet durch User
Torsten C. schrieb: > Ich habe gerade diverse Chinamänner angeschrieben, was die für 30 > Stück ohne Fernbedienung und Zubehör haben wollen In dem Fall nehme ich 2 ;-)
Torsten C. schrieb: > Stück ohne Fernbedienung und Zubehör haben wollen. Mal sehen, was da Eine Tüte Propellerblätter darf ruhig dabei sein :-)
Oliver Stellebaum schrieb: > Torsten C. schrieb: >> Stück ohne Fernbedienung und Zubehör haben wollen. Mal sehen, was da > > Eine Tüte Propellerblätter darf ruhig dabei sein :-) http://www.tmart.com/8Pcs-JXD-385-002-Double-Plastic-Blades-Set-for-JXD-RC-Helicopter_p192093.html Die vom Hubsan passen auch und sind angeblich etwas besser: http://www.tmart.com/Hubsan-X4-H107C-RC-Quadcopter-Spare-Parts-H107-A36-Tail-Rotor-Black-Green_p226117.html
Der österreichische Zoll dürfte wieder mal ziemlich lahm sein :( Oder das Paket ging irgendwo verloren... Ich hoffe ja es kommt noch, habe aber zur Sicherheit bessky_cn mal auf Ebay kontaktiert.
Leider kann ich keine Anleitung für den JD-385 im Netz finden und die Fernbedienung des Hubsan sieht anders aus. Kann bitte jemand die Funktion der Taster auf der Fernbedienung posten? Trimmung für die entsprechenden Funktionen der Joysticks? Wie ist die Standard Belegung der Knüppel? Rechts Nick und Roll, links Gier und Power?
Turbonator schrieb: > IR scheint wohl die über-billig Variante zu sein. Tatsächlich, Tmart hat geantwortet:
1 | Thanks for your email, it is our honor to help you. |
2 | It is Infrared. Sorry.we did not found the items which meets your require. |
Unglaublich ... Wegen der 30 Copter ohne Fernbedienung verhandele ich noch wegen der Versandkosten, aber zumindest scheint Interesse zu bestehen, sowohl hier im Forum, als auch bei den Chinesen.
Na wenn wir dann mit Steuer&Zoll wieder bei 25€ sind nützt das aber nichts. Und es sollte exakt das Modell sein welches wir ja alle schon im Einsatz haben.
:
Bearbeitet durch User
Oliver Stellebaum schrieb: > Na wenn wir dann mit Steuer&Zoll wieder bei 25€ sind nützt das aber > nichts. Stimmt. Wenn ich die für 3,80€ per Hermes an Euch verschicke, sollte der "nackte" Copter nicht mehr als 10,50€ incl. Versand kosten. Das wären dann ca. 315€ plus Zoll und Einfuhrumsatzsteuer für 30 Stück. > Und es sollte exakt das Modell sein welches wir ja alle schon im Einsatz > haben. Hinterher wird die Firmware eh gelöscht, ist also egal. Die Hardware sollte identisch sein. Ich könnte dem Verkäufer ja ein Foto der Platine schicken und fragen, ob seine auch "Rev 02 vom 27.06.2013" sind. Ich könnte auch 30 Copter und eine passende Fernbedienung zum testen kaufen, falls die Firmware bzw. das Protokoll unterschiedlich ist, weiss man wenigstens, dass er vorher noch flog. Ich wollte diesen Beitrag gerade "absenden", da kam das bisher preiswerteste Angebot für 12,20€ zzgl. Versand. Das sind deutlich mehr als 10,50€. Außerdem gilt der Preis für 120 Stück und ich müsste knapp 1500€ vorstrecken. Ich glaube, in die Idee habe ich mich verrant. Das bringt wohl nix. :-( PS: Georg G. schrieb im Beitrag "Re: Nuvoton Datenblatt - wir finden's nicht." : > Damit beschlossen: Es ist der N79E825. Aber eine OTP-Variante, oder? Meinst Du, dass man den auch neu flashen kann?
:
Bearbeitet durch User
Der Ansatz ist aber gut - Interesse hätte ich auch. Lass' mal hören, wie Du Dich schlussendlich entschieden hast, bzw. ob doch noch bessere Angebote (bei angemesseneren Mengen) eingetrudelt sind.
Torsten C. schrieb: > Georg G. schrieb im Beitrag "Re: Nuvoton Datenblatt - wir finden's > nicht." > : >> Damit beschlossen: Es ist der N79E825. > > Aber eine OTP-Variante, oder? Meinst Du, dass man den auch neu flashen > kann? Ich vermute die beste Lösung für die Fernbedienung ist dann ein neues Innenleben. Oder eine Pinkompatible MCU?
Torsten C. schrieb: > Aber eine OTP-Variante, oder? Meinst Du, dass man den auch neu flashen > kann? Laut Datenblatt ist es ganz normaler Flash Speicher, gegen Auslesen geschützt wie üblich. Programmieren geht über den eingebauten Bootlader. Werkzeuge dazu gibt es auf der Nuvoton Webseite kostenlos. Fertige Hardware kostet etwa € 35.-, Schaltbilder sind in den Nuvoton Unterlagen. Es ist nichts besonderes da drin verbaut.
:
Bearbeitet durch User
Angehängte Dateien:
-
N79E825.jpg
6,2 KB
Tim schrieb: > ein neues Innenleben Das Datenblatt sagt, dass bei einem Reset die meißten Pins hochohmig werden. Also: Pin 4 an Masse brücken und eine Platine mit neuem µC an den richtigen Stellen mit Fädeldraht verbinden. Ein richtiger N79E825 sieht anders aus. Das muss ein OTP sein. Dann geht natürlich der Streit los: AVR? MSP430? ARM?
:
Bearbeitet durch User
Torsten C. schrieb: > Dann geht natürlich der Streit los: AVR? MSP430? ARM? Natürlich ARM :) LPC812 im SOIC20 Gehäuse - hat den gleichen Footprint. Am einfachsten wäre es aber, erst einmal ein nRF24 an einen AVR (Arduiono) zu hängen. Dafür gibt es den Source für das V202 Protokoll schon fertig.
Tim schrieb: > Torsten C. schrieb: >> Dann geht natürlich der Streit los: AVR? MSP430? ARM? > > Natürlich ARM :) LPC812 im SOIC20 Gehäuse - hat den gleichen Footprint. Wenn ich das richtig sehe, dann wird ein ADC benötigt und der LPC812 hat keinen.
Davis schrieb: > Wenn ich das richtig sehe, dann wird ein ADC benötigt und der LPC812 hat > keinen. Guter Punkt. Leider gibt es gar nicht so viele ARMs in SOIC20. Dann schon eher TSSOP20. Ein AVR würde es aber auch tun. ATtiny861 z.B.
Ich habe das Repository mal mit einigen Informationen zur Fernbedienung gefüllt: https://github.com/hackocopter/Documentation/tree/master/RemoteControl
http://www.banggood.com/Night-Vision-HD-Model-Monitoring-DIY-Wireless-Micro-Camera-Set-p-909052.html ... 3,4g HD Kamera
Hat den schon jemand diesen hier gekauft? http://www.ebay.co.uk/itm/6-Axis-2-4Ghz-4CH-RC-Remote-Radio-Control-Helicopter-GYRO-UFO-Flying-JD-185-Mini-/231065258307 Ich bin ein bisschen stutzig weil erst 3 Stück verkauft wurden.
Ich habe große Teile des Schaltbildes aufgenommen. Es passt alles exakt zu dem N79E825. GND, VCC an den richtigen Pins, die Potis der Knüppel auf den 4 AD Eingängen. Es wäre ein riesiger Zufall, wenn ein anderer Prozessor das gleiche Pinout hätte. Da die Pads zum Programmieren auf dem Board sind, kann ja mal jemand, der Lust und Zeit hat, versuchen, die ID des Prozessors auszulesen. Mein Copter ist leider noch nicht hier. Sonst würde ich es selbst machen.
Georg G. schrieb: > Ich habe große Teile des Schaltbildes aufgenommen. Es passt alles exakt > zu dem N79E825. GND, VCC an den richtigen Pins, die Potis der Knüppel > auf den 4 AD Eingängen. Es wäre ein riesiger Zufall, wenn ein anderer > Prozessor das gleiche Pinout hätte. Post dein Ergebnis, dann kann man sehen was geht und was nicht geht.
WICHTIGE FRAGE: Hat einer von Euch bei Aliexpress gekauft? Ich brauche einen Snapshot:
1 | www.aliexpress.com/snapshot/########.html |
Den Link bekommt man, wenn man auf "Manage Orders" / "My orders" auf den Artikel klickt. Ich brauche den Snapshot, um einen Link mit dem alten (niedrigen) Preis zu haben. Dominic A. schrieb: > weil erst 3 Stück verkauft wurden 28,83€ wären mir auch zu teuer. Oder habe ich mich verrechnet? Georg G. schrieb: > Es wäre ein riesiger Zufall, wenn ein anderer > Prozessor das gleiche Pinout hätte. Das wird schon der Prozessor sein, da widerspricht ja keiner. Aber vermutlich ein OTP-Typ, also ohne Flash.
:
Bearbeitet durch User
> 28,83€ wären mir auch zu teuer. Oder habe ich mich verrechnet?
Ja. Die Versandkosten fehlen.
Torsten C. schrieb: > Aber vermutlich ein > OTP-Typ, also ohne Flash. Die Chinesen sehen sehr aufs Geld. Warum sollte man einen OTP entwickeln, wenn man Flash hat? Wäre der in der Produktion billiger? In welcher Technologie? Das macht schon seit Jahren niemand mehr. Man nimmt den normalen Flash Typ und setzt die Sicherheitsbits.
Das ist alles Spekulation und hilft nicht wirklich weiter. Irgendjemand muss einen Programmer anschließen und es ausprobieren. Am besten noch mit einem "richtigen" N79E825 daneben, um zu testen, ob der Programmer wenigstens damit funktioniert. Georg G. schrieb: > Man nimmt den normalen Flash Typ und setzt die Sicherheitsbits. Ich hab' jetzt nicht nachgeschaut. Kann man die so "durchbrennen", dass sie nicht löschbar sind? Dann hast Du Deine Antwort.
:
Bearbeitet durch User
Torsten C. schrieb: > Ich hab' jetzt nicht nachgeschaut. Kann man die so "durchbrennen", dass > sie nicht löschbar sind? Dann hast Du Deine Antwort. Das wird wohl das gleiche wie mit den Lockbits im Mini54ZAN sein.
Torsten C. schrieb: > Kann man die so "durchbrennen", dass > sie nicht löschbar sind? Üblicherweise sind sie löschbar - aber nur zusammen mit dem Rest des Speichers.
> preiswerteste Angebot für 12,20€ zzgl. Versand. Das sind deutlich mehr > als 10,50€. Außerdem gilt der Preis für 120 Stück und ich müsste knapp > 1500€ vorstrecken. > > Ich glaube, in die Idee habe ich mich verrant. Das bringt wohl nix. :-( Also ich würde 10 bis 15 stk nehmen wenn das mit dem (usb) funkmodul klappt ,wenn nicht 5stk als ersatzteilager und mit den einzelteilen kann man ja was basteln flugzeug ect.(motoren porpeller)
Sag dem Chinamann deutlich das Du 100 Stück (ohne FB) für 900€ inkl. Versand nimmst. Sonst kann er es vergessen. Deute an das Du bei einwandfreier Ware evtl. 1000 Stück nimmst. Das ist schlimmer als auf einem Bazar, nicht so schnell aufgeben.
Angehängte Dateien:
-
packet-count.png
21 KB
Ich habe noch einmal etwas mit der Fernbedieung herumgespielt. Das Format der Datenpakete ist soweit verstanden und entspricht dem vom V202, wie oben beschrieben. Das Frequency-Hopping Schema scheint aber stark abzuweichen. Beim V202 werden nur 16 Kanäle benutzt. Beim Hack-O-Copter (JXD185/385) scheinen es fast alle zu sein. Die Verteilung hat dabei einen Schwerpunnkt auf den niedrigen Kanälen (siehe Bild). Wahrscheinlich könnte man einfach auf allen Kanälen nach Zufallsverteilung Daten senden und so den Copter kontrollieren. Allerdings werden dann viele Daten verloren gehen. Besser wäre es, das Hopping-Schema zu kennen.
:
Bearbeitet durch User
Oliver Stellebaum schrieb: > Sag dem Chinamann deutlich das Du 100 Stück (ohne FB) für 900€ inkl. Genau. Bleib dran (wenn du Lust / Zeit hast). Ich denke das Potential, die Dinger hier an den Man zu bringen ist sehr sehr groß. Und die Freude, die du den Leuten damit machst auch. Wenn du Sorgen hast, auf den Coptern sitzen zu bleiben, finden sich bestimmt hier Leute, die im Notfall bei dem Preis auch mehr abnehmen. Also ich hätte gerne so 2 bis 3 Stück. Wenn am Ende die Nachfrage nicht groß genug ist würde ich dir aber auch 10 abnehmen. So ne kleine Flotte hat was. Auch als Geschenk für Freude und Verwandte ne tolle Sache, wenn hier irgendwann mal die alternative Firmware steht. Auch ein tolles Dev. Board. Ach so, viele Möglichkeiten... Oliver Stellebaum schrieb: > Deute an das Du bei einwandfreier Ware evtl. 1000 Stück nimmst. Das deckt sich mit meiner Erfahrung. Fasele evtl. etwas von long term buisness relationship, etc. Ist ja vielleicht am Ende gar nicht mal gelogen, wenn der Preis stimmt und hier irgendwann ne Firmware steht finden sich hier sicher noch viel viel mehr Interessenten. Wenn ich mir überlege wie der erfolgreich der Crazyflie ist (und der kostet 150 $ ohne Fernbedienung). Weiterhin ist in meinen Augen jegliches Zubehör / Ersatzteile unnötig. Bei dem Preis nehme ich lieber nen zweiten Copter, da habe ich Ersatzteile für jeden erdenklichen Fall. Den LiPo-Lader werde ich persönlich ohnehin nicht verwenden, ich benutze einen auf MCP73831T Basis [1]. Einzig der LiPo selber wäre interessant, aber da scheint es ja auch eine menge alternativer Quellen für zu geben. Also, da geht noch was. Würde mich freuen wenn du das durchziehst ;-) [1] http://www.ebay.com/itm/LiPo-Charger-Basic-Micro-USB-3-7V-Battery-Charger-module-/321149954122?
:
Bearbeitet durch User
Philipp E. schrieb: > [1] > http://www.ebay.com/itm/LiPo-Charger-Basic-Micro-USB-3-7V-Battery-Charger-module-/321149954122? 9.90$? WTF? Mit meiner Variante liegen ich bei einem Bruchteil des Preises: In ca. zwei Wochen sind alle Teile für den Protypen da. https://github.com/hackocopter/LiPoCharger
Philipp E. schrieb: > finden sich hier sicher noch viel viel mehr Interessenten. Wenn ich mir > überlege wie der erfolgreich der Crazyflie ist (und der kostet 150 $ > ohne Fernbedienung). Ja, und er hat außer der schnelleren CPU definitiv keine bessere Hardware. Das Preis/Leistungsverhältnis des JD185 ist wirklich unschlagbar.
Tim schrieb: > 9.90$? WTF? Mit meiner Variante liegen ich bei einem Bruchteil des > Preises: Na klar. Das geht natürlich noch viel billiger. Habe das Ding mir schon vor längerem unabhängig vom Copter bestellt, weil ich einen kleinen Lader für eine Zelle brauchte und keine Zeit hatte mich um den Aufbau zu kümmern. Wollte das nur als eine Möglichkeit erwähnen, der billigste und beste Weg ist sicher [1]. Philipp E. schrieb: > (und der kostet 150 $ ohne Fernbedienung) Der Fairness halber sei angemerkt, dass er ohne Fernbedienung aber mit USB-Nrf-Dongle 150 $ kostet. Ganz ohne Fernbedienung kostet er "nur" 120 $. Dennoch, der Preis des JD185 ist so unglaublich gut, wenn jetzt noch Preisnachlass durch größere Menge und weglassen der "Fernbedienung", Lader, etc. dazukommt, dann kann man ja gar nicht mehr wiederstehen ;-) [1] https://github.com/hackocopter/LiPoCharger
Philipp E. schrieb: > Na klar. Das geht natürlich noch viel billiger. Habe das Ding mir schon > vor längerem unabhängig vom Copter bestellt, weil ich einen kleinen Ich freue mich nur, dass eine Bastellösung tatsächlich mal preiswerter als der chinesische Clone ist :)
:
Bearbeitet durch User
Philipp E. schrieb: > Oliver Stellebaum schrieb: >> Sag dem Chinamann deutlich das Du 100 Stück (ohne FB) für 900€ inkl. > > Genau. Bleib dran (wenn du Lust / Zeit hast). Ich denke das Potential, > die Dinger hier an den Man zu bringen ist sehr sehr groß. Und die > Freude, die du den Leuten damit machst auch. Man sollte auch bedenken, dass die Preise im Moment wegen Weihnachten anziehen. Das wird wohl auch für größere Bestellungen gelten. Wahrscheinlich gibt es im Januar mehr Verhandlungsspielraum.
Also bei einem Preis von <12 Euro würde ich auf jeden Fall auch 2-3 Stück nehmen. Habe mir soeben auch noch 5 Stück der MCP73831T bestellt. Eine kleine Frage zu deinem Akkulader. Ist der Ladestrom mit 400mA nicht ein bisschen hoch? Ich lese immer etwas von 1C bei kleinen Akkus. Das entspricht ja ca. 240mA beim Original Akku. Noch eine weitere Frage: Weiss jemand was für ein Stecker da am Akku dran ist? Oder wie löst ihr das mit dem Aufladen? Eigenen Stecker dran machen?
Tim schrieb: > Ich freue mich nur, dass eine Bastellösung tatsächlich mal preiswerter > als der chinesische Clone ist :) Finde ich auch voll gut! ;-) Daher: Dominic A. schrieb: > Habe mir soeben auch noch 5 Stück der MCP73831T bestellt. Dito ;-) Tim schrieb: > Man sollte auch bedenken, dass die Preise im Moment wegen Weihnachten > anziehen. Das wird wohl auch für größere Bestellungen gelten. > Wahrscheinlich gibt es im Januar mehr Verhandlungsspielraum. +1
Dominic A. schrieb: > Also bei einem Preis von <12 Euro würde ich auf jeden Fall auch 2-3 > Stück nehmen. > Habe mir soeben auch noch 5 Stück der MCP73831T bestellt. > Eine kleine Frage zu deinem Akkulader. Ist der Ladestrom mit 400mA nicht > ein bisschen hoch? Ich lese immer etwas von 1C bei kleinen Akkus. Das > entspricht ja ca. 240mA beim Original Akku. Du hast recht. Ich habe auch noch einmal nach ähnlichen Akkus gesucht. Obwohl es keine Angaben zu den JXD385 Akkus gibt, liegen alle ähnlichen bei 1 C. Ich habe den Widerstand in der Schaltung auf 4k7 erhöht. > Noch eine weitere Frage: Weiss jemand was für ein Stecker da am Akku > dran ist? Oder wie löst ihr das mit dem Aufladen? Eigenen Stecker dran > machen? Ich würde eines der Ladegeräte schlachten und das Innenleben ersetzen.
:
Bearbeitet durch User
Tim schrieb: > Ich würde eines der Ladegeräte schlachten und das Innenleben ersetzen. Ich denke ich werde den Stecker am Akku mit einer Standard Stiftleiste ersetzen. Somit kann ich dann eine kleine "Ladestation" für mehrere Akkus bauen und muss nicht immer jeden Akku einzeln laden. Falls meine zusätzlichen Akkus irgendwann einmal eintrudeln.
Bis Januar ist es nicht mehr lang, das "professionelle" Weihnachtsgeschäft ist vermutlich lange gelaufen. Und bis die Organisation einer Sammelbestellung über das Forum dauert bei normalem Workflow sicher auch einige Zeit. Vielleicht kann man sogar zeitgleich eine Sammelbestellung für den Bu-Link organisieren und das ganze dann als Copter-Bundle anbieten. Kopter+Bulink+Software für 25€ oder sowas.
Hat schon jemand Erkenntnisse über das HF Modul in der Fernbedienung? Im Gegensatz zu gängigen Modulen hat es nicht 8 sondern 9 Anschluss Pins.
Ich habe hier einen interessanten Beitrag gefunden: http://hackaday.com/2013/11/19/hacking-a-cheap-toy-quadcopter-to-work-with-arduino/ Ich glaube zwar nicht, dass es der gleiche Quadcopter ist, aber zumindest vom Lösungweg könnte man ja lernen ;-) http://dzlsevilgeniuslair.blogspot.dk/2013/11/more-toy-quadcopter-hacking.html
Oliver Stellebaum schrieb: > Vielleicht kann man sogar zeitgleich eine Sammelbestellung für den > Bu-Link Das wäre auch nicht schlecht. Auf der anderen Seite, vielleicht geht es ja auch ohne BuLink, das Chip Erase Protokoll muss doch zu knacken sein. Ist denn schon sicher, dass der BuLink funktioniert? Oder ist der noch auf dem Weg von China nach Deutschland?
Philipp E. schrieb: > oder ist der noch auf dem Weg von China nach Deutschland? Tim schreibt bestimmt einen unübersehbaren Post, wenn der da ist, vielleicht mit #### "eingerahmt"? ;-) Tim schrieb: > Besser wäre es, das Hopping-Schema zu kennen. Hat jemand 'ne Vorstellung, wieviele NRF24L01+ man "parallel" betreiben muss, um alle 128 Kanäle zu scannen? Ich befürchte, da muss man sich 128 Stück kaufen, oder? Oliver Stellebaum schrieb: > Das ist schlimmer als auf einem Bazar, nicht so schnell aufgeben. Ich mache für die Verkäufer eine Powerpoint- bzw. PDF-Datei. Bilder sagen mehr als 1000 Worte. Dann sollten die das hoffentlich schnell begreifen. Torsten C. schrieb: > Ich habe mal den "Sales Support Inquiry" angeschrieben. Meine Frage ist heute an das "MCU team" weitergeleitet worden; ich war in CC.
Hi, mein „Frankfurter“ Helikopter liegt scheinbar in Raubling beim Zoll und kann nicht verzollt werden da keine Rechnung beiliegt. Das hinwenden meines Paypal Zahlungsbelegs macht auch keinen Sinn, da auf dem Päckchen „Remote control“ für 19,99€ steht und das hat weder vom Inhalt noch vom Preis etwas mit dem bestellten zu tun. Tolle wurst. Gruß Martin
Martin K. schrieb: > ... und kann nicht verzollt werden ... http://notizblog.wordpress.com/2012/12/10/anstrengender-ebay-kauf/ Auch bei Dir weicht der Artikel erheblich von der Beschreibung ab. Frag' den Verkäufer, ob er sich drum kümmert oder hole Dir das Geld bei Paypal zurück. Torsten C. schrieb: > … da muss man sich 128 Stück kaufen, oder? Das wären 88€: http://www.aliexpress.com/item//1099347789.html
Martin K. schrieb: > Das hinwenden > meines Paypal Zahlungsbelegs macht auch keinen Sinn, da auf dem Päckchen > „Remote control“ für 19,99€ steht und Ich habe das ganz gut hinbekommen indem ich Paypalbeleg UND Ebayartikelnummer als PDF-Druck zum Zollamt schickte. Das können die dann wohl schon vergleichen (so sie denn wollen).
Als Anhang die derzeitigen Erkenntnisse über die Pinbelegung des Prozessors in der Fernbedienung. Leider ist nur mit Fotos momentan nicht mehr machbar. Falls jemand noch Erkenntnisse hat, bitte melden,
Georg G. schrieb: > Die Chinesen sehen sehr aufs Geld. Warum sollte man einen OTP > entwickeln, wenn man Flash hat? Wäre der in der Produktion billiger? Ja, z.B. 0.25 micron, standard 5V CPU sind 22 Masken, hingegen mit Flash sind es 37 Masken, Aufpreis von ca 100%. Hierbei wird da die CPU eine Flash cpu ist, mit den Flash Masken gearbeitet und nur eine zusaetzliche Metall oder metall interconnection mask gemacht. > welcher Technologie? Das macht schon seit Jahren niemand mehr. Man nimmt > den normalen Flash Typ und setzt die Sicherheitsbits. Es gibt viele cpu mit nur otp oder simuliertem flash durch otp (4/8k flash durch 64k otp simuliert). Der Vorteil von einfachen MCU ist, dass man sei es ROM wie FLASH oder auch zusatlliches OTP designen kann, ohne mehr Flaeche zu brauchen. Bei ARM hingegen muss man den Flash nehmen.
Mit Metall Maske hast du aber festen Code, nichts mehr mit One Time Programmable. Für OTP brauchst du den ganzen Flash Zauber auch.
Georg G. schrieb: > Als Anhang die derzeitigen Erkenntnisse über die Pinbelegung des > Prozessors in der Fernbedienung. Leider ist nur mit Fotos momentan nicht > mehr machbar. > > Falls jemand noch Erkenntnisse hat, bitte melden, Pin1: P2.CS Pin2: P2.CLK Pin3: P2.DATA
B. B. schrieb: > Pin1: P2.CS > Pin2: P2.CLK > Pin3: P2.DATA Seltsam... das I2C Interface ist nämlich mit Daten und Takt auch am RF Modul. Hast du die komplette Anschlussbelegung des Moduls, eventuell Typ oder Datenblatt? Andere Frage: neben der CPU auf der FB sitzt ein kleiner 6-Beiner. Kann jemand den Typ entziffern?
Georg G. schrieb: > Falls jemand noch Erkenntnisse hat, ... ... bitte gleich eintragen: http://www.mikrocontroller.net/wikisoftware/index.php?title=Hack-O-Copter&action=edit§ion=11 Hier im Thread schadet ein kleiner Hinweis m.E. trotzdem nicht.
:
Bearbeitet durch User
Angehängte Dateien:
-
LGJ13227TX4REV0420130728.jpg
100 KB
Georg G. schrieb: > B. B. schrieb: >> Pin1: P2.CS >> Pin2: P2.CLK >> Pin3: P2.DATA > > Seltsam... das I2C Interface ist nämlich mit Daten und Takt auch am RF > Modul. Hast du die komplette Anschlussbelegung des Moduls, eventuell Typ > oder Datenblatt? > > Andere Frage: neben der CPU auf der FB sitzt ein kleiner 6-Beiner. Kann > jemand den Typ entziffern? Welchen 6-Beiner meinst du? Ich hab dir mal ein Bild von meiner FB angehängt. Ich seh da keinen 6-Beiner.
Torsten C. schrieb: > bitte gleich eintragen Houston, wir haben ein Problem... Es gibt auf Github den hack-o-copter. Dort werden Infos gesammelt. Wenn hier parallel ein Wiki entsteht, besteht die Gefahr, dass Infos verloren gehen, speziell, wenn im Forum kein Hinweis kommt. Mir ist es im Prinzip egal, wer wo sammelt. Aber bitte einigt euch. In diesem frühen Stadium ist es imho am sinnvollsten, wenn sich jeder nur eine Ecke des Projekts raus sucht und dafür die Mütze aufsetzt. Ich für mein Teil wollte das Schaltbild aufnehmen. Falls dabei jemand mitmachen möchte - bitte, gern. Aber dann sollten wir verabreden, wie wir vorgehen.
Tim schrieb: > hat den gleichen Footprint Ich dachte eher an so eine kleine Adapterplatine wie im Beitrag "Erster Kontakt mit dem ATTINY1634" . Da wäre der Footprint egal. B. B. schrieb: > Ich hab dir mal ein Bild von meiner FB > angehängt Du hättest auch einfach auf diese verweisen können, nur so als Tipp: http://www.mikrocontroller.net/wikifiles/f/fb/HOC_Fernbedienung_Platine_total.jpeg
B. B. schrieb: > Ich seh da keinen 6-Beiner rechts neben der CPU, klein und unscheinbar, einige Cs drum herum.
Torsten C. schrieb: > Philipp E. schrieb: >> oder ist der noch auf dem Weg von China nach Deutschland? > > Tim schreibt bestimmt einen unübersehbaren Post, wenn der da ist, > vielleicht mit #### "eingerahmt"? ;-) Leider ist das bu-link noch nicht da. Heute lag aber ein Schrieb vom Zoll im Briefkasten, vielleicht kommt da etwas - oder es ist ein weiterer Quadcopter. > Tim schrieb: >> Besser wäre es, das Hopping-Schema zu kennen. > > Hat jemand 'ne Vorstellung, wieviele NRF24L01+ man "parallel" betreiben > muss, um alle 128 Kanäle zu scannen? Ich befürchte, da muss man sich 128 > Stück kaufen, oder? Hmm... dann bräuchte man nur noch 128 Microcontroller um die ganzen SPI-Kanäle auszulesen? :) Ich habe einfach alle Kanäle nacheinander durchgescannt. Wenn das hopping der FB wirklich einen Zufallsmuster folgt, sollte dann auch die korrekte Verteilung herauskommen. Nur die Sequenz kennt man dann natürlich noch nicht. Man könnte natürlich auch einen LA an die Fernbedienung hängen.
Georg G. schrieb: > Als Anhang die derzeitigen Erkenntnisse über die Pinbelegung des > Prozessors in der Fernbedienung. Leider ist nur mit Fotos momentan nicht > mehr machbar. > > Falls jemand noch Erkenntnisse hat, bitte melden, Super, vielen Dank! Komisch dass das Funkmodul am I2C-Port hängt? Der BK2423 hat eigentlich ein SPI interface.
Georg G. schrieb: > Houston, wir haben ein Problem... > > Es gibt auf Github den hack-o-copter. Dort werden Infos gesammelt. Wenn > hier parallel ein Wiki entsteht, besteht die Gefahr, dass Infos verloren > gehen, speziell, wenn im Forum kein Hinweis kommt. > > Mir ist es im Prinzip egal, wer wo sammelt. Aber bitte einigt euch. In > diesem frühen Stadium ist es imho am sinnvollsten, wenn sich jeder nur > eine Ecke des Projekts raus sucht und dafür die Mütze aufsetzt. Ich für > mein Teil wollte das Schaltbild aufnehmen. Falls dabei jemand mitmachen > möchte - bitte, gern. Aber dann sollten wir verabreden, wie wir > vorgehen. Also ich sehe das so: Das Github-Repository ist dafür da, um Quellcode und Binärdaten einfach und unstrukturiert zu sammlen. Durch die Versionierung ist sichergestellt das nichts verloren geht und niemand etwas kaputtspielt. Das Repository hat genug Platz um auch ungeordnete Informationsflut wie z.B. Logfiles zu sammeln. Der Wikiartikel ist ein Einstiegspunkt für "Outsider" und soll eine Übersicht über alle Informationen und Anleitungen zum Einstieg bieten. Das Wiki enthält damit einen Informationsextrakt aus den Daten im Repository. Es gibt natürlich einen große Schnittmenge. Das kann man wahrscheinlich nicht immer einfach lösen. Vielleicht wäre es in dem Fall sinnvoll, das Repository für die Arbeitsfiles zu nutzen und die Kernerkenntnisse in das Wiki zu übertragen wenn der Kenntnissstand einigermassen gesichert ist? Aus dem Wikiartikel kann man ja wieder auf die Rohdaten im Repository verlinken. z.B. ein Screenshot der Schaltung im Wiki und die .sch Datei im Repository.
:
Bearbeitet durch User
Georg G. schrieb: > Hat schon jemand Erkenntnisse über das HF Modul in der Fernbedienung? Im > Gegensatz zu gängigen Modulen hat es nicht 8 sondern 9 Anschluss Pins. Hier wird ein ähnlich aussehendes Modul auf Ebay verkauft. Auf der Rückseite sind die Anschlussbezeichnungen. http://www.ebay.de/itm/2-4G-Wireless-Module-FSK-BK2423-Atmega-AVR-Arduino-UNO-R3-SPI-MCU-ARM-C51-STM32-/271139012729 Edit: Sorry, ich war zu schnell. Das Ebay-Modul hat nur 8 Anschlusse.
:
Bearbeitet durch User
Tim schrieb: > Der Wikiartikel ist ein Einstiegspunkt für "Outsider" und soll eine > Übersicht über alle Informationen und Anleitungen zum Einstieg bieten. > Das Wiki enthält damit einen Informationsextrakt aus den Daten im > Repository. > > Es gibt natürlich einen große Schnittmenge. Das kann man wahrscheinlich > nicht immer einfach lösen. Vielleicht wäre es in dem Fall sinnvoll, das > Repository für die Arbeitsfiles zu nutzen und die Kernerkenntnisse in > das Wiki zu übertragen wenn der Kenntnissstand einigermassen gesichert > ist? Sehe ich auch so in der Art. Ich denke, alles was ins Wiki kommt sollte sich nicht mehr wirklich verändern und der Kentnisstand darüber sollte einigermaßen vorhanden sein. Denn gerade so eine Wikipage ist wie du schon schreibst für Leute, die neu dazukommen und sich auch mit dem Hack-O-Copter befassen wollen. Ich werde übrigens bald verrückt. Der Chinese hat nur geschrieben, dass es wegen Weihnachten uns so länger dauern kann, er rückte aber wenigstens mal eine Trackingseite heraus ...
Tim schrieb: > ein Screenshot der Schaltung im Wiki und die > .sch Datei im Repository. Gutes Beispiel. Außerdem ist im Wiki schneller mal was geändert, wie der Name schon sagt. Die Frage, ob wir das github Wiki nehmen, hatten wir schon. Sind wir uns denn da einig? Wie ist das z.B. mit der Pinbelegung^^? Wiki oder Github? Tim schrieb: > Komisch dass das Funkmodul am I2C-Port hängt http://www.i2cchip.com/mix_spi_i2c.html Nur so ein Gedanke.
:
Bearbeitet durch User
Torsten C. schrieb: > Tim schrieb: >> ein Screenshot der Schaltung im Wiki und die >> .sch Datei im Repository. > > Gutes Beispiel. Außerdem ist im Wiki schneller mal was geändert, wie der > Name schon sagt. Die Frage, ob wir das github Wiki nehmen, hatten wir > schon. Sind wir uns denn da einig? Ja, auf jeden fall das µC Wiki. Das Github-Wiki habe ich selbst noch nicht gefunden :) > > Wie ist das z.B. mit der Pinbelegung^^? Wiki oder Github? Das Textfile ins Github und die editierte Tabelle ins Wiki? :)
Hey Leute, also die Frage Git vs. Wiki finde ich auch recht tricky. Was ist z. B. mit dem neuen Lipo Lader bzw. dem RC-Protokoll. Da ist aktuell das Repository die beste Anlaufstelle (Schaltung als Bild, kurze Beschreibung bzw. Graph der aufgetretenen Channels). Das sollte auf lange Sicht wohl eher ins Wiki, oder wie seht ihr das? Ich persönlich finde Redundanz, auch wenn sie wohl unvermeidbar ist, sehr störend. Ich würde dafür plädieren, im Zweifel lieber einen Link (man kann ja sowohl die Git-Hub Doku als auch die Wiki Abschnitte direkt Adressieren) an der entsprechenden Stelle platzieren, als die Informationen mehrmals zu sammeln. Wenn ich den Wiki Artikel mir so ansehe, gibt es viele Stellen, wo direkt auf das Repo verlinkt werden könnte (Datenblätter, Fotos). Just my 2 cents
Philipp E. schrieb: > Hey Leute, > > also die Frage Git vs. Wiki finde ich auch recht tricky. Was ist z. B. > mit dem neuen Lipo Lader bzw. dem RC-Protokoll. Da ist aktuell das > Repository die beste Anlaufstelle (Schaltung als Bild, kurze > Beschreibung bzw. Graph der aufgetretenen Channels). Das sollte auf > lange Sicht wohl eher ins Wiki, oder wie seht ihr das? > Das sollte auf lange Sicht auch ins Wiki, wenn es fertig ist. :)
Philipp E. schrieb: > Was ist z. B. mit … dem RC-Protokoll. … Das sollte auf > lange Sicht wohl eher ins Wiki, oder wie seht ihr das? Das fände ich auch übersichtlicher. > Ich persönlich finde Redundanz, auch wenn sie wohl unvermeidbar ist, > sehr störend. Redundanz sollte dringend vermieden werden, das sehe ich auch so. > Wenn ich den Wiki Artikel mir so > ansehe, gibt es viele Stellen, wo direkt auf das Repo verlinkt werden > könnte (Datenblätter, Fotos). OK, ich müsste erst suchen. Am besten gleich erledigen. Danke.
Torsten C. schrieb: > Hat jemand 'ne Vorstellung, wieviele NRF24L01+ man "parallel" betreiben > muss, um alle 128 Kanäle zu scannen? Ich befürchte, da muss man sich 128 > Stück kaufen, oder? Also so wie ich das sehe, müsste das Hopping Shema aus dem Source Code der Deviation Firmware zu erkennen sein. Das File v202_nrf24l01.c [1] implementiert das v202 Protocoll, was laut Internet mit unserem Copter kompatibel sein müsste. Die entscheidenden Stellen im Code:
1 | // This is frequency hopping table for V202 protocol
|
2 | // The table is the first 4 rows of 32 frequency hopping
|
3 | // patterns, all other rows are derived from the first 4.
|
4 | // For some reason the protocol avoids channels, dividing
|
5 | // by 16 and replaces them by subtracting 3 from the channel
|
6 | // number in this case.
|
7 | // The pattern is defined by 5 least significant bits of
|
8 | // sum of 3 bytes comprising TX id
|
9 | static const u8 freq_hopping[][16] = { |
10 | { 0x27, 0x1B, 0x39, 0x28, 0x24, 0x22, 0x2E, 0x36, |
11 | 0x19, 0x21, 0x29, 0x14, 0x1E, 0x12, 0x2D, 0x18 }, // 00 |
12 | { 0x2E, 0x33, 0x25, 0x38, 0x19, 0x12, 0x18, 0x16, |
13 | 0x2A, 0x1C, 0x1F, 0x37, 0x2F, 0x23, 0x34, 0x10 }, // 01 |
14 | { 0x11, 0x1A, 0x35, 0x24, 0x28, 0x18, 0x25, 0x2A, |
15 | 0x32, 0x2C, 0x14, 0x27, 0x36, 0x34, 0x1C, 0x17 }, // 02 |
16 | { 0x22, 0x27, 0x17, 0x39, 0x34, 0x28, 0x2B, 0x1D, |
17 | 0x18, 0x2A, 0x21, 0x38, 0x10, 0x26, 0x20, 0x1F } // 03 |
18 | };
|
sowie beim init
1 | const u8 *fh_row = freq_hopping[sum & 0x03]; |
2 | // Higher 3 bits define increment to corresponding row
|
3 | u8 increment = (sum & 0x1e) >> 2; |
4 | for (u8 i = 0; i < 16; ++i) { |
5 | u8 val = fh_row[i] + increment; |
6 | // Strange avoidance of channels divisible by 16
|
7 | rf_channels[i] = (val & 0x0f) ? val : val - 3; |
8 | }
|
Sollte es sich also wirklich um das v202 Protokoll handeln, ist
diesbezüglich alles klar. Wobei diese Information der GitHub Doku ("15
Checksum Used to determine next channel for channel hopping")
wiederspricht.
[1]https://bitbucket.org/PhracturedBlue/deviation/src/c960b8ea4e774154ef09968dd187c07651b7f9fc/src/protocol/v202_nrf24l01.c?at=default
:
Bearbeitet durch User
Tim schrieb: > Das sollte auf lange Sicht auch ins Wiki, wenn es fertig ist. :) Super. Denke das ist die perfekte Aufteilung. Work in Progress im Repo sammeln. Sobald es fertig ist Infos ins Wiki verlagern und im Repo einen Link auf die entsprechende Stelle im Wiki.
Philipp E. schrieb: > Torsten C. schrieb: >> Hat jemand 'ne Vorstellung, wieviele NRF24L01+ man "parallel" betreiben >> muss, um alle 128 Kanäle zu scannen? Ich befürchte, da muss man sich 128 >> Stück kaufen, oder? > > Also so wie ich das sehe, müsste das Hopping Shema aus dem Source Code > der Deviation Firmware zu erkennen sein. Das File v202_nrf24l01.c [1] > implementiert das v202 Protocoll, was laut Internet mit unserem Copter > kompatibel sein müsste. Das dachte ich bis gestern auch. Nach dem Code dürften aber nur genau 16 channels genutzt werden. In der Praxis waren es nach meinem Versuch deutlich mehr. Was ich noch nicht geschrieben hatte: Ich habe auch Versucht das Channel-Hopping im Empfänger zu implementieren, indem ich bei erfolgreichem Empfang auf einem Kanal auf den Nachfolgekanal gesprungen bin. Leider war das nicht wirklich erfolgreich - es kamen fast nie sofort Pakete an.
:
Bearbeitet durch User
Interessant und spannend. Mensch, wie gerne hätte ich endlich meinen hier in Händen zum testen. Nur ein paar Gedanken, kann gut sein dass sie nicht zutreffen... Tim schrieb: > Das dachte ich bis gestern auch. Nach dem Code dürften aber nur genau 16 > channels genutzt werden. In der Praxis waren es nach meinem Versuch > deutlich mehr. Könnte es sein, dass die verwendeten Chips nicht so sauber arbeiten und beim Test, wenn du den Empfänger auf Channel x einstellst auch mal ein Packet empfangen wird, das eigentlich auf Channel x +/- 1 gesendet wurde und dadurch die Anzahl der verwendeten Channels größer erscheint? Tim schrieb: > Was ich noch nicht geschrieben hatte: Ich habe auch Versucht das > Channel-Hopping im Empfänger zu implementieren, indem ich bei > erfolgreichem Empfang auf einem Kanal auf den Nachfolgekanal gesprungen > bin. Leider war das nicht wirklich erfolgreich - es kamen fast nie > sofort Pakete an. Ich meine in den Source code Kommentaren gelesen zu haben, dass die Packete zwei mal verschickt werden. Könnte es sein, dass du schon beim ersten Packet springst und es deswegen etwas "dauert" bis das Packet auf dem nächsten Channel ankommt.
Tim schrieb: > dann bräuchte man nur noch 128 Microcontroller Bei SPI? Man nehme neun 74HC154 (4,32€). Oder sehe ich das zu naiv? Oder lohnt sich die Arbeit nicht? Da ich den NRF24L01 plane, als "Hausbus" einzusetzten, wäre so ein Funk-Logger vielleicht nicht übel.
:
Bearbeitet durch User
Philipp E. schrieb: > Könnte es sein, dass die verwendeten Chips nicht so sauber arbeiten und > beim Test, wenn du den Empfänger auf Channel x einstellst auch mal ein > Packet empfangen wird, das eigentlich auf Channel x +/- 1 gesendet wurde > und dadurch die Anzahl der verwendeten Channels größer erscheint? Da bin ich mir nicht sicher. Die Kanäle haben 1 Mhz Abstand. Ich hoffe doch dass die Trennschärfe ausreicht. Philipp E. schrieb: > Ich meine in den Source code Kommentaren gelesen zu haben, dass die > Packete zwei mal verschickt werden. Könnte es sein, dass du schon beim > ersten Packet springst und es deswegen etwas "dauert" bis das Packet auf > dem nächsten Channel ankommt. Das habe ich auch erst gedacht, aber teilweise hat es Sekunden gedauert bis das nächste Packet kam. Bei 50 Updates pro Sekunde sollte eigentlich häufiger was kommen?
Torsten C. schrieb: > Oder sehe ich das zu naiv? Oder lohnt sich die Arbeit nicht? Ich denke, ich nehme Stapelbare Buchsenleisten und mache 16 Platinen mit je einem 74HCT238 und acht NRF24L01. Bis die Platinen von Jakob zurück sind, habt Ihr bestimmt das hopping schon anders heraus bekommen, oder?
Tim schrieb: > aber teilweise hat es Sekunden gedauert > bis das nächste Packet kam Ne, das passt wirklich nicht zusammen. Wenn es in der Größenordnung liegt, dann kann das eigentlich nicht das V202 Protokoll sein. Torsten C. schrieb: > Bei SPI? Man nehme neun 74HC154 (4,32€). So ein Scanner wäre vermutlich der beste Ansatz um rauszufinden, wo was los ist. Oder halt ein Spektrum Analyzer, damit würde man ja auch sehen, welche Kanäle verwendet werden. Leider decken diese schönen DAB-Dongles ja nur den Bereich bis 2 GHz ab, sonst wäre das eine Idee. Naja, ich glaube allerdings nicht, dass man umbedingt für jeden Channel einen Empfänger braucht. Es muss ja nicht umbedingt das ganze Band gleichzeitig überwacht werden, um Rückschlüsse zu ziehen. Wahrscheinlich reicht auch die Hälfte oder ein Viertel aus, um Erkenntnisse zu extrahieren.
Torsten C. schrieb: > Bis die Platinen von Jakob zurück sind, habt Ihr bestimmt das hopping > schon anders heraus bekommen, oder? Ich versuche gerade 'mal den den SPI-Bus in der Fernbedienung anzuzapfen.
Tim schrieb: > Ich versuche gerade 'mal den den SPI-Bus in der Fernbedienung > anzuzapfen. Das ist sicher mit Abstand vom Hardware Aufwand der günstigste und beste Weg. Bin gespannt...
Auf dem kleinen "6-Beiner" steht S2M0 oder S2M6 und ne Art Regenbogen drauf und ist nur ein 5 -Beiner. Bestimmt ein 3.3V Regler oder ähnlich... Auch von der Belegung und den C's außenrum..
Angehängte Dateien:
-
RC-MCU-UR-HOC.jpg
260 KB
So, die Leitungen sind angeschlossen. Dabei gab es eine kleine Überraschung: In meiner Fernbediendung sitzt ein Microcontroller mit anderer Typenbezeichnung. Konnte man mit bloßem Auge kaum erkennen. N79E814AS2? ?=Zeichen nicht erkennbar 321002234B?78?2??A
:
Bearbeitet durch User
No y. schrieb: > Auf dem kleinen "6-Beiner" steht S2M0 oder S2M6 und ne Art Regenbogen > drauf und ist nur ein 5 -Beiner. > > Bestimmt ein 3.3V Regler oder ähnlich... Auch von der Belegung und den > C's außenrum.. Ja, das kleine SOT23 Ding unten rechts ist mit VDD der MCU verbunden. Das ist ja wohl ein ziemlich schwachsinniges Design. Gleich zwei Linearregler in einem Batteriegerät? Da hätte man ja auch gleich ein paar Batterien weglassen können.
Der eine ist aber ein 5V Regler oder? Zumindest steht bei mir AMS1117 5.0 S1142 drauf... Hehe die China Lupen Brille hat sich jetzt schon gelohnt... :D
Warum haben die denn bitte schön enn 80C51 Controller drin... Nen 2. ARM wäre mir lieber... so brauch man ja noch einen Programmer... Mein J-Link kann den zumindest anscheinend nicht... Achja wie ist die Belegung des Funk Moduls? Dann häng ich auch mal nen LA dran... Isses denn nu SPI oder I2C?
:
Bearbeitet durch User
Philipp E. schrieb: > Das ist sicher mit Abstand vom Hardware Aufwand der günstigste und beste > Weg. Gut, dass es Dich gibt, Tim. Torsten C. schrieb: > Wie ist das z.B. mit der Pinbelegung^^? Wiki oder Github? Ich denke an solchen Beispielen lernen wir schneller, ohne lange Grundsatzdiskussion. Tim schrieb: > Das Textfile ins Github und die editierte Tabelle ins Wiki? :) Das wäre redundant, also Mist! Oder war das ein Augenzwinkern? Im Wiki kann man schneller mal was dazu schreiben. Versioniert wird auch. Also: Wohin denn nun? Georg G. schrieb: > Aber bitte einigt euch. Sind wir uns denn nun einig? No y. schrieb: > Isses denn nu SPI oder I2C? Vielleicht beides^^.
No y. schrieb: > Warum haben die denn bitte schön enn 80C51 Controller drin... > > Nen 2. ARM wäre mir lieber... so brauch man ja noch einen Programmer... > > Mein J-Link kann den zumindest anscheinend nicht... > > > Achja wie ist die Belegung des Funk Moduls? Dann häng ich auch mal nen > LA dran... > > Isses denn nu SPI oder I2C? Das solltest Du mit einem LA recht schnell erkennen können Gruß Martin
:
Bearbeitet durch User
Auf der unterseite des FunkModuls stehen die Signal Bezeichnungen...
3.3V Mosi SCK MISO SE ??? GND IRQ Bezeichnungen sind von links nach rechts (Diode Rechts) von oben drauf geschaut.. Die letzten 3 Pin kann ich net richtig sehen wegen dem Lötpunkt vom Quarz... Könnte es jetzt mal noch auslöten... muss aber dann erstmal wieder meine Lötstation unter dem Bett hervorkramen...
:
Bearbeitet durch User
Ok, hier sind erste Ergebnisse: https://github.com/hackocopter/Documentation/tree/master/RemoteControl/Datalog_RC_SPI Ich habe den Datenverkehr an der Pins 6-10 der MCU mitgeschnitten. Pin 7 scheint clk zu sein, 6 Data out. Pin 10 ist evtl. nicht richtig verbunden. Ich habe jeweils einmal nach Einschalten und einmal nach Binding mitgeloggt. Die Daten gibt es einmal per SPI-Analyzer exportiert und einmal Roh. Die Rohdaten lassen sich mit "Logic" einlesein: http://www.saleae.com/logic/features -> downloads Man kann in dem Log nach dem Einschalten schön sehen, wie die Register des BK2423 nacheinander initialisiert werden. Um das Channelhopping zu entschlüssln, müsste man die Logs parsen. Ich muss jetzt leider weiter. Werde mir das in den nächsten Tagen noch einmal anschauen. Mit den Daten sollte sich schon einiges anfangen lassen.
Angehängte Dateien:
-
screenshot.png
88 KB
Hier noch ein screenshot des ersten Schreibzugriffs auf das RF-Modul nach dem Einschalten der FB.
3.3V MOSI an PIN6 MCU SCK an PIN7 MCU MISO an PIN8 MCU CE GND IRQ CSN an PIN9 MCU RXEN So sind die Pins Die anderen gehen nicht an den MCU
:
Bearbeitet durch User
Tim schrieb: > Ok, hier sind erste Ergebnisse: Super. Vielen Dank!!! Werde da gleich mal einen Blick drauf werfen.
No y. schrieb: > … MOSI an PIN6 MCU … Super, vielen Dank. :-) So kommen wir voran! Torsten C. schrieb: > Sind wir uns denn nun einig? > Ich friere meine Arbeiten so lange ein. Wie soll denn das z.B. ins Wiki kommen? Soll ich sowas in Zukunft immer übertragen? http://www.mikrocontroller.net/wikisoftware/index.php?title=Hack-O-Copter&action=edit§ion=12 Wir brauchen Regeln, so ähnlich wie im Beitrag "SUPER Bauteile-Schnäppchen WIKI"
:
Bearbeitet durch User
So, habe mal das Protokoll analysiert. Habe jetzt leider keine Zeit mehr alles im Wiki zu dokumentieren, daher poste ich die Infos gleich hier. Alles zur freien Verfügung (CC BY-NC-SA)
Wo ist denn hier?? Und außerdem wie analysiert man sowas? Rein Interesse halber.. Mit so einem Parser? Wenn ja welcher und wie geht sowas dann?
Philipp E. schrieb: > daher poste ich die Infos gleich hier Ist Cut&Paste hier einfacher als dort? http://www.mikrocontroller.net/wikisoftware/index.php?title=Hack-O-Copter&action=edit§ion=13
So, zuerst kurz zur Software, falls jemand die Auswertung nachvollziehen möchte. Anbei ein kleines Python script, dass die SPI-Daten einließt und auswertet. Achtung: Der Code ist in dieser Form kein vollständiger Parser für alle Befehle, ich habe nur die Dinge implementiert die nötig sind um die Traces von Tim auszuwerten und das Fernbedienung Protokoll zu entschlüsseln. Auch verarbeite ich nur MOSI, MISO wird aktuell ignoriert. Habe die Struktur möglichst einfach gehalten, dürfte daher sehr einfach sein dass bei Bedarf zu erweitern. Eingabeformat sind die .txt Dateien aus dem GitRepo die Tim vorhin gepostet hat. Konkret habe ich verwendet: https://github.com/hackocopter/Documentation/blob/master/RemoteControl/Datalog_RC_SPI/SPI%20traffic%20after%20binding.txt Aufruf des Scripts erfolgt mit:
1 | python parseSPI.py <SPI-Trace> <Channel Target File> <Payload Target File> |
bzw. konkret, wenn die Aufzeichnung data.txt heißt:
1 | python parseSPI.py data.txt channels.txt payload.txt |
Das Script geht dann alle Daten durch. Um zu erkennen, welche Words zu einem "Paket" gehören, wird der Timestamp ausgewertet. Sobald die Daten weiter als 0.001 auseinander liegen*, nehme ich an es handelt sich um ein neues Packet. Die einzelnen Pakete werte ich dann gemäß Register Namen aus dem Datenblatt aus dem Git Repo aus. Damit wird es sehr einfach das Protokoll zu identifizieren. * Anpassung bei Bedarf durch "threshold" in "groupDataByTime" Die Ausgabe des Programms sieht dann so aus:
1 | ################################## |
2 | New Packet, Data Word Count: 25 |
3 | ################################## |
4 | R_REGISTER: STATUS |
5 | R_REGISTER: CONFIG |
6 | W_REGISTER: STATUS 0b101110 |
7 | W_REGISTER: RF_CH 0b101101 |
8 | FLUSH_TX |
9 | R_REGISTER: CONFIG |
10 | W_TX_PAYLOAD: 16 Bit 0x00 0x00 0x00 0x00 0x40 0x40 0x40 0x1F 0xE4 0x75 0x00 0x00 0x00 0x00 0x00 0x38 |
11 | |
12 | |
13 | ################################## |
14 | New Packet, Data Word Count: 25 |
15 | ################################## |
16 | R_REGISTER: STATUS |
17 | R_REGISTER: CONFIG |
18 | W_REGISTER: STATUS 0b101110 |
19 | W_REGISTER: RF_CH 0b100001 |
20 | FLUSH_TX |
21 | R_REGISTER: CONFIG |
22 | W_TX_PAYLOAD: 16 Bit 0x00 0x00 0x00 0x00 0x40 0x40 0x40 0x1F 0xE4 0x75 0x00 0x00 0x00 0x00 0x00 0x38 |
23 | |
24 | |
25 | ################################## |
26 | New Packet, Data Word Count: 25 |
27 | ################################## |
28 | R_REGISTER: STATUS |
29 | R_REGISTER: CONFIG |
30 | W_REGISTER: STATUS 0b101110 |
31 | W_REGISTER: RF_CH 0b100001 |
32 | FLUSH_TX |
33 | R_REGISTER: CONFIG |
34 | W_TX_PAYLOAD: 16 Bit 0x00 0x00 0x00 0x00 0x40 0x40 0x40 0x1F 0xE4 0x75 0x00 0x00 0x00 0x00 0x00 0x38 |
35 | |
36 | |
37 | ################################## |
38 | New Packet, Data Word Count: 25 |
39 | ################################## |
40 | R_REGISTER: STATUS |
41 | R_REGISTER: CONFIG |
42 | W_REGISTER: STATUS 0b101110 |
43 | W_REGISTER: RF_CH 0b111111 |
44 | FLUSH_TX |
45 | R_REGISTER: CONFIG |
46 | W_TX_PAYLOAD: 16 Bit 0x00 0x00 0x00 0x00 0x40 0x40 0x40 0x1F 0xE4 0x75 0x00 0x00 0x00 0x00 0x00 0x38 |
:
Bearbeitet durch User
tl;dr; Abschließend kurz meine Erkenntnisse aus der Auswertung des Traces den Tim aufgezeichnet hat (ich habe mir nur angeschaut, was nach dem Binden passiert): * Die Payload hat eine Länge von 16-Byte * Das letzte Bit entspricht der Summe aller vorherigen Bits (bzw. den unteren 16-Bits der Summe) * Das Datenformat passt zu dem im GitRepo beschriebenen (https://github.com/hackocopter/Documentation/tree/master/RemoteControl) * Das Datenformat passt zu der Implementierung des V202 Protokolls in der Deviation firmware (https://bitbucket.org/PhracturedBlue/deviation/src/c960b8ea4e774154ef09968dd187c07651b7f9fc/src/protocol/v202_nrf24l01.c?at=default) -> es handelt sich um das V202 Protokoll Zum Channel Hopping: * jedes Packet wird zweimal versendet * es immer 16-Channel durchgehoppt (dann gehts wieder von vorne los) * auch das passt zur Implementierung in der Deviation firmware Die Sequenz in den Daten:
1 | 63, 63, 46, 46, 42, 42, 40, 40, 52, 52, 60, 60, 31, 31, 39, 39, 47, 47, 26, 26, 36, 36, 24, 24, 51, 51, 30, 30, 45, 45, 33, 33 |
Da die Checksum immer gleich ist, kann ich nichts dazu sagen, ob das Hopping von ihr abhängt. In der Deviation firmware sieht es nicht so aus. Um das zu prüfen bräuchte man mal einen SPI-Trace in dem etwas mehr passiert (Stick Bewegung o. Ä.) damit sich die Checksum ändert. So, nun muss ich aber dringend ins Bett ;-) Eingabe Datei: https://github.com/hackocopter/Documentation/blob/master/RemoteControl/Datalog_RC_SPI/SPI%20traffic%20after%20binding.txt) Ergebniss Dateien im Anhang
Torsten C. schrieb: > Ist Cut&Paste hier einfacher als dort? Nein, aber beim Wiki hätte ich gerne besser / genauer dokumentiert, und dazu hab ich gerade nicht so die Zeit ;-) Habe aber die Quintessenz schonmal in den Artikel gepackt.
:
Bearbeitet durch User
Angehängte Dateien:
-
NuMicro_M051_Series.png
110 KB -
nuvoton.png
16 KB
Hallo! Ich hab hier noch ein Werbeblättchen von Nuvoton gefunden. Das wurde 2011 auf der embedded verteilt. Die M051-Serie ist nicht, wie man denken könnte ein 8051-Derivat, sondern ein low-cost Cortex-M0. Außerdem ist eine Liste dabei, von Firmen die das Zeug hier A und D verticken wollen (oder wollten?). Grüße Jens
Hier noch einmal eine wichtige Info: Der Microcontroller in der Fernbedienung ist ein 8051 Derivat. Auch wenn sich die Beschriftung hier* nur vollständig lesen lässt, muss es sich um einen N79E814AS20 handeln. Die Bausteine mit den anderen Beschriftungen sind dann evtl. vom Hersteller programmierte Bausteine. (Also Maske, OTP oder Flash) Das Datenblatt scheint es nur auf Chinesisch zu geben?!? Hier: http://www.nuvoton.com/NuvotonMOSS/Community/ProductInfo.aspx?tp_GUID=c60884e1-c6a9-45da-8268-6be8b32e9cf2 Die Peripherie sieht der des MINI54ZAN sehr ähnlich. Da hat man wohl viel wiederverwendet. "The N79E815A/814A/8132A 8-bit Turbo 51 (4T Mode) microcontroller is embedded with 16K/8K/4K bytes Flash EPROM which can be programmed through universal hardware writer, serial ICP (In Circuit Program) programmer, software ISP function. The instruction sets of the N79E815A/814A/8132A are fully compatible with the standard 8052. The N79E815A/814A/8132A contains 16K/8K/4K bytes Application Flash EPROM (APROM) memory, 4 Kbytes Data Flash memory, and 2 Kbytes Load Flash EPROM (LDROM) memory; 256 bytes direct and indirect RAM, 256 bytes XRAM; 25 I/O with bit-addressable I/O ports; two 16-bit timers/counters; 8-channel multiplexed 10-bit A/D converter; 4-channel 10-bit PWM; three serial ports including a SPI, I2C and an enhanced full duplex serial port; 2-level BOD voltage detection/reset, and power-on reset (POR). The N79E815A/814A/8132A also supports internal RC oscillator at the nominal frequency of 22.1184 MHz. The accuracy of RC oscillator (22.1184 MHz) is trimmed as ±1% under the condition of room temperature and VDD = 5V before shipping from by factory trimming mechanism. These peripherals are supported by 14 sources of four-level interrupt capability. To facilitate programming and verification, the Flash EPROM inside the N79E815A/814A/8132A allows the program memory to be programmed and read electronically. Once the code is confirmed, the user can protect the code for security." *Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter"
:
Bearbeitet durch User
Angehängte Dateien:
-
channels.png
4,9 KB
Philipp E. schrieb: > Abschließend kurz meine Erkenntnisse aus der Auswertung des Traces den > Tim aufgezeichnet hat (ich habe mir nur angeschaut, was nach dem Binden > passiert): Wow, super Arbeit! Dann ist es also doch nur ein 16 Channel Schema. Wenn man die Kanäle des Senders mit den empfangenen vergleicht, scheint es zumindest vom Bereich zu passen. Es muss aber noch ein anderes Problem geben. Entweder habe ich den nRF24 nicht richtig angesteuert oder die Trennschärfe ist doch nicht ideal.
:
Bearbeitet durch User
Philipp E. schrieb: > Da die Checksum immer gleich ist, kann ich nichts dazu sagen, ob das > Hopping von ihr abhängt. In der Deviation firmware sieht es nicht so > aus. Ja, ich weiss auch nicht mehr woher ich das hatte. Anscheinend ist es doch ein statisches Schema. Habe den Hinweis wieder entfernt.
Der N79E814 pass vom Pinning her besser in die Schaltung. Die Abfrage der Taster wird damit erklärbar. Der 5-Beiner "S2M?" kann ein Spannungsregler sein. Es gibt den AMS1117, der die Batteriespannung auf 5V regelt. Dann ist unterhalb des Knüppels auf der S11 Seite ein SOT223 zu sehen (Typ nicht zu entziffern), der ein Spannungsregler sein wird. Den Layout nach macht er die Versorgung der CPU. Der 5-Beiner ist nur für das RF-Modul zuständig. Frage: An den oberen Ecken sind zwei ??? mit Drähten angeschlossen. Die Lötpunkte sind mit MODE1 und MODE2 bezeichnet. Sie werden zusammen mit den Tastern abgefragt. Wozu sind sie da?
No y. schrieb: > Die anderen gehen nicht an den MCU Kannst du das bitte noch mal nachprüfen? Laut meinem Foto geht eine Leitung zwischen den Beinen der LED durch zum Modul. Kann bitte mal jemand ausklingeln, wohin das zweite LED Bein führt? Die Leitung geht zum Widerstand R5 (eine Drahtbrücke) und versickert dann unter der CPU. Die N79E814 Prozessoren gibt es übrigens bei Aliexpress für 10.- per 10 Stück. Da kann man das Original auslöten und aufheben. Fehlt nur eine gute Fassug für das Ding :-)
Die Leitung die zwischen den LED Pins durchgeht ist die CSN. Die geht einmal an die MCU wie bereits geschrieben und zum anderen auf den Widerstand. Die LED Leitung kommt auf der anderen Seite des MCu wieder raus. geht da auf das obere Pad des Widerstandes direkt neben dem Chip den 1k. Und dann über den Widersatnd an PIN 11 der MCU.
:
Bearbeitet durch User
Anbei das Schaltbild der Fernbedienung. Es fehlen noch die zwei Spannungsregler für CPU und RF-Modul und die Bauteilwerte teilweise. Kennt jemand einen 5-beinigen SOT??? Spannungsregler? Dann nehme ich den stellvertretend. Das Eagle File liegt auf Github
:
Bearbeitet durch User
Die Fernbedienung und der Quadrocopter arbeiten nach dem gleichen Algorithmus. Beide habe eine Tabelle [4 Reihen mit je 16 "magischen" Zahlen (siehe Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter", um aus dieser mittels der ID der Fernbedienung die 16 Kanäle zu generieren. Die Checksumme enthält für das Hopping keine weiteren Informationen, sie ist lediglich die Summe der vorhergehenden Bytes modulo 0x100. Beispiel: Packet: 00 00 00 00 40 40 40 1F E4 75 00 00 00 00 00 38 Die Summe der Bytes 0 bis 14 ist 0x238. 0x238 % 0%100 = 0x38
Georg G. schrieb: > MODE1 und MODE2 ... Wozu sind sie da? Tauschen der Belegung der Steuerknüppel (roll/gier/nick) z.B. für Flugzeuge.
Wahnsinn Leute, hier gehts ja ordentlich voran. Toll! Davis schrieb: > Die Checksumme enthält für das Hopping keine weiteren Informationen, sie > ist lediglich die Summe der vorhergehenden Bytes modulo 0x100. Philipp E. schrieb: > * Das letzte Bit entspricht der Summe aller vorherigen Bits (bzw. den > unteren 16-Bits der Summe) Genau. Allerdings ist immer noch etwas unklar, wie er die Hopping Sequenz auswählt. Der Code:
1 | u8 sum; |
2 | tx_id[0] = (id >> 16) & 0xFF; |
3 | tx_id[0] = (id >> 8) & 0xFF; |
4 | tx_id[0] = (id >> 0) & 0xFF; |
5 | sum = tx_id[0] + tx_id[1] + tx_id[2]; |
6 | // Base row is defined by lowest 2 bits
|
7 | const u8 *fh_row = freq_hopping[sum & 0x03]; |
der die Reihe auswählt und läd scheint mir etwas wirr, die ersten zwei Zuweisungen sind ja ohne Effekt. Vielleicht hat da jemand vergessen den Array Index anzupassen. Also auf die schnelle konnte ich das Hopping Schema aus Tims Trace nicht mit der Tabelle oben abgleichen, habe da aber auch nur sehr oberflächlich geschaut.
Georg G. schrieb: > Anbei das Schaltbild der Fernbedienung. Es fehlen noch die zwei > Spannungsregler für CPU und RF-Modul und die Bauteilwerte teilweise. Ziemlich interessant. Wenn man die FB mit 6x1.5V Batterien bestückt, dann dienen zwei davon nur dazu den Linearregler aufzuheizen. 4 Batterien könnten also reichen, wenn sie voll sind. Hat schon einmal jemand geschaut, ob am LCD-Port auch Signale ankommen?
Tim schrieb: > Linearregler aufzuheizen Und aus den stabilisierten 5V werden dann zweimal 3.3V gemacht für CPU und RF Modul. Da ist noch reichlich Potential zum Optimieren. Ein LiIon Akku würde ausreichen.
Wenn die Indizes von tx_id korrigiert werden, dann funktioniert der
Algorithmus (siehe unten). Die berechneten Werte stimmen mit den
beobachteten überein.
Zeile 9: "f_row" ist ein Zeiger auf eine Zeile mit 16 Bytes.
Zeile 11: "increment" wird ein 3 Bit Wert zugewiesen.
Zeile 12: "val" bekommt 1 Byte aus der Tabelle plus dem "increment" als
Kanal zugewiesen.
Zeile 15: Dieser wird im Array "rf_channels" abgelegt. Liegt der Kanal
an einer 16er Grenze,
dann wird der Kanal um 3 verringert.1 | static const u8 freq_hopping[][16] = { |
2 | { 0x27, 0x1B, 0x39, 0x28, 0x24, 0x22, 0x2E, 0x36, |
3 | 0x19, 0x21, 0x29, 0x14, 0x1E, 0x12, 0x2D, 0x18 }, // 00 |
4 | { 0x2E, 0x33, 0x25, 0x38, 0x19, 0x12, 0x18, 0x16, |
5 | 0x2A, 0x1C, 0x1F, 0x37, 0x2F, 0x23, 0x34, 0x10 }, // 01 |
6 | { 0x11, 0x1A, 0x35, 0x24, 0x28, 0x18, 0x25, 0x2A, |
7 | 0x32, 0x2C, 0x14, 0x27, 0x36, 0x34, 0x1C, 0x17 }, // 02 |
8 | { 0x22, 0x27, 0x17, 0x39, 0x34, 0x28, 0x2B, 0x1D, |
9 | 0x18, 0x2A, 0x21, 0x38, 0x10, 0x26, 0x20, 0x1F } // 03 |
10 | };
|
11 | |
12 | |
13 | 1 static void set_tx_id(u32 id) |
14 | 2 { |
15 | 3 u8 sum; |
16 | 4 tx_id[0] = (id >> 16) & 0xFF; |
17 | 5 tx_id[0] = (id >> 8) & 0xFF; |
18 | 6 tx_id[0] = (id >> 0) & 0xFF; |
19 | 7 sum = tx_id[0] + tx_id[1] + tx_id[2]; |
20 | 8 // Base row is defined by lowest 2 bits |
21 | 9 const u8 *fh_row = freq_hopping[sum & 0x03]; |
22 | 10 // Higher 3 bits define increment to corresponding row |
23 | 11 u8 increment = (sum & 0x1e) >> 2; |
24 | 12 for (u8 i = 0; i < 16; ++i) { |
25 | 13 u8 val = fh_row[i] + increment; |
26 | 14 // Strange avoidance of channels divisible by 16 |
27 | 15 rf_channels[i] = (val & 0x0f) ? val : val - 3; |
28 | 16 } |
29 | 17 } |
1. Fall
sum = 0x1F + 0xE4 + 0x75; // 0x178 ergibt bei U8 0x78 0111 1000
*fhrow zeigt auf die 0. Reihe
{ 0x27, 0x1B, 0x39, 0x28, 0x24, 0x22, 0x2E, 0x36, 0x19, 0x21, 0x29,
0x14, 0x1E, 0x12, 0x2D, 0x18 }, // 00
"increment" ist 0110 0x06
1 | "val" nimmt nacheinander diese Werte an: |
2 | |
3 | 0x2D, 0x21, 0x3F, 0x2E, 0x2A, 0x28, 0x34, 0x3C, 0x1F, 0x27, 0x2F, 0x1A, 0x24, 0x18, 0x33, 0x1E |
4 | |
5 | Daraus ergeben sich diese "rf_channels" Werte: |
6 | |
7 | 45, 33, 63, 46, 42, 40, 52, 60, 31, 39, 47, 26, 36, 24, 51, 30 |
Davis schrieb: > Die berechneten Werte stimmen mit den > beobachteten überein. Genau. Hatte gestern Nacht das increment falsch bestimmt. Jetzt passt alles. Super, damit ist das Protokoll geklärt. Abschließend frage ich mich noch, wie der Empfänger im Copter das Hopping Schema ermittelt. Also ich meine, am Anfang weiß er ja nicht, welche ID der Sender hat und kennt daher nicht das konkret verwendete Schema. Sobald er die ID kennt, ist ja alles klar. Vermutlich lauscht der zu Beginn auf einem oder mehreren festen Channeln und wartet ab ob dort das "Bind"-Packet vorbeikommt. Dann hat er alle Infos und es kann losgehen. Was meint ihr?
1 | if (bind) { |
2 | flags = FLAG_BIND; |
3 | packet[0] = 0; |
4 | packet[1] = 0; |
5 | packet[2] = 0; |
6 | packet[3] = 0; |
7 | packet[4] = 0; |
8 | packet[5] = 0; |
9 | packet[6] = 0; |
10 | }
|
Philipp E. schrieb: > Vermutlich lauscht der zu Beginn auf einem oder mehreren festen Channeln > und wartet ab ob dort das "Bind"-Packet vorbeikommt. Dann hat er alle > Infos und es kann losgehen. Was meint ihr? Vielleicht kann man ja anhand der Kanalnutzung nach dem Einschalten der FB erkennen, welche Kanäle für das Binding relevant sind?
Es gibt in jeder Reihe einen Kanal 0x18. Also lauscht der Copter nacheinander, jeweils für eine bestimmte Zeit, auf den Kanälen 0x18 bis 0x1F. Ein fester Binding-Kanal wäre auch eine Möglichkeit.
Philipp E. schrieb: > Vermutlich lauscht der zu Beginn auf einem oder mehreren festen Channeln > und wartet ab ob dort das "Bind"-Packet vorbeikommt. Dann hat er alle > Infos und es kann losgehen. Davis schrieb: > Es gibt in jeder Reihe einen Kanal 0x18. Also lauscht der Copter > nacheinander, jeweils für eine bestimmte Zeit, auf den Kanälen 0x18 bis > 0x1F. Damit wäre dann auch das geklärt. Fein. Damit wäre es nun auch möglich den Copter ohne weitere Anpassungen an der Firmware via PC / Smartphone zu steuern. Coole sache...
Wollte mir dann auch mal zwei bis drei der Dinger zu legen. Gibt es einen Link, den ihr aktuell empfehlt? Möglichst billig... Oder lohnt es noch auf diese Sammelbestellung zu warten oder ist das gestorben?
Für die Freunde des Arduino habe ich mal einen ersten, unbeholfenen Entwurf einer Empfangsroutine angehängt die mit meinen Fernbedienungen funktioniert. Erste Spalte ist die Zeit in ms zwischen zwei Reads, danach die payload und der gelesene Kanal. Bei Änderung des Throttle:
1 | 9 FE 00 00 00 40 40 40 AB D5 87 00 00 00 00 00 C5 Hop 15 -> 29 |
2 | 8 FE 00 00 00 40 40 40 AB D5 87 00 00 00 00 00 C5 Hop 0 -> 35 |
3 | 8 FC 00 00 00 40 40 40 AB D5 87 00 00 00 00 00 C3 Hop 1 -> 40 |
4 | 8 F8 00 00 00 40 40 40 AB D5 87 00 00 00 00 00 BF Hop 2 -> 24 |
5 | 4 F5 00 00 00 40 40 40 AB D5 87 00 00 00 00 00 BC Hop 3 -> 58 |
6 | 12 EF 00 00 00 40 40 40 AB D5 87 00 00 00 00 00 B6 Hop 4 -> 53 |
7 | 9 E6 00 00 00 40 40 40 AB D5 87 00 00 00 00 00 AD Hop 5 -> 41 |
8 | 8 E2 00 00 00 40 40 40 AB D5 87 00 00 00 00 00 A9 Hop 6 -> 44 |
9 | 7 DD 00 00 00 40 40 40 AB D5 87 00 00 00 00 00 A4 Hop 7 -> 30 |
10 | 8 D9 00 00 00 40 40 40 AB D5 87 00 00 00 00 00 A0 Hop 8 -> 25 |
11 | 8 D4 00 00 00 40 40 40 AB D5 87 00 00 00 00 00 9B Hop 9 -> 43 |
12 | 8 CD 00 00 00 40 40 40 AB D5 87 00 00 00 00 00 94 Hop 10 -> 34 |
Helmut H. schrieb: >Für die Freunde des Arduino habe ich mal einen ersten, unbeholfenen >Entwurf einer Empfangsroutine angehängt die mit meinen Fernbedienungen Sauber! Dann wissen wir ja schon, wie der RX-Teil der Quadrocopter Firmware aussehen muss. Wenn alle 8ms ein "hop" kommt heisst das, das alle 4ms ein Datenpaket gesendet wird. -> 250Hz. Damit ist der Controller schon gut beschäftigt.
Da das Protokoll ja tatsächlich das V202 Protokoll ist, kann also auch die schon existierende Software genutzt werden. Hier gibt es ein Arduino-Sketch, welches eine V202 Fernbedienung emuliert: https://bitbucket.org/rivig/v202/src/ Download: https://bitbucket.org/rivig/v202/get/c2142a790c46.zip Man benötigt nur ein nRF24L01+-Modul. Die Stickpositionen werden auf den Analogeingängen ausgelesen. Man könnte das aber leicht ändern, um z.B. über die serielle SChnittstelle vom PC aus zu steuern.
:
Bearbeitet durch User
Tim schrieb: > Man benötigt nur ein nRF24L01+-Modul. Die Stickpositionen werden auf den > Analogeingängen ausgelesen. Man könnte das aber leicht ändern, um z.B. > über die serielle SChnittstelle vom PC aus zu steuern. Das ist natürlich super. Das bietet sich doch dann super an, um sich mal mit Motor PWM Werten und so heranzutasten (über den PC Werte senden). Dann kann man mal ein Gefühl für das Verhalten des Teils bekommen. Meiner dürfte übrigens beim Zoll sein, hab schon eine Benachrichtigung bekommen. Die haben wohl nicht geglaubt, dass der steuerfrei eingeführt werden kann hier :(
Das Schaltbild (5 Seiten A4) ist soweit komplett, dass man darauf basierend Software beginnen kann. Wenn ich Zeit habe, werde ich es (in einigen Wochen) komplettieren. Das Eagle File liegt auf Github. Die Lib mit den Spezialteilen kann man sich aus dem Schaltbild per ULP ziehen.
@Georg G: Vielleicht liegt's nur an mir, aber irgendwie verstehe ich nicht, wie man über diese MOxSEN Anschlüsse irgendwas messen soll. Hab mich schon letztens gewundert beim Foto der Platine, ob ich irgendwas falsch sehe, aber hier im Schaltplan sieht's genauso aus.
Wir haben offenbar eine "optimierte Bestückung" erwischt. Ursprünglich waren zwischen MOxSEN und dem dazu gehörenden Drain (vermutlich) Widerstände geschaltet. Damit hätte man dann in den Aus-Phasen der PWM die Generatorspannung des Motors und damit die Drehzahl messen können. Aber im Zuge der Entwicklung wurde das eingespart oder es war eine dumme Idee gewesen oder ...
Leutz, hat keiner einen Link für mich. Würde gerne drei so Dingens bestellen...
Die Umdrehungsgeschwindigkeit wird sicher durch back-emf gelesen.
Haben will schrieb: > Leutz, hat keiner einen Link für mich. Würde gerne drei so Dingens > bestellen... Also diese hier findet man durch eine schnelle ebay-Suche: http://www.ebay.de/sch/i.html?_sacat=0&_from=R40&_nkw=Gyro+2.4GHz+4+6+Axis+Channel+Remote+Control&_sop=15 Im Thread sind auch noch ein paar Links verstreut. Leider sind die Preise inzwischen etwas gestiegen.
Georg G. schrieb: > Wir haben offenbar eine "optimierte Bestückung" erwischt. Ursprünglich > waren zwischen MOxSEN und dem dazu gehörenden Drain (vermutlich) > Widerstände geschaltet. Damit hätte man dann in den Aus-Phasen der PWM > die Generatorspannung des Motors und damit die Drehzahl messen können. > Aber im Zuge der Entwicklung wurde das eingespart oder es war eine dumme > Idee gewesen oder ... Das muss eine Luftadmittanz sein :) Irgendwie ist es aber schon bizarr. Es kann ja schon sein, dass man während der Entwicklung festgestellt hat dass es auch ohne die Sense-Eingänge geht. Aber warum sind dann die Widerstände bestückt, die die ADC-Eingänge mit Masse verbinden?
Tim schrieb: > Wenn alle 8ms ein "hop" kommt heisst das, das > alle 4ms ein Datenpaket gesendet wird. -> 250Hz. Damit ist der > Controller schon gut beschäftigt. Da ist einiges Los over the air. Aber es reicht ja wenn wir auf jedes zweite Datenpacket reagieren. Sobald ein Packet da ist hoppen wir auf den nächsten channel. Dann kommt erstmal noch 1 Paket auf dem aktuellen Channel (davon bekommen wir gar nix mehr mit, ist auch egal, weil das haben wir ja schon) Und dann kommt 1 Paket auf dem nächsten Channel (auf den wir gehoppt sind). Also alle 8 ms ein für uns relevantes Packet -> 125 Hz Weiterhin hat der nrf chip eine interne Queue, so dass es nicht auf jede µs ankommt. Der Remote Task sollte allerdings in jedem Fall alle 8ms mal in die Queue schauen, denn sonst verpassen wir einen Hop und dann ist der Sync hin und wir verlieren erstmal 16 Packete (128 ms), was unter Umständen reicht das Ding zum Absturz zu bringen.
Georg G. schrieb: > Das Schaltbild (5 Seiten A4) ist soweit komplett, dass man darauf > basierend Software beginnen kann. Georg, noch einmal vielen Dank für das Erstellen der Schaltung. Damit kommen wir deutlich weiter. Und Deine Eagle-Künste gehen über die meinigen eindeutig hinaus.
> Im Thread sind auch noch ein paar Links verstreut. Leider sind die > Preise inzwischen etwas gestiegen. Cool. Danke. Dachte ihr kennt die ultimative quelle. Werde dann wohl den: http://www.ebay.de/itm/6-Axis-Gyro-2-4GHz-4-Channel-Remote-Control-RC-Quadcopter-UFO-Helicopter-Blue-/350874671816?pt=AU_Toys_Hobbies_Radio_Controlled_Vehicles&hash=item51b1c29ac8 Ist das der richtige? Will mir so 3 bis 5 von den Dingern shoppen. Aber eine Sammelbestellung gibt es jetzt nicht, oder?
Ja ist der richtige.. Aber kauf lieber erstmal einen... Dann nächste Woche wieder einen... Dann übernächste wieder einen... Sonst lohnt es sich nämlich wegen den Steuern nicht...
Philipp E. schrieb: > Tim schrieb: >> Wenn alle 8ms ein "hop" kommt heisst das, das >> alle 4ms ein Datenpaket gesendet wird. -> 250Hz. Damit ist der >> Controller schon gut beschäftigt. > Weiterhin hat der nrf chip eine interne Queue, so dass es nicht auf jede > µs ankommt. Der Remote Task sollte allerdings in jedem Fall alle 8ms mal > in die Queue schauen, denn sonst verpassen wir einen Hop und dann ist > der Sync hin und wir verlieren erstmal 16 Packete (128 ms), was unter > Umständen reicht das Ding zum Absturz zu bringen. In einer Custom-Firmware könnte man auch auf einen Kanal gehen und die Auto-Ack Funktion verwenden, wie es beim Crazyflie gemacht wird. Dann ist die Verbindung zwar nicht mehr so Störungssicher, aber man bekommt automatisch einen Rückkanal. Hast Du eigentlich auch mal mein Dump nach dem Einschalten durch Deinen Parser geschickt? Dadurch könnte man in Erfahrung bringe, welche Kanäle beim Binding verwendet werden.
:
Bearbeitet durch User
Tim schrieb: > In einer Custom-Firmware könnte man auch auf einen Kanal gehen und die > Auto-Ack Funktion verwenden, wie es beim Crazyflie gemacht wird. Dann > ist die Verbindung zwar nicht mehr so Störungssicher, aber man bekommt > automatisch einen Rückkanal. Ganz genau. So würde ich es auch gerne machen. Ich hatte vor ein paar Beiträgen geschrieben, dass ich persönlich Teile der Crazyflie Firmware verwenden möchte. Vor allem der PC-Client mit dem Rückkanal hat es mir sehr angetan. Damit wird das Entwickeln und Abstimmen von Reglern und Co sicher viel Freude machen. Habe mir als Dongle dazu: http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=300975449625&clk_rvr_id=550780063776 bestellt. Damit wird der Rückkanal ja Pflicht. Channel Hopping geht dann zwar auch, aber so viel zur Robustheit wie aktuell trägt es dann nicht mehr bei. Allerdings fände ich es schön, wenn die Firmware auch weiter die Option (also Compiler Switch o. Ä.) bietet, den beiliegenden Receiver zu verwenden. Aber das Protokoll ist ja nun bekannt. Tim schrieb: > Hast Du eigentlich auch mal mein Dump nach dem Einschalten durch Deinen > Parser geschickt? Dadurch könnte man in Erfahrung bringe, welche Kanäle > beim Binding verwendet werden. Ne, das wollte ich aber noch tun. Wollte aber vorher fragen, ob die Traces soweit vollständig sind. Wie war der Status als das Logging gestartet wurde und wie als es Endete? Also für das File: SPI traffic during binding.txt Vorher: Copter und RC angeschaltet, nichts gedrückt? Nachehr: Binding abgeschlossen?
Georg G. schrieb: > Das Schaltbild (5 Seiten A4) ist soweit komplett, dass man darauf > basierend Software beginnen kann. Danke Georg! Großartige Arbeit!!!
Philipp E. schrieb: > Ganz genau. So würde ich es auch gerne machen. Ich hatte vor ein paar > Beiträgen geschrieben, dass ich persönlich Teile der Crazyflie Firmware > verwenden möchte. Vor allem der PC-Client mit dem Rückkanal hat es mir > sehr angetan. Damit wird das Entwickeln und Abstimmen von Reglern und Co > sicher viel Freude machen. Habe mir als Dongle dazu: > > http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=300975449625&clk_rvr_id=550780063776 > > bestellt. Damit wird der Rückkanal ja Pflicht. Channel Hopping geht dann > zwar auch, aber so viel zur Robustheit wie aktuell trägt es dann nicht > mehr bei. So ein Dongle habe ich auch. Wir sollten uns tatsächlich mal Gedanken machen, wie man das ganze strukturiert angeht. Mein Vorschlag wäre, in Stufen vorzugehen. Das hat auch den Vorteil, dass man sich die Arbeit besser teilen kann. 1) Firmware für das Dongle entwickeln, welche einen unmodifizierten Copter steuern kann. Dazu könnte man auf das Arduino-Sketch von oben aufsetzen. Man könnte hier mit RS232+AVR+nRF24L01 gleich in Ansi-C loslegen und den Code später auf SDCC und 8051 portieren damit er auf dem Dongle läuft. 2) Endlich den Copter entsperren (Das BU-link müsste langsam mal angekommen) 3) Eine bestehende Firmware auf den Copter portieren und für das V202 Protokoll adaptieren. Eine Möglichkeit wäre Bradwii (http://www.rcgroups.com/forums/showthread.php?t=1922403) von der es bereits einen ARM-Port gibt. Wenn man einige Optionen nicht mitcompiliert passt die Firmware bereits jetzt in 16kb. 4) Dongle und Firmware an neues Protokoll anpassen. Firmware mit Rückkanal optimieren. 5) Die Copter HW erweitern.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.