Afro MINI 32
- Themenstarter fdietsch
- Beginndatum
- Status
So ich habe die Mixereinstellungen angepasst geht nur zeile für zeile also so wie ganz unten soll es aussehen. Wenn ich motor 1 auf null setze ist die tabelle ganz weg daher die beiden ersten Zeilen dann passt die Nummerirung auch zum Board.
Hier eine kleine Anleitung
Auf CLI schalten
feature ppm eingeben
map zeigt die kanalreiehenfolge
kann dann mit
map ATER1234 geändert werden
mixer custom schaltet auf die selbstgebaute tabelle
cmix 1: 1 1 1 1 setzt die werte für motor 1 ...
Hier eine kleine Anleitung
Auf CLI schalten
feature ppm eingeben
map zeigt die kanalreiehenfolge
kann dann mit
map ATER1234 geändert werden
mixer custom schaltet auf die selbstgebaute tabelle
cmix 1: 1 1 1 1 setzt die werte für motor 1 ...
Anhänge
Makrolon glaube nicht ,das war ein Reststück von einer 5 mm Plexiglasscheibe Acryl Makrolon.. weis nicht. Der ist innerlich ausgefräst damit er etwas leichter wird. Es begann alles mit einem Einzeller jetzt habe ich mal einen mit 3S gebaut. Der geht auch draußen recht gut inlc. Looping...
Die afro mini hab ich jetzt mal zusammen mit dem Empfänger eingeschrumpft und auf 4 kleine Alpagelwürfel geklebt, die Gyro LPF auf 10 reduziert und nun geht er auch ordentlich.
https://plus.google.com/photos/114024906765141606417/albums/5674566216959718353?banner=pwa
http://www.youtube.com/watch?v=uMiHpL83TOk
Die afro mini hab ich jetzt mal zusammen mit dem Empfänger eingeschrumpft und auf 4 kleine Alpagelwürfel geklebt, die Gyro LPF auf 10 reduziert und nun geht er auch ordentlich.
https://plus.google.com/photos/114024906765141606417/albums/5674566216959718353?banner=pwa
http://www.youtube.com/watch?v=uMiHpL83TOk
Warten bis Graupner seine Aussage vom September/12 einlöst und ein Firmwareupdate auf SUMO anbietet.
'SUMH dürfte eher einem SpectrumSat oder wie das wieder heißt entsprechen. Ist wie SUMD mit anderer Prüfsumme.
Aber der Empfänger wäre dann schon cool - klein, preiswert, und mit der Möglichkeit die LiPo Spannung an die Hott zu übertragen.
vg jörg
'SUMH dürfte eher einem SpectrumSat oder wie das wieder heißt entsprechen. Ist wie SUMD mit anderer Prüfsumme.
Aber der Empfänger wäre dann schon cool - klein, preiswert, und mit der Möglichkeit die LiPo Spannung an die Hott zu übertragen.
vg jörg
Aber vor einem halben Jahr noch Interesse geweckt. 
...
Die wollen diese Empfänger bestimmt für Minihubi´s ala Blade etc vermarkten. Reine Verkaufsstrategie lieber teure für den Rest der Welt. Was nützten mir die Monsterempfänger mit allen Ausgängen ich brauche überall sowieso nur den SUMO der Rest ist verschwendeter Platz.
Außerdem wäre ich sofort bereit mir für jeden Copter einen Empfänger anzuschaffen für 30€ - so wird halt gewechselt.
Hast Du eine Dokumentation gefunden über das SUMH?
...Die wollen diese Empfänger bestimmt für Minihubi´s ala Blade etc vermarkten. Reine Verkaufsstrategie lieber teure für den Rest der Welt. Was nützten mir die Monsterempfänger mit allen Ausgängen ich brauche überall sowieso nur den SUMO der Rest ist verschwendeter Platz.
Außerdem wäre ich sofort bereit mir für jeden Copter einen Empfänger anzuschaffen für 30€ - so wird halt gewechselt.
Hast Du eine Dokumentation gefunden über das SUMH?
Nö aber es gibt eine Multiwii 2.2 mit SUMH weis aber nicht ob die BL Motoren ansteuert oder was der erfinder da alles geändert hat. SUMH ist jedenfalls drin. Wenn ich ein wenig zeit finde versuche ich mal ob ich das geht.
http://forum.flyduino.net/viewtopic.php?f=7&t=506&start=10#p1914
http://forum.flyduino.net/viewtopic.php?f=7&t=506&start=10#p1914
Hallo,
nö 'ne Doku hab ich nicht. Ich hab' mir den Empfänger gekauft, weil der so schön klein war. Das der kein PPM-SUM kann wußte ich da noch nicht. Im Nachhinein ist der Nachteil sogar ein Vorteil. Am Sender braucht man nämlich keine Servowege wie bei meinem GR-12 mehr einzustellen. Das Timing (Pulsbreite) vom RX ist nicht wichtig. Die Daten der Funke werden komplett digital übertragen. Da von Graupner im Netz nichts über die Innereien von SUMH zu finden war, habe ich mir alles selbst zusammengereimt.
Ich habe einfach den Empfänger an ein Nanowii angeschlossen und meine Funke gebunden. Das Frameintervall stimmt mit dem eingestellten im Sender überein (11/22ms, habe ich mit Oszi gemessen). Das Frame wird lückenlos mit 115200 Baud übertragen. Bei Failsafe kommen noch ein paar Mal die eingestellten Failsafedaten und dann ist Funkstille bis wieder etwas empfangen wird. Fehlerhafte Daten habe ich nie gesehen. Damit man es versteht, versuche ich mal es in c-code zu dokumentieren.
struct sumhframe {
uint8_t Framestart; // immer 0xA8
uint8_t Header1; // wird ignoriert, steht die Framegröße drin und irgendwas anderes bedeutungsloses drin
uint8_t Header2; // dito
uint16_t PITCH; // MSB zuerst
uint16_t YAW;
uint16_t THROTTLE;
uint16_t ROLL;
uint16_t AUX1;
uint16_t AUX2;
uint16_t AUX3; // 0% bei 6 Kanalsender
uint16_t AUX4; // dito
uint16_t Checksum; // wieder ignoriert. scheint einfach aufsummiert zu werden.
}
Das Frame ist 21 Byte gross und biete Platz für 8 Kanäle. Für die Umrechnung von -100%..+100% auf die benötigten 1000..2000 für MWC genügt lineare Algebra:
y=x/6.4 - 375
Wer hat, kann mir gerne die offizielle Beschreibung zukommen lassen. In den ignorierten Daten stehen Info über Framegröße und programmiertem Failsafe drin. Da Übertragung sicher zu sein scheint, bringt die Auswertung keinen Mehrgewinn sondern verschlingt wahrscheinlich nur unnötig Speicher und Rechenzeit.
bis dann
jörg
nö 'ne Doku hab ich nicht. Ich hab' mir den Empfänger gekauft, weil der so schön klein war. Das der kein PPM-SUM kann wußte ich da noch nicht. Im Nachhinein ist der Nachteil sogar ein Vorteil. Am Sender braucht man nämlich keine Servowege wie bei meinem GR-12 mehr einzustellen. Das Timing (Pulsbreite) vom RX ist nicht wichtig. Die Daten der Funke werden komplett digital übertragen. Da von Graupner im Netz nichts über die Innereien von SUMH zu finden war, habe ich mir alles selbst zusammengereimt.
Ich habe einfach den Empfänger an ein Nanowii angeschlossen und meine Funke gebunden. Das Frameintervall stimmt mit dem eingestellten im Sender überein (11/22ms, habe ich mit Oszi gemessen). Das Frame wird lückenlos mit 115200 Baud übertragen. Bei Failsafe kommen noch ein paar Mal die eingestellten Failsafedaten und dann ist Funkstille bis wieder etwas empfangen wird. Fehlerhafte Daten habe ich nie gesehen. Damit man es versteht, versuche ich mal es in c-code zu dokumentieren.
struct sumhframe {
uint8_t Framestart; // immer 0xA8
uint8_t Header1; // wird ignoriert, steht die Framegröße drin und irgendwas anderes bedeutungsloses drin
uint8_t Header2; // dito
uint16_t PITCH; // MSB zuerst
uint16_t YAW;
uint16_t THROTTLE;
uint16_t ROLL;
uint16_t AUX1;
uint16_t AUX2;
uint16_t AUX3; // 0% bei 6 Kanalsender
uint16_t AUX4; // dito
uint16_t Checksum; // wieder ignoriert. scheint einfach aufsummiert zu werden.
}
Das Frame ist 21 Byte gross und biete Platz für 8 Kanäle. Für die Umrechnung von -100%..+100% auf die benötigten 1000..2000 für MWC genügt lineare Algebra:
y=x/6.4 - 375
Wer hat, kann mir gerne die offizielle Beschreibung zukommen lassen. In den ignorierten Daten stehen Info über Framegröße und programmiertem Failsafe drin. Da Übertragung sicher zu sein scheint, bringt die Auswertung keinen Mehrgewinn sondern verschlingt wahrscheinlich nur unnötig Speicher und Rechenzeit.
bis dann
jörg
Zuletzt bearbeitet:
Super danke,
da steht alles drin. Jetzt ist es höchstens noch interessant ob der Failsafe Status über ein bestimmtes Bit oder Wert angezeigt wird. Aber da schaue ich dann mal selbst wenn ich einen habe.
Wichtig war mir nur erst einmal ob es ein normale serielles Protokoll ist. Bei den doch eingeschränkten Anschlüsse der NAZE ist das dann etwas lästig.
vg jörg
da steht alles drin. Jetzt ist es höchstens noch interessant ob der Failsafe Status über ein bestimmtes Bit oder Wert angezeigt wird. Aber da schaue ich dann mal selbst wenn ich einen habe.
Wichtig war mir nur erst einmal ob es ein normale serielles Protokoll ist. Bei den doch eingeschränkten Anschlüsse der NAZE ist das dann etwas lästig.
vg jörg
- Status
