hier noch die von Harald angesprochene Version. " Sensor on Board "
Druckbare Version
hier noch die von Harald angesprochene Version. " Sensor on Board "
Testboard deshalb, weil ich nicht weiß ob die Software mit den jetzt verwendeten Anschlüssen zurecht kommt, oder ob es besser andere wären.
Ich dachte halt so wie ein Arduinoboard zum Ausprobieren.
Es wäre schön, wenn sich auch mal jemand über die Software äußern würde, machbar oder nicht?
Gruß Bernd
Also ich würde als "Testboard" ebenfalls das hier bereits diskutierte verwenden. Wenn Chris uns die Prototypen ätzen könnte wäre das doch optimal. Ansonsten müsste man nur wieder ein Board mehr erstellen, löten etc. Wenn auf dem Prototypen was falsch ist muss man halt mit Kupferlackdraht ran, aber immerhin hat man dann ein einsatzbereites Board. Ich wäre für den PDI Stecker, da der Bootloader wieder eine andere Baustelle ist, und zu testen ob der ganze Krempel überhaupt funktioniert erfordert viiiiele Programmiertests. Da ist mir halt ein Stecker lieber. Auch weiß ich noch nicht wie das im Xmega mit dem Eeprom funktioniert. Das kommt alles später, erstmal muss der Xmega einen Copter zum fliegen bringen.
Die paar Sachen die ich bisher gelesen habe klingen sehr vielversprechend. Wie das aber im Detail mit PWMs, UARTs, I²C usw. funktioniert weiss ich noch nicht. Bootloader und EEprom sind wieder anders. Aber wir sind ja nun ein paar mehr Leute (z.T. sogar schon mit xmega erfahrung), vielleicht kann sich jeder auf einen Teil konzentrieren und wir führen die Lösungen dann Schritt für Schritt zusammen.Zitat:
Es wäre schön, wenn sich auch mal jemand über die Software äußern würde, machbar oder nicht?
Was mir noch einfällt: Bei meinen layout mache ich die Solderpads für SMD Teile immer eine Ecke länger. Dann komme ich besser mit dem Lötkolben dran. Sind die Pads der IMU lang genug?
Wenn Bernd das Pad von mir verwendet hat, dann sind die Pads länger als Original und lang genug (Sven und ich haben mit diesen Pads schon insgesamt 5 Copter gelötet).Zitat:
Zitat von Willa
Also gut, dann überarbeite ich das Board mit den 6 Motoren ( je ein Anschluß ) und dem extra Sensor für 1,27 mm Stecker (oder besser Buchse, gegen Kurzschlüsse beim Absturz :-) ), die nehmen auch nicht mehr Platz weg als die Pads.
Die wichtigen Pads bei der IMU sind schon etwas länger. (da war ich zu langsam)
Weitere Wünsche??
Ich kann auch zwei oder drei verschiedene Layouts machen.
Gruß Bernd
Ich habe das Schaltbild nach bestem Wissen und Gewissen so ausgelegt, dass die Ports passend zur Aufgabe gewählt sind.Zitat:
Zitat von bendh
Also einen HW-UART für den Empfänger (ok, hier muss noch die Beschaltung des Steckers geändert werden), einen weiteren HW-UART für die Kommunikation zur GUI [edit] die beiden UARTs können vertauscht verwendet werden, wenn die Stromversorgung besser an den GUI-Stecker gebracht werden kann [/edit] , die sechs HW-PWM-Ausgänge für die ESC-Ansteuerung, einen HW-I²C-Port für den MPU, einen weiteren HW-I²C-Port für den potentiellen Versuch von Willa, seine ESCs über die Konverter anzusprechen.
Den Kleinkram (im Wesentlichen sind das noch die LEDs) habe ich dann noch auf die restlichen freien Ports verteilt und dabei versucht, kurze Leitungen zum geplanten Einbauplatz (der LEDs z.B.) zu ermöglichen.
Reset, Quarz, PDI sind vorgegeben.
Also, ich würde sagen, mit dieser Beschaltung können wir ins Rennen gehen.
?? Welcher extra Sensor? Habe ich einen oder mehrere Posts übersehen?Zitat:
Zitat von bendh
Eine Leitung von Pin 12 des MPU nach Pin 25/26/27 des Atmel -> Interrupt wenn neue Sensordaten im Ausleseregister stehen. Damit kann dann auch der MPU-interne Fifo verwendet werden. (Keine Ahnung, ob wir das nutzen können, aber wenn es Willa packt, dann findet er bestimmt raus, wie er an seine Euler- und sonstigen magischen Zahlen im MPU ran kommt, und die werden, glaube ich, über das Fifo ausgespuckt).Zitat:
Zitat von bendh
William möchte, glaube ich gelesen zu haben, auch lieber den Sensor auf einem extra Board.
Ja. Ursprünglich hätte ich es auch schicker gefunden nur ein Board inkl. Sensor zu haben. Aber Bernd hat recht, die Sensoren ändern sich dauernd (bleiben aber hoffentlich bei I²C und 3.3V). Somit hätte man ein board mit höherer Habwertszeit. Außerdem kann man so den Sensor besser lagern. Ich würde das Hauptboard mit Kunststoffschrauben vibrationsgedämpft anbringen. Dann kommt das IMU Board mit doppelseitigem Schaumklebeband oben auf den xmega drauf. Diese doppelte Entkopplung könnte was bringen. Vielleicht auch für den SNQ, denn dort sind die motoren ja "direkt an die IMU geschraubt".Zitat:
William möchte, glaube ich gelesen zu haben, auch lieber den Sensor auf einem extra Board.
Harald, wie ist das denn bei der IMU? Wie schnell kommen da neue Werte raus? Etwas weiter oben im Thread hast du geschrieben, dass du oftmals die gleichen Werte ausliest. D.h. die Daten kommen lansamer als mit 500Hz? Wenn dem so ist, ist das für den PID Regler natürlich ziemlich schlecht. Besonders für den D-Anteil, der ja zwei aufeinanderfolgende Werte vergleicht. Zu wissen wann neue Werte da sind ist also ziemlich wichtig.Zitat:
Eine Leitung von Pin 12 des MPU nach Pin 25/26/27 des Atmel -> Interrupt wenn neue Sensordaten im Ausleseregister stehen
Ich würde jetzt bei Reichelt mal die benötigten komponenten bestellen (Harald, hast du noch eine IMU für mich?)
Ich habe gelesen, dass der AVR ISP mk2 PDI unterstützt und auch direkt mit BASCOM funktioniert. Den gibt es bei Reichelt:
http://www.reichelt.de/Programmer-En...T=0&OFFSET=16&
Allerdings steht dort im Datenblatt nichts von PDI... Ist dass der richtige? Gibt es funktionierende Alternativen?
Im datenblatt des MPU600 lese ich beim Gyro:Zitat:
Wie schnell kommen da neue Werte raus?
OUTPUT DATA RATE Programmable 4 - 8000 Hz
und beim ACC:
OUTPUT DATA RATE Programmable Range 4 - 1000 Hz
Zitat:
The Sample Rate is generated by dividing the gyroscope output rate by SMPLRT_DIV:
Sample Rate = Gyroscope Output Rate / (1 + SMPLRT_DIV)
where Gyroscope Output Rate = 8kHz when the DLPF is disabled (DLPF_CFG = 0 or 7), and 1kHz when the DLPF is enabled (see Register 26).
Note: The accelerometer output rate is 1kHz. This means that for a Sample Rate greater than 1kHz, the same accelerometer sample may be output to the FIFO, DMP, and sensor registers more than once.
Was habt ihr da in euren fliegenden Coptern eingestellt?
Noch etwas kleiner
Sieht echt super aus, richtig kompakt. Harald muss sich dann noch mal äußern ob Pin12 der IMU wirklich gebraucht wird, oder ob man vieleicht die Refresh rate der IMU hochsetzen kann. Pin12 an die Steckerleiste zu bekommen ist scheinbar etwas Aufwand...Zitat:
Zitat von bendh
ich muß gestehen, dass ich bis jetzt nur MultiWii-Kopter mit der MPU6050 in die Luft bekommen habe.
Mit der Software von Harald gibt es nur sehr kurze unruhige Flüge die, wenn ich sie nicht schnell beende, mit einem Überschlag enden.
Es hilft bis jetzt auch nicht die Werte in der GUI zu verändern, da wird alles zwar träger, aber auch nicht fliegbarer.
Es könnte aber auch seine Impulserzeugung sein, evt. ist sie nicht schnell genug. So flogen meine Kopter, wenn die ESCs nicht geeignet waren.
Zum testen verwende ich aber immer dieselbe Mechanik und ändere nur die Software. Beides, Willa und Wii Software läufen auf einem ATmega 328.
Ich habe aber keine Ahnung von der Software und habe meine Änderungen im Arduino-Sketch beim Wiikopter immer mit ausprobieren erreicht.
Gruß Bernd
Hi Willa,
den selben Programmer habe ich mir vor kurzem auch bei Reichelt bestellt. Anfangs hatte ich auch bedenken, weil im DB nichts von der PDI Schnittstelle steht, aber er kanns ;) Die Einbindung in BASCOM ist auch ganz einfach und in der Hilfe von BASCOM findet man eine gute Anleitung, auch bzgl. des Treibers usw....
Falls du Fragen zur Programmierung des XMegas hast, stehe ich gerne zur Verfügung. Habe schon fast mit allen Schnittstellen gearbeitet.
Eine Frage habe ich aber noch:
Wäre es nicht sinnvoll, den MPU6000 zu verwenden und diesen über die SPI Schnittstelle auszulesen? Ich werde das heute mal testen. Damit wäre der Kontrollloop nochmal schneller, da man auf das Senden der Adresse verzichten könnte und der Sensor bis zu 1Mhz Taktrate funktioniert.
Gruß
Chris
EDIT:
Habe gerade mal deinen Code vom Bolt auf einen XMEGA64A3 mit MPU6000 (I2C) umgeschrieben und an den PC angeschlossen. Es funktioniert ;)
Natürlich ist jetzt noch kein Empfänger dran und auch keine Motoren, aber die PWM funktioniert (6 mal Hardware PWM mit 500Hz und 16Bit Auflösung) und die Sensorwerte werden in der TRIGuide angezeigt. Einziges Manko:
Der Sensor liefert 16Bit Werte, somit müsste man einige Variablen noch anders definieren und auch die OFFSET-Berechnung kann wegfallen (MPU gibt bereits Integer aus) und eben noch ein paar Kleinigkeiten. Aber im Prinzip war das eine Änderung innerhalb 20Minuten. Wenn Interesse besteht, würde ich den Code (von Willa!!!) reinstellen.
Hallo Chris,
das sind ja tolle Neuigkeiten.
Kommst du mit dem von mir erzeugten Layout zurecht, oder soll ich da noch etwas anpassen?
an alle:
ist das letzte Layout in Ordnung, oder hat noch jemand Wünsche?
Nur eine Quattro-Version oder bestimmte Pads auf Stecker oder noch kleiner oder....
Gruß Bernd
Hallo Bernd,
hm ich habe bis jetzt noch nie ein EAGLE Layout gedruckt und geätzt, aber das sollte kein Problem werden. Aber könntest du mir bitte einen Gefallen tun? Ich weiß leider nicht, wie man einen Design Rule Check in Eagle macht. Könntest du für den Mindestabstand von Kupfer zu Kupfer (also Leiterbahn - Leiterbahn, Leiterbahn - Loch, SMD Pad - Leiterbahn, usw...) 0.15mm (also ca. 6mil) eingeben und den Test durchlaufen lassen? Es wären zwar auch geringere Abstände möglich, aber ich möchte gerne informiert sein ;)
Ich habs gerade selbst probiert, aber irgendwie kommen bei mir 113 Fehler. Teilweise wird der Abstand eines SMD-Pads mit sich selbst angezeigt xD
Gruß
Chris
EDIT:
Wäre es noch möglich, dass du eine "Automasse" einfügst, damit ich etwas Natriumpersulfat sparen kann? Auch das kann ich leider nicht, da ich noch nie mit Eagle gearbeitet habe.
EDIT2:
Habe gerade versucht, das Layout mal auszudrucken, jedoch habe ich dabei ein Problem: Ich habe den Hacken bei "Schwarz" gesetzt, trotzdem wird es nur sehr blass-blau ausgedruckt, fast nicht sichtbar... Wahrscheinlich muss man es anders machen, oder?! Ich habe die ganz normale "Drucken" Funktion verwendet.
Hallo Chris,
da hast du dir aber etwas vorgenommen, dieses Layout auszudrucken und zu ätzen, ist doch alles ziemlich eng und klein.
Kannst du auch Lötstoplack aufbringen? Das ist wohl nötig um den Sensor ohne Kurzschluss zu löten.
Automasse? Wegen dem bisschen Ätzmittel sparen, aber auf der anderen Seite sollen die Kopter das schwere Kupfer schleppen?
Zum Ausdrucken:
du darfst nur die Layer anzeigen lassen, die du wirklich brauchst, also 1, 17, 18 und höchstens noch 20.
Du siehst ja auf dem Schirm was noch übrig bleibt. Also oben links unter dem i das Display für Layer öffnen, dann Keine drücken und dann einfach einmal 1 und OK, du siehst dann was übrig bleibt.
Dann bei Drucken Schwarz und bei mir auf dem Laserdrucker sieht es ganz gut aus.
Gruß Bernd
Hallo Jungs, ihr seid mir leider etwas zu schnell... das richtige Leben fordert zwischendurch auch mal seinen Tribut ;-)
Aber ich versuche mal, auf die Postings seit meinem letzten Post zu antworten...
Ok, das mit der Updaterate des Sensors habt ihr ja schon selbst raus bekommen: 8 kHz für die Gyros, 1 kHz für die ACCs.
Die sNQs fliegen bei Sven mit voller Samplerate, also keine Dämpfung aktiviert. Mein sNQ flog damals mit eingeschalteter Dämpfung (der MPU hängt ein Filter vor die Ausgabe der Werte), was impliziert, dass die Samplerate auch bei den Gyros auf 1 kHz runter gesetzt wird. Was dabei bei den ACCs passiert habe ich nicht gelesen, evtl stehts nicht drin oder ich hab´s vergessen.
Ankopplung des MPU an den Atmel: SPI ist zwar 2,5 mal schneller bei der Übertragung, man sollte aber mal überschlagen, was das letztlich bringt. Kann ich bei Gelegenheit nachtragen, habe gerade keine Lust lange rum zu rechnen.
Den IRQ habe ich verdrahtet, um ausschließen zu können, dass das von mir immer beobachtete Rauschen auf den ACC-Werten von unkoordiniert ausgelesenen Halbworten verursacht wird.
"Refreshrate des IMU hochsetzen" ist mir nicht geläufig, Willa hat die Maximalwerte angeführt, schneller gibt der MPU nichts aus.
Mit ein bisschen Magie an den Registern des MPU kann man maximal 1000 Werte in ein internes Fifo ablegen lassen und das dann in einem Rutsch so schnell wie möglich auslesen (in diesem Betriebsmodus (bis zu 500 Integers in einem Rutsch) kann ich mir einen positiven Effekt durch schnellere Übertragung per SPI tatsächlich vorstellen. Bei 5 Integers in jedem einzelnen Durchlauf ist der Unterschied eher unbedeutend (nur Bauchgefühl, sollte wie gesagt mal jemand durchrechnen).
Als Programmer habe ich mir den DIAMEX ALL-AVR von Reichelt geholt, der soll die XMegas per PDI programmieren können.
Hallo Bernd,Zitat:
Zitat von bendh
also das machst du wirklich Klasse! :-)
Eine kleine Anmerkung habe ich noch zu deinem letzten Layout.
Ich lege die Masse bei einseitigen Layouts immer als Ring komplett außen rum, wenn es sich einrichten lässt.
So wie du jetzt entflochten hast, "baumelt" der Quarz ganz am Ende ewig weit weg vom Akku massetechnisch in der Luft rum.
In gewisser Weise gilt das auch für den MPU.
Andererseits sitzt direkt im Pfad vor dem Quarz der Atmel, der durch die Schaltvorgänge an seinen Ausgängen die Masse ziemlich in Unruhe versetzt.
Würdest du auf 12 Uhr die Masse (an der Referenz vorbei mit dicker Leitung) zum Ring schließen, wäre das "Rumbaumeln" weg.
Gibt es dazu andere Meinungen? Oder Bestätigungen? Würde mich interessieren, ob ich mit dieser Betrachtungsweise alleine dastehe.
[edit]
Du hast verschiedene der Kondensatoren als 0402 verbaut (die 4 Blockkondensatoren um den Atmel herum), alle anderen aber auf 0603 belassen.
Absicht? Vermutlich. Der Hintergedanke dabei?
Na ja, den Trick mit der Massefläche habe ich auch angewandt, als ich noch selbst geätzt habe. Die Ersparnis an Ätzmittel ist nicht zu verachten, es muss ja nicht nur um das gesparte Geld gehen, man tut auf diese Weise auch der Umwelt was Gutes.Zitat:
Zitat von bendh
Das gesparte Gewicht, wenn man die Fläche komplett frei ätzt, ist hingegen wahrscheinlich zu vernachlässigen.
@Chris:
Du musst ein Polygon um die komplette Fläche herum legen und dann den Ratsnest-Befehl ausführen.
Anhang 21900
[edit]
ACHTUNG!!
Entweder den Einbauplatz des Quarzes sperren (ein Rect im Layer "tRestrict (41)" um den Quarz herum legen), so dass dort kein Kupfer flächig verlegt wird, oder das flächig belegen komplett weg lassen.
Ich habe leider offenbar das Layout des Quarzes falsch erzeugt, so dass die Pads (die ich gegenüber den Originalpads durch Überlagern mit Kupferflächen vergrößert habe) beim Fluten mit Kupfer kurzgeschlossen werden.
Super, wäre schön wenn du den hier reinstellst. Da habe ich dann nicht mehr so viel zu tun mit dem ändern. Wenn das letzte Byte wie Harry beschrieben hat eh nur rauschen ist, kann man das ja auch weglassen... Ich werde mir das dann mal angucken.Zitat:
EDIT:
Habe gerade mal deinen Code vom Bolt auf einen XMEGA64A3 mit MPU6000 (I2C) umgeschrieben und an den PC angeschlossen. Es funktioniert :wink:
Natürlich ist jetzt noch kein Empfänger dran und auch keine Motoren, aber die PWM funktioniert (6 mal Hardware PWM mit 500Hz und 16Bit Auflösung) und die Sensorwerte werden in der TRIGuide angezeigt. Einziges Manko:
Der Sensor liefert 16Bit Werte, somit müsste man einige Variablen noch anders definieren und auch die OFFSET-Berechnung kann wegfallen (MPU gibt bereits Integer aus) und eben noch ein paar Kleinigkeiten. Aber im Prinzip war das eine Änderung innerhalb 20Minuten. Wenn Interesse besteht, würde ich den Code (von Willa!!!) reinstellen.
@Harald: Hast du noch eine MPU IMU über? man bekommt die ja schon wieder nirgends...
@All: Ich habe die nächsten zwei Wochen sturmfrei hier bei mir... D.h., ich kann ohne verständnisslose Blicke (die sind ja zum Teil auch gerechtfertigt...) ein paar Nachtschichten einlegen. Es wäre also super wenn wir es schaffen möglichst bald eine finale Platine zu haben, und wenn Chris die ätzen könnte. An der Platine wüsste ich nichts mehr auszusetzen, außer dass man die Borlöcher anders setzen sollte, aber das macht eh jeder selbst. (Chris, sind die genutzen PWM ports die richtigen? Oder muss man da auf irgendwas achten?)
Na ja, lässt du das Byte weg per Ausmaskieren, dann springen die Werte um 256.Zitat:
Zitat von Willa
Rechnest du das Byte raus per Teilen, werden die Werte entsprechend klein und passen nicht mehr zu deinen Algorithmen.
Ich wäre heilfroh, wenn sich das Thema mal jemand anschaut, der, so wie du, schon den einen oder anderen Copter mit deinem Code zum Fliegen gebracht hat :-)
Ja, habe ich. Noch 2 übrig.Zitat:
Zitat von Willa
Super!Zitat:
Zitat von Che Guevara
Hast du mal auf die Sensorwerte im Sinne von "Rauschen" geachtet? Zappeln die Anzeigen wild rum, oder stehen die wie eine Eins?
Naja, ohne Motoren waren meine Anzeigen in der GUI auch ganz brauchbar...
Hi,
Code ist im Anhang, da er zu groß für die CodeTags ist.
Es waren auch nicht sehr viele Änderungen, hauptsächlich habe ich die ganzen Variablen für die Regelung von Integer auf Long geändert, damit keine Überläufe mehr vorkommen. Dann noch den MPU integriert, die typischen XMEGA Geschichten eingefügt (Config Priority, Open "COM2", ADC Settings, usw...) und ein paar Änderungen gabs noch bei der GUI Connection bzgl. Skalierung. Aber seht selbst ;)
Zu den PWM Ports:
Beim XMega64A3 gibt es
- TCC0 (Portc.0 - Portc.3)
- TCC1 (portc.4 - Portc.5)
- TCD0 (portd.0 - portd.3)
- TCD1 (portd.4 - portd.5)
- TCE0 (porte.0 - porte.3)
- TCE1 (porte.4 - porte.5)
Aufs Layout habe ich es jetzt nicht angepasst, aber ich denke, bei der Auswahl sollte das kein Problem sein.
@Harald:
Nein, habe ich noch nicht sooo genau gemacht, aber das werde ich mal demnächst machen. Mir stellt sich sowieso die Frage:
Sollte man die Werte der Sensoren entweder auf 12Bit Auflösung (wie im Original) kürzen oder mit den vollen 16Bit rechnen? Dann wäre ggf. der interne Digital Lowpassfilter angebracht. Grundsätzlich sehen aber die Sensorwerte gut aus.
"Rumzappeln" tun sie auf jeden Fall nicht und in der Gui stehen sie wirklich fast wie eine Eins ;)
Info:
Im Code habe ich die "Gyro / ACC Reverse" Funktionen gelöscht, da man das ja dann fest einstellen kann. Das stimmt ggf. noch nicht. Wie gesagt ist der Code sowieso nur ganz Grob abgeändert, aber grundsätzlich funktionierts.
Gruß
Chris
Hallo Bernd,Zitat:
Zitat von Willa
wegen der Bohrlöcher könntest du noch die Leiterbahnen nach innen "biegen", dann wird Raum für die Platzierung der Löcher frei.
So in etwa:
Anhang 21906
Ich habe hier auch mal probeweise die Masse geschlossen und dem Sensorboard einen Rahmen verpasst.
So nun die bisher letzte Variante.
Wer es noch kleiner braucht, man könnte die überflüssigen Pads noch weglassen.
Wem es zu klein ist, größer machen kein Problem, ich bin aber auf 80x100 mm beschränkt. :-)
Wenn nun jeder sein OK gegeben hat, könnte man anfangen.
Hi,
wollte gerade versuchen, die Automasse einzuzeichnen. Habe als erstes alle Layer bis auf 1,17,18 und 20 ausgeblendet und dann ein Polygon um die komplette Platine eingezeichnet. Anschließend bei dem Click auf Ratsnest kommt eine Fehlermeldung,
"Signal 'N$36 enthält ein ungültiges Polygon" beim Klick auf Ok kommt dann "Fehler beim Berechnen der Polygone!". Wahrscheinlich mache ich irgendeinen Fehler. Gibts irgendwo eine kurze Anleitung zu dem Thema oder würde sich jemand von euch bereit erklären, das Layout bei sich schnell zu ändern und dann nochmal hochzuladen?
@Bendh:
Hm so klein finde ich das gar nicht, das ist bei mir Standart, da ich kleinere und filigranere Leiterbahnen einfacher schöner finde ;)
Vielen Dank & Gruß
Chris
Hallo Chris,
ich hoffe das hilft dir weiter. Ich musste nach dem öffnen nochmal Ratsnest drücken.
Welches Verfahren wendest du an um so enge Strukturen zu belichten und zu ätzen?
Wenn du das wirklich ätzen kannst, wäre bei den Massebahnen noch etwas machbar.
Gruß Bernd
Hi,
danke, jetzt funktionierts und wird auch richtig ausgedruckt ;)
Also ich belichte mit einem 500W Halogenstrahler (ich hatte nie Probleme damit, die Qualität ist stets gleichbleibend, es ist eine punktuelle Lichtquelle, usw...) ca. 1Min 30Sek lang, danach mit 20g NaOH auf 1l Wasser entwickeln und dann mit einer selbstgebauten Ätzküvette mit NaPS ätzen. Klappt alles wunderbar, selbst 0.05mm dicke Leiterbahnen kann ich ätzen. Nur dann muss ich schon seeeehr genau arbeiten, damit sich nirgends ein Staubkörnchen beim Belichten einschleicht.
Normalerweise verwende ich für Standartleiterbahnen entweder 0.15, 0.20 oder 0.30mm Dicke, kommt auf den verfügbaren Platz und den Strom an.
Natürlich kannst du die Massebahnen noch etwas verengen, für mich ist es kein Problem ;) Dann aber wieder bitte mit einer extra Version für mich, wenns dir keine Ümstände macht :D
Gruß
Chris
EDIT:
Eine Frage an alle: Ich müsste wissen, wer eine LP möchte, damit ich notfalls noch welche Bestellen kann. Und ich wollte wissen, wie ihr sie gern haben möchtet? Gebohrt, nicht gebohrt, einzeln ausgeschnitten, usw... Wäre nett, wenn ihr euch da auf etwas einheitliches einigen könntet.
Ich hätte gerne je 1 Hauptplatine und 1 Sensorplatine.
Bohren und ausschneiden ist nicht notwendig.
wenn möglich 1mm oder 0,8 mm dick.
Und dann noch eine Kontonummer für die Unkosten :-)
Gruß Bernd
HI CHris,
für mich bitte die selbe Combo. Also eine Hauptplatine und eine Sensorplatine und eine Kontoinfo. Die Dicke ist mir egal.
"Nicht ausschneiden" bedeutet was? Ich bekomme alle Platinen aller Besteller??... ;-)
Kaum, oder?
@Bernd:
Also normalerweise arbeite ich nur mit 1.5mm, d.h. wenn du es dünner willst, müsste ich extra eine Basisplatine bestellen?! Das wären dann aber Mehrkosten in Form der Versandkosten (hab grad selber nix zum Bestellen) und es würde länger dauern ...Möglich wärs aber durchaus ;)
@Harald:
Ok, geht klar ;) Ausgeschnitten bedeutet, dass ich die beiden Platinen nach dem Ätzen voneinander trenne und die Konturen abschneide ;) Übrigens: Jetzt funktionieren schon 2 der 3 MPUs, den Dritten konnte ich noch nicht testen. Der Fehler lag in der Adresse, da ich den AD0 Pin auf Masse gelegt habe und somit ist die Adresse nicht &HD2, sondern &HD0 :)
Ohne DLP des MPU ist schon ein deutliches Wackeln der Werte zu sehen. Heute habe ich mal den Wert durch 64 geteilt, was einer Auflösung von 10Bit entspricht, dann schwankt der Wert nur um 1. Also genauso so genau wie ADXRS610, wenn ich mich nicht irre ;) Bzw. eig sogar noch besser, da ich ja keinen DLP verwendet habe. Willa hatte ja auch einen Tiefpass verbaut. Das Wackeln um 1 Einheit bezog sich ja auf Werte mit Tiefpass :)
Gruß
Chris
Also gut dann 1,5mm. Dann geht beim Versand wenigstens nichts kaputt.
Wenn es zu schwer wird, dann muß ich sie halt dünner schleifen. :-)
Hier noch eine Teile Liste.
ich habe noch eine Frage:
welche Frequenz soll jetzt der Quarz eigentlich haben?
Bernd
Hm also ich wäre ja für den internen 32MHz Quarz, oder aber einen externen 8MHz Quarz dann mit PLL, denn die schnelle Taktrate sollte man IMHO schon ausnutzen! Dadurch wird das System deutlich stabiler.
Die Platinen werde ich noch heute oder morgen fertigen, werden dann am Montag rausgehen ;)
Gruß
Chris
Chris wenn du es noch ändern kannst, nimm diese Version des Layouts.
Bernd
@ Happy Jack
Hast du dir das Layout schon angesehen und auf seine Tauglichkeit Richtung WiiKopter geprüft?
Gruß Bernd
EDIT:
Gerade habe ich deine Mail vom Harald bekommen, schreibe mir doch einmal genau was du wo brauchst, also welcher Pin des XMega auf Stecker oder auf Pad.
@bendh,
Ich kann im Urlaub alles mit verfolgen. Habe aber nur ein iPad dabei, so dass ich die Layouts nicht beurteilen kann. Harald hatte mir einen Teil (analoge Anschlüsse) geschickt. Für eine Wii-Adaption sollte das, was ich bisher gelesen habe, passen. Meine Wünsche bezüglich SPI teile ich Dir am Besten per E-Mail mit.
@Chris,Falls es noch nicht zu spät ist, würde ich gern je ein PCB nehmen, am Liebsten geschnitten und gebohrt. Kann aber erst ab Anfang April Geld überweisen (Urlaub).
Hans
Kann die PLL aus 16 MHz 32 machen? Also ein 16 MHz Quarz außen dran? So welche habe ich nämlich noch in der Krabbelkiste :-)Zitat:
Zitat von Che Guevara
@Harald
Hm sicher bin ich mir jetzt nicht, steht im DB, aber ich denke schon ;) Notfalls ginge ja auch der interne Osc, als Übergangslösung ;)
@Happy Jack
Ja klar, geht in Ordnung ;)
Schaffe es heute sowieso nicht mehr, morgen werde ich sie ätzen.
Gruß
Chris