2x GELÖST: ACT DSL-8 RSSI an EZOSD
- Themenstarter moscito
- Beginndatum
- Status
GELÖST: ACT DSL-8 RSSI an EZOSD?
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
Nur drei Bauteile werden benötigt
So sieht es zusammengefriemelt aus
Andere Seite
Und fertig
Jetzt noch der Bascom Sourcecode
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
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
Nur drei Bauteile werden benötigt
So sieht es zusammengefriemelt aus
Andere Seite
Und fertig
Jetzt noch der Bascom Sourcecode
Code:
$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
'------------------------------------------------------------------------
EndDie 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
RE: GELÖST: ACT DSL-8 RSSI an EZOSD
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
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
RE: GELÖST: ACT DSL-8 RSSI an EZOSD
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
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
RE: GELÖST: ACT DSL-8 RSSI an EZOSD
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
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
RE: GELÖST: ACT DSL-8 RSSI an EZOSD
@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
@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
RE: GELÖST: ACT DSL-8 RSSI an EZOSD
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.
Wenn jemand Interesse hat werde ich die Daten mal aufbereiten und posten ...
Moscito
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.
Wenn jemand Interesse hat werde ich die Daten mal aufbereiten und posten ...
Moscito
RE: GELÖST: ACT DSL-8 RSSI an EZOSD
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.
N'joy
Moscito
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.
Code:
' #####################################################################################
' # -----------------------------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 SubN'joy
Moscito
RE: GELÖST: ACT DSL-8 RSSI an EZOSD
wow!
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
im wahrsten sinn des wortes - "analog" dazu: @ carlson: also ja, bei 200k eingangsimpedanz... pfhe!
eine beispielbestückung wäre zb R= 3k3 und C= 100nF
nach f[size=xx-small]0[/size]=1 / 2pi * R * C
also f[size=xx-small]0[/size]=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.
wow!
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
im wahrsten sinn des wortes - "analog" dazu: @ carlson: also ja, bei 200k eingangsimpedanz... pfhe!
eine beispielbestückung wäre zb R= 3k3 und C= 100nF
nach f[size=xx-small]0[/size]=1 / 2pi * R * C
also f[size=xx-small]0[/size]=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
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.
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...
Grüße,
Georg
PS: Okke - vielen Dank für Deine Hilfe und die Mühe mit den Kondensatoren!
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.
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...
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
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
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.:
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) 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
Klasse Leistung dein RSSI->Analog-Wandler. Im gegensatz zur ersten Lösung umweiten besser, und damit mein ich nicht nur den Kommentar.
: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) 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
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
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
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
- Status
