Lieber Besucher, herzlich willkommen bei: RCLine Forum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

Montag, 11. Mai 2009, 15:56

2.4GHz EFlite RTF Sender Signalkodierung: vom Steuerknüppel zum DSM2

Hallo Zusammen,

im mCX Blade Hauptthread hat sich gerade eine Diskussion um die Kodierung der Signale in den EFlite 2.4GHz Sendern, wie sie den RTF Sets beigelegt wird, entwickelt. Da ich finde, dass dieser Thread eh schon VIEL zu gross ist (wer kann bei mehr als 1500 Posts schon noch relevante Info finden...?) und nicht unbedingt auch damit noch belastet werden muss, und dieses Thema vielleicht auch unabhängig vom mCX relevant sein könnte, und auch ein Vorschlag in diese Richtung kam, mache ich nun diesen Thread hier auf.

Wer das dort bisher gepostete lesen will, such ab 08.05.2009, oder Seite 111 in Standardeinstellung.

Um es aber einfacher zu machen, war ich so unverschämt..., äh, habe ich mir die Freiheit genommen aus diesen Posts eine willkürliche Auswahl hier in den nächsten Post zu kopieren.

Ciao,
Olli

2

Montag, 11. Mai 2009, 16:19

soweit so gut

Olli: Signalcodierung des 2ms Pulses der RTF Funke
habe mir gestern mal zum Spass das Signal angesehen dass die original 4-Kanal RTF Funke an das HF-Modul schickt. Ist natürlich kein PPM, wäre ja noch schöner, sondern eine Bitfolge in einem ca. 2ms Puls gefolgt von ca 20 ms Ruhe. Sieht bei mir genauso aus wie im 11.ten Post hier. Weiss jemand wie diese Bitfolge genau aufgebaut ist (im genannten Thread wird ja leider nur vom Decodieren des Signals geredet aber ohne Ergebnisse)? Wird schon irgendwie eine Reihe von Paketen sein, wenn man an den Knüppeln werkelt ergeben sich Änderungen nur immer in einem gewissen Segment der Bitfolge. Aber wie ist das Signal genau codiert wäre meine Frage... :)

Helmut:
Meine erste Vermutung wären mal 4 x 8 Bit + evtl. Parity Bits und/oder Markierungen; so wär´s für die Signalverarbeitung im µC am einfachsten. Und man wird wahrscheinlich auch nichts völlig Neues in der Signalgenerierung erfunden haben bzw. vorhandene Programm-Module übernommen haben. Im einfachsten Fall ist nur die PPM-Codierung weggelassen und statt dessen eine serielle Ausgabe.

Und ich würde mal versuchen, die Bereiche abzugrenzen, in denen sich bei Betätigung der einzelnen Funktionen etwas ändert. Dazu wäre es hilfreich, für einen andern µC ein Progrämmchen zu schreiben,

Olli:
Wenn ich das recht verstehe, muss das mit dem Binden ja auch noch irgendwie gehen... vielleicht einfach ein Standardpaket vorneweg oder so, aber wer weiss...

Helmut:
die "höheren stunts" macht der Hf-Chip völlig autonom. Du kannst diese Tx/Rx-Bausteine als "black boxes" ansehen; Binärsignal rein- dto. raus. Man muß wirklich "nur" rausfinden, wie dieses Impulssignal aufgebaut ist.

Helmut:
ich hab übrigens mal versucht, auf der website von Cypress mehr über den im Heli verwendeten Chip CY RF6910 zu erfahren.

Hannes:
Euch kann geholfen werden :-) die vollständige Bezeichnung des Chips ist CYRF69103-40LFXC, und hier ist die URL zum Datasheet:
http://download.cypress.com.edgesuite.ne…cyrf69103_8.pdf

Olli:
mein AVR Program geht zwar noch nicht, aber ich habe mir das Signal mal ein bischen näher am Oszi angesehen. Es kommt erstmal eine Intro, dann die Infos für die 4 Kanäle, und dann noch zum Ende raus ne ganze Menge anderes unveränderliches Zeugs. Insgesamt etwa 1.2 ms, bei einer Framelänge von ca. 22 ms. Mit meinem Uraltoszi kann ich Zeiten nicht soo genau messen, aber es könnte sein das ein Bit 7.5 us lang ist.
Aufbau der Intro: könnte passen zu (1)0 00000000 10 00000000
Aufbau der Info jeden Kanals: 10 XX YY 0000 10 ZZZZZZZZ
X sind 2 bits die die Knüppelstellung grob angeben, gehen linear von 00 nach 11
Y sind 2 bits in dennen die Kanalnr drinnen steckt:
Kanal1: 00, Kanal2: 10, Kanal3: 01, Kanal4: 11
Z sind 8 bits die die Knüppelstellung genauer angeben, deren Kodierung ist mir aber unklar:
Knüppel unten: X= 00 Z= 01010101
Knüppel oben: X= 11 Z= 00101010
Und der ganze lange Rest, keine Ahnung. Das Format sieht aus ... 0 Byte 1 (vielleicht 1 Startbit, Byte, 1 Stopbit?).

Hannes:
Das Protokoll wird wohl "64 chip 8DR" sein, Bitrate 125 kbps. Die Details stehen in diesem Technical Reference Manual: http://www.cypress.com/?docID=9301

Olli:
Ich komme gerade mit ner Genauigkeit von 1% konsistent auf eine Zeit von 7.63 us für ein Bit... bei 125kbps wären es 8.0 us...

Hannes:
vielleicht hilft ja diese Analyse des DSM2-Protokolls weiter: http://www.rcgroups.com/forums/showpost.…933&postcount=8

Olli:
so, ich glaube mein Program geht jetzt, hat zumindest einige Checks überstanden, ist natürlich trotzdem keine Garantie. Ergebnis: Ein Bit hat (edit ca.) 7.65 us.
Der Bitstrom sieht für ein paar Knüppelstellungen so aus (Fenster maximieren!):

Gas unten/oben
0000000001 0000000001 0000000001 0010101011 0011000001 0110001001 0100100001 0111101011 0101100001 0110111111 0110010001 0001010101 0001010001 00101010
0000000001 0000000001 0110000001 0001010101 0011000001 0110001001 0100100001 0111101011 0101100001 0110111111 0110010001 0001010101 0001010001 00101010
Gier links/mitte/rechts
0000000001 0000000001 0000000001 0010101011 0011000001 0110001001 0100100001 0111101011 0111100001 0101010001 0110010001 0001010101 0001010001 00101010
0000000001 0000000001 0000000001 0010101011 0011000001 0110001001 0100100001 0111101011 0101100001 0110111111 0110010001 0001010101 0001010001 00101010
0000000001 0000000001 0000000001 0010101011 0011000001 0110001001 0100100001 0111101011 0001100001 0101010111 0110010001 0001010101 0001010001 00101010
Nick oben/mitte/unten
0000000001 0000000001 0000000001 0010101011 0011000001 0111110001 0110100001 0011100101 0101100001 0110111111 0110010001 0001010101 0001010001 00101010
0000000001 0000000001 0000000001 0010101011 0011000001 0111110001 0100100001 0001011011 0101100001 0110111111 0110010001 0001010101 0001010001 00101010
0000000001 0000000001 0000000001 0010101011 0011000001 0101110001 0000100001 0010101011 0101100001 0110111111 0110010001 0001010101 0001010001 00101010
Roll links/mitte/rechts
0000000001 0000000001 0000000001 0010101011 0111000001 0110010101 0100100001 0111101011 0101100001 0110111111 0110010001 0001010101 0001010001 00101010
0000000001 0000000001 0000000001 0010101011 0011000001 0111110001 0100100001 0111101011 0101100001 0110111111 0110010001 0001010101 0001010001 00101010
0000000001 0000000001 0000000001 0010101011 0001000001 0100011011 0100100001 0111101011 0101100001 0110111111 0110010001 0001010101 0001010001 00101010

Ich habe die Trennungen nach jeweils 10 Bits gemacht, zumindest ist dann immer eine 0 am Anfang und eine 1 am Ende... doch Start/Stopp Bits? Beim letzten Paket .. 11 angehängt denkt würde es ins Schema passen...
erst zwei Intro-Päckchen, dann jeweils 2 Päckchen für jeden Kanal in der Reihenfolge Gas, Roll, Nick, Gier, Aufbau 0XXYY00001 0ZZZZZZZZ1 pro Kanal
restlichen Päckchen einfach als Kanal 5 und 6 zu betrachten. Der Aufbau wäre dann 0XXYYY0001 0ZZZZZZZZ1 (also drei Y für 5=001 und 6=101). Die gewählten Stellungen sind dann für Kanal 5 ganz nach oben und für Kanal 6 ganz nach unten.

Da das alles so Sinn macht, ist mein Vorschlag für das Datenformat also:
- ein Byte wird als 0-BYTE-1 verpackt
- es wird 2mal 0-0x00-1 voraus geschickt
- dann kommen für 6 Kanäle jeweils 2 Bytes mit dem Aufbau 0-XXYYY000-1 0-ZZZZZZZZ-1, wobei YYY für die Kanalnummer steht.

Ha, ist ja nett, der 2.4GHz Teil in der Funke ist ja wirklich nur so eine daumennagelgrosse Platine, die einfach nur mit den obigen Signalen gefüttert werden muss => man kann damit leicht jede PPM-Funke mit nem kleinen AVR zu ner Spektrum 2.4GHz Funke aufrüsten!
Frage: Welche Spektrum-Empfänger gehen mit der MLP4DSM? Alle?

Olli:
sehr interessant, dein Post, Hannes, (und nicht nur der, sondern der ganze Thread ).
PPM zu DSM2-Konverter ist dann wohl der nächste logische Schritt (wie im obigen Thread) .

Hannes:
Auf dem "HF-Modul" wohnen zwei Cypress-Chips:
CPU CY8C21434 - http://www.cypress.com/?docID=16681
Transceiver CYRF6936 - [URL]http://www.cypress.com/?docID=14517[/URL]

Helmut:
In meiner Anleitung zum BNF-mCX sind als kompatible Sender aufgeführt:
E-Flite LP5DSM
E-Flite HP6DSM
ParkZone Vapor
JR X9303 2.4
JR 12X 2.4
Spektrum DX5e
Spektrum DX6i
Spektrum DX7
Spektrum Modules

3

Montag, 11. Mai 2009, 22:44

Hallo,

hatte angefangen den AVR so zu programmieren, dass er ein passendes Signal künstlich erzeugt. Geht natürlich noch nicht ganz, aber schon soweit um das zu sagen:

Wenn ich 30 bits ausgebe, dann sind die auf meinem Oszi innerhalb dessen was ich erkennen kann genauso lang wie wenn ich mir 30 bits der RTF-Funke mit den selben Oszi-Einstellungen ansehe => die (Un)genauigkei der Zeitbasis meines Oszis spielt da keine Rolle. Die Bitfolge habe ich mit einem 16MHz ATmega 8, Prescaler 1, Clear Timer on Compare Match mit OCR=121 gemacht => 1/(16 MHz) * 121 = 7.5625 us (wenn ich OCR=122 oder 120 nehme, dann ist auf dem Oszi ganz deutlich eine Abweichung zu sehen). 125kbps oder noch niedriger würde ich daher ausschliessen.

In meiner Funke ist ein 4.194 MHz verbaut. Durch 32 geteilt ergibt das 131062.5 ... wäre bei einem ATmel UBRR = 1 ... könnte Sinn machen. 32/4.194 MHz * 16 MHz = 122.08. Ich finde das Datenblatt vom ATmega8 an dieser Stelle nicht ganz klar, scheint aber so dass die Resolution des Timers durch OCR+1 gegeben ist, und das würde genau OCR = 121 ergeben... auch das könnte Sinn machen. :) (und mein Oszi hätte sich über die Jahre ja doch gut gehalten :))

Was für ein Quarz ist denn in der 5-Kanal RTF Funke des Blade CX2 eingebaut?

Ich habe auch festgestellt, dass ich mit dem AVR nur bis 56000 baud kommunizieren kann, darüber, schon bei 57600, geht's schief. Das ich das "Zwischensignal" nicht direkt mit der RS232 einlesen konnte, liegt also wohl an meinem Terminalprogram und/oder Computer. Ich benutze das hier.

Kennt vielleicht jemand ein anderes Terminalprogramm das mit beliebigen Baudraten arbeiten kann, und das bei um die 130 kbps sicher arbeitet?

Ciao,
Olli

4

Dienstag, 12. Mai 2009, 16:09

Zitat

Original von waldmann
Kennt vielleicht jemand ein anderes Terminalprogramm das mit beliebigen Baudraten arbeiten kann, und das bei um die 130 kbps sicher arbeitet?


Hi Olli,

Für die "kritischeren" sachen brauch ich HTERM. Ob das allerdings deine baudrate schafft hab ich nie getestet.

Betreffend "komischem" timing von 4.195 gibts bei kleineren avr's die möglichkeit den internen osc zu trimmen. Du kannst beim attiny45 und konsorten durchaus 16.5 mhz oder 12.8 mhz taktrate fahren, 4*4.195 sollte also auch gehen. Oder ein quarz, die frequenz ist handelsüblich. Ausgabe muss dann parallel sein, da das timing mt dem pc nicht mehr stimmt.

Etwas ähnliched hab ich für einen DVB-S sender gebastelt, mit einem 2313. Datenrate ist hier aber 1mbit/sec, paralleler input vom drucker port, serieller output mit 1.024 mhz, cpu werkelt mit 8*1.024 mhz. (oder 16.384mhz fur 2mbit/sec)

Gruss Cesco (leider anderes 2.4ghz system hier, hätte gerne mitgebastelt ==[] )
HK250 HK450 HK500 HK600
[SIZE=3]Cesco [/SIZE]

5

Dienstag, 12. Mai 2009, 17:20

Hallo Cesco,

HTerm: danke für diesen Tipp, werde ich heuet abend gleich mal ausprobieren. :)

4.194 MHz: Diese Zahl war eigentlich nur interessant weil es die Diskussion über die Baudrate des "Zwischensignals" gab. Bei TheSteve steht 125 kbps, und auch Hannes hat das eher favorisiert als die krummen 131XXX. Mit 4.195 MHz (oder vielfache) kommt man aber sehr natürlich auf die 131XXX. Nimmt man 4 MHz (oder vielfache), dann kommt man sehr natürlich auf 125 kbps. Deswegen würde ich sagen das in der 5-Kanal RTF Funke von TheSteve ein 4MHz Quarz steckt, und sich die "krumme" Baudrate bei meiner 4-Kanal Funke einfach ergibt weil sich EFlite aus irgendwelchen Gründen dazu entschieden hat dort nen 4.194MHz Quarz einzubauen. Vielleicht (vermutlich) ist es dem HF-Teil ja völlig egal was die Baudrate ist, und EFlite nimmt einfach was gerade billig verfügbar ist.

Ich glaube Parallelport ist mir zu kompliziert. Ich bastle gerade an einem Program mit dem ich dem AVR über die RS232 die Knüppelstellungen sage, und der dann das passende Zwischesignal erzeugt, um so letztendlich die Servos zu steuern. Ist so natürlich nur Spielerei, würde aber zeigen, dass der entscheidende Teil geht. Wenn man das mal hat, dann sollte alles andere einfach sein. Bliebe dann nur die Frage wie man günstig an die HF-Platinchen kommen könnte....

Ciao,
Olli

.

6

Dienstag, 12. Mai 2009, 17:57

Zitat

Original von waldmann
Bliebe dann nur die Frage wie man günstig an die HF-Platinchen kommen könnte....


Hi Olli,

Wenn du die flysky (turborix,turnigy,hobbyking) sachen nimmst kommt man recht günstig an rx/tx ran. Ist aber ein anderes system auf A7122 basierend. Ein RX kostet 15$, eine ganze anlage RX+TX 30$ oder 33$ (4/6 kanal). Dann gibt's noch TX-PPM-module für 17$, der RX dazu 20$ / 23$ (6 / 9 kanal).

Stresst mich grad ... ich hab gestern die teure 110$ anlage bestellt, und heute ist eine für 33$ drin die für mich wesentlich besser geeignet wäre. Ich hasse steuerungen mit zuviel knöpfen. :angry:

Gruss Cesco
HK250 HK450 HK500 HK600
[SIZE=3]Cesco [/SIZE]

7

Dienstag, 12. Mai 2009, 20:33

Zitat

Original von Cesco1
Wenn du die flysky (turborix,turnigy,hobbyking) sachen nimmst ...

BTW: Haben die eigentlich eine Zulassung für DE? Sind ja preislich schon sehr interessant...

8

Dienstag, 12. Mai 2009, 20:52

Zitat

Original von amm
BTW: Haben die eigentlich eine Zulassung für DE?


??? Die frage hab ich mir nie gestellt.

Das ist ISM bereich, 80 mw power, braucht's da ne zulassung ?
Ist mir eigentlich eh egal. wenn der zoll meckert schick ich denen eine kopie vom radiotelegrafisten ausweis.

Gruss Cesco

:angry: diese edit funktion stresst ! Die vergisst immer die änderungen :angry:
HK250 HK450 HK500 HK600
[SIZE=3]Cesco [/SIZE]

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »Cesco1« (12. Mai 2009, 21:08)


9

Dienstag, 12. Mai 2009, 21:30

Guckt doch mal ob das hier nicht das identische Protokoll ist:

http://www.rcgroups.com/forums/showthread.php?t=721024

10

Dienstag, 12. Mai 2009, 21:50

Hallo Peter,

das ist der TheSteve Thread den Hannes oben schon ausgegraben hatte, und ja, das ist das identische Protokoll, nur die kbps scheinen leicht anders zu sein. :)

Trotzdem DANKE.
Olli

11

Mittwoch, 13. Mai 2009, 01:19

Hallo,

so, jetzt muss ich noch schnell über meinen heutigen Fortschritt berichten. Mein AVR Program funktioniert noch nicht perfekt (der UART steigt manchmal aus), aber doch soweit dass ich die Impulsfolge machen kann, und mit Kommandos über's Terminal (z.B. gas 235 etc.) die Implusfolge auch steuern kann. Also, wagemutig voran, gleich mal an den HF-Chip angeschlossen (da die Spannung im Sender 3.3V ist, mein Board aber auf 5V läuft, habe ich noch einen Widerstandsteiler eingebaut, macht die Flanken ein bischen rund, aber nicht schlimm, hoffe dass das kein Problem ist) ... eingeschaltet ... Lipo an den mCX ... auf's Lampen leuchten gewartet ... durchgeatmet ... Kommando roll 0 eingegeben ... Enter gedrückt ... und ... es geht! Der Servo bewegt sich! Kommando roll 1000, es geht, der Servo bewegt sich! nick 0, komisch, es tut sich nichts, nick 1000, komisch, es tut sich nichts, also wieder roll, es geht, also mal gaannnzz vorsichtig gas 200 ... und der Heli schiesst mich Affenspeed an die Decke ... zum Glück ist nichts kaputt gegangen ... wieder durchatmen und beschliessen für heute aufzuhören. Ich mag meinen mCX ja eigentlich schon ganz gerne... :)

Also offensichtlich muss ich mir die Kanalbelegung und die Kodierung der Knüppelstellung noch mal genauer ansehen, und natürlich mein Program... :)

Gute Nacht,
Olli

haschenk

RCLine User

Beruf: Dipl. Ing.

  • Nachricht senden

12

Mittwoch, 13. Mai 2009, 10:32

Hallo Olli,

gestern hab ich mal (nur auf dem Papier bzw. Bildschirm) versucht, die von dir angegebenen Bitfolgen mit der von "thesteve" angegebenen Formatierung in Übereinstimmung zu bringen. Trotz einigen klar erkennbaren und eindeutigen Abhängigkeiten gelingt mir das bislang nur teilweise. Was durchaus an mir liegen kann...

Meine Frage:
Sind die von dir angegebenen Bitfolgen die reinen Datenbytes (Kanalnummern+Daten), oder ist es der Bitstrom auf der Leitung (incl. Start- und Stopbits) ?


Gruß,
Helmut

13

Mittwoch, 13. Mai 2009, 13:40

Hallo Helmut,

Zitat

gestern hab ich mal (nur auf dem Papier bzw. Bildschirm) versucht, die von dir angegebenen Bitfolgen mit der von "thesteve" angegebenen Formatierung in Übereinstimmung zu bringen.

super, das ist sehr nützlich :) Hätte ich schon längst tun sollen, habe es aber nicht...

Zitat

Sind die von dir angegebenen Bitfolgen die reinen Datenbytes (Kanalnummern+Daten), oder ist es der Bitstrom auf der Leitung (incl. Start- und Stopbits) ?

Ich habe die Zeiten zwischen den Signalwechseln gemessen, und daraus unter Annahme einer Zeit für ein Bit (siehe oben) einen Bitstrom gemacht. Das bedeutet aber das evetuell vorhandene 1en am Ende NICHT enthalten sind, da sie ja über Signalwechsel nicht zu messen sind.
Also, die Angaben oben sind der Bitstrom auf der Leitung GENAUSO wie ich ihn MESSEN kann.

Wenn wir diese Bitfolge als eine Sequenz von 14 Bytes eingefasst von je einem Start und Stopbit interpretieren dürfen, wofür ja alles spricht, dann sind also Start- und Stoppbits enthalten, und du musst am Ende noch 11 anhängen um das Format vollständig zu bekommen.

Für mich sieht es so aus:
Es werden zunächst 2 Bytes mit Wert 0 übetragen.
Dann werden 6 Kanäle mit je 2 Bytes übertragen, in denen die Infos für Kanalnr und Knüppel kodiert ist als

0HHYYYYYY1 0LLLLLLLL1

0 und 1en sind die Start/Stopbits
YYYYYY gibt die Kanalnr.
HH die oberen Bits des 10-bit Wertes für die Knüppelstellung
LLLLLLLL die unteren Bits des 10-bit Wertes für die Knüppelstellung
(alles so wie übertragen, also in "umgekehrter" Reihenfolge der Bits, niedrigwertiges zuerst)

Ich habe heute morgen nochmals die Bitfolgen für mehrere Knüppelstellungen gemessen.
Gas = Kanal 0 (also 3.tes und 4tes Byte im Bitstrom), Roll = 1, Nick = 2, Gier = 3.

EDIT: hier standen viele Bitfolgen, die jetzt aber überflüssig sind und nur Platz wegnehmen => weg

Ich habe ja die Hoffnung das eigentlich alles geht ausser dass ich 1) einfach bei der Zuordnung der Kanalnr zu der Funktion einen Fehler gemacht habe (gier statt nick) und 2) im nächtlichen Konzentrationsloch nicht gas 200 sondern gas 2000 eingegeben habe... was Vollgas gewesen wäre...

Ciao,
Olli

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »OlliW« (13. Mai 2009, 23:34)


14

Mittwoch, 13. Mai 2009, 14:12

Gelöscht. Dass msb-lsb vertauscht sind hast du ja geschrieben.
HK250 HK450 HK500 HK600
[SIZE=3]Cesco [/SIZE]

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Cesco1« (13. Mai 2009, 14:17)


15

Mittwoch, 13. Mai 2009, 23:12

es geht

Hallo,

na, das war ja dann doch noch einfach. Ich hatte tatsächlich einfach gier mit nick verwechselt, und muss gestern abend etwas falsches für gas eingetippt haben... jedenfalls, jetzt geht es wie es soll!! :):)

Ich habe versucht einen Film vom PC-gesteuerten mCX zu machen, aber da kam nur Mist raus, auch die Bilder sind mir völlig aussagefrei gelungen. Deswegen unten nur ein Bild das zeigt wie und wo ich das Signal eingeschleift habe (und das ich dass Pollin Evaluationsboard habe...)

Für alle die es mal ausprobieren wollen habe ich den C-Code auch mit angefügt. Aber bitte berücksichtigt, dies ist mein allererstes AVR-Projekt gewesen, seid also nachsichtig wenn der Code professionellen Ansprüchen nicht genügt (es gibt da so ein paar Dinge die mir noch nicht ganz klar sind... :))

Als nächstes ist dann wohl die Ergänzung mit einer PPM-Einleseroutine dran...

Und eine gute&billige Quelle für dieses HF-Platinchen...

Und die Empfängerseite...

Ciao,
Olli

[RCLTV]1391[/RCLTV]
»OlliW« hat folgende Datei angehängt:

haschenk

RCLine User

Beruf: Dipl. Ing.

  • Nachricht senden

16

Sonntag, 17. Mai 2009, 03:22

Hallo Olli,

danke für deine letzte Info; inzwischen ist alles klar.
Ein wenig Neues:

Meine Messungen am DX5e-Sender zeigen prakt. völlige Übereinstimmung mit deinen Ergebnissen.
Die Folge der 14*10 Bit dauert 1,1 ms; genauer kann ich nicht ablesen (rechnerisch 1,07); Wiederholzeit 22 ms (45 Hz). Für 1 Bit kann ich mit etwas Tricksen noch 7,6 µs ablesen, genauer geht´s auch hier nicht.
Aus deinen Daten ist eine geringfügige interaction zwischen Nick und Roll zu entnehmen; dürfte von der Knüppelmechanik herrühren.

Im Anhang 2 Bilder vom Innenleben des Senders.
µC, Rf-Modul und Potis werden aus stabilisierten 3,3 V gespeist. Stromaufnahme gesamt 82,7 mA, Rf-Modul allein 47,1 mA, => 155 mW. Wieviel davon als Rf-Leistung rausgehen, weiß ich nicht; könnten schon 100 mW sein.

Das RF-Modul ist größer als beim RTF-Sender und abgeschirmt; 12 Lötpins + ganzflächig mit Schaumstoffzwischenlage aufgeklebt => ich bau das jetzt nicht aus. Es sind aber nur 3 der 12 Pins beschaltet; GND, +3.3 V, Eingang "Metasignal". Das Letztere kommt von Pin 31 (TxD) des Controllers.

Der µC arbeitet mit 8 MHz (Quarz) und kann nach Lage der Dinge (Frequenz, Spannung, Beschaltung) nur ein ATMega 8L sein. Es gibt also nicht allzu viel Möglichkeiten der Baudrate-Konfiguration mit den UBRR-Registern.

Der Sender hat 2 Schaltereingänge. Einer davon ist K5 und beeinflusst dessen Bytes; der andere (Taster) hat eine Mehrfachfunktion (Trainerbetrieb, Binden+Failsafepositionen setzen, Reichweitentest); er beeinflusst auch die Bytes von K6.

Ich hab auch noch die Spannungen an den Knüppelpotis (Mitten und Endlagen) gemessen; lasse ich hier mal weg, aber bei Interesse kann ich sie nachreichen. Man kann daraus schließen, daß die Potis einen geringeren elektrischen Drehwinkel haben als sonst üblich (ist bei allen RC-Anlagen so), und daß sie mechanisch nur grob justiert eingebaut werden. Die Endlagen werden dann zum Schluß der Fertigung softwaremäßig kalibriert. Dabei und in der vermutlichen softwaremäßigen Begrenzung geht natürlich Auflösung verloren; mal sehen, was am Schluß rauskommt.


Als Nächstes werde ich versuchen, ein AVR-Progrämmchen zur Aufnahme des Metacodes und LCD-Anzeige der einzelnen Zahlenwerte zu schreiben. Das ist natürlich nicht das Ziel, dürfte aber öfters mal hilfreich sein.


Gruß,
Helmut
»haschenk« hat folgendes Bild angehängt:
  • DX5e-TX.jpg

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »haschenk« (17. Mai 2009, 03:28)


17

Sonntag, 17. Mai 2009, 10:46

Hallo Helmut,

super, danke für diese zusätzlichen Infos. Das mit den 8MHz bestätigt also die obige Vermutung, passt mit den 125 kbps zusammen. Dein HF Chip sieht etwas anders aus als wie bei mir, aber auch bei mir waren nur 3 Pins beschaltet. Um mich dazwischen zu schalten, habe ich es auch nicht ausgebaut, sondern es gab eine Drahtbrücke die ich aufgetrennt habe (und mit einem Jumper wieder schliessen kann :)).

Zitat

Als Nächstes werde ich versuchen, ein AVR-Progrämmchen zur Aufnahme des Metacodes und LCD-Anzeige der einzelnen Zahlenwerte zu schreiben. Das ist natürlich nicht das Ziel, dürfte aber öfters mal hilfreich sein.

Wenn du willst kann ich dir mein AVR Progrämchen posten mit dem ich die Metasignale ausgewertet habe (sendet über RS232), obwohl du in der Zeit die ich brauche um das zu posten den Teil wahscheinlich schon selbst, und besser geschrieben hast :)

An welchen Details der Beschaltung hast du erkannt, dass es sich um einen ATmega8L handelt (L ist mir klar)? Ich meine, das würde ich bei mir auch gerne mal checken.

Ciao,
Olli

haschenk

RCLine User

Beruf: Dipl. Ing.

  • Nachricht senden

18

Sonntag, 17. Mai 2009, 20:29

Hi Olli,

Zitat

An welchen Details der Beschaltung hast du erkannt, dass es sich um einen ATmega8L handelt...


Das kann ich so einfach garnicht sagen, weil es nur das Ergebnis von vorhergehender Übung bzw. praktischer Arbeit ist. Ich hab schon ziemlich viel (aber alles nur für Hobby/Modellflug) mit dem Mega8 gemacht, Programmieren und Layouten; da hat man dann häufig oder immer wiederkehrende Pinbelegungen irgendwann im Kopf. Das gilt aber nur für die immer gleiche Gehäuseform, in diesem Fall TQFP32, bei DIL28 müsste ich auch nachschauen.

Z.B. liegen auf Pin 1-8 2 I/Os von PortD, "verschachtelt" je 2x GND und Vcc, und die Anschlüsse für einen externen Resonator. Das sind Stellen, die beim Layouten immer etwas Probleme machen, wenn´s eng wird; oder auf Pin 9-15 sind keine ADC-Eingänge, 30 und 31 haben das UART als Zweitfunktion, usw.

Und da schaut man dann auf der Leiterplatte erstmal hin... ; erleichtet auch beim Fehlersuchen die Arbeit.

Auf dem Bild sieht man leider nicht, daß viele (schätze mal mindestens die Hälfte) der "Widerstände" nur Null-Ohm-Brücken sind, und auf der Bestückungsseite gibt´s auch zahlreiche Draht-Jumper.


Ich programmiere übrigens fast ausschließlich in Assembler; kann aber C lesen und in einfachen Fällen damit auch programmieren. Das hat nur "historische" Gründe, war eben früher (80xx, Z80, HC05/08...) mal "Pflicht", als es noch keine oder nur sehr teure Compiler gab.
Da meine Progrämmchen selten über 200 Worte (AVR-hex-Code) haben, ist die Assembler-Programmierung kein Hemmnis und hat manchmal sogar Vorteile. Man macht sich da ja auch im Laufe der Zeit eine kleine Bibliothek für immer wiederkehrende Routinen.

Bei größeren Aufgaben würde ich natürlich auf C umsteigen; die größeren Sachen (z.B. Propellerberechnung, Auftriebsverteilung von Tragflügeln u.ä.) für den PC habe ich früher in Turbo-/Borland-Pascal geschrieben.


Gruß,
Helmut

PS
Danke noch für deinen Hinweis auf das AVR-EVA-Board bei Pollin. Hab mir auch eins bestellt als Zweit- bzw. Drittboard. Normalerweise arbeite ich mit dem STK500 und AVR-Studio von Atmel. Das einzige Problem ist, daß man als "Privater" nicht an Programmiersockel für TQFP32 oder SOIC8 rankommt; noch nicht mal an Angebote. Da hat mir mal ein Bekannter (damals auch aus dem Forum) mit "Sonderanfertigungen" bzw. Teilen dafür sehr geholfen.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »haschenk« (17. Mai 2009, 20:45)


19

Montag, 18. Mai 2009, 00:38

Hallo Helmut,

Zitat

Das kann ich so einfach garnicht sagen, weil es nur das Ergebnis von vorhergehender Übung bzw. praktischer Arbeit ist. Ich hab schon ziemlich viel (aber alles nur für Hobby/Modellflug) mit dem Mega8 gemacht,

Tja, diese Erfahrung bringe ich bei weitem nicht mit, habe 15 Jahre nicht mehr gebastelt, und von Atmels etc weiss ich erst seit ein paar Monaten ... :) Dann werde ich das nicht rausfinden...

Ist schon lustig. Mit Z80 habe ich auch mal gebastelt, habe mir einen "Einplatinencomputer" selber gebaut (inkl Layout, ätzen, etc), und ein Eprom-Programierer-Program in Assembler geschrieben - aber das war's. TurboPascal habe ich auch viel benutzt, aber seit das Borland aufgegeben hat benutze ich C. Und das finde ich an den ATmels so cool, die Programmer sind einfach und billig, und dann gibt es auch noch nen C-Compiler...

Wenn dein Program läuft wäre es ja toll wenn du es zugänglich machen würdest, um davon zu lernen. :)

Ciao,

haschenk

RCLine User

Beruf: Dipl. Ing.

  • Nachricht senden

20

Donnerstag, 28. Mai 2009, 18:55

Hallo Olli,

nun ist die erste Version des "Metacode-Monitors" fertig. Siehe das angehängte Bild; erklärt sich eigentlich von selbst. Auf dem Bild sind die Daten meines Dx5e-Senders zu sehen, so wie beim Fliegen getrimmt und Sticks auf Neutral (ausgenommen "Gas" auf Null). Das Display ist handelsüblich 4x16.

Das Programm ist ca. 370 Worte lang, das Meiste davon wird für die LCD-Ausgabe gebraucht. Im Moment ist noch ein wenig externe Hardware erforderlich; zur Pegelanpassung (wegen des LCDs muß der µC mit 5V laufen), sowie ein nachtriggerbares Monoflop zur Synchronisation beim Einlesen der Daten. Das Letztere werde ich in der nächsten Version noch durch eine Softwarelösung zu ersetzen versuchen.

Du kannst Source- und Object-Code von mir kriegen. Dazu bräuchte ich deine Email-Adresse. Zum freien download möchte ich es im Moment noch nicht zur Verfügung stellen.


Gruß,
Helmut
»haschenk« hat folgendes Bild angehängt:
  • DSM2-Display.jpg

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »haschenk« (28. Mai 2009, 18:58)