Menü aufrufen
Toggle preferences menu
Persönliches Menü aufrufen
Nicht angemeldet
Ihre IP-Adresse wird öffentlich sichtbar sein, wenn Sie Änderungen vornehmen.

Ab Revisionsphase im Sommer/Herbst 2009 hgz, and, uku

  • Diese Seite gilt zukünftig als Logbuch anstelle der Papierform


August 09 September 09 Oktober 09 November 09 Dezember 09 Januar 10 Februar 10 März 10 April 10


Mai 10

02.05.2010

Berücksichtigung der Referenzwerte bei Darstellung im Programm RTData. Die beim Datenimport auszuwählenden Spalten sind wie folgt:

Date/Time - Spalte 1

RA - Spalte 6

Dec - Spalte 7

Werte - Spalte 3

Ref Switch Status - Spalte 9


Die Spalte Date/Time muß zur Berücksichtigung der Referenzwerte angegeben werden. Zusätzlich ist jetzt auch zeitlich geordnete Darstellung der Werte (Values vs. Date/Time) möglich. Allerdings wird die x-Achse z.Zt. noch nicht im Zeitformat sondern in einfacher aufsteigender Reihenfolge skaliert.

03.05.2010

Beobachtung bei Scan des Himmels: im Süden gibt es offenbar eine Stelle erhöhter Intensität (Az=160..170°, Alt=74..78°), die stationär zu sein scheint (wandert nicht mit den Sternen mit). Intensität geht dabei bis nahe Umgebungstemperatur, d.h. erreicht in etwa den Wert der Referenz. Das müßte mit einem Scan über (Az,Alt) genauer überprüft werden. Ich sehe im Moment 3 Erklärungen:

1) GPS-Satellit oder ähnliche geostationäre, künstliche Quelle

2) Seiteneinstrahlung von horizontnahen Sendern ins Feed oder Leck in den Leitungen/Gehäuse der VV-Kette, so dass horizontnahe Sender direkt (ohne Reflexionen an der Schüssel) in die VV-Kette gelangen können.

3) unsicherer Kontakt der Feedspeisung, mit Kontaktschwierigkeiten v.a. bei bestimmten Neigungen der Schüssel (in diesem Fall bei hohen Elevationen), einen Fehlkontakt an darauffolgenden Gliedern der VV-Kette kann man ausschliessen, da die Referenz stets einen stabilen Wert liefert.


ab 16. Mai 2010

Betriebsunterbrechung nach Störung an Steuerung/Controler; Ursachenermittlung im Gange.

23./24. Mai 2010

Controllerfunktionalität wieder hergestellt, Veränderungen zu vorhergehendem Controller:

  • alle aus der Steuerbox herausführenden Verbindungen mit Surpressordioden (Durchbruchspannung 15V) abgesichert. Zusätzlich sind Serienwiderstände (10 Ohm) in beide RS485-Signale sowohl auf Controller als auch auf Converterseite integriert.
  • Bootloader nicht lauffähig. Firmware darum per ISP ohne Möglichkeit eines Firmwareupdates über serielles Interface aufgespielt. Der Erase-Cycle-Counter konnte aus diesem Grund nur per "avrdude" geschrieben werden, was eine fehlerhafte Anzeige der Schreibzyklen zur Folge hat, da sich das Format des Zählers im EEPROM seit der letzten Revision von "avrdude" geändert hat.
  • 120 Ohm Terminierungswiderstände in RS485 Adernpaar sowohl auf Konverter- als auch auf Controllerseite eingefügt. Die Signalform auf dem Bus ist im Ruhezustand akzeptabel
    Oszillogramm 1
    (s. Oszillogramm 1). Bei Aktivierung der Azimutbewegung bricht Kommunikation zusammen und ein durch die PWM (3.9kHz, 256us Pulsdauer) der Motorsteuerung moduliertes starkes Signal dominiert
    Oszillogramm 2
    (s. Oszillogramm 2). Nach Optimierung der Kabelführung in Steuerbox Bestätigung der These, dass es sich um induzierte Störungen vom Leistungsteil auf den Bus handelt. Provisorische Abschirmung des verdrillten RS485-Adernpaars verbesserte die Signalqualität erheblich
    Oszillogramm 3
    (s. Oszillogramm 3).

ToDo

  • Einbau einer Common-Mode-Drossel in RS485-Busleitungen, um Gleichtakteinstreuungen (wie z.b. Induktion von Motorsteuerung) zu unterdrücken. siehe EMI und deren Vermeidung, Vortrag von P. Wright (Seiten 30-35). Es dürfte ein Ferritring genügen, der auf die verdrillten RS485-Leitungen im Controller sowie im Konverter geschoben wird oder das Kabel mehrfach durch den Ferrit gemäß Seite 32 in obiger Referenz gewickelt ist.
  • Einbau einer kleinen Kapazität (<100pF) zwischen die RS485-Signalleitungen direkt vor dem RS485-Treiberchip (im Konverter sowie in Steuerbox)
  • Einbau jeweils einer kleinen Kapazität (ca. 100pF) in je eine RS485-Busleitung auf der Treiberabgewandten Seite der Common-Mode-Drossel. Dadurch sollte sich die reflektierte Welle von Störungen unterdrücken lassen.

Insgesamt ergibt sich also folgende Reihenfolge von Komponenten auf dem RS485-Bus an beiden Enden und vom Treiberchip aus gesehen (Benennung der differentiellen Busleitungen: A,B) :

  1. kleine Kapazität von 47pF zwischen A und B
  2. Serienwiderstände von 10 Ohm in A und B
  3. Common-Mode-Drossel in A und B (magnetisch gekoppelt)
  4. Kondensator von A gg. Gehäusemasse und B gg. Gehäusemasse (100pF)
  5. Surpressordioden von jeweils A und B gg. Gehäusemasse

24. Mai 2010

Fragezeichen. Wackler an Netzverbindung an Buchse Radioid.

kein Signal von Azimut-Poti. ADC-Wert steht auf Anschlag. Verdacht auf Kabelbruch, da am Abend der Nord-Punkt von beiden Seiten angefahren wurde (hgz)

25. Mai 2010

Lötverbindung von Az-Poti auf Steuerungs-PCB war gelöst. Problem durch Anlöten behoben. Antriebsrolle Elevation aufgerauht gegen Durchrutschen.

ca. 17:00: erneuter Ausfall Az-Poti. Problem ist demnach wohl ein unzuverlässiger Kontakt auf der PCB.

26. Mai 2010

Nach eingehender Untersuchung des Kabel- und Leiterbahnverlaufs des Az-Poti-Anschlusses im RT-Steuergerät und auf der Steuerungsplatine wurde eine ungenügend klemmender und leicht aus der Steckerfassung herausgerutschter Steckerkontakt (5V-Versorgung des Poti) gefunden und repariert. Anschließender Testlauf des RT bis in beide azimutale Endlagen ohne Beanstandungen durchgeführt. Hinweis: nach jedem Eingriff in den Kabelverlauf im RT-Fuß ist eine Fahrt in beide Az-Endlagen nötig um korrekte Kabellage zu prüfen!