Corona CR6D Single-Line Firmware

Status
Nicht offen für weitere Antworten.

chris4711

Erfahrener Benutzer
#1
Huhuu, ich habe für den Corona CR6D 2,4GHz eine neue Firmware geschrieben um einen Single-Line-Ausgang zu bekommen. Das ganze funktioniert an meinem Heli sehr gut, aber natürlich könnten trotzdem noch Fehler drin sein. Vor allem weiß ich nicht, ob die Kanäle 7 und 8 korrekt zugeordnet sind, da ich mit meiner 6-Kanal-Funke keine Testmöglichkeit dafür habe. Also: Verwendung der Firmware auf eigene Gefahr.

Auf dem Empfänger befindet sich ein Atmega88V. Jeder der einen passenden Programmer dafür hat kann die Software also draufspielen.
Die dazu benötigten Pins sind auf dem Empfänger schon vorhanden, man muss nur noch eine Stiftleiste einlöten. Die Pinbelegung habe ich im Anhang kurz skizziert.

Ist die Firmware erst mal auf dem Chip muss der Empfänger noch gebunden werden und das funktioniert folgendermaßen:

Schritt 1: Knopf am Empfänger gedrückt halten
Schritt 2: Empfänger anstecken
Schritt 3: Knopf am Empfänger loslassen.
Schritt 4: Die rote LED sollte durchgehend leuchten.
Schritt 5: Sender anschalten (ca. 1m Abstand zum Empfänger) und warten bis die rote LED ausgeht.
fertig

Im Flugbetrieb leutet die LED immer dann auf, wenn ein Datenpaket verloren gegangen ist. Das passiert, wenn der Empfang schlecht ist, aber auch, wenn man mit dem Sender zu nahe an den Empfänger kommt (< 1m). Die LED wird immer dann angeschaltet, wenn ein Fehler aufgetreten ist und geht erst wieder aus, wenn ein korrektes Datenpaket empfangen wurde.

Durch kurzes Drücken der Empfängertaste werden die aktuellen Knüppelpositionen als Failsafe gespeichert. Die Failsafe-Daten sind auf dem EEPROM gespeichert und somit auch nach Spannungsverlust noch vorhanden. Das Failsafe wird aktiv, wenn ~2 Sekunden lang kein korrektes Signal mehr empfangen wurde.

Die Software wechselt jedesmal, wenn beim Empfang ein Fehler auftritt, die Antenne. Deshalb ist die Firmware eigentlich nur für Empfänger mit 2 Antennen geeignet.

Wahrscheinlich funktioniert die Software auch auf den CR8D Empfängern und eventuell auch auf den CR4D. Dies kann ich aber nicht testen, da ich keinen solchen besitze.


Joa gut. Das war glaub ich alles was es zu sagen gibt. Es würde mich freuen, wenn mein Werk auch für andere Helikopter/Quadrokopter-Piloten nützlich ist :)
 

Anhänge

chris4711

Erfahrener Benutzer
#3
Nein, ich bin auf rcgroups auch als chris4711 registriert ;)
Oh, der RP8D1 ist auch interessant :) Aber da ist die Software etwas aufwändiger glaub ich :p Beim CR6D ist ja quasi alles per SPI gesteuert....

Hmm, ich hab nicht auf die fuses geachtet... und müsste den Empfänger jetzt erst wieder aus dem Heli ausbauen um nachzuschauen.

Also beschreiben konnte ich flash und eeprom ohne probleme. Ein lesen von flash und eeprom hat auch keinen Fehlermeldung gebracht. Wenn ich aber die runtergelesene original-Firmware wieder draufspiele funktionierts aber komischerweise nicht mehr...
 

chris4711

Erfahrener Benutzer
#5
Ich finde deine Arbeit zum RP8D1 äußerst interessant. Da werd ich unbedingt dran bleiben und es evtl auch mal ausprobieren. Das Controller rumgelöte schreckt mich aber jetzt noch ab ;)

Zu den Lockbits nochmal: Ich versteh das nicht. Ich sehe im Datenblatt keine Möglichkeit NUR das lesen zu sperren. Wie haben die das gemacht? Ich lese da nur was von "programming and verification disabled" aber das "programming" geht ja ohne Probleme...
 

chris4711

Erfahrener Benutzer
#7
Achso, so ist das. Wieder was gelernt :) Dann sind meine 2 CR6D lesegeschützt gewesen :)

Dann sollte hier wohl erwähnt werden, dass der in diesem Thread beschriebene Mod auf Single-Line-Ausgang (bis jetzt) irreversibel ist :p
 

chris4711

Erfahrener Benutzer
#9
Hey cool! :) Das war auch mein Traum, Tx und Rx umzuprogrammieren. Was die Corona-Mitarbeiter da programmiert haben ist nämlich ziemlich umständlicher und teilweise sinnloser Schrott, wie sich herausgestellt hat :p Hättest du was gesagt, dann hätte ich dir meinen Sourcecode gegeben ;) Da hätte man sicherlich auch einige Teile weiterverwenden können.

FrSky nutzt meines Wissens nach doch auch den CC2500. Kennst du ein Projekt, welches die Corona-Empfänger mit FrSky kompatibel macht? Bin nämlich umgestiegen und hab jetzt jede Menge nutzloser Corona-Empfänger :S
 

sepp1964

Neuer Benutzer
#10
Hallo Chris,
dass die Corona- Firmware suboptimal ist hab ich auch festgestellt.
Das Ding könnte wesentlich besser funktionieren, wenn man hier mehr investiert hätte.
Leider ist der Umbau nicht so einfach, weil die ISP beim Tx fehlt. Dieser hat aber eine Leiste mit 3 Pin vom UART.
Außerdem hab ich da ein Bauteil auf der Platine, von dem ich vermute es ist ein Flash mit I²C, das ich aber irgendwie nicht brauche ;) Könnten die Chinesen noch Kohle sparen. :p:
Das mit dem Quellcode hätte wahrscheinlich nicht geholfen. Das Originalprotokoll hab ich mal vor über einem Jahr zum Spaß nachgebaut, quasi als Einstieg. Aber trotzdem Danke.
FrSky hat andere CPU, glaub ich. Außerdem sind die Corona Rx nicht sendefähig. Ich weis nicht was dann der Tx macht. Wenn trotzdem alles normal läuft wäre es vielleicht möglich.

Gruß
Josef
 

chris4711

Erfahrener Benutzer
#11
Naja, es müsste möglich sein einen Corona-Empfänger dazu zu bringen als FrSky Empfänger zu arbeiten... Es gibt ja schließlich auch "Einweg"-Empfänger von FrSky. Oder denkst du, dass die trotzdem irgendwas zurücksenden? Kennst du jemanden der weiß wie das FrSky-Protokoll funktioniert?

Ich habe mit den Corona-Empfängern außerdem noch ein ungelöstet Problem... Ich habe ca. 7 Empfänger und zwei davon haben eine wesentlich geringere Reichweite (150m maximal).
Vielleicht ist dir aufgefallen, dass die Emfänger nichts mehr empfängen, wenn der LNA aktiv ist und man mit dem Sender zu nahe an den Empfänger kommt. Genau das ist bei den "Problem"-Sendern auch nicht der Fall. Die empfängen auch noch, wenn mit dem Sender direkt hingeht. Vielleicht ist bei denen der LNA kaputt? Hattest du das Problem auch schon?
 

sepp1964

Neuer Benutzer
#12
Ja wenn es die FrSky auch als Einweg mit dem selben Protokoll gibt, spricht eigentlich nichts gegen deine Idee.
Ob sie überhaupt senden können, kann man erst beurteilen, wenn sich jemand die Platine genau anschaut. Das Protokoll müsste man relativ leicht nachbauen können, wenn man den spi mitmisst.
Bei mir gibt es auch Aussetzer, wenn der Sender zu nah ist. Hab aber nur 3 und die verhalten sich alle gleich.
Habs aber geschafft ein DIY zu killen, weil ich den PPM- Eingang aktiv auf 9V geschaltet habe. Dadurch wird die VCC der Platine auf 5V gezogen, was der Atmega problemlos aushält. Der cc2500 aber nicht. Was auch sein könnte ist, dass der LNA über die CPU zu wenig Spannung kriegt. Da die Dinger ja eh fast kaputt sind, kannste ja die VCC mal direkt am LNA anschliessen. Wenn das nicht hilft, LNA auslöten und kleine Brücke rein.
edit: Ich hab natürlich die Möglichkeit die Sendeleistung zu reduzieren, was ich beim Binden auch mache.:p:
 

chris4711

Erfahrener Benutzer
#13
Hast du bei den Corona Empfängern ausprobiert zu senden? Woran scheitert es denn?

Das mit der direkten VCC Verbindung werd ich mal testen! :p
 

sepp1964

Neuer Benutzer
#14
Ich habs probiert. Auf der anderen Seite ist nie was angekommen. Als dann die Erkenntnis kam, dass das unbekannte Bauteil nur ein LNA sein kein, hab ich die Sendefunktion deaktivierbar gemacht. Gegen den LNA senden macht kein Sinn. Den LNA ausschalten und dann senden auch nicht.
Die Reichweite ohne PA ist eh bescheiden. Für Updates und Test ginge es. Nicht aber für Telemetrie.
 

chris4711

Erfahrener Benutzer
#15
Hmm, schade :(

Ich hab gelesen, dass du auch am th9x Projekt beteiligt bist? Wird es bald eine Software geben, die den Umweg über PPM nicht mehr braucht? :p Also direkt mit I2C oder so aus der Steuerung ins Sendermodul? Das wäre genial... Ist ja schon ärgerlich, dass man heutzutage wegen des veralteten PPM immer 20ms Verzögerung und 50Hz ertragen muss... :p
 

sepp1964

Neuer Benutzer
#16
Wird es geben!
Und zwar seriell. Zum Einen weil ein Levelshifter erforderlich ist (th9x hat 5V, Corona 3,3V) und zum Anderen um den Verkabelungsaufwand zu minimieren. Des weiteren ist auf dem Corona DIY der UART auf Stiftleiste herausgeführt.
Die Verzögerung ist dann:
Sticks einlesen und Mischer rechnen ca. 5ms
Daten zum DIY übertragen: <1ms
Daten Senden: 2ms für Kanal 1 - 4
4ms für Kanal 5 - 8
Impulsausgabe: 1,5ms
ergibt wenn ca. 10ms Verzug (bei ppm: Sender 10ms + PPM 20ms + Ausgabe 1,5ms = mehr als 30ms)
Außerdem werden die Daten alle 10ms neu berechnet und übertragen.
Was aber meiner Meinung nach wichtiger ist: Die th9x richtet das Timing nach dem DIY, so dass es keine Schwebungen (Jitter) gibt und es werden sowohl Kanaldaten wie auch Telemetriedaten über eine Schnittstelle ausgetauscht.
Ob man merkt, dass die Verzögerung ca. 20ms weniger ist, glaub ich allerdings nicht.
 

sepp1964

Neuer Benutzer
#18
Also meine Servos schaffen alle weniger.
Die minimale Zeit ist programmierbar und steht momentan auf 15ms.
Der Hintergrund meiner Aktivitäten ist aber ein anderer: Die PWM wird mit dem Sender synchronisiert.
Das bedeutet die Delays sind konstant und das war mir wichtiger.
Falls die digitale Übertragung zum Tx in 10ms erfolgt, verwerfe ich die Daten zwar im Rx, aber ich hab sie wenigstens parat, falls mal ein paar Pakete verloren gehen. Macht doch mehr Sinn als sie im Sender zu verwerfen.
 

chris4711

Erfahrener Benutzer
#19
Liest man bei den digital-Servos nicht immer was von über 330Hz? Denke auch nicht, dass das ein Problem sein sollte...
Außerdem glaube ich schon, dass man die 20ms bemerkt. Wie ich darauf komme? Ich habe früher viel Egoshooter online gespielt und da merkt man einen Unterschied von wenigen Millisekunden im Ping schon ganz deutlich. Es fühlt sich einfach "direkter" an. Außerdem kann man sich überlegen, dass ein 100km/h schnelles Modell in 20ms immerhin mehr als einen halben meter zurücklegt ;)

naja, ich habe zwar keine Fernsteuerung fürs th9x aber ich freu mich schon auf deine Software :) Wenn die PPM-Generierung dann entfällt wird ja vielleicht auch wieder ein bisschen Speicherplatz für Anderes frei... ;)
 

sepp1964

Neuer Benutzer
#20
Entfallen wird wohl nichts, ich hab noch einen PPM- Sender, der mal ein Schweinegeld
gekostet hat und auf den will ich nicht verzichten.;)
Aber das serielle Interface ist ja schon in der Software eingebaut. Es wird automatisch immer das Interface benutzt, auf dem Daten kommen. (also PPM oder UART)
zum Thema 20ms: Aus beruflichen Gründen weiß ich, dass 100ms als direkte Reaktion empfunden werden. (bei Tasten z. B) Dass Spieler auch 20ms merken mag sein, aber man darf ja nicht vergessen, dass beim Fliegen immer noch Mechanik und somit Trägheiten im Spiel sind.
Wenn du die Fernsteuerung auf 2.4GHz umstellst, hast du bei den meisten immer min. 1 Frame (20ms) Verzug gegenüber 35MHz.
Es gibt aber nicht viele, die das merken.
p.s. keine th9x! Schade. Es gibt nicht viele Sender, die für so wenig Geld soviel können, besonders mit der richtigen Firmware :)
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten