RadioWiki - Benutzerbeiträge [de]

Aktuelle Ereignisse

2011-10-18T18:43:08Z

Kdsachse:

'''''Ab Revisionsphase im Sommer/Herbst 2009''''' hgz, and, uku, kds
*Diese Seite gilt zukünftig als Logbuch anstelle der Papierform

{| border="1"
|'''2009'''
|colspan=7 |
|[[ August 09|8 ]]
|[[ September 09|9 ]]
|[[ Oktober 09|10 ]]
|[[November 09|11 ]]
|[[Dezember 09|12]]
|'''2010'''
|[[Januar 10|1]]
|[[Februar 10|2]]
|[[März 10|3]]
|[[April 10|4]]
|[[Mai 10|5]]
|[[Juni 10|6]]
|[[Juli 10|7]]
|[[August 10|8]]
|[[September 10|9]]
|[[Oktober 10|10]]
|[[November 10|11]]
|[[Dezember 10|12]]
|'''2011'''
|[[Januar 11|1]]
|[[Februar 11|2]]
|[[März 11|3]]
|[[April 11|4]]
|Mai 11|5
|[[Juni 11|6]]
|[[Juli 11|7]]
|[[August 11|8]]
|[[September 11|9]]
|Oktober 11|10
|November 11|11
|Dezember 11|12
|}

'''Oktober 11'''
Zustand des RT ist undefiniert rt_ref ist nicht anwendbar<br>
@Andreas kannst Du etwas dazu sagen ?

Benutzer Diskussion:Kdsachse

2011-10-18T18:21:35Z

Kdsachse: Drehgeber

'''Hallo Kollegen'''

Am 15.10.2011 eröffnete mir Andreas, das die Drehgeber wohl kein langes Leben mehr haben werden.

Aus diesem Grunde zitiere ich hier mal aus einer eMail von Dr. Michael Heber:

======================================================================================================================================================================
www.siko.de
Winkelkodierer WV36M/SSI
Winkelkodierer WV36M/CAN
Magnetisch absoluter Multiturn Drehgeber WV36M/SSI - batterielos, mit SSI Schnittstelle. Der WV36M/SSI ist dank doppelter Kugellager, kleiner Bauform und verschleißfreiem magnetischen Messprinzip auch für Positionieraufgaben in mechanisch anspruchvollen Umgebungen bestens geeignet.

Merkmale
■kompakte Bauform (36.5 mm Durchmesser)
■Schnittstelle SSI
■Schutzart IP64
■Multiturn ohne Batterie
■Doppelte Kugellager
■13 bit Multiturn (8192 Umdrehungen)
■12 bit Singleturn (4096 Schritte)

Absolutgeber AV58M
Der Drehgeber AV58M mit "Teach-in-Funktion" ist ein magnetischer Absolutwertgeber mit analogem Ausgang. Der Drehgeber kann über zwei an der Rückseite befindlichen Taster sowie über zwei externe Eingänge, vom Benutzer selbst, auf den gewünschten Messbereich eingestellt werden. Das Gerät verfügt über eine batterielose Multiturntechnologie.
Merkmale
■Absoluter Analoggeber
■Auflösung 4096
■bis -40°C Arbeitstemperatur
■Spannungs- (0-10V) oder Stromausgang (4-20mA)
■programmierbarer Messbereich über teach-in Funktion mit Tastenfunktion oder externe Eingänge

http://www.rls.si/default.asp?prod=encoders&lang=german&gclid=CIizkZ3H5aoCFRk03wodd3Jk9w

http://www.baumer.com/motion/absolute-drehgeber.html?gclid=CI-Ih5vH5aoCFRsu3wody2Lcbw

http://www.baumer.com/sensor/magnetische-sensoren/magnetische-winkel-messende-sensoren.html

======================================================================================================================================================================

Grüße

KDS

Aktuelle Ereignisse

2011-04-06T21:13:23Z

Kdsachse: /* Sprünge an Geber Azimut 6. April */

'''''Ab Revisionsphase im Sommer/Herbst 2009''''' hgz, and, uku
*Diese Seite gilt zukünftig als Logbuch anstelle der Papierform

{| border="1"
|'''2009'''
|colspan=7 |
|[[ August 09|8 ]]
|[[ September 09|9 ]]
|[[ Oktober 09|10 ]]
|[[November 09|11 ]]
|[[Dezember 09|12]]
|'''2010'''
|[[Januar 10|1]]
|[[Februar 10|2]]
|[[März 10|3]]
|[[April 10|4]]
|[[Mai 10|5]]
|[[Juni 10|6]]
|[[Juli 10|7]]
|[[August 10|8]]
|[[September 10|9]]
|[[Oktober 10|10]]
|[[November 10|11]]
|[[Dezember 10|12]]
|'''2011'''
|[[Januar 11|1]]
|[[Februar 11|2]]
|[[März 11|3]]
|April 11|4
|Mai 11|5
|Juni 11|6
|Juli 11|7
|August 11|8
|September 11|9
|Oktober 11|10
|November 11|11
|Dezember 11|12
|}

'''April 11'''

==3./4.April==

* Andreas hat den VV wieder mit den korrekten Spulen versehen und in funktionsfähigen Zustand gebracht. Feed sollte jetzt wieder voll einsatzfähig sein.
* Die Referenzumschaltung wird ab jetzt von einem FTDI-USB-Controller erledigt. Die Software (Datataker) wurde entsprechend angepasst und ins svn-repo eingecheckt. Damit alle Benutzer Zugriffsrechte für das USB-Device haben, wurde eine entsprechende udev-rule definiert (siehe Dokumentation im Sourcecode in radio/daq/atmel/datataker.cpp).
* Firmware für den ADC z.Zt. geflasht mit der aktuellen Version aus dem Repo. Diese benutzt einen schnelleren Moving-Average-Algorithmus, arbeitet jedoch bislang noch fehlerhaft (Stufen in den Messdaten in Vielfachen von 16 counts). Messungen sollten jedoch dessen ungeachtet bis zur Korrektur der Firmware trotzdem gemacht werden.
* Andreas hat die Kontakte des El-Motors gereinigt und festgezogen. Seither sind keine Aussetzer beim Fahren in El mehr beobachtet worden.
* Messungen mit aktueller Konfiguration hocherwünscht (Sonne, Horizont und Radioquellen)!

Nachtrag: erneute massive Verbindungsabbrüche beim Fahren in El beobachtet. V.a. beim Parken ist der Kontrollverlust reproduzierbar. Das dann in allen Achsen unkontrolliert fahrende RT konnte nur durch Notabschaltung des Radioiden gestoppt werden. Dadurch ist das RT momentan in der Endlage blockiert und muß manuell aus dieser bewegt werden. (hgz) -Nachtrag zum Nachtrag: Nach Start Radioid aus Endlage Nord remote gefahren --[[Benutzer:Ulli|Ulli]] 07:54, 4. Apr. 2011 (UTC)

== Sonnentransit 6. April ==

<gallery>
Bild:Sun transit06042010.png|Transit mit Seitenkeulen, Hub nach Umbau deutlich verbessert
Bild:Sum transit06042010.png|Zur Wiederholgenauigkeit einer Messung am gleichen Tag, Referenzposition angepasst
</gallery>

== Sprünge an Geber Azimut 6. April ==

Beim Fahren im Bereich um 180° Az (nicht aber an dieser Grenze) springt der Geber nicht nachvollziehbar auf Nullposition. Fahrversuche eingestellt. Neustart Radioid nicht hilfreich.

Ergänzung von KDS:

der Bewegungszustand des RT (Videostream) und die Ausgabe von rt_ref vermitteln den Eindruck, '''das RT sei vom radioid getrennt'''. Habe Andreas via skype gebeten, dies zu prüfen.

Aktuelle Ereignisse

2011-03-29T10:04:44Z

Kdsachse: /* März 23 */

'''''Ab Revisionsphase im Sommer/Herbst 2009''''' hgz, and, uku
*Diese Seite gilt zukünftig als Logbuch anstelle der Papierform

{| border="1"
|'''2009'''
|colspan=7 |
|[[ August 09|8 ]]
|[[ September 09|9 ]]
|[[ Oktober 09|10 ]]
|[[November 09|11 ]]
|[[Dezember 09|12]]
|'''2010'''
|[[Januar 10|1]]
|[[Februar 10|2]]
|[[März 10|3]]
|[[April 10|4]]
|[[Mai 10|5]]
|[[Juni 10|6]]
|[[Juli 10|7]]
|[[August 10|8]]
|[[September 10|9]]
|[[Oktober 10|10]]
|[[November 10|11]]
|[[Dezember 10|12]]
|'''2011'''
|[[Januar 11|1]]
|[[Februar 11|2]]
|[[März 11|3]]
|April 11|4
|Mai 11|5
|Juni 11|6
|Juli 11|7
|August 11|8
|September 11|9
|Oktober 11|10
|November 11|11
|Dezember 11|12
|}

== März 11 ==

'''14. März''' Verkabelungsarbeiten am Radioteleskop. LX200 daher von ratsche -d nicht sichtbar. (KDS 14.3.2011 12:02) Bitte Ulli , Andreas und Hans-Georg, wenn Ihr fertig seid, dann tragt das hier ein. Grüße KDS

== März 23 ==

Beim Versuch endlich mal das nach den Kabelverlegearbeiten nötigen Az-Endlagencheck (das RT in beide Az-Endlagen fahren und kontrollieren, ob die Kabel im RT-Fuss irgendwo klemmen) sind mir vor Ort einige Dinge übel aufgestossen.
1. Beim Frühjahrsputz im Vereinsraum hat jemand den Radioiden mitsamt Computertisch so kräftig gegen den Kabelkanal an der Wand geschoben, dass mindestens das DVI-Monitorkabel jetzt zerknickt ist und eventuell die Grafikkarte auch Schaden genommen hat. Zumindest kommt nur noch Flimmermüll auf dem Monitor. Wenn der lokale Radioidarbeitsplatz wieder benutzt werden soll, muss ein neues DVI-Kabel besorgt werden. Kostenpunkt ca. 10€

2. Werden immer mehr Netzkabel und Verteilerkabel an die Steckdose des Radioden gesteckt. Irgendwann wirds mindestens unübersichtlich, wenn nicht gar elektrisch bedenklich. Bitte immer drauf achten und fremdes Gerassel (zBsp Canon-Akkuladegeräte und Telefonstromversorgung) einfach abziehen.

3. Irgendwelche Kids haben einige Hände voll Sand/Split in die RT-Schüssel geworfen, wer Lust hat kann ja mal die Webcamaufzeichnungen durchgehen...

Beim Verlegen des neuen Feed-Spannungsversorgungskabel in den Kabelkanal ist leider das RS485-Kabel etwas zurück in den Kanal gerutscht und lässt sich nicht mehr auf die ursprüngliche Länge herausziehen. Ich habe es nun provisorisch angestoppelt, so kann das RT wieder bis in beide Az-Endlagen ohne Kabelabriss fahren. Im Feed ist momentan keine Empfangstechnik eingebaut, da noch Lötarbeiten für die neue Spannungsversorgung nötig sind.

Und ich habe mal das Prellen des Anemometers aufgenommen: [[file:Prellen1.bmp|100px]]

== März 25 ==

Ergänzug von KDS: Am 25.3.2011 habe ich festgestellt, dass der radioid nicht per Netzwerk erreichbar ist. Eine Überprüfung am 26.3.2011 durch Markus ergab, daß möglicherweise das Mainboard des radioid tot ist. Auffällig sind hier nahezu gleichzeitige Ausfälle anderer Sensoren die in der Nacht am 24/25.3.2011 auftraten. Markus hat dankenswerterweise ein neues MB herausgegeben (Anbau, Tisch des radioid). Ich selbst möchte den Austausch des MB nicht vornehmen, da mir hierfür die notwendige Routine verlorengegangen ist , dies mit vetretbarem Aufwand zu erledigen. Daher meine Bitte an Andreas, dies zu prüfen und ggf. das MB zu tauschen. Danke schon voraus an Andreas

KDS

März 11

2011-03-15T11:25:41Z

Kdsachse:

== März 11 ==

'''14. März''' Verkabelungsarbeiten am Radioteleskop. LX200 daher von ratsched nicht sichtbar. (KDS 14.3.2011 12:02)
Bitte Ulli , Andreas und Hans-Georg, wenn Ihr fertig seid, dann tragt das hier ein. Grüße KDS

März 11

2011-03-15T11:08:04Z

Kdsachse:

== März 11 ==

'''14. März''' Verkabelungsarbeiten am Radioteleskop. LX200 daher von ratsched nicht sichtbar. (KDS 14.3.2011 12:02)

Aktuelle Ereignisse

2011-03-15T11:07:33Z

Kdsachse:

Neue seite erzwingen

2011-03-15T11:04:00Z

Kdsachse: hat „Neue seite erzwingen“ nach „März 11“ verschoben

#WEITERLEITUNG [[März 11]]

März 11

2011-03-15T11:04:00Z

Kdsachse: hat „Neue seite erzwingen“ nach „März 11“ verschoben

== März 11 ==

'''14. März''' Verkabelungsarbeiten am Radioteleskop. LX200 daher vopn ratsched nicht sichtbar. (KDS 14.3.2011 12:02)

März 11

2011-03-15T11:02:21Z

Kdsachse: Die Seite wurde neu angelegt: „== März 11 == '''14. März''' Verkabelungsarbeiten am Radioteleskop. LX200 daher vopn ratsched nicht sichtbar. (KDS 14.3.2011 12:02)“

== März 11 ==

'''14. März''' Verkabelungsarbeiten am Radioteleskop. LX200 daher vopn ratsched nicht sichtbar. (KDS 14.3.2011 12:02)

Anleitungen/Tutorials

2011-03-02T19:40:03Z

Kdsachse: /* Server-Prozess */

= Benutzung der Datenaquisitions-Tools =

Beispiel für Aufruf datataker:
bin/datataker /dev/ttyS5

Obige Zeile verbindet sich mit dem ADC und gibt die Daten mit Timestamp auf ''stdout'' aus.

Um den Zusammenhang zwischen gemessenen Intensitäten und Koordinaten auszugeben ist

macros/acquire

aufzurufen. Dieses Script gibt in dieser Reihenfolge folgende Werte auf ''stdout'' aus:
timestamp ADC-Wert Azimut Höhe Stunde Deklination Controllertemperatur

macros/acquire_ref

erweitert die Ausgabe von macros/acquire um eine weitere Spalte

per default wird hier 19 mal der feed gemessen und danach 1 mal den Referenzkanal
Es gibt hier noch 3 wichtige (Stellungs)Parameter
*1. Averaging Anzahl default:100
*2. Verhältnis Signalwerte Referenzwerte default :20 heisst 19 Signal 1 Referenz
*3. Gesamtzahl der auszugebenden Werte default :-1 (endlos)

= Steuerung von Messungen =

== Steuerung über bash-Skripte ==

Das ist die flexibelste Art, Messungen auszuführen. Für die verschiedenen Aufgaben stehen im repo-tree im Unterverzeichnis [https://rm-radeberg.dyndns.org/trac/browser/trunk/macros macros/] (zusätzlich zu den reinen DAQ-Skripten, s.o.) folgende Steuerskripte zur Verfügung:

'''rt_scan_hor''' ... Messung in äquidistantem Grid in Horizontalkoordinaten (mind. 5 Parameter benötigt, s. Usage-Hilfe bei Aufruf ohne Parameter)

'''rt_scan_equ''' ... Messung in äquidistantem Grid in Äquatorialkoordinaten (mind. 5 Parameter benötigt, s. Usage-Hilfe bei Aufruf ohne Parameter)

== Steuerung über Task Scheduler "RATSCHE" ==

Das sollte ab Januar 2011 die verbindliche (einzige) Möglichkeit von Messungen sein, da hier Kollisionen ausgeschlossen sind.

=== Server-Prozess ===

Auf dem Radioiden muß eine Instanz von '''ratsche''' im Servermodus laufen, der Daemon-Prozess ist folgendermassen zu starten:
ratsche -d -x /home/hgz/svnlocal/hgz/macros
'''(Im Moment ist offenbar das hier angegebene Verzeichnis sowie der aktuell laufende Serverprozess defekt !)'''

Das Argument zum Parameter -x ist der Ort der ausführbaren Makros, wie z.b. '''rt_scan_equ''', es muß also nicht unbedingt genau obige Zeile sein, wichtig ist nur das Macro-Verzeichnis irgendeiner lokalen Kopie des SVN-Repos (im obigen Fall meine lokale Arbeitskopie) anzugeben.

In Zukunft (irgendwann Jan-März) werde ich ein Start-Skript für den Radioiden schreiben, das automatisch den ratsche-daemon startet, dann haben wir eine Sorge weniger. Bis dahin bitte nach Neustart Radioid obige Zeile einmalig ausführen (wenn der Daemon bereits läuft wird jedoch keine zweite Instanz gestartet, der Aufruf gibt dann eine entsprechende Info-Meldung aus).

Eine Bemerkung von KDS: Bitte überprüft mit:
ps ax | grep -i ratsche
ob eine ratsche -d läuft und startet ggf. o.a. Kommandozeile den ratsche Server.

Im Moment baut Andreas dieses Kommando in init.d ein

Der Serverprozess schreibt mehr oder weniger detaillierte Ausgaben (je nach beim Start angegebenen Verbosity-Level) in das System-Logfile. Diese können von allen Benutzern mit folgendem Befehl begutachtet werden:
tail -f -n 1000 /var/log/messages | grep ratsche
Der Output sieht dann beispielsweise so aus:
Jan 23 11:39:09 Radioid ratsche[18528]: starting RT task scheduler server
Jan 23 11:39:09 Radioid ratsche[18528]: using message queue 0x0000000a
Jan 23 11:39:09 Radioid ratsche[18528]: using executable path /home/hgz/svnlocal/hgz/macros/
Jan 23 11:39:09 Radioid ratsche[18528]: found 1 zombie message(s) in queue...deleting
Jan 23 11:50:00 Radioid ratsche[18528]: starting EquScan task with id=0 (pid 20342)

=== Benutzung von '''RATSCHE''' ===

Zum Zugriff auf den Taskmanager gibt es das systemweit bekannte tool '''ratsche''' (Option -h für Kommandozeilen-Hilfe und Auflistung aller verfügbarer Optionen). Hier nur eine kurze Beschreibung der wichtigsten Optionen:

ratsche -l

listet alle definierten Tasks auf. Die Bedeutung der einzelnen Werte ist aus dem ebenfalls ausgegebenen Header ersichtlich.

ratsche -a <tasklist>

fügt die in der datei <tasklist> definierten Tasks hinzu. Eine Beispieldatei ist zu finden im SVN-Repo in [https://rm-radeberg.dyndns.org/trac/browser/trunk/macros/dummy_task macros/dummy_task]. Am besten man legt sich eine lokale Kopie dieser Datei an, so dass es bei Veränderung dieser nicht zu SVN-Konflikten kommt, z.B. mit
cp dummy_task tasklist
Die Datei '''tasklist''' ist dann beliebig editierbar. für alle möglichen Task-Typen ist mind. ein Beispiel angegeben. Wenn der Task von '''ratsche''' übernommen werden soll, muß natürlich die entsprechende Zeile auskommentiert sein, i.e. das führende "#" zu entfernen. Das genaue Spaltenformat ist in der Beispieldatei erläutert.

'''Hinweis:''' Momentan werden die Werte von Priority und Alt-Period noch nicht berücksichtigt. Wird in Zukunft noch implementiert (ist auf meiner ToDo-Liste irgendwo mittendrin ;)

----

= Benutzung des Subversion (SVN) Repositories =

seit Anfang März 2010 lagert das Software-Repository auf Roberts Server. Eine Übersicht über die Struktur des Repositorys ist erreichbar über
file:///.../svnlocal/hgzlib/html/index.html in einem Browser, aber nur wenn man vorher die doxygen-Dokumentation mittels ''doxygen'' in diesem Verzeichnis erstellt hat.
Der Code kann auch durch ein [http://trac.edgewall.org/ Trac]-Webinterface angeschaut werden:

[https://rm-radeberg.dyndns.org/trac/browser/trunk https://rm-radeberg.dyndns.org/trac/browser/trunk]

(login und pw sind identisch mit dem Wiki-account)

Zum Auschecken der Repos in eine lokale Arbeitskopie kann entweder obige url benutzt werden, oder aber folgende Quelle, die auch Änderungen im Repository zuläßt (der https-Kanal ist read only, bzw. sollte es sein):

svn co svn+ssh://svn@rm-radeberg.dyndns.org/var/svn/hgz/trunk ~/svnlocal

Passwort ist bei [[Benutzer:Hgz|Hgz]] oder [[Benutzer:penner|Penner]] zu erfragen. Zusätzlich kann man sich noch durch Schlüsselaustausch und einem ssh-Agenten das lästige Eintippen des Passworts sparen (siehe unten).

Existiert bereits eine lokale Arbeitskopie (vom vorhergehenden Repository) ist es möglich, diesem die neue Adresse durch folgenden Befehl (im Hauptpfad der lok. Kopie, z.b. svnlocal/) mitzuteilen:

svn switch --relocate svn+ssh://svnuser@141.30.85.175/home/hgz/svnrep/trunk svn+ssh://svn@rm-radeberg.dyndns.org/var/svn/hgz/trunk

der commit-befähigte user heißt also jetzt svn (pw wie schon erwähnt erfragen). Das soll sich mittelfristig ändern, nämlich dann wenn das Repo endgültig auf dem Perseiden beheimatet wird. Dann wird jeder, der etwas in das Repo einchecken möchte einen Account haben, so dass der Urheber eines Commits auch automatisch im Log erkennbar ist. Andererseits wird nicht jeder auf Perseid registrierte User Schreibzugriff auf das SVN-Repo besitzen. Eine Registrierung (in Form einer mündlichen Absichtserklärung) ist vorzugsweise bei penner und Rücksprache mit [[Benutzer:Hgz|Hgz]] vorzunehmen.

=== Zugriff auf das svn-Repository durch ssh-Schlüssel ===

einen passwortlosen Zugriff auf das svn-Repository kann man durch Austausch eines vertraulichen Schlüssels erreichen. Dieser kann von [[Benutzer:Hgz|Hgz]] bezogen werden. Zum Aktivieren des Schlüssels (nehmen wir an, er heißt ''svnkey'') sollte man ihn zuerst an einem geeigneten Ort, wie z.B. $(HOME)/.ssh deponieren. Danach kann er dem ssh-Agenten bekannt gemacht werden mit:
ssh-add ~/.ssh/svnkey
Zum Kontrollieren, ob der Schlüssel geladen wurde, oder um sich die Liste bereits geladener Schlüssel anzusehen ist folgender Befehl nützlich:
ssh-add -l

Das bisher beschriebene Verfahren muß jedesmal wiederholt werden, wenn eine neue Konsole gestartet wird. Um den Schlüssel permanent in einer interaktiven Shell (das ist diejenige, die an dem Rechner gestartet wird, an dem man auch sitzt) bekannt zu machen, genügt es, obige Zeile in seine .bashrc (d.h. im eigenen Home-Verzeichnis) anzufügen, also

...
ssh-add ~/.ssh/svnkey

dann sollte an einem Rechner, auf dem eine grafische Benutzeroberfläche läuft, keine Passwortabfrage mehr beim Zugriff auf das svn-Repo erscheinen.

Anders verhält sich das bei entferntem Zugriff auf einen Rechner, z.b. über ssh-login. Dort wird standardmäßig eine Login-Shell gestartet (vgl. interaktive Shell, s.o.), die üblicherweise keine Instanz eines ssh-Agenten initiiert.

Hier gibt es zwei Möglichkeiten:

1.Möglichkeit (empfohlen): man installiert das paket keychain (sofern in den Distributionsquellen vorhanden) und überläßt diesem Programm dann das Starten des ssh-Agenten und Laden des Schlüssels. Dazu muß, analog zu obiger Vorgehensweise, in .profile oder in .bashrc in seinem Home-Verzeichnis (im Prinzip ist es egal, in welcher) nur der Aufruf von keychain mit dem Schlüssel als Argument erfolgen.

2.Möglichkeit: man fügt folgende Zeilen an seine .profile an:

# start up ssh-agent
SSH_ENV="$HOME/.ssh/environment"
function start_agent {
echo "Initialising new SSH agent..."
/usr/bin/ssh-agent | sed 's/^echo/#echo/' > "${SSH_ENV}"
echo succeeded
chmod 600 "${SSH_ENV}"
. "${SSH_ENV}" > /dev/null
/usr/bin/ssh-add ~/.ssh/svnkey;
}
# Source SSH settings, if applicable
if [ -f "${SSH_ENV}" ]; then
. "${SSH_ENV}" > /dev/null
#ps ${SSH_AGENT_PID} doesn't work under cywgin
ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent$ > /dev/null || {
start_agent;
}
else
start_agent;
fi

Zu beachten ist hier, dass der Schlüssel, welcher geladen werden soll, hier mit angegeben ist (9. Zeile). Der Name muß entsprechend dem tatsächlichen Namen des Schlüssels angepaßt werden.
In jeder zukünftig geöffneten Shell wird nun automatisch der Schlüssel geladen, so dass eine Passwortabfrage bei Zugriff auf svn umgangen (im positiven und auch sicheren Sinn) wird.
Um die Änderungen auch in der aktiven Shell anzuwenden, kann man außerdem noch den Inhalt der veränderten .profile erneut ausführen lassen mit:
source ~/.profile

= Remote-Mounten der Datenpartition durch sshfs =

Zum Mounten von Ordnern fremder Rechner auf dem lokalen Computer über ssh ist das tool sshfs ganz hilfreich. Es setzt auf dem FUSE-Dateisystem-Konzept auf, der Benutzer muß daher Mitglied der Gruppe "fuse" auf dem lokalen Rechner sein.

Als erstes sollte man sicherstellen, dass sshfs installiert ist, und es ggf. über den Paketmanager installieren, z.b.
sudo zypper install sshfs
Danach noch (z.b. über YaST->Benutzer und Gruppen) den eigenen Benutzer zur Gruppe ''fuse'' hinzufügen.

nun kann man ein Verzeichnis anlegen, in das das Filesystem des entfernten Rechners hingemountet wird:
mkdir sshfs/radioid

das mounten geschieht über:
sshfs radioid:/daten ~/sshfs/radioid/

dann sollte der Ordner /daten des radioiden in dem Verzeichnis sshfs/radioid gemountet sein. Der Hostname (in diesem fall radioid:/) muß natürlich dem System bekannt sein. Am besten man benutzt den Alias wie auch beim ssh-Login. Dann muß man auch kein PW eingeben.

Noch ein Tip: Ich habe das Mounten von nicht-lokalen Verzeichnissen komfortabel in ''gkrellm'' integriert. Dazu muß man einfach bei ''Configuration->File System'' ein neues primäres FS hinzufügen (s. Screenshot).

<gallery>
Bild:Gkrellm sshfs mount.png|Konfiguration sshfs-mount in gkrellm
Bild:Gkrellm sshfs mount2.png|Einbindung des Radioiden über sshfs-mount in gkrellm
</gallery>

Anleitungen/Tutorials

2011-02-16T21:58:28Z

Kdsachse: /* Server-Prozess */

= Benutzung der Datenaquisitions-Tools =

Beispiel für Aufruf datataker:
bin/datataker /dev/ttyS5

Obige Zeile verbindet sich mit dem ADC und gibt die Daten mit Timestamp auf ''stdout'' aus.

Um den Zusammenhang zwischen gemessenen Intensitäten und Koordinaten auszugeben ist

macros/acquire

aufzurufen. Dieses Script gibt in dieser Reihenfolge folgende Werte auf ''stdout'' aus:
timestamp ADC-Wert Azimut Höhe Stunde Deklination Controllertemperatur

macros/acquire_ref

erweitert die Ausgabe von macros/acquire um eine weitere Spalte

per default wird hier 19 mal der feed gemessen und danach 1 mal den Referenzkanal
Es gibt hier noch 3 wichtige (Stellungs)Parameter
*1. Averaging Anzahl default:100
*2. Verhältnis Signalwerte Referenzwerte default :20 heisst 19 Signal 1 Referenz
*3. Gesamtzahl der auszugebenden Werte default :-1 (endlos)

= Steuerung von Messungen =

== Steuerung über bash-Skripte ==

Das ist die flexibelste Art, Messungen auszuführen. Für die verschiedenen Aufgaben stehen im repo-tree im Unterverzeichnis [https://rm-radeberg.dyndns.org/trac/browser/trunk/macros macros/] (zusätzlich zu den reinen DAQ-Skripten, s.o.) folgende Steuerskripte zur Verfügung:

'''rt_scan_hor''' ... Messung in äquidistantem Grid in Horizontalkoordinaten (mind. 5 Parameter benötigt, s. Usage-Hilfe bei Aufruf ohne Parameter)

'''rt_scan_equ''' ... Messung in äquidistantem Grid in Äquatorialkoordinaten (mind. 5 Parameter benötigt, s. Usage-Hilfe bei Aufruf ohne Parameter)

== Steuerung über Task Scheduler "RATSCHE" ==

Das sollte ab Januar 2011 die verbindliche (einzige) Möglichkeit von Messungen sein, da hier Kollisionen ausgeschlossen sind.

=== Server-Prozess ===

Auf dem Radioiden muß eine Instanz von '''ratsche''' im Servermodus laufen, der Daemon-Prozess ist folgendermassen zu starten:
ratsche -d -x /home/hgz/svnlocal/hgz/macros
Das Argument zum Parameter -x ist der Ort der ausführbaren Makros, wie z.b. '''rt_scan_equ''', es muß also nicht unbedingt genau obige Zeile sein, wichtig ist nur das Macro-Verzeichnis irgendeiner lokalen Kopie des SVN-Repos (im obigen Fall meine lokale Arbeitskopie) anzugeben.

In Zukunft (irgendwann Jan-März) werde ich ein Start-Skript für den Radioiden schreiben, das automatisch den ratsche-daemon startet, dann haben wir eine Sorge weniger. Bis dahin bitte nach Neustart Radioid obige Zeile einmalig ausführen (wenn der Daemon bereits läuft wird jedoch keine zweite Instanz gestartet, der Aufruf gibt dann eine entsprechende Info-Meldung aus).

Eine Bemerkung von KDS: Bitte überprüft mit:
ps ax | grep -i ratsche
ob eine ratsche -d läuft und startet ggf. o.a. Kommandozeile den ratsche Server.

Im Moment baut Andreas dieses Kommando in init.d ein

Der Serverprozess schreibt mehr oder weniger detaillierte Ausgaben (je nach beim Start angegebenen Verbosity-Level) in das System-Logfile. Diese können von allen Benutzern mit folgendem Befehl begutachtet werden:
tail -f -n 1000 /var/log/messages | grep ratsche
Der Output sieht dann beispielsweise so aus:
Jan 23 11:39:09 Radioid ratsche[18528]: starting RT task scheduler server
Jan 23 11:39:09 Radioid ratsche[18528]: using message queue 0x0000000a
Jan 23 11:39:09 Radioid ratsche[18528]: using executable path /home/hgz/svnlocal/hgz/macros/
Jan 23 11:39:09 Radioid ratsche[18528]: found 1 zombie message(s) in queue...deleting
Jan 23 11:50:00 Radioid ratsche[18528]: starting EquScan task with id=0 (pid 20342)

=== Benutzung von '''RATSCHE''' ===

Zum Zugriff auf den Taskmanager gibt es das systemweit bekannte tool '''ratsche''' (Option -h für Kommandozeilen-Hilfe und Auflistung aller verfügbarer Optionen). Hier nur eine kurze Beschreibung der wichtigsten Optionen:

ratsche -l

listet alle definierten Tasks auf. Die Bedeutung der einzelnen Werte ist aus dem ebenfalls ausgegebenen Header ersichtlich.

ratsche -a <tasklist>

fügt die in der datei <tasklist> definierten Tasks hinzu. Eine Beispieldatei ist zu finden im SVN-Repo in [https://rm-radeberg.dyndns.org/trac/browser/trunk/macros/dummy_task macros/dummy_task]. Am besten man legt sich eine lokale Kopie dieser Datei an, so dass es bei Veränderung dieser nicht zu SVN-Konflikten kommt, z.B. mit
cp dummy_task tasklist
Die Datei '''tasklist''' ist dann beliebig editierbar. für alle möglichen Task-Typen ist mind. ein Beispiel angegeben. Wenn der Task von '''ratsche''' übernommen werden soll, muß natürlich die entsprechende Zeile auskommentiert sein, i.e. das führende "#" zu entfernen. Das genaue Spaltenformat ist in der Beispieldatei erläutert.

'''Hinweis:''' Momentan werden die Werte von Priority und Alt-Period noch nicht berücksichtigt. Wird in Zukunft noch implementiert (ist auf meiner ToDo-Liste irgendwo mittendrin ;)

----

= Benutzung des Subversion (SVN) Repositories =

seit Anfang März 2010 lagert das Software-Repository auf Roberts Server. Eine Übersicht über die Struktur des Repositorys ist erreichbar über
file:///.../svnlocal/hgzlib/html/index.html in einem Browser, aber nur wenn man vorher die doxygen-Dokumentation mittels ''doxygen'' in diesem Verzeichnis erstellt hat.
Der Code kann auch durch ein [http://trac.edgewall.org/ Trac]-Webinterface angeschaut werden:

[https://rm-radeberg.dyndns.org/trac/browser/trunk https://rm-radeberg.dyndns.org/trac/browser/trunk]

(login und pw sind identisch mit dem Wiki-account)

Zum Auschecken der Repos in eine lokale Arbeitskopie kann entweder obige url benutzt werden, oder aber folgende Quelle, die auch Änderungen im Repository zuläßt (der https-Kanal ist read only, bzw. sollte es sein):

svn co svn+ssh://svn@rm-radeberg.dyndns.org/var/svn/hgz/trunk ~/svnlocal

Passwort ist bei [[Benutzer:Hgz|Hgz]] oder [[Benutzer:penner|Penner]] zu erfragen. Zusätzlich kann man sich noch durch Schlüsselaustausch und einem ssh-Agenten das lästige Eintippen des Passworts sparen (siehe unten).

Existiert bereits eine lokale Arbeitskopie (vom vorhergehenden Repository) ist es möglich, diesem die neue Adresse durch folgenden Befehl (im Hauptpfad der lok. Kopie, z.b. svnlocal/) mitzuteilen:

svn switch --relocate svn+ssh://svnuser@141.30.85.175/home/hgz/svnrep/trunk svn+ssh://svn@rm-radeberg.dyndns.org/var/svn/hgz/trunk

der commit-befähigte user heißt also jetzt svn (pw wie schon erwähnt erfragen). Das soll sich mittelfristig ändern, nämlich dann wenn das Repo endgültig auf dem Perseiden beheimatet wird. Dann wird jeder, der etwas in das Repo einchecken möchte einen Account haben, so dass der Urheber eines Commits auch automatisch im Log erkennbar ist. Andererseits wird nicht jeder auf Perseid registrierte User Schreibzugriff auf das SVN-Repo besitzen. Eine Registrierung (in Form einer mündlichen Absichtserklärung) ist vorzugsweise bei penner und Rücksprache mit [[Benutzer:Hgz|Hgz]] vorzunehmen.

=== Zugriff auf das svn-Repository durch ssh-Schlüssel ===

einen passwortlosen Zugriff auf das svn-Repository kann man durch Austausch eines vertraulichen Schlüssels erreichen. Dieser kann von [[Benutzer:Hgz|Hgz]] bezogen werden. Zum Aktivieren des Schlüssels (nehmen wir an, er heißt ''svnkey'') sollte man ihn zuerst an einem geeigneten Ort, wie z.B. $(HOME)/.ssh deponieren. Danach kann er dem ssh-Agenten bekannt gemacht werden mit:
ssh-add ~/.ssh/svnkey
Zum Kontrollieren, ob der Schlüssel geladen wurde, oder um sich die Liste bereits geladener Schlüssel anzusehen ist folgender Befehl nützlich:
ssh-add -l

Das bisher beschriebene Verfahren muß jedesmal wiederholt werden, wenn eine neue Konsole gestartet wird. Um den Schlüssel permanent in einer interaktiven Shell (das ist diejenige, die an dem Rechner gestartet wird, an dem man auch sitzt) bekannt zu machen, genügt es, obige Zeile in seine .bashrc (d.h. im eigenen Home-Verzeichnis) anzufügen, also

...
ssh-add ~/.ssh/svnkey

dann sollte an einem Rechner, auf dem eine grafische Benutzeroberfläche läuft, keine Passwortabfrage mehr beim Zugriff auf das svn-Repo erscheinen.

Anders verhält sich das bei entferntem Zugriff auf einen Rechner, z.b. über ssh-login. Dort wird standardmäßig eine Login-Shell gestartet (vgl. interaktive Shell, s.o.), die üblicherweise keine Instanz eines ssh-Agenten initiiert.

Hier gibt es zwei Möglichkeiten:

1.Möglichkeit (empfohlen): man installiert das paket keychain (sofern in den Distributionsquellen vorhanden) und überläßt diesem Programm dann das Starten des ssh-Agenten und Laden des Schlüssels. Dazu muß, analog zu obiger Vorgehensweise, in .profile oder in .bashrc in seinem Home-Verzeichnis (im Prinzip ist es egal, in welcher) nur der Aufruf von keychain mit dem Schlüssel als Argument erfolgen.

2.Möglichkeit: man fügt folgende Zeilen an seine .profile an:

# start up ssh-agent
SSH_ENV="$HOME/.ssh/environment"
function start_agent {
echo "Initialising new SSH agent..."
/usr/bin/ssh-agent | sed 's/^echo/#echo/' > "${SSH_ENV}"
echo succeeded
chmod 600 "${SSH_ENV}"
. "${SSH_ENV}" > /dev/null
/usr/bin/ssh-add ~/.ssh/svnkey;
}
# Source SSH settings, if applicable
if [ -f "${SSH_ENV}" ]; then
. "${SSH_ENV}" > /dev/null
#ps ${SSH_AGENT_PID} doesn't work under cywgin
ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent$ > /dev/null || {
start_agent;
}
else
start_agent;
fi

Zu beachten ist hier, dass der Schlüssel, welcher geladen werden soll, hier mit angegeben ist (9. Zeile). Der Name muß entsprechend dem tatsächlichen Namen des Schlüssels angepaßt werden.
In jeder zukünftig geöffneten Shell wird nun automatisch der Schlüssel geladen, so dass eine Passwortabfrage bei Zugriff auf svn umgangen (im positiven und auch sicheren Sinn) wird.
Um die Änderungen auch in der aktiven Shell anzuwenden, kann man außerdem noch den Inhalt der veränderten .profile erneut ausführen lassen mit:
source ~/.profile

= Remote-Mounten der Datenpartition durch sshfs =

Zum Mounten von Ordnern fremder Rechner auf dem lokalen Computer über ssh ist das tool sshfs ganz hilfreich. Es setzt auf dem FUSE-Dateisystem-Konzept auf, der Benutzer muß daher Mitglied der Gruppe "fuse" auf dem lokalen Rechner sein.

Als erstes sollte man sicherstellen, dass sshfs installiert ist, und es ggf. über den Paketmanager installieren, z.b.
sudo zypper install sshfs
Danach noch (z.b. über YaST->Benutzer und Gruppen) den eigenen Benutzer zur Gruppe ''fuse'' hinzufügen.

nun kann man ein Verzeichnis anlegen, in das das Filesystem des entfernten Rechners hingemountet wird:
mkdir sshfs/radioid

das mounten geschieht über:
sshfs radioid:/daten ~/sshfs/radioid/

dann sollte der Ordner /daten des radioiden in dem Verzeichnis sshfs/radioid gemountet sein. Der Hostname (in diesem fall radioid:/) muß natürlich dem System bekannt sein. Am besten man benutzt den Alias wie auch beim ssh-Login. Dann muß man auch kein PW eingeben.

Noch ein Tip: Ich habe das Mounten von nicht-lokalen Verzeichnissen komfortabel in ''gkrellm'' integriert. Dazu muß man einfach bei ''Configuration->File System'' ein neues primäres FS hinzufügen (s. Screenshot).

<gallery>
Bild:Gkrellm sshfs mount.png|Konfiguration sshfs-mount in gkrellm
Bild:Gkrellm sshfs mount2.png|Einbindung des Radioiden über sshfs-mount in gkrellm
</gallery>

Anleitungen/Tutorials

2011-02-16T21:58:00Z

Kdsachse: /* Server-Prozess */

= Benutzung der Datenaquisitions-Tools =

Beispiel für Aufruf datataker:
bin/datataker /dev/ttyS5

Obige Zeile verbindet sich mit dem ADC und gibt die Daten mit Timestamp auf ''stdout'' aus.

Um den Zusammenhang zwischen gemessenen Intensitäten und Koordinaten auszugeben ist

macros/acquire

aufzurufen. Dieses Script gibt in dieser Reihenfolge folgende Werte auf ''stdout'' aus:
timestamp ADC-Wert Azimut Höhe Stunde Deklination Controllertemperatur

macros/acquire_ref

erweitert die Ausgabe von macros/acquire um eine weitere Spalte

per default wird hier 19 mal der feed gemessen und danach 1 mal den Referenzkanal
Es gibt hier noch 3 wichtige (Stellungs)Parameter
*1. Averaging Anzahl default:100
*2. Verhältnis Signalwerte Referenzwerte default :20 heisst 19 Signal 1 Referenz
*3. Gesamtzahl der auszugebenden Werte default :-1 (endlos)

= Steuerung von Messungen =

== Steuerung über bash-Skripte ==

Das ist die flexibelste Art, Messungen auszuführen. Für die verschiedenen Aufgaben stehen im repo-tree im Unterverzeichnis [https://rm-radeberg.dyndns.org/trac/browser/trunk/macros macros/] (zusätzlich zu den reinen DAQ-Skripten, s.o.) folgende Steuerskripte zur Verfügung:

'''rt_scan_hor''' ... Messung in äquidistantem Grid in Horizontalkoordinaten (mind. 5 Parameter benötigt, s. Usage-Hilfe bei Aufruf ohne Parameter)

'''rt_scan_equ''' ... Messung in äquidistantem Grid in Äquatorialkoordinaten (mind. 5 Parameter benötigt, s. Usage-Hilfe bei Aufruf ohne Parameter)

== Steuerung über Task Scheduler "RATSCHE" ==

Das sollte ab Januar 2011 die verbindliche (einzige) Möglichkeit von Messungen sein, da hier Kollisionen ausgeschlossen sind.

=== Server-Prozess ===

Auf dem Radioiden muß eine Instanz von '''ratsche''' im Servermodus laufen, der Daemon-Prozess ist folgendermassen zu starten:
ratsche -d -x /home/hgz/svnlocal/hgz/macros
Das Argument zum Parameter -x ist der Ort der ausführbaren Makros, wie z.b. '''rt_scan_equ''', es muß also nicht unbedingt genau obige Zeile sein, wichtig ist nur das Macro-Verzeichnis irgendeiner lokalen Kopie des SVN-Repos (im obigen Fall meine lokale Arbeitskopie) anzugeben.

In Zukunft (irgendwann Jan-März) werde ich ein Start-Skript für den Radioiden schreiben, das automatisch den ratsche-daemon startet, dann haben wir eine Sorge weniger. Bis dahin bitte nach Neustart Radioid obige Zeile einmalig ausführen (wenn der Daemon bereits läuft wird jedoch keine zweite Instanz gestartet, der Aufruf gibt dann eine entsprechende Info-Meldung aus).

Eine Bemerkung von KDS: Bitte überprüft mit:
ps ax | grep -i ratsche
ob eine ratsche -d läuft und startet ggf. o.a. Kommandozeile den ratsche Server.

Im Momnet baut Andreas dieses Kommando in init.d ein

Der Serverprozess schreibt mehr oder weniger detaillierte Ausgaben (je nach beim Start angegebenen Verbosity-Level) in das System-Logfile. Diese können von allen Benutzern mit folgendem Befehl begutachtet werden:
tail -f -n 1000 /var/log/messages | grep ratsche
Der Output sieht dann beispielsweise so aus:
Jan 23 11:39:09 Radioid ratsche[18528]: starting RT task scheduler server
Jan 23 11:39:09 Radioid ratsche[18528]: using message queue 0x0000000a
Jan 23 11:39:09 Radioid ratsche[18528]: using executable path /home/hgz/svnlocal/hgz/macros/
Jan 23 11:39:09 Radioid ratsche[18528]: found 1 zombie message(s) in queue...deleting
Jan 23 11:50:00 Radioid ratsche[18528]: starting EquScan task with id=0 (pid 20342)

=== Benutzung von '''RATSCHE''' ===

Zum Zugriff auf den Taskmanager gibt es das systemweit bekannte tool '''ratsche''' (Option -h für Kommandozeilen-Hilfe und Auflistung aller verfügbarer Optionen). Hier nur eine kurze Beschreibung der wichtigsten Optionen:

ratsche -l

listet alle definierten Tasks auf. Die Bedeutung der einzelnen Werte ist aus dem ebenfalls ausgegebenen Header ersichtlich.

ratsche -a <tasklist>

fügt die in der datei <tasklist> definierten Tasks hinzu. Eine Beispieldatei ist zu finden im SVN-Repo in [https://rm-radeberg.dyndns.org/trac/browser/trunk/macros/dummy_task macros/dummy_task]. Am besten man legt sich eine lokale Kopie dieser Datei an, so dass es bei Veränderung dieser nicht zu SVN-Konflikten kommt, z.B. mit
cp dummy_task tasklist
Die Datei '''tasklist''' ist dann beliebig editierbar. für alle möglichen Task-Typen ist mind. ein Beispiel angegeben. Wenn der Task von '''ratsche''' übernommen werden soll, muß natürlich die entsprechende Zeile auskommentiert sein, i.e. das führende "#" zu entfernen. Das genaue Spaltenformat ist in der Beispieldatei erläutert.

'''Hinweis:''' Momentan werden die Werte von Priority und Alt-Period noch nicht berücksichtigt. Wird in Zukunft noch implementiert (ist auf meiner ToDo-Liste irgendwo mittendrin ;)

----

= Benutzung des Subversion (SVN) Repositories =

seit Anfang März 2010 lagert das Software-Repository auf Roberts Server. Eine Übersicht über die Struktur des Repositorys ist erreichbar über
file:///.../svnlocal/hgzlib/html/index.html in einem Browser, aber nur wenn man vorher die doxygen-Dokumentation mittels ''doxygen'' in diesem Verzeichnis erstellt hat.
Der Code kann auch durch ein [http://trac.edgewall.org/ Trac]-Webinterface angeschaut werden:

[https://rm-radeberg.dyndns.org/trac/browser/trunk https://rm-radeberg.dyndns.org/trac/browser/trunk]

(login und pw sind identisch mit dem Wiki-account)

Zum Auschecken der Repos in eine lokale Arbeitskopie kann entweder obige url benutzt werden, oder aber folgende Quelle, die auch Änderungen im Repository zuläßt (der https-Kanal ist read only, bzw. sollte es sein):

svn co svn+ssh://svn@rm-radeberg.dyndns.org/var/svn/hgz/trunk ~/svnlocal

Passwort ist bei [[Benutzer:Hgz|Hgz]] oder [[Benutzer:penner|Penner]] zu erfragen. Zusätzlich kann man sich noch durch Schlüsselaustausch und einem ssh-Agenten das lästige Eintippen des Passworts sparen (siehe unten).

Existiert bereits eine lokale Arbeitskopie (vom vorhergehenden Repository) ist es möglich, diesem die neue Adresse durch folgenden Befehl (im Hauptpfad der lok. Kopie, z.b. svnlocal/) mitzuteilen:

svn switch --relocate svn+ssh://svnuser@141.30.85.175/home/hgz/svnrep/trunk svn+ssh://svn@rm-radeberg.dyndns.org/var/svn/hgz/trunk

der commit-befähigte user heißt also jetzt svn (pw wie schon erwähnt erfragen). Das soll sich mittelfristig ändern, nämlich dann wenn das Repo endgültig auf dem Perseiden beheimatet wird. Dann wird jeder, der etwas in das Repo einchecken möchte einen Account haben, so dass der Urheber eines Commits auch automatisch im Log erkennbar ist. Andererseits wird nicht jeder auf Perseid registrierte User Schreibzugriff auf das SVN-Repo besitzen. Eine Registrierung (in Form einer mündlichen Absichtserklärung) ist vorzugsweise bei penner und Rücksprache mit [[Benutzer:Hgz|Hgz]] vorzunehmen.

=== Zugriff auf das svn-Repository durch ssh-Schlüssel ===

einen passwortlosen Zugriff auf das svn-Repository kann man durch Austausch eines vertraulichen Schlüssels erreichen. Dieser kann von [[Benutzer:Hgz|Hgz]] bezogen werden. Zum Aktivieren des Schlüssels (nehmen wir an, er heißt ''svnkey'') sollte man ihn zuerst an einem geeigneten Ort, wie z.B. $(HOME)/.ssh deponieren. Danach kann er dem ssh-Agenten bekannt gemacht werden mit:
ssh-add ~/.ssh/svnkey
Zum Kontrollieren, ob der Schlüssel geladen wurde, oder um sich die Liste bereits geladener Schlüssel anzusehen ist folgender Befehl nützlich:
ssh-add -l

Das bisher beschriebene Verfahren muß jedesmal wiederholt werden, wenn eine neue Konsole gestartet wird. Um den Schlüssel permanent in einer interaktiven Shell (das ist diejenige, die an dem Rechner gestartet wird, an dem man auch sitzt) bekannt zu machen, genügt es, obige Zeile in seine .bashrc (d.h. im eigenen Home-Verzeichnis) anzufügen, also

...
ssh-add ~/.ssh/svnkey

dann sollte an einem Rechner, auf dem eine grafische Benutzeroberfläche läuft, keine Passwortabfrage mehr beim Zugriff auf das svn-Repo erscheinen.

Anders verhält sich das bei entferntem Zugriff auf einen Rechner, z.b. über ssh-login. Dort wird standardmäßig eine Login-Shell gestartet (vgl. interaktive Shell, s.o.), die üblicherweise keine Instanz eines ssh-Agenten initiiert.

Hier gibt es zwei Möglichkeiten:

1.Möglichkeit (empfohlen): man installiert das paket keychain (sofern in den Distributionsquellen vorhanden) und überläßt diesem Programm dann das Starten des ssh-Agenten und Laden des Schlüssels. Dazu muß, analog zu obiger Vorgehensweise, in .profile oder in .bashrc in seinem Home-Verzeichnis (im Prinzip ist es egal, in welcher) nur der Aufruf von keychain mit dem Schlüssel als Argument erfolgen.

2.Möglichkeit: man fügt folgende Zeilen an seine .profile an:

# start up ssh-agent
SSH_ENV="$HOME/.ssh/environment"
function start_agent {
echo "Initialising new SSH agent..."
/usr/bin/ssh-agent | sed 's/^echo/#echo/' > "${SSH_ENV}"
echo succeeded
chmod 600 "${SSH_ENV}"
. "${SSH_ENV}" > /dev/null
/usr/bin/ssh-add ~/.ssh/svnkey;
}
# Source SSH settings, if applicable
if [ -f "${SSH_ENV}" ]; then
. "${SSH_ENV}" > /dev/null
#ps ${SSH_AGENT_PID} doesn't work under cywgin
ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent$ > /dev/null || {
start_agent;
}
else
start_agent;
fi

Zu beachten ist hier, dass der Schlüssel, welcher geladen werden soll, hier mit angegeben ist (9. Zeile). Der Name muß entsprechend dem tatsächlichen Namen des Schlüssels angepaßt werden.
In jeder zukünftig geöffneten Shell wird nun automatisch der Schlüssel geladen, so dass eine Passwortabfrage bei Zugriff auf svn umgangen (im positiven und auch sicheren Sinn) wird.
Um die Änderungen auch in der aktiven Shell anzuwenden, kann man außerdem noch den Inhalt der veränderten .profile erneut ausführen lassen mit:
source ~/.profile

= Remote-Mounten der Datenpartition durch sshfs =

Zum Mounten von Ordnern fremder Rechner auf dem lokalen Computer über ssh ist das tool sshfs ganz hilfreich. Es setzt auf dem FUSE-Dateisystem-Konzept auf, der Benutzer muß daher Mitglied der Gruppe "fuse" auf dem lokalen Rechner sein.

Als erstes sollte man sicherstellen, dass sshfs installiert ist, und es ggf. über den Paketmanager installieren, z.b.
sudo zypper install sshfs
Danach noch (z.b. über YaST->Benutzer und Gruppen) den eigenen Benutzer zur Gruppe ''fuse'' hinzufügen.

nun kann man ein Verzeichnis anlegen, in das das Filesystem des entfernten Rechners hingemountet wird:
mkdir sshfs/radioid

das mounten geschieht über:
sshfs radioid:/daten ~/sshfs/radioid/

dann sollte der Ordner /daten des radioiden in dem Verzeichnis sshfs/radioid gemountet sein. Der Hostname (in diesem fall radioid:/) muß natürlich dem System bekannt sein. Am besten man benutzt den Alias wie auch beim ssh-Login. Dann muß man auch kein PW eingeben.

Noch ein Tip: Ich habe das Mounten von nicht-lokalen Verzeichnissen komfortabel in ''gkrellm'' integriert. Dazu muß man einfach bei ''Configuration->File System'' ein neues primäres FS hinzufügen (s. Screenshot).

<gallery>
Bild:Gkrellm sshfs mount.png|Konfiguration sshfs-mount in gkrellm
Bild:Gkrellm sshfs mount2.png|Einbindung des Radioiden über sshfs-mount in gkrellm
</gallery>

Daten Auslesen

2010-11-19T21:11:41Z

Kdsachse: /* Roh-Datenformat */

= Paralleles Auslesen von diversen Sensoren und Zusammenbauen der Daten=
== Rohdatenspeicherung ==
Soweit ich verstanden habe, besteht die Aufgabe darin, den AD-Wandler mit einer Frequenz im Bereich 1 kHz und die Koordinaten mit einer Frequenz im Bereich 10 Hz auszulesen. Evtl. kommen auch mal noch weitere Sensoren hinzu. Die Weiterverarbeitung soll in Form von n-Tupeln (Zeitstempel; AD-Wert; Koordinaten) erfolgen. Das Ganze soll auch unter Belastung des Rechners noch zuverlässig erfolgen. Die Speicherung der Rohdaten erfolgt dabei sinnvollerweise nicht als n-Tupel, sondern in einem Raster der Art:

<math>(t_{n,0},ad_{n,0},c_{n,0});\, (t_1,ad_1);\, (t_2,ad_2);\, ... (t_{n,i},ad_{n,i},c_{n,i});\, (t_{n+1},ad_{n+1});\, ... </math>

mit

<math>n=k*i</math>

Die Koordinaten werden also nur aller k Zeitschritte auch wirklich ausgelesen und aufgeschrieben. Aus solch einem File kann für die Weiterverarbeitung wieder eine Liste mit kompletten n-Tupen erstellt werden. Dabei kann man die Koordinaten zwischen den Stützstellen interpolieren oder man lässt sie einfach konstant bis zum nächsten Messpunkt. Evtl. würde eine von beiden Varianten irgendwelche Statistiken stören. Die Rohdaten verursachen so weniger Last beim Schreiben und belegen weniger Speicherplatz als wenn immer ganze n-Tupel geschrieben werden müssten.

== '''Roh-Datenformat''' ==

Die bei der Messung der integralen Signalintensität im 1420MHz-Band am Detektorausgang gesampelten Daten werden im AVR-ADC-Board zunächst in einem Ringpuffer einem gleitenden Mittel unterzogen. Jeweils ein über RS232 aquirierter Messwert ist also schon ein Mittel über eine (einstellbare) Puffergröße (16-32768) und somit auch mit einer Zeitkonstanten behaftet. Dieser Messwert soll zusammen mit einem Zeitstempel im ASCII-Format abgelegt werden. Zusätzlich werden die äquatorialen Koordinaten benötigt und eine Information, ob das Signal der Antenne oder dem Referenzkanal entstammt.

Enthalten sein müssen:

* Zeitstempel, Format: yyyy/MM/dd hh:mm:ss.s
* Äquatorialkoordinaten (RA/Dec), Format: HH.h DD.d
* Messwert in ADC-Counts, floating-point
* Schalterstatus Referenz (0 oder 1)

Daneben sollte ein weiterer, davon unabhängiger Prozess alle Sensorenwerte und andere periphere Daten in regelmäßigen Zeitabständen in einer Log-Datei speichern. Dazu gehören diverse Temperaturen, Spannungen, Ströme, andere Umweltsensoren und evtl. INDI-RT-spezifische Werte, wie Motorgeschwindigkeiten o.ä. aber auch Observablen des Steuerrechners, wie z.b. die aktuelle Präzision der ntp-gesteuerten Systemuhr. Die Identifikation und ggf. Korrelation zu den Hauptdaten erfolgt wieder durch Vergabe eines eindeutigen Zeitstempels.
Bsp.:
#date time temp1 temp2 windsensor IMot1 IMot2 U1 U2 U3 U4 ntp-err
2010/04/19 23:25:11.765235000 28.5 43.1 15 0 3.5 11.8 5.1 24.6 0.25 2.3

Beispiel für Aufruf datataker:
bin/datataker /dev/ttyS5

Obige Zeile konnekted mit dem ADC und gibt die Daten mit timestamp auf stdout aus.

Um den Zusammenhang zwischen gemessenen Intensitäten und Koordinaten auszugeben ist

macros/acquire

aufzurufen. Dieses Script gibt in dieser Reihenfolge folgende Werte auf stdout aus:
timestamp ADC-Wert Azimut Höhe Stunde Deklination Controlertemperatur

macros/acquire_ref

erweitert die Ausgabe von macros/acquire um eine weitere Spalte

per default wird hier 19 mal der feed gemessen und danach 1 mal den Referenzkanal
Es gibt hier noch 3 wichtige (Stellungs)Parameter
1. Averaging Anzahl default:100
2. Verhältnis Signalwerte Referenzwerte default :20 heisst 19 Signal 1 Referenz
3. Gesamtzahl der auszugebenden Werte default :-1 (endlos)

== Datenaufnahme ==
Um eine möglichst jitterarme Datenaufnahme zu gewährleisten scheint es sinvoll, die einzelnen Sensoren in jeweils einen eigenen Prozess oder Thread zu packen. Dann kann der sich in aller Genauigkeit um seinen Sensor kümmern und wird hoffentlich vom Betriebssystem richtig mit Zeitscheiben versorgt. Dabei benötigt man allerdings eine gemeinsame Zeitbasis mit ausreichender Genauigkeit.

In [[Daten_Auswerten#Einzelwerte]] steht etwas von einem Ringpuffer der im DA vorhanden sei und dessen eigenständiger Messwertaufnahme in eben diesen Ringpuffer. Wie funktioniert das denn eigentlich?

Ich stelle mir den prinzipiellen Ablauf so vor:
# zentrale Instanz übergibt Details wie Samplefrequenz, ... und den Startzeitpunkt an einzelne Messprozesse.
# Messprozesse warten auf Startzeitpunkt und legen dann los
# Messprozesse messen vor sich hin, in persönlichen großen Ringpuffer.
# zentrale Instanz holt sich ab und an aus den Ringpuffern die Daten die sie haben will und schreibt sie in ein File

----

----

== Verschiedene Prozesse ==
Die Kommunikation könnte man über Pipes, Fifos, Shared-Memory, Message-Queues, TCP (Sockets) machen, im Prinzip auch mit MPI.

* MPI ist Mist, weil man dann immer ein MPI-System braucht
* Message Queues sind im Prinzip cool, praktisch aber viel zu kurz und für zu kleine Datenmengen gedacht (10 Messages a 8kB ist Standard unter Linux). Dafür soll das halt sehr schnell sein (im L1-Cache bleiben etc).
* Pipes, Fifos ist halt ein bisschen fummelig. TCP keine Ahnung
* SHMem ist eigentlich ziemlich ok. Man muss natürlich von Hand synchronisieren. Das ist eigentlich auch kein Ding weiter. Wenn man einmal Zugriff auf den gemeinsamen Speicherbereich hat, sollte das nicht schwieriger sein als mit OpenMP (s.u.).

*[http://www.ecst.csuchico.edu/~beej/guide/ipc/mq.html Message Queues]
*[http://kirkwylie.blogspot.com/2008/10/posix-message-queues-useful-but-limited.html POSIX Message in Linux]

== Verschiedene Threads ==
Nachteil ist, dass die einzelnen Ausleseprozesse nicht gegeneinander geschützt sind.
=== OpenMP ===
Dafür gibt es die nahezu triviale Variante mit OpenMP. Der geringe Aufwand könnte die eher theoretischen Nachteile durchaus wieder wettmachen, finde ich.
Ich stelle mit das ungefähr so vor:

#include <iostream>
#include <stdlib.h>
#include <stdio.h>
#include <omp.h>
#include <unistd.h>

using namespace std;
int showAction;

/* Das ist eine etwas missbräuchliche aber immer noch sehr einfache Verwendung
von OpenMP zur Arbeit mit Threads. Auf alle Fälle ist es schön
einfach. Evtl. müssen die Jobs das Lesen nicht in einer critical Section
machen aber es wird hier nichts schaden.
*/

int job1(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&1) cout << "1";
cout.flush();
usleep(5000); // nominell 5 ms
}
}

int job2(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&2) cout << "2";
cout.flush();
usleep(5000); // 5 ms
}
}

int job3(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&4) cout << "3";
cout.flush();
usleep(5000); // 5 ms
}
}

int main()
{
int nthreads, tid;
omp_set_nested(1);

/* Fork a team of threads with each thread having a private tid variable */
#pragma omp parallel private(tid) num_threads (4)
{

/* Obtain and print thread id */
tid = omp_get_thread_num();
printf("Hello World from thread = %d\n", tid);
switch (tid)
{
case 1: job1(); break;
case 2: job2(); break;
case 3: job3(); break;
}
/* Only master thread does this */
if (tid == 0)
{
nthreads = omp_get_num_threads();
printf("Number of threads = %d\n", nthreads);
}
for(;;) // master thread verteilt die aufgaben
{
#pragma critical
showAction=rand();
usleep(100000); // nominell 100 ms
}
} /* All threads join master thread and terminate */
}

* [http://cclh61.chm.tu-dresden.de/edv/manuals/xlc5/compiler/ref/ruompcrt.htm critical section]

== Synchronisation ==
Mit den Pragmas von OpenMP kann man eine Synchronisation erreichen. Ein Thread wartet auf andere Threads, ich würde denken aktiv. Für Zwecke des Datensampelns sind die meisten Threads fast immer in Wartestellung. OpenMP bietet die Möglichkeit, Locks zu setzen. Darauf aufbauend könnte man eine sinnvolle Datenübergabe bauen und dazwischen die Threads schlafen legen.
Das stelle ich mir so vor:

= Systemtechnik und Zeitkonstanten =

== Kompendium der Usage ==

* Vergesslichkeit etc. zu bekämpfen ...
** Allanplot: root # .L allanplot.C++ # allenplot() ... tatsächlich mit e, nicht a
** Macros: (zB)
*** <makro>.C (zuvor <file> einsetzen): # root -l <makro>.C
*** '''oder''' # root -> .x <makro.C
** 2dfft siehe Changeset 497 for trunk

== Verfahren bei zeitkonstanten Signalen ==

Vorbehaltlich einer grafischen Darstellung. Die Einzelschritte sind für eine rise time gerechnet, die eine Amplitude von 90% auf der Flanke ergibt [[http://de.wikipedia.org/wiki/Anstiegs-_und_Abfallzeit]]. Keine Totzeiten eingerechnet.

* analoge Tiefpassfilterung resp. Integration im Detektor: <math>\tau_{Det}</math>
** 400ns für einen Anstieg von 10% auf 90% gem. Datenblatt AD8307

* zeit- und wertdiskrete Tiefpassfilterung im Analog-Digital-Konverter (ADC): <math>\tau_{ADC}</math>
** Der ADC sampelt mit 20kHz, d.h. der Puffer ist in 50ms einmal durchgeschoben, je nach Firmware kann sich ein Faktor 2 oder gar 4 zu diesem Wert ergeben. Also 10...200ms

* zeit- und wertdiskrete Tiefpassfilterung (resp. Integration) per Software (precision:double): <math>\tau_{SW}</math>
** (Beispiel). 50 Samples von 2,5 Dauer eines Timestamps, sind (hier) 75s

Die 0,9-Zeitkonstante ergibt sich hier zu <math>\sqrt{\tau_{Det}^2+\tau_{ADC}^2+\tau_{SW}^2}\approx76s</math>. Es ist ersichtlich dass die Zeitkonstante via Suche nach dem rms-Minimum ganz überwiegend von der Software bestimmt wird.

* Der Schwenk zum nächsten Punkt dauert ebenfalls mehrere Sekunden, sind hier alles in allem 80s.

* Unterstellt man einmal, dass
** die 5° breite "ideale" Keule mit 3dB Abfall in 1/5-Schritten noch akzeptable Werte bringt (sind 1°) und
** ein 1h in RA / 15° in Dec grosses Feld interessiert, so wären
** für diesen Scan 5h anzusetzen.
** ideale Wetterbedingungen vorausgesetzt

* Abhängig von der Deklination der Quelle sind hier Zu- und Abschläge möglich. Horizontprobleme, Messungen unter 30° Elevation sind in der Regel wertlos oder nicht möglich.

Daten Auslesen

2010-11-19T21:00:51Z

Kdsachse: /* Roh-Datenformat */

= Paralleles Auslesen von diversen Sensoren und Zusammenbauen der Daten=
== Rohdatenspeicherung ==
Soweit ich verstanden habe, besteht die Aufgabe darin, den AD-Wandler mit einer Frequenz im Bereich 1 kHz und die Koordinaten mit einer Frequenz im Bereich 10 Hz auszulesen. Evtl. kommen auch mal noch weitere Sensoren hinzu. Die Weiterverarbeitung soll in Form von n-Tupeln (Zeitstempel; AD-Wert; Koordinaten) erfolgen. Das Ganze soll auch unter Belastung des Rechners noch zuverlässig erfolgen. Die Speicherung der Rohdaten erfolgt dabei sinnvollerweise nicht als n-Tupel, sondern in einem Raster der Art:

<math>(t_{n,0},ad_{n,0},c_{n,0});\, (t_1,ad_1);\, (t_2,ad_2);\, ... (t_{n,i},ad_{n,i},c_{n,i});\, (t_{n+1},ad_{n+1});\, ... </math>

mit

<math>n=k*i</math>

Die Koordinaten werden also nur aller k Zeitschritte auch wirklich ausgelesen und aufgeschrieben. Aus solch einem File kann für die Weiterverarbeitung wieder eine Liste mit kompletten n-Tupen erstellt werden. Dabei kann man die Koordinaten zwischen den Stützstellen interpolieren oder man lässt sie einfach konstant bis zum nächsten Messpunkt. Evtl. würde eine von beiden Varianten irgendwelche Statistiken stören. Die Rohdaten verursachen so weniger Last beim Schreiben und belegen weniger Speicherplatz als wenn immer ganze n-Tupel geschrieben werden müssten.

== '''Roh-Datenformat''' ==

Die bei der Messung der integralen Signalintensität im 1420MHz-Band am Detektorausgang gesampelten Daten werden im AVR-ADC-Board zunächst in einem Ringpuffer einem gleitenden Mittel unterzogen. Jeweils ein über RS232 aquirierter Messwert ist also schon ein Mittel über eine (einstellbare) Puffergröße (16-32768) und somit auch mit einer Zeitkonstanten behaftet. Dieser Messwert soll zusammen mit einem Zeitstempel im ASCII-Format abgelegt werden. Zusätzlich werden die äquatorialen Koordinaten benötigt und eine Information, ob das Signal der Antenne oder dem Referenzkanal entstammt.

Enthalten sein müssen:

* Zeitstempel, Format: yyyy/MM/dd hh:mm:ss.s
* Äquatorialkoordinaten (RA/Dec), Format: HH.h DD.d
* Messwert in ADC-Counts, floating-point
* Schalterstatus Referenz (0 oder 1)

Daneben sollte ein weiterer, davon unabhängiger Prozess alle Sensorenwerte und andere periphere Daten in regelmäßigen Zeitabständen in einer Log-Datei speichern. Dazu gehören diverse Temperaturen, Spannungen, Ströme, andere Umweltsensoren und evtl. INDI-RT-spezifische Werte, wie Motorgeschwindigkeiten o.ä. aber auch Observablen des Steuerrechners, wie z.b. die aktuelle Präzision der ntp-gesteuerten Systemuhr. Die Identifikation und ggf. Korrelation zu den Hauptdaten erfolgt wieder durch Vergabe eines eindeutigen Zeitstempels.
Bsp.:
#date time temp1 temp2 windsensor IMot1 IMot2 U1 U2 U3 U4 ntp-err
2010/04/19 23:25:11.765235000 28.5 43.1 15 0 3.5 11.8 5.1 24.6 0.25 2.3

Beispiel für Aufruf datataker:
bin/datataker /dev/ttyS5

Obige Zeile konnekted mit dem ADC und gibt die Daten mit timestamp auf stdout aus.

Um den Zusammenhang zwischen gemessenen Intensitäten und Koordinaten auszugeben ist

macros/acquire

aufzurufen. Dieses Script gibt in dieser Reihenfolge folgende Werte auf stdout aus:
timestamp ADC-Wert Azimut Höhe Stunde Deklination Controlertemperatur

== Datenaufnahme ==
Um eine möglichst jitterarme Datenaufnahme zu gewährleisten scheint es sinvoll, die einzelnen Sensoren in jeweils einen eigenen Prozess oder Thread zu packen. Dann kann der sich in aller Genauigkeit um seinen Sensor kümmern und wird hoffentlich vom Betriebssystem richtig mit Zeitscheiben versorgt. Dabei benötigt man allerdings eine gemeinsame Zeitbasis mit ausreichender Genauigkeit.

In [[Daten_Auswerten#Einzelwerte]] steht etwas von einem Ringpuffer der im DA vorhanden sei und dessen eigenständiger Messwertaufnahme in eben diesen Ringpuffer. Wie funktioniert das denn eigentlich?

Ich stelle mir den prinzipiellen Ablauf so vor:
# zentrale Instanz übergibt Details wie Samplefrequenz, ... und den Startzeitpunkt an einzelne Messprozesse.
# Messprozesse warten auf Startzeitpunkt und legen dann los
# Messprozesse messen vor sich hin, in persönlichen großen Ringpuffer.
# zentrale Instanz holt sich ab und an aus den Ringpuffern die Daten die sie haben will und schreibt sie in ein File

----

----

== Verschiedene Prozesse ==
Die Kommunikation könnte man über Pipes, Fifos, Shared-Memory, Message-Queues, TCP (Sockets) machen, im Prinzip auch mit MPI.

* MPI ist Mist, weil man dann immer ein MPI-System braucht
* Message Queues sind im Prinzip cool, praktisch aber viel zu kurz und für zu kleine Datenmengen gedacht (10 Messages a 8kB ist Standard unter Linux). Dafür soll das halt sehr schnell sein (im L1-Cache bleiben etc).
* Pipes, Fifos ist halt ein bisschen fummelig. TCP keine Ahnung
* SHMem ist eigentlich ziemlich ok. Man muss natürlich von Hand synchronisieren. Das ist eigentlich auch kein Ding weiter. Wenn man einmal Zugriff auf den gemeinsamen Speicherbereich hat, sollte das nicht schwieriger sein als mit OpenMP (s.u.).

*[http://www.ecst.csuchico.edu/~beej/guide/ipc/mq.html Message Queues]
*[http://kirkwylie.blogspot.com/2008/10/posix-message-queues-useful-but-limited.html POSIX Message in Linux]

== Verschiedene Threads ==
Nachteil ist, dass die einzelnen Ausleseprozesse nicht gegeneinander geschützt sind.
=== OpenMP ===
Dafür gibt es die nahezu triviale Variante mit OpenMP. Der geringe Aufwand könnte die eher theoretischen Nachteile durchaus wieder wettmachen, finde ich.
Ich stelle mit das ungefähr so vor:

#include <iostream>
#include <stdlib.h>
#include <stdio.h>
#include <omp.h>
#include <unistd.h>

using namespace std;
int showAction;

/* Das ist eine etwas missbräuchliche aber immer noch sehr einfache Verwendung
von OpenMP zur Arbeit mit Threads. Auf alle Fälle ist es schön
einfach. Evtl. müssen die Jobs das Lesen nicht in einer critical Section
machen aber es wird hier nichts schaden.
*/

int job1(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&1) cout << "1";
cout.flush();
usleep(5000); // nominell 5 ms
}
}

int job2(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&2) cout << "2";
cout.flush();
usleep(5000); // 5 ms
}
}

int job3(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&4) cout << "3";
cout.flush();
usleep(5000); // 5 ms
}
}

int main()
{
int nthreads, tid;
omp_set_nested(1);

/* Fork a team of threads with each thread having a private tid variable */
#pragma omp parallel private(tid) num_threads (4)
{

/* Obtain and print thread id */
tid = omp_get_thread_num();
printf("Hello World from thread = %d\n", tid);
switch (tid)
{
case 1: job1(); break;
case 2: job2(); break;
case 3: job3(); break;
}
/* Only master thread does this */
if (tid == 0)
{
nthreads = omp_get_num_threads();
printf("Number of threads = %d\n", nthreads);
}
for(;;) // master thread verteilt die aufgaben
{
#pragma critical
showAction=rand();
usleep(100000); // nominell 100 ms
}
} /* All threads join master thread and terminate */
}

* [http://cclh61.chm.tu-dresden.de/edv/manuals/xlc5/compiler/ref/ruompcrt.htm critical section]

== Synchronisation ==
Mit den Pragmas von OpenMP kann man eine Synchronisation erreichen. Ein Thread wartet auf andere Threads, ich würde denken aktiv. Für Zwecke des Datensampelns sind die meisten Threads fast immer in Wartestellung. OpenMP bietet die Möglichkeit, Locks zu setzen. Darauf aufbauend könnte man eine sinnvolle Datenübergabe bauen und dazwischen die Threads schlafen legen.
Das stelle ich mir so vor:

= Systemtechnik und Zeitkonstanten =

== Kompendium der Usage ==

* Vergesslichkeit etc. zu bekämpfen ...
** Allanplot: root # .L allanplot.C++ # allenplot() ... tatsächlich mit e, nicht a
** Macros: (zB)
*** <makro>.C (zuvor <file> einsetzen): # root -l <makro>.C
*** '''oder''' # root -> .x <makro.C
** 2dfft siehe Changeset 497 for trunk

== Verfahren bei zeitkonstanten Signalen ==

Vorbehaltlich einer grafischen Darstellung. Die Einzelschritte sind für eine rise time gerechnet, die eine Amplitude von 90% auf der Flanke ergibt [[http://de.wikipedia.org/wiki/Anstiegs-_und_Abfallzeit]]. Keine Totzeiten eingerechnet.

* analoge Tiefpassfilterung resp. Integration im Detektor: <math>\tau_{Det}</math>
** 400ns für einen Anstieg von 10% auf 90% gem. Datenblatt AD8307

* zeit- und wertdiskrete Tiefpassfilterung im Analog-Digital-Konverter (ADC): <math>\tau_{ADC}</math>
** Der ADC sampelt mit 20kHz, d.h. der Puffer ist in 50ms einmal durchgeschoben, je nach Firmware kann sich ein Faktor 2 oder gar 4 zu diesem Wert ergeben. Also 10...200ms

* zeit- und wertdiskrete Tiefpassfilterung (resp. Integration) per Software (precision:double): <math>\tau_{SW}</math>
** (Beispiel). 50 Samples von 2,5 Dauer eines Timestamps, sind (hier) 75s

Die 0,9-Zeitkonstante ergibt sich hier zu <math>\sqrt{\tau_{Det}^2+\tau_{ADC}^2+\tau_{SW}^2}\approx76s</math>. Es ist ersichtlich dass die Zeitkonstante via Suche nach dem rms-Minimum ganz überwiegend von der Software bestimmt wird.

* Der Schwenk zum nächsten Punkt dauert ebenfalls mehrere Sekunden, sind hier alles in allem 80s.

* Unterstellt man einmal, dass
** die 5° breite "ideale" Keule mit 3dB Abfall in 1/5-Schritten noch akzeptable Werte bringt (sind 1°) und
** ein 1h in RA / 15° in Dec grosses Feld interessiert, so wären
** für diesen Scan 5h anzusetzen.
** ideale Wetterbedingungen vorausgesetzt

* Abhängig von der Deklination der Quelle sind hier Zu- und Abschläge möglich. Horizontprobleme, Messungen unter 30° Elevation sind in der Regel wertlos oder nicht möglich.

Daten Auslesen

2010-11-19T20:42:51Z

Kdsachse: /* Roh-Datenformat */

= Paralleles Auslesen von diversen Sensoren und Zusammenbauen der Daten=
== Rohdatenspeicherung ==
Soweit ich verstanden habe, besteht die Aufgabe darin, den AD-Wandler mit einer Frequenz im Bereich 1 kHz und die Koordinaten mit einer Frequenz im Bereich 10 Hz auszulesen. Evtl. kommen auch mal noch weitere Sensoren hinzu. Die Weiterverarbeitung soll in Form von n-Tupeln (Zeitstempel; AD-Wert; Koordinaten) erfolgen. Das Ganze soll auch unter Belastung des Rechners noch zuverlässig erfolgen. Die Speicherung der Rohdaten erfolgt dabei sinnvollerweise nicht als n-Tupel, sondern in einem Raster der Art:

<math>(t_{n,0},ad_{n,0},c_{n,0});\, (t_1,ad_1);\, (t_2,ad_2);\, ... (t_{n,i},ad_{n,i},c_{n,i});\, (t_{n+1},ad_{n+1});\, ... </math>

mit

<math>n=k*i</math>

Die Koordinaten werden also nur aller k Zeitschritte auch wirklich ausgelesen und aufgeschrieben. Aus solch einem File kann für die Weiterverarbeitung wieder eine Liste mit kompletten n-Tupen erstellt werden. Dabei kann man die Koordinaten zwischen den Stützstellen interpolieren oder man lässt sie einfach konstant bis zum nächsten Messpunkt. Evtl. würde eine von beiden Varianten irgendwelche Statistiken stören. Die Rohdaten verursachen so weniger Last beim Schreiben und belegen weniger Speicherplatz als wenn immer ganze n-Tupel geschrieben werden müssten.

== '''Roh-Datenformat''' ==

Die bei der Messung der integralen Signalintensität im 1420MHz-Band am Detektorausgang gesampelten Daten werden im AVR-ADC-Board zunächst in einem Ringpuffer einem gleitenden Mittel unterzogen. Jeweils ein über RS232 aquirierter Messwert ist also schon ein Mittel über eine (einstellbare) Puffergröße (16-32768) und somit auch mit einer Zeitkonstanten behaftet. Dieser Messwert soll zusammen mit einem Zeitstempel im ASCII-Format abgelegt werden. Zusätzlich werden die äquatorialen Koordinaten benötigt und eine Information, ob das Signal der Antenne oder dem Referenzkanal entstammt.

Enthalten sein müssen:

* Zeitstempel, Format: yyyy/MM/dd hh:mm:ss.s
* Äquatorialkoordinaten (RA/Dec), Format: HH.h DD.d
* Messwert in ADC-Counts, floating-point
* Schalterstatus Referenz (0 oder 1)

Daneben sollte ein weiterer, davon unabhängiger Prozess alle Sensorenwerte und andere periphere Daten in regelmäßigen Zeitabständen in einer Log-Datei speichern. Dazu gehören diverse Temperaturen, Spannungen, Ströme, andere Umweltsensoren und evtl. INDI-RT-spezifische Werte, wie Motorgeschwindigkeiten o.ä. aber auch Observablen des Steuerrechners, wie z.b. die aktuelle Präzision der ntp-gesteuerten Systemuhr. Die Identifikation und ggf. Korrelation zu den Hauptdaten erfolgt wieder durch Vergabe eines eindeutigen Zeitstempels.
Bsp.:
#date time temp1 temp2 windsensor IMot1 IMot2 U1 U2 U3 U4 ntp-err
2010/04/19 23:25:11.765235000 28.5 43.1 15 0 3.5 11.8 5.1 24.6 0.25 2.3

Beispiel für Aufruf datataker:
./datataker /dev/ttyS5

Obige Zeile konnekted mit dem ADC und gibt die Daten mit timestamp auf stdout aus.

== Datenaufnahme ==
Um eine möglichst jitterarme Datenaufnahme zu gewährleisten scheint es sinvoll, die einzelnen Sensoren in jeweils einen eigenen Prozess oder Thread zu packen. Dann kann der sich in aller Genauigkeit um seinen Sensor kümmern und wird hoffentlich vom Betriebssystem richtig mit Zeitscheiben versorgt. Dabei benötigt man allerdings eine gemeinsame Zeitbasis mit ausreichender Genauigkeit.

In [[Daten_Auswerten#Einzelwerte]] steht etwas von einem Ringpuffer der im DA vorhanden sei und dessen eigenständiger Messwertaufnahme in eben diesen Ringpuffer. Wie funktioniert das denn eigentlich?

Ich stelle mir den prinzipiellen Ablauf so vor:
# zentrale Instanz übergibt Details wie Samplefrequenz, ... und den Startzeitpunkt an einzelne Messprozesse.
# Messprozesse warten auf Startzeitpunkt und legen dann los
# Messprozesse messen vor sich hin, in persönlichen großen Ringpuffer.
# zentrale Instanz holt sich ab und an aus den Ringpuffern die Daten die sie haben will und schreibt sie in ein File

----

----

== Verschiedene Prozesse ==
Die Kommunikation könnte man über Pipes, Fifos, Shared-Memory, Message-Queues, TCP (Sockets) machen, im Prinzip auch mit MPI.

* MPI ist Mist, weil man dann immer ein MPI-System braucht
* Message Queues sind im Prinzip cool, praktisch aber viel zu kurz und für zu kleine Datenmengen gedacht (10 Messages a 8kB ist Standard unter Linux). Dafür soll das halt sehr schnell sein (im L1-Cache bleiben etc).
* Pipes, Fifos ist halt ein bisschen fummelig. TCP keine Ahnung
* SHMem ist eigentlich ziemlich ok. Man muss natürlich von Hand synchronisieren. Das ist eigentlich auch kein Ding weiter. Wenn man einmal Zugriff auf den gemeinsamen Speicherbereich hat, sollte das nicht schwieriger sein als mit OpenMP (s.u.).

*[http://www.ecst.csuchico.edu/~beej/guide/ipc/mq.html Message Queues]
*[http://kirkwylie.blogspot.com/2008/10/posix-message-queues-useful-but-limited.html POSIX Message in Linux]

== Verschiedene Threads ==
Nachteil ist, dass die einzelnen Ausleseprozesse nicht gegeneinander geschützt sind.
=== OpenMP ===
Dafür gibt es die nahezu triviale Variante mit OpenMP. Der geringe Aufwand könnte die eher theoretischen Nachteile durchaus wieder wettmachen, finde ich.
Ich stelle mit das ungefähr so vor:

#include <iostream>
#include <stdlib.h>
#include <stdio.h>
#include <omp.h>
#include <unistd.h>

using namespace std;
int showAction;

/* Das ist eine etwas missbräuchliche aber immer noch sehr einfache Verwendung
von OpenMP zur Arbeit mit Threads. Auf alle Fälle ist es schön
einfach. Evtl. müssen die Jobs das Lesen nicht in einer critical Section
machen aber es wird hier nichts schaden.
*/

int job1(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&1) cout << "1";
cout.flush();
usleep(5000); // nominell 5 ms
}
}

int job2(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&2) cout << "2";
cout.flush();
usleep(5000); // 5 ms
}
}

int job3(void)
{
for(;;)
{
#pragma critical
int sAct=showAction;
if (sAct&4) cout << "3";
cout.flush();
usleep(5000); // 5 ms
}
}

int main()
{
int nthreads, tid;
omp_set_nested(1);

/* Fork a team of threads with each thread having a private tid variable */
#pragma omp parallel private(tid) num_threads (4)
{

/* Obtain and print thread id */
tid = omp_get_thread_num();
printf("Hello World from thread = %d\n", tid);
switch (tid)
{
case 1: job1(); break;
case 2: job2(); break;
case 3: job3(); break;
}
/* Only master thread does this */
if (tid == 0)
{
nthreads = omp_get_num_threads();
printf("Number of threads = %d\n", nthreads);
}
for(;;) // master thread verteilt die aufgaben
{
#pragma critical
showAction=rand();
usleep(100000); // nominell 100 ms
}
} /* All threads join master thread and terminate */
}

* [http://cclh61.chm.tu-dresden.de/edv/manuals/xlc5/compiler/ref/ruompcrt.htm critical section]

== Synchronisation ==
Mit den Pragmas von OpenMP kann man eine Synchronisation erreichen. Ein Thread wartet auf andere Threads, ich würde denken aktiv. Für Zwecke des Datensampelns sind die meisten Threads fast immer in Wartestellung. OpenMP bietet die Möglichkeit, Locks zu setzen. Darauf aufbauend könnte man eine sinnvolle Datenübergabe bauen und dazwischen die Threads schlafen legen.
Das stelle ich mir so vor:

= Systemtechnik und Zeitkonstanten =

== Kompendium der Usage ==

* Vergesslichkeit etc. zu bekämpfen ...
** Allanplot: root # .L allanplot.C++ # allenplot() ... tatsächlich mit e, nicht a
** Macros: (zB)
*** <makro>.C (zuvor <file> einsetzen): # root -l <makro>.C
*** '''oder''' # root -> .x <makro.C
** 2dfft siehe Changeset 497 for trunk

== Verfahren bei zeitkonstanten Signalen ==

Vorbehaltlich einer grafischen Darstellung. Die Einzelschritte sind für eine rise time gerechnet, die eine Amplitude von 90% auf der Flanke ergibt [[http://de.wikipedia.org/wiki/Anstiegs-_und_Abfallzeit]]. Keine Totzeiten eingerechnet.

* analoge Tiefpassfilterung resp. Integration im Detektor: <math>\tau_{Det}</math>
** 400ns für einen Anstieg von 10% auf 90% gem. Datenblatt AD8307

* zeit- und wertdiskrete Tiefpassfilterung im Analog-Digital-Konverter (ADC): <math>\tau_{ADC}</math>
** Der ADC sampelt mit 20kHz, d.h. der Puffer ist in 50ms einmal durchgeschoben, je nach Firmware kann sich ein Faktor 2 oder gar 4 zu diesem Wert ergeben. Also 10...200ms

* zeit- und wertdiskrete Tiefpassfilterung (resp. Integration) per Software (precision:double): <math>\tau_{SW}</math>
** (Beispiel). 50 Samples von 2,5 Dauer eines Timestamps, sind (hier) 75s

Die 0,9-Zeitkonstante ergibt sich hier zu <math>\sqrt{\tau_{Det}^2+\tau_{ADC}^2+\tau_{SW}^2}\approx76s</math>. Es ist ersichtlich dass die Zeitkonstante via Suche nach dem rms-Minimum ganz überwiegend von der Software bestimmt wird.

* Der Schwenk zum nächsten Punkt dauert ebenfalls mehrere Sekunden, sind hier alles in allem 80s.

* Unterstellt man einmal, dass
** die 5° breite "ideale" Keule mit 3dB Abfall in 1/5-Schritten noch akzeptable Werte bringt (sind 1°) und
** ein 1h in RA / 15° in Dec grosses Feld interessiert, so wären
** für diesen Scan 5h anzusetzen.
** ideale Wetterbedingungen vorausgesetzt

* Abhängig von der Deklination der Quelle sind hier Zu- und Abschläge möglich. Horizontprobleme, Messungen unter 30° Elevation sind in der Regel wertlos oder nicht möglich.