Ich habe heute einen "6 Axis Channel Remote Control RC Quadcopter" bekommen, den es momentan sehr billig auf ebay gibt: http://www.ebay.com.au/itm/Gyro-2-4GHz-4-6-Axis-Channel-Remote-Control-RC-Quadcopter-UFO-Helicopter-Blue-/350820057796 Da der Akku eine Weile laden musste, habe ich ihn natürlich erst einmal auseinandergenommen :) Ich hatte eigentlich ein paar vergossene ICS (China-Blob) und nicht nachvollziehbare Elektronik erwartet, bin aber überrascht worden. Bilder anbei. Bisher habe ich folgende Bauteile identifizieren können: * Invensense MPU6050 - 6 Achsen intertialsensor * Nuvoton Mini54ZAN - Cortex-M0 MCU mit 16kb flash und 2kb SRAM, SWD * Beken BK3423 - 2.4 Ghz tranceiver, anscheinend voll kompatibel zum nrf24L01 Netterweise ist sogar der SWD-Port herausgeführt. Damit müsste sich doch etwas anfangen lassen? Hat jemand dieses Controllerboard schon einmal gesehen? Gibt es dafür evtl. frei verfügbare Firmware, die man verändern könnte?
Der MPU6050 ist übrigens der gleiche Sensor, der auch in high-end Smartphones, wie z.B. Galaxy S4, verwendet wird...
Ich hab auch mal einen bestellt, so ein paar nrf24L01 Module hab ich auch noch rumliegen und SWD Debugger sowieso. Mal sehen wie er sich macht und zu Weihnachten wird er dann weiter verschenkt.
Is ja echt nen schickes schnuckeliges Teilchen. Das nenn ich mal spartanische Beschaltung :-) Wirklich nur das notwendigste drin. Aber irgendwie vermisse ich die Freilaufdioden bei den Motoren. Oder sind die da drauf gelötet ? Wie verhält sich das Teil denn im Flug ? Also programmieren lassen dürfte sich das Teil bestimmt (würd ich einfach mal so schätzen). Wär nen echt interessantes Spielzeug. Bin mal gespannt auf diesen Thread :-)
Moin, dieser kleine Quadrocopter ist im Original als Hubsan X4 bekannt. Im Original besitzt die Funke ein LCD. Dort kann man dann Reaktionszeiten usw. einstellen. Eine alternative Firmware gibt es dafür nicht. Gruß Kay
Kay, Du hast recht, es handelt sich um einen Hubsan X4 Nachbau. http://www.rcgroups.com/forums/showthread.php?t=1892499 Der X4 verwendet ein anderes PCB mit zwei 3-Achsen sensoren und einem anderen Tranceiver (A7105). Erstaunlich, dass der billigere Clone die modernere Hardware verwendet!? Beim Hubsan X4 ist der SWD-Anschluss auch nicht so bequem herausgeführt. Für den Hubsan X4 ist anscheinend das Protokoll der Fernbedienung reverse-Engineered worden: http://www.instructables.com/id/Easy-Android-controllable-PC-Interfaceable-Relati/ Zur Firmware habe ich nach intensiver Suche wirklich nichts finden können. In der RC-Community verwendet man gerne fertige Controller-Boards (Multiwii), es will sich wohl keiner mit den Controllern selbst auseinandersetzen :)
Rene, das Bauteil A476 könnte zusammmen mit den Substratdioden der n-channel Mosfets (G2301) die Freilaufdioden bilden. Ansonsten ist die Beschaltung wirklich minimal. Die Motoren werden direkt aus dem Akku gespeist, ohne dass es eine Rückkoppelung zum Ladestand zu geben scheint. Daher verändern sich die Flugeigenschaften mit der Zeit. Das Ding fliegt sich wirklich gut. Sogar deutlich besser als der zigmal teurere Opensource Crazyflie, der eine recht ähnliche Hardware verwendet (MPU6050 mit Cortex M3). Vas, Versand hat bei mir 4 Wochen gedauert.
Rechts scheint noch ein Serieller Port herausgeführt zu sein. Die Anschlüsse führen zu den RX und TX pins des MCUs.
Tim . schrieb: > Der X4 verwendet ein anderes PCB mit zwei 3-Achsen sensoren und einem > anderen Tranceiver (A7105). Erstaunlich, dass der billigere Clone die > modernere Hardware verwendet!? Beim Hubsan X4 ist der SWD-Anschluss auch > nicht so bequem herausgeführt. Da der Clone nach dem Hubsan kam ist es ja verständlich das dort auch die aktuellere Hardware verwendet wird. Tim . schrieb: > Zur Firmware habe ich nach intensiver Suche wirklich nichts finden > können. In der RC-Community verwendet man gerne fertige > Controller-Boards (Multiwii), es will sich wohl keiner mit den > Controllern selbst auseinandersetzen :) Die meisten Hubsan oder Clone besitzer sind keine Programmierer. Deswegen werden vorhandene Multiwii Boards eingesetzt. Bei meinem aktuellen Projekt: LittleOktoPussy ( 8x Hubsan Motoren in Koax Bauweise ) setze ich auch die Multiwii Software ein, weil das schneller zum Erfolg führt und sich die Software bewährt hat. Der Rahmen wird gerade in einem 3D Drucker gedruckt. Gruß Kay
Hier für unter 20EUR auf Aliexpress http://www.aliexpress.com/item/Newest-6-Axis-Gyro-2-4GHz-4-Channel-Remote-Control-RC-Quadcopter-UFO-Helicopter-Kids-Toy/1045781270.html
Habe mir auch einen bestellt. Mal schauen was man damit anstellen kann (zumindest fliegen sollte das teil ja können :)) Tim hast du den schon mal an einen SWD ran gehangen? Kann man die Firmware auslesen (um die nach dem Basteln/Kaputt machen wieder drauf zu bekommen)? Eventuell kommt ja mit der original-Firmware auch schon was aus dem UART...
Also wenn du du dich einarbeitest könntest du locker die Paparazzi firmwar dafür verwenden. http://paparazzi.enac.fr/wiki/Main_Page Das projekt ist eh schon für locker 10 verschiedene verschiedene Boards ausgelegt, allerdings wird das nadelöhr wohl der support vom MCU. Fertig unterstützte Cortex m0 boards gibts bei dem Projekt noch ned.
Hab' mir auch mal einen (eigentlich 2) bestellt. Was denkt Ihr - ob das Teil eine einfache Kamera mitnehmen kann ? Würde damit zu gerne ein paar Luftaufnahmen z.B. unseres Hauses machen. Und winzige Kameras mit äusserst geringem Gewicht sind ja auch zu haben.
Martin Schröer schrieb: > Hab' mir auch mal einen (eigentlich 2) bestellt. > Was denkt Ihr - ob das Teil eine einfache Kamera mitnehmen kann ? > > Würde damit zu gerne ein paar Luftaufnahmen z.B. unseres Hauses machen. > Und winzige Kameras mit äusserst geringem Gewicht sind ja auch zu > haben. In der aktuellen c't Hacks steht, dass der Copter eine Keycam tragen kann, obwohl große Höhen damit nicht zu erreichen sind.
Ebenfalls mal bestellt, mal sehen wie lange das dauert. Woran hängt denn die erreichbare Höhe? Und wieviel macht die Kamera vom Gesamtgewicht aus?
qq schrieb: > Woran hängt denn die erreichbare Höhe? "Die Kette bricht stets am schwächsten Glied", sagt der Volksmund. Der Luftdruck (Wetterlage) bestimmt die absolut erreichbare Höhe. Die Akku-Kapazität und die Funk-Reichweite die relative Höhe vom Startpunkt. Das "schwächste Glied" dürfte die Funk-Reichweite sein. Tim. schrieb: > anscheinend voll kompatibel zum nrf24L01 Das wär' ja nicht übel, aber der nrf24L01 macht m.E nur 0dBm. "Bluetooth class 1" hingehen 20dBm. Die Reichweite wäre also nur etwa ein Zehntel von Bluetooth, im Freien also ca. 10m. Oder kommt die Fernbedienung weiter? @cpldcpu: Probiere das doch bitte mal aus. Bei meinem Helikopter-Projekt habe ich aus o.g. Grund erstmal "Bluetooth class 1" genommen. Nrf24L01 wäre aber auch nicht schlecht.
:
Bearbeitet durch User
Torsten C. schrieb: > Oder kommt die Fernbedienung weiter? @cpldcpu: Probiere das doch bitte > mal aus. Bei meinem Helikopter-Projekt habe ich aus o.g. Grund erstmal > "Bluetooth class 1" genommen. Nrf24L01 wäre aber auch nicht schlecht. Habe das Ding bisher nur im Zimmer ausprobiert. Da reicht die Entfernung. Allerdings haben sowohl Fernbedienung als auch Controllerboard nur eine recht einfache Antenne, ich glaube nicht dass man damit all zu weit kommt. Bin bisher noch nicht dazu gekommen, etwas an den SWD-Port anzuschließen, da ich im moment verreist bin.
Habe mir auch mal einen bestellt. Was ist denn da für ein Akku drin und wo bekommt man den? Bei einer Laufzeit von gerade mal 8 Minuten und 30 Minuten Ladezeit sollte man lieber ein paar mehr zur Hand haben.
Oliver Stellebaum schrieb: > Habe mir auch mal einen bestellt. > Was ist denn da für ein Akku drin und wo bekommt man den? > Bei einer Laufzeit von gerade mal 8 Minuten und 30 Minuten Ladezeit > sollte man lieber ein paar mehr zur Hand haben. Bei Ebay einfach "Hubsan Akku" eingeben.
Muss man den Copter irgendwie an die Fernbedienung anlernen? Ich habe nach dem Auspacken schnell mal geschaut ob der auch geht und es ging auch alles. Nachdem ich den akku dann voll geladen habe, blinken zwar die LED's am Modell, aber er reagiert nicht auf die Fernbedienung. Die aber blinkt und piept bei jedem Kommando und sonst habe ich auch nix verändert
Auf ebenen Untergrund legen, nach ein paar Sekunden blinkt er langsamer, dann den linken Steuerhebel einmal hoch und wieder runter.
hier ein Bild des Senders die Aussenantenne ist nur Verarsche, genauso wie die Angaben des Verkaeufers tonsee_mall (Artikel bezahlt am 22 Sep., versendet am 29 Sep., von wegen Versand am naechsten Tag und der Verk. erzaehlt 'Maerchen' auf nachfrage) vlG Charly
g Und dann gibts da bestimmt Leute, die in irgendwelchen Foren behaupten man müsse die Antenne so oder so drehen, damit die Reichweite besser ist :D Irgendwo müssen die halt sparen, damit die das ding für 20€ verticken können. Immerhin nicht nur ne PIFA (auch wenn die nicht unbedingt schlecht sind)
:
Bearbeitet durch User
Der "Original" Hubsan X4 hat in der Fernsteuerung nur eine PIFA... Da ist der Clone wohl sogar noch überlegen :)
kann bzw muss man das Ding irgendwie kalibrieren? Beim Hubsan wir ja in einigen Foren geschrieben, das man ja nicht die Trimmung verwenden soll, sondern das teil immer mal wieder neu kalibrieren muss. meiner kam vor 2 Tagen an, jedoch hatte einer der Motoren einen Defekt und funktioniert nicht richtig. Bin mal gespannt wie es mit dem Umtausch aussieht, bzw einem Ersatz.
:
Bearbeitet durch User
hab eben gesehen, da sind ueber 1000st verkauft, verutlich kommen die deswegen immer spaeter weil die kein nachschub beibekommen ich hab mir noch einen hier bestellt: 190881964364 ist nur 3 Cent teurer, wird aber vermutlich scheller geliefert vlG Charly http://www.ebay.de/itm/6-Axis-Gyro-2-4GHz-4-Channel-Remote-Control-RC-Quadcopter-UFO-Helicopter-Blue-/190881964364?pt=AU_Toys_Hobbies_Radio_Controlled_Vehicles&hash=item2c7173a14c
:
Bearbeitet durch User
Martin J. schrieb: > jedoch hatte einer der Motoren einen Defekt Das ist ja schade, aber mein "Beileid" hilft Dir leider auch nicht. Viel Erfolg bei der Reklamation. Für meinen hatte ich vorgestern 'ne Benachrichtigung im Briefkasten (Nachnahme per ebay). Heute abgeholt und mit meinem Sohn (10 Jahre) zusammen ausprobiert. Wir hatten Glück und sind beide begeistert. Der Z-Gyro (Gierwinkel) ist ja super präzise. Von dem MPU6050 hatte ich trotzdem mehr erwartet. Beim Steuern verliert er an Höhe, da kann man sicher noch einiges an der Firmware "schrauben". Die Accel_Z scheinen die gar nicht auszulesen. Ich überlege immer noch, ob ich mir so ein Projekt ins Haus hole und noch einen zweiten bestelle. Hat schon einer von Euch konkrete Ambitionen in dieser Richtung? Ach ja: Ersatzakku muss sein, die Flugzeit ist ja wirklich kurz.
:
Bearbeitet durch User
Torsten C. schrieb: > Ersatzakku muss sein Ich habe diese bestellt: 380mAh, 2,31€/Stück http://www.aliexpress.com/item//1135685083.html Ich hoffe, dass die Gewichtsverteilung bei den größeren Akkus paßt, das Akkufach scheint ja groß genug zu sein, der mitgelieferte Akku füllt das Akkufach ja nicht ganz aus.
Habe meinen jetzt auch ausgiebig getestet uns muss sagen: Die Hadware ist echt super aber die Firmware hat einige Bugs: Nach harten Beschleunigungen scheint der 'QC dekalibriert, will imme völlig zufällig abhauen. Nachdem man einmal gegengesteuert hat fängt er sich wieder und alles wird wieder normal. Außerdem Scheint der Roll und Nickwinkel den Schub nicht zu beinflußen. Deshalb sinkt er natürlich beim Manöver fliegen... Das kann die Multiwii firmware besser... Die gibts aber leider nur für Atmegas....
Vielen Dank Hubsi! Lag zusätzlich noch daran, das wohl noch die Trimmung der fernbedienung komplett verstellt war
Lieferung von tonsee_mall kam heute bei mir an, bestellt am 22. Versand laut Tracking am 23. Dummerweise ist ein Arm angebrochen und der Motor drin kaputt. Ich hab den Verkaeufer angeschrieben, mal sehen was passiert. Sonst gibt es hier: http://www.tmart.com/search.html?q=385 Ersatzteile, hab mal was bestellt und bin gespannt wann es ankommt. Sind die Motoren Verbrauchsmaterial oder hab ich meine schlecht behandelt?
Bei mir ist nach etlichen Crashs auch ein Motor kaputt gegangen. Scheint verbrauchsmaterial zu sein.
Hätte ich das mal früher gewusst, so hielt der Spaß nur 15 Minuten und jetzt wieder drei Wochen Versandspaß :)
Tim . schrieb: > Bei mir ist nach etlichen Crashs auch ein Motor kaputt gegangen. Oh, da habe ich Sohnemann nochmal geimpft: Keine Crashs mehr! 30g Nutzlast kann er (wegen des Bodeneffekts) gerade so anheben, aber mit 28..29g gewinnt er sogar Höhe, mit vollem Akku.
Torsten C. schrieb: > Hat schon einer von Euch konkrete Ambitionen in dieser Richtung? PS: Wenn wir es schaffen, 'ne neue Firmware zu machen, würde ich gern 'ne Kamera einbauen. Ich habe bei Aliexpress für 5€/Stück drei Nokia-Lumia-Kameras auf "gut Glück" gekauft. Ich habe noch keine Ahnung, wie die Pinbelegung ist. Hoffentlich wenigstens DCMI. Die wäre optimal, um sie unter den den Quadkopter zu kleben. Der 24-Pin-Steckverbinder im Bild hat 0,4mm-Pitch. Ich werde dazu mal einen Extra-Thread starten, wenn ich erste Erkenntnisse habe.
Ich habe zeitgleich auch eine Cam bestellt, erstmal was ganz billiges (Ebay: 141019163321) Wenn man das Ding entbeint könnte man vielleicht was erreichen. Neue Firmware programmieren ist interessant, aber wie? Erstmal die PINs finden und was für ein Interface braucht man dafür?
Oliver Stellebaum schrieb: > Ich habe zeitgleich auch eine Cam bestellt, erstmal was ganz billiges > (Ebay: 141019163321) Die Dinger hat Conrad mal für richtig viel Geld vertickt.. Am Quadcopter hat diese Kamera bei mir kein gutes Ergebnis geliefert, das Bild "wobbelt" stark. Am Readyset Spielzeugfluggerät hatte ich mal so eine: http://www.ebay.de/itm/camera-Kamera-Parts-Ersatzteile-fur-WLToys-V959-16-RC-Quadcopter-UFO-/181224819804?pt=RC_Modellbau&hash=item2a31d74c5c. Die Videos waren ziemlich gut. Leider etwas teuer. Und man müsste probieren wie man die ansteuern muss. War bei meinem Quaddi mit einem dreipoligen Kabel direkt mit der FC verbunden.
Oliver Stellebaum schrieb: > was für ein Interface braucht man dafür? Ich habe (noch) keine Ahnung. Wenn ich weiss, wonach ich suchen muss, würde ich mich mal wie beim Oszi-Componententester mit niedrigen Strömen langsam an die 24 Pins heran tasten. Siehe Beitrag "Handy-Kamera: Welche Schnittstelle?" Ich gebe mir mal 'ne 20%-Chance. Aber ein Versuch ist es m.E. Wert.
Ist es möglich an den motor anschlüssen brushless motortreiber und motoren zu hängen ? Oder fliegt der dann nicht mehr gut ? Da liegen ja spannugen von 0-3,7 V an
Torsten C. schrieb: > Ich gebe mir mal 'ne 20%-Chance. Dieses Forum ist echt gut (also einige spezielle Mitglieder). Inzwischen bin ich bei 80%. Turbonator schrieb: > brushless motortreiber Klar, aber BLDC sind viel schwerer. Dann musst Du auch neue Propeller berechnen. Und die sind dann viel größer. Dann brauchst Du ein anderes "Gehäuse" usw. Außerdem wäre es sinnvoller die Spannung vor dem DAU digital "abzugreifen", als die 0..3,7V auszuwerten. Was hast Du vor? PS: Wobei: Gibt es Quadkopter mit sich überlappenden Propellern? Also einfach in zwei oder vier Ebenen?
:
Bearbeitet durch User
Ich hatte vor das ganze zu vergrößern motor , Rahmen, usw. Dann noch einen 7,4 oder 11,1 volt akku benutzen , extra platine die versorgt die orginal platine mit 3,7 Betriebsspannung worauf dann auch der regler sitzt . Spinnereien halt :)
Das es dann nicht mehr gut fliegt habe ich gefragt weil ich mir gedacht hab das der quadrocopter vieleich umkippt im flug wegen dem anderem leistungs Verhältnis ( motorleistung, gewicht ) oder trägheit (ms)der treiber ... ich hab keine ahnung deshalb die frage an jemand mit ahnung . Sehr interessant morgen bestell ich mir auch eins
Turbonator schrieb: > Ich hatte vor das ganze zu vergrößern Die Idee ist nicht übel, aber ich denke, man tut sich keinen Gefallen damit. Alle Regel-Parameter sind auf die Hubsan-Physik ausgelegt. Um neue Firmware wirst Du nicht herum kommen. Torsten C. schrieb: > mit sich überlappenden Propellern? Ich meine so, wie im Bild. rot: obere Ebene, rehts drehend blau: untere Ebene, links drehend grün: Platine Zur Platine: Nix in der Mitte, dafür sind Elektronik, Akkus und Kameras im "Windschatten" unter den Motoren. Also nicht so wie hier in der Mitte: http://1.bp.blogspot.com/-rWZ62wg3CaY/TqgxZbDMUvI/AAAAAAAAAAY/RhV3H7Ri2vA/s1600/parts.JPG Alternativ: Der Quadkopter fliegt auf dem Kopf, damit der GPS-Empfänger freie Sicht hat. Wegen des Off-Topic-Risikos: Wohin weichen wir aus? Brauchen wir einen neuen Thread? PS: Oder noch besser: Die roten Propeller oben (Kameras unter den Motoren) und die blauen unten (GPS-Empfänger über den Motoren). PPS: Das Kreuz in der Mitte ist kein FR4 sondern das sind Kupferdrähte aus Hausnsinstallationskabeln, um die LiPos über und unter den Motoren ohne großen Spannungsabfall in Reihe zu schalten. Dazu SDA und SCL, um Informationen zwischen den vier Platinen auszutauschen.
:
Bearbeitet durch User
Deine idee hab ich so verstanden das die gegenüberliegenden entweder oben oder unten liegen . Hat bestimmt einen komischen schwerpunkt und bei einem Absturz sieht es für die motoren/popeller die richtung unten angebracht schlecht aus , wahrscheinlich falsch verstanden .
Turbonator schrieb: > wahrscheinlich falsch verstanden Nö. Ich bin halt so: Nix ist selbstverständlich. Turbonator schrieb: > Hat bestimmt einen komischen schwerpunkt Der liegt in der Mitte - so oder so. Turbonator schrieb: > bei einem Absturz sieht es für die motoren/popeller die richtung unten > angebracht schlecht aus Meine Beobachtung ist: Für die oberen Propeller (andere kenne ich bisher nicht) sieht es auch nicht gut aus. Oft landet das Teil auf dem Kopf.
Ok hast recht ist wie mit dem Marmeladenbrot oben sind die motoren deswegen fällt der auf die popeller . Ich meinte mich selber mit der Aussage : warscheinlich falsch verstanden . 80% mit kamera was heißt das ? ich muss erst ab 22 € mit dem zoll aufpassen oder ?sry wegen dem offtopic
Turbonator schrieb: > 80% mit kamera was heißt das ? Das Zitat sagt alles: Dominic A. schrieb im Beitrag "Re: Handy-Kamera: Welche Schnittstelle?": > Ich dachte immer das es zur MIPI Schnittstelle sogut wie gar keine > öffentliche Dokumentationen gibt... Bis zu Frank seinem Post. Nun bin ich optimistischer.
:
Bearbeitet durch User
@Turbo: Korrekt, 22€ sind die Freigrenze ohne Einfuhrsteuer, mehr als 22€ bis 150€ kostet 19% Einfuhrsteuer und ab 150€ kommen tatsächlich Zölle drauf. Zu beachten ist, dass es dabei immer um die Summe inklusive Versand geht. Die 80% mit Kamera, damit meinte Thorsten wohl, dass er sich selbst eine 80%ige Chance gibt, die vom ihm gekaufte Lumia-Kamera an's Laufen zu bringen. Das würde mich übrigens auch sehr interessieren. @Thorsten C: Ein Offtopic-Risiko sehe ich hier (noch) nicht. Was Ihr Euch überlegen solltet, ist, dass Ihr bei diesen massiven Änderungen, also neue Motoren, neuer Akku, damit auch neue Rotoren, wahrscheinlich neuer Rahmen, aber in jedem Fall wohl neue Firmware am Ende nur noch die Fernbedienung im Originalzustand behalten werdet. [Und wegen neuer Firmware - s.o. - wird die wohl auch noch überarbeitet werden müssen.] Da macht es doch schon eher Sinn, gleich einen Quad komplett neu zu entwerfen, oder ? [Und in diesem Falle wäre so ein Thema dann auch zu viel für diesen Thread.] ----- Ihr - und wenn das Paket endlich ankommt, auch wir - besitzen doch alle den Hubsan-Klon, bzw. beabsichtigen, uns einen zuzulegen. Vielleicht sollten wir uns zunächst auf kleinere Modifikationen und Tests an dem Hubsan verständigen, um so Ideen und Erfahrungen zu sammeln; diese könnte man dann schlussendlich in einem eigenen Projekt zwecks Neubau eines Quads umsetzen. Ich habe hier gestern Abend erst recht erfolgreich eine einfache Funkschaltung mit RFM12 Modulen aufgebaut - und war recht angetan, wie weit und zuverlässig diese Module funktionieren. [Ich hatte den Sendeteil im Haus am Labornetzteil und bin wie ein Irrer mit dem Empfangsteil (vom 9V Block gespeist) durch unsere Siedlung gelaufen - um halb drei nachts :) Ich kann nur hoffen, dass mich keiner unserer Nachbarn mit dem wild grün und blau blinkenden Ding gesehen - oder wenigstens nicht erkannt hat :P ]
Martin Schröer schrieb: > Da macht es doch schon eher Sinn, gleich einen Quad komplett neu zu > entwerfen Zustimmung, so meinte ich das ^^. Martin Schröer schrieb: > Ich habe hier gestern Abend erst recht erfolgreich eine einfache > Funkschaltung mit RFM12 Modulen aufgebaut - und war recht angetan, wie > weit und zuverlässig diese Module funktionieren. Das klingt gut, aber verstanden habe ich es noch nicht: Meinst Du die mitgelieferte Ferbnbedienung oder andere Module? Torsten C. schrieb: > Das wär' ja nicht übel, aber der nrf24L01 macht m.E nur 0dBm. Wieviel dBm hatten diese Module ggfs.?
Timmo H. schrieb: > 0dBm die nRF und die Beken machen eigentlich 5dBm OK, wie erwartet. Ich will ja nicht penetrant sein aber: Wie weit und zuverlässig funktionieren diese Module nachts um halb drei, also wieviele Meter?
Mit den 0dBm kommst du etwa 30-40m Freifeld und PIFA, mit den 5dBm etwa 80-100m. Eigentlich sind die recht genial die dinger. Für 1€ bekommt man die nRF module. Und inzwischen für 4€ die nRF24L01+ mit LNA und PA (damit kommt man dann mit der mitgelieferten Dipolantenne auf ~1000m bei 20dBm)
:
Bearbeitet durch User
Timmo H. schrieb: > inzwischen für 4€ die nRF24L01+ mit LNA und PA Cooool. :-) Kannst Du den Link bitte mal im Beitrag "China SUPER Bauteile-Schnäppchen Thread" posten? Ich bin nicht unter 4,40€ gekommen: http://www.aliexpress.com/item//1372071825.html
Naja hab etwas untertrieben sind 4,42€ http://www.aliexpress.com/item/NRF24L01-PA-LNA-Wireless-Module-with-Antenna-1000-Meters-Long-Distance-FZ0410-Free-Shipping-Dropshipping/782032049.html Vor etwas über ein Jahr müsste ich noch $15/ Stück blechen.
:
Bearbeitet durch User
Timmo H. schrieb: > Vor etwas über ein Jahr müsste ich noch $15/ Stück blechen. Ich schlockere auch nur noch mit den Ohren. Ein Wahnsinn! Ich habe eben das 5er-Set bestellt.
Der Quadcopter scheint generell unter dem Namen "JXD 385" bekannt zu sein. http://www.rcgroups.com/forums/showthread.php?t=1987864 Dort hat auch jemand das Ding mit einer Kamera ausgerüstet. "Y3000": http://www.aliexpress.com/item/Free-shipping-THE-World-s-Smallest-1280-720P-mini-Video-Recorder-High-Definition-Camera-support-32/825597460.html Hersteller ist Jin Xing Da. Die Website scheint nicht auf dem neusten Stand zu sein: http://www.jxdtoys.com/en/aboutus.asp
So, die Frage ist nun, ob und wie man neue Firmware auf den Controller bekommt? Hier ein paar Links zum MINI54ZAN: http://www.keil.com/dd/chip/6142.htm http://www.nuvoton.com/NuvotonMOSS/Community/ProductInfo.aspx?tp_GUID=5dbf7d7a-b6df-4fe1-91c9-063449500ce7 http://www.nuvoton.com/NuvotonMOSS/Community/ProductInfo.aspx?tp_GUID=ca35dc89-c740-421a-b13b-5a8d050315e3 Die Beschaltung des Controllers ist recht einfach (siehe Bild): Der MPU6050 hängt am I2C Port, der BK2423 am SPI. UART und SWD sind herausgeführt. Die Datenblätter die wichtigsten Bauteile habe ich angehängt. Korrektur zum Bild: Die Spannungsregler sind für 3V, nicht für 3.3V ausgelegt. Macht bei einem 3.7V Akku auch mehr Sinn.
:
Bearbeitet durch User
Aus der Featureliste
1 | Core |
2 | ARM® Cortex™-M0 core running up to 24 MHz |
3 | One 24-bit system timer |
4 | Supports low power Idle mode |
5 | A single-cycle 32-bit hardware multiplier |
6 | NVIC for 32 interrupt inputs, each with 4-level priority |
7 | Supports Serial Wire Debug (SWD) with 2 watchpoints/4 breakpoints |
8 | Built-in LDO for Wide Operating Voltage Range: 2.5V to 5.5V |
9 | |
10 | Memory |
11 | 4KB/8KB/16KB flash memory for program memory (APROM) |
12 | Configurable flash memory for data memory (Data Flash) |
13 | 2KB flash memory for loader (LDROM) |
14 | 2KB SRAM for internal scratch-pad RAM (SRAM) |
15 | In-System Programming (ISP) and In-Circuit Programming (ICP) |
SWD wird supported. Nur wie lässt sich diese Port nutzen, um die Firmware auszulesen? Die Neuprogrammierung per ISP scheint sich etwas komplexer zu gestalten. Die Controller hat einen dedizierten Flash-Bereich für den Bootloader (LDROM). Allerdings scheint es keinen fest vorgegebenen Bootloader zu geben, sondern der Benutzer kann diesen festlegen. Der Herausgeführte serielle Port deutet darauf hin, dass ein Bootloader installiert sein könnte. Nuvoton hat netterweise die Referenzimplementierung der ISP-Tools ins Netz gestellt: http://www.nuvoton.com/NuvotonMOSS/Community/ProductInfo.aspx?tp_GUID=4b47b09d-b116-4ccd-aa85-31e261a87d30
:
Bearbeitet durch User
Das ISP-Tool sieht ziemlich nützlich aus. Leider lässt sich damit die Firmware nicht auslesen:
1 | There is no way to use this ISP Programming Tool to dump the MCU‟s APROM no matter the MCU chip is locked or |
2 | un-locked. So, the data security of APROM is ensured. For DataFlash, however, it is not easy to be protected |
3 | because it can be dumped by executing a program residing in APROM, which may be the user‟s program or a |
4 | malicious program. (Note accessing DataFlash is a normal function when MCU runs in APROM.) The hacker can |
5 | use this programming tool to program his malicious program in APROM, and then let MCU start to run to dump the |
6 | DataFlash. |
Also lässt sich nur eine neue Firmware schreiben und flashen oder wie ist das ISP-Tool gemeint?
Es muss ein Tool geben, um das AProm zu lesen/verifizieren. Wie sollte man sonst zuverlässig programmieren? Und ohne die originale Firmware lesen zu können, macht es wenig Spaß. Schließlich möchte man notfalls den Rückweg antreten können, wenn die eigene Soft nicht fertig wird.
Es gibt noch andere Programmiermodi: ICP, Gang http://www.nuvoton.com/NuvotonMOSS/Community/ProductInfo.aspx?tp_GUID=4b47b09d-b116-4ccd-aa85-31e261a87d30 Außerdem gibt es noch SWD. Kennt sich hier jemand mit SWD aus? Ist das Protokoll standardisiert? Kann man damit den Speicher lesen?
Aha, mit ICP scheint es zu gehen. Nur dafür benötigt man anscheinend ein USB-Dingle von Nuvoton. Leider finde ich auch gerade die Dokumentation des Protokolls nicht. Im Handbuch gibt es nur Hinweise darauf, dass das Protokoll den SWD-Port nutzt.
1 | 1.1.2 Features |
2 | 1.1.1 In-Circuit programming target chip |
3 | 1.1.2 Backup flash data of target chip (If the target chip is not flash protected) |
4 | 1.1.3 Backup offline flash data |
5 | 1.1.4 Offline programming mode |
6 | 1.1.5 Write software serials number (SN) to target chip |
7 | 1.1.6 Limit the maximum programming count |
Das macht Hoffnung: https://www.youtube.com/watch?v=hL1Q7yYJfOs @Thorsten C: Die RFM12 hatten zunächst nichts mit dem Quad zu tun, da ich immer noch auf die Lieferung warte. Ich hatte diese Funkstrecke nur aus Neugier / Langeweile aufgebaut.
hier gibt es auch das camera Modul extra :) http://www.ebay.de/itm/AMAX-Akku-Battery-Propeller-Motor-LED-Ladegerat-FPV-Kamera-UFO-Drohne-Hubsan-X4-/331000374134?pt=RC_Modellbau&var=540228311869&hash=item4d1128e376
Hast Du zu dem "original" Kameramodul weitere Infos ? Ich konnte weder Daten zur Auflösung, Features oder Gewicht finden, noch listet youtube Beispielvideos. Bis dahin würde ich also eher zur 808 tendieren, die ist zumindest halbwegs "dokumentiert".
:
Bearbeitet durch User
Tim . schrieb: > Hier ein paar Links zum MINI54ZAN … Datenblätter für die > wichtigsten Bauteile habe ich angehängt. Wow, gute Arbeit, danke. Marco schrieb: > camera Modul extra Hier sind noch ein paar mehr Bilder von dem "HX4C": http://www.banggood.com/Hubsan-X4-H107C-RC-Quadcopter-Spare-Parts-Camera-Module-30W-H107-a28-p-86938.html Martin Schröer schrieb: > Das macht Hoffnung Sieht nett aus, aber etwas verzerrt. Wie meinst Du das mit der Hoffnung? Was würdet Ihr denn nehmen, eine "Y3000", das "HX4C" oder die "808"? http://nerdfever.com/?p=1215 Ich denke mal "laut": Preislich nehmen die sich alle nicht viel. Das "HX4C" paßt wohl kaum noch in das Quadkopter-Gehäuse. Die Y3000 hat 'ne gute Auflösung und ein Gehäuse, vieleicht kann man den Akku ausbauen, um Gewicht zu sparen. Wenn die Kamera am Antriebs-Akku hängt, wird dieser zwar stärker belastet, aber da die Propeller weniger Last tragen müssen, dürfte die Flugzeit trotzdem länger sein. @der_nachbauer: Du tendierst zur 808? Die kann man zwar sicher auch am Antriebsakku betreiben, aber die Bildqualität der Y3000 macht auf mich einen besseren Eindruck, weniger Verzerrung. PS: Hat jemand Bilder gefunden, die mit der HX4C gemacht wurden? Oder ist das eine Y3000 ohne Gehäuse? Georg G. schrieb: > Schließlich möchte man notfalls den Rückweg antreten können, wenn die > eigene Soft nicht fertig wird. Wegen der 10€ würde ich mir nicht so viele Gedanken machen: http://www.tmart.com/JXD-385-004-PCB-Board-Receiver-for-RC-Helicopter-Green_p192103.html PS: Hat sich schon mal jemand durch das "CooCox Tech Support Forum" und das "Nuvoton Tech Support Forum" gewühlt? http://www.coocox.org/nuvoton.htm
:
Bearbeitet durch User
So, hab meinen gestern auch bekommen, ist gar nicht so einfach das Ding zu fliegen, jedenfalls nicht in einem beengten Zimmer: https://www.youtube.com/watch?v=Q2mY_YL8R2U
Dein Zimmer ist doch vergleichweise groß, ich habe wesentlich weniger Platz im im Zimmer hier. Du musst beim Gasgeben die Massenträgheit mehr beachten: Alle Reaktionen mit dem Gas dauern etwas und du übersteuerst im Kopf etwas, deshalb fliegt der Kopter immer rauf und runter... immer etwas sensibler und dafür immer etwas abwarten. Nach meiner Erfahrung lässt sich der Copter in der ersten Geschwindigkeitsstufe garnicht fliegen, da selbst bei Vollauschlag zuwenig passiert....
Thorsten, zur 808 tendiere ich nur deswegen, weil es einige Videos - wie z.B. das oben angegebene - von dieser Kamera am Hubsan gibt. Und das begründet auch die Hoffnung, belegt es doch, dass diese Kombination funktioniert, d.h. der Copter fliegt damit noch anständig [hoch]. [Und Stromversorgung aus dem Copter ist da noch nicht einmal gegeben, laut Kommentaren hatte der Macher des Videos beides (Copter && Cam) mit separaten Akkus versorgt. Da wäre also sogar noch Spielraum.] Die Y3000 müsste ich mir mal als Alternative ansehen. [Btw - habt Ihr schon günstige und schnelle (innereuropäsich ?) Bezugsquellen für die Cams gefunden ?] Deine Einschätzung zu der HX4C finde ich herzallerliebst, wird diese Kamera doch von dem entsprechenden shop als "original" Zubehör zum Hubsan vertrieben :)
:
Bearbeitet durch User
Habe grade mal die fb geöffnet: Unten ist ein SPI? Pinheader und ein Auschnitt für ein zusätzliches Display und 4 Buttons, alles unter dem Sticker auf der Vorderseite. Alles gut beschriftet, deshalb könnte ja mal einer mit logic analyzer reinschauen... DEr µC ist von Nuvoton, mit der Bezeichnung kann google aber nix anfangen.
Nils A. schrieb: > Habe grade mal die fb geöffnet: > Unten ist ein SPI? Pinheader und ein Auschnitt für ein zusätzliches > Display und 4 Buttons, alles unter dem Sticker auf der Vorderseite. > Alles gut beschriftet, deshalb könnte ja mal einer mit logic analyzer > reinschauen... DEr µC ist von Nuvoton, mit der Bezeichnung kann google > aber nix anfangen. Schauen nach was? Welche Signale interessieren? Mein Quadcopter ist kaputt und hier liegt ein 10-Euro-Logikanalyzer.
Naja zum vermeindlichen Display geht ein 3 Wire Spi Bus, da könnte man ja mal lauschen, ob der µC versucht das Display anzusteuern... Die Daten und Takt Leitung an diesem Anschluss geht auch zum Funkmodul, dieses hängt also am selben SPi bus. Wenn man diese Daten jetzt Mitloggt und dann reverse Engineert könnte man also recht leicht herausfinden, welche Daten an den Copter geschickt werden und seine eigene Fernsteuerung villeicht auch mit einem AVR oder einen Pc gesteuerten Quadro bauen.
Meiner ist gestern angekommen. Man ist das kompliziert zu fliegen, da muss man echt üben. Schon aus wenigen cm. Höhe knallt er ganz schön auf den Boden. Macht es Sinn unter jeden Fuß ein wenig Sugru zu kneten damit er etwas gefederter aufsetzen kann oder beinträchtigt dies das Gewicht?
> Naja zum vermeindlichen Display geht ein 3 Wire Spi Bus, da könnte man > ja mal lauschen, ob der µC versucht das Display anzusteuern Das Original von Hubsan hat ein Display. Da davon auszugehen ist, dass im Clone die gleiche Software Verwendung findet, sollte auch ein Display unterstützt werden. > Schon aus wenigen cm. Höhe knallt er ganz schön auf den Boden. Macht es > Sinn unter jeden Fuß ein wenig Sugru zu kneten damit er etwas gefederter > aufsetzen kann oder beinträchtigt dies das Gewicht? Ja. Styroporfüßchen.
Oliver Stellebaum schrieb: > Schon aus wenigen cm. Höhe knallt er ganz schön auf den Boden Es gibt - leider noch nicht separat gefunden - in einem Reparaturset einen rundum Rammschutz. Der schont Wände, Möbel und vor allem die Propeller.
Davis schrieb: > Ja. Styroporfüßchen. Habe ich auch gemacht. Schlimmer ist aber ein Kopüber-Aufprall auf die Propeller. Da hatte ich noch leine gute Idee. Ein Propeller hatte sich so weit auf die Achse geschoben, dass der Propeller blockiert hat. Hochziehen hing nur mit zwei Kartoffelschälmessern, die ich als "Schere" angeornet zusammengedrückt habe.
Torsten C. schrieb: > Davis schrieb: >> Ja. Styroporfüßchen. > > Habe ich auch gemacht. Schlimmer ist aber ein Kopüber-Aufprall auf die > Propeller. Da hatte ich noch leine gute Idee. Ein Propeller hatte sich > so weit auf die Achse geschoben, dass der Propeller blockiert hat. Und genau dabei kann es auch die Achse durch den Motor nach unten drücken, dann brauchst du einen neuen Motor.
Torsten C. schrieb: > Achse --> Welle! Torsten C. schrieb: > Hochziehen hing nur mit zwei Kartoffelschälmessern, die ich als "Schere" > angeornet zusammengedrückt habe. Mechanik und handwerkliche Dinge sind nicht deine Freunde. Lass lieber die Finger davon, bevor du dich ernsthaft verletzt.
mudda schrieb: > Mechanik und handwerkliche Dinge sind nicht deine Freunde. Lass lieber > die Finger davon, bevor du dich ernsthaft verletzt. Lass' du mal das mitschreiben hier, das schadet deinen Angststörungen.
Ach Mutti (mudda), was täten wir in unserem Forum nur ohne besserwisserische Gäste, wie Dich. ;-) Ich hatte gehofft, dass vielleicht noch jemand 'ne bessere Idee hat, als Kartoffelschälmesser. Meine Scheren hatten alle einen zu großen Keilwinkel. PS: Für Muttis sind "Angststörungen" ganz typisch, das kenn ich von meiner. ;-)
:
Bearbeitet durch User
Moritz A. schrieb: > Lass' du mal das mitschreiben hier, das schadet deinen Angststörungen. Du konntest es einfach nicht lassen zu antworten, oder?
Torsten, schau mal ob der Prop oben durchgebohrt ist. Dann kannst du die Welle auch mit einer zweiten, etwas dünneren, nach unten ausdrücken. Alternativ mit irgendeinem anderen Gegenstand, Rouladennadel, Eierpiekser, etc..
mudda schrieb: > schau mal ob der Prop oben durchgebohrt ist. Das Brainstorming-Prinzip: Das bringt mich auf den Gedanken, die (normalerweise nicht durchgebohrten) Propeller zu durchbohren, so dass man oben einen Gumminöpsel hineinstecken kann. Das dämpft den Aufprall und ermöglicht ein Entfernen der Propeller, ohne die Motorlager zu belasten. Mein Sohn meinte, man könnte Silikon-Dichtmasse dafür nehmen. Vielleicht hat noch jemand 'ne bessere Idee. Bitte Feedback, falls das hier zu off-topic wird. Turbonator schrieb: > Hat sich schon etwas mir der firmware ergeben ? Was soll sich denn da ergeben? Will die im Ernst jemand disassemblieren? Eine neue (eigene) Firmware kann doch nicht so kompliziert sein, bei den vielen Mikro- und wasweisichwas-Kopter Open-Source-Projekten.
:
Bearbeitet durch User
http://www.aliexpress.com/item/Free-Shipping-Hubsan-H107-H107L-X4-V252-RC-Quadcopter-Parts-Protection-Cover/1337556710.html G. schrieb: > Oliver Stellebaum schrieb: >> Schon aus wenigen cm. Höhe knallt er ganz schön auf den Boden > > Es gibt - leider noch nicht separat gefunden - in einem Reparaturset > einen rundum Rammschutz. Der schont Wände, Möbel und vor allem die > Propeller. ......
Turbonator schrieb: > Hat sich schon etwas mir der firmware ergeben ? Ich habe im Multiwii-Forum einen Thread aufgemacht: http://www.multiwii.com/forum/viewtopic.php?f=22&t=4155 Die Antworten sind noch etwas mager, aber anscheinend hält man es nicht für aussichtlos, MultiWii auf den MINI54ZAN zu portieren. Bleiben also noch ein paar Schritte: - Protokoll der Fernsteuerung reverse-engineeren (Dazu gibt es zum Hubsan X4 schon einiges) - Die Hardware komplett entflechten (Ist wohl das kleinste Problem) - Coocox für Nuvoton in Betrieb nehmen. - Lernen wie man den Controller über den Bootloader neu flashed. - Multiwii auf Cortex M0 portieren und für die neue Umgebung konfigurieren. - Multiwii an den BK2423 anpassen. Alternative: - Kann man über SWD die original Firmware auslesen? - Wenn ja: Original-Firmware auslesen und recompilieren.
Torsten C. schrieb: > Was soll sich denn da ergeben? Will die im Ernst jemand disassemblieren? Ist doch die frage ! In was für einer programmier Sprache ist das wohl geschrieben? Ich kenn mich nur ein wenig in asm pic aus.
Davis schrieb: > Ja. Styroporfüßchen. Ich habe meinem 4 Gummideämpfer verpasst die mit einem Standart RC-Servo geliefert wurden. Passen genau unter die Motoren.
Warum Multiwii? Warum nicht lieber ein fertiges für ARM? Openpilot bzw. Taulabs? Oder eines der vielen anderen?
Die Fernbedienung hat auf der Rückseite eine Portbeschriftung. S11 und S12 sind nicht bestückt. Irgendwer eine Idee was da drann war?
Testi schrieb: > Warum Multiwii? > > Warum nicht lieber ein fertiges für ARM? > > Openpilot bzw. Taulabs? > > Oder eines der vielen anderen? Hi Testi, wie sieht es denn mit dem Speicherbedarf von Openpilot und Taulabs aus? Auf der ersten Blick scheinen die eine Menge Zusatzfunktionen zu haben? Immerhin gibt es nur 16kb flash. Multiwii erschien mir eine recht speichersparende Lösung zu sein. Kennst Du noch andere?
liquidMiakdo schrieb: > Davis schrieb: >> Ja. Styroporfüßchen. > > Ich habe meinem 4 Gummideämpfer verpasst die mit einem Standart RC-Servo > geliefert wurden. Passen genau unter die Motoren. Kannst du ein Bild oder Link von den Gummidämpfern posten?
liquidMiakdo schrieb: > Die Fernbedienung hat auf der Rückseite eine Portbeschriftung. > S11 und S12 sind nicht bestückt. Irgendwer eine Idee was da drann war? Wenn man denn lesen könnte, was da an den Bohrungen steht, wäre man schon weiter.
liquidMiakdo schrieb: > Die Fernbedienung hat auf der Rückseite eine Portbeschriftung. > S11 und S12 sind nicht bestückt. Irgendwer eine Idee was da drann war? Kannst Du eine Nahaufnahme des Tranceiver-Moduls machen? Was steht auf dem microcontroller auf der anderen Seite?
Also bei der Bezeichnung S würde ich auf Taster tippen... Speicherbedarf bei Taulabs ist groß. Aber wenn man alles rausschmeißt was man nicht brauch (viele Sensoren zusätzlich usw.) kann es vielleicht passen. Und man müsste halt es halt auch noch so umbauen das es ohne den Bootloader läuft. Oder man muss noch mehr umbauen so das es ohne das PiOS läuft. Die Hardware ist ja fest bei uns. Ich habe mal gerade nachgesehen die standart Firmware fürs f3 ist 167kb groß.
Turbonator schrieb: > Ich kenn mich nur ein wenig in asm pic aus. Das ist kein "pic" sondern ein "arm" (oben links unter www.mikrocontroller.net, Home und AVR kommt ARM). Und wenn man die Firmware ausliest, kommt das unleserliches Assembler heraus. Turbonator schrieb: > In was für einer programmier Sprache ist das wohl geschrieben? Schwer zu sagen, die Antwort hilft aber auch nicht weiter, da man Assembler nicht wieder in diese "Sprache" zurückwandeln kann. Tim . schrieb: > Original-Firmware auslesen und recompilieren. Du meinst reassemblieren, oder? Ohne Kommentare und sprechende Variablennamen kann man damit aber m.E. kaum was anfangen.
Hallo, ist der auf Ebay.de zu findende JD-185 der gleiche wie der JXD-385? Also gleiche Elektronik? VG
Franz N. schrieb: > Hallo, > > ist der auf Ebay.de zu findende JD-185 der gleiche wie der JXD-385? Also > gleiche Elektronik? > > VG http://www.china-gadgets.de/gadget/hubsan-x4-h107-micro-quadrocopter/
Aus dem Artikel (Danke!) lese ich, dass man also den JD-185 für 25eur (Standort: Deutschland) kaufen kann und damit nicht auf den China Versand warten muss? :-)
Franz N. schrieb: > ist der auf Ebay.de zu findende JD-185 der gleiche wie der JXD-385? Also > gleiche Elektronik? Sicher ist nichts. Der Hersteller heisst "JXD" und das Modell "JD-385".
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
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 Plus GBP 4,48 Versand.
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 Plus GBP 4,49 Versand.
Mit GBP habe ich schlechte Erfahrungen gemacht. Da als ungeschriebene Regel gilt, dass erst Strafsachen ab etwa 1.000 Euro überhaupt verfolgt werden, passieren leider oft Betrügereien im kleineren Rahmen. Kollege von mir wollte sich günstiger als ich ein neues Handy kaufen, dachte sich, er könne beim Kauf aus GB nochmal ein paar Euro sparen ... war schlussendlich ein teurer Spass.
Nachbauer schrieb: > Mit GBP habe ich schlechte Erfahrungen gemacht. > Da als ungeschriebene Regel gilt, dass erst Strafsachen ab etwa 1.000 > Euro überhaupt verfolgt werden, passieren leider oft Betrügereien im > kleineren Rahmen. In diesem Fall sollte PayPal davor schützen. Habe schon oft aus UK ohne Probleme bestellt.
Hab noch einen entdeckt, der der gleiche sein könnte: http://www.ebay.de/itm/RC-Ferngesteuert-Quadrocopter-Quadcopter-Multicopter-Drone-UFO-Schwarz-NEU-/171129650792?pt=RC_Modellbau&hash=item27d81f3e68 Versand aus DE...
So hab mich jetzt da mal ein wenig beschäftigt. Ich denke der Quadrocopter benutzt das HiSKY protocol. Dieses wurde bereits für Deviation nachgebaut. http://www.deviationtx.com/forum/protocol-development/1822-hisky-protocol?limitstart=0&start=80 Ich werde mir mal einen zulegen und mit meiner Devo Fernsteuerung testen. Grüße, Kille EDIT: Warscheinlich doch ein anderes. Aber auch dieses scheint schon zu existieren: http://www.deviationtx.com/forum/protocol-development/1647-v202-protocol?limitstart=0&start=200
:
Bearbeitet durch User
So wie es aussieht, benutzen die alle das gleiche Protokoll: http://www.rcgroups.com/forums/showthread.php?t=1902350&page=10 Ich habe mal einen bestellt (http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=171129650792&clk_rvr_id=532053641700) und werde berichten...
Der Quadro aus Deutschland hat aber ne Andere Fernbedienung als der aus China ist mir grade aufgefallen. Super wäre es wenn jemand die Software auslesen könnte. Dann würde ich mir auch Direkt einen Bestellen wenn ich den Selbst nen bisschen umschreiben könnte.
Sascha E. schrieb: > Der Quadro aus Deutschland hat aber ne Andere Fernbedienung als der aus > China ist mir grade aufgefallen. > Das ist unerheblich, solange das Protokoll das gleiche ist. > Super wäre es wenn jemand die Software auslesen könnte. > Dann würde ich mir auch Direkt einen Bestellen wenn ich den Selbst nen > bisschen umschreiben könnte. Das wird dir aber dann auch nix bringen. Das ist dann noch lange kein C-Code! Jedoch ist zuminderst der Teil des Protokolls der Fernsteuerung schon da. Siehe mein Link. Das müsste das Hisky Protokoll sein... Damit könnte schon ein fähiger Software Entwickler (ich bin das leider nicht) eine alternative Firmware für den schreiben.
Martin Schröer schrieb: > @Turbo: > > Korrekt, 22€ sind die Freigrenze ohne Einfuhrsteuer, mehr als 22€ bis > 150€ kostet 19% Einfuhrsteuer und ab 150€ kommen tatsächlich Zölle > drauf. > Zu beachten ist, dass es dabei immer um die Summe inklusive Versand > geht. Gut zu wissen. Z.Z ist der Wechselkurs bei Paypal schlecht weswegen es über 22 Euro wären. Also besser nicht bestellen weil sonst 19% drauf kommen würden und man das Paket dann wo umständlich abholen müsste?
Ich hab Ratsuchend schrieb: > Martin Schröer schrieb: >> @Turbo: >> >> Korrekt, 22€ sind die Freigrenze ohne Einfuhrsteuer, mehr als 22€ bis >> 150€ kostet 19% Einfuhrsteuer und ab 150€ kommen tatsächlich Zölle >> drauf. >> Zu beachten ist, dass es dabei immer um die Summe inklusive Versand >> geht. > > Gut zu wissen. Z.Z ist der Wechselkurs bei Paypal schlecht weswegen es > über 22 Euro wären. Also besser nicht bestellen weil sonst 19% drauf > kommen würden und man das Paket dann wo umständlich abholen müsste? Ich hab es für 22,50€ bestellt ,gestern in 3 wochen kann ich es dir sagen :)
http://www.youtube.com/watch?v=1HkI00suQDs zeigt wie einer das Teil mit einer anderen Fernbedienung verwendet, sieht schon aus als sprächen alle die gleiche Sprache.
Turbonator schrieb: > Ich hab es für 22,50€ bestellt ,gestern in 3 wochen kann ich es dir > sagen :) Hat da jemand eine Erfahrung ob der Zoll wirklich wegen 50cent mehr die 19% verlangt?
Ratsuchend schrieb: > Turbonator schrieb: >> Ich hab es für 22,50€ bestellt ,gestern in 3 wochen kann ich es dir >> sagen :) > > Hat da jemand eine Erfahrung ob der Zoll wirklich wegen 50cent mehr die > 19% verlangt? Rechne die EUst aus. Ist sie kleiner als 5 Euro, wird sie nicht erhoben.
cyblord ---- schrieb: > Rechne die EUst aus. Ist sie kleiner als 5 Euro, wird sie nicht erhoben. Ah gut zu wissen. Mir geht es nicht um die knapp 5 Euro mehr sondern das ich keine Lust und Zeit habe zum Zollamt zu gehen. Aber 19% von 22,50 sind ja unter 5 Euro.
Du musst auch nicht umbedingt zum Zollamt wenn der betrag über 22€ ist. Es reciht wenn ausen sichtbar eine Rechnung auf dem Paket angebracht wird. Dann wird dir das Paket auch nach Hause gebracht und dein Postbote nimmt dir dan das Geld ab. Du musst nur zum Zollamt wenn am Paket keine Rechung angebracht ist da der Zollbeamte das Paket ja nicht öffnen darf und somit nicht weiß was in dem Paket ist und wie viel der Inhalt gekostet hat. Gelegentlich Funktioniert es wenn der versender es als Geschenk oder Muster Deklariert. Als auf meinen Letzten Paket aller dings draufstandt 5000x Samples haben die beim Zoll das woll nicht ganz so geglaubt und ich musste es doch abhollen.
Manchmal habe ich auch einen Brief vom Zollamt bekommen. Ich habe dann einfach per Email (ja, das geht!) die Paypal-Abrechnungen, die Ebay-Nummer und sowas als PDF-Anhang geschickt und wenige Tage später lag das "Item" dann kommentarlos in meinem Briefkasten (sofern die 22€ unterschritten waren).
Oliver Stellebaum schrieb: > einfach per Email (ja, das geht!) die Paypal-Abrechnungen, > die Ebay-Nummer und sowas als PDF-Anhang geschickt Dumm nur, wenn man nicht weiß, was da gerade beim Zoll liegt, weil mehrere Sendungen unterwegs und überfällig sind... ...
Hannes Lux schrieb: > Dumm nur, wenn man nicht weiß, was da gerade beim Zoll liegt, weil > mehrere Sendungen unterwegs und überfällig sind... Notfalls kann man vorher nachfragen, wer der Absender ist (wobei das meist auch nicht wirklich hilft) oder sogar fragen was drin ist (machen die aber alles andere als gerne) aber wenn es gar nicht anders geht kann das helfen. Wegen Zoll bitte ich noch zu beachten, dass denen völlig egal ist, welchen Wechselkurs PayPal verwendet. Die berechnen den Wechselkurs nach einem eigenen Verfahren [1] Viele Grüße [1] http://www.zoll.de/DE/Fachthemen/Zoelle/Zollwert/Aktuelle-Umrechnungskurse/Umrechnungskursarten/umrechnungskursarten_node.html;jsessionid=C6AE75B857F98C2448D6D0C7DCD4083B
Jetzt aber zurück zum Wesentlichen. DEN Quadcopter. Gibt es schon weitere Erkenntnisse bezüglich der Firmware oder ob man eine eigene aufspielen kann?
Oliver Stellebaum schrieb: > ob man > eine eigene aufspielen kann? Das kann man mit Sicherheit. Die notwendigen Anschlüsse sind herausgeführt. Für etwa € 35.- bekommst du ein Nulink Interface. Ein Bootlader über die Sellerieschnitte wird vermutlich nicht drauf sein - auch, wenn es den bei Nuvoton gibt, einschließlich Steuerprogramm für den PC.
Georg G. schrieb: > Ein > Bootlader über die Sellerieschnitte wird vermutlich nicht drauf sein - > auch, wenn es den bei Nuvoton gibt, einschließlich Steuerprogramm für > den PC. Aber warum ist dann die serielle Schnittstelle herausgeführt? Ich werde am WE mal versuchen einen LA daran zu hängen. Vielleicht sieht man ja etwas. Leider ein ziemlich kleiner pitch...
> Aber warum ist dann die serielle Schnittstelle herausgeführt? Ich werde > am WE mal versuchen einen LA daran zu hängen. Vielleicht sieht man ja > etwas. Leider ein ziemlich kleiner pitch... Gibt es keinen Experten Modus? Stick reindrücken/klicken ?
Georg G. schrieb: > Die notwendigen Anschlüsse sind > herausgeführt. Für etwa € 35.- bekommst du ein Nulink Interface. Ich habe mal geschaut, wie man den 10-Pin Nuvoton ICE Connector "ICEJP8" des Nu-Link-Me Debug Adapters damit verbindet. 2 - VDD (3,0V) 4 - dta 6 - clk 8 - rst 10 - GND Die anderen Pins sind nicht genutzt. Das "NuTiny-SDK-Mini51"ist teurer als der Helikopter: http://www.digikey.de/product-detail/de/NUTINY-SDK-MINI51/NUTINY-SDK-MINI51-ND/3065250 Aliexpress meint dazu nur "Do you mean: nudity?" ;-) Da ich bei Digikey nicht bestellen kann: Wo bekommt man den? Tim . schrieb: > Die Neuprogrammierung per ISP scheint sich etwas komplexer zu gestalten. Wo erwartetst Du Probleme?
Torsten C. schrieb: > Ich habe mal geschaut, wie man den 10-Pin Nuvoton ICE Connector "ICEJP8" > des Nu-Link-Me Debug Adapters damit verbindet. > > 2 - VDD (3,0V) > 4 - dta > 6 - clk > 8 - rst > 10 - GND Das sind die normalen SWD Anschlüsse.
:
Bearbeitet durch User
Torsten C. schrieb: > Tim . schrieb: >> Die Neuprogrammierung per ISP scheint sich etwas komplexer zu gestalten. > > Wo erwartetst Du Probleme? Man benötigt proprietäre HW (kein USB zu RS232) und das Protokoll ist nicht dokumentiert.
Torsten C. schrieb: > Aliexpress meint dazu nur "Do you mean: nudity?" ;-) bei alibaba gibt es einen anbieter: http://www.alibaba.com/product-gs/804555783/KIT_EVAL_NUMICRO_MINI51_NUTINY_SDK.html
nosilent schrieb: > Torsten C. schrieb: >> Aliexpress meint dazu nur "Do you mean: nudity?" ;-) > > bei alibaba gibt es einen anbieter: > http://www.alibaba.com/product-gs/804555783/KIT_EVAL_NUMICRO_MINI51_NUTINY_SDK.html wahrscheinlich ist aber ein nachgebauter Keil Ulink günstiger: http://www.ebay.com/itm/Ulink-2-USB-JTAG-Emulator-ARM9-Cortex-Keil-Ulink-II-GH2-White-Adapter-Debug-G6-/200942168148?pt=LH_DefaultDomain_0&hash=item2ec9162854
Angeblich kann man die STM Discovery-Boards auch als generellen SWD-Adapter missbrauchen. Das lässt sich vom Preis her kaum unterbieren. Habe mich allerdings noch nicht damit beschäftigt.
Also auf Discovery Boards kann man Versaloon aufspielen. http://www.versaloon.com Und Versaloon unterstützt OpenOCD http://openocd.sourceforge.net/ Und OpenOCD unterstützt die Nuvoton Mini54 Serie. Soweit ich das jetzt alles verstanden habe. Die Frage ist, ob das auch alles zusammen so funktioniert.
Tim . schrieb: > Angeblich kann man die STM Discovery-Boards auch als generellen > SWD-Adapter missbrauchen. Manuel Steiner schrieb: > Also auf Discovery Boards kann man Versaloon aufspielen. Das sind m.E. zwei ganz unterschiedliche Vorschläge. Auf dem Disco ist ja bereits ein SWD, ohne dass man da irgendwas "aufspielt". CooCox habe ich installiert, ein Disco habe ich auch da. Ich werde aber wohl dieses Wochenende nicht mehr dazu kommen, das auszuprobieren.
Soweit ich weiß, sind aber nicht alle SWD Protokolle von allen Herstellern gleich. Also ich meine mal wo gelesen zu haben, dass STM SWD nur zur Programmierung von STM MCUs zu gebrauchen ist, weil eben das Protokoll proprietär ist. Ich kann mich natürlich auch irren.
Manuel Steiner schrieb: > Soweit ich weiß, sind aber nicht alle SWD Protokolle von allen > Herstellern gleich. Also ich meine mal wo gelesen zu haben, dass STM SWD > nur zur Programmierung von STM MCUs zu gebrauchen ist, weil eben das > Protokoll proprietär ist. vielleicht ist es doch nicht proprietär: http://www.arm.com/products/system-ip/debug-trace/coresight-soc-components/serial-wire-debug.php zumindest für die ARM Cortex Mikrocontroller sollte es gleich sein: > SWD is compatible with all ARM processors and any processor using JTAG for debug > and provides access to debug registers in Cortex™ processors (A,R,M) and the > CoreSight debug infrastructure.
so wir (steinerhippo und ich) haben den SWD von einem STM32F4Disocervy mit einem NXP LPC1343 verbunden und das Target wird von Keil erkannt. Verbundene Pins für eine erfolgreiche Kommunikation: LPC1343 SWD STM32F4Discovery SWDIO/TMS SWDIO SWDCLK/TCK SWDCLK nRESET NRST VTREF VDD_TARGET Wir gehen davon aus, dass es auch mit den Novoton uCs funktioniert. Unser Quadcopter ist noch auf dem Weg...
Na so kann man sich irren :) Dann sind doch so Discovery Boards echt eine feine Sache. Wie nosilent bereits geschrieben hat, ist unser Quadcopter noch auf dem Weg, evtl. kommt ja vor uns noch jemand anderes dazu, mal ein Discovery oder Ähnliches an die SWD Schnittstelle zu hängen.
Andere Möglichkeit ist der CoLink-Ex: http://www.coocox.org/CoFlash_Programmer.htm http://www.coocox.org/CoLinkExGuide/Buy_CoLinkEx.htm Hat ja nicht jeder Keil... Wäre schön, wenn es noch eine freie Software geben würde um den F4 SWD mit den Nuvotons ans rennen zu bekommen.
Keil gibt es bis 32Kb kostenlos. reicht also für den Quadrocopter. Weiß nur nicht ob Keil auch die Nuvoto drin hat. Hab hier meinen Quad liegen und nen Segger J-Link Edu. Der kann die Nuvoto Mini 54. Coocox wohl auch oder? Bringt mir nur beides nichts, da ich keine Ahnung habe wie man dafür ne Firmware schreibt... Bin bei ARM noch am Anfang und am lernen...
:
Bearbeitet durch User
Wenn das Discoveryboard mit Keil den MINI54ZAN beschreiben kann, ist das Programmierproblem schon fast gelöst. Die freie MDK-Version kann bis 32kb Flash, der Controller hat nur 16kb... http://www.keil.com/arm/selector.asp
No y. schrieb: > Keil gibt es bis 32Kb kostenlos. reicht also für den Quadrocopter. Weiß > nur nicht ob Keil auch die Nuvoto drin hat. Oh, da hatten wir den gleichen Gedanken. Keil kennt den Controller: http://www.keil.com/dd/chip/6142.htm Allerdings bin ich mir noch nicht sicher, wie ich den im Projekt einstelle...
Ich hab hier mal eine Anleitung für eine andere Nuvoton Serie gefunden. http://webshop.atlantikelektronik.de/Webpage/NUC1xx%20Quick%20Start%20Guide%20for%20Keil%20uVision4.pdf Sieht wohl so aus, als müsste man Nuvoton MCUs als generische ARM MCUs behandeln (im Fall des MINI54ZAN ein generischer Cortex M0). Wie es allerdings dann mit den spezifischen Settings aussieht, weiß ich auch noch nicht...
No y. schrieb: > da ich keine Ahnung habe wie man dafür ne > Firmware schreibt... Na, dann ist das doch genau das richtige Projekt um das zu lernen. Ich fände es jedenfalls spannender als zum tausendsten Mal einen Roboter zu bauen, der auf einem Strich entlang fährt oder die anderen typischen Anfänger-Projekte. Tim . schrieb: > Aber warum ist dann die serielle Schnittstelle herausgeführt? Die kann noy z.B. nutzen, um bei seinen ersten Versuchen mit dem Quadkopter über die serielle Schnittstelle am Kabel (oder über einen BTM-222) zu reden: Ich würde damit anfangen, per serieller Schnittstelle erstmal die Motoren mit geringer Drehzahl anzusteuern und die Daten aus dem MPU-6050 auszulesen, um ein Gefühl für die Werte zu bekommen. Entweder man macht dann mit Bluetooth weiter oder man leitet die Daten vom Nrf24L01 an die serielle Schnittstelle und analysiert die Bytes, damit man erkennt, wie die Hebelstellungen der Fernbedienung übertragen werden. Und so tastet man sich dann langsam vor. Es kam ja auch schon der Vorschlag, vorhandene Projekte (Paparazzi, Flyduino, ...) zu portieren. Ich denke, es macht Sinn, mal hinein zu scchauen, um zu sehen wie andere die Flugstabilisierung gemacht haben. Ich hab' mal "laut gedacht", vielleicht hat noch jemand bessere Vorschläge.
:
Bearbeitet durch User
Torsten C. schrieb: > Ich würde damit anfangen, per serieller Schnittstelle erstmal die > Motoren mit geringer Drehzahl anzusteuern und die Daten aus dem MPU-6050 > auszulesen, um ein Gefühl für die Werte zu bekommen. Hab ich mir auch in etwa so gedacht. Evtl kann man hier auch gleich über ein Nrf24L01, welches über USB o.Ä. am PC verbunden ist mit dem Funkmodul am Quadcopter kommunizieren (über ein Terminal oder so dann Werte für den Motor senden, ...). Dann hätte man gleich die vorhandene Funkschnittstelle benutzt und man benötigt kein Kabel. Dass die ganze Sache eventuell einen kleinen Mehraufwand am Anfang bedeutet, ist natürlich klar. Ich denke man sollte sich erstmal mit den Gegebenheiten vertraut machen und in etwa herausfinden, wie man mit dem Quadcopter umgehen muss, bevor man gleich versucht größere, bereits vorhandene Softwarelösungen zu portieren. Gegen Hineinschnuppern und nach vorhandenen Lösungen sehen, spricht ja überhaupt nichts. Auch gegen das Portieren nicht, ich glaube nur, dass dies nur in Frust endet, wenn man zuvor nicht genau verstanden hat, wie der Quadcopter zu handhaben ist.
Manuel Steiner schrieb: > Evtl kann man hier auch gleich über ein Nrf24L01, welches über USB o.Ä. > am PC verbunden ist mit dem Funkmodul am Quadcopter kommunizieren (über > ein Terminal oder so dann Werte für den Motor senden, ...). Dafür musst du aber trotzdem den SPI-Verkehr zum nRF24L01 einmal mit plotten um herauszubekommen auf welchen Kanal (1...125) und welche Adresse (5 Byte) kommuniziert wird. Der Rest ist dann einfach, habe ich bei meiner LG Funkmaus mit nRF24L01 auch schon gemacht.
http://conference.hitb.org/hitbsecconf2011ams/materials/D2T3%20-%20Travis%20Goodspeed%20-%20Building%20a%20Promiscious%20nRF24L01%20Packet%20Sniffer.pdf bzw http://travisgoodspeed.blogspot.de/2011/02/promiscuity-is-nrf24l01s-duty.html Es gibt auch Wege, das einfacher zu sniffen ;)
Naja die 3,4 Leitungen sind schnell an den Chip geklatscht (kommt man ja noch ganz gut ran) und dann eben die SPI-Daten über den UART rauszuhauen geht wohl schneller als sich erst das ominöse Board zu besorgen (falls es das überhaupt noch gibt). Aber wo du gerade den A7125 ins spiel gebracht hast... evtl. wäre das $3-Modul mit A7125 mal ganz interessant für zukünftige sniffereien: http://www.elecfreaks.com/store/24ghz-easy-radio-de-a7125-modulemasterslave-p-167.html Bringt natürlich nichts wenn die Copter 250kbit verwenden, da das a7125 nur 1 und 2 Mbit kann. Und das ding hat auch weniger Kanäle (2.400-2.483 GHz) die nRF - falls sie denn mal von so einem Copter genutzt werden - haben 125 Kanäle (also bis 2.525 GHz)
:
Bearbeitet durch User
Timmo H. schrieb: > Manuel Steiner schrieb: >> Evtl kann man hier auch gleich über ein Nrf24L01, welches über USB o.Ä. >> am PC verbunden ist mit dem Funkmodul am Quadcopter kommunizieren (über >> ein Terminal oder so dann Werte für den Motor senden, ...). > Dafür musst du aber trotzdem den SPI-Verkehr zum nRF24L01 einmal mit > plotten um herauszubekommen auf welchen Kanal (1...125) und welche > Adresse (5 Byte) kommuniziert wird. Der Rest ist dann einfach, habe ich > bei meiner LG Funkmaus mit nRF24L01 auch schon gemacht. Mein Ansatz war eher (wenn einem der original Funkverkehr egal ist), selbst Sende- und Empfangsroutine zu implementieren. Dann kann ich das doch alles selbst einstellen, wenn ich mich nicht irre. Das müsste dann ausreichen, um einfache Kommandos drahtlos an den Quadcopter zu übertragen, um mal zu testen wie sich der so verhält. Die ganze Motoransteuerung und Stabilisationssache muss ja sowieso neu programmiert werden. Wenn man den Quadcopter jedoch mit der orignial Fernbedienung weiterhin verwenden will, ist es wohl sehr sinnvoll, das Ganze mal mitzuloggen. nosilent und ich haben eher vor, den Quadcopter ohne Fernbedienung autonom mit eventuell ein paar Sensoren fliegen zu lassen. Aber die Kommandos von der Fernbedienung wären wohl trotzdem interessant, falls man Autonomie mit Fernsteuerung mal verbinden will.
Das Protokoll haben netterweise schon Andere reverse engineered. Es ist unter der Bezeichnung V2x2 Protokoll bekannt, und wird von Deviation, einer Universalfernsteuerungssoftware untestützt: http://www.deviationtx.com/forum/protocol-development/2111-protocols-chips-and-hardware Den Quellcode der Firmware gibt es hier: https://bitbucket.org/PhracturedBlue/deviation/downloads Der relevante Teil liegt hier: https://bitbucket.org/PhracturedBlue/deviation/src/c960b8ea4e77/src/protocol?at=default V202...
Hier ist ein Forenthread, in dem das Protokoll diskutiert wird: http://www.deviationtx.com/forum/protocol-development/1647-v202-protocol
Einen kleinen Erfolg kann ich vermelden: Es hat sich als relativ einfach herausgestellt, das Protokoll der FB zu empfangen. Mit Hilfe eines nRF24L01+ Moduls an einem LPC812 (NXP Cortex M0+ MCU) war das kein Problem. Channel-Hopping habe ich nicht implementiert, man kann aber auf einem konstanten Kanal bereits etliche Datenpackete pro Sekunde empfanden. Source für den LPC812 anbei. Er sollte sich relativ einfach auf AVR/Arduino portieren lassen. Dazu muss "radiopinfunction.c" angepasst und main.c um die Hauptschleife neu geschrieben werden. Das Datenformat ist relativ einfach. Es werden 16 Byte-Pakete verschickt. Dump einiger Datenpakete:
1 | > 74 99 00 00 40 40 3E 1F E4 75 00 00 00 00 00 43 |
2 | > 80 99 00 00 40 40 3E 1F E4 75 00 00 00 00 00 4F |
3 | > FF 00 00 00 40 40 3E 1F E4 75 00 00 00 00 00 35 |
4 | > FF 00 00 00 40 40 3E 1F E4 75 00 00 00 00 00 35 |
5 | > FF 14 00 00 40 40 3E 1F E4 75 00 00 00 00 00 49 |
6 | > FF 15 00 00 40 40 3E 1F E4 75 00 00 00 00 00 4A |
Das Format der Datenpakete (siehe auch https://bitbucket.org/rivig/v202/src)
1 | Byte Function Range |
2 | 0 Throttle 0-255, note: Trim will be added by remote control |
3 | 1 Yaw bit 7 indicates direction, value in [6:0] depends on speed button settings |
4 | 2 Pitch bit 7 indicates direction, value in [6:0] depends on speed button settings |
5 | 3 roll bit 7 indicates direction, value in [6:0] depends on speed button settings |
6 | 4 trim yaw 2-126, 64 is neutral |
7 | 5 trim pitch 2-126, 64 is neutral |
8 | 6 trim roll 2-126, 64 is neutral |
9 | 7 txid1 Unique ID, 0x1fe475 in my RC |
10 | 8 txid2 Unique ID, 0x1fe475 in my RC |
11 | 9 txid3 Unique ID, 0x1fe475 in my RC |
12 | 10 unused |
13 | 11 unused |
14 | 12 unused |
15 | 13 unused |
16 | 14 Flags 0x40 is "turning button" |
17 | 15 Checksum Used to determine next channel for channel hopping |
http://news.ebay.de/globalnews/item/show/1789?_trksid=p3984.m2301.l3955 > Hongkong Post hat vor kurzem angekündigt, dass alle per Luftpost aus > Hongkong versandten Briefe und Pakete fortan geröntgt werden. Diese > zusätzliche Überprüfung kann zu Lieferverspätungen führen, auf die der > Verkäufer keinen Einfluss hat. Wenn Sie einen Artikel von einem Verkäufer in > Hongkong gekauft haben, sollten Sie berücksichtigen, dass sich die Lieferung > um einige Zeit verspäten kann. Bitte rechnen Sie mit mindestens einer Woche > mehr als der vom Verkäufer ursprünglich angegebenen Lieferzeit.
Tim . schrieb: > Channel-Hopping habe ich nicht implementiert Von wem werden denn die neuen Kanäle festgelegt? Von der Fernsteuerung oder vom Quadkopter? Nach "Sender" oder "Empfänger" kann man ja hier nicht unterscheiden.
Fragen aus Neugier: Was wollt ihr eigentlich mit diesem Copter machen? Angenommen der uC lässt sich programmieren - was soll man dann daran ändern wollen? Das fliegt doch schon...
der_leser schrieb: > was soll man dann daran ändern wollen? Das fliegt doch schon... Zunächst denke ich, dass an der Flugstabilisierung noch einiges getan werden kann, denn ich schrieb: > Beim Steuern verliert er an Höhe, … Accel_Z wird zwar offenbar für die Regelung benutzt, aber die Regler sind m.E suboptimal ausgelegt. Aber die Frage ist natürlich in sofern berechtigt, als dass es noch gar kein "Brainstorming" hier gab, was man noch alles machen könnte. Fernsteuerung über Bluetooth (größere Entfernung oder auch vom Handy aus) kam ja bisher nicht so gut an ^^. Man könnte noch vorprogrammierte Kunstflugfiguren vorsehen und Ausgänge, um die Kamera zu steuern (Foto und Film Start/Stopp). Ein GPS-Empfänger ist vermutlich schon zu schwer, zumindest die 8€-Teile aus China. Gibt's sonst noch Ideen? PS: Oder ein LED-Streifen, der beim fliegen einen Schriftzug datstellt (POV-Display-Prinzip). PPS: Ich sollte mich langsam an die "Vorschau"-Funktion gewöhnen, sorry:
:
Bearbeitet durch User
Torsten C. schrieb: > noch gar kein "Brainstorming" ... Ach ja, noch einer: Da bereits ein Sender eingenaut ist, könnte man auch das Kamera-Bild senden. Ich habe ja noch vor, eine Handy-Kamera auszulesen, siehe Beitrag "Handy-Kamera: Welche Schnittstelle?"
der_leser schrieb: > Fragen aus Neugier: > Was wollt ihr eigentlich mit diesem Copter machen? > Angenommen der uC lässt sich programmieren - was soll man dann daran > ändern wollen? Das fliegt doch schon... nosilent und ich haben eher vor, den Quadcopter ohne Fernbedienung autonom mit eventuell ein paar Sensoren fliegen zu lassen. Mal sehen in wie weit sich das relisieren lässt, all zu viel Zusatzgewicht kann man ja nicht ranhängen, aber eine Minikammera wäre wirklich iteressant. Torsten C. schrieb: > PS: Oder ein LED-Streifen, der beim fliegen einen Schriftzug datstellt > (POV-Display-Prinzip). Das wäre z.B. auch interessant.
Manuel Steiner schrieb: > > nosilent und ich haben eher vor, den Quadcopter ohne Fernbedienung > autonom mit eventuell ein paar Sensoren fliegen zu lassen. Per Knopfdruck aus dem Auto-Schiebedach rausfliegen, Parkplatz von oben Scanen, Lücke finden, Bild mit dem "Weg" zum Parkplatz markieren.
Manuel Steiner schrieb: > autonom mit eventuell ein paar Sensoren Das klingt auch sehr interessant. Ultraschallsensoren sind zwar groß, aber leicht und billig (1€ pro Stück). Aber ich finde, das Prinzip taugt nicht so gut, wenn sich die Echo-Reflektoren (z.B. Personen) bewegen. Was habt Ihr vor? Falls Ihr einen leichten GPS-Empfänger findet, sagt bitte Bescheid. Eine serielle Schnittstelle für die NMEA-Daten hat der Quadcopter ja noch frei. PS: Per Nrf24L01 lassen sich ja auch DGPS-Daten übermitteln. PPS: Die Parkplatzsuche ist m.E. der beste Vorschlag und ließe sich mit GPS m.E. ganz gut umsetzen, auch wenn der Quadkopter in einer einfachen Lösung erstmal zurück fliegen muss, damit man das Foto sieht. Hallo schrieb: > Per Knopfdruck aus dem Auto-Schiebedach rausfliegen Ich stelle mir das gerade vor. Eine kleine Start-/Lande-Plattform unter dem Schiebedach mit Elektromagnet zum halten und kraftlosen Kontakten, um den LiPo zu laden. Cool. :-)
:
Bearbeitet durch User
Hallo schrieb: > Manuel Steiner schrieb: >> >> nosilent und ich haben eher vor, den Quadcopter ohne Fernbedienung >> autonom mit eventuell ein paar Sensoren fliegen zu lassen. > > Per Knopfdruck aus dem Auto-Schiebedach rausfliegen, Parkplatz von oben > Scanen, Lücke finden, Bild mit dem "Weg" zum Parkplatz markieren. Was ich meinte, muss auch kein richtiges Bild sein. Es reicht schon, wenn der QCopter über die Stelle stehen bleibt als Markierung. Man kann den auch so programmieren, dass bei "bekannten" Parkplätzen, z.B. Arbeit, Haus, da wo man oft parkt, der bei einer Annäherung automatisch rausfliegt (GPS) und die Arbeit vorleistet.
der Quadrocopter kann ja auch auf dem freien Platz parken & diesen freihalten, dabei sendet er ein Peilsignal oder in der einfachen version zuendet er eine Rauchpatrone... ;) vlG Charly
Von Vishay habe ich Infrarot Distanzsensoren gefunden, die im Normalbetrieb bis 20cm. Das Ganze in einem sehr kleinen Gehäuse. 20cm sind jetz nicht wirklich viel, aber für einige Sachen könnte man damit eventuell schon etwas anfangen. Vielleicht kennt jemand noch so kleine Alternativen mit höherer Reichweite? http://www.vishay.com/ppg?84150 Gibts auch quadratisch (4010) und noch einmal ähnlich (4020)
Charly B. schrieb: > der Quadrocopter kann ja auch auf dem freien Platz > parken & diesen freihalten, dabei sendet er ein Peilsignal > oder in der einfachen version zuendet er eine Rauchpatrone... > > ;) > > vlG > Charly Oder fängt an gefährlich wild zu rotieren, wenn ein anderes Auto parken will... "ich kratz dich gleich du Blechkiste..."
Hallo schrieb: > "ich kratz dich gleich du Blechkiste..." In Kombination mit einer (POV-) Laufschrift. Nett, aber alles m.E. etwas übertrieben. Manuel Steiner schrieb: > Infrarot Distanzsensoren Oh, Cool. Die wären auch für meinen Helokopter interessant, als Nahbereichs-Ergänzumg zu Ultraschall. Ich suche auch selbst nochmal. Bisher habe ich aber verstanden, dass die nicht die Zeit für das Echo auswerten, sondern nur die Lichtstärke. Das heißt bei dunklem Fußboden fliegt der QKopter niedriger als bei hellem, oder wie?
:
Bearbeitet durch User
Torsten C. schrieb: > Das heißt bei dunklem Fußboden > fliegt der QKopter niedriger als bei hellem, oder wie? Im Datenblatt steht zumindest: Excellent ambient light suppression by signal modulation. Wie exzellent das funktioniert kann ich allerdings nicht sagen, ich bin erst vor kurzem auf die Teile gestoßen und hatte sie noch nicht selbst im Einsatz.
Manuel Steiner schrieb: > Excellent ambient light suppression by signal modulation Ja, hab'ich auch gelesen. Dass heiß aber m.E. nur, dass er das Licht moduliert und nur die Amplitude (Spitze-Spitze) analysiert und ner Offset unterdrückt wird. Die Helligkeit des Reflektors (z.B. Fußboden^^) müsste theoretisch trotzdem gewaltig in den Messwert eingehen. Beim Sharp GP2D120 ist ein Diagramm im Datenblatt: "White paper (90% Reflectance)" und "Gray paper (18% Reflectance)" sind kaum unterschiedlich. Das verstehe ich nicht. PS: Alles andere wäre LIDAR, z.B. http://www.parallax.com/product/28044 … und viel zu teuer.
:
Bearbeitet durch User
Torsten C. schrieb: > Torsten C. schrieb: >> noch gar kein "Brainstorming" ... > > Ach ja, noch einer: Da bereits ein Sender eingenaut ist, könnte man auch > das Kamera-Bild senden. Ich habe ja noch vor, eine Handy-Kamera > auszulesen, siehe Beitrag "Handy-Kamera: Welche Schnittstelle?" Würdest Du die zum Laufen bringen, wäre das natürlich ideal - und würde mich auch über das Quad-Projekt hier hinaus interessieren. So lange das jedoch noch nicht gelungen ist, schiele ich immer noch in Richtung der bereits schon einmal erwähnten 808 keycams [die übrigens nur deutlich teurer als der Quad selbst zu bekommen sind :( ], zumal dafür schon einige Videos existieren, welche belegen, dass es damit auch praktisch funktioniert. Ich kann derzeit blöderweise "nur über den Zaun schauen", da mein(e) Quad(s) immer noch nicht geliefert sind - blöd. ----- P.S: ich habe noch keine 808er bestellt, erst einmal möchte ich den Hubsan (Klon) live in den Händen halten, um eine eigene Einschätzung vornehmen zu können. Kann ja so lange auch nicht mehr dauern ... (am 22.09. bestellt)
:
Bearbeitet durch User
der_leser schrieb: > was soll man dann daran ändern wollen? Das fliegt doch schon... Der Höhenverlust beim Steuern ist schon etwas nervig. Besonders bei hoher Geschwindigkeit muss man aufpassen, dass man keine Bruchlandung macht. Ich hätte auch gerne eine Höhenregelung. Also das der Quadcopter die höhe hält und man nicht so viel am Gas rum regeln muss (wie genau man das realisieren soll weiss ich nicht). Ein Abstandssensor wäre auch nicht schlecht zur Höhenregelung. Bei 20cm könnte man zumindest kurz vorm Aufprall noch was abfangen :) Wie verhält sich der Quadcopter bei euch eigentlich wenn der Akku leer ist? Mir ist es jetzt schon ein paar mal passiert, dass er sich bei leeren Akku einfach ausschaltet - ungünstig wenn man gerade etwas höher fliegt. Oder er schaltet sich ab sobald man einen Flip ausführen will. Das könnte man in der Software auch ändern, dass die Motorleistung langsam auf Null runter gefahren wird.
Bei mir wird sie das auch? Irgendwann hat man auch bei vollgas nurnoch leichten Sinkflug und 5sec später geht der Copter dann aus....
Meiner schaltet sich auch einfach aus. Wobei er dann mit der Kalibrierung der Fluglage anfängt, könnte also auch mit einer Brown Out Detection zu tun haben
Chris L. schrieb: > könnte also auch mit einer Brown Out > Detection zu tun haben Jo, habe ich mir auch schon gedacht. Auf jeden Fall etwas, dass man verbessern könnte (auch schon durch einfaches Deaktivieren des Brown-Out).
Torsten C. schrieb: > Manuel Steiner schrieb: >> Infrarot Distanzsensoren > > Oh, Cool. Die wären auch für meinen Helokopter interessant, als > Nahbereichs-Ergänzumg zu Ultraschall Ich habe soeben ein paar Samples von 3020, 4010 und 4020 erhalten. Wenn ich Zeit habe, werde ich mal testen, wie sich das mit unterschiedlichen Bodenbeschaffenheiten verhält. @nosilent: Ich hoffe du liest hier fleißig mit, die Dinger sind richtig klein und wollen wo aufgelötet werden :P
Ich habe jetzt einmal den seriellen Port auf dem Board "angezapft". Interessanterweise werden nach dem Einschalten tatsächlich Daten ausgegeben, und zwar "LF36\n\r" und "OK" 6.5ms später. (115200 baud, 8N1). Anscheinend handelt es sich um Debugginginformationen der Firmware. Auf Dateneingaben reagiert er nicht. Ich habe auch die ISP-SOftware von Nuvoton am seriellen ausprobiert. Leider bekomme er keine Verbindung. Evtl. muss erst der Bootloader auf andere Weise aktiviert werden, sofern er überhaupt vorhanden ist. Den SWD-Port werde ich mir vornehmen, sobald Keil µvision richtig funktioniert. Der MINI54ZAN ist in der Device Database vorhanden (File->Device Database). In "Project->Select Device for Target" kann ich ihn aber nicht auswählen? Was soll das? Ist da schon jemand weiter?
:
Bearbeitet durch User
Torsten C. schrieb: > Tim . schrieb: >> Channel-Hopping habe ich nicht implementiert > > Von wem werden denn die neuen Kanäle festgelegt? Von der Fernsteuerung > oder vom Quadkopter? Nach "Sender" oder "Empfänger" kann man ja hier > nicht unterscheiden. Die Fernbedienung "hüpft" nach einen vorgegebenen Schema durch die Kanäle und der Quadcopter muss nach gleichem Algorithmus folgen. Die Sequenz wird dabei durch die ID der Fernbedienung festgelegt, welche in jedem Datenpacket mitgesendet wird. Dadurch werden Kollisionen verhindert. Von bidirektionaler Verbindung kann allerdings nicht die Rede sein. Die FB sendet einfach ohne Rücksicht auf Verlust. Es wird noch nicht einmal die integrierte Auto-Acknowledge Funktion des Tranceivers verwendet.
Tim . schrieb: > Ich habe jetzt einmal den seriellen Port auf dem Board "angezapft". > Interessanterweise werden nach dem Einschalten tatsächlich Daten > ausgegeben, und zwar "LF36\n\r" und "OK" 6.5ms später. (115200 baud, > 8N1). Anscheinend handelt es sich um Debugginginformationen der > Firmware. Auf Dateneingaben reagiert er nicht. > > Ich habe auch die ISP-SOftware von Nuvoton am seriellen ausprobiert. > Leider bekomme er keine Verbindung. Evtl. muss erst der Bootloader auf > andere Weise aktiviert werden, sofern er überhaupt vorhanden ist. > > Den SWD-Port werde ich mir vornehmen, sobald Keil µvision richtig > funktioniert. Der MINI54ZAN ist in der Device Database vorhanden > (File->Device Database). In "Project->Select Device for Target" kann ich > ihn aber nicht auswählen? Was soll das? Ist da schon jemand weiter? Weiß nicht ob du das PDF mal kurz angesehen hast. Jedenfalls verwenden die bei Nuvoton irgendwie das generische Cortex M0 Device. ... Ich hab hier mal eine Anleitung für eine andere Nuvoton Serie gefunden. http://webshop.atlantikelektronik.de/Webpage/NUC1x... Sieht wohl so aus, als müsste man Nuvoton MCUs als generische ARM MCUs behandeln (im Fall des MINI54ZAN ein generischer Cortex M0). Wie es allerdings dann mit den spezifischen Settings aussieht, weiß ich auch noch nicht...
Manuel Steiner schrieb: > Weiß nicht ob du das PDF mal kurz angesehen hast. Jedenfalls verwenden > die bei Nuvoton irgendwie das generische Cortex M0 Device. > > ... > > Ich hab hier mal eine Anleitung für eine andere Nuvoton Serie gefunden. > > http://webshop.atlantikelektronik.de/Webpage/NUC1x... > Hi Manuel, Danke! Ich hätte erwähnen sollen, dass ich die Anleitung schon gesehen habe. Die Anleitung ist allerdings von Jan 2010. Ich hatte gehofft, dass der Support inzwischen besser ist, insbesondere da die MCU tatsächlich in der Datenbank auftaucht. Nach der alten Variante muss man fast alles per Hand einstellen. Wäre blöd die Arbeit doppelt zu machen, wenn es auch einfacher geht. Hier der Eintrag:
1 | BOOK0=DATASHTS\Nuvoton\M051Series\M051_Series_Technical_Reference_Manual_EN_V2.0.pdf("Reference Manual") |
2 | BOOK1=datashts\arm\cortex_m0\r0p0\DDI0432C_CORTEX_M0_R0P0_TRM.PDF("Technical Reference Manual") |
3 | BOOK2=datashts\arm\cortex_m0\r0p0\DUI0497A_CORTEX_M0_R0P0_GENERIC_UG.PDF("Generic User Guide") |
4 | CPU=IRAM(0x20000000-0x20000FFF) IROM(0-0x03FFF) CLOCK(12000000) CPUTYPE("Cortex-M0") |
5 | FLDLL=UL2CM3(-O206 -S0 -C0 -FO7 -FD20000000 -FC800 -FN1 -FF0NU_M054_AP_16 -FS00 -FL04000) |
6 | MON=SARMCM3.DLL("") TARMCM1.DLL("-pCM0") |
7 | REGFILE=M051Series.h("Nuvoton\M051Series") |
8 | SFILE="STARTUP\Nuvoton\M051Series\startup_M051Series.s" ("Nuvoton M051 Series Startup Code") |
9 | SIM=SARMCM3.DLL("") DARMCM1.DLL("-pCM0") |
10 | SVD=SFD\Nuvoton\M051Series\M051AN.SFR |
Torsten C. schrieb: > der_leser schrieb: >> was soll man dann daran ändern wollen? Das fliegt doch schon... > > Zunächst denke ich, dass an der Flugstabilisierung noch einiges getan > werden kann, denn ich schrieb: >> Beim Steuern verliert er an Höhe, … > > Accel_Z wird zwar offenbar für die Regelung benutzt, aber die Regler > sind m.E suboptimal ausgelegt. > > Aber die Frage ist natürlich in sofern berechtigt, als dass es noch gar > kein "Brainstorming" hier gab, was man noch alles machen könnte. > > Fernsteuerung über Bluetooth (größere Entfernung oder auch vom Handy > aus) kam ja bisher nicht so gut an ^^. > > Man könnte noch vorprogrammierte Kunstflugfiguren vorsehen und Ausgänge, > um die Kamera zu steuern (Foto und Film Start/Stopp). > > Ein GPS-Empfänger ist vermutlich schon zu schwer, zumindest die 8€-Teile > aus China. > > Gibt's sonst noch Ideen? Die Ideenliste gefällt mir. Ich glaube eine Automatische Haltefunktion wäre die interessanteste Ergänzung. Ultraschall bietet sich dabei ein. Vielleicht hilft ein Kompass oder ein Drucksensor ja auch? Dann wäre es natürlich spannend das Ding vom PC aus zu kontrollieren. Ich glaube das lässt sich von den genannten Dingen fast am einfachsten realisieren. Mir persönlich geht es einfach auch darum ein komplettes System zum lernen zu haben. Am Quadrocopter ist vieles dran, was gerade in embeeded Sytems wichtig ist: Datenübertragung per 2.4Ghz, Inertialsensoren, Motorcontroller, Regelschleifen usw..
:
Bearbeitet durch User
Ich habe jetzt die Nuvoton Keil-Treiber installiert. http://download.nuvoton.com/NuvotonMOSS/DownloadService/Member/DocumentsInfo.aspx?tp_GUID=SW0520101208200142 Dieser hat auch MCUs zur Datenbank hinzugefügt. Allerdings kann ich die immer noch nicht auswählen. Die Beispielprojekte lassen sich öffnen, aber ich kann die Target-CPU nicht ändern. Vielleicht ein Kompatibilitätsproblem zwischen µvision 4 und 5? Ärgerlich.
Ok, Problem gefunden: Keil hat in der µVision 5 ein neues System ("Software Packs") für den Support von Devices eingeführt. Im neuen System werden erst sehr wenige Controller unterstützt: http://www.keil.com/dd2/Pack/ Für allen alten Controller muss man den Legacy support installieren: http://www2.keil.com/mdk5/legacy/ Jetzt kennt er auch den MINI54ZAN! Werde mich demnächst mal dran machen.
:
Bearbeitet durch User
Wow, hier ist ja was los! Marius S. schrieb: > wie genau man das realisieren soll weiss ich nicht Zwei Dinge: - Erstens die Motordrehzahlen so steuern, dass der Effekt kaum auftritt. - Zweitens den Proportional- und Integralteil von Accel_Z vom MPU-6050 anpassen No y. schrieb: > Der copter fängt erst an mit den LEDs zu blinken... dann geht er ... ... langsam in den Sinkflug, würde ich sagen. Und/oder: Tim . schrieb: > Von bidirektionaler Verbindung kann allerdings nicht die Rede sein. Entweder man nimmt für den Rückkanal einen separaten Empfänger oder muss auch noch die FB hacken, damit der SOC ("state-of-charge") empfangen und angezeigt wird. Sensoren (Strom und Spannung) für die SOC-Messung müssten dann natürlich rein. Aber dafür gibt's ja fertige 1-Chip-Lösungen. Manuel Steiner schrieb: > Wenn ich Zeit habe, werde ich mal testen, wie sich das mit > unterschiedlichen Bodenbeschaffenheiten verhält. Danke, das interessiert mich sehr! Tim . schrieb: > Ultraschall bietet sich dabei an. Die 1€-Ultraschallsensoren aus China wiegen 8,3 Gramm und reichen von 60mm bis max. 4700mm: HC-SR04. Also bis zur Zimmerdecke gibt's sichere Messwerte. Tim . schrieb: > Vielleicht hilft ein Kompass oder ein Drucksensor ja auch? Kompass: Hilft m.E. nur beim Gierwinkel, der ist aber nun wirklich schon jetzt super stabil. Drucksensoren sind recht ungenau (vielleicht 50..500cm?), das bringt wohl leider nicht viel. Tim . schrieb: > Dann wäre es natürlich spannend das Ding vom PC aus zu kontrollieren. Den Hintergedanken hatte ich bei Bluetooth ^^ auch. Neben mehr Reichweite hat man auch den Rückkanal für den SOC ^^ und für Fotos vom Parkplatz. ^^ Tim . schrieb: > Mir persönlich geht es einfach auch darum ein komplettes System zum > lernen zu haben. Ich denke, das ist eigentlich die treffenste Antwort auf die Frage von "der_leser". Wo bekommt man schon für 20€ eine so spannende Lernumgebung?
Torsten C. schrieb: > Tim . schrieb: >> Von bidirektionaler Verbindung kann allerdings nicht die Rede sein. > > Entweder man nimmt für den Rückkanal einen separaten Empfänger oder muss > auch noch die FB hacken, damit der SOC ("state-of-charge") empfangen und > angezeigt wird. Sensoren (Strom und Spannung) für die SOC-Messung > müssten dann natürlich rein. Aber dafür gibt's ja fertige > 1-Chip-Lösungen. [Edit: verlesen] Ja, die Fernbedienung müsste man dann auch hacken. Kann jemand ein Bild des Controllers machen? War auch von Nuvoton, ich kenne den Typen allerdings nicht.
:
Bearbeitet durch User
Hatte die schonmal zerlegt, die Bezeichnung hat bei mir mit googles Hilfe absoulut keine Ergebnisse gebracht. Nur der große Nuvoton Schriftzug ist sinnvoll.
Torsten C. schrieb: > Tim . schrieb: >> Ultraschall bietet sich dabei an. > > Die 1€-Ultraschallsensoren aus China wiegen 8,3 Gramm und reichen von > 60mm bis max. 4700mm: HC-SR04. Also bis zur Zimmerdecke gibt's sichere > Messwerte. Ich habe mit den billig dingern eher andere Erfahrung gemacht. Entweder sie spuckten nur max ~70cm aus oder lieferten bei größeren Entfernungen unsinnige Ergebnisse. Keine Ahnung ob das bei den "teureren" Modulen besser ist. > Tim . schrieb: > Drucksensoren sind recht ungenau (vielleicht 50..500cm?), das bringt > wohl leider nicht viel. Also ich verwende für meinen selbstgebauten Quadcopter den MPL3115A2. Der hat eine Auflösung von 0,3m bzw. 1,5 Pa. In der Praxis lässt sich mit Oversampling und ein bisschen Filtern so 50cm rausbekommen. Anbei mal Messungen die ich mit dem Ding zu Hause gemacht habe. Es ist also durchaus brauchbar. Ganz praktisch ist, dass man das teil bereits kompensierte Messwerte rausgibt (also nicht wie beim alten MPL115A2 bei dem man noch selbst die Koeffizienten und Temperatur über ein Polynom schicken musste). Zudem bekommt man bei der Eingabe des Luftdrucks auf NN auch direkt die Höhe in Metern raus. In der Praxis Pendelt der Copter dann so um 1m herum und man muss natürluch bedenken dass der Luftdruck sich auch innerhalb von ein paar Minuten so weit ändern kann, dass der Copter dann bereits einige Meter zu hoch oder zu niedrig ist. Hier könnte ein weiterer Luftdrucksensor in der Fernbedienung, der seinen Wert dann ebenfalls an den Copter sendet Abhilfe schaffen. So kann man praktisch die Differenzhöhe zwischen Copter und Fernbedienung recht konstant halten. Das wollte ich auch nochmal testen. Und wenn man die Reichweite noch etwas erhöhen will lann man in der Fernbedienung auch den nRF24L01 PA+LNA (max. 20dBm) einbauen. Das Protokoll ist ja kompatibel nur ist die Sendeleistung dann höher. Allerdings darf man hier in Deutschland IMHO nicht die 20dBm ohne FHSS/DSSS benutzen. Aber selbst mit 10mW kommt man schon ne Ecke weiter.
Timmo H. schrieb: > lieferten bei größeren Entfernungen unsinnige Ergebnisse Ohne Filtern und plausibilisieren geht's gar nicht, klar. Das liegt an der Physik (nicht immer rechte Winkel, Multiechos, ...). Aber dass unsere Ergebnisse so unterschiedlich sind, wundert mich. Ich habe auch nur die billigen. Beste Ergebnisse erhielt ich mit 'ner Plexiglas- Platte (Strukturglas) mit dem Muster "Pyramid" vom Baumarkt. Ein Blumenbeet z.B. gibt naturgemäß schlechtere Werte. Daher bin auch ich von Ultraschall nicht so begeistert. Aber Luftdruck (50..100cm) empfinde ich als unbrauchbar. Bevor ich den Luftdruck per Funk sende, sende ich lieber DGPS-Daten. Damit habe ich nicht nur die Höhe genauer. Nur fehlt mir noch eine NMEA-Quelle mit geringer Masse. PS: Mit Ultraschall würde ich gegen die Zimmerdecke messen, nicht gegen den Fußboden und das was drauf steht (Tische, Stühle, Personen, ...).
:
Bearbeitet durch User
Torsten C. schrieb: > eine NMEA-Quelle mit geringer Masse Teuer aber 16 Gramm leicht: http://www.multiplex-rc.de/fileadmin/content/dateien/downloads/zr_gps_sensor_110214_5sp.pdf Kennt jemand 'ne preiswertere Alternative?
Torsten C. schrieb: > Daher bin auch ich von Ultraschall nicht so begeistert. Aber Luftdruck > (50..100cm) empfinde ich als unbrauchbar. Hängt davon ab. Für einen größeren Copter mit dem man draußen fliegt ist das ausreichend. > Bevor ich den Luftdruck per Funk sende, sende ich lieber DGPS-Daten. > Damit habe ich nicht nur die Höhe genauer. Naja die zwei Byte haben in in meinen 32 Byte nRF Datenpaketen schon noch übrig. Ich sende mit 100 Hz alle 7 Poti-Werte (je als 16 bit) und Taster meiner 9-Kanal Fernsteuerung. Da habe ich noch genug übrig. Von Copter zur Fernbedienung sende ich mit 10 Hz (Höhe, Lage, Batteriespannung...). > Nur fehlt mir noch eine > NMEA-Quelle mit geringer Masse. Also selbst die kleinen GPS Module die ich verwende (Maestro A2235-H) sind mit 4g zwar noch relativ leicht, aber für einen 38g Copter immerhin schon 10% mehr. Zudem halte ich GPS für so einen kleinen Copter eh für etwas übertrieben.
:
Bearbeitet durch User
Meine Meinung zum Luftdruck bezog sich auch auf meinen Honey Bee King 3 (HBK3). Timmo H. schrieb: > Für einen größeren Copter mit dem man draußen fliegt ist > das ausreichend. Das artet in eine Geschmackfrage aus, da werden wir uns nie einig. ;-) Timmo H. schrieb: > Naja die zwei Byte haben in in meinen 32 Byte nRF Datenpaketen > schon noch … … übrig? DGPS sind ja nun auch nicht wirklich viele Bytes. Im Grunde reicht ja ein Byte pro Achse (X/Y/Z), also drei Bytes. Oder 10 Bit pro Achse, macht 4 Bytes. Genauer ist DGPS eh nicht. Timmo H. schrieb: > Maestro A2235-H … mit 4g Falls Du untertrieben haben solltest: Kein Problem. Aber der "VK16U6" für 11€ aus China wiegt 12 Gramm (hatte ich mir schwerer vorgestellt). Da ist das Teil von Multiplex ja richtig schwer. (Wieso eigentlich? Sieht viel leichter aus.) Falls Du die 4g bitte nochmal bestätigen kannst, bedanke ich mich ganz herzlich und kaufe ich den! Kostet zwar soviel wie der QKopter, aber ich will ihn ja nicht unbedingt gleichzeitig im HBK3 und im QKopter haben. PS: Timmo H. schrieb: > Zudem halte ich GPS für so einen kleinen Copter eh für > etwas übertrieben. Welches Verhältnis hältst Du für übertrieben? Programmieraufwand, Preis, Gewicht, Nutzen, ...? Mich interessiert die Antwort wirklich, z.B. im Vergleich zu einer Kamera. Vielleicht bin ich ja auf dem Holzweg.
:
Bearbeitet durch User
Timmo H. schrieb: > Torsten C. schrieb: >> Daher bin auch ich von Ultraschall nicht so begeistert. Aber Luftdruck >> (50..100cm) empfinde ich als unbrauchbar. > Hängt davon ab. Für einen größeren Copter mit dem man draußen fliegt ist > das ausreichend. Wenn überhaupt – der Luftdruck ändert sich mit der Strömungsgeschwindigkeit, und damit vermutlich mit jeder Änderung der Rotordrehzahl oder Geschwindigkeit des Kopters.
Torsten C. schrieb: > > Timmo H. schrieb: >> Maestro A2235-H … mit 4g > > Falls Du untertrieben haben solltest: Kein Problem. Aber der "VK16U6" > für 11€ aus China wiegt 12 Gramm (hatte ich mir schwerer vorgestellt). Naja das ist das was im Datenblatt steht. > Falls Du die 4g bitte nochmal bestätigen kannst, bedanke ich mich ganz > herzlich und kaufe ich den! Naja, meine "hochgenaue" Küchenwaage sagt 5g :D > Kostet zwar soviel wie der QKopter, 11,90€ bei Mouser (exkl. MwSt) > Timmo H. schrieb: >> Zudem halte ich GPS für so einen kleinen Copter eh für >> etwas übertrieben. > > Welches Verhältnis hältst Du für übertrieben? Programmieraufwand, Preis, > Gewicht, Nutzen, ...? Mich interessiert die Antwort wirklich, z.B. im > Vergleich zu einer Kamera. Vielleicht bin ich ja auf dem Holzweg. Eher Nutzen. Mit so einem kleinen Copter kann man ja nicht so die wahnsinns Strecken aufgrund der begrenzten Geschwindigkeit und Flugdauer erreichen. Bei einem größeren Copter mit einer Vernünftigen Kamera kann es ja durchaus Sinnvoll sein die Position für 10-15 Minuten zu halten oder Coming Home bei schwachem Akku. Schnallt man aber auf den Winzling eine Kamera und GPS Modul dann ist die Flugzeit ja schon fast verstrichen bis er die Position erreicht hat (und heile nach unten muss er dann ja auch wieder). Oder was hattest du mit GPS bei dem Ding vor?
:
Bearbeitet durch User
Moritz A. schrieb: > und damit vermutlich mit jeder Änderung der > Rotordrehzahl oder Geschwindigkeit des Kopters. Ja, aber nicht die Höhe. Die Einflüsse auf die Luftdruckänderungen muss man natürlich heraus rechnen. Timmo H. schrieb: > Naja, meine "hochgenaue" Küchenwaage sagt 5g Geil! Danke. Timmo H. schrieb: > Oder was hattest du mit GPS bei dem Ding vor? Torsten C. schrieb: > Ich überlege immer noch, ob ich mir so ein Projekt ins Haus hole. An dieser Stelle nochmal vielen Dank für die informativen Beiträge. Wenn die SWD-Schnittstelle vom Disco ^^ funktioniert, dann habe ich ein neues Projekt. Nach oben eine 4-Pin-Buchsenleiste für - HC-SR04 für Indoor oder - GPS für Outdoor Unten drunter 'ne Handy-Kamera. Funk: Bidirektional, mit Bildübertragung. Härtetest: Bild vom Parkplatz übertragen und zurück zum Schiebedach des Autos finden. Ich habe mir viel vorgenommen, aber wenn der zweite QKopter von meinem Sohn da ist, wird meiner neu geflasht. Bittebitte: Lasst die SWD vom DISCO funktionieren. ;-) Timmo H. schrieb: > Flugzeit ja schon fast verstrichen bis er die Position erreicht hat OK, das werde ich testen, wenn die größeren LiPos aus China da sind (sind ja auch schwerer). Vielleicht wird ja doch nix aus meinem Projekt. PS: Hat jemand eine Ahnung, ob sich mit 'nem größeren Akku und mehr Gewicht ein anderer Propeller (Pitch/Durchmesser) lohnt? Ich habe davon keinen Plan. PPS: Und schon wieder so viele Typos, sorry:
:
Bearbeitet durch User
Und es funktioniert!! Ich habe es geschafft über Keil und ST-Link vom Discovery board auf den SWD-Port zuzugreifen. Um in Keil ohne Sourcecode debuggen zu können, musste ich die Setting kreativ ändern. Beispielprojekt anbei. Leider ist, wie erwartet, das Lesen des Code-Flash gesperrt - alle Positionen werden als 0xff ausgelesen. Interessanterweise lässt sich aber das SRAM auslesen, welches beim Reset nicht gelöscht wird. Im Hexdump lassen sich einige bekannte Werte finden:
1 | 0x200000B0 06 2C 66 88 68 68 68 88 - 66 86 86 86 00 00 00 00 |
Die sind die RX und TX Addressen der Fernbedienung. Damit scheint der Zugriff also zuverlässig zu funktionieren. Leider kenne ich mich mit den Möglichkeiten von SWD nicht sehr gut aus. Ist es z.B. möglich, Inhalte des SRAMs oder Registerinhalte zu verändern? Wenn ja, könnte man evtl. das Flash über das SRAM auslesen. Ginge das mit GDB? Bin für alle Info dankbar. Das Neuschreiben des Flash habe ich noch nicht probiert. Ich will erst einmal die Firmware retten.
:
Bearbeitet durch User
Torsten C. schrieb: > Bittebitte: Lasst die SWD vom DISCO funktionieren. ;-) Dein Bitten scheint geholfen zu haben :)
Tim . schrieb: > Und es funktioniert!! Geil!! Danke für die Info. Dann müsste es mit CooCox doch auch gehen, oder? Tim . schrieb: > Ich will erst einmal die Firmware retten. Entweder Ich hab's nicht verstanden, oder Du hast die Frage schon selbst beantwortet: Tim . schrieb: > For DataFlash, however, it is not easy to be protected > because it can be dumped by executing a program residing in APROM BTW: Bringt eigentlich 'ne Phycomp ISM-Band Chip-Antenne zusätzliche Reichweite? PS: Halte dich mit dem "Firmware retten" nicht auf. Wenn's geht, macht das bestimmt einer und postet die hier. PPS: Neuer Titel: "Hackbarer(!!!) 21 EUR Quadcopter". ;-)
:
Bearbeitet durch User
Tim . schrieb: > Und es funktioniert!! Hört sich doch wunderbar an :) Jetz kann ich es gar nicht mehr erwarten bis das Teil kommt.
Und was braucht man nun alles für Hardware um da einsteigen zu können?
Oliver Stellebaum schrieb: > Und was braucht man nun alles für Hardware um da einsteigen zu können? So wie es jetzt aussieht, kommt ein STM32 Discovery Board wohl am günstigsten. Über dessen SWD kann dann der Nuvoton MCU am Quadcopter geflasht werden.
Sind das diese kleinen Dinger die man letztes Jahr oder so für wenig Geld kaufen konnte?
Oliver Stellebaum schrieb: > Sind das diese kleinen Dinger die man letztes Jahr oder so für wenig > Geld kaufen konnte? Ja z.B. das STM32F$DISCOVERY, hat dann auch gleich selbst einen leistungsstarken MCU, falls man mit dem Discovery selber auch experimentieren will. http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF252419 Ich glaube Tim hat das STM32F0DISCOVERY verwendet. Dies hat einen MCU eher für weniger intensive CPU Anforderungen. http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF253215
Tim . schrieb: > Ich will erst > einmal die Firmware retten. Nur so eine Idee ich bin mir nicht sicher ob das klappt. Aber kann man nicht über SWD ein Programm in den Ram laden das dann den Flash ausliest? Der Cortex kann doch Code aus dem RAM ausführen?!
Torsten C. schrieb: > Entweder Ich hab's nicht verstanden, oder Du hast die Frage schon selbst > beantwortet: > > Tim . schrieb: >> For DataFlash, however, it is not easy to be protected >> because it can be dumped by executing a program residing in APROM Das Dataflash ist ein Teil des APROM. Das APROM will ich auslesen, daher kann ich es nicht beschreiben. Christopher B. schrieb: > Tim . schrieb: >> Ich will erst >> einmal die Firmware retten. > Nur so eine Idee ich bin mir nicht sicher ob das klappt. > Aber kann man nicht über SWD ein Programm in den Ram laden das dann den > Flash ausliest? Der Cortex kann doch Code aus dem RAM ausführen?! Genau daran habe ich gedacht. Es scheint aber nicht ganz so simpel zu sein. Denn wie führt man den Code dann aus? Manuel Steiner schrieb: > Ich glaube Tim hat das STM32F0DISCOVERY verwendet. Dies hat einen MCU > eher für weniger intensive CPU Anforderungen. Stimmt genau. Eigentlich sollte aber jedes STM32-Discovery-Board funktionieren, da der ST-Link Teil identisch zu sein scheint.
Tim . schrieb: > Stimmt genau. Eigentlich sollte aber jedes STM32-Discovery-Board > funktionieren, da der ST-Link Teil identisch zu sein scheint. Ja, von dem gehe ich auch aus.
Mist, das Ding was ich habe ist nur STM8. Muss ich wohl noch mal was kaufen. Naja, so teuer sind die Dinger ja nicht. Was braucht man denn noch so? Diese kleinen Stecklingskabel müssen wohl auch noch angeschafft werden.
:
Bearbeitet durch User
Oliver Stellebaum schrieb: > Mist, das Ding was ich habe ist nur STM8. Es gibt viele Board mit SWD-Debugger. Die Infineon XMC Boards könnten auch funktionieren, ebenso wie LPCXpresso
Das STM8 müsste ausreichen. Laut ST ist da wohl auch ein ST-Link drauf. Fraglich sit nur ob man einen ST-Link V2 brauch oder ob der ST-Link reicht. Falls es der V2 sein muss dann reich auch kein STM32VL Board.
Tim . schrieb: > Oliver Stellebaum schrieb: >> Mist, das Ding was ich habe ist nur STM8. > > Es gibt viele Board mit SWD-Debugger. Die Infineon XMC Boards könnten > auch funktionieren, ebenso wie LPCXpresso Ich glaube allerdings, dass das SWD an den STM8 Discovery Boards ein abgespecktes SWD ist, bzw. die Firmaware im dazugehörigen Chip abgespeckt ist und sich damit nur STM8 Teile programmieren lassen. Und zu den Kabeln. Ich glaube an den Discoveries ist das ein ganz normales 2,54mm Raster. Also sollte sich da schnell ein Header finden lassen.
:
Bearbeitet durch User
Oliver Stellebaum schrieb: > Diese kleinen Stecklingskabel müssen wohl auch noch angeschafft werden. Manuel Steiner schrieb: > Ich glaube an den Discoveries ist das ein ganz > normales 2,54mm Raster. Genau, siehe Foto ^^. Stichworte: "dupont jumper" oder "dupont wire" bei ebay oder aliexpress. Gehört eh in jede Bastelecke. ;-)
Ein Problem: Da sowieso ein Ersatzcopter auf dem Weg ist, habe ich gedacht dass ich ja auch das Flash löschen könnte. Leider ist das nicht so einfach: Keil gibt ein "Cannot Load Flash Programming Algorithm" aus. Evtl. ist für die Programmierung des Flash das Discovery Board doch nicht geeignet? Eine Möglichkeit ist noch Versaloon (neue Firmware für das Discovery Board), aber vielleicht geht es auch noch anders...
Bei Keil lassen sich die Algorithmen im Target Driver Setup einstellen. Ich habe nur überhaupt keine Ahnung ob da für Nuvoton etwas dabei ist oder nicht.
Hey, macht keinen Mist :-) Hab mir jetzt so ein Discoveryboard bestellt und die kleinen Kabel. Will doch wenigstens mal die 4 Motoren nach meiner Pfeife tanzen lassen. Na mal im Ernst, ein simples "stillstehen" über einen Magnetfeldsensor oder sowas wäre schon cool. Also so ein "Luftnagel".
:
Bearbeitet durch User
Tim . schrieb: > Da sowieso ein Ersatzcopter auf dem Weg ist, habe ich gedacht dass ich Ich hab tonsee_mall geschrieben und der schickt mir einen neuen, btw. Wo kommt dein Ersatz her?
Tim . schrieb: > Keil gibt ein "Cannot Load Flash Programming Algorithm" aus. Vielleicht ist das LOCK-Bit im Config0-Register gesetzt (Seite 128 vom Datenblatt): Security Lock 0 = Flash data locked. 1 = Flash data unlocked. When flash data is locked, only device ID, unique ID, Config0 and Config1 can be read by writer and ICP through serial debug interface. Other data is locked as 0xFFFFFFFF. ISP can read data anywhere regardless of the LOCK bit value. "writer and ICP" soll wohl das SWD-Interface oder Parallel-/Gang-Programmer sein. Aber da du ja zumindest vom RAM lesen kannst... Kannst ja mal versuchen Config0 zu lesen (Adresse 0x00300000). Vielleicht kannst es ja auch umschreiben falls das Bit gesetzt ist :-) ISP ist der Bootloader. Könnte mir vorstellen, dass ein selbst gestrickter drauf ist welcher über die UART läuft (aber wird schwer raus zu finden wie der läuft).
Ich hab da noch etwas gefunden ... http://www.nuvoton-m0.com/forum.php?mod=viewthread&tid=1311&extra=page%3D3 The full erase procedure is part of ICP waveform, which shares the same pins of SWD(serial wire debug), but is not SWD. Der Thread Owner hat dann aber irgendwie geschrieben: EDIT: I found a way to use the ICP tool as a workaround. Er schreibt aber nicht, welches Hardwaretool er dafür einsetzt und wie er das Ganze dann gemacht hat. Edit: Vielleicht funktioniert das mit dem ICP Tool und mit dem normalen SWD, man kanns ja mal probieren...
:
Bearbeitet durch User
Manuel Steiner schrieb: > Ich hab da noch etwas gefunden ... Ich verstehe das so, dass es über ICP/SWD geht aber irgendwas spezielles über SWD gemacht wird. Das würde bedeuten, dass man die Nuvoton hardware zum Löschen bräuchte denke ich.
Marius S. schrieb: > Manuel Steiner schrieb: >> Ich hab da noch etwas gefunden ... > > Ich verstehe das so, dass es über ICP/SWD geht aber irgendwas spezielles > über SWD gemacht wird. Das würde bedeuten, dass man die Nuvoton hardware > zum Löschen bräuchte denke ich. Wenn wir Glück haben, ist die Hardware nicht relevant und das Ganze geschieht in der ICP Software. Ich kanns mir aber leider auch irgendwie nicht so vorstellen, dass es mit normaler SWD Hardware funktioniert. Edit: Ich vermute auch mal, dass die ICP Software schon mal die Discovery Hardware erkennen wird, wenn man sich das mal überlegt. Ich glaube auch, dass Marius da recht hat.
:
Bearbeitet durch User
Manuel Steiner schrieb: > Ich hab da noch etwas gefunden ... > > http://www.nuvoton-m0.com/forum.php?mod=viewthread&tid=1311&extra=page%3D3 Hi Manuel, das ist ein Super-Fund! Jetzt verstehe ich auch, wo das Problem ist: Die Programmierung des Flash läuft normalerweise (z.B. unter µVision) so, dass per SWD ein kleines Programm ins SRAM geladen wird, welches anschließend das Schreiben des Flash übernimmt. Die Quellcodes sind sogar in µVision vorhanden und werden mit der Software mitinstalliert (Habe ich mal angehängt). Im gesperrten Zustand ist es aber nicht möglich das SRAM zu beschreiben, so dass das Löschen anders geschehen muss. Inzwischen habe ich herausgefunden, dass sich die Flash Control Register (ab 0x5000c000, 5.7.5 im Manual) zumindest teilweise per SWD beschreiben lassen. Diese Register werden normalerweise von der Software zur Programmierung des Flash verwendet. Gut möglich, dass "erase" im ICP Modus über einen direkten Registerzugriff erfolgt. Jetzt gibt es ein paar Möglichkeiten um weiter zu machen: - Nuvton anbetteln die Spezifikation herauszugeben (wahrscheinlich aussichtslos) - Alternative Software suchen, die Erase im ICP-Modus für die MINI51-Serie anbietet. OpenOCD, CooCox? - Vielleicht hat inzwischen jemand das Protokoll analysiert? Und im Netz etwas veröffentlicht? - Nu-Link kaufen und das Protokoll selbst analysieren.
:
Bearbeitet durch User
Also ich glaube ich werde da mal in die Tasche greifen und ein Nulink besorgen. Kostet ja nicht die Welt. Wenn danach ein funktionierendes System zur Verfügung steht, hat sich das meiner Meinung nach schon gelohnt. Weil ob z.B. Versaloon auf den Discoveries mit den Nuvoton Teilen funktioniert usw. ist ja auch nicht wirklich sicher. Und ich glaube eben auch wirklich, dass man für das Löschen da mal mit dem ICP Tool arbeiten muss. Und wenn das am PC kein Nulink findet wird das wohl seinen Dienst verweigern.
:
Bearbeitet durch User
http://dx.com/p/hubsan-h107-a18-value-pack-for-hubsan-x4-h107l-r-c-quadcopter-256313 zufällig gefunden...
Manuel Steiner schrieb: > Also ich glaube ich werde da mal in die Tasche greifen und ein Nulink > besorgen. Wo gibt's den? falls das zu zweit/dritt oder so billiger wird, würde ich mich anschließen. Ich kann mir auch vorstellen, für andere Projekte einen der unterstützten Nuvoton µC einzusetzen, falls man mal billig an geringe Stückzahlen kommt: http://www.coocox.org/NuLink.htm Bei Aliexpress habe ich noch keine gefunden, aber das ist ein anderes Thema. Wo bestellst Du den Nulink?
Würde es einen Unterschied machen wenn ich es mit meinem J-Link versuche? Der kann soweit ich weiß die Nuvoto von Haus aus. Muss ich mal schaun ob ich morgen Zeit dazu habe..
Tim schrieb: > Jetzt gibt es ein paar Möglichkeiten um weiter zu machen Ich habe noch eine: Für 2€ bei dikigey einen neuen MINI54ZAN bestellen, und den alten incl. Original-Firmware auslöten. Timmo H. schrieb: > Gibts bei Digikey Ah, danke. Also könnte es sich lohnen, nicht allein zu bestellen, falls man nicht eh über 65€ kommt. Es gibt - "NU-LINK-PRO" (46,54€), - "NU-LINK" (33,94€) und - "ULINK-ME" (49,38€ bei Mouser) Auf der CooCox-Seite ^^ ist auch noch ein "NuLinkMe"(?!) erwähnt. Hat einer von Euch den Überblick, was man am besten bestellt, damit man auch über das Quadcopter-Projekt hinaus danach noch einen Nutzen hat? µCs von Nuvoton mit ARM Cortex-M0 gibt's ja schon ab 1,60€.
No y. schrieb: > Würde es einen Unterschied machen wenn ich es mit meinem J-Link > versuche? > Der kann soweit ich weiß die Nuvoto von Haus aus. > > Muss ich mal schaun ob ich morgen Zeit dazu habe.. Das wäre toll, wenn du das versuchen könntest. Jede Erfahrung bringt einen weiter. Ich habe nur wirklich so das Gefühl, dass man wie Tim auch schon geschrieben hat, wegen dem Lockbit nichts in den RAM schreiben darf, und deswegen die von Keil verwendete erase Routine nicht verwenden kann. Dafür muss man dann wohl das ICP Tool verwenden welches wahrscheinlich auch nur mit Nulink bzw Nuvoton SDKs mit integriertem Nulink funktioniert. Torsten C. schrieb: > Tim schrieb: >> Jetzt gibt es ein paar Möglichkeiten um weiter zu machen > > Ich habe noch eine: Für 2€ bei dikigey einen neuen MINI54ZAN bestellen, > und den alten incl. Original-Firmware auslöten. Geht natürlich auch, nur wird sich das wahrscheinlich nicht jeder zutrauen bzw. machen wollen. Es hatten ja auch schon Leute wegen Einsteiger-, Lernplattform ein Auge auf den Quadcopter, soweit ich das mitbekommen habe. > Hat einer von Euch den Überblick, was man am besten bestellt, damit man > auch über das Quadcopter-Projekt hinaus danach noch einen Nutzen hat? nosilent und ich werden vermutlichen den Pro bestellen. Ich habe zwar keine Ahnung ob man das ganze wide voltage settings Zeug braucht, aber die paar Euro sollen dann auch nicht das Problem sein. Von den Nulink ME hab ich nur gelesen, dass die alle auf den Nutiny SDK Kits oben sind, wovon es zumindest ein paar gibt, die nämlich ICP nicht unterstützen. Also ist hier Vorsicht geboten. Dass es das Teil auch standalone gibt, hatte ich nicht gewusst. Wenn der Nulink dann mal da ist, bzw. der Quadcopter auch, würd ich dann natürlich auch mal Logic Analyzer usw anhängen, um evtl. den erase Prozess zu analysieren. Vielleicht lässt sich ja eine Software machen, die über das Discovery SWD oder andere SWD dann auch löschen kann. Falls das in irgend einer Form möglich ist. Da der Quadcopter allerdings noch nicht da ist kann das noch eine Weile dauern. Falls sich noch er dazu entschließt, einen Nulink zu besorgen, und auch den Quadcopter bereits zu Hause hat, kann da natürlich auch schon mal analysieren :) Bezüglich Sammelbestellung weiß ich nicht so genau. Ich werde nämlich mit nosilent bestellen und ich schätze wird kommen über den Mindestbestellwert. Da das ganze über ihn geht, kann ich dazu leider nichts sagen.
:
Bearbeitet durch User
Da hat sich ja einiges getan! Ein paar Sachen sind mir noch eingefallen: - Das Nu-Link ist Teil der Nuvoton Evaluation kits (Wie beim Discovery). Die sind teilweise billiger als ein einzelnes Nu-Link im Gehäuse. Distributor in Deutschland ist Atlantik Elektronik: https://webshop.atlantikelektronik.de/index.php/cat/c794_Evaluation-Kits.html Habe mich mal registiert, mal sehen ob man dort bestellen kann. Das neue Kit zum MINI51F interessiert mich sowieso. - Der aktuelle Master branch von OpenOCD unterstützt die mini51 serie. Vielleicht klappt es damit ja besser. Sieht nur aus, als wenn man sich das selbst compilieren muss. http://openocd.sourceforge.net/doc/doxygen/html/mini51_8c_source.html
Danke für die Infos, Manuel. :-) Manuel Steiner schrieb: > … würd ich dann natürlich auch mal Logic Analyzer usw anhängen … > Vielleicht lässt sich ja eine Software machen, > die über das Discovery … auch löschen kann. Den Gedanken hatte ich auch schon. Man kann ja auch den Target-µC vom Disco entsprechend programmieren. Das ist ja vermutlich kein komplizierter Vorgang. Toll dass Du das anbietest. Dann warte ich mit dem Nulink erstmal, bis Du (oder evt. jemand anders vor Dir) ein Ergebnis hat. Für_mich hat sich damit auch erstmal die Frage nach der Sammelbestellung erledigt.
Tim schrieb: > - Das Nu-Link ist Teil der Nuvoton Evaluation kits (Wie beim Discovery). Richtig, nur bitte passt auf, welches ihr bestellt, wenn ihr eines bestellt. Denn mindestens von 2 hab ich schon in irgend einer Präsentation von Nuvoton gelesen, dass die NICHT ICP unterstützen obwohl da ein Nulink ME drauf ist. Edit: http://www.ie.ksu.edu.tw/data/nuvoton/Training%20Material/NuMicro%20NUC100%20Series/13_NuMicro%20Nuvoton%20Tools.pdf Folie 22: Nutiny SDK 100, Nutiny SDK 120: No ICP
:
Bearbeitet durch User
Tim schrieb: > Atlantik Elektronik Die kosten alle 25,45€ bei Digikey. Ob die bei Antlantik nennenswert billiger sind? Wenn NUTINY-SDK-NUC120 und NUTINY-SDK-NUC100 nicht in Frage kommen, bleiben für den gleichen Preis: - NUTINY-SDK-NUC123 - NUTINY-SDK-NUC140 - NUTINY-SDK-NUC122 - NUTINY-SDK-MINI51 - NUTINY-SDK-NUC200 - NUTINY-SDK-NUC220 - NUTINY-SDK-NANO100 und - NUTINY-SDK-M051
Torsten C. schrieb: > - NUTINY-SDK-M051 hat glaub ich laut Atlantik Homepage auch keine ICP Funktion
Hm... stimmt. Eigentlich merkwürdig, da das Nu-link selbst im wesentlichen auch nur aus einer MCU besteht. Die Schaltung gibt es ja auf der CooCox Website. Es kann sich also nur um eine andere Firmware handeln.
Manuel Steiner schrieb: > hat glaub ich ... auch keine ICP Funktion Ich schätze, das gilt für alle in der Preisklasse. Seite 10 ^^ interpretiere ich so, dass debuggen nur mit ISP und programmieren des LDROMs nur mit ICP geht. Braucht man also zwei unterschiedliche "Adapter", wenn man beides will?
:
Bearbeitet durch User
Torsten C. schrieb: > Seite 10 ^^ interpretiere ich so, dass debuggen nur mit ISP und > programmieren des LDROMs nur mit ICP geht. Braucht man also zwei > unterschiedliche "Adapter", wenn man beides will? ISP is glaub ich Bootloader über seriell. Da braucht man gar keine extra Hardware. Mit ICP kann man glaub ich und hoff ich doch alles machen :)
Manuel Steiner schrieb: > Mit ICP kann man glaub ich und hoff ich doch alles machen :) Nein, CPU Run Code = "No" auf Seite 10 ^^ Aber wohl trotzdem mit dem Nu-Link, über die USB <-> SWD bridge Sorry, erst eben genau gelesen.
Da man mit ICP alle Bereiche schreiben kann und der eigentliche Applikationscode im APROM liegt, geh ich davon aus, dass das funktioniert :)
Meiner ist grade angekommen: http://www.ebay.de/itm/171129650792?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649 Scheint zwar die gleichen Komponenten verbaut zu haben. Leider ist das Layout geändert, ist nur noch einseitig, und es ist vom Nuvoton Mini54ZAN nix rausgeführt. Daher ist dieses Modell nicht gut zum Hacken geignet... Ich werde testen ob es auch das V2X2 Protokoll spricht. EDIT: mal genauer schaun... Auch hier ist offensichtlich der SWD Port rausgeführt. Auf der Unterseite als Testpads... Könnte sich von daher auch eignen.
:
Bearbeitet durch User
Kille H. schrieb: > Leider ist das Layout geändert, ist nur noch einseitig Der sieht für mein Empfinden eh komplett anders aus. Ich würde nicht sagen "geändert" sondern "anders implementiert". Das kommt davon, wenn man aus "Frankfurt, Deutschland" bestellt. ;-) Spaß beiseite: Klingt interessant, kannst Du davon auch mal so gute Fotos posten?
:
Bearbeitet durch User
Kille H. schrieb: > Meiner ist grade angekommen: Habe auch in "Frankfurt" bestellt. Wie lange hast du gewartet?
Wie kann man denn die "RB...CN" Nummer tracken die man vom Versandhändler aus China EBay bekommt? Hat das bei euch geklappt?
Manchmal kann bei die bei dhl.com tracken, aber nur bis es beim deutschen Zoll ankommt.
Ja geht mit DHL. Hängt immer etwas davon ab wie weit. Manchmal nur bis "Die Sendung wird ins Zielland transportiert..." manchmal noch bis "Die Sendung ist im Zielland eingetroffen. (IPZ-Ffm, Deutschland)". Danach ist aber immer Schluss. Oftmals dauert es aber schon 5-10 Tage bis du die Nummer überhaupt tracken kannst. Hier geht oftmals mehr: http://track-chinapost.com/startairmail.php
Hallo, ihr sucht doch einen ISP-Adapter, das hier könnte was sein: http://www.aliexpress.com/item/Free-Shipping-NuLink-BuLink-Compatible-Cortex-M0-M051-ISP-ICP-Program/674565728.html Gruß Stefan
wow, wie viele sind denn hier Frankfurter? da lohnt sich ja evtl. eine "Frankfurter"-sammelbestellung :)
Naja bei 0€ Versandkosten lohnt das eher nicht, weil du dann schnell über die Freigrenze hinaus kommst.
Stefan V. schrieb: > ihr sucht doch einen ISP-Adapter, das hier könnte was sein: > > http://www.aliexpress.com/item/Free-Shipping-NuLink-BuLink-Compatible-Cortex-M0-M051-ISP-ICP-Program/674565728.html > > Gruß > Stefan Sehr interessant, danke! Mich macht nur stutzig dass die Software von 2011 sein soll und der MINI51 nirgendwo erwähnt wird. Ich habe mal beim Verkäufer angefragt.
Nuvoton veranstaltet mir den Programmieradapter ja wirklich ein ziemliches Verwirrspiel. Ich werde erst einmal ein Discovery-Board mit Versaloon flashed und sehen, ob ich damit weiter komme.
So hab jetzt nur mal ein Foto von der Rückseite. Macht echt Spaß der kleine. Die Funke ist nur ein graus. Ich hoffe ich komme am we dazu meine auf das vermutliche Protokoll umzubauen.
Kille H. schrieb: > So hab jetzt nur mal ein Foto von der Rückseite. Du machst es aber spannend. Die andere Seite ist interessanter :)
Ich kann es kaum noch erwarten bis das teil da ist :) ich hab das ganze hier verfolgt , wann kann jemand sagen was ich brauch um damit zu lernen ? (Programmieren)
Schönen Abend :) Nur kurz zur Info. Ich hätte mich mal im Nuvoton M0 Forum registriert und gefragt ob man das Protokoll bzw. Timing Diagramm für ICP erase bekommen kann. Wie Tim allerdings schon vermutet hat wird da nichts rausgerückt. Der admin meinte nur, er kennt es Protokoll auch nicht und ich soll meinen Distributer fragen ... Bleibt wohl nur, das Ganze wirklich über Nulink zu analysieren. Vielleicht hat man ja Erfolg. Zu den Aliexpress Teilen. Mich macht das skeptisch, weil dort ISP steht. ISP is ja bei Nuvoton der serielle Bootloader. Es kann ja durchaus sein, dass irgendwelche anderen Chinesen oder so das ICP Zeug schon nachgebaut haben und es mit diesem Teil funktioniert, den gelockten Flash zu löschen. Es kann aber denke ich genau so gut sein, dass es mit diesem Teil auch nicht funktioniert.
So weit ich das hier bisher mit gelesen habe, ist es noch nicht ganz so weit. Aber es sieht zumindest vielversprechend aus. --- Kleines Update von meiner Seite: Meine sind heute auch angekommen, am 21.09. bestellt. Interessant: Zollaufkleber auf dem Paket gab an "zollamtlich bearbeitet", habe aber keine Karte oder sonst was bekommen, hat lediglich ca. eine Woche länger gebraucht als ein paar andere CN Bestellungen, die ich etwa zeitgleich (größtenteils später) aufgegeben hatte ...
Turbonator schrieb: > Ich kann es kaum noch erwarten bis das teil da ist :) ich hab das ganze > hier verfolgt , wann kann jemand sagen was ich brauch um damit zu lernen > ? (Programmieren) Das ist im Moment noch etwas unklar, was jetzt wirklich alles genau benötigt wird. Mit einem original Nulink Programmer und dem ICP Tool wird es aber wahrscheinlich funktionieren. Zumindest ist das doch sehr stark anzunehmen :)
Gut dann gibt es halt eine Spielpause Ich finde den jetzt nicht besonders agil. Aber im Vergleich zu meinen WL9x9 find ich das regelverhalten deutlich besser.
Kille H. schrieb: > Gut dann gibt es halt eine Spielpause > > Ich finde den jetzt nicht besonders agil. Aber im Vergleich zu meinen > WL9x9 find ich das regelverhalten deutlich besser. Also sieht aber schon so aus, als wäre da SWD nach außen geführt.
Kille H. schrieb: > Gut dann gibt es halt eine Spielpause > > Ich finde den jetzt nicht besonders agil. Aber im Vergleich zu meinen > WL9x9 find ich das regelverhalten deutlich besser. Danke! Das Board ist ja noch spartanischer. Der SWD-Port scheint tatsächlich herausgeführt zu sein.
So jetzt auch vom PC aus... Ich denke auch. Auf der Unterseite sind die Pads sogar beschriftet. Insgesammt find ich das Board eigentlich pfiffiger ist, bis auf den Quarz. Warum zweiseitige Bestückung wenns auch einseitig geht ;-)! Der Controller ist definitiv der gleiche, den MPU6050 konnte ich nicht hundertprozentig erkennen, den nrf24L01 nachbau gar nicht. Die Change steht allerdings gut, das die Boards sonst gleich sind!
Nachtrag: Auch, wenn es wahrscheinlich schon hinreichend bekannt ist: das kleine Ding macht höllisch Spass ! [Und das für ~ 20€ ... da habe ich schon öfter schlechtere Unterhaltung für deutlich mehr Geld ertragen.] Die Steuerung ist frickelig, die Kalibrierung erlaubte mir auch nach mehrmaligen Versuchen auf einem (lt. Wasserwaage) absolut planen Untergrund keinen sauberen Senkrechtflug ["in der Luft stehen"], ich muss höllisch viel und sehr sorgsam nachregeln, um das kleine Teil halbwegs sicher durch die Luft zu bewegen. Aber nachdem ich eben das erste Mal einen vorprogrammierten Backflip [Knopf oben rechts an der FB halten, dann rechtes Steuerkreuz bis zum Anschlag nach unten ziehen] gesehen habe, bin ich restlos begeistert. Das kleine Teil hat einen recht aggressiven Backflip auf kleinstem Raum hingelegt. Nicht schlecht für so einen "billigen Klon" ...
Hatte eigentlich schon jemand Erfahrungen mit den alternativen Akkus sammeln können ? Vor allem würde mich interessieren, wie sich die in passender Baugrösse erhältlichen, grösseren Modelle schlagen. Es gibt ja welche mit 340 mAh bis hin zu einem "Monster" mit 750 mAh, all diese werden als "Hubsan X4 compatible" beworben. Wäre interessant, wenn sich damit die Airtime erhöhen liesse.
Ich benutze meine vorhandenen CB100 Akkus. Sind leicht größer, also leider zu breit aber mit einem Gummi kann man die einfach unten drunter hängen. Fliegt damit ganz gut. Haben 3,7V mit 420mAH laut Aufschrift. Die gibts günstig bei Ebay. Hier zb: http://www.ebay.de/itm/NEW-6x-3-7V-400mAh-20C-RC-MINI-Lipo-Battery-FOR-Walkera-4-3B-4G6-4-6-LAMA2-CB100-/300928044632?pt=Radio_Control_Parts_Accessories&hash=item4610b58e58 sind aber halt ein wenig zu breit... aber geht mit nem Gummi...
Klingt ja gut. Lädst Du die auch über das "Hubsan" Ladegerät, oder hast Du dafür ein separates ? Wie sieht es mit Gewicht und Flugzeitgewinn aus ?
Ich lade die über das Ladegerät vom CB100. Ist halt ein Schaltnetzteil. Lade ungern was über meine USB buchsen... Aber sollte wohl auch funktionieren. Vielleicht mit nem 230V auf USB Netzteil und dann das Hubsan dingen. Dauert aber eventuell länger.. Gewicht ist laut Briefwaage 3g schwerer als der "original" Hubsan also 12g. Ob da jetzt die Flugzeit verlängert wird, kp. Denke mal ja. Aber bin dafür noch zu wenig geflogen. Hab erst eine Akku Ladung verflogen bei jeweils einen Akku. Aber selbst wenn.. bei den 13Stück die ich hier rumliegen habe kann ich immer wechseln..
Ich hab ihn mit den Akkus von meinem Helikopter fliegen lassen. Der hat nur 240mAh und ist deutlich kleiner und ich denke auch deutlich leichter. Mit dem Akku macht er noch mal deutlich mehr Spaß. Da ist er agiler, gute Steigleistung aber der Spaß ist natürlich recht schnell wieder vorbei ;-(! Ich hab auch noch andere Akkus, bei meinem passt der Originale schon kaum rein bzw raus. Wirklich zum wechseln ist das so nicht. An drunter schnallen hab ich auch schon gedacht. Dann bezüglich der Kapazität die auf dem Akku steht. Ich hatte verschiedene Akkus für meinen Helikopter. Leider koreliert die Angabe auf dem Akku nur unzureichend mit dem was das Ladegerät anzeigt. Erfahrungsgemäß häufiger mit der Größe. Gerade "Tuning" akkus mit gleicher größe und wunder wie viel mAh waren bei mir keinen deut besser als die Originalen. Ich tendiere lieber zu kleineren. Sind nicht viel teurer pro mAh und der flugspaß ist besser. Ich werde schauen das ich meine 240mAh akkus aus dem Genius CP gut und einfach verwenden kann. Hier passen die Originalen halbwegs, die größeren Akkus fast durch die Bank nicht. Ach ja, es scheint jetzt auch den JD-185 direkt von Frankfurt aus zu geben: http://www.ebay.de/itm/171097513221?ssPageName=STRK:MEWAX:IT&_trksid=p3984.m1423.l2649 Grüße
Danke für die Infos, insbesondere an noy. Denke, ich werde dann auch mal mein Glück mit den breiten CB100er Akkus versuchen, der Preis ist ja auch absolut ok und mit 6 Stück gibt's dann auch genügend Reserve.
Der Akku hier hat exakt die selben Maße und den passenden Steckverbinder. Ist in Hobbykings EU Warehouse (Holland) verfügbar (Versand ab 2.80, kein Zoll). http://www.hobbyking.com/hobbyking/store/uh_viewItem.asp?idProduct=36235 Liegt vor mir und ist für gut befunden.
Tim schrieb: > Stefan V. schrieb: >> ihr sucht doch einen ISP-Adapter, das hier könnte was sein: >> >> > http://www.aliexpress.com/item/Free-Shipping-NuLink-BuLink-Compatible-Cortex-M0-M051-ISP-ICP-Program/674565728.html >> >> Gruß >> Stefan > > Sehr interessant, danke! Mich macht nur stutzig dass die Software von > 2011 sein soll und der MINI51 nirgendwo erwähnt wird. Ich habe mal beim > Verkäufer angefragt. Inzwischen habe ich die Antwort vom Verkäufer. Angeblich werden MINI51, ICP und chip erase unterstützt. 100% überzeugt bin ich noch nicht, habe aber mal einen programmierer bestellt.
:
Bearbeitet durch User
Mein Quadcopter schaltet sich immernoch ab und zu einfach schlagartig aus. Nachdem er sich ausgeschaltet hat habe ich mal die LiPo-Spannung gemessen und die war so bei 3,6 Volt. Wenn ich dann nochmal Gas gebe bricht die Spannung auf 2,9 Volt ein und da schaltet er sich auch wieder ab. Der Spannungsregler hat eine maximale DropOut-Spannung von 680mV. Wundert mich überhaupt, dass die Elektronik bis runter auf 2,9 Volt Batteriespannung noch läuft. Wäre auf jeden Fall gut, wenn die Firmware mitbekommen würde, dass die Akkuspannung zusammen sackt und Gas weg nimmt. Ich frage mich ob das an meinem Akku liegt, denn zu Anfang hat er sich noch nicht so oft schlagartig ausgeschaltet? Habe den Akku dann mal geladen. Danach habe ich eine Spannung von 4,24 Volt gemessen. Sind die 40mV zu viel schon schädlich für den Akku?
Die 40mV sind zu viel. Allerdings wird das bei fast allen billigen ladegaraten die ich hier so rumfliegen hab so gemacht. Ich schätze einfach, das der langer fliegt. Aber die Akkus sind so billig, da ist mir das egal ob der 50 oder 500 Zyklen hält.
Tim schrieb: > 100% überzeugt bin ich noch nicht, habe > aber mal einen programmierer bestellt. Find ich gut. Wie gesagt, ich werde mir mal trotzdem den Nulink besorgen. Wenn der Nachbau von Aliexpress auch funktioniert, können wir uns das ja möglicherweise mit der Analyse des erase Protokolls sparen. Bei dem Preis lohnt sich dass dann ja schon fast nicht mehr da recht viel Zeit zu investieren. Falls der Nachbau nicht funktioniert, wird wohl reverse engineered :) Aber ich drücke auf jeden Fall die Daumen. Denn wenns funktioniert hat man mit rund 30€ doch eine recht tolle Lernplattform bzw. Experimentierplattform wie ich meine.
ISP ist im Datenblatt beschrieben und SW dafuer kann man runterladen. ICSP benutzt IAP ueber SWD, Kail hat dazu Beispielsourcen.
Chris schrieb: > ISP ist im Datenblatt beschrieben und SW dafuer kann man runterladen. > ICSP benutzt IAP ueber SWD, Kail hat dazu Beispielsourcen. Also soweit wir alle hier glauben muss Keil für erase ein Programm in den RAM laden. Und das darf Keil aber nicht wenn der Flash gelockt ist. Also muss das ICP Tool verwendet werden um den MCU zu entsperren und zu löschen. Oder funktioniert IAP anders? Und ISP ist laut Tim auch gesperrt. Wäre ja auch zu schön ohne extra Hardware über seriell flashen zu können :) Falls ich mich jetzt komplett irre, bitte korrigiert mich.
:
Bearbeitet durch User
Manuel Steiner schrieb: > … hat man mit rund 30€ doch eine recht tolle Lernplattform bzw. > Experimentierplattform wie ich meine. Full Ack! Das wäre ein Tipp für viele Schulen mit Arbeitsgemeinschaften. Manuel Steiner schrieb: > Ich habe soeben ein paar Samples von 3020, 4010 und 4020 erhalten. Hast Du die schon mal ausprobiert? Ich weiss nicht, ob Oekel am Montag wieder bei Mouser bestellt. Die sind alle lieferbar, kosten 2,50€ und haben I²C, 16 bit und 1..200mm. Und nun? Zur not bestelle ich auch jeweils einen.
Torsten C. schrieb: > Hast Du die schon mal ausprobiert? Nein, sorry. Ich hoffe ich komme demnächst dazu. 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.
Manuel Steiner schrieb: > Wir müssen mal schauen wo wir die auflöten. OK, dann nehme ich ein paar VCNL4010. Der Pin-Abstand ist etwas größer und damit leichter zu löten. Ansonsten habe ich nur in "Fig. 3 - Proximity Value vs. Distance" einen leichten Unterschied gefunden. Der VCNL4010 kann vielleicht bei geringeren Abständen noch etwas besser messen. Die Sensoren sind nämlich dichter beieinander (2,47mm statt 3,46mm). Der VCNL3020 hat keine "ambient light photo-pin-diode". PS: Ich lasse mir bei Jakob ein paar "Breakouts" dafür machen.
:
Bearbeitet durch User
Manuel Steiner schrieb: > Chris schrieb: >> ISP ist im Datenblatt beschrieben und SW dafuer kann man runterladen. >> ICSP benutzt IAP ueber SWD, Kail hat dazu Beispielsourcen. > Falls ich mich jetzt komplett irre, bitte korrigiert mich. Mit ISP wenn dies eingeschalten ist, kann man definitiv den Kontroller umprogrammieren, auslesen geht nicht, bzw nur das Data Flash, vergleichbar dem EEprom im AVR. Auch beim AVR, wenn security bit gesetzt kann man das Programm nicht auslesen, man kann aber ein neues Programm flashen. Ich verstehe, daß man Bedenken hat, wenn ein funktionierendes Teil lahmgelegt wird durch Umprogrammierung, und wenn dies nicht passt, das Teil nun nutzlos ist. Kann denn niemand die Config bits auslesen, dies geht immer. Daraus lässt sich dann konkreter schließen, was machbar ist. Glück wäre natürlich, wenn man die FW auslesen könnte, was ich nicht glaube.
chris schrieb: > Mit ISP wenn dies eingeschalten ist, kann man definitiv den Kontroller > umprogrammieren Richtig, aber ISP ist bei Nuvoton der serielle Bootloader. Und der ist laut Tim gesperrt. Das Ganze ist bei ARM nicht wie bei AVR Teilen. Da ist ein gewaltiger Unterschied. chris schrieb: > Glück wäre natürlich, wenn man die FW auslesen könnte, was ich nicht > glaube. Wie schon mehrfach in dem Thread geschrieben, sind die Lockbits gesetzt.
:
Bearbeitet durch User
chris schrieb: > Mit ISP wenn dies eingeschalten ist, kann man definitiv den Kontroller > umprogrammieren, auslesen geht nicht, bzw nur das Data Flash, > vergleichbar > dem EEprom im AVR. Auch beim AVR, wenn security bit gesetzt kann man das > Programm nicht auslesen, man kann aber ein neues Programm flashen. Ich glaube du vergisst hier eine ganz wichtige Sache: Es handelt sich um einen ARM Mikrocontroller. Ein ARM Controller hat nichts (oder sagen wir fast nichts) mit einem AVR gemeinsam. Das ist eine andere Architektur. chris schrieb: > Kann denn niemand die Config bits auslesen, dies geht immer. Geht nicht so einfach, aus den Gründen wie oben bereits erwähnt. Beschäftige dich mal mit ARM, CMSIS und kau mal die Refernece Manuals von ST, NXP und Nuvoton durch. Du wirst (hoffentlich) feststellen, dass mit ISP nicht alles möglich ist und es hier auch Hardware bzw. Hersteller-spezifische Modien für die Programmierung und Konfiguration der Controller gibt. Aber genug OT von mir...
Habt ihr alle eure Flattermaxe kaputtgespielt und wartet auf die neue Lieferung oder warum ist hier tote Hose ;-)
Ich warte auf das Zweitexemplar und darauf, dass mal einer das Protokoll für für ICP erase postet oder Tim bestätigt, dass das mit dem "BuLink" geht.
Ich warte noch auf ersatzteile und einen zweiten, den ich dann kaputtprogrammieren kann
Übrigens verwenden auch alle größeren "Brüder" aus der V2X2 Bande ein ähnliches Board mit dem selben Controller: http://www.banggood.com/WLtoys-V222-RC-Quadcopter-Spare-Parts-Receiver-Board-p-77477.html Ich gehe mal davon aus, das alle von einander abgeleitet sind. Das heißt einmal gehackt mit vielen Modellen Potentieller Spaß!
Und nochbesser... Es wäre eine weitere billige Alternative für ne FC in nem selbstbau. Bisher steht das FlyingF3 mit Taulabs in dem Preissegment und dem können ziemlich alleine da... Zumindest wüsste ich kein anderes was so günstig und Leistungsstark ist..
Ja das stimmt. Die wurden auch komplett integrierte FCboards incl. RX darstellen. Kleiner und billiger geht dann kaum noch.
Oliver Stellebaum schrieb: > warum ist hier tote Hose ;-) Die Zeit zwischen zwei Flugrunden, reicht nicht um sinnvolle Artikel zu posten, oder um mal eben das Programmier-Protokoll zu hacken :-) Und solange, wie ich mit dem Ding noch in allen Ecken Staub aufwirbeln kann, wird er auch nicht zerlegt. Grüße Michael P.S.: Wobei die Höhenregulierung wirklich eine Optimierung gebrauchen kann.
Kaputtgespielt, und tmart.com ist ein komischer Laden mit Fake-Trackingnummern oder so.
Frust loswerden verstehe ich ja, aber wenn der Beitrag etwas Sinn machen soll, dann fehlen noch ein paar Infos. hubsi schrieb: > Kaputtgespielt Sprich: Erfolgreich ein "hello world" (LED-blinken) geflasht? > und tmart.com ist ein komischer Laden mit Fake-Trackingnummern oder so. Was hast Du denn dort worüber bestellt? Ebay? Aliexpress?
Torsten C. schrieb: > Frust loswerden verstehe ich ja, aber wenn der Beitrag etwas Sinn machen > soll, dann fehlen noch ein paar Infos. Sorry, ich schrieb weiter oben, dass es dort Ersatzteile gibt und wollte mit dem letzten Post darauf hinweisen, dass der Laden wohl doch etwas komisch ist, respektive nicht unbedingt zu empfehlen.
Habe gerade im Keller ein Dev-Kit von Nuvoton gefunden. Hatte ich mal bei nem Gewinnspiel abgestaubt und wusste bisher nix damit anzufangen. Kann ich damit schon mal weiterhelfen? So ein Hubsan Klon fliegt bei mir schon seit ein paar Wochen. Fände das auch shr interessant wenn man damit was anstellen könnte.
Robert Knipp schrieb: > Kann ich damit schon mal weiterhelfen? Na klar :) Am besten mal mit dem PC verbinden und schauen, ob das ICP Tool damit funktioniert (ob das ICP Tool den am Devkit verbauten Nulink erkennt). http://download.nuvoton.com/NuvotonMOSS/DownloadService/Member/DocumentsInfo.aspx?tp_GUID=SW0520101208200310 Edit: Was für ein Devkit ist es denn?
:
Bearbeitet durch User
Steht keine Bezeichnung drauf. Habe mal ein Foto vom Inhalt gemacht. Ist jedenfalls ein NuLink dabei. Dann probiere ich das heute abend mal aus.
Ah da ist ja sogar ein extra Nulink dabei ... Na mit dem sollte das ICP Tool auf jeden Fall funktionieren :) Das ist sogar eines der teureren SDKs die Nuvoton im Angebot hat, weil da eben ein extra voll funktionsfähiger Nulink dabei ist.
:
Bearbeitet durch User
Robert Knipp schrieb: > Dann probiere ich das heute abend mal aus. Ich bin auch gespannt. :-) Aber wenn Du probierst, ob "ICP erase" geht: Fliegt er danach denn noch? BTW: Bevor wieder ein Mod schimpft wegen der Bildformate: Da sieht man ja jedes Detail. :-)
Torsten C. schrieb: > Fliegt er danach denn noch? Dann macht der wohl gar nix mehr :) Dann is ja die Firmware im MCU weg.
So, nach einem FW Update des NuLink scheint es funktioniert zu haben. Als ich die Kopterplatine rangesteckt hatte, meldete das ICP sofort dass er gelockt ist und fragte ob er versuchen soll ihn zu löschen. Auf OK geklickt und nun meldet ICP das beim Connect nicht mehr.
:
Bearbeitet durch User
Ja also ich glaub sobald man den jetzt einmal unlocked und erased hat, kann man danach auch mit Keil und dem SWD vom Discovery Board drauffahren, weil der kann dann ja wahrscheinlich sein erase Programm in den RAM laden. Vermute ich jetzt mal so. Aber fürs erste mal muss man das eben so machen.
Also wie müsste ich dann jetzt weiter machen? Brauche ich ein Discovery Board? (Wollte eh eins bestellen) Habe hier noch ein EFM32-G8xx-STK mit nem Gecko von Energy Micro. Das wird bei Keil auch aufgelistet. Ob das auch geht? Da ist jedenfalls auch ein Debugging Interface drauf.
Warum benutzt du nicht den NuLink? Dafür gibt es anscheinend einen Treiber für Keil: http://www.nuvoton.com/NuvotonMOSS/Community/ProductInfo.aspx?tp_GUID=4b47b09d-b116-4ccd-aa85-31e261a87d30 Herzlichen Glückwunsch zu deinem Brick-Copter :-P
Marius S. schrieb: > Warum benutzt du nicht den NuLink? Dafür gibt es anscheinend einen > Treiber für Keil: > http://www.nuvoton.com/NuvotonMOSS/Community/ProductInfo.aspx?tp_GUID=4b47b09d-b116-4ccd-aa85-31e261a87d30 Jo, den Treiber habe ich auch gerade gefunden. Muss nur noch herausfinden wie ich in Keil auf den Controller komme. > Herzlichen Glückwunsch zu deinem Brick-Copter :-P naja, einer musste es ja mal testen. Vertraue darauf, dass Ihr eine bessere FW entwickelt ;.) Zum Spielen bestelle ich halt nen neuen.
Robert Knipp schrieb: > Muss nur noch herausfinden wie ich in Keil auf den Controller komme. Tim hat weiter oben im Thread mal Keil Projekt angehängt. Evtl. hilft das ja. ... Ich würde natürlich auch den Nulink einfach weiter verwenden. Ich wollte in meinem vorigen Post nur ausdrücken, dass sobald der MCU nicht mehr gelockt ist, man den Nulink wahrscheinlich nicht mehr braucht, sondern auch ein Teil mit SWD reicht.
Robert Knipp schrieb: > naja, einer musste es ja mal testen. Hut ab! Danke. :-) > Vertraue darauf, dass Ihr eine bessere FW entwickelt Echt Cool! Die Motivation scheint hoch zu sein und das "Team" (kann man das schon so nennen?) ist ja auch schon ziemlich groß. Das sind gute Voraussetzugen. Noch ein paar Wochen, und es wird Zeit für ein Team-Meeting. Vielleicht nicht wie früher in einer Kneipe mit Anreise per Auto oder Bahn, aber vielleicht online, also wenigstens mit Audio und Video.
Manuel Steiner schrieb: > Tim hat weiter oben im Thread mal Keil Projekt angehängt. Evtl. hilft > das ja. Build läuft nicht...
1 | Build target 'Mini51 CFG' |
2 | compiling FlashPrg.c... |
3 | FlashPrg.c: error: C3903U: Argument '/ropi/rwpi' not permitted for option 'apcs'. |
4 | ".\Mini51_CFG.axf" - 1 Error(s), 0 Warning(s). |
5 | Target not created |
Ich habe leider noch nie mit Keil oder einem 32bit Controller gearbeitet. Daher sagt mir das jetzt nix.
Ich frag mich ob Tim das Projekt nicht mit der konstenlos erhältlichen Lite Version erstellt hat bzw ob der Build bei ihm gelaufen ist. Ich hoffe er kann mehr dazu sagen :). Ich hab nämlich bei den Einschränkungen gefunden:
1 | The compiler and assembler do not generate position-independent code or data. |
2 | The --apcs /ropi /rwpi /pic/ pid compiler and assembler command line options are disabled. |
Weiters:
1 | The linker does not accept scatter-loading description files for sophisticated memory layouts. |
2 | The --scatter command line option is disabled. |
Im Projekt ist ja auch ein File enthalten, in dem als Kommentar in der ersten Zeile "scatter-loading" steht. Ich bin zur Zeit leider unter Linux und kann grad nicht ins Keil. Tim hat auch in einem früheren Post mal ein uvproject File hochgeladen, ohne Sourcen: https://www.mikrocontroller.net/attachment/194816/jxdhack.uvproj Vielleicht kann man das ja als Vorlage benutzen und eigene Sourcen zum Projekt hinzufügen. Man wird wohl sicherlich mal die ganzen CMSIS Libs von der Nuvoton Homepage brauchen. Ich hab den MCU auch noch nicht vor mir liegen, weil der Quadcopter noch nicht da ist, von daher ist das im Blindflug etwas schwierig :/ Vielleicht kommen wir mal gemeinsam zu einem Template Projekt, welches dann jeder verwenden kann, wenn er möchte.
Robert Knipp schrieb: > So, nach einem FW Update des NuLink scheint es funktioniert zu > haben. > Als ich die Kopterplatine rangesteckt hatte, meldete das ICP sofort dass > er gelockt ist und fragte ob er versuchen soll ihn zu löschen. Auf OK > geklickt und nun meldet ICP das beim Connect nicht mehr. Hey, das sind super Neuigkeiten! Damit sollte einer neuen Firmware nichts mehr im Wege stehen. Hast Du zufällig auch einen logicanalyzer, um den chip-erase Vorgang zu protokollieren?
Robert Knipp schrieb: > Also wie müsste ich dann jetzt weiter machen? Brauche ich ein Discovery > Board? (Wollte eh eins bestellen) Habe hier noch ein EFM32-G8xx-STK mit > nem Gecko von Energy Micro. Das wird bei Keil auch aufgelistet. Ob das > auch geht? Da ist jedenfalls auch ein Debugging Interface drauf. Der erste Test wäre ein Blinky-Programm :) Die LEDs sind ja schon angeschlossen. Wie oben schon geschrieben, unterstützt Keil auch Nulink. Du müsstest Dir also Keil mit Legacy device support installieren (siehe mein Post oben). Ich glaube als nächsten Schritt müssten wir erst einmal die Schaltung dokumentieren, damit klar ist, welche Peripherie an welchem Port hängt.
Manuel Steiner schrieb: > Robert Knipp schrieb: >> Muss nur noch herausfinden wie ich in Keil auf den Controller komme. > > Tim hat weiter oben im Thread mal Keil Projekt angehängt. Evtl. hilft > das ja. Mit den Projekten lässt sich allerdings nicht viel anfangen. Das eine ist ein leeres Dummy-projekt zum Debuggen ohne Source. Das Andere was der Sourcecode für den SWD-Softwareupdate. Ich bin gerade nicht zu Hause, kann am WE aber mal versuchen ein Testprojekt in Keil zu erstellen. Auf den Seiten von Nuvoton gibt es Archive mit Beispielprojekten für Keil: http://www.nuvoton.com/NuvotonMOSS/Community/ProductInfo.aspx?tp_GUID=4b47b09d-b116-4ccd-aa85-31e261a87d30 Ich denke wir müssten wegen des kleinen Flash auf die "DirectRegisterAccess" Variante zurück fallen. Die Startupcode kann Keil übrigens auch über den Projektwizard erzeugen.
Um dieses Archiv geht es:
> Mini51 SeriesBSP_DirectRegisterAccess_EN_V1.01.002.zip
... und ein Blinky-Projekt war auch dabei. Es muss nur noch der Port angepasst werden. (Auf welchem Port ist die LED angeschlossen?)
Tim (cpldcpu) schrieb: > Auf welchem Port ist die LED angeschlossen? Sind die überhaupt am MCU angeschlossen oder einfach an die Spannungsversorgung? Es geht ja richtig voran, juhu :) Mein Quad könnte auch schon langsam kommen. Jetzt fehlt wirklich dann auch nur mehr eine Methode, mit der man sich nicht einen Nulink zulegen muss. Entweder auf den Bulink hoffen oder wie gesagt spätestens wenn der Quadcopter bei mir ist werde ich mit dem Nulink mal das erasen analysieren.
Manuel Steiner schrieb: > Tim (cpldcpu) schrieb: >> Auf welchem Port ist die LED angeschlossen? > > Sind die überhaupt am MCU angeschlossen oder einfach an die > Spannungsversorgung? Die LEDs zeigen einige Statusinformationen an (Bind usw.). Daher sind sie wohl mit dem Controller verbunden.
Noch ne Frage an Tim, Torsten, Robert und co.: Wäre dann auch eventuell mal eine Wiki Page interessant, auf der wir die ganzen Informationen zusammentragen? Ich persönlich halte das für eine gute Idee, möchte aber nicht jetz einfach eine Wiki Page erstellen, obwohl ich das Ding noch gar nicht bei mir zu Hause habe. Ich würde aber auf jeden Fall daran dann mitarbeiten.
Tim (cpldcpu) schrieb: > Die LEDs zeigen einige Statusinformationen an (Bind usw.). Daher sind > sie wohl mit dem Controller verbunden. Ah ok, cool. Wie gesagt, für mich ist es im Moment noch ein wenig schwierig, weil das Teil noch nicht da ist :)
Manuel Steiner schrieb: > Noch ne Frage an Tim, Torsten, Robert und co.: > > Wäre dann auch eventuell mal eine Wiki Page interessant, auf der wir die > ganzen Informationen zusammentragen? > > Ich persönlich halte das für eine gute Idee, möchte aber nicht jetz > einfach eine Wiki Page erstellen, obwohl ich das Ding noch gar nicht bei > mir zu Hause habe. Ich würde aber auf jeden Fall daran dann mitarbeiten. Da hattest Du den gleichen Gedanken. Ich habe gerade einen Organization-Account auf Git-Hub erstellt: https://github.com/hack-opter Das ist sehr praktisch, um sich Aufgaben zu teilen und Code abzulegen. Ich werde am WE mal anfangen das hochzuladen, was sich schon angesammelt hat. Um dort Mitglied zu werden und Schreiben zu können, benötigt Ihr einen kostenlosen GIthub-account. Lesen ist für alle kostenlos. Ich denke zur Dokumentation macht zusätzlich ein Wiki-Artikel auf µcontroller.net Sinn.
>Lesen ist für alle kostenlos.
Lesen ist für alle möglich.
(habe leider meine Login-Daten auf diesem Rechner nicht.)
Ich hab mich mal angemeldet. Git ist ja so ähnlich wie Mercurial, Von da her kenn ich mich da auch schon ein wenig aus :) @Tim: Kann man das Projekt dann einfach clonen und auschecken, oder musst du mich da als Member im Projekt eintragen?
Manuel Steiner schrieb: > Ich hab mich mal angemeldet. Git ist ja so ähnlich wie Mercurial, Von da > her kenn ich mich da auch schon ein wenig aus :) Wie ist denn Dein Name? Dann kann ich Dich gleich hinzufügen :) > @Tim: Kann man das Projekt dann einfach clonen und auschecken, oder > musst du mich da als Member im Projekt eintragen? Forken, clonen und pull-requests submitted kann jeder. Damit zu Pull-requests in das Master repository mergen kannst, muss ich Du allerdings Mitglied der Organisation werden und ich muss Dich freischalten.
:
Bearbeitet durch User
Alles klar Edit: Mein Username bei Github: steinerhippo, so wie im Forum
:
Bearbeitet durch User
Tim (cpldcpu) schrieb: > Hey, das sind super Neuigkeiten! Damit sollte einer neuen Firmware > nichts mehr im Wege stehen. Hast Du zufällig auch einen logicanalyzer, > um den chip-erase Vorgang zu protokollieren? Jein, der MockUp LA liegt halb zusammengebaut im Keller. Da könnte ich mich aber morgen mal ransetzen. Heute wird das leider nichts mehr. > ... und ein Blinky-Projekt war auch dabei. Es muss nur noch der Port > angepasst werden. (Auf welchem Port ist die LED angeschlossen?) Versuche ich morgen auch mal zu testen. Manuel Steiner schrieb: > Es geht ja richtig voran, juhu :) Mein Quad könnte auch schon langsam > kommen. Jetzt fehlt wirklich dann auch nur mehr eine Methode, mit der > man sich nicht einen Nulink zulegen muss. In den nächsten Tagen, vielleicht schon morgen müsste mein Discoveryboard kommen. Wir könnten also meinen NuLink auch erstmal rumschicken im Vertrauen darauf dass er irgendwann auch wieder zurück kommt. Falls jemand aus dem Raum Hannover unter euch ist könnte man sich auch treffen, ginge noch schneller. Nur ein Angebot, da sich ja vielleicht nicht jeder nur zum Löschen eines Chips so ein Teil kaufen will.
Hm noch einfacher und vll. billiger wäre es einfach jeweils das Board des Quad mit Rückumschlag zu dir zu schicken und du löscht es. Zumindest für die Leute die es nciht selber können.
No y. schrieb: > Hm noch einfacher und vll. billiger wäre es einfach jeweils das Board > des Quad mit Rückumschlag zu dir zu schicken und du löscht es. Zumindest > für die Leute die es nciht selber können. Könnte ich dann auch anbieten, wenn der Nulink da ist. Nachteil bei mir ist allerdings, dass ich aus Österreich bin. Bevor das aber alle haben wollen, sollten wir noch testen, ob der nicht gelockte MCU auch wirklich über das Discovery SWD beschreibbar ist. Nicht dass wir die Platinen unnötig hin- und herschicken und das mit SWD doch nicht so funktioniert wie es soll. Ich gehe aber davon aus, dass es geht.
Am besten wäre es, auf dem Discovery ein kleines Programm zu implementieren, welches nur den chip-erase Teil übernimmt. Dazu müsste man den Vorgang mindestens einmal mit einem LA mitschneiden.
Ich meine abgesehen davon sollten wir schon mal prüfen, ob wir wirklich den Flash mit dem Discovery SWD beschreiben können. Nicht dass hierbei auch noch unerwartete Probleme auftreten. Weil dann würde man ja sowieso wahrscheinlich einen Nulink brauchen oder man flasht einmalig einen Bootloader für ISP. Tim schrieb: > Am besten wäre es, auf dem Discovery ein kleines Programm zu > implementieren, welches nur den chip-erase Teil übernimmt Ja das wäre natürlich für alle die beste Lösung. Außer der Bulink kann das auch alles :)
:
Bearbeitet durch User
No y. Schrieb: > Hm noch einfacher und vll. billiger wäre es einfach jeweils das Board > des Quad mit Rückumschlag zu dir zu schicken und du löscht es. Zumindest > für die Leute die es nciht selber können. So können wir es natürlich auch machen. Manuel Steiner schrieb: > Ich meine abgesehen davon sollten wir schon mal prüfen, ob wir wirklich > den Flash mit dem Discovery SWD beschreiben können. Nicht dass hierbei > auch noch unerwartete Probleme auftreten. Weil dann würde man ja sowieso > wahrscheinlich einen Nulink brauchen oder man flasht einmalig einen > Bootloader für ISP. Mein Discovery wurde heute verschickt. Sobald es da ist teste ich es gleich .
Eventuell könnte das "nutiny-sdk-m051" eine gute Wahl sein. Digikey hat es für 26$ im Angebot. Das ist dann ein kleiner Nulink plus eine Breakoutplatine für den Mini51.
Meiner ist heute angekommen - bestellt am 26.09. Fliegen mit dem Teil habe ich mir einfacher vorgestellt...
Torsten S. schrieb: > Fliegen mit dem Teil habe ich mir einfacher vorgestellt... Ich auch... ;-) ...
Georg G. schrieb: > Eventuell könnte das "nutiny-sdk-m051" eine gute Wahl sein. Digikey hat > es für 26$ im Angebot. Das ist dann ein kleiner Nulink plus eine > Breakoutplatine für den Mini51. Manuel Steiner schrieb: > Torsten C. schrieb: >> - NUTINY-SDK-M051 > > hat glaub ich laut Atlantik Homepage auch keine ICP Funktion Wie bereits geschrieben ist bei den Nutiny SDKs Vorsicht geboten, falls ICP mit unlock und erase verwendet werden soll ...
Manuel Steiner schrieb: > Wie bereits geschrieben ist bei den Nutiny SDKs Vorsicht geboten, falls > ICP mit unlock und erase verwendet werden soll ... Laut Nuvoton Seite wird ICP unterstützt. http://www.nuvoton.com/NuvotonMOSS/Community/ProductInfo.aspx?tp_GUID=c78adfaf-87ca-46d1-a15a-0d33583c2797
In der Nuvoton Präsentation die weiter oben verlinkt ist war zum Nutiny NUC100 und NUC120 auch zu lesen, dass kein ICP unterstützt wird und auf der Homepage steht es wird unterstützt. Also ist Nuvoton hier sehr inkonsistent was Angaben betrifft. Wenns irgendwem die 26$ bzw bei uns wahrscheinlich auch genau so viele € wert ist, kann er sichs ja mal gern besorgen. Ein dedizierter Nulink ist da aber auch nicht mehr recht teurer und mit dem funktionierts 100%, wie wir dank Robert festgestellt haben. Ich will hier natürlich keinen davon abhalten, sich ein SDK zu kaufen. Ich äußere nur die Bedenken die wir hier schon mal festgehalten haben.
:
Bearbeitet durch User
So, da mein erster solangsam komische geräusche von den Motorlagern gibt möchte ich mir mal nen 2. bestellen. So habe ich dann zum einen alle Ersatzteile nochmal und das günstiger als die Ersatzteile einzeln zu bestellen. Zum anderen kann ich den einen zum Programmieren missbrauchen und trotzdem fliegen. Wie sieht es denn mit der Qualität mit denen aus Frankfurt aus? Oder z.B: http://www.ebay.de/itm/RC-Ferngesteuerter-Quadrocopter-Quadcopter-Multicopter-Drohne-UFO-/200978469863?pt=RC_Modellbau&var=&hash=item2ecb4013e7 Da wären so Schutzringe bei. Dürfte wohl der selbe sein. Nur vom Plastik weiß ich es nicht so richtig. Der "Original" China den ich hier hab hält bisher sehr gut. Bei den anderen Gehäusen aus Frankfurt weiß ich es so nicht. Kann jemand dazu was sagen?
No y. schrieb: > Da wären so Schutzringe bei. Dürfte wohl der selbe sein. Nur vom Plastik > weiß ich es nicht so richtig. Der "Original" China den ich hier hab hält > bisher sehr gut. Bei den anderen Gehäusen aus Frankfurt weiß ich es so > nicht. > > Kann jemand dazu was sagen? Also ich habe meinen Klon von DX. Hat bisher zig teilweise üble Abstürze hinter sich und funktioniert immer noch 1A (bis zum Löschen des Controllers). Habe bisher nur einen Prop verloren. Ist wohl unter einem Schrank gelandet.
No y. schrieb: > Ist das denn so einer wie die aus Frankfurt? Das ist meiner: http://dx.com/p/219612
Hallo zusammen, Habt Ihr denn schon einmal versucht die Schaltpläne zu den verschiedenen Versionen aufzunehmen? Wenn der Mikrocontroller schon einmal leer ist würde ich damit doch anfangen. Gruß Martin
Hannes Lux schrieb: > Torsten S. schrieb: >> Fliegen mit dem Teil habe ich mir einfacher vorgestellt... > > Ich auch... ;-) > > ... Gut zu wissen Hannes. Dann sind wir ja beide Co-Piloten ;) Käffchen?
Manuel Steiner schrieb: > Ich würde aber auf jeden Fall daran dann mitarbeiten. Ich auch. Machen wir denn alles im hack-opter-github oder brauchen wir noch eine Wiki-Seite? http://www.mikrocontroller.net/wikisoftware/index.php?title=Hack-Opter&action=edit Ich bin "TorstenC" bei github.
Torsten S. schrieb: > Gut zu wissen Hannes. Dann sind wir ja beide Co-Piloten ;) Nicht mehr, ein guter Freund (75 km südlich) hat mir das Ding abgeschwatzt. Ich wollte damit eigentlich nur mal testen, ob ich damit umgehen kann und ob sich später dann die Anschaffung einer FlyCam lohnt. Ich habe mich aber dafür entschieden, bei der auf Gartenbahngleisen fahrenden Train-Cam zu bleiben und die Helis Helis sein zu lassen... http://www.youtube.com/channel/UCEbswoJIlUy-rokhdFtW6xw/videos Man kann nicht überall mitmischen... > Käffchen? Ja sicher doch! - Sofern es Deine knappe Zeit erlaubt. ...
Torsten C. schrieb: > Ich auch. Machen wir denn alles im hack-opter-github oder brauchen wir > noch eine Wiki-Seite? > > http://www.mikrocontroller.net/wikisoftware/index.php?title=Hack-Opter&action=edit Github ist gut, um Daten auszutauschen. Damit Außenstehende verstehen, worum ist überhaupt geht, wäre ein Wiki-Artikel sinnvoll.
Tim schrieb: > Github ist gut, um Daten auszutauschen. Damit Außenstehende verstehen, > worum ist überhaupt geht, wäre ein Wiki-Artikel sinnvoll. Github selber bietet auch Wiki-Funktionen; welche sogar von Nicht-Projektmitgliedern editiert werden dürfen: https://github.com/blog/774-git-powered-wikis-improved Ich persönlich finde es immer angenehmer, alle Infos an einer zentralen Stelle zu haben.
Moritz A. schrieb: > Github selber bietet auch Wiki-Funktionen; Hier in diesem Forum gibt es aber schon ein Wiki. Und ein Respository ist auch vorhanden. Ist alles da, es kann sofort losgelegt werden. ...
Ja, ich denke man sollte das Mikrocontroller Wiki nehmen. Das Repository kenne ich nicht, aber ich habe Zweifel dass es an die Mächtigkeit von Github heran kommt. Github hat auch den Vorteil, dass man eine evtl. entstehende Firmware auch nicht-deutschsprachigen näherbringen kann.
Die LEDS sind übrigens an P0.0 angeschlossen. Das Blinky-Programm sollte also nur diesen Port ansprechen. Ich habe das Repository schon mit einigen Daten gefüllt: https://github.com/hack-opter/Documentation Fühlt euch frei zu Forken und Pullen. Die Mitglieder der "Organisation" können auch direkt auf das Repository zugreifen und eigene erstellen.
Tim schrieb: > Das Repository > kenne ich nicht, Schau mal in Deinen Einstellungen ganz unten nach, da steht Dein Passwort zum hiesigen SVN-Server. ...
So, ich war fleissig und habe ein Blinky-Testprojekt erstellt, indem ich das Offizielle Beispiel abgewandelt habe. Leider kann ich es Mangels "Bu-Link" noch nicht auf echter Hardware testen, aber vielleicht kann Robert es testen? Ein Project für Keil uvision ist enthalten. Wenn alles funktioniert, sollten die LEDS mit 2 Hz blinken. https://github.com/hack-opter/Examples
:
Bearbeitet durch User
Hannes Lux schrieb: > Schau mal in Deinen Einstellungen ganz unten nach, da steht Dein > Passwort zum hiesigen SVN-Server. Danke! Ich bin allerdings schon voll zu git konvertiert :)
Tim (cpldcpu) schrieb: > Ich denke wir müssten wegen des kleinen Flash auf die > "DirectRegisterAccess" Variante zurück fallen. Ist die CMSIS Lib so groß? Bei STM32 läuft die zB auch ohne Probleme auf 16k Flash. Komfortabler wäre CMSIS glaube ich schon, aber wenn es nicht anders geht, wird man sich wohl auch mit Direct Register Access zurechtfinden :) Tim schrieb: > Ich habe das Repository schon mit einigen Daten gefüllt Gefällt mir :)
Manuel Steiner schrieb: > Ist die CMSIS Lib so groß? Bei STM32 läuft die zB auch ohne Probleme auf > 16k Flash. Komfortabler wäre CMSIS glaube ich schon, aber wenn es nicht > anders geht, wird man sich wohl auch mit Direct Register Access > zurechtfinden :) Man kann CMSIS auch noch verkleinern, dann gibt es wahrscheinlich keinen wirklichen Unterschied zum direct register access mehr. Ich habe das mal für den LPC810 gemacht - war aber ein ganz schönes Gefrikel. (https://github.com/microbuilder/LPC810_CodeBase/pull/3) Für Umsteiger von AVR ist DRA vielleicht intuitiver? Ich muss mir das bei Gelegenheit noch einmal anschauen.
:
Bearbeitet durch User
Tim schrieb: > Für Umsteiger von AVR ist DRA vielleicht intuitiver? Stimmt, so gesehen ist es vielleicht nicht so schlecht.
Ich habe das Repository noch einmal umbenannt, weil es mir so besser gefiel. Lieber jetzt als später... https://github.com/hackocopter
Hallo, habe den "Frankfurter"-Quadrocopter in dieser Woche erhalten und habe mit dem Copter zwei Probleme: Zuerst schalte ich die Fernbedienung ein, dann den Copter und warte bis die Fernbedienung signalisiert, dass es losgehen kann. Jetzt taucht das erste Problem auf: in den ersten 1 - 2 Minuten werden die Befehle nur mit großer Verzögerung angenommen (1 - 2 Sekunden), danach funktioniert alles einwandfrei. Das zweite Problem ist, der Copter muss nach jedem Einschalten getrimmt werden. Wie kann ich die beiden Probleme abstellen? Herbert
Mach es mal andersrum. Erst Copter anstecken, dann FB an und das Gas auf Vollgas schieben und zurück. Dann sollte es direkt gehen. Das mit dem Trimmen... Ich glaub das musst du allgemein machen. Auch wenn der Akku nachlässt musst du ab und zu nachtrimmen..
Wollte gerade das Blinkprogramm ausprobieren, doch mit dem funktioniert das Build auch irgendwie nicht. Keil findet ein File nicht. Es ist aber definitiv da. Verstehe das nicht.
Robert Knipp schrieb: > Es ist aber definitiv da Dann liegt es an einem Platz, wo es der Keil nicht sucht.
Und es blinkt.... Georg G. schrieb: > Robert Knipp schrieb: >> Es ist aber definitiv da > > Dann liegt es an einem Platz, wo es der Keil nicht sucht. GitHub hatte das Projekt irgendwie nicht richtig synchronisiert.
Hannes Lux schrieb: > Torsten S. schrieb: >> Gut zu wissen Hannes. Dann sind wir ja beide Co-Piloten ;) > > Nicht mehr, ein guter Freund (75 km südlich) hat mir das Ding > abgeschwatzt. Ich wollte damit eigentlich nur mal testen, ob ich damit > umgehen kann und ob sich später dann die Anschaffung einer FlyCam lohnt. > Ich habe mich aber dafür entschieden, bei der auf Gartenbahngleisen > fahrenden Train-Cam zu bleiben und die Helis Helis sein zu lassen... > http://www.youtube.com/channel/UCEbswoJIlUy-rokhdFtW6xw/videos > Man kann nicht überall mitmischen... Ja man kann nicht auf mehreren Hochzeiten tanzen. Es ist besser sich für eine Sache zu entscheiden und die dann richtig zu machen. Eine Flycam habe ich mir auch angeschafft, ein User in diesem Thread hatte diese empfohlen [1]. Leider kann der kleine Hupsi diese nicht heben weil zu schwer. Trotzdem kein Fehlkauf - die Qualität ist beeindruckend. Man sieht die Grashalme auf dem Rasen hin-und-her wippen. Das unscheinbare Teil stellt einen kürzlich erworbenen Camcorder in die Ecke. [1] EbayNr.: 221259368601
Es blinkt oha :D das ist mal sehr schön was muss ich mir an sachen bestellen um die firmware zu flashen ? Oder basteln zu können ? Was kostet das ca.
Turbonator schrieb: > Es blinkt oha :D das ist mal sehr schön was muss ich mir an sachen > bestellen um die firmware zu flashen ? Oder basteln zu können ? Was > kostet das ca. Also wenn man ein wenig in dem Thread hier liest, dann kommt man auf Folgendes: - Mit einem Nulink Programmer funktioniert es 100% (etwa 35€) - Tim wartet auf den Nachbau (Bulink, ca 11 Dolla, wenn ich es richtig im Kopf habe), und wird hoffentlich berichten sobald der da ist - Vermutlich funktioniert es auch mit einem SWD (wie etwa auf STM32 Discovery Boards zu finden, ab 10€ erhältlich), sobald der MCU einmal unlocked und erased ist. Hierzu werden wir noch analysieren, ob sich dieser Vorgang auch ohne Nulink, etwa mit dem SWD von Discovery Boards durchführen lässt. Dazu muss aber erst mal herausgefunden werden, wass wirklich beim unlocken und erasen mit dem ICP Tool und Nulink passiert.
Ok cool danke bei dem ganzen hin und her will ich auf nummer sicher gehen aber das orgi teil ist ja auch günstig damit ich nichts falsch mach wäre ein link auf ebay cool wenn es nicht zuviel verlangt ist . Und mit der Software von nulink kann man in der free version bis 16kb was bei dem reicht oder ist das völlig falsch ? ... welche Programm sprache ist angebracht?
Das ICP Tool von Nuvoton brauchst du zur zum Unlocken und Löschen des MCU. Danach kannst du zB mit Keil neue Firmware schreiben. Diese hat in der freien Version ein Limit von 32k. Programmiersprache ist C / C++. Das original Nuvoton Nulink Teil gibts nur bei Distributoren, zB. Digikey: http://www.digikey.com/product-search/en?x=0&y=0&lang=en&site=us&KeyWords=nulink Es ist auch sehr ratsam den Thread zu verfolgen, es wurden schon sehr viele hilfreiche Informationen zusammengetragen. Wir sind gerade dabei, dass auch alles in Github zu sammeln und eine Wikipage zu erstellen, wie ein paar Posts weiter oben zu lesen ist.
Ja das stimmt, ok danke trotzdem. Jetzt ne andere frage . Ich als anfänger hab mir gedacht erstmal da wo die motoren dransind einen RGBW stripe dranzumachen und das zum leuchten zu bringen ein bekannter von mir in C programieren oder ist das kompletter schwachsinn ?
Turbonator schrieb: > Ich als anfänger hab mir gedacht erstmal da wo > die motoren dransind einen RGBW stripe dranzumachen und das zum leuchten > zu bringen ein bekannter von mir in C programieren oder ist das > kompletter schwachsinn ? Ist es schon so spät, dass ich die Frage (zumindest den 2. teil mit bekannteer und C programmieren) nicht versteh, oder fehlt da noch wo ein Teil in der Frage? Warum willst du statt den Motoren LEDs anbringen? Man kann da ja nicht so viel kaputt machen. Zur Not die Propeller abnehmen, damit der Quad nicht unkontrolliert irgend etwas macht oder mal einfach mit den LEDs die verbaut sind anfangen zu spielen (mal PWM drauf los lassen und dimmen etc).
Also ich meinte das als übung das er mich unterstützt mein bekannter
Ich weiß nicht ob dein Bekannter in Sachen ARM bzw MCU Programmierung Erfahrung hat. Falls ja, klar könnt ihr miteinander da rum probieren, wieso auch nicht? Allgemein sollte man sich aber wohl mal mit C Programmierung im Generellen auseinandersetzen. Danach mit der ARM Plattform und den Konzepten von MCU Programmierung. Da wird sehr viel eventgesteuert programmiert usw. Falls du hier gleich versuchst, ohne irgendwelche Vorkenntnisse mit dem Quad zu experimentiern könnte das eventuell schnell zu Frust anstatt zu Spaß werden. Für Anfänger ist es sicher nicht trivial, mal eben PWM oder ähnliches zur programmieren. Man sollte da eventuell mit einfachen Ausgängen anfangen, die mal high bzw low setzen. Das Ganze ist meine Meinung.
> zu bringen ein bekannter von mir kann in C programieren oder ist das > kompletter schwachsinn ? So ist es richtig . Hast recht ich sollte tv gucken oder schlafen . Pwm ist mir sehr wichtig , ne555 kann das auch aber so mein ich das nicht . Eher mit drei phasen zb brushless motor aber mit mikrocontrollern das hat aber nichts mit dem hier zu tun . Es geht mehr um das programmieren also um den copter .
Robert Knipp schrieb: > Wollte gerade das Blinkprogramm ausprobieren, doch mit dem funktioniert > das Build auch irgendwie nicht. > Keil findet ein File nicht. Es ist aber definitiv da. Verstehe das > nicht. Das Definieren von Pfaden in Keil ist ziemlich verwirrend. Ich dachte schon, ich hätte da etwas falsch gemacht. Aber das Compilieren funktioniert bei mir auch von einem anderen Laufwerk. Hast Du denn das ganze Archiv heruntergeladen und entpackt? Sind die Pfade die gleiche wie vorher? >Und es blinkt.... Ah, dann vergiss das Obige :) Super! dann funktioniert ja alles. >GitHub hatte das Projekt irgendwie nicht richtig synchronisiert. Inwiefern?
:
Bearbeitet durch User
Tim schrieb: >>GitHub hatte das Projekt irgendwie nicht richtig synchronisiert. > > Inwiefern? Habe mir die GitHub Anwendung für Windows installiert und darüber das Projekt auf meinen Rechner geklont. Das wollte erst nicht so richtig. Zwischenzeitlich war aber auch der Samba auf meinem NAS, auf dem GitHub das Projekt klonen sollte, abgestürzt und dann gabs natürlich Fehler. Danach funktionierte der Sync auch nicht mehr. Hatte es dann aus der Anwendung wieder rausgelöscht und es nochmal klonen lassen. Dann funktionierte es.
:
Bearbeitet durch User
Wollte jetzt mal mit dem LA an das Teil ran. Wenn der LA dran hängt mag Keil aber nicht mehr flashen. Ich habe den MiniLA Version MockUp und habe die ersten drei Kanäle an den Datenleitungen hängen und Masse angeschlossen. Ich greife die Signale direkt am NuLink ab. Den Trigger habe ich auf steigende Flanke am Clocksignal eingestellt. Der LA wartet auch brav auf den Trigger. Ich habe bisher noch nie mit einem LA gearbeitet. Mache ich da was falsch?
Durch weglassen einer Leitung nach der anedren kannst du probieren, welcher Anschluss das Problem verursacht. Eventuell ist die Masse das Problem.
Ich hatte doch etwas nicht richtig angreschlossen. Nun funktionierts. Ich habe allerdings Probleme beim Mitschneiden der Programmierung über ICP. Sobald ICP Verbindung mit dem Controller hat kommuniziert es anscheinend ständig mit dem Controller. Sobald ich den LA starte löst der Trigger sofort aus, der LA zeichnet etwa 20us auf, überträgt zum PC und geht dann wieder auf Standby. Habt Ihr nen Tip auf was ich da triggern muss? Habe übrigens die Time Analysis FW drauf. Das sollte doch richtig sein, oder? Jetzt muss ich leider erstmal weg. Teste das dann eventuell heute abend nochmal.
:
Bearbeitet durch User
Die Chinamänner haben gemerkt das Dinger beliebt sind und haben die Preise angezogen! Keiner mehr unter 25€. Es geht auf Weihnachten zu.
Ich habe es jetzt mal hinbekommen beim erase Vorgang etwas aufzuzeichnen. Bin mir da allerdings nicht sicher ob es der komplette Vorgang ist. Auf der data Leitung passiert so gut wie nichts und nicht immer exakt das selbe. Habe drei erase Vorgänge gesüpeichert. Vielleicht kann ja jemand etwas damit anfangen.
Robert Knipp schrieb: > Ich habe es jetzt mal hinbekommen beim erase Vorgang etwas > aufzuzeichnen. Bin mir da allerdings nicht sicher ob es der komplette > Vorgang ist. Auf der data Leitung passiert so gut wie nichts und nicht > immer exakt das selbe. Habe drei erase Vorgänge gesüpeichert. Vielleicht > kann ja jemand etwas damit anfangen. Was sind das für Dateien? Wie kann man sich die anschauen?
Broo schrieb: > Robert Knipp schrieb: > >> Ich habe es jetzt mal hinbekommen beim erase Vorgang etwas >> aufzuzeichnen. Bin mir da allerdings nicht sicher ob es der komplette >> Vorgang ist. Auf der data Leitung passiert so gut wie nichts und nicht >> immer exakt das selbe. Habe drei erase Vorgänge gesüpeichert. Vielleicht >> kann ja jemand etwas damit anfangen. > > Was sind das für Dateien? Wie kann man sich die anschauen? Die wurden mit der MiniLA Software gespeichert. Anderes Format kann die leider nicht. Die SW gibts im Artikel. http://www.mikrocontroller.net/articles/Minila_Version_MockUp
Habe gerade gesehen es geht auch Export in Bin+Ini und VCD. Vielleicht kann man das ja mit nem anderen Programm öffnen. Kenne mich da noch nicht so aus.
Robert Knipp schrieb: > Ich habe es jetzt mal hinbekommen beim erase Vorgang etwas > aufzuzeichnen. Bin mir da allerdings nicht sicher ob es der komplette > Vorgang ist. Auf der data Leitung passiert so gut wie nichts und nicht > immer exakt das selbe. Habe drei erase Vorgänge gesüpeichert. Vielleicht > kann ja jemand etwas damit anfangen. Am interessantesten wäre wahrscheinlich der erase Vorgang mit locktem MCU. Eventuell kann man den ja nochmal locken und analysieren. Mein Quadcopter lässt leider immer noch auf sich warten, bis ich mal was machen kann. Aber Danke natürlich an jede Mithilfe und deine Mühe. Vielleicht lässt sich damit ja auch schon was anfangen. Nicht dass jetz wer glaubt, ich würde das nicht Wert schätzen oder so :)
:
Bearbeitet durch User
Manuel Steiner schrieb: > Am interessantesten wäre wahrscheinlich der erase Vorgang mit locktem > MCU. Eventuell kann man den ja nochmal locken und analysieren. Genau so habe ich es ja gemacht. Erst gelocked und dann wieder erased.
Robert Knipp schrieb: > Manuel Steiner schrieb: >> Am interessantesten wäre wahrscheinlich der erase Vorgang mit locktem >> MCU. Eventuell kann man den ja nochmal locken und analysieren. > > Genau so habe ich es ja gemacht. Erst gelocked und dann wieder erased. Ah ok alles klar, sorry für die Verwirrung.
Broo schrieb: > Robert Knipp schrieb: > >> Näher gezoomt bekomme ich nicht alles drauf.... > > Sieht doch brauchbar aus. Ist es nicht etwas wenig? Mehr zeichnet er aber auch nicht auf. Bricht die Aufzeichnung von selbst ab.
Hallo zusammen, ich habe mir das Board mit einem J-link Edu unter Keil angeschaut. Löschen oder Zugriff auf geschützte Register funktioniert nicht, also auch keine Neu-Programmierung. Allerdings ist die ISP-Routine im Datenblatt vom Mini beschrieben (S. 130ff). Der Schlüssel liegt wohl in der Startsequenz: An Adresse 0x50000100 die Werte 0x59, 0x16, 0x88 schreiben. Anschliessend sind die geschützten Register (nicht Flash) beschreibbar. Das funktioniert auch, das Bit ändert seinen Wert: Adresse 0x50000100 Bit 0 (1=unlocked, 0=locked). Wie es dann mit der ISP-Routine weitergeht ist kompliziert. Vielleicht hilft der Ansatz aber bei der Analyse weiter...
Meiner ist gerade gekommen. Ausgepackt, Akku geladen und den Kram mal laufen lassen. Es ging vom Schreibtisch vehement an die Decke und von da in die Küche. Er ist auf der Nase gelandet und hat mir ordentlich auf die Finger gehauen. Nettes Bieldeug :-)))
Am 16.10, ca. 3 Wochen. Ich habe ihn jetzt einmal hinter dem Schrank wiedergefunden, es sammelt Wollmäuse und zickt etwas :-)))) Vielleicht mal die Katze jagen ...
Mein Ersatz von tonsee_mall kam heute an, mit Akku. Versand war 16.10.
Also ich wohne in nrw Essen und meiner wurde auch am 16.10 abgeschickt . Auch von tonsee mall ,dann kommt der wohl morgen .
Oliver Stellebaum schrieb: > Die Chinamänner haben gemerkt das Dinger beliebt sind und haben die > Preise angezogen! Keiner mehr unter 25€. > Es geht auf Weihnachten zu. Habe hier gerade meinen Drittcopter gekauft: http://www.ebay.de/itm/151110512069?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649 22.37EUR
Robert Knipp schrieb: > Ich habe es jetzt mal hinbekommen beim erase Vorgang etwas > aufzuzeichnen. Bin mir da allerdings nicht sicher ob es der komplette > Vorgang ist. Auf der data Leitung passiert so gut wie nichts und nicht > immer exakt das selbe. Habe drei erase Vorgänge gesüpeichert. Vielleicht > kann ja jemand etwas damit anfangen. Hallo Robert, vielen Dank! Das sieht sehr interessant aus. Die Sequenz sieht wirklich merkwürdig aus. Reset während CLK getoggled wird? Eigentlich macht das gar keinen sinn, aber vielleicht ist das ja auch das Geheimnis. Ich bin immer noch auf der Suche nach eine guten Referenz für das SWD-Protokoll. Kennt da zufällig jemand etwas?
Tim schrieb: > Oliver Stellebaum schrieb: >> Die Chinamänner haben gemerkt das Dinger beliebt sind und haben die >> Preise angezogen! Keiner mehr unter 25€. >> Es geht auf Weihnachten zu. > > Habe hier gerade meinen Drittcopter gekauft: > > http://www.ebay.de/itm/151110512069?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649 > > 22.37EUR Den hättest auch aus DE haben können: http://www.ebay.de/itm/171097513221?ssPageName=STRK:MEWAX:IT&_trksid=p3984.m1423.l2649 Grüße
Tim schrieb: > Ich bin immer noch auf der Suche nach eine guten Referenz für das > SWD-Protokoll. Kennt da zufällig jemand etwas? Ich hab letztens mal libswd gefunden: http://sourceforge.net/apps/trac/libswd Das ist eine SWD Library. Auf dieser Seite waren unter anderem folgende Dokumente zu SWD verlinkt: http://www.arm.com/products/system-ip/debug-trace/coresight-soc-components/serial-wire-debug.php http://www.arm.com/files/pdf/Low_Pin-Count_Debug_Interfaces_for_Multi-device_Systems.pdf An die genaue Spezifikation kommt man wahrscheinlich nur als ARM Partner :/ Edit: Die ARM Debug Interface Architecture Specification könnte noch interessant sein. (Kapitel 5.2) http://www.pjrc.com/arm/pdf/doc/ARM_debug.pdf
:
Bearbeitet durch User
Thema Gyros :-) Mal eine Verständnisfrage. Angeblich soll da doch ein präzises Gyrosop verbaut sein, so eins wie in modernen Smartphones. Wieso steht das verflixte Ding dann nicht still sondern driftet?
Oliver Stellebaum schrieb: > Angeblich soll da doch ein präzises Gyrosop verbaut sein, so eins wie in > modernen Smartphones. > Wieso steht das verflixte Ding dann nicht still sondern driftet? Der Drift wird normalerweise über den Beschleunigungssensor ausgeglichen, da dieser langzeitstabil ist. Ist alles eine Sache der Software. Der Drift kommt einfach daher, da das Gyroskop um den "0-Punkt" rauscht und zwar immer etwas mehr im positiven als im Negativen. Da der Absolutwinkel durch Aufintegration der Winkelgeschwindigkeit ermittelt wird, fängt dieser auch bei keiner Rotation des Copters an abzudrifen. Man kann das nicht völlig rausbekommen, da dies auch Temperaturabhängig ist. Normalerweise ermittelt man bei der Initialisierung den "Rauschoffset" und zieht diesen von den Werten ab, damit ist es dann einigermaßen driftfrei, aber eben nicht ganz Auch das Gyroskop im MPU6050 ist nicht driftfrei, solche MEMS-Gyros gibt es halt nicht. Darum verwendet man eben auch den Beschleunigungssensor (da Langzeitstabil) um den Drift wieder rauszubekommen, im einfachsten Fall über einen Komplementärfilter. Damit das natürlich richtig funtkioniert muss der Beschleunigungssensor beim starten auch einmal sauber auf "0°" eingestellt werden, denn sonst wird man immer eine falsche 0°-Lage drin haben.
:
Bearbeitet durch User
Tim schrieb: > Drittcopter Der Trend geht zum Zweitbuch? Äääh Quathsch! .. zum Drittcopter? Ich habe bisher keine Quelle für Copter ohne Fernbedienung gefunden. Hat jemand dazu schon mal Aktivitäten entfaltet? Wenn nicht, würde ich die Anbieter alle mal anschreiben, z.B. für 10 Stück - so als Idee.
Torsten C. schrieb: > Ich habe bisher keine Quelle für Copter ohne Fernbedienung gefunden. Hat > jemand dazu schon mal Aktivitäten entfaltet? Wenn nicht, würde ich die > Anbieter alle mal anschreiben, z.B. für 10 Stück - so als Idee. Vielleicht macht http://www.tmart.com so etwas ja? Meine Bestellung von dort ist inzwischen gut verpackt eingetroffen. Ich kann mich nicht beschweren.
Hat sich mal jemand dieses Kameramodul angeschaut? http://www.tmart.com/Hubsan-X4-H107C-RC-Quadcopter-Spare-Parts-H107-A28-Camera-Module-30W_p226133.html
Manuel Steiner schrieb: > Edit: Die ARM Debug Interface Architecture Specification könnte noch > interessant sein. (Kapitel 5.2) > > http://www.pjrc.com/arm/pdf/doc/ARM_debug.pdf Das hilft auf jeden Fall schon einmal deutlich weiter. Vielen Dank! Die Schnittstelle scheint eine Art bidirektionales SPI zu sein. Das Protokoll ist allerdings doch etwas komplexer, dafür bräucht man wohl einen Protokoll-Analyzer.
Ich suche momentan auch ne Kamera. Aber eher für meinen großen. Habt Ihr euch mal die T9000 angeschaut? Was ist dann da der unterschied zur T8000 habe nur gesehen das die T9000 anscheinend flüssiger läuft. Oder doch die Y3000. Bei Aliexpress liegen zwischen der Y3000 und der T9000 nur knapp 10$.
Also ich hab die HD-Keycam #16 V2. Mit einem dem größeren Öffnungswinkel der Optik macht die ganz passable Aufnahmen. Wenn man die auspackt und an den Flugakku anschließt, müsste sie auch von unserem kleinen getragen werden können. Mein V929 trägt sie ganz gut. Fliegen macht dann nur kein Spaß mehr...
Tim schrieb: > Hat sich mal jemand dieses Kameramodul angeschaut? > > http://www.tmart.com/Hubsan-X4-H107C-RC-Quadcopter-Spare-Parts-H107-A28-Camera-Module-30W_p226133.html ist das echt eine cam oder ein laser?
Meiner ist da und schon kaputt :D 2 stockwerke tief gefallen ist das teil auf stein jetzt da hat der motor sich schlecht gedreht , das hab ich behoben nur jetzt bekomm ich nichtmehr den anker in die bürsten :( kann mir da jemand einen Tipp geben ? Das problem war das das lager hoch gerutscht ist und der anker aus der bürste gerutscht ist .
Turbonator schrieb: > ich behoben nur jetzt bekomm ich nichtmehr den anker in die bürsten :( > kann mir da jemand einen Tipp geben ? Leider nur den hier: http://www.tmart.com/2Pcs-JXD-385-006-Alloy-Reverse-Rotation-Motors-Set-for-RC-Helicopter-Metal-Color_p192101.html Aber wenn der Copter flügellahm ist, ist ja mehr Zeit an der Hardware herumzubasteln :)
Hat noch jemand bei bessky_cn bestellt und auch die Ware erhalten? Ich habe inzwischen den Verdacht, dass gar nichts verschickt wurde.
Hmm 4€ für 2 Motoren? Ich hab mir einfach noch nen 2. bestellt.. :D lohnt sich glaub mehr... Hat man alles nochmal als Ersatzteile und zudem einen zum basteln während der andere zum heitzen funktioniert...
Tim schrieb: > Hat noch jemand bei bessky_cn bestellt und auch die Ware erhalten? Ich > habe inzwischen den Verdacht, dass gar nichts verschickt wurde. Ich habe bei dem bestellt, warte wie gesagt noch immer
Nach 40 Tagen läuft Paypal Käuferschutz aus. Würde früh genug das melden. Oder bestellt euch doch schnell den einen aus Frankfurt für 25€.. :http://www.ebay.de/itm/JD-185-MINI-Quadcopter-6-axis-2-4ghz-4-Kanal-Gyro-UFO-MINI-RC-Helikopter-/171097513221?clk_rvr_id=542414730071 Ist ja der selbe wie der aus China..
Tim schrieb: > Hat noch jemand bei bessky_cn bestellt und auch die Ware erhalten? Ich > habe inzwischen den Verdacht, dass gar nichts verschickt wurde. Habe am 11.10.2013 bestellt und der Copter ist noch nicht da. Allerdings ist es bereits der 2. Copter den ich bei bessky_cn bestellt habe. Der erste kam nach knapp zwei Wochen. Also Geduld.
Der copter läuft wieder das war den aufwand ja fast nicht wert für den preis des motors aber danke für den link
Ich weiss nicht obs schon erwähnt wurde, es gibt eine Rekalibrierung: "Maximum speed mode (press twice left button) and put both stick lower left. Led will blink fast when calibration is done." Meiner fliegt nun viel weniger driftend. Mir ist noch aufgefallen, dass er direkt nach einem Crash oft stark in eine Richtung driftet, etwa fünf Sekunden später geht es wieder.
hubsi schrieb: > Ich weiss nicht obs schon erwähnt wurde, es gibt eine Rekalibrierung: > "Maximum speed mode (press twice left button) and put both stick lower > left. Led will blink fast when calibration is done." Danke für den Tipp. Woher hast du ihn?
Ursus schrieb: > Habe am 11.10.2013 bestellt und der Copter ist noch nicht da. Bestellt am 15.10, als verschickt markiert am 17.10 ... noch ein wenig abwarten
hubsi schrieb: > Ich weiss nicht obs schon erwähnt wurde, es gibt eine Rekalibrierung: > "Maximum speed mode (press twice left button) and put both stick lower > left. Led will blink fast when calibration is done." Funktioniert bei meinem Copter nicht.
Joachim Drechsel schrieb: >> Danke für den Tipp. Woher hast du ihn? > > Steht im Handbüchlein. Habe leider nur ein chinesisches Büchlein mitbekommen.
Diese Rekalibrierung ist genau die, die auch nach dem Einschalten gemacht wird, sobald sich der Kopter für eine Sekunde nicht mehr bewegt hat
Chris L. schrieb: > Diese Rekalibrierung ist genau die, die auch nach dem Einschalten > gemacht wird, sobald sich der Kopter für eine Sekunde nicht mehr bewegt > hat Stellt sich die Frage, warum die Kalibrierung über die beiden Steuerknüppel aufgerufen werden kann.
Chris L. schrieb: > Diese Rekalibrierung ist genau die, die auch nach dem Einschalten > gemacht wird, sobald sich der Kopter für eine Sekunde nicht mehr bewegt > hat Gefühlt funktioniert es hier besser seit der Rekalibrierung :)
Ursus schrieb: > Stellt sich die Frage, warum die Kalibrierung über die beiden > Steuerknüppel aufgerufen werden kann. Damit man den rekalibrieren kann. Hmmm, aber das weißt Du ja selbst. Wie ist denn die Frage gemeint? Oder ist Deine Frage, wozu überhaupt eine Kalibrierung gemacht wird? Ist jedenfalls einfacher als den Akku-Stecker aufzutrennen.
:
Bearbeitet durch User
Ich habe es jetzt nochmal mit dem LA versucht. Habe jetzt auf rst getriggert und hatte auch festgestellt, dass ich rst und data vertauscht hatte. Kommt halt davon wenn man das abends vor der Glotze macht. Sieht jedenfalls sinniger aus. Fragt sich nur ob man damit was anfangen kann.
Was ich komisch finde ist, dass man mit dem J-Link bei dem copter nichts reißen kann... Ich hab gedacht der Nu-Link ist auch ein abgespeckter J-Link. Wie z.b die ST-Link und viele mehr.. Oder liegt es an Keil und mit Coocox geht es?
Robert Knipp schrieb: > Sieht jedenfalls sinniger aus. Fragt sich nur ob man damit was anfangen > kann. Na das sieht doch schon deutlich besser aus :) Danke, muss man mal schauen ob das was mit normalen SWD zu tun hat, oder eigenes Zeug ist. Vielleicht hilft ja auch einfach mal nachprogrammieren und den MCU damit vollspammen :D
No y. schrieb: > Was ich komisch finde ist, dass man mit dem J-Link bei dem copter nichts > reißen kann... > > Ich hab gedacht der Nu-Link ist auch ein abgespeckter J-Link. Wie z.b > die ST-Link und viele mehr.. Also soweit ich weiß ist J-Link primär ein JTAG Teil, kann aber auch SWD. Und Keil muss zum löschen seine Löschroutine in den RAM schreiben, und führt diese Routine dann aus, welche den Flash löscht. Der RAM is aber leider ebenso wie der Flash gesperrt. Von daher ist es glaub ich völlig egal mit welchem Teil man da verbindet. Wahrscheinlich macht das ICP Tool wirklich kein normales SWD für das unlocken und löschen. Und das ICP Tool wird eben gleich mal überprüfen, ob da ein Nulink am PC hängt oder nicht.
Robert Knipp schrieb: > Fragt sich nur ob man damit was anfangen > kann. Kann man da eigentlich noch etwas weiter hineinzoomen? Oder geht da nichts mehr? Also in der Software selbst, für die Screenshots
Robert Knipp schrieb: > Ich habe es jetzt nochmal mit dem LA versucht. Habe jetzt auf rst > getriggert und hatte auch festgestellt, dass ich rst und data vertauscht > hatte. Kommt halt davon wenn man das abends vor der Glotze macht. > Sieht jedenfalls sinniger aus. Fragt sich nur ob man damit was anfangen > kann. Das sieht wirklich deutlich sinniger aus :) Verbirgt sich unter dem Menupunkt "Decoder" evtl. etwas, um die Daten in ein verständlicheres Format umzuwandeln? Prinzpipiell könnte ein SPI decoder funktionieren, auch wenn SWD anscheinend nicht immer 8 bit Pakete sendet und Dummyzyklen für die Richtungsumstellung hat.
:
Bearbeitet durch User
Besser gehts leider nicht.... Das erste is übrigens die linke Seite vom vorigen Bild und das zweite die rechte Seite. Manuel Steiner schrieb: > Vielleicht hilft ja auch einfach mal nachprogrammieren und den MCU damit > vollspammen :D Mal ne dumme Anfängerfrage. Wie bekomme ich denn aus den LA Aufzeichnungen die korrekten Timings für die Signale raus? Die Reihenfolge der 0en und 1en kann man ja leicht erkennen. Aber wie lange müssen die Signale anliegen?
:
Bearbeitet durch User
Das hier könnte interessant sein: http://www.ie.ksu.edu.tw/data/nuvoton/Training%20Material/NuMicro%20Mini51%20Series/2_8NuMicro%20Mini51%20FMC.pdf Auf den höheren Ordnern gibt es noch mehr.. http://newsletter.atxx.de/cms/website.php?id=de/index/atelektronik/atxx/data5357.html Ist hier die .bin Datei nicht die Firmware vom Nulink? Oder hab ich das in der einen Präsentation falsch verstanden? Kann man damit was Anfangen?
:
Bearbeitet durch User
Tim schrieb: > Das sieht wirklich deutlich sinniger aus :) Verbirgt sich unter dem > Menupunkt "Decoder" evtl. etwas, um die Daten in ein verständlicheres > Format umzuwandeln? Prinzpipiell könnte ein SPI decoder funktionieren, > auch wenn SWD anscheinend nicht immer 8 bit Pakete sendet und > Dummyzyklen für die Richtungsumstellung hat. Der Decoder kann auch SPI. Aber was stelle ich da ein? Edit: Ich bekomme da leider keine Einstellung hin die er akzeptiert. Mindestens ein Kanal bleibt immer rot.
:
Bearbeitet durch User
Robert Knipp schrieb: > Aber was stelle ich da ein? "Ignore Slave Select" aktivieren? MISO, MOSI: einen Kanal mit Data, den anderen mit einem freien Kanal belegen; evtl. den unbenutzen auf definiertes Potential legen? Ob SWD und SPI das gleiche Protokoll zu grunde liegt kann ich nicht sagen, d. h. der Dekoder versteht die Botschaften evtl. nicht. Man sieht ja schon einen Unterschied bei den Datenkanälen.
:
Bearbeitet durch User
No y. schrieb: > Ich hab mir einfach noch nen 2. bestellt.. :D lohnt sich glaub mehr... Beim Bestellen darauf achten, dass zwei Motoren links herum drehen und zwei rechts herum!
Georg G. schrieb: > ... zwei Motoren links herum drehen und zwei rechts ... Lustig. :-) Noy meinte einen zweiten Hack-o-copter. Da sind immer zwei links und zwei rechts.
Da Nuvoton ARM- und 8051-Controller herstellt, und ein ARM für die Fernbedienung etwas übertrieben ist, nehme ich an, dass dort eine 8051-Derivat verbaut ist. Nur welches? Die Bezeichnung auf dem Controller lautet: NUVOTON CN2-S20 3118BD293 B118 ZN2DA Suchmaschinen geben nichts her. Wer weiß mehr?
Hat sich mal jemand von den "Cracks" mal die PDFs angeschaut aus dem oben geposteten Link? Bringt das irgendwas? Wie gesagt die höheren Ordner haben noch mehr..
No y. schrieb: > Hat sich mal jemand von den "Cracks" mal die PDFs angeschaut aus dem > oben geposteten Link? Bringt das irgendwas? Wie gesagt die höheren > Ordner haben noch mehr.. Ich hab mir mal die PDFs durchgesehen, aber außern den ISP (serieller Bootloader) Routinen (mit Code) und Speicherlayout usw (welche man auch im Datenblatt findet) wäre mir nicht viel Besonderes aufgefallen. ISP bringt uns leider relativ wenig, da eben alles gesperrt ist und erstmal mit dem ICP Tool entsperrt werden muss. Zu ICP ist nur die übliche Folie mit dem Screenshot vorhanden. Ich bezeichne mich jetzt allerdings nicht als "Crack". Vielleicht ist jemanden anderen ja noch etwas aufgefallen.
Geht ISP ? B15 oder D0 auf GND . Wenn ja braucht man nur rs232/usb. Ansonsten über CooCox und z.B. ST-Link oder OpenJtag/... APROM programmieren.
chris schrieb: > Geht ISP ? B15 oder D0 auf GND . Wenn ja braucht man nur rs232/usb. > Ansonsten über CooCox und z.B. ST-Link oder OpenJtag/... APROM > programmieren. Wie bereits öfter im Thread geschrieben: Nein. Ist gesperrt. Laut Tim ist da zwar irgend etwas für die serielle Schnittstelle am MCU zuständig, reagiert jedoch weder auf manuelle Eingaben noch auf das Nuvoton ISP Tool. Vielleicht ein proprietärer Bootloader Außer unlock und erase über ICP bietet sich im Moment keine Möglichkeit, den MCU mal so weit zu bringen, dass er programmiet werden kann.
Wäre es vielleicht einfacher zu versuchen das ICP Tool anzupassen... Also das auch der J-Link oder der ST-Link ist ja das selbe mit dem ICP läuft?? Bzw. hat es jemand schonmal mit coocox probiert anstatt Keil?
No y. schrieb: > Wäre es vielleicht einfacher zu versuchen das ICP Tool anzupassen... > > Also das auch der J-Link oder der ST-Link ist ja das selbe mit dem ICP > läuft?? > > > Bzw. hat es jemand schonmal mit coocox probiert anstatt Keil? Ja also wenn die Waveform bzw. das Timing für das erase und unlocking bekannt ist, kann man das ja durchaush in ein Discovery Board MCU flashen oder so und damit dann den MCU unlocken und erasen einmalig. Das wird auch gerade probiert. Robert hat dazu auch schon Waveforms gepostet. Die Vermutung liegt nahe, dass Coocox genau so wie Keil eine Löschroutine in den RAM laden muss, um den Flash zu löschen, und das funktioniert ja bekanntlich nicht.
Ja das mit den Waveforms hab ich alles gelesen. Ich meinte aber eher wirklich am PC das ICP Tool austricksen. So dass man das Tool normal benutzt was ja den löschvorgang kann aber mit nem ST-Link. Z.B vielleicht ist die das Tool nur über VID/PID an den Nu-Link gebunden. Sodass man vielleicht dort nur die VID/PID abändern muss oder es steht irgendwo in einer dll oder so drin... Werde es mir mal runterladen und mal schauen was so für dateien dabei sind und ob man etwas findet...
Manuel Steiner schrieb: > Ja also wenn die Waveform bzw. das Timing für das erase und unlocking > bekannt ist, kann man das ja durchaush in ein Discovery Board MCU > flashen oder so und damit dann den MCU unlocken und erasen einmalig. Das > wird auch gerade probiert. Robert hat dazu auch schon Waveforms > gepostet. Um den Bildern etwas entnehmen zu können, muss die Auflösung höher sein. Es dürfte nicht schwierig sein, das Ganze in einen ATTiny oder so zu gießen.
Ich hab leider keinen Nu-Link und noch nicht den 2. Copter hier... Sonst hätte ich es mal versucht mit meinem Saleae oder dem open Bench LS aufzunehmen...:(
No y. schrieb: > So dass > man das Tool normal benutzt was ja den löschvorgang kann aber mit nem > ST-Link. Ich schätze mal schon, dass das ICP Tool da mit dem Nulink ein wenig kommuniziert und das Nulink seinen Teil dazu beträgt, dass das löschen dann funktioniert. Also ich will darauf hinaus, dass das ICP Tool wahrscheinlich nicht genau so mit einem ST Link kommunizieren kann wie mit einem Nulink. Aber ich finde den Ansatz an sich nicht schlecht, vielleicht findet man ja wirklich etwas.
Mors ultima schrieb: > Es dürfte nicht schwierig sein, das Ganze in einen ATTiny oder so zu > gießen. Muss ja nicht unbedingt ein Atmel Teil sein, kann ja auch ein MCU auf einem Discovery sein. Aber die Aufläsung muss tatsächlich höher sein, um da etwas zu erkennen. Den Open Bench LS hab ich auch hier liegen, aber auch noch keinen Nulink.
Hat eigentlich jemand schonmal in so einen Nu-Link reingeschaut, ob da viel mehr als ein µC und die Spannungsversorgung/schutz drin ist? Sonst kann man vielleicht irgendwo die Firmware des Nu-Link finden. Optimalerweise als Source Code.. Als .bin findet man die ja im Netz...
:
Bearbeitet durch User
Ich hab ja wie bereits mal geschrieben im Nuvoton Forum gefragt, ob die mir mehr über ICP erase sagen können ... Wollten aber wie erwartet nichts rausrücken.
So hab meinen Quad jetzt doch mal an meinen J-Link drangemacht... In JFlash Connected er auch. Aber auslesen geht nicht bzw. es kommt eine Fehlermeldung... Muss mir da nochmal die Configuration anschauen.. Bei JFlash kann ich auch einzelne Adressen angeben wo etwas hingeschribene werden soll... Kann ich jetzt nicht einfach die Adresse des LockBit angeben und da mal ne 0 bzw 1 reinschreieben?? Weiß jemand gerade welche Adresse da beschriben werden muss und mit was?
Im Datenblatt Seite 74 steht doch was gemacht werden muss um den Chip zu unlocken.. Oder versteh ich da was falsch?
No y. schrieb: > Im Datenblatt Seite 74 steht doch was gemacht werden muss um den Chip zu > unlocken.. > > Oder versteh ich da was falsch? Mein Datenblatt hat nur 68 Seiten!?
No y. schrieb: > Im Datenblatt Seite 74 steht doch was gemacht werden muss um den Chip zu > unlocken.. Du kannst, durch das Schreiben von 0x59, 0x16, 0x88 auf die Adresse 0x5000_0100, die Register freigeben. Das Problem, das du dann hast ist, dass du mittels ISP den Chip nicht löschen kannst (siehe Seite 139).
Hm geht nix... bzw. wenn ich erasen will meckert Jflash das ich keine Lizenz hab... Hab ich ja auch net mim EDU...
Ich muss mich mal reinlesen... Den Unterschied zwischen ISP und ICP kenne ich bisher nicht. Wie gesagt komme von PICs bisher... Da gibts ICSP beim Pickit.
No y. schrieb: > ICSP beim Pickit. Praktisch, das ist dann ja wohl eine Kombination aus beiden :) Beim MINI54ZAN: ISP= Flashen über den potentiell eingebauten Bootloader und die serielle Schnittstelle. ICP= Flashen über SWD. So wie ich es verstehe kann ein gesperrter Controller nur über ICP entsperrt werden.
Tim schrieb: > ICP= Flashen über SWD. So wie ich es verstehe kann ein gesperrter > Controller nur über ICP entsperrt werden. Genau so verstehe ich das auch
Ich habe mir jetzt gerade mal Keil MDK 5 runtergeladen und wollte ein neues Projekt anlegen. Ich kann als Target aber nicht nuvoton auswählen... Es gibt nur ARM und STM32... Wenn ich dann aber auf File/Device Database gehe ist alles drin... Versteh ich nicht... Vor allem versteh ich auch die Einstellungen bei meinem J-Link GDB Server Config file nicht... Z.B welchen Controller muss ich denn auswählen es gibt nur 4 mal Mini54LAN statt ZAN aber dürfte der gleiche sein oder? Vor allem warum 3 mal??
No y. schrieb: > Ich kann als Target aber nicht nuvoton auswählen... Es gibt nur ARM und > STM32... Schau mal hier: Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter"
Der zweite (von meinem Sohn) ist heute angekommen, am 13.10.2013 bei ebay 190881964364 bestellt. Inzwischen fliegt mein Sohn ("Pilot Jonas") viel besser als ich. Außerdem kamen die Akkus an, http://www.aliexpress.com/snapshot/278000072.html. Marius S. schrieb: > Mein Quadcopter schaltet sich immernoch ab und zu einfach schlagartig > aus. Als Jonas flog, haben wir was beobachtet: Mit den größeren Akkus funktioniert auch die "Low-Batt-Anzeige". Die LEDs beginnen erst langsam zu blinken, dann schneller, erst dann läßt die Motorleistung nach. @Tim: Ist Dein Bu-Link schon da? Wenn der gehnt, bestelle ich auch einen. Ich hab' ja nun auch einen zum "kaputtflashen".
:
Bearbeitet durch User
Mors ultima schrieb: > Manuel Steiner schrieb: > >> Ja also wenn die Waveform bzw. das Timing für das erase und unlocking >> bekannt ist, kann man das ja durchaush in ein Discovery Board MCU >> flashen oder so und damit dann den MCU unlocken und erasen einmalig. Das >> wird auch gerade probiert. Robert hat dazu auch schon Waveforms >> gepostet. > > Um den Bildern etwas entnehmen zu können, muss die Auflösung höher sein. > Es dürfte nicht schwierig sein, das Ganze in einen ATTiny oder so zu > gießen. Auf nen Screenshot bekomme ich leider nicht mehr drauf. Aber die Datei im Anhang kann man in der MiniLA Anwendung öffnen. Den Link gibts im Artikel zum LA: http://www.mikrocontroller.net/articles/Minila_Version_MockUp Damit könntet Ihr Euch das genauer anschauen. Vielleicht kann man ja auch die .vcd Datei in einer anderen LA Anwendung öffnen.
Ich hab das "Ladegerät" gestern an ein älteres USB-Handynetzteil, das eher 6V als 5V hat, gehängt und dabei ist mir das Ladegerät geschmolzen. Ich habs mal aufgemacht, im Anhang der Schaltplan, nur der 2-Ohm-Widerstand ist gemessen. Transistor ist geraten, ist ein SOT-23, beschriftet mit L6. Am 6V-Netzteil lädt das ding mit 400+mA, am 5V-Netzteil mit 260mA. Das Gehäuse des Ladegeräts wird auch mit 5V bei mir warm.
hubsi schrieb: > … das eher 6V als 5V hat Ich habe bisher "blind vertraut", aber nun auch mal nachgemessen: Bei 4,32V geht die rote Lade-Lampe aus und die Akku-Spannung geht auf 5,05V hoch . Ich habe das Verhalten bei beiden Ladegeräten. Ich denke, diese "Ladegeräte" sollte man keinesfalls verwenden.
Torsten C. schrieb: > Bei > 4,32V geht die rote Lade-Lampe aus und die Akku-Spannung geht auf 5,05V > hoch . Diese Aussage passt nicht zu dem publizierten Schaltbild. Da leuchtet die LED wird immer, relativ unabhängig von der Akkuspannung.
hubsi schrieb: > Und genau dabei kann es auch die Achse durch den Motor nach unten > drücken, dann brauchst du einen neuen Motor. "Pilot Jonas" hat deshalb auf seinen einen Schaumstoff-Klotz geklebt, der wiegt genau 1,0g. Anbei ein Foto des "Ladegeräts". Ich beobachte das Verhalten und die Spannungen nochmal weiter ...
Georg G. schrieb: > Diese Aussage passt nicht zu dem publizierten Schaltbild. Da leuchtet > die LED wird immer, relativ unabhängig von der Akkuspannung. Ich hab vergessen dazu zuschreiben, dass ich den Schaltplan abgepinselt habe, und er daher Fehler enthalten kann.
Georg G. schrieb: > Diese Aussage passt nicht zu dem publizierten Schaltbild. Oder das Schaltbild passt nicht zur Aussage. Ich denke, das ist ein PNP und die "LED-Aus-Spannung" wird von der Vorwärtsspannung der LED gegen die 5V bestimmt. Bei 6V ist auch die "LED-Aus-Spannung" entsprechend höher. Von einer "Ladeschlusspannung" kann nicht die Rede sein. 5..6V machen jeden LiPo-Akku kaputt. Wahrscheinlich hätten die Chinamänner die Diode (links auf Dsc_6189.jpg) bestücken sollen.
Hallo Leute, ein sehr interessanter Thread, ich habe auch einen Quadrocopter, zwar etwas größer aber mit den gleichen Chips. Ich möchte etwas zum 'Laderegler' beitragen. Der verwendete Transistor hat die Kennung 'L6', ist also ein 2SC1623, NPN, Ic=100mA, hFE=200..400 Von einem Laderegler mag ich bei dem Schaltbild gar nicht sprechen, es findet keine Regelung statt. R4 begrenzt lediglich den Ladestrom, eine Ladestromabschaltung erfolgt nicht. Bei einem 6V Netzteil und leerem Accu mußte R4 mehr als 3W Leistung verbraten, ich glaube im Dunkeln hätte er geleuchtet. Nach Schaltbild leuchtet D1 bei erreichen einer bestimmten Spannung am Spannungsteiler R2 / R3 Wie Torsten C. schon schreibt passt das Schaltbild nicht zu einer erlöschenden LED Aus 'Dsc_6189.jpg' kann ich aber auch nicht wirklich was Anderes erkennen. Ist da vielleicht noch was auf der Rückseite? Aber letzlich ist das auch egal. Auf jeden Fall ist dieser Ladeadapter ein Accu schädigendes Teil.
Ich habe selbst nochmal den Ladestecker geöffnet und selbst mal nachgeschaut. Im Anhang der Schaltplan, wie er bestückt ist. Vorgesehen sind weiterhin ein Widerstand parallel zum Akku und eine Diode in Reihe zum 2 Ohm Shunt.
Wo schrieb: > ist also ein 2SC1623 Warum kann das z.B. kein BSS69R sein? Der wäre PNP. Geht die LED bei Euch aus oder an? Bei mir geht sie aus, wenn der Akku voll ist. PS: Ich bae zum Glück noch einen Walkera Lama2. Da war ein ordentliches Ladegerät dabei und der Steker passt! :-p ;-)
:
Bearbeitet durch User
Was wäre denn eine gute Alternativschaltung mit leicht verfügbaren Bauelementen? Man könnte ja das bestehende Ladegerät schlachten und eine eigene Platinen im gleichen Format einsetzen?
Chris L. schrieb: > Im Anhang der Schaltplan, wie er bestückt ist. So macht er Sinn. Die LED geht aus, wenn der Ladestrom unter einen festen Wert sinkt (etwa 170mA bei 4.2V am Akku als erste Näherung).
Ich habe mal mit einem Saleae Logicanalyer den Datanverkehr vom ST-Link mitgeschrieben. Einmal für den Start einer Debug-Session und einmal für eine versuchte "Erase"-Operation. Beides erzeugt eine Unmenge an Daten, die sich ohne Protokollanalyzer kaum untersuchen lassen. Files anbei, sie lassen sich mit "Logic" anschauen. Bleibt zu hoffen, dass der Chip-Erase wirklich so einfach ist. Ich werde einfach mal weiter auf den "Bu-Link" warten. Wenn er wirklich funktioniert, gibt es kaum einen Anlass, eine Alternativlösung zu entwickeln. (http://www.aliexpress.com/item/Free-Shipping-NuLink-BuLink-Compatible-Cortex-M0-M051-ISP-ICP-Program/674565728.html)
Chris L. schrieb: > ladeanzeige.png Ist ja gruselig. Das kann man doch nicht als Ladegerät bezeichnen. Ich habe hier noch einen MAX1551, den werde ich mal da rein pflanzen.
Marius S. schrieb: > Ist ja gruselig. Das kann man doch nicht als Ladegerät bezeichnen. Du musst das aus Sicht eines Kindes sehen (der Copter wird als Spielzeug angeboten): Das Kind will spielen. Leider ist bald der Akku leer. Also wird geladen und laufend auf die LED geschaut, ob er schon voll ist. Überladen also fast unmöglich. Und wenn dann die Lust am Fliegen für heute vorbei ist, wird der Kram entladen zurück gelegt. Du musst das mehr aus Sicht eines BWLers sehen, weniger als Techniker.
>> ist also ein 2SC1623 > Warum kann das z.B. kein BSS69R sein? Der wäre PNP. Weil ich keine PNP Transistoren mag, die waren immer so schwer zu beschaffen. Aber Spaß beiseite. Ich war tatsächlich bis vor wenigen Minuten der Meinung daß sich aus der Kennung der Transistor genau bestimmen läßt. Nun bin ich zu der Erkenntnis gekommen - die Kennung ist ohne original Schaltbild völlig nutzlos. Wenn Torsten C. einen PNP einsetzt und die LED tut was sie soll dann hat das Rätselraten wohl ein Ende. @ Chris L: Der Transistortype 2SC1623 kann nicht stimmen, ich hab mich da geirrt, mit dem von Torsten C. angenommenen PNP Transistor paßt das am Besten.
Wo schrieb: > @ Chris L: Der Transistortype 2SC1623 kann nicht stimmen, ich hab mich > da geirrt, mit dem von Torsten C. angenommenen PNP Transistor paßt das > am Besten. In diesem Fall sähe der Schaltplan folgndermaßen aus
Chris L. schrieb: > In diesem Fall sähe der Schaltplan folgndermaßen aus Wie herum sind denn die Polaritäten der Anschlüsse?
Chris L. schrieb: > In diesem Fall sähe der Schaltplan folgndermaßen aus wobei die LED nie leuchten würde :-)
Das die nicht leuchten würde ist mir klar. Aber im Schaltplan von Hubsi sind die Polaritäten komplett vertauscht. Das stimmt nicht mit dem Aufdruck auf meiner Platine überein. (Bei mir liegt der Shunt zum Beispiel in der Minusleiterbahn, auch auf der Platine ist dies so) Oben und Plus und unten ist Minus. Beim Transistor ist oben Collector und unten Emitter, das habe ich gemäß datenblatt du ermittelt.
Wenn "ladeanzeige.png" stimmt, ist es NPN. PNP hätte bei Hubsis Plan Sinn gemacht. Mann, was soll das erst werden, wenn wir uns über Flugstabiliserungs-Regelalgorizhmen unterhalten? Naja, im Moment überbrücken wie ja die Zeit, bis Tim den Bu-Link getestet hat.
Georg G. schrieb: > Chris L. schrieb: >> In diesem Fall sähe der Schaltplan folgndermaßen aus > > wobei die LED nie leuchten würde :-) Einfach einmal ausprobieren: die leuchtet auf mit dem PNP. Es ist ein NPN in der Schaltung, da so die Schaltung wie beobachtbar "funktioniert" (siehe Anhang). LED-Strom: grün Akku.Strom: blau
da ich keine Lust hatte, den transistor auszulöten und an den Komponententester anzuschließen, habe ich mit dem Diodentest meine Multimeters mal gemassen. Ich konnte zwei dioden messen, die beide an Basis ihre Anode haben. Also ein NPN-Transistor [EDIT]Danke Davis, ich wollt auch grad anfangen, das ganze mal durch den Simulator zu jagen
:
Bearbeitet durch User
Das kann doch alles nicht war sein ... ich glaub das Teil veralbert uns :-)
Davis schrieb: > Einfach einmal ausprobieren: die leuchtet auf mit dem PNP. Kannst du das bitte etwas näher erläutern? Zwei Möglichkeiten: 1.) oben ist PLUS. Dann wäre die LED in Flussrichtung und könnte leuchten - was aber durch die in Sperrrichtung liegende Collector-Basis-Strecke des PNP verhindert wird. 2.) oben ist MINUS. Nun könnte der Transistor leitend werden. Aber dummerweise ist die LED nun in Sperrrichtung. Also auch dunkel.
Georg G. schrieb: > Davis schrieb: >> Einfach einmal ausprobieren: die leuchtet auf mit dem PNP. > > Kannst du das bitte etwas näher erläutern? 1. Fall (Emitter -> GND, Kollektor -> LED). Der Strom fließt durch die LED und vom Kollektor über die Basis nach GND. 2. Fall (Kollektor -> GND, Emitter -> LED). Der Strom fließt durch die LED und vom Emitter über die Basis nach GND. Beide Fälle lassen sich leicht auf dem Steckbrett überprüfen.
Es kam wie es kommen musste. Meiner liegt auf Nachbars Garagendach. Mit dem Kopf nach unten. Heul...
Wo schrieb: > Auf jeden Fall ist dieser Ladeadapter ein Accu > schädigendes Teil. Hmmm, bist Du da sicher? Ich hatte zwischen Aldi-Ladegerät mit USB-Steckdose (und Ladeschächten für alle üblichen NiMH-Rundzellen und 9V-Blöcke) und dem mitgelieferten USB-Lader einen USB-Strom/Spannungs-Tester geschaltet: http://www.ebay.de/itm/USB-Power-Current-and-Voltage-Tester-USB-Mobile-Power-Current-Test-HS-/221244340179 Dieser zeigte während des Ladens (bei leuchtender LED) um die 400 mA an, nach dem Laden bei erloschener LED 0 mA. Das sagt mir, dass der Lader den Ladestrom sauber abschaltet. Die Eingangsspannung war 5,0 V und brach während des Ladens nur gering ein. ...
Torsten S. schrieb: > Meiner liegt auf Nachbars Garagendach. Mit > dem Kopf nach unten. Da muss dann wohl der Berge-Copter ran... 8-( Käffchen? ...
Torsten S. schrieb: > Es kam wie es kommen musste. Meiner liegt auf Nachbars Garagendach. Mit > dem Kopf nach unten. > > Heul... Ich fühle mit dir ... Meiner könnt dann auch endlich mal ankommen hier, ist ja kaum auszuhalten.
:
Bearbeitet durch User
Seit Ihr Euch ganz sicher daß das Schaltbild korrekt ist? Unabhängig vom Transistor. Ich beziehe mich jetzt mal auf das 'ladeanzeige_pnp.png' von Chris L. Ich habe einen etwas anderen Ladeadapter, aber genau so sparsam aufgebaut. Bei dem hängt der Transistor mit einem Bein zwischen LED1 und R1, LED1 entsprechend direkt an Minus. Eventuell mal durchklingeln (den Ausdruck kennt Ihr wohl garnicht :-) ) um bei den Vebindungen sicher zu gehen.
Hannes Lux schrieb: > Torsten S. schrieb: >> Meiner liegt auf Nachbars Garagendach. Mit >> dem Kopf nach unten. > > Da muss dann wohl der Berge-Copter ran... 8-( > > Käffchen? > > ... Na klar, aber wie immer ;)
Wo schrieb: > Seit Ihr Euch ganz sicher daß das Schaltbild korrekt ist? Unabhängig vom > Transistor. > > Ich beziehe mich jetzt mal auf das 'ladeanzeige_pnp.png' von Chris L. > > Ich habe einen etwas anderen Ladeadapter, aber genau so sparsam > aufgebaut. Bei dem hängt der Transistor mit einem Bein zwischen LED1 und > R1, LED1 entsprechend direkt an Minus. Dann geht deine LED nach dem Ladeschluss an. Beide Varianten der Schaltung sind gleich "gut".
Hannes Lux schrieb: > Hmmm, bist Du da sicher Ja. Nach 'ladeanzeige_pnp.png' von Chris L. und meinem etwas anderen Adapter gibt es nicht was die Verbindung zum Accu trennt, der Transistor kann es nicht, egal welcher Typ. Wenn ab einer bestimmten Spannung tatsächlich kein Strom mehr fließt kann das nur bedeuten das der Accu selber abschaltet (eigene Elektronik). Das würde auch die Funktionsweise der LED erklähren. Eine ander Erklährung habe ich derzeit nicht.
Ich habe mich einfach mal 'dran gemacht, ein neues Innenleben für das Ladegerät zu designen. Ich habe mich dabei für den MCP73831 entschieden, da er recht günstig zu haben ist. Anbei schon einmal die Schaltung. Beim Layout kämpfe ich noch mit dem USB-Stecker, da er in dem Ladegerät recht merkwürdig installiert ist. Eine Frage: Was verträgt der Akku denn für einen Ladestrom? Dieser kann über R1 eingestellt werden.
:
Bearbeitet durch User
Die kleinen Akkus haben eine Kapazität von 240 mAh, der Ladefaktor liegt bei 1,4 und die Ladezeit der mitgelieferten USB-Lader bei 45 Minuten. Das wären dann rund 450 mA.
Platinen dauern doch immer länger als man denkt. Anbei das Platinenlayout für den Ersatz-LiPo Charger. Die Platine ist etwas kleiner als das Original und sollte in das gleiche Gehäuse passen. Es gibt eine einsetige Version und eine Zweiseitige, bei der, wie im Datenblatt vorgeschlagen, die Rückseite zur Wärmeableitung dient. Gibt es noch Ideen? Würde ansonsten Teile für ein paar Prototypen ordern... Alle relevanten Dateien liegen im Repository: https://github.com/hackocopter/LiPoCharger
Davis schrieb: > Die kleinen Akkus haben eine Kapazität von 240 mAh, der Ladefaktor liegt > bei 1,4 und die Ladezeit der mitgelieferten USB-Lader bei 45 Minuten. > > Das wären dann rund 450 mA. Danke! Ich habe den Ladestrom auf nominell 400mA gesetzt. (R1=2.5 kOhm)
Ich habe das Ladegerät wie im Anhang gezeigt modifiziert. Das lädt so mit knapp 100mA, dauert zwar länger als mit dem Original, aber lädt nur bis 4,2V.
Omega G. schrieb: > Ich habe das Ladegerät wie im Anhang gezeigt modifiziert. Das lädt so > mit knapp 100mA, dauert zwar länger als mit dem Original, aber lädt nur > bis 4,2V. Schick! Was ist das für ein IC?
Sooo... Ich hab's mal ausprobiert, der Accu schaltet selber ab. Ich hab ihn über Ladeadapter und auch direkt am Netgerät geladen. Die Abschaltspannung lag zwischen 4,5V und 4,9V abhängig vom Ladestrom. Das ist mit Sicherheit keine Spannungsabschaltung sondern eher eine Temperaturabschaltung. Gute Nacht
Der Akku schaltet selbstständig ab? Würde mich wundern, wenn da noch eine Elektronik drin versteckt ist...
erweitern mit zb. gps ;kamera ;bluetooth ;drucksensor ;kompass ; nicht alles aber was würde machbar sein nach deinem kenntnis stand
Noobi schrieb: > erweitern mit zb. gps ;kamera ;bluetooth ;drucksensor ;kompass ; nicht > alles aber was würde machbar sein nach deinem kenntnis stand Naja da serielle Schnittstelle und auch glaube I2C herausgeführt sind, und man eine eigene Firmware dafür schreibt wohl ziemlich viel. Die Grenze wird wohl eher das Gewicht sein. Ich meinte hier im Thread gelesen zu haben, dass hier das Limit bei 30g oder so liegt.
I2C ok aber hängt der nicht am gyro ? leiterbahn durchtrennen oder wie ?
Marius S. schrieb: > wenn da noch > eine Elektronik drin versteckt ist... Er schaltet ab, für den Ladeadapter oder das Netzgerät stellt sich das als Lastabwurf dar, von Elektronik habe ich nichts geschrieben.
Noobi schrieb: > I2C ok aber hängt der nicht am gyro ? leiterbahn durchtrennen oder wie ? Man kann dahinter noch weiter I2C Teile hängen. I2C ist ja ein Bussystem und das MPU6050 kann selbst für einen Subbus als Master agieren und die Daten von angehängten anderen I2C Geräten weitergeben, soweit ich das verstanden habe.
Noobi schrieb: > ja ok aber daran löten wird schwierig ,wo ? Ich würde bei den I2C Leiterbahnen kurz vor dem Gyro etwas den Lack (bzw. Silkscreen) runter kratzen und verzinnen. Danach das ganze mit etwas Kleber versiegeln.
Noobi schrieb: > ja ok aber daran löten wird schwierig ,wo ? Man kann sich ja ein einges PCB machen wo man alles anschließt, was man so haben möchte und ein mal I2C zum Haupt PCB führt. Die 2 Pins wird man schon wo anlöten können. Oder einfach parallel als I2C an den MCU hänten, jedes Slave Gerät hat ja sowieso eine eindeutige Adresse. Edit: Zu langsam. Danke nosilent :)
:
Bearbeitet durch User
Der Controller scheint auch noch einige freie Pins zu haben. Da sollte sich auch noch Peripherie anschließen lassen.
soweit hab ich auch schon gedacht, löten kann ich gut aber viel platzt ist da nicht wenn da etwas lötzinn wegläuft . vorverzinnen ok ja wird schon klappen :D
Noobi schrieb: > was würde machbar sein Alles bis max. ca. 20 Gramm, bei mehr hebt er vielleicht noch ab, aber Flugzeit und Agilität wären dann irgendwann zu schlecht. Wir hatten weiter oben schon mal ein Brainstorming. Noobi schrieb: > zb. gps; ja, s.o. > kamera; ja, s.o. > bluetooth; ja, s.o. > drucksensor; ja, s.o., bringt aber bei DGPS nichts mehr. > kompass; wozu? Ginge aber auch. Der MPU-9150 ist z.B. fast SW- und Pinkompatibel zum MPU-6050. Manuel Steiner schrieb: > das MPU6050 kann selbst für einen Subbus als Master agieren Ja, aber das hat gegenüber "direkt anschließen" keine Vorteile, außer (1) man bekommt die "Motion Processing Unit" zum Laufen. Das ist für uns aber vermutlich 'ne Nummer zu hoch. Es würde mich natürlich freuen, wenn ich mich irre. Oder (2), man hat zwei Sensoren mit der gleichen Slave-Adresse.
:
Bearbeitet durch User
Torsten C. schrieb: > ja, s.o. >> drucksensor; > ja, s.o., bringt aber bei DGPS nichts mehr. >> kompass; > wozu? Ginge aber auch. Der MPU-9150 ist z.B. fast SW- und Pinkompatibel > zum MPU-6050. Das bringt alles etwas mit den richtigen Sensor-Fusion Algorithmen. Anbei mal ein paar Paper dazu. Hier einfach mal zur Dokumentation. Das ist aber ein Thema für sehr sehr viel später, und evtl. auch eher für einen professionelleren Copter mit mehr Rechenleistung. :) http://en.wikipedia.org/wiki/Sensor_fusion Wenn die Gyro/Acellerometer Fusion mit dem MPU6050 DMP richtig funktioniert ist das schon ein Riesenschritt.
Ich habe heute in mühseliger Kleinarbeit begonnen, die an den Microcontroller angeschlossenen Funktionen zu entschlüssen. Anbei mein aktueller Stand und ein paar Anmerkungen, die ich mir als Gedächnisstütze gemalt habe. Interessant ist, dass die Treiberschaltungen für jeden Motor jeweils an einem PWM-Ausgang und an einem ADC-Eingang hängen. Auf irgendeine Weise gibt es also eine Rückkopplung von den Motoren. Es wäre interessant, die Treiberschaltungen als Schaltbild zu rekonstruieren. Vielleicht kann dabei jemand unterstützen? Andere interessante Fünde: - Den I2C Bus könnte man an den Pull-Up Widerständen abgreifen. (Wenn man an 0402 löten kann) - Pin 9 ist auf ein Pad herausgeführt. Funktion? - Pin 13 ist mit einen nicht bestückten Schaltungsteil verbunden, der möglicherweise noch weitere LEDs auf der linken Seite ansteuern soll. - BK2423 und MPU6050 hängen mit Minimalbeschaltung an der MCU. Eine besser formatierte Tabelle gibt es im Anhang als CSV und TXT.
1 | MINI51ZAN |
2 | QFN33-Pin Manual 3.2.2, p.16 |
3 | CPNx/CPPx = Analog comparator input |
4 | CPO=Analog comparator output |
5 | AINx= ADC input |
6 | CK0=Frequency divider output |
7 | TxEX=Timer capture/reset input |
8 | |
9 | Pin Primary Secondary Function understood External connection |
10 | 1 P1.5 AIN5, CPP0 Partially Connected to motor ctrl circuit 4 (sense?) |
11 | 2 reset YES SWD Port reset |
12 | 3 P3.0 AIN6, CPN1 NC? Not connected? |
13 | 4 P5.4 NC? Not connected? |
14 | 5 P3.1 AIN7, CPP1 Partially Connected to motor ctrl circuit 1 (sense?) |
15 | 6 P3.2 T0EX,STADC,INT0 YES MPU6050, pin 12 (interrupt) |
16 | 7 P3.4 SDA, T0 YES MPU6050, pin 24 (SDA) |
17 | 8 P3.5 SCL, T1 YES MPU6050, pin 23 (SCL) |
18 | 9 P3.6 T1EX,CK0,CPO0 Partially Connected to test pad |
19 | 10 P5.1 XTAL2 NC? Not connected? |
20 | 11 P5.0 XTAL1 NC? Not connected? |
21 | 12 VSS YES VSS |
22 | 13 P5.2 INT1 Partially Connected to unpopulated circuit part. Possibly be to control LEDS on left side |
23 | 14 P2.2 PWM0 NC? Not connected? |
24 | 15 P2.3 PWM1 NC? Not connected? |
25 | 16 P2.4 PWM2 Partially Connected to Motor 1 ctrl |
26 | 17 P2.5 PWM3 Partially Connected to Motor 2 ctrl |
27 | 18 P2.6 PWM4, CPO1 Partially Connected to Motor 3 ctrl |
28 | 19 P4.6 ICE_CLK (SWD) YES SWD Port CLK |
29 | 20 P4.7 ICE_DAT (SWD) YES SWD Port Dat |
30 | 21 P0.7 SPICLK YES BK2423 SPI CLK |
31 | 22 P0.6 MISO YES BK2423 SPI MISO |
32 | 23 P0.5 MOSI YES BK2423 SPI MOSI |
33 | 24 P0.4 PWM5, SPISS Partially Connected to Motor 4 ctrl |
34 | 25 P0.1 RTSn, RX, SPISS YES BK2434 SPI CSN |
35 | 26 P0.0 CTSn, TX YES Controls LEDS via 10 Ohm resistors |
36 | 27 P5.3 AIN0 NC? Not connected? |
37 | 28 VDD YES |
38 | 29 P1.0 AIN1 NO Connected to motor ctrl circuit 2 (sense?) |
39 | 30 P1.2 RX, AIN2 YES UART PORT RX |
40 | 31 P1.3 TX, AIN3 YES UART PORT TX |
41 | 32 P1.4 CPN0, AIN4 Partially Connected to motor ctrl circuit 3 (sense?) |
42 | 33 (Pad) VSS |
:
Bearbeitet durch User
Hallo kennt jemand einen deutschen oder eu shop der sowas ähnliches bietet ? http://www.fpvhobby.com/2-transmitter
Tim schrieb: > Pin 9 ist auf ein Pad herausgeführt. Funktion? Sieht fast so aus, als hätte der Pin bei dem Board nicht wirklich eine Funktion. Laut Datenblatt kann der Pin folgende Verwendung haben:
1 | Input/Output: Digital GPIO pin |
2 | Output: Analog comperator output pin |
3 | Output: Frequency divider output pin |
4 | Input: Timer1 external capture input/reset trigger input pin |
Also als Testpad würde das Ganze ja nur Sinn machen, wenns ein digital output pin oder analog comperator output pin wäre. In dem Fall wäre es interssant ob da digitale oder analoge Daten überhaupt anliegen oder sowieso nicht. Für eine eventuell eigene entwickelte Firmware aber dann wohl eher von weniger Bedeutung. Dann kann er ja nach belieben benutzt werden. Ich schätze mal nicht, dass man das PAD irgendwie für clock divider output oder external capture/reset input verwendet.
:
Bearbeitet durch User
Wie lange hat der Versand bei Euch gedauert? Ich warte schon seit fast einem Monat..
3 wochen ca. hat es gedauert . ich find kein kleines kamera modul
Noobi schrieb: > 3 wochen ca. hat es gedauert . > ich find kein kleines kamera modul diese hier müsste gehen: http://www.ebay.de/itm/200934338158 (ohne Gehäuse und gespeist vom Akku des Copter's)
:
Bearbeitet durch User
@ Marius S.: "von Elektronik habe ich nichts geschrieben." Das bezog sich auf meinen Beitrag von 10.11.2013 22:32. Eine Zeitlang hatte ich an einem Ladecontroller im Accu gedacht, die Versuche gaben das aber nicht her. Ich sehe da eher eine Eigenschaft unter bestimmter Bedingung hochohmig zu werden und nach unterschreiten eines Haltestroms wieder niederohmig. Die Kombination Flieger - mitgelieferter Ladeadapter funktioniert ja so. Wer aber einen Fremdaccu einbaut braucht wohl auch ein richtiges Ladegerät. Einige hier im Forum bauen den Ladeadapter in ein richtiges Ladegerät um - sind vieleicht schon fertig. Ich werde erstmal nichts ändern.
Ich hatte auch vermutet, dass Pin 9/das Pad den ISP-Mode aktiviert. Leider passiert nichts wenn man das Pad mit Masse verbindet. Übrigens wird der Bootloader wohl normalerweise dadurch aktiviert, dass kontinuierlich 0x00 an RX gesendet wird.
:
Bearbeitet durch User
Turbonator schrieb: > Hallo kennt jemand einen deutschen oder .. Währe das was? http://www.ju-tec.de/art/099/099526/MRF24J40MA-I-RM-ZigBee-Modul-2-405-2-48GHz-95dBm-0-dBm-12-Module/ z.Z. nicht lieferbar, vor 14 Tagen hab ich noch zwei gekauft, aber noch nichts mit gemacht. Ist von 'Microchip' http://www.microchip.com/pagehandler/en-us/technology/personalareanetworks/home.html?tab=t1
Aaron Christophel schrieb: > diese hier müsste gehen Oder z.B. Y3000. Wir wiederholen uns. Die Wiki-Seite muss her. Tim schrieb: > Das bringt alles etwas mit den richtigen Sensor-Fusion Algorithmen. Du hast ja Recht. Bei dem Drucksensor hatte ich vergessen, dass GPS so träge ist. Und einen Kompass habe ich bisher nicht vermisst, da die Gier-Regelung suuuper Stabil ist. Aber der würde ja fast nix kosten und fast nix wiegen, also: Warum nicht? Manuel Steiner schrieb: > Für eine eventuell eigene entwickelte Firmware aber dann > wohl eher von weniger Bedeutung. Dann kann er ja nach belieben benutzt > werden. Genau. Z.B. Kamera auslösen oder so. Ist doch cool, wenn der Pin frei ist.
Marius S. schrieb: > Würde mich wundern, wenn da noch > eine Elektronik drin versteckt ist... Bei einem Akku ist mir heute das Kabel abgerissen und im Akku ist wirklich noch eine kleine Platine drin. Da Schutzschaltungen nur für Leute mit Angst vor explodierenden Akkus sind habe ich die natürlich gleich entfernt, habe jetzt auch einen Max1555 im Ladegerät...
Marius S. schrieb: > im Akku ist wirklich noch eine kleine Platine drin. Damit ist das Original "Ladegerät" also wieder "zur Benutzung freigegeben"? Klar: Mit dem Risiko, dass jemand Nachbau-Akkus ohne Schutzschaltung erwischt.
Torsten C. schrieb: > Oder z.B. Y3000. Wir wiederholen uns. Die Wiki-Seite muss her. Ja, der Thread wird langsam unübersichtlich und die Fragen wiederholen sich. Hast Du Lust eine Seite anzulegen? Was nehmen wir? http://www.mikrocontroller.net/articles/Hack-O-Copter http://www.mikrocontroller.net/articles/JXD-385 http://www.mikrocontroller.net/articles/Quadcopter-Hacking ...?
:
Bearbeitet durch User
Tim schrieb: > http://www.mikrocontroller.net/articles/Hack-O-Copter Würde am besten zum Namen in Github passen.
http://www.mik...cles/Hack-O-Copter (Für den harten Kern) http://www.mik...cles/Hack-O-Copter-BayAndFun http://www.mik...cles/Hack-O-Copter-xxxxxxxxx http://www.mik...cles/Hack-O-Copter-YYYYYYY Eine Struktur sieser Art schaffen, wär das was ?????
Wo schrieb: > wär das was? Das Prinzip ist gut, wenn's irgendwann mal zu unübersichtlich wird. Tim schrieb: > Hast Du Lust eine Seite anzulegen? Ja, ich fange mit "Für den harten Kern" an. ;-)
Kann es sein das unser Blinky Projekt falsch ist? Da ist der Header und die Startup vom M051 drin. Aber bei Keil wird gesagt das für den M54ZAn ein anderer Header und zwar Mini51.h und auch ein Startup Mini51 genutzt wird. Ist das Blinky somit falsch?
No y. schrieb: > Kann es sein das unser Blinky Projekt falsch ist? > Da ist der Header und die Startup vom M051 drin. Aber bei Keil wird > gesagt das für den M54ZAn ein anderer Header und zwar Mini51.h und auch > ein Startup Mini51 genutzt wird. Ist das Blinky somit falsch? Es funktioniert aber....
Robert Knipp schrieb: > Es funktioniert aber.... Ich glaube (hoffe), noy wollte fragen, ober er eine neue korrigierte Version hochladen darf, oder ob das so gewollt ist.
Hm, okay... Ich versuche mich halt gerade mit meinem J-Link. Das muss doch irgendwie gehen... Ich habe nur,leider absolut keine Ahnung was ich da noch wo einstellen muss.. Gibt da ja mehrere Flash-Scripte zur Auswahl usw... Jedesmal kommt failed mit der Meldung: Cortex-M0 ! Keine Ahnung was das sein soll. Wenn ich kein Script angebe löscht er ohne Probleme, aber es ist noch alles drauf... Also ich meine er sagt er hätte es gemacht ohne das was passiert... Vielleicht schrieb ich morgen mal ne Email an Segger... Vielleicht sind die ja nett. @ Torsten: Ne ich hab fast keine Ahnung von ARM. Bzw. bisher nur bissel mit Luminary Micro Boards oder den STM aber da ist mit Coocox ja schon alles drin... Wollte nur Nachfragen ob da der M051 korrekt ist oder ob es vielleicht etwas bringt das alles auf Mini51 umzustricken da Keil dies vorschlägt.
:
Bearbeitet durch User
Noy hat recht, das Projekt nutzt die M051 includes. Da die Register an der gleichen Addresse liegen, funktioniert es aber trotzdem. Nuvoton hat gerade eine neue Version der Mini51 Beispiele heraus gebracht: http://www.nuvoton.com/NuvotonMOSS/Community/ProductInfo.aspx?tp_GUID=4b47b09d-b116-4ccd-aa85-31e261a87d30 Ich werde bei Gelegenheit mal ein CMSIS Blinky implementieren.
Will noch jemand von Euch zur Github-"Organization" hinzugefügt werden? Wenn ja, bitte sendet mir den Namen auf Github. Ihr könnte die Repositories dann direkt auslesen und updaten.
Hat hier jemand Ahnung von J-Link? Und kann mir mal erklären was ich wo auswählen muss? Beim einrichten in Keil? In Coocox läuft es direkt... Bzw. in Keil bisher auch mit den STM Boards da muss ich halt das entsprechende Script auswählen under dem Flash Fenster... Aber für den Mini54ZAN gibt es kein spezielles Script...
noy, hast du den mini51 support in Keil installiert? (legacy device support?). Du kannst den Adapter in "Options for Target->Debug" rechts oben auswählen.
Ja da kann ich den auch auswählen und auch alles einstellen. Wenn ich dann auf Settings drücke beim J-Link kann bzw. musste ich bisher immer ein "Programming Algorithmen" Script auswählen. Also J-Link auswählen dann settings drücken und auf den Reiter Flash wechseln. An dem Rest muss ich ncihts einstellen oder? Das ist ja alles schon im Projekt festgelegt. Ich kann auch direkt im J-Link CMD das Device (M054ZN oder Mini54LAN ? Oder was ganz anderes sind viele da...) anwählen und dann erase eingeben. Aber da failed der Erase immer. Weil nix in den Ram geladen werden kann. Bzw. could not read target memory. Please check your Flash Settings.. Also beim J-Link gibt es den Befehl Unlock.. Der funktioniert aber nur bei bestimmten Controllern. LM3SXXXX und STM32 und EFM... Denke mal das es dann wirklich Nuvoto eigenes Zeug ist und Segger es deswegen auch nicht kann...
:
Bearbeitet durch User
Hier ist ein Blinky basierend auf CMSIS und der aktuellen Mini51 Lib: https://github.com/hackocopter/Examples/tree/master/Blinky-CMSIS Bisher noch ungetestet. Der Code sollte auch etwas über die serielle Schnittstelle ausgeben.
:
Bearbeitet durch User
Hallo kennt jemand einen deutschen oder eu shop der sowas ähnliches bietet ? http://www.fpvhobby.com/2-transmitter Aaron Christophel schrieb: > Noobi schrieb: >> 3 wochen ca. hat es gedauert . >> ich find kein kleines kamera modul > > diese hier müsste gehen: > http://www.ebay.de/itm/200934338158 > (ohne Gehäuse und gespeist vom Akku des Copter's) sry ich brauch ein kamera modul pal/ntsc oder mit funk was zur spannung vom akku passt ich möchte das bild direkt sehen
Turbonator schrieb: > oder mit funk 3 Worte, 2 Fragen: 1. Welcher Funk? Über den eingebauten nrf24l01+? Oder meinst Du, Du findest Sender, die leicht genug sind? 2. Was meinst Du mit "oder"? Soll alternativ ein Kabel am Hack-O-Copter hängen?
Ich habe auch einen Quadrocopter am 16.10. über eBay bestellt, nämlich extra den mit dem angegebenen Artikelstandort "Frankfurt" - damits auch schnell geht. Ich bekam dann einen Tag nach dem Kauf die Mail, dass der Versand ca. 12 Werktage (das sind knapp 3 Wochen!) dauern würde. Aus Frankfurt??? Mittlerweile ist die Zeit längst abgelaufen und der Copter ist immer noch nicht da. Ich habe dem Verkäufer daher eine Mail mit folgendem Wortlaut geschickt: "Hallo, mittlerweile sind die 12 Werktage längst um und bei mir ist nichts eingetroffen. Ich kann auch überhaupt nicht verstehen, warum Sie in der Artikelbeschreibung als Artikelstandort "Frankfurt" angeben, wenn doch offensichtlich ist, dass bei so einer langen Lieferzeit (12 Werktage sind ja real 3 Wochen!) die Quadrocopter gar nicht aus Frankfurt, sondern wohl direkt aus China kommen. Aus Frankfurt könnte meine Oma den Copter zu Fuß innerhalb der von Ihnen angegebenen Zeit bringen.... da stimmt also was nicht. Ich bitte Sie, mir verbindlich einen Liefertermin zu nennen. Mit freundlichen Grüßen, ..."
Frank M. schrieb: > Ich habe auch einen Quadrocopter am 16.10. über eBay bestellt, nämlich > extra den mit dem angegebenen Artikelstandort "Frankfurt" - damits auch > schnell geht. Hi Frank, das tut mir leid, das der immer noch nicht da ist. Ich hab auch aus "Frankfurt" bestellt und es hat knapp 2 Wochen gedauert. Du hast halt auf jeden Fall den Vorteil das du dich nicht mit dem Zoll rumärgern brauchst ;-)! Der wird dir wahrscheinlich anbieten das Geld zurückzugeben oder einen neuen Rausschicken. Vielleicht hast dann zwei. Grüße
Hi Kille, Kille H. schrieb: > Der wird dir wahrscheinlich anbieten das Geld zurückzugeben oder einen > neuen Rausschicken. Vielleicht hast dann zwei. Ja, so etwas stand schon in der ersten Kontaktmail vorsorglich drin: "Falls die Ware nach der max. Lieferzeit(12 Werktage) nicht bei Ihnen eintrifft, melden Sie sich bei uns. Bewerten Sie uns NICHT SOFORT negativ oder neutral.Es gibt verschiedene Gruende dafuer, meiste koennen wir leider nicht beeinflussen. Aber die Kundenzufriedenheit liegt bei uns in erster Linie. deswegen werden wir Ihnen den Gesamtbetrag zurueckerstatten. Sie koennen trotzdem den angekommenden Artikel als unsere Entschaedigung behalten." Ich habe dann mal in die Bewertungen geschaut: Es kommt ziemlich oft vor, dass die Leute anmerken, dass nichts angekommen ist. Aber in jedem Fall gab es wohl immer das Geld zurück.... immerhin etwas :-) Ich sehe es trotzdem als Unverschämtheit an, dass die als Artikelstandort grundsätzlich (egal, welcher Artikel) "Frankfurt" reinschreiben, das Zeug aber offenbar gar nicht in Frankfurt lagert. Naja.... warten wirs ab :-) Gruß, Frank
So einen Mist hatten wir wahrscheinich fast alle schon mal hinter uns. Es bringt aber m.E. nix, hier E-Mail-Kopien zu posten. Da geht die eigentliche Information: "Aus Franfurt geht's auch nicht schneller" schnell im "Grundrauschen" unter. Kille H. schrieb: > Du hast halt auf jeden Fall den Vorteil das du dich nicht mit dem Zoll > rumärgern brauchst Da kann man sich nicht grundsätzlich sicher sein. Sogar Zoll habe ich mal bezahlt, der Paypal Käuferschutz hat mir das Geld aber zurück überwiesen: http://notizblog.wordpress.com/2012/12/10/anstrengender-ebay-kauf/ Aber der Hack-O-Copter ist ja frei von Einfuhrumsatzsteuer, also kein Problem.
:
Bearbeitet durch User
Die schicken durchaus aus Frankfurt. Da sitzt ein Importeur, der einen Container aus China bekommt, wo mehr als nur dein einer Copter drin sein wird. Sonst lohnt sich der Versand auch garnicht. Und bis der Container nicht eingetroffen ist, kann der nette Herr oder die Dame in Frankfurt auch nix abschicken. Entsprechend muss man eben etwas warten...
Torsten C. schrieb: > "Aus Franfurt geht's auch nicht schneller" Also ich finde schon. Wahren aus China dauern bei mir meistens ca. 3-4 Wochen. Hatte aber auch schon Sachen nach EINER Woche da. Aber vielleicht hatte ich mit dem aus "Frankfurt" einfach nur Glück die Waren kommen aus China und bei mir ging es nur sehr schnell. Die Stichprobe reicht einfach noch nicht für eine aussagekräftige Statistik...
Torsten C. schrieb: > Turbonator schrieb: >> oder mit funk > > 3 Worte, 2 Fragen: > > 1. Welcher Funk? Über den eingebauten nrf24l01+? Oder meinst Du, Du > findest Sender, die leicht genug sind? > > 2. Was meinst Du mit "oder"? Soll alternativ ein Kabel am Hack-O-Copter > hängen? Nicht der eingebaute funk. http://www.fpvhobby.com/2-transmitter Einen sender hab ich gefunden oberer link jetzt brauch ich dafür eine Kamera wie diese http://www.electronics123.com/s.nl/it.A/id.2905/.f?sc=8&category=241 nur günstiger . Das ODER : oder was anderes fertig mit funk leicht und passend zur spanung des quadrokopters
Ich finde ja die Bezeichnung am Bild ganz putzig... http://www.fpvhobby.com/transmitter/21-2-55-volt-500mw-24ghz-video-transmitter.html http://www.globe-flight.de/58-GHz-FPV-SETs Aber nimm 5.8GHz nicht auch 2.4GHz wie bei der Steuerung...
Hast du schonmal gerrechnet was dein Transmitter bei optimalem Wirkungsgrad an Stom zieht bei 3,7V? ;) Wirst wohl nciht lange fliegen können... Ok wenn es ein 10mW wird gehts..
:
Bearbeitet durch User
Irgendwann kommt mein Copter bestimmt auch. Falls noch jemand das Schaltbild aufnehmen möchte, hier ist schon einmal der Mini51 als Eagle-Library. Gyro und TRx kommen als nächstes.
No y. schrieb: > es ein 10mW wird gehts. War da auch ein Sender mit 10dBm dabei? Ich habe nur gefunden: * 0,6 Gramm 2.4GHz 16dBm 60mA * 2,2 Gramm 5.8GHz 23dBm 200mA * 2,0 Gramm 680MHz 16dBm ???mA 2 Gramm gehen ja noch. Aber die leichteste Kamera hat 22 Gramm und braucht 5V. Richtig? Oder habe ich was übersehen? Testi schrieb: > nicht auch 2.4GHz wie bei der Steuerung
1 | Ch1: 2414 mHz |
2 | Ch2: 2432 mHz |
3 | Ch3: 2450 mHz |
4 | Ch4: 2468 mHz |
Die Kanäle 76..125 des NRF24L01 wären doch noch frei, das müßte doch reichen. @Georg: Cool, danke. :-)
Ich kenn es nur von den großen FPV. Wenn man 2,4GHz fliegt nimmt man ein 5.8GHz System! Wenn man mit 40MHz fliegt geht auch ein 2,4GHz System...
Ist mir zuviel das jetzt alles zu lesen hier. :-) Heute ist das Ding von Ebay angekommen das ich vorletzte Woche gekauft und bezahlt hatte. Ebay-Artikel Nr. 200978469863 Von wegen auch "Artikel Standort Franktfurt", die Teile werden aus Hong Kong geliefert - was auch die lange Lieferzeit erklärt die ja ausdrücklich angegeben ist. Ein Zoll Aufkleber war auch drauf. Da kann ich nur sagen, Finger weg von dem Ding. - Anleitung nur Chinesisch - zwischen den Pluspolen des Batterie-Fachs der Fernbedienung und den Zellen ist ein Luftspalt den ich erstmal mit etwas Alu-Folie überbrücken musste - fliegt katastrophal beschissen, haut sofort irgendwohin ab, stabil ist der nur auf dem Boden oder wenn er sich an der Decke festsaugt - Akku sehr schnell leer - die Schutzringe sind ein Witz Also da habe ich mit meinem Fun2Get "Falcon-X Metal RTF" Gyro-Heli der bei Amazon auch nur 20€ kostet deutlich mehr Spass, den kann man wenigstens in die Luft bekommen und dort halbwegs stabil halten.
Rudolph schrieb: > Ebay-Artikel Nr. 200978469863 Das ist auch nicht der richtige Quadcopter. Aber vielleicht kannst Du trotzdem mal ein Bild von der Platine machen?
Rudolph schrieb: > m Irgendwas muss kaputt sein ich trimm meinen nur kurz und der bleibt an einer stelle außer wenn er vorher in eine richtung beschleunigt hat das aber auch nur minimal kurz gegensteuern fertig
Georg G. schrieb: > Irgendwann kommt mein Copter bestimmt auch. Falls noch jemand das > Schaltbild aufnehmen möchte, hier ist schon einmal der Mini51 als > Eagle-Library. Gyro und TRx kommen als nächstes. Sehr schön! Du könntest noch die Pinnumern ergänzen?
> 2 Gramm gehen ja noch. Aber die leichteste Kamera hat 22 Gramm und > braucht 5V. Richtig? Oder habe ich was übersehen? 10 mw , 5,8ghz , 70ma ,1,2g sind dabei aber besser wäre 20mw , 2,4ghz , 42ma , 0,3g Keiner eine idee mit der kamera ?
Rudolph schrieb: > Ist mir zuviel das jetzt alles zu lesen hier. Ich habe mit dem Wiki-Artikel schon angefangen. Tim schrieb: > Das ist auch nicht der richtige Quadcopter. Kommt auch ins Wiki, als Warnung. @Rudolph: Kannst Du dafür ein Foto machen? Die Fotos aus dem ebay-Artikel sind zu heikel wegen des Urheberrechts. Erster Schuss einer Gliederung: ---------- Der Begriff Hack-O-Copter beschreibt einen Nachbau des Quadrocopters „Hubsan X4“, der er sich einfach „hacken“ lässt; die Original-Firmware kann also überschrieben und durch eigene ersetzt werden. Er wird für ca. 21€ verkauft, siehe Beitrag „Hackbarer(?) 21 EUR Quadcopter“. Die Original-Firmware kann nicht ausgelesen werden, es muss also eine komplett neue Firmware erstellt werden. 1 Beschreibung des Quadrocopters - Abmessungen - Gewicht - Lieferumfang - Reichweite - Flugdauer und Ladezeit - Funktionen (3 Empfindlichkeiten, umdrehen, Rekalibrierung?) - Link zur Bedienungsanleitung 1.1 Bedienung … 1.2 Komponenten Der Quadrocopter wird von vier kernlosen Gleichstrommotoren („Coreless DC“) angetrieben. Im Inneren des Gehäuses ist eine Platine. Ihre vergleichsweise modernen Hardware-Komponenten (Mikrocontroller, Sensoren, 120mΩ MOSFETs und ein Funkmodul) sind in den folgenden Kapiteln beschrieben. 1.2.1 Mikrocontroller … 1.2.2 Sensoren zur Flugstabilisierung … 1.2.3 ESC … Die verwendeten N-Kanal MOSFETs „G2310“ haben einen „Drain-Source On-Resistance“ von etwa 120mΩ. - http://www.mikrocontroller.net/attachment/193854/G2310.pdf 1.2.4 Funk- Transceiver Für die 2,4GHz Funkstrecke zur Fernsteuerung ist mit einem „Beken BK3423“ integriert. Die Vermutung, dass dieser voll kompatibel zum NRF24L01 ist, liegt nahe, ist aber noch nicht bestätigt. 1.3 Zubehör 1.3.1 Lade-Adapter … 1.3.2 Funkfernbedienung … 1.3.3 Propeller … 1.4 chnittstellen 1.4.1 SWD-Port … 1.5 Serielle Schnittstelle … 1.6 I²C-Schnittstelle … 2 Tipps und Tricks 2.1 Bezugsquellen und Kauf 2.1.1 Direktkauf aus China … 2.1.2 Lieferanten aus Europa … 2.2 Ersatzakkus … 2.3 Reduzierung der Unfallfolgen … 3 Ideen für neue Funktionen 3.1 Bessere Flugstabilisierung mit bestehender Sensorik … 3.2 Neue Funktionen mit GPS-Sensor … 3.3 Neue Funktionen mit Luftdruck-Sensor … 3.4 Neue Funktionen mit Kamera … 3.5 Neue Funktionen mit Ultraschallsensor … 3.6 Neue Funktionen mit Infrarot-Entfernungssensor … 3.7 Neue Funktionen mit Bluetooth … 3.8 Erweiterung der Original-Fernbedienung … 3.8.1 Funkmodul mit PA + LNA … 3.8.2 Erweiterung um ein Display … 3.9 Neue Funktionen mit alternativer Fernbedienung … 4 Programmierung neuer Firmware 4.1 Beschreibung der Toolkette … 4.1.1 Notwendige Hardware und Software … 4.1.2 Installation der Toolkette … 4.1.3 ISP und ICD … 4.2 Beschreibung der Firmware-Varianten 4.2.1 „Blinky“ … 5 Weiterführende Links und Quellen … ------------------
Hier, nicht lachen, meine kleine Tochter hat sich die Farbe ausgesucht. :-) Dann werde ich das Teil mal zerlegen.
Oder auch nicht, das Ding wird auf der Unterseit von 15 Schrauben zusammen gehalten. Und die je zwei in den Auslegern sind tief versenkt. Ich finde hier gerade keinen passenden Schraubendreher, den zerlege ich morgen auf der Arbeit mal richtig.
Turbonator schrieb: > Keiner eine idee mit der kamera ? Wiegt weniger als ein Gramm (siehe Bild). Ich arbeite dran. Das ist im Prinzip eine Raspicam (oder heißt die Raspcam?). Ich weiss nicht, wieviel die mit Adapter-PCB wiegt. Außerdem müsste noch etwas dazu, was Video-Siglale für den Sender daraus erzeugt. Oder reichen die 2MBPS vom NRF24L01+? Ach nee, den wolltest Du ja nicht.
Wollen ja können nein , ich bin ein bastler . Wie sieht das denn aus ? Das modul braucht bestimmt einen ic den man programieren muss , wenn du das hinbekommst ist die Auflösungen bestimmt sehr gut mit der lumia cam< ist das doch wenn ich mich nicht täusche , hast du mal geschrieben. Wenn das geht kann der ic osd einblenden wäre auch nicht schlecht
Hier sind zwei interessante Thread zum Nachrüsten einer Kamera für den/die(?) Crazyflie: http://forum.bitcraze.se/viewtopic.php?f=6&t=427 http://forum.bitcraze.se/viewtopic.php?f=6&t=491
:
Bearbeitet durch User
ich hab eine andere frage haben die motoren vom herstellungsprosses her eine feste laufrichtung ?
Noobi schrieb: > haben die motoren vom herstellungsprosses her > eine feste laufrichtung Nein. Das ist nur Verarsche, dass Du die getrennt bestellen kannst. ;-) Spass beiseite: Weiss jemand, woran das liegt? Ich nehme an, dass der Winkel zwischen Kommutator und Spule unterschiedlich ist und die deshalb nicht für ein "umpolen" geeignet sind. Rudolph schrieb: > Hier, nicht lachen, meine kleine Tochter hat sich die Farbe ausgesucht. > :-) Genau wie meine Tochter, die hätte auch Rosa verlangt. Danke.
:
Bearbeitet durch User
Ich hab mal zwei Videos des noch nicht Hack-O-Kopter gemacht. Bei einem sieht man auch meine "kreative" Akku Montage. So macht der auch Spaß, bissl schwieriger zu fliegen. http://m.youtube.com/watch?v=8-4TUFZ634k http://m.youtube.com/watch?v=zYgnTCoxasY Im Vergleich zu mein anderen liegt der viel stabiler. Bei so einer schnellen Drehung wurde der nie stabil bleiben. PS. Gar nicht so einfach das alles mit dem Telefon zu machen.
Torsten C. schrieb: > Erster Schuss einer Gliederung: Gefällt mir. Der Artikel kann ja sowieso mit der Zeit wachsen, aber das gibt erst einmal eine gute Vorlage zum "ausfüllen".
Ich könnte mir bei den Motoren hcöhstens vorstellen, das die schleifer entsprechend angeordnet sind und damit die drehrichtung vorgegeben ist. anderstrum geht auch, aber mit mehr verschleiß
Turbonator schrieb: > Das modul braucht bestimmt einen ic den man programieren muss Ja, den "Mini54ZAN" muss man neu programmieren, wenn die Original-Firmware gelöscht wurde. Sonst fliegt der nie wieder. Chris L. schrieb: > das die schleifer entsprechend angeordnet sind Ja, "Schleifer" == "Kommutator" ^^
Torsten C. schrieb: > Ja, den "Mini54ZAN" muss man neu programmieren Aber um eine RaspCam anzuschließen, braucht man einige Pins. Entweder man setzt einen Programmierbaren Logik-IC ein (der 5M40Z kostet bei Mouser z.B. nur 86ct, reicht aber vermutlich nicht), oder es sind noch genug Pins frei. Tim schrieb: > Der Controller scheint auch noch einige freie Pins zu haben. Wieviele sind's denn, außer "PIN 9"? Noobi schrieb: > hilft das weiter? Nicht wirklich.
Torsten C. schrieb: >> Der Controller scheint auch noch einige freie Pins zu haben. > > Wieviele sind's denn, außer "PIN 9"? Alles was in der Liste als "NC" aufgeführt ist.
Sry hatte die gleiche idee wie noobi mit dem bild und erst zu spät gesehen
Noobi schrieb: > ich hab es mal kopiert hilft das weiter Turbonator schrieb: > Ich meine einen extra ic Das Bild ist doch schon im Thread, warum nochmal hoch laden? Außerdem viel zu groß... Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter" Wie bekommt man die Motoren unbeschädigt auf und wieder zu?
Hallo Leute, ich lese hier schon seid einiger Zeit mit und bin sehr angetan von dem guten Stück und euren Ideen. Aktuell kann ich mich aus Zeitmangel noch nicht mit meinem Exemplar befassen, wollte aber kurz eine Idee / Projekt mit euch teilen. 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. Es ist natürlich die Frage, was genau das Ziel ist. Für die unter uns, die Lust haben so richtig alle Basics der Quadcopter Steuerung / Implementierung zu durchdringen und alles selber zu machen, für die ist diese Firmware sicher nicht das richtige. Ich persönlich möchte jedoch nicht umbedingt das Rad neu erfinden und dabei jedes einzelne Problem aufs neue lösen. Ich persönlich habe viel mehr Lust, einzelne Aspekte zu erweitern, neue Funktionen umzusetzen und verschiedenes auszuprobieren (gibt ja oben schon eine Liste spannender Ideen). Auch wenn mich einzelne Aspekte der Steuerung (Sensor Fusion, Regler) sehr reizen und ich diese neu implementieren werde, scheint mir das Framework der Jungs aus dem Norden eine super Grundlage für meine weiteren Schritte. Vor allem die Debug Möglichkeiten (über den 2,4 Ghz Downlink) sind sicher eine sehr große Hilfe. Daher wollte ich sie hier einmal kurz erwähnen. Es gibt allerdings auch hierbei ein paar Herausforderungen. Vor allem wurde die Firmware für einen Cortex-M3 mit DEUTLICH mehr Mhz, Ram, etc. geschrieben. Daher ist eine 1 zu 1 Übernahme sicher ausgeschlossen. Aber der Rahmen wird sich vermutlich übernehmen lassen... Viele Grüße [1] http://wiki.bitcraze.se/projects:crazyflie:index
Kille H. schrieb: > Ich hab mal zwei Videos des noch nicht Hack-O-Kopter gemacht. > ... > PS. Gar nicht so einfach das alles mit dem Telefon zu machen. http://www.youtube.com/watch?v=Bt9zSfinwFA ;) Grüße, Chris
Hier mal ein paar Bilder vom Innenleben meines rosa Quadro-Taumlers. Das ist ja noch weniger komplex, Clon des Clons?
Tim schrieb: > Sehr schön! Du könntest noch die Pinnumern ergänzen? Die sind drin, nur default nicht sichtbar. Wird in der nächsten Version der Lib geändert. Als Nachtrag: Ich arbeite mit einem alten Adler (4er Version), zum einen, weil ich dafür eine Lizenz habe und ein Update auf eine neue Version für mich nicht lohnt (die Freeware kann nur eine Seite Schaltplan) und zum anderen, weil man problemlos alte Schaltbilder in neue konvertieren kann und es rückwärts nur mit erheblichem Aufwand möglich ist.
Gute Fotos. :-) Rudolph schrieb: > Clon des Clons? Auf den ersten Blick scheint ja alles dabei zu sein, damit er mit neuer Hack-O-Copter-Firmware nicht mehr taumeln muss. Aber mit EUR 23,19 ist der ja teurer als der JXD-385. Schade. Rudolph, hast Du auch vor, Dir einen Bu-Link zu kaufen? Oder war der mehr zum out-of-the-box-fliegen für Deine Tochter gedacht?
Der war eigentlich mehr zum Fliegen gedacht, ich hatte die Hoffnung, dass der sich leichter fliegen lässt als mein Falcon-X. ARM ist so mangels Bedarf an Rechenpower bzw. noch lange nicht ausgenutzter Rechenpower der AVRs bisher nur interessant für mich aber noch lange nicht ernsthaft im Fokus. Kosten/Nutzen halt, wenn die Kosten für den Controller quasi egal sind weil man nur Prototyping/Kleinstserie macht, hält einen der Umstiegs-Aufwand bei der gewohnten µC-Familie und Toolkette.
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
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.
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
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..
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.
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
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
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.
Philipp E. schrieb: > 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? Das Log fängt direkt mit dem Einschalten der FB an. Im ersten Teil sieht man daher schön, wie die Register des BK2423 initialisiert werden. Die Aufzeichnung endet noch während der Binding-Phase.
Tim schrieb: > Wir sollten uns tatsächlich mal Gedanken > machen, wie man das ganze strukturiert angeht. +1 Finde die Aufteilung sinnvoll. Wobei vermutlich jeder etwas unterschiedliche Prioritäten hat. Aber das macht ja nix, jeder kann sich das Schnappen worauf er Lust hat. Ich bin sehr an Punkt 2) bis 4) interessiert, wenn denn mein Copter endlich mal ankäme. @Torsten: Gibt es eigentlich schon neues von den China Händlern bzgl. Mengenrabatt? Tim schrieb: > 2) Endlich den Copter entsperren (Das BU-link müsste langsam mal > angekommen) Bin ja hin und her gerissen. Habe überlegt mir auch einen BU-Link zu bestellen, auf der anderen Seite wäre es für die Community sicher genial, wenn das auch ohne geht. Sobald er da ist, hängst du aber direkt den LA dran und schickst uns nen Trace vom Unlocken ;-) Tim schrieb: > Wenn man einige Optionen nicht > mitcompiliert passt die Firmware bereits jetzt in 16kb. Kannst du noch einmal posten wo genau es den Arm Port gibt? Welche Optionen hast du ausgeschaltet? Tim schrieb: > Die Aufzeichnung endet noch während der Binding-Phase. Könntest du noch mal einen Trace aufzeichnen, der die gesamte Binding Phase abdeckt? Ach ja, ich habe noch eine Frage zur IDE. Ihr verwendet alle Keil, oder? Damit kann man dann den SWD Port vom Discovery Board direkt mit dem Copter verbinden und Debuggen und Flashen (wenn er denn nicht mehr gelockt wäre). Ist das soweit korrekt? Welche Einstellungen haben sich dazu als korrekt rausgestellt? Und welche Keil Version? Ist das, was in https://github.com/hackocopter/Examples/tree/master/Blinky-CMSIS liegt als Grundlage (also vom Keil-Projekt her) geeignet?
Philipp E. schrieb: > Tim schrieb: >> Wenn man einige Optionen nicht >> mitcompiliert passt die Firmware bereits jetzt in 16kb. > > Kannst du noch einmal posten wo genau es den Arm Port gibt? Welche > Optionen hast du ausgeschaltet? https://github.com/trollcop/bradwii Habe in den Defines alles deaktiviert, was sowieso nicht unterstützt wird und anschließend manuell das Konfigurationsinterface ausgebaut (Checkboxes, EEPROM code usw.). Philipp E. schrieb: > Tim schrieb: >> Die Aufzeichnung endet noch während der Binding-Phase. > > Könntest du noch mal einen Trace aufzeichnen, der die gesamte Binding > Phase abdeckt? Habe die Verbindungen leider schon wieder entfernt. Ich gehe aber davon aus, dass es da keine Überraschung gibt. Es wird einfach vom Binding in den normalen Modus umgeschaltet. Philipp E. schrieb: > Tim schrieb: >> 2) Endlich den Copter entsperren (Das BU-link müsste langsam mal >> angekommen) > > Bin ja hin und her gerissen. Habe überlegt mir auch einen BU-Link zu > bestellen, auf der anderen Seite wäre es für die Community sicher > genial, wenn das auch ohne geht. Sobald er da ist, hängst du aber direkt > den LA dran und schickst uns nen Trace vom Unlocken ;-) Das wird das Allererste sein :) Philipp E. schrieb: > gelockt wäre). Ist das soweit korrekt? Welche Einstellungen haben sich > dazu als korrekt rausgestellt? Und welche Keil Version? µVision5 mit legacy device support. > Ist das, was in > https://github.com/hackocopter/Examples/tree/master/Blinky-CMSIS > liegt als Grundlage (also vom Keil-Projekt her) geeignet? Ich denke schon. Das sind die Einstellungen vom Beispielprojekt für den MINI54.
Philipp E. schrieb: > Gibt es eigentlich schon neues von den China Händlern bzgl. > Mengenrabatt? Das Problem ist, dass bei einer Einfuhr von mehr als einem Stück in jedem Fall Einfuhrumsatzsteuer fällig wird. Dann muss der Händler mindestens 20% Rabatt einräumen, damit es pari ausgeht. Das Porto innerhalb Deutschlands ist auch nicht zu vernachlässigen (Warensendung € 1.90). Und Torsten muss die Dinger auch einzeln neu verpacken (Karton € 0.50). Nun sind wir schon bei weiteren gut 10% die der Händler nachlassen muss. Und Torsten hat noch immer keine Entschädigung für seine Arbeit. Wenn dann auch nur ein Copter defekt ankommt... ich will gar nicht weiter rechnen... aber ich freue mich, wenn es noch klappt (ich könnte direkt bei Torsten abholen, 15km Entfernung).
Neben den Daten auf den 16 Hopping-Kanälen schickt die Fernbedienung das Gleiche nochmal auf vielen anderen Kanälen. Lauscht man nur an einem Kanal erhält man in unregelmäßigen Abständen einen Datensatz (hier Channel 2):
1 | 125 00 00 00 00 40 40 40 44 B0 46 00 00 00 00 00 FA |
2 | 261 00 00 00 00 40 40 40 44 B0 46 00 00 00 00 00 FA |
3 | 130 2F 00 00 00 40 40 40 44 B0 46 00 00 00 00 00 29 |
4 | 512 C1 00 00 00 40 40 40 44 B0 46 00 00 00 00 00 BB |
5 | 1813 DB 00 00 00 40 40 40 44 B0 46 00 00 00 00 00 D5 |
6 | 774 1A 00 00 00 40 40 40 44 B0 46 00 00 00 00 00 14 |
7 | 129 03 00 00 00 40 40 40 44 B0 46 00 00 00 00 00 FD |
8 | 126 00 00 00 00 40 40 40 44 B0 46 00 00 00 00 00 FA |
9 | 649 00 00 00 00 40 40 40 44 B0 46 00 00 00 00 00 FA |
Dann weiß der Empfänger einen Hopping-Kanal und ist schnell in Sync. Es gibt aber auch Kanäle (z.B. 0x1f) auf denen kommt nichts. Wenn die Fernbedienung noch nicht gebunden(?) hat, gibts auf vielen Kanälen (auch 0x1f) etwa alle 125ms einen Datensatz:
1 | 125 00 00 00 00 00 00 00 44 B0 46 00 00 00 00 C0 FA |
2 | 133 00 00 00 00 00 00 00 44 B0 46 00 00 00 00 C0 FA |
3 | 125 00 00 00 00 00 00 00 44 B0 46 00 00 00 00 C0 FA |
4 | 129 00 00 00 00 00 00 00 44 B0 46 00 00 00 00 C0 FA |
Auch hier kann der Empfänger dann die Kanäle ermitteln. https://bitbucket.org/rivig/v202 schickt zum Binden mehrere 0-Sätze mit byte[14]=0xc0 und geht dann in den Normalbetrieb. Mein jd385 bindet aber auch wenn [14]==0 ist. NB: Das Steuern des Helis über Tastatur ist deutlich schwieriger als über die Fernbedienung :-)
Fernbedienung: Für den N79E814 gibt es die Header Files für Keil&Co auf der Nuvoton Seite. Man muss aber nach "Demo Code" suchen, nicht nach "Header". Die sind in dem Zip versteckt. Falls der 814 ohne Bootlader in der FB ist (wovon ich ausgehe, auf den Pads ist ICP herausgeführt), brauchen wir den Stick von Nuvoton zum Programmieren (geschätzt € 30.-). Ich frage bei Nuvoton mal an, ob sie das ICP Protokoll herausrücken. Die Hardware wäre simpel.
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. Für das Binding werden keine besonderen Kanäle verwendet. Die Fernbedienung sendet einfach in ihrem 16 Kanalraster die Pakete. Das Binding wird beendet sobald der Speedstick einmal hin- und wieder zurück bewegt wurde. Die Pakete haben als Besonderheit 2 Flags gesetzt und die Werte für die Sticks sind auf 0x00 gesetzt. Coptersoftware: Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter"
Georg G. schrieb: > Das Problem ist... Stimmt. Sehe ich ähnlich. Allerdings wollen die meisten von uns vermutlich mehr als einen Copter (damit werden die Versandkosten pro Stück schon einmal geringer). Außerdem könnte ja die Fernbedienung und der Lader weggelassen werden, dürfte auch noch mal ein klein bisschen was bringen. Abschließend kann ich das nicht beurteilen. Aber wenn es tatsächlich 100 Stück für 900 € inkl. Versand geben sollte, dann ergibt sich bei Abnahme von 5 Stück pro Person: 9 € * 1,25 (Zoll + Ust.) = 11,25 € + 0,75 € (Versand und Verpackung [3,75 € / 5]) = 12,00 € pro Stück. Das wäre schon Attraktiv. Wenn Torsten jetzt noch 2 € als Profit / Puffer draufschlägt ist es immer noch 10 € billiger als bei eBay und damit wären locker 15 Defekte Copter abgedeckt. Weiterhin sollte klar sein, dass Torsten nicht dafür verantwortlich ist, wenn die Dinger defekt sind. Auf der anderen Seite ist das natürlich alles mit Aufwand und Risiko für Torsten verbunden. Auch weiß ich nicht, ob sich wirklich 9 € pro Stück erzielen lassen. Und ob hier wirklich so viel Nachfrage besteht ist auch fraglich. Vielleicht kann Torsten kurz mal schreiben, wie seine Pläne diesbezüglich sind, andernfalls würde ich mir einfach 5 von den Dingern direkt bei eBay klicken.
Bei 100 Stück könnte man vielleicht auch direkt beim Hersteller anfragen: http://www.jxdtoys.com/en/aboutus.asp
Jetzt wird der BU-Link plötzlich nicht mehr angeboten: http://www.aliexpress.com/store/product/Free-Shipping-NuLink-BuLink-Compatible-Cortex-M0-M051-ISP-ICP-Program/213957_674565728.html Ich hoffe doch, dass meiner auch wirklich geliefert wird. Langsam bekomme ich den Eindruck, dass es vielleicht sinnvoller wäre, die Chip-Erase von einem original Nu-Link zu grabben.
:
Bearbeitet durch User
Tim schrieb: > von einem original Nu-Link zu grabben Etwas Geduld noch, Bettelbrief um Infos an Nuvoton ist raus. Leider kenne ich niemanden, der deren ICs kommerziell einsetzt.
Georg G. schrieb: > Tim schrieb: >> von einem original Nu-Link zu grabben > > Etwas Geduld noch, Bettelbrief um Infos an Nuvoton ist raus. Leider > kenne ich niemanden, der deren ICs kommerziell einsetzt. Mal schauen, ob Du erfolgt hast. Es gab schon einige Anfregen über das Nuvoton-Forum, die leider abgelehnt wurden.
Tim schrieb: > Langsam > bekomme ich den Eindruck, dass es vielleicht sinnvoller wäre, die > Chip-Erase von einem original Nu-Link zu grabben. Oh no. Naja, damit muss ich mich wenigstens nicht mehr entscheiden, ob ich auch einen bestelle ;-) Hier gab es doch jemanden, der das Original hat und damit auch ein Erase durchgeführt hat. Vielleicht könnte er dir sein original ausleihen? Oder wir schmeißen hier zusammen und kaufen einen "gemeinsam". Davis schrieb: > Für das Binding werden keine besonderen Kanäle verwendet. Die > Fernbedienung sendet einfach in ihrem 16 Kanalraster die Pakete. Genau. So wie es auch in der Deviation implementiert ist. Habe mein Tool minimal angepasst und den anderen Trace ausgewertet. Am Anfang passiert ne Menge (Register Set, etc.) Das wird nicht umbedingt alles korrekt geparst, aber nach ein paar ms geht es los mit immer dem gleichen Packet:
1 | 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x1F 0xE4 0x75 0x00 0x00 0x00 0x00 0xC0 0x38 |
Also alles wie zu erwarten. Nun bin ich etwas verwirrt (mangels Copter) wie genau die "Bedienung" ist. Also RC Einschalten und dann Stick nach ganz oben? Damit sendet sie das Binding Packet solange bis der Stick auf 0 geschoben wird? Und am Copter? Schaut der einfach nach dem Einschalten nach dem ersten binding packet oder speichert er an welchen Sender er gebindet ist und es gibt am Copter ne Taste o. Ä. um das Binding zu starten?
Philipp E. schrieb: > Also alles wie zu erwarten. Nun bin ich etwas verwirrt (mangels Copter) > wie genau die "Bedienung" ist. Also RC Einschalten und dann Stick nach > ganz oben? Damit sendet sie das Binding Packet solange bis der Stick auf > 0 geschoben wird? Sobald der Speedstick, nachdem er oben war (0xFF), wieder unten ist (0x00), wird das Binding beendet und die Fernbedienung sendet "normale" Pakete. > Und am Copter? Schaut der einfach nach dem Einschalten nach dem ersten > binding packet oder speichert er an welchen Sender er gebindet ist und > es gibt am Copter ne Taste o. Ä. um das Binding zu starten? Keine Taste. Der Copter schaut nur auf die Pakete die da kommen. Die Bindung an die Fernbedienung erfolgt über die drei Bytes der Unique-ID.
Davis schrieb: > Keine Taste. Der Copter schaut nur auf die Pakete die da kommen. Ah verstehe. Also muss der Copter bei jedem Akku wechsel neu gebindet werden?
Philipp E. schrieb: > Genau. So wie es auch in der Deviation implementiert ist. Habe mein Tool > minimal angepasst und den anderen Trace ausgewertet. Am Anfang passiert > ne Menge (Register Set, etc.) Das wird nicht umbedingt alles korrekt > geparst, aber nach ein paar ms geht es los mit immer dem gleichen > Packet: > 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x1F 0xE4 0x75 0x00 0x00 0x00 0x00 > 0xC0 0x38 Interessant! Auf welchen Kanälen sendet er?
Tim schrieb: > Philipp E. schrieb: >> Genau. So wie es auch in der Deviation implementiert ist. Habe mein Tool >> minimal angepasst und den anderen Trace ausgewertet. Am Anfang passiert >> ne Menge (Register Set, etc.) Das wird nicht umbedingt alles korrekt >> geparst, aber nach ein paar ms geht es los mit immer dem gleichen >> Packet: >> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x1F 0xE4 0x75 0x00 0x00 0x00 0x00 >> 0xC0 0x38 > > Interessant! Auf welchen Kanälen sendet er? Auf den 16 Kanälen, die aus der Unique-ID generiert werden. Dabei ist immer ein Kanal zwischen 24 und 31. Die könnte der Copter "abhören", um an die ID zu kommen und dann seinerseits die 16 Hopping Kanäle zu bestimmen.
1 | Kanaele zu obiger Unique-ID: |
2 | |
3 | 5, 33, 63, 46, 42, 40, 52, 60, 31, 39, 47, 26, 36, 24, 51, 30 |
Davis schrieb: > Auf den 16 Kanälen, die aus der Unique-ID generiert werden. Also um das hier nochmal heraus zu stellen. Das Channel Hopping ist immer gleich egal ob in der "Bind" Phase oder bei der eigentlichen Steuerung. Die Sequenz hängt nur von der ID des Senders ab und ist daher immer gleich. Die Bind Phase zeichnet sich nur durch die spezielle Struktur der Pakete aus. Damit kann der Copter dann discovern welcher Sender sich binden will und kennt dann dessen ID und damit die Hopping Sequenz.
Philipp E. schrieb: > Die Sequenz hängt nur von der ID des Senders ab und ist daher > immer gleich. Also bezogen auf die ID. Die variiert natürlich von Sender zu Sender.
Philipp E. schrieb: > Oh no. Naja, damit muss ich mich wenigstens nicht mehr entscheiden, ob > ich auch einen bestelle ;-) Hier gab es doch jemanden, der das Original > hat und damit auch ein Erase durchgeführt hat. Vielleicht könnte er dir > sein original ausleihen? Oder wir schmeißen hier zusammen und kaufen > einen "gemeinsam". Ich werde wie gesagt auch einen kaufen, sobald mein Quad mal vom Zoll da ist, davor hat es keinen Sinn > Mal schauen, ob Du erfolgt hast. Es gab schon einige Anfregen über das > Nuvoton-Forum, die leider abgelehnt wurden. Jop, leider.
Manuel Steiner schrieb: > Ich werde wie gesagt auch einen kaufen, sobald mein Quad mal vom Zoll da > ist, davor hat es keinen Sinn Ach ja, stimmt ja. Super sache. Bitte direkt den LA dran hängen ;-)
Philipp E. schrieb: > Ach ja, stimmt ja. Super sache. Bitte direkt den LA dran hängen ;-) Klaro, Robert hat das zwar schon gemacht, aber vielleicht kann man da ja noch mehr rausholen. nosilent hat so einen Saleae Clone, und ich habe einen Open Bench Logic Sniffer, der sollte rein theoretisch bis 200Mhz funktionieren, aber leider nur One Shot und nicht kontinuierlich wie de saleae Teile, die den PC als Buffer verwenden. Ich hoffe es dauert nicht mehr all zu lange.
Manuel Steiner schrieb: > Robert hat das zwar schon gemacht Ich dachte irgendwie, der Trace war unvollständig. Habe ich mir das falsch gemerkt? Manuel Steiner schrieb: > Saleae Clone, und ich habe > einen Open Bench Logic Sniffer, der sollte rein theoretisch bis 200Mhz Das ist ja super. Damit müsste sicher ein guter Trace rauskommen.
Philipp E. schrieb: > Hier gab es doch jemanden, der das Original > hat und damit auch ein Erase durchgeführt hat. Vielleicht könnte er dir > sein original ausleihen? Oder wir schmeißen hier zusammen und kaufen > einen "gemeinsam". Klar, kein Ding. Hatte ich ja eh schon angeboten. Nachdem ich den Controller erased habe, brauche ich das Teil ja erstmal nicht. Sagt mir nur wo ich ihn hin schicken soll.
Robert Knipp schrieb: > Klar, kein Ding. Hatte ich ja eh schon angeboten. Wahnsinn. Danke! Klasse Sache!!! Da mein Copter noch nicht da ist, nützt mir das gute Stück leider im Moment nichts. Ich denke Tim wäre ein guter Ansprechpartner, falls er Zeit und Lust hat. Die Sache mit dem BuLink ist ja etwas ungewiss atm ;-) Ich habe noch einmal etwas im Thread gelesen und habe da noch einmal eine Frage. Du hast gesagt, du hast den Chip wieder gelockt und dann mittels ICP unlockt und erased. Hast du mit deinem LA eine Aufzeichnung, die dieses unlock + erase vollständig auf allen relevanten Leitungen Kommunikation gespeichert hat? Weil, ich hatte es damals so verstanden, dass dein LA immer irgendwann die Aufzeichnung abgebrochen hat. Danke schonmal für deine Mühe!
Philipp E. schrieb: > Ich habe noch einmal etwas im Thread gelesen und habe da noch einmal > eine Frage. Du hast gesagt, du hast den Chip wieder gelockt und dann > mittels ICP unlockt und erased. Hast du mit deinem LA eine Aufzeichnung, > die dieses unlock + erase vollständig auf allen relevanten Leitungen > Kommunikation gespeichert hat? Weil, ich hatte es damals so verstanden, > dass dein LA immer irgendwann die Aufzeichnung abgebrochen hat. Genau, der hat die Aufzeichnung selbstständig abgebrochen. Keine Ahnung warum. Ist auch das erste mal dass ich mit nem LA etwas mache. Daher fehlt mir da noch etwas die Erfahrung. Daher verleihe ich auch gern den NuLink. Ihr könnt damit wohl erstmal mehr anfangen als ich.
Haben will schrieb: > Ist das der richtige? Ja. Viel billiger als "PayPal" ist "Kredietkarte" nach wie vor nicht: http://www.aliexpress.com/item//1082441152.html Haben will schrieb: > Will mir so 3 bis 5 von den Dingern shoppen. Der übliche Hinweis: Einen nach dem anderen kaufen. Erst wenn der eine auf "versendet" steht, den nächsten. Alles was am gleichen Tag aus China abgeschickt wird, kann vom Zoll zusammen addiert werden, und dann zahlst Du drauf! Haben will schrieb: > Aber eine Sammelbestellung gibt es jetzt nicht, oder? Kann noch kommen, dann aber ohne Fernbedienung. Das Problem: Einzeln_ohne_Zoll mit Fernbedienung ist vielleicht billiger als eine Sammelbestellung mit_Zoll und ohne Fernbedienung.
:
Bearbeitet durch User
Robert Knipp schrieb: > Philipp E. schrieb: >> Hier gab es doch jemanden, der das Original >> hat und damit auch ein Erase durchgeführt hat. Vielleicht könnte er dir >> sein original ausleihen? Oder wir schmeißen hier zusammen und kaufen >> einen "gemeinsam". > > Klar, kein Ding. Hatte ich ja eh schon angeboten. Nachdem ich den > Controller erased habe, brauche ich das Teil ja erstmal nicht. Sagt mir > nur wo ich ihn hin schicken soll. Hallo Robert, vielen Dank für das Angebot. Ich würde gerne mein Glück versuchen. Du bekommst eine PM von mir.
:
Bearbeitet durch User
Tim schrieb: > Jetzt wird der BU-Link plötzlich nicht mehr angeboten: > > http://www.aliexpress.com/store/product/Free-Shipping-NuLink-BuLink-Compatible-Cortex-M0-M051-ISP-ICP-Program/213957_674565728.html > > Ich hoffe doch, dass meiner auch wirklich geliefert wird. Langsam Oh! Habe neulich auch einen geordert. Wurden soviel bestellt das die schon ausverkauft sind? Der Anbieter hat etliche Programmier-Interface im Angebot. Mal nachhaken.
So, mein NuLink ist auf dem Weg zu Tim. Vielleicht kommt er damit ja weiter.
> Wurden soviel bestellt das die schon ausverkauft sind? Es sieht so aus, dass die Firma nicht mehr existiert. Die Webseite ist ist nicht erreichbar: http://www.betemcu.cn
Robert Knipp schrieb: > So, mein NuLink ist auf dem Weg zu Tim. Vielleicht kommt er damit ja > weiter. Ich bin schon gespannt! Davis schrieb: >> Wurden soviel bestellt das die schon ausverkauft sind? > > Es sieht so aus, dass die Firma nicht mehr existiert. > Die Webseite ist ist nicht erreichbar: http://www.betemcu.cn Die Website ging schon vorher nicht. Den Aliexpress-shop gibt es aber noch. Nur bietet man das Produkt nicht mehr an.
:
Bearbeitet durch User
Hi, das Teil ist m. E. doch sehr schwer zu steuern. Also einen Schwebeflug auf konstanter Höhe in einem Raum kaum möglich. Das Teil haut immer nach den Seiten ab, auch wenn ich versuche zu trimmen.... Habe mir besseres erwartet :-(
Kalle S. schrieb: > das Teil ist m. E. doch sehr schwer zu steuern. Also einen Schwebeflug > auf konstanter Höhe in einem Raum kaum möglich. Das Teil haut immer nach > den Seiten ab, auch wenn ich versuche zu trimmen.... Meiner ist ziemlich stabil. Schaue mal hier: Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter" und weitere...
Meine beiden sind da ich musste 9euro zoll zahlen :) geht ja noch 50€ die kopter
Tim schrieb: > Kalle S. schrieb: >> das Teil ist m. E. doch sehr schwer zu steuern. Also einen Schwebeflug >> auf konstanter Höhe in einem Raum kaum möglich. Das Teil haut immer nach >> den Seiten ab, auch wenn ich versuche zu trimmen.... > > Meiner ist ziemlich stabil. Schaue mal hier: > Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter" und weitere... Danke Werde ich mal probieren. Frage : habe schon jemand ein anderes Netzteil fündig Akkus probiert?
Turbonator schrieb: > Meine beiden sind da ich musste 9euro zoll zahlen :) Dann hast Du wohl beide zusammen bestellt? > geht ja noch 50€ > die kopter War aber nicht nötig, der einzelne Copter wäre ganz legal ohne Kosten durchgegangen. Bei Käufen aus Fernost (oder Fernwest) immer die 22€-Grenze (bzw. 5€-Grenze für Gebühren) für EUst im Auge behalten. Sammelbestellungen lohnen sich da fast nie. Lieber zwischen den Bestellungen ein paar Tage oder Wochen warten. Ansonsten frisst die fällig werdende EUst den Preisvorteil auf. ...
Hannes Lux schrieb: > Lieber zwischen den Bestellungen ein paar Tage oder Wochen warten. Wie lange denn nun? ;) Torsten C. schrieb: > Einen nach dem anderen kaufen. Erst wenn der eine > auf "versendet" steht, den nächsten. @Hannes: Nicht gelesen oder anderer Meinung? Disclaimer: Es geht nicht ums "Recht haben", sondern darum, was später im Wiki steht. PS: Noch ein Wort zum Wiki: Im China-Billig-Thread ist das Wiki gerade "gestorben", siehe Beitrag "SUPER Bauteile-Schnäppchen WIKI" Ich hoffe, dass Ihr beim WIKI mit macht, und nicht alles an mir allein hängen bleibt. Im Moment muss ich erstmal etwas pausieren. Ausreden: 1. Meine Familie will, dass die LED-Leiste an der Wohnzimmerdecke endlich fertig wird (rechte Hälfte, Bild). 2. Ich muss endlich das Lochraster-Layout fertig machen, siehe Beitrag "Gitter-Drill (Trennstellen)" 3. Das Aquariumforum quengelt wegen eines LED-Strip-PWM-Dimmers: http://www.aquariumforum.de/threads/350068-sammelpost-rigid-stripes-test-fragen-beckenvorstellungen/page11?p=2346959&viewfull=1#post2346959 Das muss nun erstmal erledigt werden. Sorry.
:
Bearbeitet durch User
Habe heute um Mitternacht den Nu-Link von Robert im Briefkasten gefunden. Das ging ja wirklich schnnell! Viel dran ist nicht. Ich habe mal Bilder der Platine gemacht. Der Prozessor wurde erkannt. Auch wurde sofort gefragt, ob ich einen Chip erase durchführen will. Der Chip erase selbst dauert sehr lange, wobei eine sehr große Menge Daten über SWD geschaufelt werden, wie auf dem Screenshot zu sehen. Anbei ein Log des Datenaustausches zur Identifikation des Chips. Das Log des Erase-Vorgangs ist >100mb gezippt. Wo könnte ich das hochloaden? Ich muss jetzt erst einmal schlafen. Evtl. finde ich morgen noch etwas Zeit.
Hm, was wird da wohl in dem Flash drin stehen? Kannst du den auslesen? Vielleicht steht da die VID/PID drin. Wobei man dazu ja anscheinend meist bei billigen Sachen nen EEPROM benutzt. Achso das File geht das nicht auch bei github rein?
:
Bearbeitet durch User
Torsten C. schrieb: > @Hannes: Nicht gelesen oder anderer Meinung? Gelesen sicher, aber wieder vergessen, denn ich lese die Threads nicht in einem Stück, sondern immer mal wieder die neuesten Beiträge. Da gerät sowas schon mal in Vergessenheit. Anderer Meinung bin ich diesbezüglich nicht. Nur kann oder will man nicht immer warten, bis der erste Artikel da ist. Dazu ist die Ware einfach zu lange unterwegs. ...
Hannes Lux schrieb: > Nur kann oder will man > nicht immer warten, bis der erste Artikel da ist. Nee, da würde man ja kirre werden. Das hat m.E. auch niemand vorgeschlagen.
Tim schrieb: > Habe heute um Mitternacht den Nu-Link von Robert im Briefkasten > gefunden. Das ging ja wirklich schnnell! Super. Nochmal vielen vielen Dank an Robert! Tim schrieb: > Anbei ein Log... Klasse, auch dir tausend Dank, das du direkt den LA dran gehängt hast! Tim schrieb: > Wo könnte ich das hochloaden? Pack es zur Dropbox (https://www.dropbox.com). Der Account ist schnell angelegt und Speicher ist genug da. Nachteil: Die NSA hat dann den Log vom Erase... Tim schrieb: > Erase-Vorgangs ist >100mb Mhhh, damit wird das ganze vermutlich etwas komplexer als gedacht. Was könnten das wohl alles für Daten sein. Vielleicht ist es erst einmal das eigentliche unlocking und danach wird dann wie bei Keil ein Erase Tool in den Flash / Ram vom uC geschaufelt? Könnte es weiterhin sein, dass der Erase vlt. so lange braucht weil es viel zu löschen gibt? Kannst du den Chip noch einmal locken (aber sonst leer lassen) und noch mal das Unlock + Erase aufzeichnen? Weiterhin wäre ein reines Erase auf einem nicht gelockten (und ebenfalls leeren) Chip interessant. Ach ja, eine Frage noch: Kommt eigentlich auch was vom Chip zurück? Oder sendet der ICP nur? Torsten C. schrieb: > Im Moment muss ich erstmal etwas pausieren. Mach dir keinen Stress. Soll doch alles Hobby und Spaß bleiben. Und der Wiki Artikel kann ja über die Zeit wachsen. Außerdem muss er ja nicht jedes Detail dokumentieren. Je mehr dort steht, umso besser, aber wenn etwas dort nicht dokumentiert ist, kann das ja über die Zeit wachsen. Der Artikel ist in meinen Augen für den "frühen" Projekt Status schon auf einem super weg, ich denke das wird so weiter gehen. Jeder trägt bei, was er hat bzw. möchte bzw. kann und dann wird das schon.
:
Bearbeitet durch User
Philipp E. schrieb: > Tim schrieb: >> Wo könnte ich das hochloaden? > > Pack es zur Dropbox (https://www.dropbox.com). Der Account ist schnell > angelegt und Speicher ist genug da. Nachteil: Die NSA hat dann den Log > vom Erase... Guter Punkt. Einen Account habe ich dort eh. Hier ist das File: https://www.dropbox.com/s/l4xuxvaw1ielv19/connect%20and%20chip%20erase.zip Der Rest liegt im GitHub-Repository https://github.com/hackocopter/Documentation/tree/master/Nu-Link
Hier noch einmal ein paar Details zum Datenverkehr auf dem SWD-Interface. Das SWD-Intarface besteht aus zwei Leitungen: SWDCLK und SWDIO. SWDIO ist bidirektional. Die Datenrichtung wird dabei vom Master festgelegt. Der Chip-ERase Vorgang wird durch eine sehr kurze Sequenz eingeleitet, wie auf dem mittleren Bild zu sehen (3). Dann kommt für 25ms nicht. Diese Zeit kann eigentlich nur zum Chip-Erase reichen, wenn wirklich das ganze Flash gleichzeitig gelöscht wird. Diesen Teil hatte Robert auch oben schon einmal gepostet. Anschließend wird für eine sehr lange Zeit (20s) immer wieder die gleiche Sequenz gesendet. Bei mir kam dieser Vorgang immer erst zum erliegen, wenn ich auf "disconnect" in der ICP-Software geklickt habe. Der Controller war danach trotzdem entsperrt. Daher kann es sein, dass die lange Sequenz nicht unbedingt notwendig ist. p.s. die logfiles kann man mit Saleae Logic öffnen. Die Software ist für Testzwecke frei herunterladbar: http://www.saleae.com/downloads
:
Bearbeitet durch User
Torsten C. schrieb: > PS: Noch ein Wort zum Wiki: Im China-Billig-Thread ist das Wiki gerade > "gestorben", > siehe Beitrag "SUPER Bauteile-Schnäppchen WIKI" > > Ich hoffe, dass Ihr beim WIKI mit macht, und nicht alles an mir allein > hängen bleibt. Im Moment muss ich erstmal etwas pausieren. Ausreden: Hi Torsten, ich denke das Wiki wird sich von ganz alleine weiterentwickeln. Du hast ja schon einen sehr guten ersten Schritt gemacht. Man sollte nur häufiger darauf hinweisen dass es den Eintrag auch gibt. Daher hier noch einmal der Link auf den Artikel: http://www.mikrocontroller.net/articles/Hack-O-Copter Das wichtigste ist dass die Leute zum Artikel beitragen wenn sie Lust haben. Wenn vorher zu viele Regeln festgelegt werden schreckt das nur ab. Aufräumen kann man später immer noch.
Informationen zu SWD und freie Implementierungen sind immer noch recht spärlich. Hier einmal das, was ich bisher gefunden habe: Im MCHCK-Projekt gibt es eine SWD bit-bang Minimalimplementierung. Leider alles ziemlich wenig dokumentiert: https://mchck.org/ https://www.evernote.com/shard/s13/sh/2557f123-e1fd-4d04-b053-0adac1945c74/6343ffac964a01863d817690f27bbfb5 https://github.com/mchck/mchck/tree/master/bootloader/swd-adapter/swduino Dann natürlich Versaloon: http://www.versaloon.com/ Black Magic probe: http://www.blacksphere.co.nz/main/blackmagic https://github.com/gsmcmullin/blackmagic SWD Einführung http://www.lpcware.com/content/blog/introduction-cortex-serial-wire-debugging-part-one Hier noch Links von Manuel Steiner (Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter") damit alles an einem Platz ist: Ich hab letztens mal libswd gefunden: http://sourceforge.net/apps/trac/libswd Das ist eine SWD Library. Auf dieser Seite waren unter anderem folgende Dokumente zu SWD verlinkt: http://www.arm.com/products/system-ip/debug-trace/... http://www.arm.com/files/pdf/Low_Pin-Count_Debug_I... An die genaue Spezifikation kommt man wahrscheinlich nur als ARM Partner :/ Edit: Die ARM Debug Interface Architecture Specification könnte noch interessant sein. (Kapitel 5.2) http://www.pjrc.com/arm/pdf/doc/ARM_debug.pdf
Die Frage ist, ob es ausreicht einen Mikrocontroller so zu programmieren, dass er die Sequenzen aus "erase-preamble.png (3)" und 1x den Wiederholer aus "grosser-signalblock.png" zum Löschen sendet? Reicht das zum Löschen? Wenn nicht, was ist noch wichtig? Der Abschnitt ID-Device?
Ohne genaue Kenntnis des SWD Protokolls wird es fast unmöglich sein, die gesuchten Befehle zu finden. SWD ist bidirectional, wie soll man aus dem Mitschnitt erkennen, was der Nulink gesagt hat und was die Antwort war?
> Bei Käufen aus Fernost (oder Fernwest) immer die 22€-Grenze (bzw. > 5€-Grenze für Gebühren) für EUst im Auge behalten. Sammelbestellungen > lohnen sich da fast nie. Lieber zwischen den Bestellungen ein paar Tage > oder Wochen warten. Ansonsten frisst die fällig werdende EUst den > Preisvorteil auf. > > ... Artikel Standort Frankfurt. ?.......war angegeben
ist es mòglich die Daten binàr zu bekommen, also in definiertem Interval ein byte ist ein Sampling. Ev mit Sigrok, da geht es das Sampling als raw abzuspeichern. Hintergrund, damit kann ich dann das SWD Protokoll aufdòseln, zumindest nach Cortex M3 Docs.
Tim schrieb: > Edit: Die ARM Debug Interface Architecture Specification Genau das hat mir gefehlt! Super. Nun den Mitschnitt als Folge von Nullen und Einsen (positive Flanke von SCK ist Abtastzeitpunkt) und mit ein paar Zeilen Code kann man es grob aufdröseln.
Anbei die Daten von oben als Binary dump. Jedes Byte ist ein Sample bei 16MHz Abtastfrequenz. Bit0 =SWData Bit1=SWCLK. Man kann die Daten auch nur Abschnittsweise oder in anderen Formaten aus Logic exportieren. Ich hatte noch nicht so viel Zeit, mich mit der Interpretation zu beschäftigen. Was mir bisher aufgefallen ist: - Da die clk nur vom Host kommt, hängt die Gültigkeit der Daten von der Richtung des Datentransfers ab: Host->Target steigende Flank von Clk Target->Host fallende Flanks von Clk Das sieht man auch gut in dem SWD Bitbanging Source, der oben verlinkt ist.
1 | static void |
2 | write_bits(uint8_t buf, size_t bits) |
3 | {
|
4 | pin_configure(SWD_DIO_PIN, SWD_MODE_OUTPUT); |
5 | for (; bits > 0; --bits, buf >>= 1) { |
6 | pin_write(SWD_CLK_PIN, 0); |
7 | pin_write(SWD_DIO_PIN, buf & 1); |
8 | pin_write(SWD_CLK_PIN, 1); |
9 | }
|
10 | }
|
11 | |
12 | static void |
13 | read_bits(size_t bits, int silent) |
14 | {
|
15 | uint8_t val = 0; |
16 | |
17 | pin_configure(SWD_DIO_PIN, SWD_MODE_INPUT); |
18 | size_t bit; |
19 | for (bit = 0; bit < bits; ++bit) { |
20 | pin_write(SWD_CLK_PIN, 0); |
21 | val |= !!pin_read(SWD_DIO_PIN) << bit; |
22 | pin_write(SWD_CLK_PIN, 1); |
23 | }
|
24 | if (!silent) |
25 | reply_write(&val, 1); |
26 | }
|
Hi, Der NuLink wird eine Unlock Sequenz senden und danach darauf warten bis der Chip mit dem Flash-Löschen fertig ist. In dieser Zeit pollt er den SWD um eine Statusmedllung zu erhalten Läuft doch beim STM32 auch so. Ein Chip-Unlock löscht immer das gesamte Flash, das dauert eben etwas. Versuche zu identifizieren was in der langen Leer Phase passiert und teile die ganze Übertragung in drei Teile. Unlock -> Status polling -> Antwort. Gruß Martin
Tim schrieb: > - Da die clk nur vom Host kommt, hängt die Gültigkeit der Daten von der > Richtung des Datentransfers ab: > Host->Target steigende Flank von Clk > Target->Host fallende Flanks von Clk Bild 6 in "LPC Debug Interfaces" sagt, dass die Daten immer mit der steigenden Flanke gültig sind, egal, wer sendet. Bild 5-1 in der ARM Debug Spec sagt, dass es immer die fallende Flanke ist, egal, wer sendet. Nun darfst du dir aussuchen, was richtig ist :-) (Abgesehen davon: Der von dir gezeigte Code Ausschnitt verwendet immer die steigende Flanke, das Target legt nach der fallenden Flanke die Daten an. Man wartet etwas und zeigt mit der steigenden Flanke, dass man gelesen hat und Target bitte das nächste Bit bereit stellen möge.)
:
Bearbeitet durch User
> Der NuLink wird eine Unlock Sequenz senden und danach darauf warten bis > der Chip mit dem Flash-Löschen fertig ist. In dieser Zeit pollt er den > SWD um eine Statusmedllung zu erhalten > Läuft doch beim STM32 auch so. Ein Chip-Unlock löscht immer das gesamte > Flash, das dauert eben etwas. > > Versuche zu identifizieren was in der langen Leer Phase passiert und > teile die ganze Übertragung in drei Teile. Unlock -> Status polling -> > Antwort. Hi Martin, das kann gut sein. Es Großteil des Datenverkehrs scheint nur aus der "line reset sequence" (50x CLK während IO high ist) zu bestehen. Wahrscheinlich wartet der Adapater einfach nur darauf, dass das Target eine gültige Antwort zurück sendet. Siehe auch 5.4.1 http://www.pjrc.com/arm/pdf/doc/ARM_debug.pdf Direkt am Anfang macht er bereits 4x einen Line-Reset, ohne dass eine Antwort zu kommen scheint.
Georg G. schrieb: > (Abgesehen davon: Der von dir gezeigte Code Ausschnitt verwendet immer > die steigende Flanke, das Target legt nach der fallenden Flanke die > Daten an. Man wartet etwas und zeigt mit der steigenden Flanke, dass man > gelesen hat und Target bitte das nächste Bit bereit stellen möge.) Ja, aber dadurch ändern sich die Daten auf/nach der steigenden Flanke und sind damit dort nicht gültig. Im LA Log kann das durchaus zu Glitches führen, wie man an ein paar Stellen sehen kann.
So morgend werde ich dem Zoll die Rechnung schicken und dann ist das Teil hoffentlich auch bald hier und dann brauch ich keinen "Blindflug" bezüglich der Hardware mehr zu machen.
Interessanter Link: Beitrag "Re: Flash im Cortex-M0 durch Codeinjektion ins SRAM auslesen" Es sieht so aus, dass der "Frankfurter"-Copter nicht gelockt ist.
Ich habe den Bitstream extrahiert und das vorlàufige Ergebnis ist dieses. Warscheinlich sollte die binary noch gefiltert werden. Morgen kann ich mehr berichten. x parity error header x ack = 1 SWD(1) DAP Write = 0x997dec09 ack = 1 data parity error SWD(1) DAP Write = 0x197ccc09 ack = 7 SWD(2) DAP Write = 0xf3181332 parity error header x ack = 3 data parity error SWD(0) DAP Write = 0xbc2e048c Ack error x parity error header x ack = 1 SWD(1) DAP Write = 0x997dec09 ack = 1 data parity error SWD(1) DAP Write = 0x197ccc09 ack = 7 SWD(2) DAP Write = 0xf3181332 parity error header x ack = 3 data parity error SWD(0) DAP Write = 0xbc2e048c Ack error x parity error header x ack = 1 SWD(1) DAP Write = 0x997dec09 ack = 1 data parity error SWD(1) DAP Write = 0x197ccc09 ack = 7 SWD(2) DAP Write = 0xf3181332 parity error header x ack = 3 data parity error SWD(0) DAP Write = 0xbc2e048c Ack error x parity error header x ack = 1 SWD(1) DAP Write = 0x997dec09 ack = 1 data parity error SWD(1) DAP Write = 0x197ccc09 ack = 7 data parity error SWD(2) DAP Write = 0xf3181132 ack = 7 data parity error SWD(1) AP Write = 0xf0981032 parity error header x ack = 4 fault parity error header x ack = 1 SWD(1) DAP Write = 0x997dec09 ack = 1 data parity error SWD(1) DAP Write = 0x197ccc09 ack = 7 SWD(2) DAP Write = 0xf3181332 parity error header x ack = 3 data parity error SWD(0) DAP Write = 0xbc2e048c Ack error x parity error header x ack = 1 SWD(1) DAP Write = 0x997dec09 ack = 1 data parity error SWD(1) DAP Write = 0x197ccc09 ack = 7 SWD(2) DAP Write = 0xf3181332 parity error header x ack = 3 data parity error SWD(0) DAP Write = 0xbc2e048c Ack error x parity error header x ack = 1 SWD(1) DAP Write = 0x997dec09 ack = 1 data parity error SWD(1) DAP Write = 0x197ccc09 ack = 7 SWD(2) DAP Write = 0xf3181332 parity error header x ack = 3 data parity error SWD(0) DAP Write = 0xbc2e048c Ack error x parity error header x ack = 1 SWD(1) DAP Write = 0x997dec09 ack = 1 data parity error SWD(1) DAP Write = 0x197ccc09 ack = 7 SWD(2) DAP Write = 0xf3181332 parity error header x ack = 3 data parity error SWD(0) DAP Write = 0xbc2e048c Ack error x parity error header x ack = 1 SWD(1) DAP Write = 0x997dec09 ack = 1 data parity error SWD(1) DAP Write = 0x197ccc09 ack = 7 SWD(2) DAP Write = 0xf3181332 parity error header x ack = 3 data parity error SWD(0) DAP Write = 0xbc2e048c Ack error x parity error header x ack = 1 SWD(1) DAP Write = 0x997dec09 ack = 1 data parity error SWD(1) DAP Write = 0x197ccc09 ack = 7 SWD(2) DAP Write = 0xf3181332 parity error header x ack = 3 data parity error SWD(0) DAP Write = 0xbc28048c
Nur zur schnellen Erklàrung: parity error header -- discard bit and repeat header parsing. Ack error -- Protocol error, no answer from target data parity error -- parity error on 32bit data field. Unter umstànden ist die Pause nach dem Protokoll Fehler. Wenn dem so ist, dann ist es nicht die gesuchte Sequenz. Im Header wird neben Parity auch getestet, ob Stop bit 0 ist. Dies gibt einen eigenen Fehler, welcher hier nie aufgetreten ist. Wenn mehrere parity error header hintereinander auftreten, stimmt was nicht. Ich will noch einen Filter fuer die Raw Daten reinmachen, und dann anstelle oder zusàtzlich zum derzeitigen Debug Ausgabe ein Replay C File generieren damit man dann testen kann, ob man dies mit irgendeiner CPU raufspielen kann, ungeachtet aller Timings. Hier mein derzeitiger Code , der Rueckgabewert ist die Anzahl der bits to discard, data ist 64bit bitstream Variable als einziges Argument der Funktion. header = data>>(64-8); write = lsb(1,2,data); addr = lsb(2,3,data); ack = lsb(3,8+1,data); dat = lsb(32,8+4+write,data); par = lsb(1,8+4+write+32,data); if(header&2) return puts("stop error"),1; // test stop bit if(parity(header&0x7c)) return printf("parity error header "),1; if(!ack) return printf("Ack error "),9; printf(" ack = %d ",ack); if(ack==2) return puts(" wait "),8+4+1; // wait if(ack==4) return puts(" fault "),8+4+1; // fault if(parity(dat)!=par) puts("data parity error"); printf(" SWD(%d) %s %s = %#x\n",addr, header&0x40?"AP":"DAP",header&0x20?"Read":"Write", dat); return 14+32; } Chris
No y. schrieb: > was wird da wohl in dem Flash drin stehen? > > Kannst du den auslesen? Vielleicht steht da die VID/PID drin. Wobei man > dazu ja anscheinend meist bei billigen Sachen nen EEPROM benutzt. Das ist ein 16mbit Device. Da wird wohl etwas mehr drin gespeichert sein als nur VID/PID. Nur was? Auslesen will ich es lieber nicht, ich will den NU-Link nicht beschädigen.
chris schrieb: > x > parity error header x > ack = 1 SWD(1) DAP Write = 0x997dec09 > ack = 1 data parity error > SWD(1) DAP Write = 0x197ccc09 > ack = 7 SWD(2) DAP Write = 0xf3181332 Ich habe mir inzwischen noch einmal einige Stellen das Protokolls per Hand angeschaut. Es wird sehr lange einfach nur "Line Reset" und "Read IDCODE" gesendet, worauf das Target nicht zu antworten scheint. Erst ganz am Ende des "ID-Device" blocks findet eine gültige Kommnukation statt. Ich habe diesen Bereich mal ausgeschnitten und angehängt. Übrigens musste ich zur Auswertung des Anwort des Targets tatsächlich die fallende Flanke auswerten, da es manchmal am Übergang Glitches gab. Evtl. müsstest Du das in Deinem Code auch berücksichtigen. Der Screenshot zeigt ein "READ"-Feld, in dem das Target sendet. Manchmal hat der LA einen Übergang auf der steigenden Flanke gesampled, machmal danach.
:
Bearbeitet durch User
chris schrieb: > Nur zur schnellen Erklàrung: > parity error header -- discard bit and repeat header parsing. > Ack error -- Protocol error, no answer from target > data parity error -- parity error on 32bit data field. Also wenn ich das richtig verstehe, ist das Log auf dem Post oben aus einem Bereich wo das Target nicht antwortet. t. > Ich will noch einen Filter fuer die Raw Daten reinmachen, > und dann anstelle oder zusàtzlich zum derzeitigen Debug Ausgabe > ein Replay C File generieren damit man dann testen kann, ob man dies Ich fürchte ja fast, dass es nicht ausreicht, einfach nur die Signalsequenz zu wiederholen. Es ist wohl notwendig, die Registerzugriffe zu extrahieren und mit einem simplemen SWD-Treiber wieder abzuspielen. Aber zum Glück ist das Low-Lowevel Protokoll ja relativ einfach. > mit irgendeiner CPU raufspielen kann, ungeachtet aller Timings. > Hier mein derzeitiger Code , der Rueckgabewert ist die Anzahl der bits > to discard, data ist 64bit bitstream Variable als einziges Argument der > Funktion. Wie extrahierst Du denn "data"? Wie oben geschrieben, müsste man das evtl. Kontext-Sensitiv tun. Was machen "lsb" und "parity"? P.s.: Ich habe per Hand den IDCODE 0x0BB11477 ermittelt. Dabei stimmt die Vendor Id in [11:] = 0x23B, allerdings ist die Device ID in [27:12] mit 0xBB11 evtl. nicht richtig.
:
Bearbeitet durch User
Tim schrieb: > ganz am Ende des "ID-Device" blocks findet eine gültige Kommnukation > statt. Ich habe diesen Bereich mal ausgeschnitten und angehängt.
Tim schrieb: > ganz am Ende des "ID-Device" blocks findet eine gültige Kommnukation > statt. Ich habe diesen Bereich mal ausgeschnitten und angehängt. Hier ist auch die Datei.
> Wie extrahierst Du denn "data"? Wie oben geschrieben, müsste man das > evtl. Kontext-Sensitiv tun. Was machen "lsb" und "parity"? > Vom binary dump durch das Programm swd_dat generiere ich eine Datei, welche den Bitstream enthàlt, bei steigender Flanke von clk. Ich lese diesen Bitstream dann in der Variable data ein, Msb first. Aus diesem Grunde gibt es die Funktion lsb(len,offset,data) welche den lsb first Wert aus data zurueckgibt. Parity gibt das parity bit zurueck. > P.s.: Ich habe per Hand den IDCODE 0x0BB11477 ermittelt. Dabei stimmt > die Vendor Id in [11:] = 0x23B, allerdings ist die Device ID in [27:12] > mit 0xBB11 evtl. nicht richtig. Ich habe den Verdacht, dass die Turnaround time veràndert wird und es dadurch dann zu Timingverschiebung kommt. Gibt es eine Mòglichkeit die Geschwindigkeit runterzusetzen, kònnte ein Workaround sein, damit die Turnaround Zeit nicht raufgesetzt wird. Zum Programm, sind einfach gemacht, Daten werden als stdin eingelesen, und ueber stdout ausgegeben, also cmd Umleitung verwenden. dump -- was àhnliches wie hexdump, wenn man ein x-beliebiges Argument dazugibt, dann werden gleiche Daten ignoriert. swd_dat -- convertiert das Binary in einen gueltigen Datenstream, eine Art spi protokoll decoder. swd_dump -- dump der Kommunikation. Derzeit rudimentàr. -v als Argument gibt mehr verbosity info, man sollte dies mal probieren, derzeit max drei mal hintereinander.
Tim schrieb: > Informationen zu SWD und freie Implementierungen sind immer noch recht > spärlich. Hier einmal das, was ich bisher gefunden habe: Vor kurzem war in einem Thread: Beitrag "Logic analyzer HP, Tek - Protokollauswertung" von einem Zeroplus Logic Analyzer die Rede bei welchem der Käufer aus einer Reihe von Protokollanalyseoptionen wählen kann. Einer davon war der SWD. Eventuell hat den einer oder weiss von jemanden der einen hat?
Mein Sourcecode basiert auf diesen Link: http://theesan1688.wordpress.com/2012/11/10/implementation-of-serial-wire-jtag-flash-programming-in-arm-cortex-m3-processors/
Zum Thema "Daten erfassen": SWD ist bis 50MHz Takt spezifiziert. Das sind 20ns. Da wird es also keine langen Haltezeiten geben. Unmittelbar nach der gültigen Flanke ist das Signal schon wieder weg. Eine asynchrone Aufzeichnung müsste also mit 100MHz erfolgen. Das ist unrealistisch und ergibt einen Wust an Daten. Der Saleae kann auf Flanke triggern. Also warum nicht die Datenerfassung auf der positiven Clock Flanke machen? Eventuell zusätzlich zwei Inverter zwischen Nulink-Takt-Ausgang und Board-Takt-Eingang schalten, den Saleae mit seinem Trigger Kanal am Nulink. Das könnte 10ns Sicherheit geben (in der Hoffnung, dass der Nulink etwas Haltezeit für die Daten hat). Bei der Gelegenheit die Frage, ob jemand den User Guide für Saleae Version 1.0.21 hat. Online kommt leider die falsche Version, die im GUI etwas anders ist. Ich kann mir die Funktionen denken, bin an einigen Stellen aber nicht sicher.
Hat jemand eigentlich schonmal die arduino Software von https://bitbucket.org/rivig/v202/src/c2142a790c463abff9004b761e013cff6735f50b/V202_arduino/?at=default mit dem copter ans laufen bekommen? Ich hab da jetzt mal ein bisschen mit rumgespielt (atmega328p + nrf24l01) aber bei mir bindet der copter nicht mit der Software. :-\ Gruss, Simon
Simon schrieb: > Hat jemand eigentlich schonmal die arduino Software von > https://bitbucket.org/rivig/v202/src/c2142a790c463abff9004b761e013cff6735f50b/V202_arduino/?at=default > mit dem copter ans laufen bekommen? > Ich hab da jetzt mal ein bisschen mit rumgespielt (atmega328p + > nrf24l01) aber bei > mir bindet der copter nicht mit der Software. :-\ Ich glaube Helmut hat das hinbekommen, wenn ich seine Bemerkung richtig interpretiere. Helmut H. schrieb: > https://bitbucket.org/rivig/v202 schickt zum Binden mehrere 0-Sätze mit > byte[14]=0xc0 und geht dann in den Normalbetrieb. Mein jd385 bindet aber > auch wenn [14]==0 ist. > > NB: Das Steuern des Helis über Tastatur ist deutlich schwieriger als > über die Fernbedienung :-) Magst Du uns verraten, was Du hier gemacht hast? :)
Georg G. schrieb: > Bei der Gelegenheit die Frage, ob jemand den User Guide für Saleae > Version 1.0.21 hat. Online kommt leider die falsche Version, die im GUI > etwas anders ist. Ich kann mir die Funktionen denken, bin an einigen > Stellen aber nicht sicher. Ist nicht 1.1.15 die neuste Version?
Tim schrieb: > Ist nicht 1.1.15 die neuste Version? Das ist richtig. Aber ich suche den alten User Guide.
Habs mit dem Original nicht probiert, aber müsste eigentlich wenn man einen der #if 0 für die Definition der txid's zu #if 1 macht Mit dem angehängten Testprogramm, das davon geklaut ist, gehts mit uint8_t txid[3] = { 0xcd, 0x31, 0x71 } bei meinen beiden Helis. * Stromlosen Heli mittels handelsüblichen Nähgarns(z.B. "Sternzwirn hohreißfest") so an einer Unterlage befestigen, so dass er sich zwar bewegen, aber nicht entkommen kann * Software auf Arduino starten (benutze 8 für CE und 9 für CSN) * Terminal mit 115200 * tippe H für Hopping-Kanäle aus der o.a. txid berechnen * tippe s für senden, man sieht die gesendeten Werte von buf[0] bis buf[3] * Heli stromversorgen * Warten bis er langsam blinkt * tippe b für Binden, das schickt einfach 50 bind-Sätze. * Heli LEDs bleiben an * Üben mit +, -, i,j,k,m. Das ändert throt um 10 (von 0-255), roll und pitch um 4 (von 0x19 ..0 oder ox80 ..0x9f) * Leertaste setzt alle Werte wieder auf 0 zurück. * Nähgarn durchschneiden Mit anderen txids funktioniert das Binden nur manchmal, habe mich aber nicht weiter darum gekümmert. N.B: Interessante Erfahrung, wenn Programmier- oder Bedienungsfehler sofort mit Schmerzen bestraft werden. Beabsichtige dies als "Taktile Feedback Driven Super Agile Software Development" zu vermarkten.
:
Bearbeitet durch User
Nabend Leute, Interessanter Thread! Cooles Projekt. Wie oben schon mal angefragt, hätte ich hier einen LA von Zeroplus, der kann das SWD Protokol analysieren. Ich weiß nicht genau wie weit ihr seid und ob das noch was helfen könnte? Gruß Daniel
Hmm irgendwas stimmt mit meiner atmega nrf24l01 connection nicht. Prinzipiell sieht die Verbindung wohl gut aus, beim init bekomme ich das: STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0 RX_ADDR_P0-1 = 0x8686866688 0x6868688866 RX_ADDR_P2-5 = 0xc3 0xc4 0xc5 0xc6 TX_ADDR = 0x8686866688 RX_PW_P0-6 = 0x10 0x10 0x00 0x00 0x00 0x00 EN_AA = 0x00 EN_RXADDR = 0x03 RF_CH = 0x4c RF_SETUP = 0x07 CONFIG = 0x0f DYNPD/FEATURE = 0x00 0x00 Data Rate = 1MBPS Model = nRF24L01+ CRC Length = 16 bits PA Power = PA_HIGH Ich sehe mit dem LA auch auf MOSI/MISO die geschriebenen und gelesenen Werte. Aber wenn ich auf senden gehe (mit debugflags) dann bekomme ich: *** CHANGING TO SEND ROLE -- PRESS 'r' TO SWITCH BACK write_register(11,10) write_register(12,10) write_register(02,03) Writing Pipe write_register(00,0e) write_register(07,70) ...OK.write_register(00,0c) 00 00 00 00 write_register(05,1f) write_register(00,0e) write_register(07,70) ...Failedwrite_register(00,0c) 00 00 00 00 write_register(00,0e) write_register(07,70) ...Failedwrite_register(00,0c) 00 00 00 00 write_register(05,3d) write_register(00,0e) write_register(07,70) ...Failedwrite_register(00,0c) Also mal gehts mit ok durch, zu 99% endet das senden aber mit Failed. Hat irgendjemand einen Tipp für mich? Gruss, Simon
Also irgendwas ist bei meiner RF24.cpp im argen, da ist schonmal beim senden CE LO und HIGH vertauscht... Helmut: könntest Du noch deine RF24.h/cpp, RF24_config.h und nRF24L01.h posten? Das wäre super. Gruss, Simon
Ok, Problem gelöst... Ich habe das mit nem chinesischen arduino nano 3 clone getestet. Das NRF24L01 (ohne pa) hab ich an den 3.3V out vom ftid (wie ich dachte) gehängt, der kann ja normalerweise bis 60mA liefern. Sollte für die 10mA vom nrf24 also reichen. Zumindest für den ohne PA, für den leistungsfähigen mit PA braucht man ja eh nen 3.3V Regler. ACHTUNG: (zumindest mein) Clone hat nen PL2303, der liefert wenn überhaupt nur 19mA für PL2303 + NRF24. Das führte dazu dass sich mein NRF24 immer geresettet hat. Lösung: 3.3V Regler für den NRF24. Gruss, Simon
@Simon: schön dass es funktioniert. Simon schrieb: > Helmut: könntest Du noch deine RF24.h/cpp, RF24_config.h und nRF24L01.h > posten? Das wäre super. Nur der Vollständigkeit halber: Erforderlich sind die aktuellen Dateien von https://github.com/maniacbug/RF24 nach libraries/RF24. Habe nichts daran geändert.
Gibt es mittlerweile etwas neues vom Bu-Link? Oder von den analysierten Unlock Sequenzen?
Das neue über den von mir bestellten Bulink ist, dass er noch nicht da ist :-(
Hi ich will die Reichweite erhöhen sender/Empfänger wo bring ich die antenne am besten an ? Hat jemand schonmal die reichweite getestet. Bei mir sind 80 meter möglich, 200-500m wären gut .
Turbonator schrieb: > Bei mir sind 80 meter möglich, 200-500m wären gut . Ich habe es bisher noch nicht geschafft die Reichweite zu überschreiten. Wie denn auch? Wenn er so weit weg ist sieht man ihn sowieso nicht mehr, das einzige was man damit erreichen würde wäre, dass er unkontrollierbar (da fast nicht mehr sichtbar) irgendwo abstürzt.
Ich Bestelle mir ne funk Kamera diese woche noch und da wäre es schön auf dem feld etwas weiter fliegen zu können ich seh das teil auch noch auf 500m
Heute hat mir der Postmann Flattermaxe Nummer 3 gebracht, aber vom Bulink noch keine Spur :-(
Ich habe leider in den letzten Tagen keine Zeit gefunden, mich weiter mit dem copter zu beschäftigen. Das wird sich aber hoffentlich wieder ändern. Nur kurz ein paar Kleinigkeiten: - Das Bu-Link ist immer noch nicht da. - Programmieren mit dem Nu-Link funktioniert wunderbar. Das CMSIS-Blinky ist jetzt auch auf richtiger Hardware erprobt. Auch die Ausgabe über die serielle Schnittstelle funktioniert: https://github.com/hackocopter/Examples/tree/master/Blinky-CMSIS -Die Platinen für den LiPO-Charger sind angekommen. Leider konnte ich ihn noch nicht testen, da mir das IC noch fehlt. Aus einem mir unerfindlichen Grund hat OSH-Park mir sogar die doppelte Anzahl an Platinen geschickt. Daher würde ich an die ersten drei, die mir ihre Adresse per PM schicken, eine abgeben. Bitte nur anfragen, wenn ihr später auch hier über euren Aufbau berichtet :) https://github.com/hackocopter/LiPoCharger -Bezüglich der Chip-Erase Sequenz habe ich mir überlegt, eine Low-Level SWD Implementierung zu programmieren. Mit den Beispielen und der Dokumentation ist das nicht sonderlich kompliziert, hilft aber auch das Protokoll besser zu verstehen. Außerdem ist dann die Software zum Unlocken gleich mit fertig.
bezueglich Unlock. Es geht definitiv nicht ueber normales SWD. Teilweise waren logs da, wo SWD waehren Reset gemacht wurde, andererseits existieren Logs mit speziellen High Waveforms welche definitiv nicht das SWD Protokoll sind. Es waere hilfreich, zwei komplette Logs zu haben, einmal von einem ungesperrten Baustein, und einmal von einem welcher looked ist und testen, ob es da differenzen gibt.
Philipp E. schrieb: > Kannst du > den Chip noch einmal locken (aber sonst leer lassen) und noch mal das > Unlock + Erase aufzeichnen? Weiterhin wäre ein reines Erase auf einem > nicht gelockten (und ebenfalls leeren) Chip interessant. chris schrieb: > Es waere hilfreich, zwei komplette Logs zu haben, einmal von einem > ungesperrten Baustein, und einmal von einem welcher looked ist und > testen, > ob es da differenzen gibt. Glaube auch das die beiden Logs zusammen sehr hilfreich wären. Dann könnte man das SWD darin parsen und schauen was dann noch für Waveforms übrig bleiben.
:
Bearbeitet durch User
chris schrieb: > Es waere hilfreich, zwei komplette Logs zu haben Aber bitte nicht wieder mit freilaufendem Takt sondern auf die positive Flanke getriggert.
Philipp E. schrieb: > kann mir jemand sagen, was das für ein Connector Im "nRF24LU1 Reference Design" (was anscheinend die 2.4G NRF24lu1p china dongle ist) http://www.freqchina.com/en/down.asp?ID=102 ist ein adapter kabel gezeigt "nRF24LU1 USB Dongle Programming adapter cable", die passende buchse ist in der BOM als "JST BM05B-SRSS-TB" gelistet. Der stecker ist also JST SH familie, 5pin, 1mm pitch.
Ok, weiter gehts. Hier sind ein paar neue Logs: ->connect__protected_device_-disconnect Verbinden und Verbindung wieder trennen. Read protect ist gesetzt. ->connect-chip_erase-disconnect Verbinden, Chip erase und disconnect. Read protect war gesetzt. ->connect-program_fuses_to_protect-erase-disconnect Verbinden, Read protect fuse setzen und disconnt. Read protect war nicht gesetzt. Bit 0- SWDIO Bit 1- SWDCLK Bit 2- Reset (wird nie ausgelöst)
:
Bearbeitet durch User
Georg G. schrieb: > chris schrieb: >> Es waere hilfreich, zwei komplette Logs zu haben > > Aber bitte nicht wieder mit freilaufendem Takt sondern auf die positive > Flanke getriggert. Das kann der LA leider nicht. Das Triggering bezieht sich wirklich nur auf den Startzeitpunkt der Aufzeichnung. Danach wird einfach nur gesampled. Dafür haben die ganzen "professionellen" LA nicht die Speichertiefe. Letztendlich bin ich aber immer noch davon überzeugt, dass das Protokoll nicht darauf angewiesen ist, innerhalb eines sehr kleinen Zeitfensters zu samplen. Für so etwas wäre auf der Host-seite dedizierte Hardware notwendig. Das Nu-Link, und wahrscheinlich die meisten anderen SWD-Adapter auch, nutzt anscheinend die GPIO Pins an einem normalen Mikrocontroller per "Bit-Banging" Daher ist es gar nicht möglich, ein Clock-Signal auszugeben und gleichzeitig auf einer Flanke zu sampeln.
Kommt man vielleicht schneller weiter, wenn man per USB-Sniffer die Kommunikation zum NuLink mitschneidet? Nur ein Gedanke ...
chris schrieb: >> Wie extrahierst Du denn "data"? Wie oben geschrieben, müsste man das >> evtl. Kontext-Sensitiv tun. Was machen "lsb" und "parity"? >> > Vom binary dump durch das Programm swd_dat generiere ich eine Datei, > welche > den Bitstream enthàlt, bei steigender Flanke von clk. > Ich lese diesen Bitstream dann in der Variable data ein, Msb first. > Aus diesem Grunde gibt es die Funktion lsb(len,offset,data) welche den > lsb first Wert aus data zurueckgibt. Parity gibt das parity bit zurueck. Wie schon oben geschrieben, ich denke hier liegt m.E. das Problem. Daten, die vom Target gesendet werden, müssten auf der nachfolgenden fallenden Flanke ausgelesen werden. Das Einlesen der Daten und der Protokollanalyzer lassen sich demnach nicht trennen. Torsten C. schrieb: > Kommt man vielleicht schneller weiter, wenn man per USB-Sniffer die > Kommunikation zum NuLink mitschneidet? Nur ein Gedanke ... Damit würden sich bestimmt einfach binärdaten abfangen lassen. Aber der Befehl, den der Computer an das NU-Link zum Löschen sendet kann ziemlich beliebig sein. 42? 請刪除該芯片? "kill them all"?
:
Bearbeitet durch User
Tim schrieb: > Das kann der LA leider nicht Dann muss man mit einem Flipflop zwischen Nulink-Daten und Analyser-Daten nachhelfen, damit die Daten immer zur Flanke passen. Mit freilaufendemTakt kommt es schnell zu Schmutzeffekten. Aber vielleicht haben wir ja Glück.
Ich habe den SWD-Analyzer von Chris etwas erweitert. Aktueller Stand anbei. - Bug: Read und Write waren verwechselt - Bug: lsb(...) wurde bei mir nicht richtig compiliert, da Maskierung nicht long long war - Neu: rising udn falling edge werden ausgewertet - Neu: Analyse in einem Durchgang Leider ergeben die Logs immer noch nicht so recht viel Sinn. Sie sind voll von erfolglosen versuchen, den SWD-Port zu resetten. Ich werde später weiter machen, vermute aber langsam, dass es doch einfacher ist, sich über eine SWD-Implementierung heranzutasten. Welche Sequenz für Chip-Erase verantwortlich ist, lässt sich ja einkreisen.
Tim schrieb: > Ich habe den SWD-Analyzer von Chris etwas erweitert. Bitte noch etwas mehr erweitern: <string.h> mit dazu. Funktionen, die nichts zurück geben als void definieren. Dann meckert LCC32 auch nicht mehr :-)
Georg G. schrieb: > Ich habe den SWD-Analyzer von Chris etwas erweitert. > > Bitte noch etwas mehr erweitern: > <string.h> mit dazu. > Funktionen, die nichts zurück geben als void definieren. Du meinst, ich sollte den Source lieber in das Repository laden? :) Ist schon geschehen: https://github.com/hackocopter/SWD-Hacking mingw-gcc ist übrigens ziemlich schmerzfrei.
Tim schrieb: > mingw-gcc Mag sein. Aber nichts hält sich hartnäckiger als Software, mit der man seit mehr als 10 Jahren problemlos arbeitet. Ich würde die typedefs auch anders machen, mit Typen aus stdint.h, also nicht z.B. short int sondern int16_t. Ist defensiver. Und immer noch kein Copter gekommen...
Georg G. schrieb: > Tim schrieb: >> mingw-gcc > > Mag sein. Aber nichts hält sich hartnäckiger als Software, mit der man > seit mehr als 10 Jahren problemlos arbeitet. > > Ich würde die typedefs auch anders machen, mit Typen aus stdint.h, also > nicht z.B. short int sondern int16_t. Ist defensiver. chris scheint K&R C zu programmieren, ich halte mich eher an Ansi-C90/C95. Was Du siehst ist eben der resultierende Mischmasch. Einige casts mit long long haben mir auch ziemliche Probleme bereitet. Werde ggf. den Source noch aufräumen, aber im Moment ist mir die Funktion wichtiger. Die int-typen sind wahrscheinlich C99?
Sensation! Obiges lag gerade in der Post. Die Nuvoton-Tools haben es als Nu-Link erkannt und die Software auf den neusten Stand gebracht. Es scheint sich also um einen kompatiblen Clone zu handeln. Jetzt müsste es nur wieder lieferbar sein... Ich bin mit dem Entschlüsseln des Protokolls auch entscheidend weiter gekommen. Später mehr.
Der SWD-Analyzer ist jetzt in der Lage, die meisten Logs komplett fehlerfrei zu interpretieren. Das heisst dass Reset- und Idle Sequenzen, sowie fehlerhafte Pakete (Start/Stop bit, Parity) korrekt identifiziert werden. Dabei hat sich übrigens auch herausgestellt, dass die vermutete Erase-Sequenz von oben in Wirklichkeit eine abgebrochene Reset-Sequenz ist. Die Reset-Sequenz des Nuvotons hat gegenüber der Spezifikation allerdings einen zusätzlichen Low-Zyklus auf der Datenleitung. Oben zum Vergleich ein Reset vom Nu-Link und ST-Link. Ob das einfach nur ein Bug, oder doch relevant ist, lässt sich noch nicht sagen. Die meisten der bisher geposteten Logs werden mit 0 erkannten Fehlern geparsed. Dieses ist recht beeindruckend, da das bedeutet dass das Log der Host-Kommunikation fast frei von Bitfehlern ist. Bei teilw. >8e8 Samples schons bemerkenswert. Leider gilt das nicht für die Rückmeldungen vom Target, die etliche Übertragungs- und Paritätsfehler enthalten. Ich werde hier wohl doch noch einmal an die HW müssen... Aktueller Stand hier: https://github.com/hackocopter/SWD-Hacking/tree/master/SWD-Analyzer
Tim schrieb: > s > scheint sich also um einen kompatiblen Clone zu handeln. Jetzt müsste es > nur wieder lieferbar sein... Wow, das hört sich ja wirklich toll an. Aber schade, dass der jetzt nicht mehr lieferbar ist. Ich glaube die Post wollte mir heute meinen Quad auch endlich bringen, bin gespannt auf morgen.
So, jetzt funktioniert der SWD-Analyzer. Es wird der komplette Datenverkehr ohne Bit- und Paritätsfehler geparsed. Erstaunlicherweise funktioniert das mit 16M Samplerate sogar noch bei 4Mhz SWD-Clock. https://github.com/hackocopter/SWD-Hacking/tree/master/SWD-Analyzer Ein nerviges Problem war die Gültigkeit der Daten vom Target. Es stimmt natürlich, dass diese bei der steigenden CLK-Flanke herausgeclocked werden. Durch die Gatterlaufzeit im Target, erscheinen die Daten natürlich verzögert am Ausgang, was im LA zu glitches führt. Was mich am Anfang verwirrt hat, ist dass die Daten bereits im vorhergehenden Taktzyklus herausgeclocked werden. Dafür gibt es die Turnaround cycles. Ich habe das Problem jetzt gelöst, in dem ich die Daten an der vorhergehenden fallenden Flanke einlese. Aus dem Timing sieht man, dass das Nu-link selbst wohl genau das gleiche macht. Ein Flip-Flop hätte auch funktioniert, wie Georg oben schon angemerkt hat. So, die Herausforderung besteht jetzt natürlich darin, die Chip-Erase Sequenz zu isolieren. Falls jemand mitpuzzeln will - ich habe hier ein paar Logs als Rohdaten und nach dem Parsen abgelegt: https://github.com/hackocopter/SWD-Hacking/tree/master/Nulink-Logs Ich habe bereits einen heißen Kandidaten für die Chip-Erase Sequenz identifiziert. Direkt nach dieser Sequenz ist der Chip nämlich für 140ms "tot" und wird über einen Registerzugriff und die Resetsequenz gepollt. Die Sequenz beginnt mit einem Reset. Möglicherweise handelt es sich daher also um den Relevanten Teil. Die höheren Ebenen des SWD-Protokolls wirken auf mich ziemlich wirr. Einen Masterplan scheint es beim Design nicht gegeben zu haben. Ich frage mich, welche Randbedingungen hier relevant waren. Der Zugriff auf die tatsächlichen Funktionsregister erfolgt zweifach indirekt, wie im Bild. Dies sind die besten SWD-Referenzen: http://sourceforge.net/apps/mediawiki/stm32primer2swd/index.php?title=Main_Page#SWD_Packet_Construction http://www.pjrc.com/arm/pdf/doc/ARM_debug.pdf
Geschafft! Ich habe die Chip-Erase Sequenz extrahieren können. Damit ist es jetzt möglich, den Microcontroller ohne Bu-Link/Bu-Link zu programmieren. Noch einmal vielen Dank an Robert für das zur Verfügung stellen des NU-Links. Und an chris, georg und die anderen für die Hilfe. Das ganze ist aber noch aufwändiger geworden als gedacht. Um mit der Datenflut etwas anfangen zu können, habe ich auch noch die derüber liegende Ebene, nämlich die Speicherzugriffe, geparsed. Der aktuelle Source ist hier: https://github.com/hackocopter/SWD-Hacking Durch den Vergleich von unterschiedlichen Logs habe ich die Chip-Erase-Sequenz finden können. Anbei das kommentierte Log der Sequenz. Der Relevante Teil ist unten. Eigentlich ist es recht einfach. Die Chip-Erase Sequenz wird natürlich über die Flash-Register kontrolliert. Es gibt anscheinend ein undokumentiertes Enable-Register (0x5000C01C) und einen Undokumentierten Befehl (0x26) für das ISP Command register.
1 | @3315.698313ms:Read Buf(0x5000c000)=0x00000032 ; ISP control |
2 | @3315.738438ms:Write BD (0x5000c000)=0x00000033 ; ISP Control=0x33 Set bit 1= Enable ISP function... really? |
3 | @3315.767938ms:Read Buf(0x5000c000)=0x00000000 |
4 | @3315.927375ms:Read Buf(0x5000c01c)=0x00000000 |
5 | @3315.967688ms:Write BD (0x5000c01c)=0x00000001 ; 0x5000C01C=1 Interesting. Undocumented register in Flash controller |
6 | @3315.997188ms:Read Buf(0x5000c01c)=0x04770021 ; Buffer after write - "unpredictable" |
7 | |
8 | @3316.156188ms:Read Buf(0x5000c000)=0x00000033 |
9 | @3316.232000ms:Read Buf(0x5000c000)=0x00000033 ; check ISPFF=0 |
10 | @3316.400563ms:Read Buf(0x5000c010)=0x00000000 ; ISP not busy? |
11 | @3316.527437ms:Write BD (0x5000c00c)=0x00000026 ; ISP Command=0x26. Undocumented combination. Enable page erase and program |
12 | @3316.556938ms:Read Buf(0x5000c00c)=0x04770021 ; Buffer after write - "unpredictable" |
13 | @3316.595000ms:Write BD (0x5000c004)=0x00000000 ; ISP Address=0x00000000 Start of APROM |
14 | @3316.624500ms:Read Buf(0x5000c004)=0x00000000 |
15 | @3316.748562ms:Write BD (0x5000c010)=0x00000001 ; ISP Trigger=1 -> Start ISP Operation |
16 | @3316.778125ms:Read Buf(0x5000c010)=0x00000000 ; First read is invalid? better replicate or trouble looms |
17 | @3316.852250ms:Read Buf(0x5000c010)=0x00000001 ; Operation is ongoing during ISP Trigger reads |
18 | |
19 | ... poll poll poll ... |
20 | |
21 | @3326.586938ms:Read Buf(0x5000c010)=0x00000001 |
22 | @3326.664813ms:Read Buf(0x5000c010)=0x00000001 |
23 | @3326.742625ms:Read Buf(0x5000c010)=0x00000001 |
24 | @3326.820500ms:Read Buf(0x5000c010)=0x00000001 |
25 | @3326.898375ms:Read Buf(0x5000c010)=0x00000000 ; and done. After ~10ms |
26 | @3327.060438ms:Read Buf(0x5000c000)=0x00000033 ; check ISPFF=0 |
:
Bearbeitet durch User
Die große Frage ist jetzt natürlich wie man das am besten Umsetzt. Weiss jemand, ob sich die Befehlssequenz z.B. über ein Script in Keil/OpenOCD/etc. abbilden liesse? Eine andere Möglichkeit wäre eine kleine SWD-Implementierung auf einem Microcontroller, die nichts anderes tut als zu überprüfen ob das richtige Device angeschlossen ist und ein chip erase durchzuführen. Im Vergleich zum parsen des Logs erscheint das fast trivial, aber diese Woche nicht mehr... :)
SWD ist übrigens ein ganz schreckliches Protokoll. Und das Nu-Link ist eine noch schlimmere Umsetzung davon -> Glitches, übles Timing und redundante Zugriffe.
Tim, könntest Du bitte mal erklären wie Du vorgegangen bist. Mit dem LA den Datenstrom aufzeichnen ist klar. Ich bin nur nicht durchgestiegen wie Du das Protokoll jetzt rekonstruiert hast. Muss jetzt nicht jedes kleinste Detail sein. Aber so ein paar Stichworte, für jemanden, der sich mit uC einigermaßen auskennt aber nicht mit Protokollanalyse, wären super.
Also bei Keil und dem JLink lassen sich Scripte eingeben mit Delay, Write/Read Register usw... Da die ST-Link ja abgespeckte J-Links sind denke ich mal es geht.. Was mich jetzt mal interessieren würde ist was sonst noch so in dem "versteckten" Register für Bits gesetzt werden können..!? Mein 2. Flattermaxe von Tonnse_mall ist heute angekommen! Edit: Würde mich auch mal interessieren..
:
Bearbeitet durch User
Den Bu-Link scheint es ja auch hier noch zu geben. Ich versteh nur das Kauderwelsch nicht. Meiner von aliexpress ist leider noch nicht da :-( Für 13 Euro http://de.imendit.com/item/bu-link-really-is-fully-compatible-with-the-nu-link-emulator-offline-download-full-version-12369014346.html Für 9 € http://de.imendit.com/item/the-the-bu-link-compatible-nu-link-emulator-full-version-offline-download-new-don-the-numicro-m0-16901419914.html
:
Bearbeitet durch User
@Tim: Womit hast Du den ChipErase jetzt durchgeführt, mit Nu-Link oder mit Bu-Link?
Antwort auf eine Anfrage an den Hersteller via AliExpress: "SUSAN LIU: Hi, yes, the bulink will be avaiable after Christmas holiday, the main IC is out of stcok now." ----- @ Oliver Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter" Das ist wirklich preiswert! Die Preise sind in Dollar.
No y. schrieb: > Mein 2. Flattermaxe von Tonnse_mall ist heute angekommen! Wann bestellt? Ich warte auch auf Post von denen.
Georg G. schrieb: > No y. schrieb: >> Mein 2. Flattermaxe von Tonnse_mall ist heute angekommen! > > Wann bestellt? Ich warte auch auf Post von denen. und gut drei Stunden nach dieser Mail war er auch hier. Und er fliegt sogar :-) Ich werde dann mal versuchen, die LCD Ansteuerung im Sender zu verstehen (sie ist aktiv).
So mein Quad ist heute auch von der Post geholt worden. Ich werde also nun auch etwas aktiver sein, hoffentlich :) Aber zu fliegen ist das Teil am Anfang ja wirklich schwer
Mal ne andere Frage: Ich hab meinen gerade auseinandergenommen und wieder zusammengeschraubt. Wie viele der Schrauben hatten denn danach bei euch noch richtig Biss?
Ich frag mich nur, was an dem Teil jetzt so doll sein soll, daß man so lange darauf wartet. Fliegt das Spielzeug jetzt nicht so schnell in die Ecke, wie die anderen Mini-Helis? Bei Aldi gibts jetzt einen für 24,95, sieht besser aus man kann ihn sogar gleich mitnehmen. Für ein paar Euro mehr gibts dann die 4-kanaligen, die dann genauso oder besser fliegen wie sonn Quad.
Quadrocopter weder im Süden noch im Norden: https://www.aldi-sued.de/de/angebote/technik-aktuell-im-verkauf/ http://www.aldi-nord.de/aldi_multimedia_aktuell_im_verkauf_5_1453.html
Erstmal ganz großes Lob und vielen vielen Dank für die tolle Arbeit!!! Tim schrieb: > Eine andere Möglichkeit wäre eine kleine SWD-Implementierung auf einem > Microcontroller, die nichts anderes tut als zu überprüfen ob das > richtige Device angeschlossen ist und ein chip erase durchzuführen. Haben die Jungs vom McHck nicht eine SWD implementierung gezimmert? Könnte eventuell als Grundlage dienen... https://github.com/mchck/mchck
Philipp E. schrieb: > Erstmal ganz großes Lob und vielen vielen Dank für die tolle Arbeit!!! > > Tim schrieb: >> Eine andere Möglichkeit wäre eine kleine SWD-Implementierung auf einem >> Microcontroller, die nichts anderes tut als zu überprüfen ob das >> richtige Device angeschlossen ist und ein chip erase durchzuführen. > > Haben die Jungs vom McHck nicht eine SWD implementierung gezimmert? > Könnte eventuell als Grundlage dienen... > https://github.com/mchck/mchck Es hindert dich niemand den Link von dir und die Infos von Tim zusammenzuführen.
Davis schrieb: > Es hindert dich niemand den Link von dir und die Infos von Tim > zusammenzuführen. Doch. Noch nicht angekommener Copter. Frau. Kinder. Job. Zeit...
:
Bearbeitet durch User
Ich habe den SWD-Analyzer noch einmal etwas überarbeitet. -C99 Datentypen eingeführt, Source aufgeräumt. -Verbose level lassen sich jetzt von der Commandozeile auswählen. -Parsing der AHB-Registerzugriffe verbessert. Dummy-Lesezugriffe werden jetzt nicht mehr angezeigt. https://github.com/hackocopter/SWD-Hacking Hier sind nach dem Parsing mit der neusten Version die notwendigen Zugriffe zum Chip-Erase:
1 | @3310.553875ms:Write BD (0xe000edf0)=0xa05f0003 <- Debug Halting Control Reg STOPRead Powercon. Oscillators enabled? |
2 | @3315.189313ms:Write BD (0x50000100)=0x00000059 ; Unlock registers with magic sequence |
3 | @3315.256750ms:Write BD (0x50000100)=0x00000016 |
4 | @3315.324187ms:Write BD (0x50000100)=0x00000088 |
5 | @3315.512938ms:Read Buf(0x50000200)=0x0000001c ; Read Powercon |
6 | |
7 | Erase sequence |
8 | @3315.698313ms:Read Buf(0x5000c000)=0x00000032 ; ISP control |
9 | @3315.738438ms:Write BD (0x5000c000)=0x00000033 ; ISP Control=0x33 Set bit 1= Enable ISP function... really? |
10 | @3315.927375ms:Read Buf(0x5000c01c)=0x00000000 |
11 | @3315.967688ms:Write BD (0x5000c01c)=0x00000001 ; 0x5000C01C=1 Interesting. Undocumented register in Flash controller |
12 | |
13 | @3316.156188ms:Read Buf(0x5000c000)=0x00000033 |
14 | @3316.232000ms:Read Buf(0x5000c000)=0x00000033 ; check ISPFF=0 |
15 | @3316.400563ms:Read Buf(0x5000c010)=0x00000000 ; ISP not busy? |
16 | @3316.527437ms:Write BD (0x5000c00c)=0x00000026 ; ISP Command=0x26. Undocumented combination. Enable page erase and program |
17 | @3316.595000ms:Write BD (0x5000c004)=0x00000000 ; ISP Address=0x00000000 Start of APROM |
18 | @3316.748562ms:Write BD (0x5000c010)=0x00000001 ; ISP Trigger=1 -> Start ISP Operation |
19 | @3316.852250ms:Read Buf(0x5000c010)=0x00000001 ; Operation is ongoing while ISP Trigger reads |
20 | |
21 | ... poll poll poll ... |
22 | @3326.742625ms:Read Buf(0x5000c010)=0x00000001 |
23 | @3326.820500ms:Read Buf(0x5000c010)=0x00000001 |
24 | @3326.898375ms:Read Buf(0x5000c010)=0x00000000 ; and done. After ~10ms |
25 | @3327.060438ms:Read Buf(0x5000c000)=0x00000033 ; check ISPFF=0 |
26 | |
27 | @3329.989687ms:Write BD (0x5000c000)=0x00000032 ; Disable ISP |
28 | @3330.178625ms:Read Buf(0x5000c01c)=0x00000001 |
29 | @3330.218938ms:Write BD (0x5000c01c)=0x00000000 ; Write 0 to undocumented register |
Dann will ich mich auch mal melden, meiner ist nun auch endlich angekommen. Bestellt hatte ich am 22.10.2013. Danke an den Threadstarter! Ich wäre auch noch an 1-3 stück interressiert, falls es eine Sammelbestellung gibt.
Robert Knipp schrieb: > könntest Du bitte mal erklären wie Du vorgegangen bist. Mit dem LA den > Datenstrom aufzeichnen ist klar. Ich bin nur nicht durchgestiegen wie Du > das Protokoll jetzt rekonstruiert hast. Muss jetzt nicht jedes kleinste > Detail sein. Aber so ein paar Stichworte, für jemanden, der sich mit uC > einigermaßen auskennt aber nicht mit Protokollanalyse, wären super. Prinzipiell sind solche Protokolle ja wie eine Zwiebel in mehreren Schichten aufgebaut. Ich habe mich dabei von der niedrigsten Protokollebene, dem Hardwarelevel immer weiter nach oben gehangelt. (Bzw. Chris hat den Anfang gemacht). Am besten schaust Du Dir den Source an: https://github.com/hackocopter/SWD-Hacking/blob/master/SWD-Analyzer/swd_analyzer.c 1) Konvertieren der Samplingdaten in einen Bitstream, der nur Daten auf steigenden und fallenden Flanken enthält. (macht getnextperiod()) 2) Einteilen des Bitstreams in interpretierbare Dateneinheiten. Dazu habe ich zunächst nur geschaut, ob sich gültige Befehle (Reset-Sequenz oder Read/write) im Bitsream befinden und wie lang diese sind. Das geschieht in der Hauptschleife. Dazu wird bei SWD- Lese- und Schreibzugriffen der Header ausgewertet (Bild). Wenn er gültig ist, werden die Daten interpretiert, sonst verforfen. 3) Interpretieren und übersetzten der SWD-Befehle (macht swd()). 4) Nachbilden des Memory Access Ports (Bild), um die SWD-Befehle in Schreib- und Lesezugriffe auf die Peripherie des Prozesseres zu übersetzen. Denn per SWD wird im Grunde nichts anderes gemacht, als den Prozessor anzuhalten und auf den Addressraum zuzugreifen. Leider geschieht das auf eine extrem umständliche Art. Es gibt z.B. drei unterschiedliche Möglichkeiten eine Speicherzelle auszulsen. Die Daten die auf den unteren Protokollebenen Interpreitert werden, kann der Analyzer auch ausgeben. (Kann mit mit -v x einstellen. --help zeigt eine Hilfe an).
No y. schrieb: > Also bei Keil und dem JLink lassen sich Scripte eingeben mit Delay, > Write/Read Register usw... Hast Du dazu eine Referenz, oder kennst Du selbst damit aus? Das wäre natürlich die beste Lösung, da Keil mit vielen SWD-Adaptern zurecht kommt. No y. schrieb: > Was mich jetzt mal interessieren würde ist was sonst noch so in dem > "versteckten" Register für Bits gesetzt werden können..!? Wahrscheinlich nur das eine, aber Du kannst damit ja mal herumspielen. > Mein 2. Flattermaxe von Tonnse_mall ist heute angekommen! Habe heute auch gerade einen von denen bekommen. Komisch, da ist wohl ein Container angekommen? Oliver Stellebaum schrieb: > Kauderwelsch nicht. > Meiner von aliexpress ist leider noch nicht da :-( > > Für 13 Euro > http://de.imendit.com/item/bu-link-really-is-fully-compatible-with-the-nu-link-emulator-offline-download-full-version-12369014346.html Das ist ein Taobao-Agent, der sie für Dich von www.taobao.com kauft und Dir zusendet. Dort werden auch einige Bu-Links angeboten. Auf den Preis kommen noch erhebliche Zusatzgebühren. Manuel Steiner schrieb: > Ich hab meinen gerade auseinandergenommen und wieder zusammengeschraubt. > Wie viele der Schrauben hatten denn danach bei euch noch richtig Biss? Eigentlich alle? "Nach fest kommt ab" usw. :) Philipp E. schrieb: > Haben die Jungs vom McHck nicht eine SWD implementierung gezimmert? > Könnte eventuell als Grundlage dienen... > https://github.com/mchck/mchck Hatte ich oben auch schon gepostet. Leider haben die nur die allerunterste Ebene im client implementiert, den Rest macht der PC. Prinzipiell würde es gar nicht so lange dauern, ein kleines Bitbang-SWD-Programm zum programmieren welches Chip-Erase macht - auf jeden Fall ist das weniger aufwändig als der Analyzer. Allerdings benötigt man sowieso noch einen Keil-kompatiblen SWD-Adapter für die Programmierung. Da wäre es einfacher, diesen über ein Script anzusteuern.
:
Bearbeitet durch User
Georg G. schrieb: > Ich werde dann mal versuchen, die LCD Ansteuerung im Sender zu verstehen > (sie ist aktiv). Es wäre natürlich praktischen, wenn man nur ein LCD anschließen müsste.
Entschuldigung ich muss mich korrigieren. Ein Script lässt sich in J-Flash zusammenklicken. Nicht Keil!! Hab mich da leider vertan. Ist schon länger her, dass ich da rumgesucht hatte. Bringt also nichts. Ich glaub selbst mit nem J-Link Edu bringt es nichts da keine J-Flash Lizenz dabei ist. Weiß daher nicht ob die Scripts ausgeführt werden oder ob zuerst der Lizenzfehler kommt. Werde ich demnächst mal ausprobieren.
No y. schrieb: > Entschuldigung ich muss mich korrigieren. > > Ein Script lässt sich in J-Flash zusammenklicken. Nicht Keil!! > Hab mich da leider vertan. Ist schon länger her, dass ich da rumgesucht > hatte. Also für mich sieht es aus, als wenn es mit den Debug Function im Menu Debug->Function Editor funktionieren könnte. Man kann damit functionen definieren, die Befehle wie _WWORD (0x20000, 123); beinhalten, mit denen man den Speicher des Targets beschreiben kann. Oder verstehe ich hier etwas falsch?
Es hat sich herausgestellt, dass es wirklich sehr einfach ist, mit "Functions" im KEIL Debugmodus eigene SWD-Sequenzen zu definieren. Mit dem Anhängenden Beispielprojekt lässt sich Chip-Erase jetzt mit jedem beliebigen SWD-Adapter an KEIL durchführen. Mit ST-Link funktioniert es wunderbar. Leider gibt es noch ein paar Probleme mit ST-Link und Keil. Mann kann programme Downloaden, aber nicht debuggen und ausführen. Woran es liegt weiss ich nicht. Evtl. hilft hier Versaloon usw. Kennt sich hier jemand aus? https://github.com/hackocopter/SWD-Hacking/tree/master/KEIL-Flashtools Hier nur kurz: -Es wird Keil µVision5 mit Legacy Device support benötigt. -Die Treiber für den SWD-Adapter sollten installisert sein. -Projekt im Anhang öffnen -Den richtigen SWD-Adapter auswählen. -In den Debug-modus gehen (1) -In der Command Zeile "INCLUDE Mini51flashtools.ini"+<enter> eingeben (2) -Jetzt erscheint ein Tool-Menu mit einigen neuen Funktionen. (3) _Mini51 ShowConfig_: Zeigt aktuelle configuration des controllers an. Hier am besten zuerst mal draufklicken. _Mini51 ChipErase_: Führt ein Chip-Erase durch, wenn der Chip gesperrt war. *ACHTUNG:* Dieser Befehl löscht die original Firmware ohne Sicherheitabfrage _Mini51 WriteStdConfig_: Beschreibt die Configurationsregister mit Standardwerten. Sollte nach dem Chip-Erase immer gemacht werden. _Mini51 Reset_: Selbsterklärend
:
Bearbeitet durch User
Tim schrieb: > Mit ST-Link funktioniert es > wunderbar. Na das kommt doch genau zum richtigen Zeitpunkt. Da mein Quad so lange auf sich warten hat lassen ist ja jetzt wirklich zu überlegen, ob sich die Anschaffung eines Nulinks noch lohnt. Eigentlich hab ich nicht vor, irgendwo anders Nuvoton MCUs zu verwenden. Ich denke Tim, aber auch allen die dabei geholfen haben, das möglich zu machen, gebührt mal wirklich ein Dankeschön.
Tim schrieb: > Mit > dem Anhängenden Beispielprojekt lässt sich Chip-Erase jetzt mit jedem > beliebigen SWD-Adapter an KEIL durchführen. Mit ST-Link funktioniert es > wunderbar. Super Arbeit! Klasse. Tolles reverse engineering und super Ergebnis! Tausend Dank!!! (PS: Vielleicht machst du nen Artikel bei dir im Blog daraus und schicks zu Hack a Day o. Ä., ist sicher auch für viele andere Interessant)
Gute Arbeit cpldcpu! Nach einem chip-erase (mit dem magic register) konnte ich meine alte Firmware wieder aufspielen und das Gerät läuft wieder!!! Besten Dank!
Jog3k schrieb: > Gute Arbeit cpldcpu! Nach einem chip-erase (mit dem magic register) > konnte ich meine alte Firmware wieder aufspielen und das Gerät läuft > wieder!!! Interessant! Du hattest den "Mold-King", oder? Welche Software hast Du für die Programmierung verwendet? Bei mir klappt es mit dem ST-Link noch nicht so gut. Philipp E. schrieb: > > Super Arbeit! Klasse. Tolles reverse engineering und super Ergebnis! > Tausend Dank!!! > (PS: Vielleicht machst du nen Artikel bei dir im Blog daraus und schicks > zu Hack a Day o. Ä., ist sicher auch für viele andere Interessant) Danke! :) Habe auch schon über einen Artikel nachgedacht, aber dafür muss ich auch erstmal die Zeit finden. Der Hackocopter hat mir diese Woche schon sehr viel davon gekostet...
Tim schrieb: > Interessant! Du hattest den "Mold-King", oder? Welche Software hast Du > für die Programmierung verwendet? Bei mir klappt es mit dem ST-Link noch > nicht so gut. Genau, MouldKing (in der Anleitung als X6 betitelt, auf dem Gehäuse steht M-1). Ich habe ein eigenes Programm geschrieben bzw. erweitert und verwende den stlink-v1 vom ersten Discovery. Ich werde den Code bei Gelegenheit gerne veröffentlichen. In meinem code.google.com repo habe ich auch ein script für openocd (allerdings habe ich nicht getestet ob das Programmieren damit funktioniert). Welche Probleme hast Du mit dem stlink? Beste Grüße!
>> Interessant! Du hattest den "Mold-King", oder? Welche Software hast Du >> für die Programmierung verwendet? Bei mir klappt es mit dem ST-Link noch >> nicht so gut. > > Genau, MouldKing (in der Anleitung als X6 betitelt, auf dem Gehäuse > steht M-1). Ich habe ein eigenes Programm geschrieben bzw. erweitert und > verwende den stlink-v1 vom ersten Discovery. Ich werde den Code bei > Gelegenheit gerne veröffentlichen. In meinem code.google.com repo habe > ich auch ein script für openocd (allerdings habe ich nicht getestet ob > das Programmieren damit funktioniert). > Welche Probleme hast Du mit dem stlink? > > Beste Grüße! Ich kann mit µVision über ST-Link auf den Mini54ZAN zwar programme hochladen, aber das Debuggen und Ausführen funktioniert nicht richtig. Verwendest Du die normale ST-Link Firmware und OpenOCD zum programmieren? Dein Programm wäre sicherlich für andere auch interessant.
:
Bearbeitet durch User
Tim schrieb: > Verwendest Du die normale ST-Link Firmware und OpenOCD zum > programmieren? Ja, die Firmware auf dem Discovery ist unverändert. OpenOCD hatte ich ausprobiert und beispielsweise das Auslesen des PDID Registers hatte funktioniert. Die anderen Funktionen konnte ich zu dem Zeitpunkt nicht testen, da das Gerät nicht richtig funktionierte. Nach einem kompletten "Device-Erase" (Danke nochmal für die Informationen) und dem Aufspielen der alten Firmware kann ich jetzt auch wieder mein "uarttest.bin" Programm ausführen und bekomme entsprechendes Feedback über die serielle Schnittstelle. Das habe ich jetzt aber wieder mit meinem eigenen Programm gemacht und nicht mit OpenOCD. > Dein Programm wäre sicherlich für andere auch interessant. Sobald der Code ordentlich aussieht und ich einige weitere Funktionen implementiert habe lade ich das Programm auf meinem code.google repo hoch.
Tim schrieb: > Ich kann mit µVision über ST-Link auf den Mini54ZAN zwar programme > hochladen, aber das Debuggen und Ausführen funktioniert nicht richtig. Kannst du dies etwas präzisieren? Was funktioniert und was funktioniert nicht?
Hubsy schrieb: > Tim schrieb: > >> Ich kann mit µVision über ST-Link auf den Mini54ZAN zwar programme >> hochladen, aber das Debuggen und Ausführen funktioniert nicht richtig. > > Kannst du dies etwas präzisieren? Was funktioniert und was funktioniert > nicht? Flash und Erase wird ohne Fehlermeldung durchgeführt. Nur das hochgeladene Programm (z.B. Blinky) wird anschließend nicht ausgeführt. Ebenso zeigt der Debug-Mode einen leeren Speicher. Entsperrt ist der Chip, denn das Programmieren geht mit dem Nu-Link wunderbar.
Tim schrieb: > Hubsy schrieb: >> Tim schrieb: >> >>> Ich kann mit µVision über ST-Link auf den Mini54ZAN zwar programme >>> hochladen, aber das Debuggen und Ausführen funktioniert nicht richtig. >> >> Kannst du dies etwas präzisieren? Was funktioniert und was funktioniert >> nicht? > > Flash und Erase wird ohne Fehlermeldung durchgeführt. Nur das > hochgeladene Programm (z.B. Blinky) wird anschließend nicht ausgeführt. > Ebenso zeigt der Debug-Mode einen leeren Speicher. Entsperrt ist der > Chip, denn das Programmieren geht mit dem Nu-Link wunderbar. Kannst du mit dem ST-Link und der "STM32 ST-LINK Utility" auf den Mini54ZAN zugreifen?
Hey, Ich wollte mal eben fragen ob dein Ladegerät mittlerweile fertiggestellt ist? Ich layoute gerade selber eins und bin mir ein bisschen unsicher mit der Verlustleistung des Chips. Wie sieht das bei dir aus?
Dominic A. schrieb: > Hey, > Ich wollte mal eben fragen ob dein Ladegerät mittlerweile fertiggestellt > ist? Ich layoute gerade selber eins und bin mir ein bisschen unsicher > mit der Verlustleistung des Chips. Wie sieht das bei dir aus? Ich habe leider den Chip noch nicht, habe aber von den PCBs ein paar verschenkt. Vielleicht kommt von da eher Rückmeldung. Ich habe mich an den Layoutvorschlag aus dem Datenblatt gehalten. Allerdings werde ich den Ladestrom sowieso eher gering einstellen, so dass ich nicht mit Wärmeproblemen rechne.
Hubsy schrieb: > Kannst du mit dem ST-Link und der "STM32 ST-LINK Utility" auf den > Mini54ZAN zugreifen? Das STM32 utitlity habe ich noch nicht ausprobiert. Aber da das Script von oben funktioniert, wird der genenrelle Zugriff möglich sein. Ich glaube eher, dass das ST-Linkt versucht irgendwelche Protokolleigenarten auszunutzen, die es nur auf dem STM32 gibt.
Die Bedienungsanleitung ist mir teilweise ein Buch mit 7 Siegeln. Leider sind meine Kenntnisse der chinesischen Sprache zu gering, das Original zu entziffern. Drei Punkte, die vielleicht jemand beantworten kann: - Was bewirkt der "Turning" Taster? Ist er nur für die Rollen gedacht? - Der letzte Punkt über "flying environment" beginnt mit "if the aircraft take-off not be vertical rise..." Was will der Autor uns sagen? Was soll die beschriebene Prozedur bewirken? - Beim Trimmen kommen mal lange, mal kurze Piepser. Was will das Gerät mir sagen? Lässt sich das Ding so trimmen, dass es wirklich auf der Stelle schwebt?
Tim schrieb: > Dominic A. schrieb: >> Hey, >> Ich wollte mal eben fragen ob dein Ladegerät mittlerweile fertiggestellt >> ist? Ich layoute gerade selber eins und bin mir ein bisschen unsicher >> mit der Verlustleistung des Chips. Wie sieht das bei dir aus? > > Ich habe leider den Chip noch nicht, habe aber von den PCBs ein paar > verschenkt. Vielleicht kommt von da eher Rückmeldung. Ich habe mich an > den Layoutvorschlag aus dem Datenblatt gehalten. Allerdings werde ich > den Ladestrom sowieso eher gering einstellen, so dass ich nicht mit > Wärmeproblemen rechne. Alles klar, ich denke ich bestelle auch einfach mal meine PCB's. Ich werde wahrscheinlich auch noch ein paar zu viele und hier vergeben. Da werde ich mich aber wieder melden wenn ich die Platinen habe. Kann also noch dauern. Georg G. schrieb: > - Was bewirkt der "Turning" Taster? Ist er nur für die Rollen gedacht? Mit ihm kann scheinbar auch eine Kalibrierung durchgeführt werden. Den Knopf drücken und beide Knüppel in die Linke untere Ecke ziehen. (Hat bei mir selber aber auch noch nie funktioniert) Edit: Doch es funktioniert. Man muss beide Knüppel in die linke untere Ecke ziehen und dann den Turningbutton gedrückt halten. Georg G. schrieb: > - Der letzte Punkt über "flying environment" beginnt mit "if the > aircraft take-off not be vertical rise..." Was will der Autor uns sagen? > Was soll die beschriebene Prozedur bewirken? In meinem Handbuch kann ich diesen Satz nicht finden. Bei mir stehen unter flying environment nur so Dinge wie z.B bei warmem Wetter fliegen und nicht fliegen wenn es windet. Georg G. schrieb: > - Beim Trimmen kommen mal lange, mal kurze Piepser. Was will das Gerät > mir sagen? Lässt sich das Ding so trimmen, dass es wirklich auf der > Stelle schwebt? Das habe ich mich auch schon gefragt. Jedoch habe ich dazu soeben noch etwas Interessantes im Handbuch gefunden. Scheinbar werden die Kalibierungseinstellungen in der Fernbedienung gespeichert. Den bei mir steht der Satz:"Press and Hold the speed conversation button while turning the power switch, Trimming the remote controller is reset" Also so wie ich das verstehe werden die Kalibrierungseinstellung gelöscht wenn man die Fernbedienung mit gedrücktem Speedbutton einschaltet. Vielleicht hängt das gepiepse irgendwie damit zusammen?
:
Bearbeitet durch User
Zur Fernbedienung: Bei mir piepst die Fernbedienung nur kurz, wenn ich die Trimmtaster betätige. Die Trimmung bleibt auch nicht erhalten. Nach jedem Einschalten tippe ich 2x zurück und 2x links, danach lässt sich der Copter zum Schweben bringen. Es sind aber permanente Eingriffe erforderlich, um den Copter in einem Raum von ca. 50 x 50 x 50 cm³ o. s. zu halten. Hauptproblem dabei ist die vertikale Steuerung des Copters. Sie ist einfach nicht fein genug, um auf einer Höhe zu schweben. Eine winzige Hebelbewegung entscheidet darüber, ob der Copter steigt oder sinkt. Ansonsten: Laut Keil kann der ULINK2 mit dem Mini54ZAN "arbeiten"[1]. Der ULINK2 selbst liegt mit ca. 11 Euro preislich beim Nu-/BuLink[2] und ist aber auch für andere Controller-Familien geeignet. Was haltet ihr davon? [1] http://www.keil.com/dd/chip/5587.htm [2] http://www.ebay.de/itm/Ulink-2-USB-JTAG-Emulator-ARM9-Cortex-Keil-Ulink-II-GH2-White-Adapter-Debug-DR-/300945296019
Für Fortgeschrittene kann ich den linken Taster sehr empfehlen! - Copter schweben lassen - linke taste 1x drücken - (linken Stick) nach rechts lenken und staunen wie agil der kleine in dem Modus ist ;) (zurück zum Anfängermodus nochmal drücken) Die Rechte Taste ist auch für Loopings gut: Copter auf >2m Höhe bringen und halten, dann gleichzeitig rechte Taste und (linken) Stick zb nach Rechts -> Copter macht ne Rolle ;) Das Höhe halten fand ich auch anfangs relativ schwer, dachte schon meiner sei kaputt... Es liegt aber am Piloten, drückt die Fernbedienung mal jemanden in die Hand der Heli fliegt... ;) Also weiter üben ;) Gruss, Simon
Kann man den linken Button nicht auch 2x hintereinander drücken und dann ist er noch agiler? Habe ich zumindest das Gefühl. Noch ein kleiner Tipp. Bei mir sind manchmal die Sticks hängen geblieben. Insbesondere in den Ecken. Das ist ziemlich mühsam. Bei mir lag es daran das die Knöpfe zu stark auf die Fernbedienung gedrückt haben. Als Lösung habe ich einfach die Fernbedienung aufgeschraubt und die 2 Schrauben in der oberen Ecke des PCB ein bisschen gelöst. Nun flutschen die Sticks zurück in die Mitte wie noch nie.
Dominic A. schrieb: > Kann man den linken Button nicht auch 2x hintereinander drücken und dann > ist er noch agiler? Habe ich zumindest das Gefühl. Stimmt schon, es sind drei Modi.
Georg G. schrieb: > - Beim Trimmen kommen mal lange, mal kurze Piepser. Was will das Gerät > mir sagen? Lässt sich das Ding so trimmen, dass es wirklich auf der > Stelle schwebt? Die langen Piepser ertönen, wenn das Trimming auf 0 eingestellt ist. Das Trimming bleibt übrigens nach dem Ausschalten der FB erhalten. (EEPROM?). Am besten nutzt man es gar nicht.
Davis schrieb: > Ansonsten: > > Laut Keil kann der ULINK2 mit dem Mini54ZAN "arbeiten"[1]. Der ULINK2 > selbst liegt mit ca. 11 Euro preislich beim Nu-/BuLink[2] und ist aber > auch für andere Controller-Familien geeignet. > > Was haltet ihr davon? > > [1] > http://www.keil.com/dd/chip/5587.htm > > [2] > http://www.ebay.de/itm/Ulink-2-USB-JTAG-Emulator-ARM9-Cortex-Keil-Ulink-II-GH2-White-Adapter-Debug-DR-/300945296019 Klingt gut. Chip erase wird es nicht unterstützen, aber das macht das Script oben.
Den Versuch, im FB Sender an den LCD Anschluss ein Display zu hängen werden wir beerdigen können. Es kommen - wie bereits geschrieben - abwechselnd drei Datenpakete, die sich bei Bedienung der Hebel und Taster ändern. Es ist aber kein Zusammenhang zwischen den Bytes und Bits und irgendwelchen Aktionen zu erkennen. Um weiter zu kommen, müssten wir einen Sender analysieren, der mit LCD ausgeliefert wurde.
Schade, dann ist die Datenausgabe evtl. einfach nur übrig gebliebener Code ohne richtige Funktion? Oder lässt sich zumindest erkennen dass die Ausgabe als Reaktion auf etwas erfolgt (Binding, Steuern, usw.)
Tim schrieb: > Oder lässt sich zumindest erkennen dass die > Ausgabe als Reaktion auf etwas erfolgt (Binding, Steuern, usw.) Die Ausgabe ändert sich, wenn man steuert. Es ist aber nicht so, dass eine Änderung der Betriebsspannung bestimmte Bits ändert (oder Binden oder Trimmung oder Bewegung der Knüppel). Beispiel: Drücken auf "trimmen roll rechts" ändert ein Byte permanent von 0x04 auf 0x0c. Anschließendes Drücken auf "trimm roll links" ändert es aber nicht zurück auf 0x04. Es geht zurück auf 0x04 bei "throttle 10%". Es ist alles irgendwie pseudozufällig und doch reproduzierbar.
Tim schrieb: > Schade, dann ist die Datenausgabe evtl. einfach nur übrig gebliebener > Code ohne richtige Funktion? Oder lässt sich zumindest erkennen dass die > Ausgabe als Reaktion auf etwas erfolgt (Binding, Steuern, usw.) Der "Frankfurter" Quadrocopter meldet sich bei der Fernbedienung an. Es erscheint ein "Lampensymbol" in der Anzeige. Zudem werden die Trim-Einstellungen und die Geschwindigkeit in Prozent angezeigt. Das ist beim Modell aus dem Eingangsbeitrag nicht der Fall. Hier kann das "Binding" auch ohne Copter durchgeführt werden. Ein Rückmeldung erfolgt optisch über die beiden blauen LEDs.
Auf meinen Bulink warte ich noch immer :-( Ob ich in der Zwischenzeit den Ulink2 bestelle? Was haltet ihr von diesem http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=130738049882 Magnetsensor? Könnte man damit einen autonomen Schwebeflug erzielen?
Also zum Thema ULink: Beitrag "CoLinkEX oder Segger J-Link EDU oder Ulink2" Und für ca. 11€ bekommt man auch ne 10DOF IMU in Ebay mit MS5611 die wahrscheinlich auch nicht viel größer ist als die verlinkte.
Oliver Stellebaum schrieb: > Könnte man damit einen autonomen Schwebeflug erzielen? Für die Höhe brauchst du einen Höhensensor, barometrisch oder Ultraschall oder Laser oder Radar. Für die anderen zwei Koordinaten hilft dir der Magnetsensor auch nur begrenzt, weil das Magnetfeld sich über wenige Meter nicht merkbar ändert. Du kannst nur die Richtung der Nase damit stabilisieren.
Vielleicht kann man eine optische Maus so modifizieren, daß sie den Bewegungsvektor über Boden ausgibt (statt über Mousepad)?
Für die Höhenstabilisierung bietet sich ein Drucksensor an. Ich habe mir mal einen BMP180 bestellt, der einer der besten Sensoren am Markt zu sein scheint: http://www.ebay.de/itm/1PC-BMP180-Digitale-Luftdruck-Sensor-Brett-Modul-fur-Arduino-/271336856744 Bis das mit der Software funktioniert ist es aber noch ein weiter weg .)
batman schrieb: > Vielleicht kann man eine optische Maus so modifizieren, daß sie den > Bewegungsvektor über Boden ausgibt (statt über Mousepad)? Ich glaube nicht, dass das mit mehr als wenigen mm Abstand noch funktioniert.
Stichwort: modifizieren Es gibt durchaus Linsen, die die Brennweite der Optik verändern - quasi eine Brille für die Maus.
Wenn man dem kleinen Ding dann noch eine zusätzliche Schubdüse verpasst könnte er mit der Mouse unten drunter auch abheben :-)
Und wenn man mit Kamera fliegen will, braucht man ja ne 3-stufige Rakete. ;)
Heute ist mein original Hubsan angekommen. Da ist eine Schutzschaltung mit DW01 im Ladekabel. Schaltung scheint ziemlich exakt nach Datenblatt zu sein. Ist sicherlich nicht der Weißheit letzter Schluss, aber schon besser als beim Billig-Hubsan. Allerdings ist die Steuerung der "Flips" doof gelöst. Man muss erst in eine Richtung drücken und danach schnell in die andere Wechseln um einen Flip aus zu führen. Immer wenn man keinen Flip machen will macht er einen und wenn man einen machen will funktioniert's nicht :( Außerdem sackt er nach dem Flip noch viel stärker weg als der Billig-Hubsan.
Bevor dieser Thread hier vollkommen in der Versenkung verschwindet gebe ich bekannt dass mein bestellter Bu-Link endlich angekommen ist. Erschwerend kam hinzu, das nicht mein Name sondern nur mein Aliexpress-Name auf dem Umschlag stand. Ich konnte dem Postmann aber glaubhaft versichern das ich der rechtmäßige Empfänger bin :-) So, bald sind Weihnachtsferien, hoffe ich komme dann dazu, mir eine Testumgebung aufzubauen.
Ich habe mich gerade noch einmal wieder dran gesetzt. Eine positive Sache: Das Programmieren und Debuggen mit ST-Link funktioniert. Ich weiss nicht was letztes mal schief ging. Das heisst, dass sich der Hack-O-Copter mit jedem Discovery-Board entsperren und programmieren lässt. Ich werde jetzt noch versuchen das Flash tool zu erweitern, um den Bootloader einzuspielen. Auch wenn SWD für das Debugging praktisch ist, ist ein serieller Bootloader einfacher in der Handhabung
:
Bearbeitet durch User
Tim schrieb: > Das heisst, dass sich der Hack-O-Copter mit jedem Discovery-Board > entsperren und programmieren lässt. > > Ich werde jetzt noch versuchen das Flash tool zu erweitern, um den > Bootloader einzuspielen. Auch wenn SWD für das Debugging praktisch ist, > ist ein serieller Bootloader einfacher in der Handhabung Nice work :) Big thx. Leider stresst die Uni in letzter Zeit ziemlich :(
Ein wenig Off-topic, aber: Weiß jemand wie die Stecker für die Akkus heisen, bzw. wo man diese Kaufen kann. Ich würde mir gerne für meinen IMAX B6 ein Ladekabel mit Balancer anschluss bastel, damit ich mehrer Akkus in einem Ladevorgang geladen bekomme. THX
Genau dasselbe habe ich auch gemacht. Bei Ebay gehen die Stecker unter "Walkera Stecker".
ARM-Fan schrieb im Beitrag #3452604: > Bei Ebay gehen die Stecker unter "Walkera Stecker". Wie alles, was nach Modellbau riecht, leider wieder völlig überteuert. Bei den Preisen ist es ja billiger, sich die Stecker von den Ladegeräten abzuschneiden?
Tim schrieb: > Ich werde jetzt noch versuchen das Flash tool zu erweitern, um den > Bootloader einzuspielen. Auch wenn SWD für das Debugging praktisch ist, > ist ein serieller Bootloader einfacher in der Handhabung Ich war bisher noch nicht erfolgreich, werde aber jetzt noch einmal einen anderen Ansatz probieren. Mein Ziel ist, dass man den Copter im zugeschraubten Zustand mit dem seriellen Bootloader programmieren und debuggen kann. Nur dann lässt sich bequem eine neuen Software entwickeln. Hat jemand eine gute idee, wie man einen Stecker auslegen könnte? Der serielle Port ist direkt neben einem "Auge". Darüber könnte man dünne Kabel herausführen. Dann würde man nur noch einen günstigen, beschaffbaren und kleinen Steckverbinder benötigen.
Bin ein wenig skeptisch, ob das so eine gute Idee ist, einen Bootloader in den Copter zu flashen. Der Copter hat nur 16 KBytes Flashspeicher, der ohnehin schon knapp bemessen ist, aber dann noch einen Bootloader oben drauf? Vorschlag: Während der Entwicklung das Oberteil des Coptergehäuses abnehmen oder ausfräsen, eine Buchse in die vorhandenen Löcher einlöten, debuggen & freuen.
Davis schrieb: > Bin ein wenig skeptisch, ob das so eine gute Idee ist, einen > Bootloader > in den Copter zu flashen. Der Copter hat nur 16 KBytes Flashspeicher, > der ohnehin schon knapp bemessen ist, aber dann noch einen Bootloader > oben drauf? Davis, Du scheinst ja der Bootloaderfeind allgemein zu sein :) Der Mini54ZAN hat 2kb dedizierten Flash-Speicher für den Bootloader (LPROM), die sich für gar nichts anderes nutzen lassen. Es gibt von Nuvoton einen fertigen Bootloader, der auch von deren Host-Software unterstützt wird. Man verliert von den 16kb also kein einziges Byte. Clever wäre es natürlich, wenn man einen Bootloader programieren könnte, der im LDROM sitzt und Updates über den Funkchip zulässt. Ich würde da aber erst einmal auf dem Boden bleiben :)
Tim schrieb: > Davis schrieb: >> Bin ein wenig skeptisch, ob das so eine gute Idee ist, einen >> Bootloader >> in den Copter zu flashen. Der Copter hat nur 16 KBytes Flashspeicher, >> der ohnehin schon knapp bemessen ist, aber dann noch einen Bootloader >> oben drauf? > > Davis, Du scheinst ja der Bootloaderfeind allgemein zu sein :) Jetzt hast du mich ertappt :) > Der Mini54ZAN hat 2kb dedizierten Flash-Speicher für den Bootloader > (LPROM), die sich für gar nichts anderes nutzen lassen. Es gibt von > Nuvoton einen fertigen Bootloader, der auch von deren Host-Software > unterstützt wird. Man verliert von den 16kb also kein einziges Byte. Muss mich doch ein wenig in den Chip "einlesen". > Clever wäre es natürlich, wenn man einen Bootloader programieren könnte, > der im LDROM sitzt und Updates über den Funkchip zulässt. Ich würde da > aber erst einmal auf dem Boden bleiben :) "Auf dem Boden bleiben", ist der richtige Ausdruck. Du machst einfach zu viele Baustellen auf. Nachdem es mit dem ST-Link funktioniert, spricht nichts dagegen diesen für die Entwicklung zu verwenden.
Ööm, gibts irgendwo eine Doku für interessierte Anfänger, welches Kabel wo dran kommt und welche Software man verwendet? Ich komme aus der Anwendungsprogrammierung, habe schon ein wenig Atmel gemacht aber ansonsten noch nicht viel.
Oliver Stellebaum schrieb: > Ööm, gibts irgendwo eine Doku für interessierte Anfänger, welches Kabel > wo dran kommt und welche Software man verwendet? Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter" https://github.com/hackocopter/Documentation
So, dsa Programmieren des Bootloaders funktioniert, der Bootloader selbst nicht. Vermutlich liegt das daran, dass er auf die andere Konfiguration der seriellen Schnittstelle konfiguriert ist. Ich werde es erst einmal sein lassen und einen Wireless-Bootloader ganz unten auf die Prioliste setzen.
:
Bearbeitet durch User
Oliver Stellebaum schrieb: > Ööm, gibts irgendwo eine Doku für interessierte Anfänger, welches Kabel > wo dran kommt und welche Software man verwendet? Leider gibt es noch keine übersichtliche Anleitung für den Einstieg. Ich werde versuchen, dass in der nächsten Zeit zu ändern und den Wiki-Artikel auf Vordermann zu bringen. Die nötigen Informationen sind im Moment über die Thread verstreut. Die wesentlichen Unterliegen liegen im Repository, wie von Davis verlinkt. 1) Du musst den SWD-Port mit deinem SWD Adapter verbinden. 2) Als Software eignet sich die freie Version von Keil µVision 5. Du musst zusätzliche den "Legacy device support" installieren. 3) Anleitung zum Freischalten des Microntrollers hier (Chip Erase): Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter" 4) Beispielprojekte hier: https://github.com/hackocopter/Examples
:
Bearbeitet durch User
Die guten Angebote für den JXD385 werden immer spärlicher. Hier ist noch ein relative günstiges: http://www.ebay.de/itm/Mini-6-Axis-4-Channels-2-4GHZ-Gyro-Flying-UFO-RC-Helicopter-Aircraft-Red-Black-/161119365976
:
Bearbeitet durch User
Nun ja, also bei ob jetzt 21€ oder 25€. Ist immernoch verdammt günstig. Ansonsten erst nach Weihnachten kaufen, ist ja nicht mehr lange. Dann wird's sicherlich auch wieder günstiger ;)
Studentle schrieb: > Nun ja, also bei ob jetzt 21€ oder 25€. Eben nicht. Wenn Ebay 25,25 schreibt, dann errechnet PayPal um die 26,50. Und das ist nun wirklich zuviel für die Freigrenze der Einfuhr-Umsatzsteuer. Dann sind es nämlich knappe 32 Euro. Und nein, bitte keine Spenden an mich, ich brauche derzeit keinen weiteren Copter... ;-) Studentle schrieb: > Ansonsten erst nach Weihnachten kaufen, ist ja nicht mehr lange. Dann > wird's sicherlich auch wieder günstiger Damit könntest Du völlig recht haben, das sehe ich auch so. Ist mir aber momentan mangels Bedarf nicht so wichtig... ...
Ich hab gerade einen Motor wiederbelebt, in dem ich die Achse mit Gewalt und zwei Kombizangen rausgezogen hab, falls das jemand etwas hilft.
Ich wünsche hier mal allen, die so fleißig an dem Thema dran sind oder daran interessiert sind, oder auch nur einfach ab und zu mal wieder mitlesen, frohe Weihnachten und Festtage.
:
Bearbeitet durch User
Tim schrieb: > ARM-Fan schrieb im Beitrag #3452604: >> Bei Ebay gehen die Stecker unter "Walkera Stecker". > > Wie alles, was nach Modellbau riecht, leider wieder völlig überteuert. > Bei den Preisen ist es ja billiger, sich die Stecker von den Ladegeräten > abzuschneiden? gibt es hier billiger http://www.ebay.com/itm/Walkera-3-7v-Walkera-lipo-battery-plug-x-6-extra-long-/321270125203?pt=Radio_Control_Parts_Accessories&hash=item4acd311293 http://www.ebay.com/itm/Walkera-Charge-Lead-for-Walkera-3-7v-Battery-plug-x-6-/221332983760?pt=Radio_Control_Parts_Accessories&hash=item3388794fd0
:
Bearbeitet durch User
Für die, die nur entwickeln wollen: http://www.tmart.com/JXD-385-004-PCB-Board-Receiver-for-RC-Helicopter-Green_p192103.html
Ich habe noch einmal bei einigen chinesischen Händlern nachgebohrt. Inzwischen erscheint es mir realistisch, den Copter ohne Fernbedienung für ~10EUR pro Stück zu importieren, wenn eine entsprechende Stückzahl abgenommen wird. Unverhandelte Angebote liegen zwischen 9.6-11 USD. Dazu kommen noch Einfuhrumsatzsteuer, Zoll und Versand. Besteht an so einer Aktion noch Interesse? Dazu müsste sich eine Anzahl von Leuten finden, mehr als 5 Stück abnehmen wollen. Sonst lohnt sich der logistische Aufwand nicht. Ich wäre auch gerne Bereit, die Kontakte weiter zu geben, wenn Torsten oder jemand anderes das Thema wieder aufnehmen will.
p.s.: Ich bin im Moment am Thema Dokumentation dran. Nach Neujahr werde ich wieder etwas mehr Zeit haben.
Tim schrieb: > Ich bin im Moment am Thema Dokumentation dran. Hast du jetzt eigentlich schon mal eine neue Firmware geflasht um z.B. die LEDs blinken zu lassen oder so?
Marius S. schrieb: > Hast du jetzt eigentlich schon mal eine neue Firmware geflasht um z.B. > die LEDs blinken zu lassen oder so? Ja, diese hier: https://github.com/hackocopter/Examples
@cpldcpu Ich hätte Interesse an einem Paket. Wenn's soweit ist, einfach eine PM schicken.
Wenn hier die Entwicklung/Hackung so weitergeht würde ich auch 50€ für 5 Stück investieren um zukünftig einen Schwarm loszulassen. http://www.youtube.com/watch?v=YQIMGV5vtd4 Ist sowas utopisch oder kann man sowas mit wenig hardwareaufwand realisieren? Luftdrucksensor? Magnetometer? Viel Zuladung verkaftet der Kleine sicher nicht.
:
Bearbeitet durch User
Ein Link für viel Information zum Thema Quadcopter Software und Theorie (meist AVR, aber als Anregung dennoch gut): https://github.com/googl1/therminator
Wegen Copter Bestellung, ist auch eine Fernsteuerung mitbestellbar ? Bin dabei.
Auch ich kann natürlich zu einer Bestellung nicht "Nein" sagen... bin zwar noch mit "einfliegen" beschäftigt... aber egal... wann, wo, was ??? bin dabei :O)
Hab hier schon einen geschrottet, macht aber gut Laune. Demzufolge würde ich mich für mind. 5 Stück zu diesem Preis interessieren :) Viele Grüße, guten Rutsch und ein gesundes neues Jahr @all
Hallo Zusammen, brauche geballtes Wissen für einen Hardwarehack! Weil die Batteriewarnung durch die nach vorne gerichtete LEDs und bei Tageslicht immer nur sehr schlecht wargenommen werden kann, habe ich mir etwas besser überlegt: Anstatt oder zusätlich zu den LEDs noch einen kleinen Buzzer mit an den Port P0.0 zu hängen. Dieser mit einem P-Kanal oder PNP Transistor angesteuert wird (siehe Anhang). Wenn nun die LEDs anfangen zu Blinken ertönt auch gleichzeitig ein akustisches Signal. Nun bin ich auf der Suche nach einem passen Buzzer. Bisher habe ich nur kleine SMD Buzzer ohne interene Ansteuerung gefunden: z.B.: KSSG13J12-N oder PKLCS1212E4001-R1 Kennt jemand einen SMD Buzzer < 10x10x3mm mit interner Ansteuerung? Alternativ eine möglichst leichte externe Ansteuerung? Was ich bisher gefunden habe wäre z.b. dieser hier: LTC1799 + Transistor. THX
B. G. schrieb: > Wenn nun die LEDs anfangen zu Blinken ertönt auch gleichzeitig ein > akustisches Signal. Interessante Idee. Die LEDs auf der Vorderseite kann man wirklich schlecht erkennen. Eigentlich könnte man doch auch einfach eine LED auf die Rückseite verlegen? Auf der Platine sind sogar ungestückte Lötpads dafür vorgesehen. B. G. schrieb: > Kennt jemand einen SMD Buzzer < 10x10x3mm mit interner Ansteuerung? Leider nein.
Ich habe heute endlich den LiPO-Charge zusammengebaut. Die Teile sind erst kurz vor Weihnachten angekommen. Dabei ist mir leider aufgefallen, dass ich die Polarität des USB Steckers vertauscht habe. (Oder war das Absicht?! Mir fällt kein Grund ein). Daher muss man den USB-Stecker auf die Unterseite montieren. Es passt aber trotzdem noch alles in das Originalgehäuse - siehe Bild. Es wird gerade der erste Akku geladen. So weit scheint alles zu funktionieren.
Youtube-Video "A Swarm of Nano Quadrotors" Oliver Stellebaum schrieb: > Ist sowas utopisch oder kann man sowas mit wenig hardwareaufwand > realisieren? Nur mit Intertalsensoren ist es bestimmt schwierig, eine so genaue Positionskontrolle hinzubekommen. In dem Video wird ja anscheinen auch eine Positionsbestimmung über Kameras genutzt.
:
Bearbeitet durch User
Zur Sammelbestellung: Super, dass es doch schon so viele Interessenten gibt. Mich haben auch einige der Händler noch einmal kontaktiert. Bei mir sieht es im Moment Zeitlich nicht ideal aus. Ich würde daher eher die Zeit nach Chinese New Year für eine Sammelbestellung anpeilen. (Ende Februar oder März).
Ich habe bei meinem Hack-O-Copter jetzt den SWD-Port und den seriellen Port nach draussen geführt. Dazu habe ich einfach Stiftleisten mit Sekundenkleber an das Gehäuse geklebt. Es gibt zwischen den Schalenhäften einen Bereich mit einer Lücke, durch die sich dünne Leitungen legen lassen. Eine ziemliche Murkslösung, dafür aber einfach umsetzbar - und es funktioniert.
Georg G. schrieb: > Ein Link für viel Information zum Thema Quadcopter Software und Theorie > (meist AVR, aber als Anregung dennoch gut): > https://github.com/googl1/therminator Danke für den Link. Das sieht sehr interessant aus.
B. G. schrieb: > Nun bin ich auf der Suche nach einem passen Buzzer. Bisher habe ich nur > kleine SMD Buzzer ohne interene Ansteuerung gefunden: > > z.B.: KSSG13J12-N oder PKLCS1212E4001-R1 > > Kennt jemand einen SMD Buzzer < 10x10x3mm mit interner Ansteuerung? Das ist eher unüblich, da die kleinen Teile meist auf Boards verlötet werden und es dort kein Problem ist die Ansteuerung flexibel selbst zu gestalten. Die Dinger mit integrierter Ansteuerung sind eher die, die man mit Kabeln irgendwo extern dranmacht oder die kleinen Sirenen bei denen es auf Lautstärke ankommt. > Alternativ eine möglichst leichte externe Ansteuerung? > > Was ich bisher gefunden habe wäre z.b. dieser hier: LTC1799 + > Transistor. So genau muß die Frequenz ja nicht sein, da brauchst Du keine 2,39 EUR für so ein Teil ausgeben. Einfach ein 74LVC2G14 als astabilen Multivibrator beschalten. Alternativ, aber natürlich nicht so schön klein: 74AC14. Die Frequenz kannst Du dann über R und C einstellen. Der kann von sich aus 24mA treiben, wenn es nicht zu sehr auf Lautstärke ankommt brauchst Du gar keinen extra Transistor mehr. Oder natürlich der allseits beliebte 555, der sollte den Buzzer auch treiben können.
:
Bearbeitet durch User
Kleines Update zum LiPO-Charger: Ich habe mit ihm einem Turnigy-Akku, wie oben vorgestellt Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter", geladen. Bei 2C Ladestrom wurde das Ladeende korrekt erkannt und der Akku hat sich nicht aufgebläht o.Ä., was bei dem mitgelieferten Ladegerät leider passiert.
Danke für die Antworten... Sagen wir mal so, ich bin einfach auf der Suche nach einer leichteren und kompakteren Lösung als so ein Monster: http://such002.reichelt.de/index.html?ACTION=3;ARTICLE=35924;SEARCH=SUMMER%20CPM%20121 Ein 74LVC2G14 anstatt des LTC1799 ist eine gute Idee, wobei der Bauteilaufwand wieder steigt. Der 555 wäre dann schon ein wenig groß. Eine kleine PCB mit 0,8mm Stärke wird dann fast unumgänglich. Hätte jemand Interesse an einer entsprechenden Lösung? Hat schon jemand die "Rücklichter" Nachgerüstet? Also passende LEDs sollte ich noch in der Bastelkiste haben, nur ob ich 0805 Widerstände auf die Footprints für die Vorwiderstände bekomme^^ Außerdem habe ich am Wochenende meinen 808 #16 clone zerlegt und unter den Kopter gehängt. Leider fällt beim Fliegen die Akkuspannung zu sehr und die Cam schaltet sich gleich wieder ab. Also nur mit eigenständigem Akku möglich. Kann bei Bedarf noch ein Paar Bilder vom Umbau liefern... Gerd E. schrieb: > B. G. schrieb: >> Nun bin ich auf der Suche nach einem passen Buzzer. Bisher habe ich nur >> kleine SMD Buzzer ohne interene Ansteuerung gefunden: >> >> z.B.: KSSG13J12-N oder PKLCS1212E4001-R1 >> >> Kennt jemand einen SMD Buzzer < 10x10x3mm mit interner Ansteuerung? > > Das ist eher unüblich, da die kleinen Teile meist auf Boards verlötet > werden und es dort kein Problem ist die Ansteuerung flexibel selbst zu > gestalten. Die Dinger mit integrierter Ansteuerung sind eher die, die > man mit Kabeln irgendwo extern dranmacht oder die kleinen Sirenen bei > denen es auf Lautstärke ankommt. > >> Alternativ eine möglichst leichte externe Ansteuerung? >> >> Was ich bisher gefunden habe wäre z.b. dieser hier: LTC1799 + >> Transistor. > > So genau muß die Frequenz ja nicht sein, da brauchst Du keine 2,39 EUR > für so ein Teil ausgeben. > > Einfach ein 74LVC2G14 als astabilen Multivibrator beschalten. > Alternativ, aber natürlich nicht so schön klein: 74AC14. > > Die Frequenz kannst Du dann über R und C einstellen. Der kann von sich > aus 24mA treiben, wenn es nicht zu sehr auf Lautstärke ankommt brauchst > Du gar keinen extra Transistor mehr. > > Oder natürlich der allseits beliebte 555, der sollte den Buzzer auch > treiben können.
B. G. schrieb: > Hat schon jemand die "Rücklichter" Nachgerüstet? Also passende LEDs > sollte ich noch in der Bastelkiste haben, nur ob ich 0805 Widerstände > auf die Footprints für die Vorwiderstände bekomme^^ Ich habe es noch nicht probiert, aber man könnte prinzipiell die noch fehlenden Bauteile bestücken. Dann kann man die LEDs über einen Transistor mit P5.2 ansteuern. Alternativ kann man die LEDs natürlich auch parallel zu den "Rücklichtern" schalten.
@cpldcpu Danke nochmals für die Mühe das Bild neu zu beschriften. Hattes es hier ja auch schon mal beschreiben: Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter" Die LEDs sind 0603, die Widerstände sind 0402. Hast du mal ein Oszi an den Pin 13 gehalten und gemessen ob dieser überhaupt geschalten wird? Ansonsten habe ich morgen ein wenig Zeit, dann kann ich das an meinem mal tun.
B. G. schrieb: > Hast du mal ein Oszi an den Pin 13 gehalten und gemessen ob dieser > überhaupt geschalten wird? > > Ansonsten habe ich morgen ein wenig Zeit, dann kann ich das an meinem > mal tun. Habe ich bisher noch nicht gemacht. Wenn es auch mit der bestehenden Firmware funktionieren soll, wäre es wohl am sichersten, Die LEDs mit Pin 26 zu verbinden.
Oh Tannenbaum Ich habe einen pnp an dem - der blauen led gemacht die wießen led mit 100ohm an den Akku, die roten und gelben blinken wenn der akku leer ist und die weißen leuchten dauerhaft
Turbonator schrieb: > Oh Tannenbaum > Ich habe einen pnp an dem - der blauen led gemacht die wießen led mit > 100ohm an den Akku, die roten und gelben blinken wenn der akku leer ist > und die weißen leuchten dauerhaft Gratuliere zum Projekt und zur Orthografie.
Turbonator schrieb: > 100ohm an den Akku, die roten und gelben blinken wenn der akku leer ist > und die weißen leuchten dauerhaft Schick! Gefällt mir. Wie hast Du das ganze verkabelt?
Mit Kupferlackdraht ,durch die schlitze der Motorhalterung die obere Seite an der auch die Platine hängt. Ich hatte leider keine SMD Widerstände und Transistoren das sieht komisch aus ^^ bc559c
Angriff der Monsterbauteile! Das sieht schon ziemlich extrem aus :)
Bitte nicht aufregen wegen den unsauberen löt arbeiten das ist zur zeit mein Lötkolben
Sieht richtig gut aus. Eventuelle mach ich das bei meinem auch. Tim schrieb: > Angriff der Monsterbauteile! Das sieht schon ziemlich extrem aus :) Und der riesen Bilder. Turbonator schrieb: > Bitte nicht aufregen wegen den unsauberen löt arbeiten das ist zur zeit > mein Lötkolben Falsches Bild erwischt? Ich dachte du willst ein Bild von deinem Lötkolben zeigen =).
haha Das ist schlecht mit den großen Bildern und war auch nicht meine Absicht wieso sind die Bilder kleiner wenn ich die direkt vom Handy hochlade und so groß wenn ich das Handy am pc und mit dem pc hochlade ?
Turbonator schrieb: > Passiert hier nichts mehr ? Nö, fliegt doch super :) Aber jetzt wird es etwas zu kalt, da frieren mir immer die Finger an der Funke fest :-(
Ja ist schon etwas frostig! Wie ist das mit den akkus besser nach dem gebrauch, direkt laden oder kann ich die nach gebrauch ruig 1-3 wochen wegpacken ?
Marius S. schrieb: > Aber jetzt wird es etwas zu kalt, da frieren mir immer die Finger an der > Funke fest :-( Dann ist ja eigentlich mehr Zeit um das Ding auf dem Seziertisch zu analysieren und rauszufinden, wie man es neu programmieren kann.
Oliver Stellebaum schrieb: > Dann ist ja eigentlich mehr Zeit um das Ding auf dem Seziertisch zu > analysieren und rauszufinden, wie man es neu programmieren kann. Funktioniert doch schon? Fehlt nur noch vernünftiger Source Code :P
Source code gibt es schon, und zwar Bradwii: https://github.com/bradquick/bradwii Davon gibt es auch bereits einen Cortex-Port https://github.com/trollcop/bradwii Ich habe auch schon einmal versuchsweise überflüssige Features herausgeworfen und den Source damit auf unter 16kb bringen können. Es muss nur die Fernbedienung und die PWM-Ansteuerung neu programmiert werden. Mein Plan war bisher, die Dokumentation etwas aufzuräumen und eine englische Anleitung zum flashen zu erstellen, damit sich vielleicht von den Bradwii-Leuten auch jemand für das Projekt gewinnen lässt: http://www.rcgroups.com/forums/showthread.php?t=1922403 Bei mir hat im Moment leider noch ein anderes Projekt vorrang und es sieht mit der Zeit nicht mehr so doll aus. Ich arbeite aber langsam eins nach dem anderen ab.
:
Bearbeitet durch User
Basierend auf dem Thread hab ich mir auch ein Exemplar gekauft mit der Idee ihn zu erweitern. Aber bis dahin, was tut eigentlich der "Turning Button"? Das versprochene Manual fehlte in meiner Packung leider und im Netz finde ich es auch nicht. Hinter die Funktion des "Speed Button" bin ich selbst gekommen.
Fleig mal 4m übern Boden und schwebe still... Dann Drück den Turning Button und schieb den linken Stick in eine beliebige Richtung(vorne, hinten, links,rechts) und schau was passiert...
Hallo Leute, ich wollte mich an einem Empfänger für die Fernbedienung versuchen und nach viel studieren hab ich inzwischen gefunden, dass das BIND-Paket wohl auf Kanal 8 übertragen wird. Zumindest initialisiert die Deviation Firmware den RF_CH auf 8. Jetzt kommts aber. Ich erhalte vielleicht alle paar Minuten ein Paket aber immer mit einer anderen TX_ID Weiß vielleicht jemand woran das liegen kann? Probehalber hab ich das mit dem Arduino probiert.
1 | ...
|
2 | uint8_t data[16]; |
3 | ...
|
4 | if(Mirf.dataReady()) |
5 | {
|
6 | Serial.println(F("\r\n#############################")); |
7 | Serial.println(F("## Packet received ##")); |
8 | Serial.println(F("#############################")); |
9 | |
10 | Mirf.getData(data); |
11 | Serial.println(F("Analysing data")); |
12 | |
13 | if(data[14] == 0xc0) |
14 | {
|
15 | Serial.println(F("Bind packet received")); |
16 | |
17 | |
18 | Serial.print(F("Adress is: ")); |
19 | Serial.print(data[7], HEX); |
20 | Serial.print(data[8], HEX); |
21 | Serial.print(data[9], HEX); |
22 | }
|
23 | }
|
der Output sieht so aus
1 | ############################# |
2 | ## Packet received ## |
3 | ############################# |
4 | Analysing data |
5 | Bind packet received |
6 | Adress is: 3017D8 |
7 | |
8 | ############################# |
9 | ## Packet received ## |
10 | ############################# |
11 | Analysing data |
12 | Bind packet received |
13 | Adress is: 3013D8 |
14 | |
15 | ############################# |
16 | ## Packet received ## |
17 | ############################# |
18 | Analysing data |
19 | Bind packet received |
20 | Adress is: 3013D8 |
da ist schonmal zwischen den ersten beiden Paketen ein Unterschied in der Adresse. Wenn ich Fernbedienung und Arduino neu starte kommt auch mal was anderes
1 | ############################# |
2 | ## Packet received ## |
3 | ############################# |
4 | Analysing data |
5 | Bind packet received |
6 | Adress is: 3213D8 |
Konfiguration:
1 | Mirf.spi = &MirfHardwareSpi; |
2 | Mirf.init(); |
3 | Mirf.configRegister(CONFIG, _BV(EN_CRC) | _BV(CRCO)); |
4 | Mirf.configRegister(EN_AA, 0x00); // no auto ack |
5 | Mirf.configRegister(EN_RXADDR, 0x3f); // all Pipes enabled |
6 | Mirf.configRegister(SETUP_AW, 0x03); // 5 bytes - default |
7 | Mirf.configRegister(SETUP_RETR, 0xff); // not relevant for receiver |
8 | Mirf.configRegister(RF_CH, 0x08); // channel eight |
9 | Mirf.configRegister(RF_SETUP, 0x05); // 1Mbps |
10 | Mirf.configRegister(STATUS, 0x70); |
11 | Mirf.configRegister(OBSERVE_TX, 0x00); |
12 | Mirf.configRegister(CD, 0x00); // CD-RPD |
13 | Mirf.configRegister(RX_PW_P0, 16); |
14 | Mirf.configRegister(RX_PW_P1, 16); |
15 | Mirf.configRegister(FIFO_STATUS, 0x00); |
16 | Mirf.setTADDR((byte*)("\x66\x88\x68\x68\x68")); |
17 | Mirf.setRADDR((byte*)("\x88\x66\x86\x86\x86")); |
18 | Mirf.flushRx(); |
19 | Mirf.powerUpRx(); |
Vielleicht weiß jemand Rat
Hallo Danke schonmal für die Antwort, vorerst noch nicht, ich hab mich auf [1] verlassen und dachte ich könnte auch auf konstantem Kanal "bereits etliche Datenpackete pro Sekunde empfanden". [1] https://github.com/hackocopter/Documentation/tree/master/RemoteControl/Receiver-Test
Christopher B. schrieb: > Hallo Danke schonmal für die Antwort, > > vorerst noch nicht, ich hab mich auf [1] verlassen und dachte ich könnte > auch auf konstantem Kanal "bereits etliche Datenpackete pro Sekunde > empfanden". > Hallo Christopher, das war bei mir so, aber auch nicht auf allen Kanälen. Außerdem hängt das Channelhopping ja auch von der ID der Fernbedienung ab. Das Schema kann bei Dir also ein anderes sein. Später im Thread kommen ja auch noch einige Beträge zur Dekodierung des Funkschemas aus den SPI-Daten, die meinem Versuch etwas widersprechen.
:
Bearbeitet durch User
Hallo, danke an Tim und Helmut für die Antworten, aber der Fehler lag ganz wo anders. Ich habe ja (leider) diese Mirf Lib vom Arduino benutzt und da kommt dieses
1 | Mirf.powerUpRx(); |
was mir leider das Bit CRCO löscht. Nachdem ich dass dann manuell wieder gesetzt habe, hat es auf Anhieb funktioniert. Das Frequenzhopping ist nun auch drin, aber richtig flüssig läuft das noch nicht. Es gibt immer wieder Sekunden in denen gar nichts ankommt. In manchen Sekunden kommen 3-4 Pakete. Aber es sollte eigentlich viel mehr sein, oder? Die ID meiner Fernbedienung ist 0x30 0x13 0xD8 Tabelle ist dementsprechend die dritte und das Inkrement ist 6. Damit komm ich auf folgende Kanäle: [28 2d 1d 3f 3a 2e 31 23 1e 2d 27 3e 16 2c 26 25] LG Christopher
Christopher B. schrieb: > Die ID meiner Fernbedienung ist 0x30 0x13 0xD8 > Tabelle ist dementsprechend die dritte und das Inkrement ist 6. Damit > komm ich auf folgende Kanäle: komme auf das gleiche Ergebnis
1 | calculating from 30 13 D8 : Sum 1B Inc 06 |
2 | 40 45 29 63 58 46 49 35 30 45 39 62 22 44 38 37 <dec |
3 | [28 2d 1d 3f 3a 2e 31 23 1e 2d 27 3e 16 2c 26 25 <hex |
Das könnte natürlich auch an der gleichen Quelle der Beschreibung u/o Software liegen. Die Zeit zwischen zwei Reads war so um die 8 ms, lange Pausen sind mir nicht aufgefallen. Meine FB nennt sich jd385.
:
Bearbeitet durch User
Mal ein Zwischenstand. Hier ist die neu geordnete Dokumentation: https://github.com/hackocopter/JD385_Documentation Hier die Anleitung zum Flashen mit ST-Link: https://github.com/hackocopter/JD385_Documentation/tree/master/Quad%20Firmware%20Flashing
Hallo mal ein kleines Update von mir. Also ich hab mal den Logic Analyzer an die Fernbedienung gehangen und hab dadurch die Belegung des verbauten Funkmoduls in der Fernbedienung (meine heißt übrigens auch JD-385) herausfinden können. Vorher hatte ich nach diesem Modul gesucht aber nichts gefunden. Habe Bilder davon und werde die noch beschriften und dann teilen. Jedenfalls was beim Sniffen herausgekommen ist, ist, dass die Fernbedienung genau die Kanäle einstellt die wir hier errechnet haben. Soweit hat also alles gepasst. Bloß hat die Ausgabe auf der Schnittstelle zum PC offenbar solange gedauert dass ich zwischendrin Pakete (mindestens 2) nicht bekommen habe und so nicht weitergehoppt wurde. Außerdem hab ich den Ort beim testen gewechselt. Ich war vorher wohl in einer von WLAN vereuchten Umgebung. Dadurch bin ich aber auf eine Idee gekommen. Ich hoppe immer sobald ich ein gültiges Paket empfangen habe. Das nächste Paket auf der neuen Frequenz müsste in etwa 16ms kommen. Wenn ich nach 20ms kein neues Paket empfange, dann wechsel ich auf den nächsten Kanal, weil ich davon ausgehe, dass der derzeitige gestört ist. lg Christopher
Gibt es das Teil auch ab 25€ bei ebay? http://www.ebay.de/itm/MINI-Quadcopter-6-axis-2-4ghz-4-Kanal-Gyro-UFO-RC-Hubschrauber-Helikopter-/200997651082?pt=RC_Modellbau&var=&hash=item2ecc64c28a /MINI Quadcopter 6 axis 2,4ghz 4 Kanal Gyro UFO RC Hubschrauber Helikopter/ Ist das der Gleiche oder ein sehr ähnliches Modell? Bin ein Noob, habe davon keine Ahnung. Gruß Fabian
> Ist das der Gleiche oder ein sehr ähnliches Modell? Ja. siehe: http://www.china-gadgets.de/gadget/hubsan-x4-h107-micro-quadrocopter/
Augenscheinlich gibt es den H4 auch noch mal als X-Dart: http://www.ebay.de/itm/121265393174?ssPageName=STRK:MEWAX:IT&_trksid=p3984.m1438.l2649 Abgesehen von der Gehäusefarbe wohl identisch.
Hat jemand den Sender mit Display und kann man ein Foto des aktiven Displays hier einstellen? Sind Hinweise auf den Typ / Hersteller auf dem Display zu erkennen?
Gibt es den Sender mit Display? Die Hubsan X4 FB hat ein Display, diese scheint aber ein anderes Innenleben zu haben, da sie auch einen anderen Tranceiver nutzt. Übrigens gibt es inzwischen ein neueres Modell, den JXD388: http://www.banggood.com/JXD-388-2_4G-4CH-6-Axis-Gyroscope-RC-Quadcopter-With-4-Lights-RTF-p-912240.html Die FB ist die gleiche. Das Innenleben auch. http://www.rcgroups.com/forums/showthread.php?t=2055735
Christopher B. schrieb: > Dadurch bin ich aber auf eine Idee gekommen. Ich hoppe immer sobald ich > ein gültiges Paket empfangen habe. Das nächste Paket auf der neuen > Frequenz müsste in etwa 16ms kommen. Wenn ich nach 20ms kein neues Paket > empfange, dann wechsel ich auf den nächsten Kanal, weil ich davon > ausgehe, dass der derzeitige gestört ist. Super Arbeit. Funktioniert das soweit? Interessant wäre es, diesen Code jetzt auf dem copter selbst zum Laufen zu bringen :)
Nunja, es funktioniert bisher um einiges besser als stupide die Kanäle durchzuhoppen. Ich habe aber manchmal Probleme überhaupt was zu empfangen. Eventuell muss ich mir nochmal ein neues Modul schnappen und weiter weg von der USB-Buchse vom Arduino anbringen. Ich hab nämlich ein echtes Problem mit Störungen. Ich werde jetzt nochmal das Programm von Helmuth ausprobieren. Wenn ich da auch so wenig Pakete empfange dann liegt es an meinem HW-Setup. Ich melde mich in jedem Fall wenn ich weiter gekommen bin. Tim schrieb: > Übrigens gibt es inzwischen ein neueres Modell, den JXD388: Super, der hat einen Ein-Aus-Schalter :) EDIT: Übrigens auch als BNF-Version, also ohne Fernbedienung für unter 21€ zu haben. Also definitiv Einfuhrumsatzsteuerfrei http://www.banggood.com/JinXingDa-JXD388-2_4G-6-Axis-Gyroscope-RC-Quadcopter-BNF-p-912835.html
:
Bearbeitet durch User
Kann man das B 'n' F Modell auch mit der Fernbedienung der Hubsan X4 Klone, also den JD-185 bzw. JD-385 steuern? Danke Fabian
Das Innenleben und die Fernbedienung von JD388 und JD385 scheinen identisch zu sein. Nur das Platinenlayout ist anders. SWD und UART sind aber immer noch herausgeführt. Ich habe die BNF-Version vor einer Weile bestellt. Werde Bilder machen, wenn der copter ankommt. http://www.rcgroups.com/forums/showthread.php?t=2071264 http://www.rcgroups.com/forums/showthread.php?t=2073713
Ich habe mal bei laufendem Sender - sowohl im Modus "bind" als auch "run" - alle 128 Kanäle abgehorcht. Seltsamerweise sind Kanal 7 und Kanal 8 immer recht aktiv, obwohl sie in meiner Hop-Liste nicht aufgeführt werden. Wenn ich es richtig gelesen habe, wird auf Kanal 8 auch initialisiert und das Binding gemacht. Aber wieso ist der Kanal auch danach noch aktiv? Noch eine Idee gesucht: Wie synchronisiert man am sinnvollsten das Hüpfen? Auf dem ersten Kanal der Tabelle auf ein Paket warten und dann loslegen? Aber was ist, wenn ausgerechnet dieser Kanal gestört ist? Hat schon mal jemand einen kompletten lauffähigen und hüpfenden Empfänger realisiert?
Anbei zwei Grafiken. Es wurde jeweils pro Kanal eine feste Zeit gewartet und es wurden die in dieser Zeit gehörten Pakete gezählt. Eine Kontrolle bei ausgeschaltetem Sender zeigte, dass keine Störsender in der Luft waren. Die Hopliste: 034 039 023 057 052 040 043 029 024 042 033 056 013 038 029 031 Tx-ID: 7F 7E 26
:
Bearbeitet durch User
Georg G. schrieb: > Noch eine Idee gesucht: Wie synchronisiert man am sinnvollsten das > Hüpfen? Auf dem ersten Kanal der Tabelle auf ein Paket warten und dann > loslegen? Aber was ist, wenn ausgerechnet dieser Kanal gestört ist? Hat > schon mal jemand einen kompletten lauffähigen und hüpfenden Empfänger > realisiert? Das ist bei genauerer Betrachtung tatsächlich nicht trivial. Eine gute Idee habe ich auch nicht. Wie läuft es denn z.B. bei Bluetooth, welches im gleichen Freqenzbereich hüpft?
Ich habe noch einen anderen Quadcopter bekommen, der auf der gleichen Hardware mit leichten Modifikationen aufbaut. Interessanterweise hat er eine Fernbedienung mit LCD. Anbei ein paar Bilder. Nennt sich "F180". Ich habe ihn als Sonderangebot von T-Mart gekauft. Jetzt ist er etwas teurer.
Wer sich für DFM interessiert wird an dem Ding seine Freude haben. Es ist gegenüber der letzten Variante einiges optimiert worden. Das Design ist vom 3. Dezember. Bestellt habe ich anfang Februar. Eine ziemlich beeindruckende time to market, das bekommt ein deutscher Großkonzern nicht hin :) Die zwei Heizbatterien in der Fernbedienung hat man auch herausoptimiert. Jetzt gibt es nur noch einen LDO und nur vier Batterien, obwohl die Hardware fast gleich ist. Das LCD ist übrigens völlig nutzlos und zeigt nur Thrust in % und die Richtung des Trimmings an. Die Signalstärkeanzeige kann prinzipbedingt nicht funktionieren, ob die Battieranzeige funktioniert, weiss ich nicht.
:
Bearbeitet durch User
Fabian Hoemcke schrieb: > @Tim, hast Du mal n Link wo man das bestellen kann? http://www.tmart.com/DFD-F180-6-Channel-2.4GHz-Remote-Control-RC-Quadcopter-Black-Blue_p234623.html
Hier mal eine Zusammenfassung nach meinem Verständnis - ARM CPU muss erst gelöscht/unlocked werden, damit neue Firmware übertragen werden kann - Original-Programmieradapter und Klone können diesen erase-Vorgang von Haus aus, sind aber hier nur zur Analyse genutzt worden: - es geht auch mit SWD Interfaces wie ST-Link, setzt aber eine bestimmte Kommandosequenz voraus - diese Sequenz lässt sich mit manchen IDEs durchführen - es gibt eine Minimalsoftware für die kostenlose, codegrößenbegrenzte KEIL µVision IDE (legacy device support erforderlich wg. Umstellung), die LEDs blinken lässt - Anleitung und Minimalsoftware s.u. - es gibt Flug-Software für ähnliche Hardware, aber die meisten Projekte setzen größere Controller mit mehr Programmspeicherplatz ein - es gibt also noch keine fliegende Alternativ-Firmware - das Funk-Protokoll der Fernbedienung ist weitestgehend entschlüsselt und ist ähnlich zu internet-bekannten Spielzeugen -- Sender-Code existiert -- Empfänger-Code in Arbeit - der enthusiastisch angelegte Wiki-Artikel http://www.mikrocontroller.net/articles/Hack-O-Copter ist weitestgehend informationslos - cpldcpu hat seine ganze Arbeit unter https://github.com/hackocopter/ dokumentiert - das Interesse hat nachgelassen, da die original-Firmware offenbar gut funktioniert und das Gerät für Erweiterungen nur wenig Raum bzw. Schub bietet - Vorgehen für offene Flug-Software: Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter" - die Ladeschaltung begrenzt nur den Ladestrom (Spannungsabhängig) und basiert auf der integrierten Sicherheitsabschaltung des Akkus
Info schrieb: > -- Sender-Code existiert Es gibt Code (Deviation), der die Funktionen des Senders nachbilden kann, der aber für andere Hardware geschrieben wurde. Für den originalen Sender gibt es keinen Code. > -- Empfänger-Code in Arbeit Das ist sehr optimistisch ausgedrückt. Es gibt Ansätze und noch Probleme. > - das Interesse hat nachgelassen, da die original-Firmware offenbar gut > funktioniert und das Gerät für Erweiterungen nur wenig Raum bzw. Schub > bietet Die vorhandene Firmware ist sehr verbesserungswürdig. Die gängigen Boards für größere Copter (KK, Multi-2 usw) bieten auch nur wenig mehr Resourcen. Der Prozessor reicht schon hin. Das größere Problem ist die Hardware. Das Ding ist einfach zu klein und zu schwach, um es im Freien zu fliegen (in 10m Höhe sieht man nicht mehr, wo vorn und hinten ist und eine leichte Bö versetzt den Copter in Sekundenschnelle um 50m). Und im Innenraum hat man meist nicht genug Platz. Wer wohnt schon in einer Turnhalle? Für einen Flip sollte man 2m Luft in alle Richtungen haben... > - die Ladeschaltung begrenzt nur den Ladestrom (Spannungsabhängig) und > basiert auf der integrierten Sicherheitsabschaltung des Akkus Der Akku hat keine Sicherheitsschaltung. Die Ladeschaltung begrenzt Strom und Spannung und funktioniert erstaunlich gut. Aber das Ding macht Spaß, mehr als die kleinen Koax-Helis, die sind einfach viel zu stabil :-)
Mal wieder etwas zum Nachdenken/Diskutieren: Das Hüpfmuster des Senders passte nach ersten Messungen nicht zur Theorie. Es erschienen deutlich mehr Kanäle als die erwarteten 16. Und bei den erwarteten Kanälen war kein Maximum in der Verteilung. Tim hat vor Monaten das auch festgestellt. Ich habe nun mal einen Logik Analysator an die Pins des HF Moduls gehängt und den Verkehr mitgeschrieben. Es ist in schöner Folge alle 4ms "lese Status, lösche Tx-Interrupt Flag, setze Kanal, sende Packet, große Pause". Und die geschriebenen Kanal Nummern passen exakt zu den erwarteten 16 Werten (die übrigens nicht immer 16 verschiedene sein müssen). Muss man nun folgern, dass der Empfänger viel Müll hört (aber richtig! CRC passt!)? Was bedeutet das für die Bindung Phase? Kanal 8 wird mitnichten immer verwendet. Beim Binding mittels Kanal 8 leben wir von Schmutzeffekten? Fakt ist, dass es funktioniert. Als Ingenieur rollen sich mir aber momentan die Fußnägel hoch.
Georg G. schrieb: > Was bedeutet das für die Bindung Phase? Kanal 8 wird mitnichten immer > verwendet. Beim Binding mittels Kanal 8 leben wir von Schmutzeffekten? Hallo Georg, grundsätzlich stimme ich dir da zu, aber weiter oben sieht man meine Kanalliste und da ist Kanal 8 nicht mit drin. Trotzdem stellt meine Fernbedienung beim Start erstmal Kanal 8 ein. Aber da werden dann auch nur zwei Pakete gesendet. lg
Christopher B. schrieb: > Trotzdem stellt meine > Fernbedienung beim Start erstmal Kanal 8 ein. Aber da werden dann auch > nur zwei Pakete gesendet. Dann hast du eine andere Fernbedienung als ich (JD-385). Auf Kanal 8 kommt nur 1 Paket, das auch nicht das Bind-Flag gesetzt hat. Dieses Paket hat offensichtlich keinen Sinn, man kann es weglassen. Ich hänge die komplette etwas kommentierte Initialisierung meines Senders an (Analyser am SPI Port). Man sieht Abweichungen vom Beken Datenblatt. Ich gehe mal davon aus, dass viele Dinge im Code "historisch gewachsen" sind. Der Sender streut offenbar breit und man kann auf Kanal 8 zuverlässig empfangen, obwohl dort nicht gesendet wird. Im Prinzip reicht ja ein Paket und man kann auf die Tabelle synchronisieren. Dann muss ich mir wohl mal einige N79E814 besorgen oder einen Adapter für einen ATMega bauen. Den originalen Chip möchte ich (noch) nicht löschen. Schliesslich will ich ja ab und an mal spielen :-)
Das passt auf jeden Fall zu meinen Ergebnissen. Wobei ich immer noch nicht recht glauben mag, dass es an fehlender Trennschärfe liegt. Es kann natürlich sein, dass das Signal auf den Nachbarkanälen sehr schwach ist und man es nur deswegen empfängt weil die Distanz gering ist und auf dem Kanal kein Sender ist. Georg, wenn Du willst kann ich Dir eine FB oder deren Innerein gegen Porto überlassen. Bei mir haben sich ein paar Angesammelt :)
Ich habe mal versucht, das Protokoll der FB in Prosa zu fassen. Fragen, Ergänzungen und Korrekturen bitte per p-Mail an mich.
Ich habe mal das kleine Spielzeug neben das große Spielzeug gestellt. Die belegten Kanäle (und wahrscheinlich auch die gesendeten Daten) ändern sich je nach Betriebsmodus: * direkt nach dem Einschalten (modus_ein) * Hebel ganz nach oben gedrückt (hobel_oben) * synchronisiert (modus_normal) Ob wirklich synchronisiert wurde, kann die Fernbedienung nicht wissen, da der Rückkanal fehlt, aber sie piept trotzdem :-) Den synchronisierten Modus habe ich nochmal näher untersucht. Man erkennt, das die einzelnen Frequenzen zyklisch durchlaufen werden. Ein Zyklus dauert ca. 128 ms und besteht aus 16 "Symbolen". Jedes "Symbol" besteht aus zwei Impulsen im Abstand von 4 ms. Dann wird die Frequenz gewechselt (normal_spektrogram). Hier ein Zyklus als Liste:
1 | Frequenz Zeit |
2 | GHz ms |
3 | 2,45361 180,503 |
4 | 2,45356 184,257 |
5 | 2,42501 188,018 |
6 | 2,42507 192,535 |
7 | 2,43263 196,289 |
8 | 2,43269 200,805 |
9 | 2,44068 204,566 |
10 | 2,44068 208,320 |
11 | 2,42002 212,081 |
12 | 2,42008 216,598 |
13 | 2,43000 220,352 |
14 | 2,43006 224,868 |
15 | 2,41804 229,377 |
16 | 2,41804 232,383 |
17 | 2,44503 236,900 |
18 | 2,44503 241,409 |
19 | 2,42405 245,170 |
20 | 2,42405 249,687 |
21 | 2,43864 252,693 |
22 | 2,43864 257,202 |
23 | 2,42705 261,718 |
24 | 2,42673 265,472 |
25 | 2,45662 269,989 |
26 | 2,45662 273,750 |
27 | 2,43972 277,503 |
28 | 2,43960 282,020 |
29 | 2,43569 285,781 |
30 | 2,43564 289,535 |
31 | 2,43403 294,052 |
32 | 2,43403 297,813 |
33 | 2,44562 301,567 |
34 | 2,44605 306,083 |
Das müßte sich ja mit den Daten der Protokollanalyse decken. Viele Grüße, Volker
Volker schrieb: > Die belegten Kanäle (und wahrscheinlich auch die gesendeten Daten) > ändern sich je nach Betriebsmodus: Das wäre etwas neues. Die belegten Kanäle werden fest durch die Seriennummer des Senders vorgegeben. Die Kanäle und damit die Frequenzen kannst du dir selbst errechnen (siehe Protokoll.pdf). Es ändern sich nur die Daten. Erstaunlich ist für mich nur, wie schön der Empfänger den Splatter dekodieren kann. Das macht das synchronisieren nicht einfacher. > * direkt nach dem Einschalten (modus_ein) Es werden Pakete mit Flag 0xc0 gesendet, alle anderen Daten sind "normal". > * Hebel ganz nach oben gedrückt (hobel_oben) Es wird "Vollgas" mit Flag 0xc0 gesendet, alles andere sind die normalen Daten. > * synchronisiert (modus_normal) Das Flag ändert sich auf 0x00 (bzw 0x04 während "Flip" gedrückt ist).
Georg G. schrieb: >> Die belegten Kanäle (und wahrscheinlich auch die gesendeten Daten) >> ändern sich je nach Betriebsmodus: > Das wäre etwas neues. Die belegten Kanäle werden fest durch die > Seriennummer des Senders vorgegeben. Das schließt sich ja nicht aus. Die ersten drei Bilder zeigen, daß zumindest meine FB, zwischen Einschalten, Vollgas und normal verschiedene Frequenzen benutzt. Vielleicht wird bei mir noch zwischen den Tabellen gewechselt? Der Wechsel ist nicht ganz einfach zu erkennen, da ich Start/Stop angepasst habe, aber der Marker steht jeweils auf der selben Frequenz. > Die Kanäle und damit die Frequenzen > kannst du dir selbst errechnen (siehe Protokoll.pdf) Mit meiner Frequenzliste und Deiner protokoll.pdf, kommen folgende Kanäle raus (alles hex): 36, 19, 21, 29, 14, 1E, 12, 2D, 18, 27, 1B, 39, 28, 24, 22, 2E Das entspricht genau Deiner Tabelle 0. Den Offset hatte ich willkürlich gewählt. Viele Grüße, Volker
Volker schrieb: > Vielleicht wird bei mir noch zwischen den Tabellen gewechselt? Dann hättest du die erste Fernbedienung dieser Art. Kannst du uns bitte den Typ nennen?
Georg G. schrieb: > Dann hättest du die erste Fernbedienung dieser Art. Kannst du uns bitte > den Typ nennen? Den genauen Typ kann ich Dir momentan nicht nennen, erst nächste Woche wieder. Dann kann ich auch die startup und die pairing Sequenz nochmal gezielt aufnehmen. Hatte es bei der letzten Messung erst am Ende entdeckt. Viele Grüße, Volker
Georg G. schrieb: > Kannst du uns bitte den Typ nennen? Auf der Fernbedienung steht JD-385 und 2.4 MHz. Sonstige Aufschriften, wie Seriennummern sind nicht zu erkennen und ein LC-Display ist auch nicht vorhanden. Ich habe die Einschaltsequenz noch einmal gezielt aufgenommen. Man sieht, es wird zwischen zwei Hopping-Sequenzen gewechselt. Es gibt die normale Sequenz und die pairing Sequenz. Die Frequenzen/Kanalnummern der normalen Sequenz lauten bei mir:
1 | dez: 63, 58, 46, 49, 35, 30, 45, 39, 62, 22, 44, 38, 37, 40, 45, 29 |
2 | hex: 3F, 3A, 2E, 31, 23, 1E, 2D, 27, 3E, 16, 2C, 26, 25, 28, 2D, 1D |
Die Frequenzen/Kanalnummern der pairing Sequenz lauten bei mir:
1 | dez: 57, 40, 37, 34, 46, 54, 25, 33, 41, 20, 30, 18, 45, 24, 39, 27 |
2 | hex: 39, 28, 25, 22, 2E, 36, 19, 21, 29, 14, 1E, 12, 2D, 18, 27, 1B |
Die pairing Sequenz ist Deine Tabelle 0. Die normale Sequenz finde ich dort nicht. Viele Grüße, Volker
Nun wird es richtig mysteriös. Auf meiner FB steht das gleiche (nur, dass es 2.4GHz und nicht 2.4MHz sind). Ich habe mit einem Logikanalysator aufgezeichnet, was dem Sendemodul übermittelt wurde. Und das waren sowohl beim Binding als auch im Betrieb die Werte aus der Tabelle, die sich aus der Seriennummer errechnen lies. In welchem zeitlichen Abstand wird zwischen den Tabellen umgeschaltet? Kannst du dir die Pakete mitschreiben? Da steht immer die Seriennummer drin.
Georg G. schrieb: > In welchem zeitlichen Abstand wird zwischen den Tabellen umgeschaltet? Im Spektrogramm sieht man, wie der Sender eingeschaltet wird. Dann hab ich den Gashebel hoch und wieder runter bewegt und losgelassen. Der Hebel bestimmt also die Zeitachse (in dem Fall Y). > Kannst du dir die Pakete mitschreiben? Da steht immer die Seriennummer > drin. Da muss ich erstmal sehen, ob der Spektrumanalysator die GFSK dekodieren kann... Viele Grüße, Volker
Ich konnte gerade das "Flying Saucer Aircraft JD-385" fliegen und stelle fest, dass es in der Tat etwas schwierig zu fliegen ist, da entweder die Regelung oder die Fernsteuerung keine "feinfühlige" Steuerung zulässt. Speed Stufe 1 ist zu träge, Stufe zwei ist OK, #3 zu empfindlich für meinen Geschmack. Aber richtig proportional erscheint es mir nicht, eher digital. Außerdem ist die Federkraft meiner Steuerknüppel nicht gleich. Sind da wirklich Potis drin oder irgendwelche quasibinären Kohle-Gummis? Mein Vergleich: Eigenbau mit STM32F3-Discovery und "tau labs". Die Packung hat einen eachbuyer.com Aufkleber: http://www.eachbuyer.com/mini-6-axis-4-channels-2-4ghz-remote-control-gyro-flying-aircraft-rc-helicopter-p175545.html -- aber der Preis passt nicht zum *bay-Angebot.
Info schrieb: > Sind da wirklich Potis drin E sind Potis drin, Fotos vom Innenleben findest du auf github und weiter oben in diesem Thread. Ansonsten stimme ich dir zu. Speziell die Höhenstabilisierung lässt sehr zu wünschen übrig. Die verbaute Hardware würde ein besseres Verhalten hergeben. Der Sender reagiert auch auf kleine Knüppel Ausschläge (sieht man an mitgeschriebenen Daten), das Problem muss im Empfänger liegen.
Anbei ein paar Programme, um die Fernbedienung JD-385 simulieren/empfangen zu können. Als Hardware sowohl für Sender als auch Empfänger dient eine kleine Schaltung mit einem ATMega328 (oder anderen, bitte im Programm dann die SPI Belegung anpassen) und einem RFM70-Modul. Das Schaltbild ist in RFM70-rx-tx-sch.png zu finden. Monitor.c dekodiert die Pakete der Fernsteuerung. Es wird nur Kanal 8 empfangen. Da der Empfänger sehr breitbandig ist, hört er auf dem Labortisch auch den hüpfenden Sender zuverlässig. RFM70-fb-rx.c ist ein Empfänger, der auf den Sender synchronisiert und ihm in der Frequenz folgt. Über Pulsfolgen an einigen Pins (siehe Programm) kann man verfolgen, ob es zu Aussetzern kommt. Das Folgen lässt sich auch stoppen und man kann gezielt einzelne Kanäle einstellen. Der Helptext im Programm sollte ausreichen. RFM70-fb-tx.c ist ein Sender, der passend zu seiner Seriennummer hüpfen kann, der aber auch auf festen Kanälen senden kann. Der Helptext zeigt die möglichen Funktionen. RFM70.c is eine Lib für das Modul. Sie stammt aus dem Internet und wurde für die Fernbedienung modifiziert und an einigen Stellen etwas umgeräumt. Nicht alle Funktionen sind getestet. Mit Überraschungen sollte man daher rechnen. Wer Fehler findet oder Anregungen hat, schickt mir bitte eine Mail. Dann will ich das gern einarbeiten. Der nächste Schritt ist, das alles in den originalen Sender zu stopfen. Sein HF-Modul ist zum RFM70 kompatibel (nicht zum nRF24L01!).
Der Prozessor im Sender enthält keinen Bootlader im LDROM. Er kann also nicht über ISP neu programmiert werden. Ich werde mir dann mal einen ICP Adapter beschaffen und weiter forschen. Übrigens: In dem Schrumpfschlauch, der als Antenne angebracht ist, verbirgt sich eine kleine Sperrtopf Antenne. Da hat ein Entwickler richtig mit gedacht. Wenn man den Antennen Plastik Knüppel am Gehäuse entfernt (er ist ohnehin nur Deko) und den Schrumpfschlauch statt dessen durch das Loch steckt, funktioniert der Sender drastisch besser. Man müsste es schaffen, den Sperrtopf im Inneren des Plastik Knüppels unter zu bringen...
Zwecks Programmierung der FB braucht man ein lesbares Datenblatt des Prozessors. Beim Hersteller gibt es nur das chinesische Original. Ich habe also einmal angefangen, die relevanten Teile ins Deutsche zu übersetzen. Wenn jemand zeit und Lust hat mitzumachen. ist er herzlich eingeladen. Chinesisch muss er nicht können. Es gibt eine Grobübersetzung von Dr. Gurgel. Mit etwas Spaß an Rätseln kann man daraus deutsche Prosa machen. Also... wer übernimmt ein Kapitel?
> Wenn man den Antennen Plastik Knüppel am Gehäuse entfernt (er ist ohnehin > nur Deko) und den Schrumpfschlauch statt dessen durch das Loch steckt, > funktioniert der Sender drastisch besser. Interessante Information, werde ich die Tage überprüfen. > Der nächste Schritt ist, das alles in den originalen Sender zu stopfen. > Sein HF-Modul ist zum RFM70 kompatibel (nicht zum nRF24L01!). Bedeutet dies, dass der nRF24L01 nicht mit dem Empfänger funktioniert?
Davis schrieb: > Bedeutet dies, dass der nRF24L01 nicht mit dem Empfänger funktioniert? Auf der HF Seite kann man beide kompatibel gestalten. Das ist bei der FB auch so gemacht. RFM70 und nRF24L01 sind aber nicht kompatibel auf der CPU Seite. Sie sind nur sehr ähnlich. Und der nRF24L01, speziell die "+" Variante, kann mehr. Mit der Bemerkung wollte ich nur sagen, dass man die Beispielsoft auf Github und auch die "richtige" Soft nicht 1:1 mit einem nRF24L01 verheiraten kann. Die notwendigen Änderungen sind aber schnell gemacht (andere Initialisierung).
Überraschende Neuigkeiten! Victor hat mit Hilfe unserer Dokumentation Bradwii auf einen V202 portiert und zum lauefen bekommen. https://github.com/victzh/bradwii
Tim als gast schrieb: > Bradwii auf einen V202 > portiert und zum lauefen bekommen. Super, dann steht IR-Kanonen oder einem Süßigkeiten-Abwurf ja nichts mehr im Wege! Allerdings traue ich mich noch nicht, meinen Flieger umzuflashen .. Hat jemand das Auto PID tuning schon ausprobieren können, sofern es an die Flip-Taste angebunden ist?
Mal eine Frage, warum so intensiv mit der Funke beschäftigen? Ich fliegen den JD 385 mit einer Devo 7e + nRF24L01, bis auf die Flips funktioniert das Super! Interessant ist eher die Hardware der Quad voll auszureizen, oder nicht?
Studentle schrieb: > warum so intensiv mit der Funke beschäftigen? Gute Frage :-) Von Tim habe ich eine Sender Platine bekommen. Also musste ich nicht meinen Copter schlachten. Und an irgend einer Ecke muss man ja anfangen. Außerdem missfällt mir die Steuerung sehr. Im Anfänger Mode ist sie zu träge, im Experten Mode zu wackelig, dazwischen geht es so. Da würde ich gern mal mit geänderten Kennlinien spielen. Wenn der Sender fertig ist, gehe ich an den Copter. Mich stört speziell die schlechte Stabilisierung der Höhe. Mal sehen, ob ich dann eine Platine aus einem zerstörten Copter bekomme.
Georg G. schrieb: >> Auto PID tuning > > Was ist das? PID ist (vermutlich) die Regelung, die das Ding fliegbar macht (Lageregelung): https://de.wikipedia.org/wiki/Regler#PID-Regler Den Regler muss man einstellen (tuning), d.h. seine Parameter finden. Das lässt sich aber auch automatisch machen -> auto-tuning. Dies ist in "bradwii" als Feature genannt und auch als Modul in dem o.g. Port vorhanden. Ob es eingebunden ist, habe ich noch nicht geprüft. Allerdings haben wir alle dieselbe Hardware, ein Satz optimaler Parameter genügt also :-)
@Georg Ja die Funke ist einem Preis entsprechend... Wie schon gesagt ich habe mir die DEVO 7e zugelegt die mit der DEVIATION Firmeware einiges leistet und preislich immernoch im Rahmen ist. Potis in i.O. und lassen sich schön parametieren. Mann kann auch eine Graupner Funke verwenden und mit Hilfe eines Arduino das PPM-Signal aus der DSC Buchse für das Funkmodul der original Funke verwenden. Dass die Portierung von Bradwii klappt, ist sehr schön zu höhren, damit wird der kleine richtig gut!
Gerade entdeckt, wer noch interesse hat: http://www.aliexpress.com/item/Newest-6-Axis-Gyro-2-4GHz-4-Channel-Remote-Control-RC-Quadcopter-UFO-Helicopter-Kids-Toy/1780689687.html 16,23USD Have fun!
Osterhasi schrieb: > Gerade entdeckt, wer noch interesse hat: Der Shop hat kein Feedback-Rating und bietet viele Produkte deutlich unter dem üblichen Preis an. Ich wäre vorsichtig - auf keinen Fall die Einspruchfrist verstreichen lassen.
Schaltbild des Senders aktualisiert (fehlende Bauteile, einige Bauteilwerte).
Wie hast du ("Turbonator") es in Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter" geschafft, das Motorgehäuse zu öffnen? Selbst mit Skalpell kann ich die Laschen nicht aufbiegen bzw. ich komme nicht dahinter. Gibt es eine empfehlenswerte Quelle für Ersatzmotoren?
Turbonator schrieb: > Das problem war das das lager hoch gerutscht ist und der anker aus der > bürste gerutscht ist . Welches Lager meinst du? Die Buchse am Stator? Durch einen Schlag würde sie doch eher nach innen wandern, und damit das axiale Spiel des Rotors vergrößern, und ihn nicht verklemmen - ich verstehe nicht, was die Ursache für den schwergängigen Motor ist. Sobald das Bürstengehäuse etwas gelockert wird, dreht er wieder. Ich das Gehäuse aufgebohrt - alle Grate etc. am Gehäuse sind aber im Weg, wenn man den Rotor entfernen will, aber auch der Motor passt nicht mehr so gut ins Flieger-Gestell. Die Bürsten haben jeweils drei "Finger", man muss aufpassen, dass beim Einsetzen des Kommutators der unterste Finger nicht verbiegt. Ansonsten mit einer dünnen Messerklinge die Bürsten seitlich wegdrücken und dann den Kommutator von der Seite "eindrehen". Dazu muss der Rotor ja nicht im Gehäuse sein.
Okey... das mit dem Angebot war nix... aliexpress hat den Verkäufer gesperrt, hab das Geld wiederbekommen. Aber JXD385 ohne Funke für ~15€: http://www.aliexpress.com/item/4-Colors-Free-Shipping-JXD-385-BNF-without-Transmitter-4CH-3D-Mini-Quadcopter-w-6-Axis/1805974928.html oder JXD388 ohne Funke: http://www.aliexpress.com/item/JXD-388-BNF-4CH-6-Axis-Gyro-MINI-RC-Quadcopter-Without-Transimitter-2-4GHz-with-LED/1718288442.html Have fun^^
Hat sich schonmal jemand getraut, die freie Firmware auszuprobieren? Wie isses? Abgesehen von den anfälligen Motoren ist das Teil für mich der optimale Büroflieger - nur das Aufladen müsste man mit einer Dockingstation automatisieren.. Als Sensor eignet sich der Wii Remote IR Sensor, der 4 IREDs tracken kann. Daraus lässt sich die relative Position berechnen. Der Sensor nutzt I2C und wiegt < 1 g (+ Oszillator). http://de.wikipedia.org/wiki/Wii-Fernbedienung http://wiibrew.org/wiki/Wiimote#IR_Camera Sind noch 2 Pins frei und etwas Flash? Dazu gibt es auch schon einige Papers und evtl. open source? https://www.google.de/search?q=wii+ir+camera+quadrotor+land Zum Docken dann ein (selbstzentrierender) Kegel mit Kontaktringen. Die on-board Elektronik müsste dann aber elektronisch vom Akku getrennt, oder so modifiziert werden, dass sie das Laden übersteht und nicht stört.
Hab leider kein Programmer um die Firmware zu flashen :( Ansonsten sind die Motren nicht anfällig! Also ich habe seit Dezember einen einzigen Motor gecrasht. Propeller kaufe ich inzwischen im 10er Pack. Also bin überrascht was der kleine ab kann! Als Lader verwende ich den iMAX B6 mit einem entsprechenden Kabel damit ich immer 3 Akkus zur gleichen Zeit laden kann. Habe 6 Akkus ;) Ein Bericht über einen umgeflashten Quad wäre echt Interessant.
Ich bin jetzt endlich dazu gekommen, die neue Firmware, den Bradwii-Port von Victor auszutesten. https://github.com/victzh/bradwii Er hat wirklich gute Arbeit geleistet. Die Firmware belegt im aktuellen Zustand nur 13kb Speicher - es ist also noch viel Platz für Weiteres. Das Projekt lässt sich mit Keil uvision 5 compilieren. Allerdings musste ich noch ein "-C99" compilerflag ergänzen, sonst gab es Fehlermeldungen. Nachdem ich ST-Link configuriert habe, konnte ich auch die Firmware uploaden. Das Binding mit der Fernbedienung funktioniert normal. Neu ist, dass man den Quadcopter "scharf" machen muss, in dem man beide Hebel nach unten recht bewegt. Die Motoren laufen dann in der niedrigsten Geschwindigkeit. Das Fliegen selbst funktioniert leider noch nicht sehr gut. Möglicherweise sind die Motoren unterschiedlich zugeordnet. Dabei scheint es Unterschiede zwischen den Mini54ZAN basierten Typen zu gehen. Werde noch versuchen das Problem zu lösen.
Osterhasi schrieb: > oder JXD388 ohne Funke: > > http://www.aliexpress.com/item/JXD-388-BNF-4CH-6-Axis-Gyro-MINI-RC-Quadcopter-Without-Transimitter-2-4GHz-with-LED/1718288442.html Der JXD 388 ist übrigens eine lahme Kröte - kann ich nicht weiter empfehlen. Der hier sieht interessant aus: http://www.aliexpress.com/item/WLtoys-V272-Velocity-2-4G-6-Axis-GYRO-Super-Mini-4CH-RC-Quadcopter-BNF-like-Hubsan/1830128325.html Und hier noch eine interessante kombination. Fehlt nur noch der Schwimmmodus: https://www.youtube.com/watch?v=KenU_a_uZtY
Und nach genau 1111 Posts fliegt er endlich mit eigener Firmware! Die Firmware von Victor ließ sich mit minimalen Änderungen auf dem JD385 zum laufen bringen. Hier ist das Repository des KEIL Projektes: https://github.com/hackocopter/bradwii-jd385 Das Projekt lässt sich mit der kostenlosen Version von KEIL µVision 5 compilieren. Hier die Anleitung zum flashen: https://github.com/hackocopter/JD385_Documentation Der PID-Controller ist in der aktuellen Version noch nicht optimal konfiguriert. Aber ansonsten fliegt der Quadrocopter wie mit der originalen Firmware. Es gibt aber noch viele Stellen an denen die Software noch optimiert werden muss. Jetzt sind alle Möglichkeiten offen! Wichtige Ergänzung: Mit der neuen Firmware fliegt der Copter nur nach "arming". Dazu muss man beide Hebel nach unten rechts bewegen.
:
Bearbeitet durch User
Nabend. Habe mir auch mal einen Copter bestellt. Allerdings hat dieser das Problem, dass er nur kurz läuft und dann schnell Blinkt. Wenn ich nur ein wenig Gas gebe, fängt er nach ca. 1Sekunde an zu blinken. Wenn ich mehr Gas gebe dauert es länger. Wenn ich ihn festhalte und vollgas gebe, läuft er. Warum läuft er nur auf Vollgas? Die einzige Abweichung die ich zu den hier gelisteten Modellen finden kann, ist dass anstelle des Funk Empfänger Chips ein schwarzer Klecks sich befindet. In dem hier zur verfügung stehenden Schaltplan finde ich leider nicht woran das liegen könnte. Wäre sehr dankbar, wenn mir jemand helfen könnte. Sollte ich wichtige Informationen vergessen haben, bitte einfach bescheid sagen.
Hoffentlich kommt mein Ersatz bald. https://www.keil.com/demo/eval/arm.htm Ist "MDK-ARM Version 5.10" richtig? Gibt es auch einen FTP Server für den Download? Weiß jemand zufällig ob es in der Firmware eine Stelle gibt, an der man an "aufbereitete" Lagedaten einfach herankommt, oder gehen Sensorwerte direkt in die Regelung?
Hallöle: also meine sind heute gekommen: http://www.aliexpress.com/item/4-Colors-Free-Shipping-JXD-385-BNF-without-Transmitter-4CH-3D-Mini-Quadcopter-w-6-Axis/1805974928.html Hab mir 2 ohne Funke bestellt, tun einwandfrei und habe gerade gesehen sind nochmals im Preis gefallen: € 13,49. ST-Programmer ist letzte Woche schon gekommen, dann wird ich mir auch mal Bradwii flashen ;) @enttöuscht also ein vergleichbares verhalten haben meine nur wenn der Akku leer ist. sprich drehten noch und leds blinken schnell. Allerdings kann man dannach nicht mehr starten/fliegen! Ansonsten habe ich inzwischen 4 und fliegen alle 1A!
Um die FB neu zu flashen braucht man den Nuvoton Writer NWR-005. Den gibt es bei Atlantik Elektronik für €20.- . Dummerweise ist der Mindestbestellwert aber €400.- . Darunter gibt es €25.- Mindermengen Zuschlag. Ich würde einen NWR-005 kaufen. Möchte sich noch jemand an die Bestellung anhängen? Oder bestellt jemand regelmäßig bei Atlantik und würde mir das Ding mit bestellen?
Weiß jemand was in dem Empfänger aus diesem Set für ein IC drin ist? http://www.hobbyking.com/hobbyking/store/__8992__turnigy_9x_9ch_transmitter_w_module_8ch_receiver_mode_2_v2_firmware_.html Wäre cool, wenn man diese FB auch für den kleinen Copter nehmen könnte. Sie hat ja mehrere Modellspeicher...
Daniel schrieb: > Weiß jemand was in dem Empfänger aus diesem Set für ein IC drin ist? > http://www.hobbyking.com/hobbyking/store/__8992__turnigy_9x_9ch_transmitter_w_module_8ch_receiver_mode_2_v2_firmware_.html > Wäre cool, wenn man diese FB auch für den kleinen Copter nehmen könnte. > Sie hat ja mehrere Modellspeicher... Das wird mit dem Sender so einfach nix werden. Der Funkstandard ist ein anderer. Aber die DEVO funken können das Protokoll mit einer anderen Firmware: http://deviationtx.com/ Und so macht der spaß ;-)!
Auch ganz lustig: https://www.youtube.com/watch?v=-pmmC3SG5kA Kennt jemand nen guten Service wo man CFK Teile Fräsen lassen kann?
Hier ist ein Thread über den Hack-O-Copter auf RCGroups: http://www.rcgroups.com/forums/showthread.php?t=2174365 Dort ist etwas mehr los als hier. Man versucht jetzt, den Code auf den H4 zu portieren.
Übrigens unterstützt die neue Firmware MultiWiiconfig über den seriellen Port. Damit lassen sich alle Parameter des Quadcopters über eine GUI konfigurieren.
Moin, zwei Fragen: 1) Hat jemand eine passende Funke über und gibt diese günstig ab? Ich habe 3 dieser http://www.aliexpress.com/item/4-Colors-Free-Shipping-JXD-385-BNF-without-Transmitter-4CH-3D-Mini-Quadcopter-w-6-Axis/1805974928.html Mini Copter, aber nur einen mit Funke. 2) Ist die Flip Funktion eine Art Macro im Sender, der eine Reihe Befehle sendet, oder wird ein Befehl an den Copter gesendet und die FW im Copter steuert den Ablauf des Flips? Kann die Alternativ-FW den Flip? Danke und Gruß Nils
Hallo Nils zu 1. brauchst du noch eine Funke oder du hast schon eine? Also mit einer kannst du alle Modelle fliegen! Zu 2. der FlipMode wird über einen extra Kanal gesteuert. Wenn der Ruderausschlag auf 100% geht + FlipMode ON, macht das Teile die Flips. Im FlipMode OFF passiert nichts. Sprich: Die Flips macht der Copter nicht die Funke!
Octo schrieb: > zu 1. brauchst du noch eine Funke oder du hast schon eine? Also mit > einer kannst du alle Modelle fliegen! Sowohl als auch ;-) Ich habe 1 Funke und kann auch alle 3 Copter fliegen, aber eben nur einzeln. Hatte mir 2 ohne Funke zum Basteln und als Ersatz gekauft. Da die Copter aber so witzig sind, möchte ich gerne eine weitere Funke haben, damit ich mit jemandem zusammen fliegen kann... Es hörte sich hier im Thread mal so an, als wenn einige Leute ein paar Funken übrig hätten, da sie schon mehrere Copter verbastelt oder kaputt geflogen haben. Zu 2) D.h. die Alternative-FW kann die Flips nicht?
1.) Ok, verstanden. Hatte 2. Funken habe aber eine geschlachtet um an das Funkmodul zu kommen. Kann dir da leider nicht weiterhelfen 2.) Korrekt. Wobei Tim an dieser stelle bessere Informationen bieten kann...
Octo schrieb: > 1.) Ok, verstanden. Hatte 2. Funken habe aber eine geschlachtet um an > das Funkmodul zu kommen. Kann dir da leider nicht weiterhelfen Ich bekomme jetzt von Tim eine Funke im Tausch gegen die Attinys :-)
Nils Nachname schrieb: > Octo schrieb: > Zu 2) D.h. die Alternative-FW kann die Flips nicht? Wenn das Teil vernünftig fliegt braucht man dafür aber auch kein Makro. Ist nur etwas Übung...
Jain, also das Ding macht richtig Spaß auch ohne Flips. Die Flips sind ganz nett zum posen... Allerdings lässt sich der Copter maximal um ca. 45° kippen. Genial wäre natürlich in "frei" fliegen zu können. Also der kleine den du gepostet hast ist ein anderer, habe ich auch. Ist aber nur noch für Innenräume geeigent.
Robert Knipp schrieb: > http://www.aliexpress.com/store/product/free-shipping-ufo-vs-HUBSAN-NANO-Q4-H111-The-world-s-smallest-4CH-remote-control-toys/1093640_1859612633.html?spm=5261.7049941.1997368589.417&promotionId=253311003 Ist das denn kompatibel?
Hallo ich meine der hier ist der Clone von JXD: http://www.rcmaster.net/de-jxd-395-4ch-6-axes-nano-quadcopter-rc-2-4ghz-rtf-p237014.htm Meist sind die Funken der hersteller kompatiebel, also die JXD 385 nutzen das v2x2 Funkprotokoll. Könnte also auch mit dem JXD 395 funktionieren.
Ach und wer sich schon Akkus mit dem mitgelieferten "Lader" zerstört hat, wird dieses kleine Platinchen sicherlich lieben: http://www.ebay.de/itm/LiPo-Charger-Basic-Micro-USB-3-7V-Battery-Charger-module-/321149954122?pt=LH_DefaultDomain_0&hash=item4ac607684a
Ist das der gleiche Quadcopter, den es gerade bei Heise für ein Miniabo zu 16,50€ als Prämie bekommt, angeblich "SYMA X4"? http://www.mydealz.de/35435/6x-ct-z-b-quadrocopter-fuer-1650e/
Eher nicht: - das "Original" hatte keinen Rotorschutzring - andere Rotorenform - andere Gehäuseform, anderes Design Die einzige Gemeinsamkeit scheint zu sein, dass es sich bei beiden um Quadrocoptern handelt :P
Kennt jemand dieses model und oder weiß welcher Controller drauf ist? http://www.rcmaster.net/de-yizhan-x4-6-axis-gyro-rc-quacopter-with-lcd-transmitter-p237412.htm
Martin S. schrieb: > Die einzige Gemeinsamkeit scheint zu sein, dass es sich bei beiden um > Quadrocoptern handelt :P Naja, ein anderes Gehäuse zu gießen ist ja nicht das Problem. Aber vermutlich hat mich das »Hubsan X4« vs »SYMA X4« auf die Idee gebracht.
Also im Zweifel scheint die Elektronik der ganzen China-Quadkopter immer noch sehr ähnlich zu sein. Bisher gab es noch keinen Komplett-Reinfall.
Nachdem mir das Original Gehäuse immer wieder an den Armen bricht und auch kleben nur bis zum nächsten Crash hält, habe ich mir mal einen Rahmen aus FR4 für den kleinen gefräst. Das ganze ist einfach in Sandwich-Bauweise zusammen gesetzt. Ist glaube ich 1,5mm starkes FR4, also so wie Platinen-Material. Die Motoren sind mit Sekundenkleber eingeklebt (ist natürlich nicht ganz optimal). Der Rotor-Abstand ist etwas kleiner als beim Original-Gehäuse. Ist eventuell etwas wendiger, kann es noch nicht richtig beurteilen. Fliegen tut er mit dem neuen Rahmen sehr gut und liegt ruhig in der Luft. Mit dem original Gehäuse kommt es zum Teil zu Vibrationen, da die Arme nicht steif genug sind. Gewicht ist gegenüber dem Original um 1 Gramm leichter. Man könnte jetzt noch in der Mitte ein paar Ausfräsungen setzen und Carbon anstatt FR4 nehmen. Eventuell reicht aber auch eine Platte aus, da muss man nur die Motoren irgendwie gerade bekommen (evtl. kleine Hülsen um die Motoren, welche mit der Platte verklebt sind).
Ich würde mal nach aktuellen Erfahrungen mit dem "tmart" fragen. Zuächst wurde ich 1,5Monate hingehalten, und nun ist auch nach über einer Woche die neue Trackingnummer der Post noch immer nicht bekannt. Sind eure Teile bisher immer angekommen?
Michael D. schrieb: > Zuächst wurde ich 1,5Monate hingehalten, und nun ist auch nach über Bei was? Hast Du vorher schon einmal in China bestellt? > einer Woche die neue Trackingnummer der Post noch immer nicht bekannt. > Sind eure Teile bisher immer angekommen? Ja.
Michael D. schrieb: > Sind eure Teile bisher immer angekommen? Ich habe fast immer über Alibaba bestellt und nie Probleme gehabt. Die Lieferzeit variiert stark, zwischen 2 Wochen und fast 10 Wochen. Ein nicht unerheblicher Teil davon geht aber für die Strecke "Ankunft in Deutschland - Zoll - Auslieferung" drauf. 4 Wochen Lagerzeit im Zoll sind nicht ungewöhnlich. In einem Fall habe ich nach 60 Tagen Wartezeit reklamiert. Das Geld war innerhalb von 24 Stunden wieder da. Die Ware kam dann eine Woche später doch noch.
Tim schrieb: > Bei was? Hast Du vorher schon einmal in China bestellt? Ja habe bereits vorher in China bestellt gehabt, aber noch nie solche Probleme gehabt. Maximale Lieferzeit war bsiher immer 1Monat.
@Martin Sehr schöne Lösung! Hab da grad auch grad etwas konstruiert, allerding möchte ich die Motoren klemmen. Man weiß ja nie. Bin grad auf der Suche nach einer günstigen Möglichkeite 0.8mm CFK Fräsen zu lassen. Kennt jemand einen Service mit bezahlbaren Preisen bei guter Qualität?
Octo schrieb: > @Martin > > Sehr schöne Lösung! Meinst du mich? Wenn ja, danke :-) Octo schrieb: > die Motoren klemmen Und wie willst du das anstellen? Octo schrieb: > Kennt jemand einen Service mit bezahlbaren Preisen Also wir haben bei uns eine CNC in der Firma, die ich halt genutzt habe. Sollte auch CFK können (sagen zumindest die Kollegen). Ich habe mir eine 0.8mm Platte bestellt. Wenn du willst, kann ich deins mit fräsen oder so. Zeigst mal deine Konstruktion?
Robert Knipp schrieb: > http://www.aliexpress.com/store/product/free-shipping-ufo-vs-HUBSAN-NANO-Q4-H111-The-world-s-smallest-4CH-remote-control-toys/1093640_1859612633.html?spm=5261.7049941.1997368589.417&promotionId=253311003 > > $12,50 für 24h Habe heute ein unerwartetes Geschenk mit der Post bekommen (Ist ja schon so lange her...). Bilder anbei. Ist ein lustiges Ding, allerdings etwas träger als der JXD385. Am Design gibt es deutliche Unterschiede - alles ist ein bischen mehr Kostenoptimiert. Als RF-Transponder kommt ein anderer nRF24L01-Clone zum Einsatz, ein XN297. Der Controller wird vermutlich wieder ein Mini54ZAN sein, auch wenn die Kennzeichnung entfernt wurde. SWD ist herausgeführt. Der Intertialsensor befindet sich wohl auf der anderen Seite der Platine, wahrscheinlich wieder ein MPU6050. Leider kann man das Gehäuse nicht entfernen, ohne es zu zerstören. Für 9.50 EUR ungeschlagen im Preis/Leistungsverhältnis, aber nicht sehr hackerfreundlich...
Ähnelt dem von Revell. Nur das der von Revell um einiges mehr kostet. Aber deiner steht doch bei Ali für 35$, wie sind es dann 9,50 € geworden?
Mathias O. schrieb: > Aber deiner steht doch bei Ali für 35$, wie sind es dann 9,50 € > geworden? Als Robert den Links gepostet hat, gab es ihn für 50% off. Habe das Gehäuse übrigens doch aufbekommen. Auf der anderen Seite ist ein MPU6050, vier FETs als Motortreiber und ein LDO.
mahlzeit! bin recht neu hier, aber habe mich hier komplett durchgelesen...lustige truppe, nette ideen, aber irgendwie kam noch keiner auf die idee die mir die ganze zeit vorschwebt (wo das teil gerade nicht so gut schwebt ;-) ): den quadrocopter vergößern! d.h. die platine wird von den motoren befreit und die ausgänge der motoren werden zu einer steuerplatine um-geleitet an der sich zB normale brushless regler und motoren befinden. dann hätte man doch VIELE möglichkeiten den copter zu erweitern (gps, so ziemlich jede cam, parkplatz-finder, fpv, und was euch sonst noch in den sinn kommt/kam). leider habe ich lediglich ein einfaches multimeter, aber irgendwer hat doch sicher mal gemessen, was die motoren antreibt!? der PWM ausgang wird doch sicher mit xx kHz oder so beschaltet sein, mit der dann die motoren schneller oder langsamer laufen? just-my-2-cent gruß Kevin PS: ich fliege seit einem jahr den copter und habe nach zig rotorblättern den ersten motor auf dem gewissen. ;-)
habe heute mal meine Anleitung gescannt und in eine PDF geworfen, wenn die im wiki verlinkt werden soll/darf würde ich es machen oder einer von euch gründervätern macht das https://dl.dropboxusercontent.com/u/15577728/jd-385_manual/A5_manual.pdf
Moin. Also ich hab jetzt nicht alles hier gelesen, aber kann es sein das es keine Umstellung auf Mode 1 oder Mode 3 gibt??
Hallo allerseits, der Thread ist ja schon ein bisschen älter, trotzdem bin ich darauf gestossen weil wir für ein Uni-Projekt eine große Anzahl Mini-Quad mit openSource Firmware suchen. Der JD-385 mit bradwii-jd385 wäre da wohl ideal. Ich habe meine ersten beiden Quadcopter (JD-385) gelöscht und neu programmiert (download von https://github.com/hackocopter/bradwii-jd385); das ging recht problemlos. Einzige "Änderung": in Keils MDK -> Project -> Option-for-Target->Device->"Legacy Device Database [no RTE]". Allerdings kann ich mit dem neuprogrammierten Copter nicht per Fernsteuerung kommunizieren (meine Fernbedienung zeigt keine Reaktion). Nach Power-Up dauert es nun ca. 4 Sekunden bis die blauen LED angehen; dann signilisieren die LEDs die "Stabilität". So weit, so gut. Und wie weiter? Wie kann ich fliegen? Wenn ich jetzt meine Fernbedienung "binden" will (nach Einschalten linken Steuerknüppel "hoch und runter") weiss ich nicht ob das funktioniert (keine Rückmeldung vom Copter); wenn ich danach "armen" möchten (beide Steuerknüppel nach rechts unten) passiert gar nichts. Auch sonst keine Reaktion vom Quadcopter. Was mache ich falsch? Verstehe ich etwas nicht? Brauche ich eine andere Fernbedienung? Die "vorhandene" funktionierte vor dem Neuprogrammieren einwandfrei und läuft immernoch mit "Quad Nummer #3 (der NICHT neu programmiert wurde). Nur die zwei Quads auf die ich "bradwii-jd385" gespielt habe reagieren nicht auf meine Fernbedienung. Ich habe auch andere Fernbedienungen (V2x2 Protokoll) probiert; selber Effekt: vorher einwandfrei, danach nicht mehr. Ist die Software im repo "lauffähig"? Wer kann mir helfen??? Danke sehr! Grüße, Jörg
Hallo Leute, ich weiß ja nicht ob es noch jemanden interessiert oder schon bekannt ist. Aber ich habe bei Versuchen mit der Fernbedienung noch etwas festgestellt. 1. Der Schub lässt sich immer bis auf ff drehen, egal welche Geschwindigkeit eingestellt ist. 2. Auch auf voller Geschwindigkeit (Stufe 3) gehen Roll+Pitch nicht bis auf ff hoch, sondern bleiben deutlich darunter (kann mich an den genauen Wert nicht erinnern). Auf Yaw hab ich nicht geachtet, werde ich aber noch nachholen. 3. Wenn der Flip Button gedrückt wird, wird das Flag auf 04 gesetzt und Roll+Pitch können Vollausschlag (ff) annehmen. Wie es bei Yaw aussieht werde ich noch nachreichen, falls überhaupt Interesse besteht. VG Christopher
:
Bearbeitet durch User
Mit bradwii muss erst "gearmed" werden. Beide hebel nach unten rechts? Bin mir nicht mehr sicher. Am besten auch den rcgroups thread lesen. Sorry, habe gerade kein inet...
Danke für die schnelle "Vorab-Antwort" zu meinem Flugproblem. Das "armen" mache ich wie im Wiki beschrieben (beide Steuerknüppel nach rechts-unten --- nach dem "binding"); leider zeigt das keine Reaktion. Gibt es sonst noch einen "Trick" zum Starten? Und/oder kann mir jemand ein "fertiges" Firmware file (compiliert) von dem bradwii-jd385 - Projekt senden (hier als Anhang?)? Dann weiß ich zumindest, dass die Firmware auf dem Quad richtig ist und kann mit meiner Fernbedienung weiter experimentieren (wenn ich mit der FW das gleiche Verhalten sehe). Aber vielleicht mache ich ja auch beim Compilieren (im Keil IDE) etwas falsch, das könnte ich dann ansehen wenn "die andere" Firmware geht; meine aber nicht. Danke sehr! Freue mich auch weitere Vorschläge; bin gerne bereit das sofort auszuprobieren. Wer benutzt denn die Firmware "ohne Probleme"??? Auch mit einem "aktuellen" Keil - IDE? Danke, Jörg
Danke sehr! Habe ich jetzt ausführlich durchgelesen (nicht jedes Wort, aber doch jeden Beitrag)... hilft nicht weiter. Das "armen" mache ich wie beschrieben. Leider reagiert der JD-385 "gar nicht" - also ich kann keine Änderung erreichen. Ab wann sollte ich denn etwas sehen? Also z.B. anderes Blinken der LED und/oder Motorenbewegung? Erst nach dem "armen"? Kann ich feststellen, ob die Fernbedienung angebunden ("binding") ist?? Oder kann mir jemand der Mitlesenden sein Binary der Firmware geben? Es könnte ja sein, dass mein Compiler etwas falsch übersetzt... keine Ahnung... Freue mich auf weitere Tipps! Danke sehr! Jörg
:
Bearbeitet durch User
Hi, hast du mal probiert die Fernbedienung zurückzusetzen? ICch weiß gerade nicht wie das geht (aber es geht). Vielleicht sind bei dir die Mittelpunkte zu weit oben oder links und er erkennt es nicht als ganz unten rechts.
Christopher B. schrieb: > Fernbedienung zurückzusetzen Es wäre nett, wenn du bei Gelegenheit erkunden würdest, wie das geht und es hier posten würdest. In der Anleitung finde ich nämlich keinen Hinweis darauf.
Ich glaube du musst eine der beiden Schultertasten gedrückt halten beim einschalten. Die Fernbedienung müsste dann kurz anders piepsen. Jetzt wo ich nochmal darüber nachdenke, kann es auch sein, dass das bei der Fernbedienung vom V911 so war. Aber du kannst die ja auch so auf Mittelpunkt stellen, einfach so lange auf den Verstellknöpfen drücken bis es einmal länger piept. Zum Beispiel YAW erst ganz oft nach links drücken, wenn es piepst, bist du in der Mitte, wenn nicht, dann eben ganz oft nach rechts drücken. Irgendwann muss es länger piepsen und dass ist die Mitte. LG Christopher
Meinst du die Trimmung? Unter "Rücksetzen" verstehe ich etwas anderes.
Ja klar die Trimmung, was willst du sonst ab der Fernbedienung verstellt haben? Zumindest meine bietet nicht allzu viele Einstellungen... Und wenn du wegen der Trimmung nicht den im copter eingesehen Arm-Wert erreichst dann laufen die Motoren nicht an.
Hallo! Danke sehr! Habe meine Fernbedienung überprüft (FernedienungEN --- ich habe 4 verschiedene die alle "vor" der Custom-Firmware liefen); an einer verstellten Mittellage / Trimm liegt es nicht. Irgendwo anders muss "der Wurm drinsein". Also wie geschrieben kann ich compilieren, dann flashen und der Quadcopter zeigt "Lebenszeichen": Nach etwa 4 sek gehen die Lichter an; danach wird eine "Stabile Lage" durch die LEDs angezeigt. Software läuft also soweit. Aber dann... meine Fernbedienung kann keinerlei Reaktion hervorrufen. Sollte ich nach dem "binden" etwas sehen? Nach dem "armen" sollen die Motoren angehen; tun sie aber nicht. Was sollte ich am JD-385 noch beobachten? Kann mir jemand bitte eine funktionierende "bradwii-jd385" Firmware senden? Dann kann ich die Flashen und zumindest das Problem eingrenzen. Oder erinnert sich wer an "seltsame" Einstellungen im Keil-Compiler? Ich nutze einen ST-Link V2 (aber das Programmieren geht ja). Danke, Jörg
Hallo, Wenn du eh selber übersetzt, dann versuch doch mal in der Datei rx_v202.c in der Funktion set_bound die led aus zu schalten und danach in eine endlos schleife zu gehen. Dann weißt du ob die Verbindung zustande kommt. Ich werde nächste Woche mal bradwii ausprobieren. Kann am Wochenende nicht. Ist dann mein letzter jd-385... mein zweiter ist meiner Verlobten abhanden gekommen. Der flog so hoch dass ich ihn dann nichtmehr sehen konnte als sie mir im Panik die Fernbedienung wieder gab ;-D
Hallo ich nochmal, hast du deinen Transmitter auf Geschwindigkeit 3 eingstellt? Also nach dem Binden zweimal die Schultertaste oben links gedrückt? LG Christopher
Oha... nein, habe ich nicht. Typischer Anfängerfehler. Ich kann das leider erst am Mittwoch prüfen (bin unterwegs); melde mich dann aber gleich nochmal. Sorry wenn es wirklich das ist... klingt aber schon so, dass er ohne "volle Geschwindigkeit" eben auch das "arming" nicht hinbekommt... Sorry!!! Ich melde mich am Mitwoch...
Jorg C. schrieb: > ohne "volle Geschwindigkeit" eben auch das "arming" > nicht hinbekommt... Bei mir bindet er sich auch in Stellung "Anfänger" (Original Soft).
Georg G. schrieb: > Jorg C. schrieb: >> ohne "volle Geschwindigkeit" eben auch das "arming" >> nicht hinbekommt... > > Bei mir bindet er sich auch in Stellung "Anfänger" (Original Soft). Ja er Bindet. Nur bei der Originalsoftware musst du den Copter nicht "Armen". D.h. er fliegt automatisch los sobald du gas gibst. Bei Bradwii drehen die Motoren aber schon auf Nullstellung wenn er "gearmt" ist. Christopher B. schrieb: > Wie es bei Yaw > aussieht werde ich noch nachreichen, falls überhaupt Interesse besteht. Also ich habe das gestern nochmal probiert. Ja, bei YAW ist es genauso wie beschrieben, dass solange der "Flip-Button" gedrückt gehalten wird die Achsen bis zum Vollausschlag aussteuern. Ich arbeite gerade an einem "Repeater" der a) einen Empfänger darstellt und die Daten der Originalfernbedienung verwendet und b) einen Sender simuliert der die von der Fernbedienung empfangen Daten weiterreicht, bloß ohne das Flip-Flag. Mich interessiert wie der Copter sich verhält wenn die Achsen in Vollaussteuerung gehen, aber das Flip-Flag nicht gesetzt ist.
Danke --- Jetzt kann ich mit der "Custom-Firmware" einwandfrei fliegen. Es lag tatsächlich daran, dass in der "Default"-Einstellung das Arming (rechts-unten) nicht ging. Jetzt läuft es wieder. Vielen Dank nochmals an alle die mir geantwortet haben! Jörg
Hallo Jörg, freut mich dass es jetzt geht. Kannst du jetzt die vorkompilierte Firmware hier reinstellen? Dann brauch ich mir nicht Keil installieren um das zu übersetzen, wäre echt nett. lg Christopher
klar, hier ist eine compilierte Version der JD385-bradwii firmware. Allerdings nutze ich das Keil-IDE trotzdem um die Firmware auf den Copter zu übertragen (flashen). Keine Ahnung ob es dafür auch andere Tools gibt. Viel Erfolg! Jörg
Hier hat sich einer richtig viel Mühe gegeben und alles erklärt: http://www.rcgroups.com/forums/showthread.php?t=2278850 Respekt!
Hi! Hat jemand schonmal folgendes Problem erfolgreich gelöst: Der Copter resettet sich bei viel/schnell Schubgeben. Wenn ich ganz langsam abhebe geht es, aber ab und zu resettet er sich in der Luft. Gebe ich zu beginn schub crasht er sofort. Akku ist ein neuer dran (an nem anderen getestet) und ich hab auch gestern 4 neue Motoren eingebaut. Immer noch dasselbe Problem... Das ist echt ärgerlich :( Danke & Gruss, Simon
Hallo Simon, erfolgt das ganze mit der Stock Firmware oder mit Bradwii? Ansonsten wie alt sind deine Akkus? Bringen diese noch den notwenigen Spitzenstrom? Ich musste auch schon Motoren ersetzten, allerdings weil die verschlissen waren und keinen richtigen Schub mehr erzeugt haben. Beim Fliegen selbst hatte ich noch nie Probleme.
Es gibt Wettbewerb für JXD. Der Cheerson CX10 kostet nur 15 EUR: http://www.eevblog.com/forum/reviews/teardown-cheerson-cx10-mini-quadcopter/ Tear down: http://www.eevblog.com/forum/reviews/teardown-cheerson-cx10-mini-quadcopter/ Interessant ist, dass dieses mal ein microcontroller von ST zum Einsatz kommt.
:
Bearbeitet durch User
Hallo Zusammen, ich habe gerade ein wenig Zeit und beschäftige mich wieder aktiv mit dem kleinen. Nachdem ich die letzte Zeit nur gefolgen bin. Hierbei ist mir aufgefallen, dass es für den JXD 385 eine weitere Hardware gibt. Die von Tim Eingangs gepostet ist REV:02 vom 2013-06-27 Ich habe hier noch die REV:05 vom 2013-08-22 Auffällig hierbei die Bestückung des Funkchips direkt auf der PCB mit Epoxy vergossen und der ?Widerstände? welche zu den ?Analogeingängen? des Controllers gehen. Damit stellt sich mir allerdings die Frage wie bei REV:02 die Batteriespannung überwacht wird?
Nochmal zum Ladegerät: Ich habe 3 etwas stärkere Akkus gekauft. Zwei davon sind jetzt wohl defekt, der Kopter geht nach gut 30 Sekunden zu Boden. Beim Laden habe ich jetzt tatsächlich 5V an den Akkus gemessen! Die LED des USB-Laders leuchtet dunkel vor sich hin, Strom noch gut 80mA. Also unbedingt eine andere Lösung zum Laden verwenden!
Hallo Chris, ja ist leider so! Die Ladegeräte die dabei sind tötlich für die Akkus! Ich habe Ladegeräte und alle sind gleich: - Ester ProtoX - WLtoy V272 - JXD 385 - JXD 388 Habe die Kabel alle abgeschnitten und durch einen JST-Stecker angelötet. Jetzt kann ich mit dem iMAX B6 Laden oder mit diesem kleinen Platinchen: http://www.ebay.de/itm/371204483020
Tim schrieb: > Es gibt Wettbewerb für JXD. Der Cheerson CX10 kostet nur 15 EUR: > > http://www.eevblog.com/forum/reviews/teardown-cheerson-cx10-mini-quadcopter/ > > Tear down: > http://www.eevblog.com/forum/reviews/teardown-cheerson-cx10-mini-quadcopter/ > > Interessant ist, dass dieses mal ein microcontroller von ST zum Einsatz > kommt. Sehr interessant, mal ein Teil mit vernünftigem MCU :)
Hallo Zusammen, beschäftigt sich noch jemand mit dem Quad? Ich versuche immernoch eine Rückmessung der Batteriespannung hin zu bekommen. Allerdings finde ich keinen "vernünftigen" Punkt wo ich die Batteriespannung mehr oder minder stabile abgreifen kann. z.b. P1.5 geht auf AIN5, in Rev05 gibt es hier auch einen Spannungsteiler der auf ~4V Eingangsspannung 0,3V am P1.5 anliegen lässt. Allerdings fällt diese Spannung beim Fliegen auf nahezu 0V ab, ist also unbrauchbar. Darüber hinaus ist mir aufgefallen, dass 2 Spannungsregler verbaut sind! Einer auf der Vorder und einer auf der Rückseite! Hat schon jemand eingefangen einen Schaltplan zu reichnen? Ansonsten werde ich mich mal an die Arbeit machen, und sehen was ich dabei heraus bekomme.
B. G. schrieb: > Hat schon jemand eingefangen einen Schaltplan zu reichnen? Welchen Quadcopter meinst du? Für den JD385 findest du alles auf Github, steht weiter oben im Thread.
Hallo Georg, ja ich meinte den JD385. Sry, der Thread ist inzwischen recht lang und unübersichtlich geworden. Ich habe nur deinen Schaltplan der Funke gesehen. Dann werde ich mal deinen Schaltplan des Kopters erweitern... Hat jemand eine Idee für was der 2. Spannungsregler sein kann? Ref. Spannung für den ADC?
B. G. schrieb: > Hat jemand eine Idee für was der 2. Spannungsregler sein kann? Ref. > Spannung für den ADC? Siehe Schaltplan... der Entwickler war nicht allzu helle.
Hallo Georg, wir reden jetzt beide von diesem Schaltplan (link) und dem JXD385 Quad und nicht von der Funke? https://github.com/hackocopter/JD385_Documentation/blob/master/Quad%20Hardware/Circuit%20Diagrams/Copter00.pdf Stehe wohl grad ein wenig auf dem Schlauch...
:
Bearbeitet durch User
Ich glaube da fehlt in der Tat der zweite Spannungsregler. Ich bin mir aber auch nicht sicher, welchen Zweck der erfüllt.
Sorry, ich war gedanklich auch bei der falschen Platine. Aber auf "meiner" Copter Platine ist kein zweiter Spannungsregler zu finden. Wo sitzt der? Foto?
Da hättest Du besser den Hubsan X4 mit Kamera bestellt - die Qualität der Aufnahmen ist eigentlich ganz ok. Denke daran, daß "oben" immer mehr Wind weht als unten und daß es nicht so einfach ist, wenn die Orientierung des Quadrocopters nicht mehr mit der eigenen Ausrichtung übereinstimmt - also Obacht bei Drehungen in luftiger Höhe!
Rüdiger schrieb: > "oben" immer mehr Wind weht als unten Imho ist der Zwerg für draußen nicht geeignet. Ich habe es einmal abends an einem windstillen Tag versucht. Am Boden war es wirklich windstill. Aber in 5m Höhe hat es den Copter in Sekunden Schnelle 30m weit weg geweht - mit Bruchlandung und einem defekten Motor. Um die Orientierung zu erleichtern, sollte man vielleicht eine rote und eine grüne LED an den Seiten anbringen.
Hier sind die Bilder: Beitrag "Re: Hackbarer(?) 21 EUR Quadcopter" Bei den Akkus Pads befinden sich sowohl auf der Vorder als auch auf der Rückseite ein Bauteil im SOT-23 Gehäuse mit dem Code "65Z5" Bei beiden liegt an Pin 3 die Akkuspannung und an Pin 2 3.0V...
Guten tag , habe den mould king x6 "china quadcopter" und bekomme keine verbindung zur Remote mehr hin, die leds blinken gleichzeitig und weiß nicht was zutun, vielleicht weiß jemand was. mfg
Mahlzeit @tobias schu ! Dein "mould king x6" ist nicht der hier besprochene Quadcopter, ich bezweifle dass hier jemand helfen kann. Allerdings habe ich bei verschiedenen Modellen eine Gemeinsamkeit gesehen: 1. Funke an (Gas UNTEN) 2. Akku im Quadcopter anschließen 3. Gas hochschieben (zumeist blinken Quadcopter und Funke irgendwann syncron) 4. Gas wieder runter 5. fliegen...
Ich habe mich jetzt lange nicht mit "den Kleinen" beschäftigt, aber dieses Video ist wieder eine Inspiration: https://www.youtube.com/watch?v=w2itwFJCgFQ#t=153 Ein paar reflektierende Kugeln wiegen nix und so ein Netz (Bild) auch nicht. Die rote Linie ist die Flugbahn der Kugel im Netz - zurück zur Person! Aktuell habe ich aber nur zwei Quadcopter und drei weitere Projekte am Laufen.
:
Bearbeitet durch User
In der Hoffnung, dass einige der damaligen Mithacker hier noch lesen: Hat noch jemand ein funktionsfähiges PCB mit der originalen Software zum Verkauf und würde es abgeben? Bei Aliexpress habe ich leider nichts mehr gefunden.
Ich müsste meinen noch irgendwo haben, wenn ich ihn beim Umzug nicht entsorgt habe. Ich schau heute abend mal, dann kannst du ihn haben!
Wen es interessiert: Der Hack-O-Copter lebt im rcgroups Forum weiter. Dort wurden inzwischen wohl schon viele andere Typen "gehackt": https://www.rcgroups.com/forums/showthread.php?2278850-BradWii-revolution-!!-(for-toy-quadcopters)
Bei der Gelegenheit: Mein Enkel hat das gute Stück etwas hart auf einem Fliesenboden gelandet. Das hat die Elektronik nicht überlebt. Falls also jemand noch ein Exemplar hat, bei dem die Elektronik spielt aber die Mechanik (Rotor, Motor, ...) defekt ist, wäre ich interessiert.
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.