Archiv verlassen und diese Seite im Standarddesign anzeigen : 2x GELÖST: ACT DSL-8 RSSI an EZOSD
Mahlzeit zusammen,
gibt es schon Erfahrungswerte oder Projekte, um das ACT PWM RSSI Signal in ein analoges Signal umzusetzen, um es dann im EZOSD als RSSI anzeigen zu lassen?
Habe auf Anhieb nur alle möglichen Mods von anderen Receivern gefunden.
Jeder Hinweis ist willkommen.
Thx
Moscito
Hallo Gemeinde,
wie es scheint hatte keiner eine Lösung - also habe ich mal eben mit der heißen Nadel selbst etwas gestrickt und möchte es Euch nicht vorenthalten.
Zuerst ein paar Details zum Thema:
Wie es scheint hat der Analogeingang am EZ-OSD Stromsensor einen Bereich von 0-2 Volt. Darüber hinaus kommt nur Unsinn heraus.
Weiterhin scheint der Eingang mit einem 200k(?) Widerstand bestückt zu sein (Eingangsimpedanz).
Um das RSSI Signal aus dem ACT Empfänger herauszubekommen muss dieser entsprechend der ACT Anleitung umprogrammiert werden.
Das RSSI Signal wird dann in Form eines PWM (Servo) Signals an einem der 8 Servoausgänge bereitgestellt.
Ziel ist es nun das PWM Signal des Empängers in eine 0-2V Analogspannung umzusetzen.
Schaltungsbeschreibung:
Benutzt wird ein Atmel Attiny45, der am Pin b4 das Servosignal abfrägt und auswertet. Anschliessend wird am Pin b0 ein PWM Signal mit 1,4 kHz und variierendem Puls/Pausenverhältnis ausgegeben.
Mittels einer banalen PWM basierenden Digital/Analog Umsetzung wird daraus dann so etwas ähnliches wie eine Gleichspannung erzeugt.
Das Ganze wurde unter Bascom gefrickelt.
Zuerst mal die Schaltung
http://farm3.static.flickr.com/2535/3994609363_760f789cee_b.jpg
Nur drei Bauteile werden benötigt
http://farm3.static.flickr.com/2648/3995369208_8f2c7440a4.jpg
So sieht es zusammengefriemelt aus
http://farm3.static.flickr.com/2673/3995369006_578262f270.jpg
Andere Seite
http://farm3.static.flickr.com/2622/3994608553_b85f6ac769.jpg
Und fertig
http://farm3.static.flickr.com/2532/3995368446_3a71424a22.jpg
Jetzt noch der Bascom Sourcecode
$regfile = "ATtiny45.dat"
$crystal = 1000000
$hwstack = 32
$swstack = 10
$framesize = 40
Config Timer0 = Pwm , Compare A Pwm = Clear Down , Compare B Pwm = Clear Down , Prescale = 1
Dim Timercount As Integer
Config Portb.0 = Output
Config Portb.4 = Input
Portb.4 = 1 ' Pullup active
Gimsk.5 = 1 ' PinChange enable
Pcmsk = &B00010000 ' PB4 change aktiv
Tccr1 = &B00001000 ' Prescale 128
On Pcint0 Readrctime
Portb.3 = 0
Enable Interrupts
Do
Loop
'-----------------------------------------------------------------------
Readrctime:
If Pinb.4 = 1 Then
Tcnt1 = 0
Else
Timercount = Tcnt1
Timercount = Timercount * 10
Pwm0a = Timercount
End If
Return
'------------------------------------------------------------------------
End
Aufgrund hoher Bauteiltoleranzen kann es notwendig sein den Multiplikator (Timercount = Timercount * 10) anzupassen.
Die Werte in Klammern im Schaltplan sind die gemessenen Werte. Die liegen schon ordentlich daneben.
Hab's heute getestet - funktioniert astrein.
Allerdings bleibt zu erwähnen, daß die Anzeige etwa um 5% schwankt.
Das kommt sicher durch einen Timerkonflikt. Wenn das Auslesen des Servosignals in die ISR springt, dann wird die PWM Generation kurzzeitig ausgesetzt.
Ist aber nicht wirklich tragisch.
Vielleicht gibt es hier ja ein paar Programmiercracks, die das besser lösen können.
So - das war's.
Viel Spaß damit.
Moscito
Grandcaravan
10.10.2009, 18:41
Wow! Du hast meinen Respekt!
Vielen Dank dafür!
Beste Grüße
Heiko
Hallo Moscito,
angeregt durch Deinen Thread möchte ich das Thema ein wenig aufbohren:
Ich lese die beiden RSSI Signale aus einem ACT Empfängerdiversity mit einem Arduino aus. Mit einem 3 Stufen Schalter am Sender (dessen Kanal ich auch mit dem Arduino auslese), kann ich dann die Anzeige zwischen den RSSI Stärken beider Empfäger - oder dem jeweils besseren Signal umschalten.
Mein Problem: Das EzOSD hat Schwierigkeiten mit dem PWM Signal aus dem Arduino (490 Hz.).
Nun habe ich gesehen, daß Du Dir aus einem Widerstand und einem Kondensator einen Low Pass Filter gebaut hast.
Meine Frage: Wie errechne ich die richtigen Werte für den Widerstand und den Kondensator für die PWM Frequenz des Arduino (490 Hz.)?
Grüße,
Georg
flyingKenny
21.01.2010, 18:06
Hi,
Hatte auch schon wegen den diversity ACT überlegt, ob ich das aus mienem großen in den FPV einbaue.
Jedenfalls kann man mit einem µC auch beide Servosignale auslesen und dann einfach das bessere an das OSD weitergeben. Programmierteschnisch ist das kein Problem, muss nur mal jemand machen.
Einen Tiefpass berechnet sich so: Grenzfrequenz=1/(2*Pi*R*C)
in Si-Einheiten eigeben ! 1µF = 0,000001 F
okke dillen
21.01.2010, 18:06
guck mal hier (http://www.sengpielaudio.com/Rechner-RCglied.htm)
;) o.d.
vielen Dank für die Hilfe...
... uff - die Berechnung klingt für mich doch komplizierter als ich gedacht hätte...
Die faule Variante: Könnte mir von Euch jemand sagen, was für einen Widerstand und was für einen Kondensator ich bei 490 Hz. brauche?
Um meinserseits auch etwas beizutragen stelle ich gerne die Software in C (für Arduino) ein, wenn alles funktioniert.
Grüße,
Georg
okke dillen
21.01.2010, 19:10
an was für übertragungsströme denkst Du denn so?
;) o.d.
Die analoge Spannung wird nur als Signal für das EzOSD gebraucht. Nach meinem Messgerät sind es gerade mal 0,0052 mA...
Steffen Graap
21.01.2010, 19:25
@moscito
Vorneweg, mit Bascom kenne ich nicht wirklich aus.
Ich denke mal dein Problem ist die Initialisierung des Timers. Es gibt beim Tiny zwei PWM MOdes. Einmal FAst-PWM und ein mal Phase Correct PWM. Du bräuchtest für dein Projekt den zweiten Modus (Phase Correct).
Auch würde ich den Code ändern. So wie ich dein Programm verstehe, löscht du Timer1 solange das Eingangssignal High ist. Wenn es Low wird änders du ständig das PWM register. Das kann zu Problemen führen.
Ich würde einen Pin-Change-Interrupt auf den Eingang programmieren. Bei der High->Low-Flanke löscht du den Timer1, bei der Low->HIGH-Flanke übernimmst du den Timerwert und skalierst ihn mit deinem Faktor und schreibst ihn in das PWM-Register. Das kann man auch in einem Befehl machen (Pwm0a = Tcnt1 * 10). Sei dir aber darüber bewusst, das diese Skalierung ihre Zeit dauert, da der Tiny keinen Hardwaremultiplizierer hat.
So wird die Berechnung und das Update des PWM-Registers nur einmalig pro Eingangs-PWM-Impulse ausgeführt.
Gruß Steffen
Hallo Carlson und alle anderen,
angeregt durch meine eigene Vorarbeit habe ich mein Projekt nochmals neu aufgerollt. Ich kann's einfach nicht leiden, wenn es nur zu 95% optimal ist.
Die neue Lösung hat einen Atmel Attiny 45, der das digitale DSL Signal vom Act Empfänger am DSL Stecker ausliest, verwurstet und mittels eines I²C Digital/Analog Wandlers 100,00%ig für das EZOSD aufbereitet.Mit Referenzspannung, Datenverlusterkennung und allem Brimborium.
http://farm5.static.flickr.com/4063/4293789048_af1432f9c2_b.jpg
Wenn jemand Interesse hat werde ich die Daten mal aufbereiten und posten ...
Moscito
flyingKenny
21.01.2010, 20:05
Ich hätt das extrem gerne, da mich das brennend interessiert, wie die ACT Empfänger kominizieren.
Das ist doch auf jeden fall 1000x besser.
Na dann schauen wir mal:
das Ganze ist wieder in Bascom geschrieben. Der Sourcecode kommt gleich.
Im Attachment befindet sich der Sourcecode, die Hex Datei, der Eagle Schaltplan, das Eagle Board und beides noch als PDF.
' ################################################## ###################################
' # -----------------------------RSSI2ANA------------------------------------ #
' # Firmware für ATTiny45 zur Auswertung des seriellen Datenstroms eines ACT #
' # DSL-8 DSQ R/C Empfängers um den RSSI (Feldstärke) Wert zu ermitteln und #
' # daraus eine äquivalente 0-1900 mV Analogspannung (0-100% RSSI) für den #
' # RSSI Eingang des EZ OSD zu erzeugen. #
' # #
' # Hinweis: #
' # Diese Programmeinstellungen sind für den DSL-8 geschrieben und bisher nicht mit #
' # anderen Receivern getestet, da diese einen anderen Wert für den RSSI Level #
' # ausgeben. Wenn das RSSI Byte 0-161 ist, sollte es allerdings funktionieren. #
' # #
' # Features: #
' # - Selbstkalibrierend um Bauteiltoleranzen und Umgebungstemperatur zu kompensieren #
' # - I2C Anbindung des DAC #
' # - DAC auf Null setzen bei fehlendem Datenstrom #
' # - LED Anzeige für erfolgreich ausgelesene Daten (1s Blinken) #
' # - LED Anzeige für fehlenden Datenstrom (schnelles Blinken) #
' # - RS232 UART Emulation #
' # - Debug Ausgabe #
' # #
' # Fusebits #
' # - Internal Clock Divider by 8 = OFF #
' # - RSTDISBL =1 - WIRD NUR FÜR DEN DEBUG AUSGANG BENUTZT - KEIN MUSS! #
' # #
' # VORSICHT! Sobald der Reset Pin disabled wurde kann der Baustein nicht mehr mit #
' # einem ISP Programmer gebrannt werden. Nur noch mit einem HV Progger!!! #
' # --------------------------------------------------------------------------------- #
' # (c) 2009 Moscito #
' # Sourcecode und Schaltung frei zur privaten Nutzung #
' # Gewerbliche Nutzung ausgeschlossen ! #
' # #
' ################################################## ###################################
$regfile = "atTiny45.dat"
$crystal = 8000000
$hwstack = 32 ' default use 32 for the hardware stack
$swstack = 10 ' default use 10 for the SW stack
$framesize = 40 ' default use 40 for the frame space
$lib "i2c_usi.lbx" ' I2C benutzt modifizierte USI Library
Config Scl = Portb.2 ' Ports fuer I2C-Bus definieren
Config Sda = Portb.0
Config Adc = Single , Prescaler = Auto , Reference = 2 'ADC Wandler konfigurieren - interne 2.5V Referenz
Tccr1 = &H00 ' Timer1 Prescaler = Aus (Timer anhalten)
On Timer1 Timer1_isr ' Timer ISR definieren
Dim Datenbyte As Byte
Dim Lastbyte As Byte
Dim Analogwert As Single
Dim Dacout As Integer
Dim Prozent As Single
Dim Adcin As Word
Dim Adcsum As Word
Dim X As Byte
Dim Calib As Single
Dim I2cval As Integer
Dim Max517 As Byte
Dim Cmd_max517 As Byte
Dim Blinker As Integer
' Deklarationen
Max517 = &H58 ' Max517 Slave Adresse
Cmd_max517 = 0 ' Das zweite (Command) Byte beim Max517 ist immer 0
Lastbyte = 1 ' Damit wir bei RRSI = 0 einen Unterschied haben
Declare Sub I2cout(byval I2cval As Integer) ' I2C Ausgaberoutine deklarieren
I2cinit ' I2C Bus initialisieren
Open "COMB.4:38400,8,N,1" For Input As #2 ' Soft UART Eingang konfigurieren
Open "COMB.5:38400,8,N,1" For Output As #1 ' Soft UART Ausgang konfigurieren
' Willkommensmeldung
Print #1 , "" ' im Debug ausgeben
Print #1 , "ACT DSL8 DSQ - RSSI TO ANALOG CONVERTER"
Print #1 , "(C) 2009 Moscito"
Print #1 , ""
Print #1 , "Calibrating ..."
Call I2cout(255) ' Analogausgang auf Maximum zum Kalibrieren
Start Adc ' 254 Messzyklen starten
For X = 1 To 254 ' Analogspannung des Max517 mit ADC einlesen
Adcin = Getadc(3) ' Analogwerte zusammenzählen
Adcsum = Adcsum + Adcin ' Im Debug ausgeben
Print #1 , " " ; Adcin; ' Wir lassen dem ADC ein wenig Zeit
Waitms 20
Next X
Adcsum = Adcsum / 254 ' Mittelwert der gemessenen Analogwerte ermitteln
Print #1 , ""
Print #1 , "AVG ADC: " ; Adcsum ' Im Debug ausgeben
Stop Adc ' ADC anhlten um Strom zu sparen
Calib = Adcsum / 250 ' Kalibrationsfaktor ermitteln für maximale Ausgabe von 1900 mV
Print #1 , "Calibration Factor : " ; Calib ' Im Debug ausgeben
Analogwert = 255 / Calib
Dacout = Analogwert
Call I2cout(dacout) ' Wir testen die Kalibration und geben mal 1900 mV aus
Print #1 , "Testing 100% Output" ' Im Debug ausgeben
Waitms 2000 'Für 2 sec
Call I2cout(0) ' Max517 wieder auf 0 setzen
Print #1 , "Calibration done" ' Im Debug ausgeben
'Wird erst hier konfiguriert, da sonst die DAC Kalibration in die Hose geht, da der LED Output den ADC3 verfälscht
Config Pinb.1 = Output ' LED Ausgabepin konfigurieren
Led Alias Portb.1 ' Spitzname für die LED
Enable Timer1 ' Timer1 einschalten
Enable Interrupts ' Interrupts für Timer1 einschalten
'Safe the Planet
Set Prtim0 'Timer0 deaktivieren
Set Pradc 'ADC deaktivieren
Do ' ****** HAUPTPOGRAMM ******
Datenbyte = Waitkey(#2) ' Datenbyte aus Empfänger einlesen
Tccr1 = &H0F ' Config Timer1 = Timer , Prescale = 16384
If Datenbyte = 255 Then ' Wenn 255 dann weiter
Datenbyte = Waitkey(#2) ' ... und nochmal
If Datenbyte = 255 Then
Datenbyte = Waitkey(#2) ' drei weitere
Datenbyte = Waitkey(#2) ' Datenbytes
Datenbyte = Waitkey(#2) ' auslesen
Datenbyte = Waitkey(#2) ' Das ist jetzt das RSSI Byte
If Datenbyte <> Lastbyte Then ' Änderung im RSSI Signal?
Analogwert = Datenbyte * 1.5838509316770186335403726708075 ' Der Receiver liefert nur Werte von 0 - 161
Analogwert = Int(analogwert) ' Daher Anpassung auf 0 - 255
Dacout = Analogwert / Calib ' Kalibrationsfaktor mit einrechnen
Prozent = Datenbyte / 1.61 ' Umrechnung für Prozentangabe im Debug Terminal
Prozent = Int(prozent) ' Wir basteln uns eine Ganzzahl
Print #1 , "DAC: " ; Dacout ; " (" ; Prozent ; " %)" ' Im Debug ausgeben
Call I2cout(dacout) ' I2C Routine für Ausgabe aufrufen
Lastbyte = Datenbyte ' Wert merken für nächsten Durchlauf
End If
If Blinker > 20 Then ' Bei jedem 20. Durchlauf wird die LED getoggled
Toggle Led ' sind so etwa 0.5s
Blinker = 0 ' (Anzeige für erfolgreichen Datenempfang)
Else
Incr Blinker ' Blinkerzähler hochzählen
Tccr1 = &H00 ' Stoppt Timer1 (Prescaler = 0)
Tcnt1 = &H00 ' Lädt Timer1 mit 0 (Langsames Blinken)
End If
End If
End If
Loop ' ****** ENDE HAUPTPROGRAMM ******
End
Timer1_isr: ' ****** Timer 1 Interrupt Service Routine ******
If Dacout <> 0 Then ' Den DAC bei Datenverlust nur einmal auf Null setzen,sonst spinnt er
Call I2cout(0) ' Max517 wieder auf 0 setzen
Dacout = 0 ' ... und merken ...
End If
Toggle Led ' LED toggeln
Print #1 , "Receiver Data Dropout!" ' Im Debug ausgeben
Tcnt1 = &HBF ' Timer 1 vorladen für schnelles Blinken
Return
Sub I2cout(byval I2cval As Integer) ' ****** Unterprogramm für I2C Ausgabe - I2Cval ist der Beiwert der gesetzt wird ******
I2cstart ' I2C Startbedingung setzen
I2cwbyte Max517 ' I2C Slave Adresse schicken
I2cwbyte Cmd_max517 ' I2C Command (0) schicken
I2cwbyte I2cval ' I2C Wert zum DAC schicken
I2cstop ' I2C Stopbedingung Setzen
End Sub
N'joy
Moscito
okke dillen
22.01.2010, 00:37
wow! :D
die progsprache erscheint mir ja verblüffend einfach, das ist ja weit weg von jeglichem assemblergedöns! da könnt ja sogar ich mich noch mit anfreunden...hmm :cool:
im wahrsten sinn des wortes - "analog" dazu: @ carlson: also ja, bei 200k eingangsimpedanz... pfhe! :D
eine beispielbestückung wäre zb R= 3k3 und C= 100nF
nach f0=1 / 2pi * R * C
also f0=1/2pi*3300Ohm*0,0000001F= 482Hz
nah genug dran mit standardbauteilen.
aber, ist deine pwm-frequenz auf 490Hz? dann willst du ja gerade nicht, daß die 490Hz noch durchkommen, sondern daß daraus soweit irgend möglich ripplefreie gleichspannung wird.
dann sollte die zeitkonstante Tau (=R*C) eher zur ansprechgeschwindigkeit passen, anstatt zur pwm-frequenz.
die würd ich so grob mal bei...öööhm...pffh...vielleicht 20Hz ansetzen, dann läge die ansprechgeschwindigkeit für eine DC-wertänderung am C bei grob 1/20 sekunde. oder? wäre das schnell genug?
dann könntste zb C=330nF und R=22k für 22Hz nehmen. R sollte nicht über 1/10 der 220k meßeingangsimpedanz am osd liegen, während C klein genug bleiben sollte, um keinen polaren elko nehmen zu müssen, also unter 1µF.
wenn mir jetzt kein schnitzer unterlaufen ist, sollte das so hinkommen, dann hast Du den arduino auch am laufen ;)
viel spaß,
o.d. ;)
Bascom ist in der Tat recht einfach zu programmieren.
Wenn es spezieller wird steht man aber in der Regel doof da.
Außerdem war (ist) Bascom immer schon ziemlich buggy.
Nochmals zu dem Tiefpass-Thema:
Ich bin von diesem Konzept weggegangen, weil es immer ein Kompromiss zwischen Meßzyklus und Restripple ist.
Außerdem müssen immer mehrere Messungen durchgeführt und gemittelt werden um ein vernünftiges Ergebnis zu erhalten.
Für so etwas einfaches wie das RSSI Signal eigentlich durchaus ausreichend.
Im Moment habe ich eine etwas komplexere PWM Motorsteuerung im Angriff. Hierbei muss der PWM Motorstrom ebenfalls über einen RC Tiefpass gefiltert werden um ihn zu messen. Der berechnete Tiefpass mit einer Grenzfrequenz von 1/10 der PWM Frequenz brachte nur Müll. Also statt R ein Poti rein und ausprobiert. Jetzt geht es gut - wem gut reicht ...
Ich denke wenn eh schon ein u-Controller drin ist ist ein DAC doch kein Aufwand mehr ...
Moscito
Ich sehe den Low Pas Filter auch eher als Kompromiss. Nachdem es beim großen C heute nicht ansatzweise alle Teile vorrätig gab, die ich benötigt hätte um den Filter zu bauen, habe ich nun auch eine andere Richtung eingeschlagen.
Auch wenn es wie die sprichwörtliche Wurzelbehandlung durch den Allerwertesten ist, habe ich mir überlegt, mit dem Arduino ein ausgemustertes Servo anzusteuern. Je größer das RSSI Signal, desto größer der Ausschlag. Der Arduino ist also eigentlich nur noch dazu da, die RSSI Signale der beiden Empfänger zu koordinieren.
An das Poti des Servos habe ich nun ein Kabel gelötet, von dem ich eine absolut saubere analoge Spannung je nach Ausschlag zwischen 1 und 3 Volt abgreifen kann. :D :D :D
Ein DAC wäre bestimmt die sauberere Lösung gewesen. Ich muss aber zugeben, daß ich als völlig fachfremder Mensch schon stolz wie Oscar bin, einen Arduino programmieren zu können. Ein DAC hat schon wieder so viele Beinchen, daß ich laaange gebraucht hätte bis ich verstanden hätte wie ich damit umgehen soll... :rot:
Grüße,
Georg
PS: Okke - vielen Dank für Deine Hilfe und die Mühe mit den Kondensatoren!
Update:
Ich habe testweise mal alles zusammengesteckt und den Arduino programmiert. Es scheint super zu fuktionieren. Die RSSI Anzeige lässt sich nun durch einen drei Stufen Schalter am RC Sender umschalten (linker Empfänger - rechter Empfänger - bester Empfänger). Dadurch ist es mir erstmalig möglich, verschiedene Antennenverlegungen und Antennenlängen direkt am "fliegenden Objekt" zu vergleichen. Ich bin gespannt!
Grüße,
Georg
Steffen Graap
23.01.2010, 00:35
Hallo moscito / all
Klasse Leistung dein RSSI->Analog-Wandler. Im gegensatz zur ersten Lösung umweiten besser, und damit mein ich nicht nur den Kommentar.:P:
Aber als Softwareentwickler liegen mir noch ein paar Steinen im Magen. Da ich deine Programmiererfahrungen nicht kenne, siehe folgendes nicht als Kritik, sondern als Ratschlag für zukünftige Entwicklungen. Sollte dier das alles schon bewußt sein, vergiss mein Post.
Mach dir bitte mal Gedanken über die Genauigkeiten diener Variablen, und die damit verbundenen Ausführungszeiten und Codegrößen. Mehrfach benutz du Flotingpointvariablen in deinem Programm. Das Rechnen, und insbesondere die Multiplikation und Division mit diesen Zahlen kostet dem kleinen Tiny emens viel Rechenzeit, und vergrößert den HEX-Code. Wie schon weiter oben geschrieben hat der Tiny keinen Hardwaremultiplizierer, muss also Multiplikationen per Software erledigen, Flotingpointzahlen verschlimmern diese Berechnungen noch mehr. Du nutz z.B. zur Skalierung deines Alanlogwertes eine Zahl mit 31:???: Nachkommastellen (mehr hat der Windowsrechner wohl nicht her gegeben:D) Da dein Eingangswert (RSSI von COM) aber nur 161 unterschiedliche Zustände annehmen kann, werden alle folgenden Wert keine höhere Auflösung haben. (Hier sei kurz erwähnt, das man die Auflösung magrinal erhöhen kann indem man das Rauschen eines Signales rausmittelt kann. Dies funktioniert aber nur bei verrauschten Signalen.) Eine Skalierung mit 1,58 hätte bei weitem gereicht um deinen Wert in das 255'er Rastes zu skalieren.
Als nächsten Schritt erzeugst du mit (INT) eine Ganzzahl von deinem errechneten Wert, speicherst sie dann aber wieder in der Floatingpointvariable. Damit hast dunur erreicht, das die Nachkommastellen weg sind (deine Genauigkeit also wieder sinkt), der Rechenaufwand für weitere Berechnungen aber der gleich bleibt. Du solltest die Ganzzahl dan auch in einem INT speichern.
Nachfolgend ermittelst du den Ausgabewert für den ADU indem du deinen Analogwert durch den Kalibreirungswert (Floatingppoint) teilst. Hier gilt das gleiche wie oben schon gesagt. Selbst wenn mann die Gesammtgenauigkeit nicht in Frage stellt, warum verrechnest du den Kalibrierwert nach der Kalibrierung nicht einmalig mit dem Skalierwert (1,58) und rechnest dann mit diesem Wert weiter:???: Du würdest dir pro Hauptschleifendurchlauf eine zeitraubende Multiplikation/Division sparren.
Die Debugausgabe wird ja nicht immer gebraucht, verbraucht aber in der Hauptschleife Zeit (Berechnung des Prozentwertes, Ausgabe über COM). MAch doch einfach einen Jumper in deine Schaltung, den du beim Start abfragst, und damit deine Ausgabe einschaltest. Da ja schon alle Pins belegt sind kannst du hierzu den Debugausgabepin selbst nehmen. Lege diesen einfach über einen Steckjumer oder Dip-Schalter auf Masse. Bei der Initialisierung definierst du den Pin als Eingang mit aktiven PullUp, und fragst den Pin ab. Ist er Low (jumper gesetzt), bleibt er ein Eingang und die Debugausgabe bleibt aus, ist er High, aktivierst du den SoftCOM auf dem Pin und gibst deine Debugdaten aus.
Genauigkeit der ganzen Schaltung. Einer meiner Dozenten hat mal gesagt: Immer nur so genau wie nötig, und nicht wie möglich. Wie genau muss die Anzeige im OSD überhaupt sein? Was soll mit der Anzeige erreicht werden? Soll sie nur dazu dienen ein verlassen des Sendebereiches zu erkennen, dann würde eine Genauigkeit von 50 Schritten locker reichen. Soll die Anzeige zum Vergleich von Antennenverlegungen dienen, sollte sie die max. Genauigkeit (161) haben.
Hier ein Vorschlag, der wenig rechenleistung benötigt:
Bei einer Referez von 2,5V am ADU wird für 1,9V eine Vorgabe von 193,8 benötigt ( 1,9/(2,5/255) ). Das heißt also bei einem Eingangswert von 161 brauchen wir einen Ausgabewert von 193. Die Differenz der beiden Werte beträgt 32. Um diese Erhöhung linear auf den Eingangswertebereich zu verteilen teilen wir 161 durch 32 und erhalten 5,03125 (rund 5). Alle 5 eingangsschritte muss der Ausgabewert un 1 erhöht werden. Mit "Ausgabe = Eingabe + (Eingabe / 5)" wird genau dies erreicht. Hierbei erfolgt nur eine Division mit Ganzzahlen. Das Endergebnis ist fast das gleiche. siehe Excel-Tabelle (zip) im Anhang. Der Fehler der Bauteiltoleranzen (TL431 1%-2%,MAX517) ist größer.
Gute Nacht Steffen
PS: Sorry für die Länge
Hallo Steffen, All,
zuerst mal Danke für Dein Lob und Deine Verbesserungsvorschläge.
Ich hätte ja im Leben nicht gedacht, daß sich jemand den Sourcecode überhaupt mal anschaut :D
Du hast natürlich mit allen Deinen Aussagen Recht. Zu dem Zeitpunkt, als ich das Proggie geschrieben habe war ich ein noch blutigerer Anfänger im proggen als jetzt. Inzwischen hat es sich ein wenig verbessert. Allerdings bin ich doch eher auf der Hardwareseite angesiedelt. Von daher war ich heilfroh, daß es überhaupt fehlerfrei funktionierte ;) und auch ein wenig stolz auf die Features, wie Autokalibration, Debugausgabe auf dem Resetpin und sonstiges Gedöns.
Deine Vorschläge sind echt interessant - ich werde (nach dem gegenwärtigen Projekt) unbedingt mal versuchen alles umzusetzen - schon alleine um daraus zu lernen... Außerdem fehlt ja noch die Ausschöpfung der Möglichkeit die Checksumme des ACT Datenstroms zu verifizieren.
Vielleicht schwenke ich dann gleich auf C um, da ich jetzt bereits erste Anzeichen erkenne, daß mein linearprogrammierter alter Verstand langsam begreift warum man besser objektorientiert programmiert. Langsam halt ....
Allen Anderen sei versichert, daß es trotzdem funktioniert und auch keiner Scheu haben sollte selbst Hand anzulegen, den Code zu verbessern.
Moscito
Grandcaravan
24.01.2010, 11:09
Hey Leute!
Echt klasse, was ihr da erstellt habt. Meine Hochachtung zu dieser Leistung!
Es wäre toll, wenn das komplette Projekt noch einmal in einem eigenen Thema zusammengefasst werden könnte ;)
Beste Dank und noch einen schönen Sonntag!
Heiko
Steffen Graap
24.01.2010, 17:47
Hey moscito
Wenn du mit C Anfangen/weitermachen möchtest, dann lege ich die als Entwicklungsumgebung eclipse + WinAVR ans Herz. Das ganze ist kostenlos, und dadurch das die eclipse Platform ein OpenSource-Projekt ist gibt es dafür noch unendlich viele Adons. Aber selbst die eclipse allein stellt schon so manchen kaufbaren C-Compiler in den Schatten.
Zwecks Checksummenprüfung:
In meinen Projekten lasse ich die ankommenden COM-Daten per TX-Interrupt in einen Puffer legen. Aus diesem Puffer wird bei jedem Hauptschleifendurchlauf alle Daten einer Sequenz (solange vorhanden)entnommen, auf Startbyte, Datenanzahl und Cheksumme geprüft, und wenn alles I.O. ist die Daten verarbeitet, und über Variablen den weiteren Programmfunktionen zur Verfügung gestellt. Somit brauchst du dich nicht mehr mit der Com-Funktionalität herumschlagen, und die Daten stehen überall zur verfügung. Auch lässt sich so einen TimeOut-Überwachung einbauen, die nach TimeOut die Variablen löscht.
Übrigens habe ich mal ein keines C-Projekt für den Tiny 45 gemacht, um einen Vergleich zwischen Floatmultiplikation und Ganzzahlmultiplikation zu erhalten. Die Übernahme aus USIDR (universal serial Data Register) musste ich machen, da der Compiler bei einer festen Zahl die Berechnung sonst im Precompiler erledigt. Hier der C-Code:
#include <avr/io.h>
float Data_Out = 0;
float Data_In = 0;
//unsigned int Data_Out = 0;
//unsigned int Data_In = 0;
#define FAKTOR 3
int main (void)
{
Data_In = USIDR;
Data_Out = Data_In * FAKTOR;
return 0;
}
Ich habe jeweils mit float- oder int-Variablen compiliert, wobei die jeweils anderen Rasukommentiert ( // ) wurden. Dann hab ich in AVR-Studio die Ausführungszeit gemessen, dabei ist folgendes herrausgekommen:
Variablentyp---Zeit---------Flashgröße--RAMgröße
float----------3065 Takte--2070 Byte---272 Byte
INT-----------88 Takte----136 Byte-----4 Byte
Du siehst die Unterschiede sind gewaltig.
Gruß Steffen
Hallo Moscito,
ich hoffe, Dein Projekt geht weiterhin mit so großen Schritten voran wie bisher. Ich bin nach den ersten Testflügen an eine Herausforderung gestoßen und würde gerne wissen, ob sie Dir auch schon aufgefallen ist und wie Du damit umgehst:
Ich lese das RSSI Signal vom Empfänger aus und gebe linear weiter an das OSD (vereinfacht ausgedrückt). Sobald ich jetzt in einer Entfernung von mehr als 200 Metern fliege, zeigt das OSD nur noch Werte zwischen ca. 0 und 20 % an obwohl ich mich noch lange nicht am Rand der Reichweite befinde. Ich habe bei ACT mal gelesen, daß die Ausgabe des RSSI Signals bewusst restriktiv dargestellt wird, da man Auffälligkeiten dadurch angeblich besser erkennen kann. Mir ist das in der Vergangenheit auch an den internen LOGs der ACT Empfänger aufgefallen: Fast der gesamte Flug wurde dort meist im unteren Fünftel der Empfangsstärke aufgezeichnet.
Ist Dir das auch schon aufgefallen?
Mein Lösungsansatz ist nun, das eingelesene RSSI Signal nicht mehr linear weiterzugeben sondern in eine Exponentialkurve umzurechnen damit der Bereicht der geringeren Signalstärke mit einer größeren Skalierung dargestellt wird (ähnlich der Expo Funktion im RC Sender: Kleine Knüppelbewegung = großer Ausschlag).
Grüße,
Georg
@ Steffen,
sorry für die späte Rückmeldung. Musste mal eben kurz meinen Arbeitgeber wechseln :D
Ich hatte mir vor geraumer Zeit mal Eclipse für ein Amateur Java Script Projekt (Ethernet Steckdose mit Webserver) angekuckt. Das Teil war mir zu gewaltig. Bin dann auf Visual Cafe umgeschwenkt.
Werde mir jetzt mal WinAVR reinziehen und am besten noch nen AVR C-Kurs voraus... Mehr dann in ein paar Monaten :S:
Das mit dem Tx Interrupt hatte ich mir erst auch überlegt - haperte dann aber an der mangelnden Hardware Uart des Tiny 45.
Die Unterschiede zwischen float und int sind ja echt gewaltig - da muss man sich echt mal einen Gedanke um die Wichtigkeit der Nachkommastellen machen.
@Georg:
das ist ein schwieriges Thema.
Zum Einen zeigt der DSL8 immer nur maximal 63% Signallevel an zum Anderen ist das Verhalten des Signals nicht ganz einfach zu identifizieren.
Mein Eindruck bisher war, daß der Signallevel des ACT von 0 auf 161 immer gleich springt: 0-8-16-32-64-128-161 (oder so ähnlich).Auf jeden Fall stufenweise und stark zeitverzögert.
Weiterhin scheint noch ein Bug im EZOsd zu sein, der große Sprünge nicht verarbeiten kann (siehe extra Thread hier im Unterforum).
Und jetzt mal zu meinen Werten:
Habe bisher nur einige wenige Flüge mit OSD aufgezeichnet - alle mit dem EzOSD/Analog Konverter in der Urversion. Dieser setzt die 161 in 100% um.
Ich habe während des Fluges eigentlich nur zwei Situationen:
1.) 100% RSSI
2.) Voll abkackendes Signal - bis runter auf 0. Eigentlich immer in der Wende in der die Antenne die kleinste Fläche abbildet. Das Signal fängt sich aber immer gleich wieder.
Selbst bei einer Höhe von 450m und 400m Entfernung ist der Grundlevel nicht unter 100% gefallen.
Mein letzter Crash ließ sich aber astrein auf den niedrigen RSSI Level zurückführen, wie die Videoauswertung später zeigte. Ursache war ein schlechter geografischer Aufbau der entscheidenden Komponenten.
Ich hoffe bald eine neue Testreihe mit dem neuen Konverter machen zu können - zuerst muss aber erst mal der Job in trockene Tücher gebracht werden ...
Cheers
Moscito
Steffen Graap
31.01.2010, 23:22
Hey Moscito
Ja das eclipse ist schon gewaltig. Mit dem PlugIn für den Win Avr geht es aber schon, man muss ja nicht die ganze Funktionalität benutzen.
Zum Thema AVR C-Kurs habe ich noch zwei Links. Der eine ist ein reines C-Lexikon im allgemeinen als Onlinebook. Der andere ist ein AVR-GCC-Tutorial.
http://openbook.galileocomputing.de/c_von_a_bis_z/
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial
Gruß Steffen
Du meinst, das RSSI Signal aus Deinem Empfänger kennt nur diese 7 Stufen (0-8-16-32-64-128-161)? Das kann ich nicht bestätigen. Ich lese das Signal in C mit dem Befehl „pulseIn“ aus und bekomme dadurch Werte zwischen ca. 800 und 2100. Dazwischen ist je nach Empfangsstärke alles möglich. Ich habe aber auch in der Empfängersoftware den RSSI Anteil zweimal auf den Kanal gemischt um einen doppelten Ausschlag => mehr Auflösung zu bekommen. Ein am RSSI Ausgang des Empfängers angeschlossenes Servo bewegt das Servohorn dadurch zwischen min. und max. ca. 90°. Hast Du mal versucht, ob sich ein Servo am RSSI Ausgang Deines Empfängers auch im Rahmen dieser 7 Stufen bewegt?
Nicht ganz passend zum Thema: Ich war erstaunt, wie stark der Empfang abnimmt, wenn man mit der Senderantenne auf den Flieger „zielt“. Da kann der Empfang in einer Entfernung um 200 Meter bis auf Null abfallen während schon ein ganz leichter Winkel reicht um auch in mehr als 800 Metern noch guten Empfang zu haben.
Grüße,
Georg
@Steffen:
Danke für die Links! Der Kurs bei uC.net ist genau, was ich gesucht hatte. X-mal besser als die anderen, die ich bisher gefunden hatte. Da hab ich ja genug zu lesen :rot:
@Georg:
Definitiv in Stufen. Hab es mit nem Servo, mit PWM Auswertung über PulseIn und Abfrage des seriellen Datenstroms probiert. Immer das gleiche Ergebnis.
Mal ganz banal gefragt: welchen ACT benutzt Du? Bei mir ist es ein DSL-8 DSQ.
Ja das mit der Antenne ist so eine Sache. Da könnte ich noch zehn weitere Threads aufmachen.
Lass mal eben zusammenfassen: Am Anfang war der EZStar mit Bürste und alles war cool, außer meine Flugkünste. Dann war alles im Griff und es kam der erste brushless Motor. Von diesem Augenblick an hatte (habe) ich wenns doof läuft Reichweiten unter 50m. Hab inzwischen ALLES bereits x-Mal gewechselt und auch das DSL-8 Set als Diversity eingebaut, aber alles für den Popo. Das Thema brauchen wir auch nicht mehr vertiefen - Fakt ist, daß der Aufbau der elektrischen Komponenten im EZ mehr als suboptimal ist. Inzwischen fliegt eh der Twinny und der EZ verstaubt ...
Das blöde an der ganzen Sache ist schlichtweg, daß ich die 2,4 GHz für's Video brauche und deshalb noch mit 35MHz fliegen muss :dodgy:
Cheers
Moscito
Ich fliege 2 ACT DDS 10 PMC als Diversity wobei ich sagen muss, daß der Futaba R149 DP im direkten Vergleich eigentlich genauso gut ist. Erstunlich, daß die Ausgabe der RSSI Signals so unterschiedlich ist. Ich würde direkt mal bei ACT anfragen ob das so gewollt ist. Haben die Empfänger nicht lebenslange Garantie?
BL Motoren in Verbindung mit 35 MHz können schon zu einem abendfüllenden Thema werden... Ich habe lange Zeit in diversen Fliegern und nicht zuletzt in einem 450er Heli (alle Komponenten auf engstem Raum) damit herumgefriemelt.
Nach meiner Erfahrungen streuen die Störungen des BL Motors fast immer durch die Stromversorgung in den RC Empfänger und weniger durch Antenne und Leitungen, wie so oft behauptet wird. Versuche es mal spaßeshalber mit einem separaten 4 Zellen NI-XX Akku für den RC Empfänger. Achte dabei aber darauf, die + Leitung vom RC Empfänger zum Regler zu unterbrechen weil der Regler die Doppelstromversorgung normalerweise nicht verträgt. Ich bin mir fast sicher, daß damit Deine Sorgen mit Störungen durch den BL Motor Vergangenheit sind.
Ich drücke die Daumen!
Grüße, und viel Erfolg im neuen Job!
Georg
So langsam wird es klarer.
Die DDS 10 sind komplett anders als die DSL-8.
Hatte unlängst einen 10er von einem Bekannten in der Mangel.
Dagegen ist der 8er ein kastriertes Garnichts.
Die Anfrage bei ACT kann ich mir wohl schenken, da beide 8er sich gleich verhalten.
Wir wollen es jetzt auch mal nicht überspitzt darstellen.
Die 8er sind natürlich auch eine andere Preisklasse und den Zweck erfüllt das RSSI ja auch - wenngleich auch grob.
Bei der Empfangsqualität kann ich allerdings zustimmen. Mein einfacher Jamara Compa 6x steht da in Nichts nach. ABER: Die Failsafe- und Mixqualitäten des ACT sind sehr gut gelöst. Insbesondere die Servostretchlösung durch aufmischen des eigenen Signals.
Das Ganze wird allerdings wieder durch die chaotische Hompage und undurchsichtige Dokumentation getrübt.
...
Den separaten Receiverakku hatte ich natürlich längst getestet. Mit getrennter 5V Leitung und einem Pfund Ferroringe -> Nada.
Natürlich nur gute Ware verbaut. Hacker,Jeti,Saehan,Act.
Entweder kommt der Müll über die Masseleitung, oder durch immense Magnetfelder. Wie auch immer - ruhe er in Frieden ...
Danke für die Wünsche zum neuen Job. Der erste Tag war schonmal aufregend :wow:
Cheers
Moscito
Karsten J.
14.11.2010, 19:11
Hallo
Hat sich hier mittlerweile noch was getan ?
Gibt es mittlerweile eine einfache Lösung, ein RSSI Signal aus dem ACT DSQ8 für das OSD rauszubekommen ?
Falls nicht, gibt es doch die Möglichkeit, ein Servo anzusteuern und am Poti vom Servo das analoge Spannungssignal abzugreifen, oder ?
Welche Kabel muss ich dort anzapfen ? (Ich nenne es jetzt einfach mal das linke, das mittlere oder das rechte Kabel :-))
Gruß Karsten
Powered by vBulletin® Version 4.1.10 Copyright ©2013 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.