Rückschau zerties.org-Treff (52nd day of Confusion in the YOLD 3175)

Das Internet ist voller Katzen...

...also springen wir Zerties jetzt auch auf diesen Zug auf (:lol:).
Links sieht man übrigens Didis neues As*s-Netbook (:mrgreen:)- Zweck dieser Aktion war das Testen der eingebauten Webcam. Angenehmerweise funktioniert auch der Rest der Hardware sehr schön "out of the box". Anne meinte schon, wir brauchen in Zukunft gar nicht mehr den großen Stammtisch- naja inzwischen kommen sich Jochen und Doc mit ihren klassischen Notebooks schon vor wie Dinosaurier (:razz:).
Aber wie die Erfahrung zeigt wird der freiwerdende Platz sofort von anderen Gadgets wie Netzteilen, GPS-Empfängern, PDAs, Zusatztastaturen, Schaltungen, Teilchenbeschleunigern usw. usf. eingenommen...

Jochen bastelt einen Akku

Mit bewundernswerter Ausdauer hat sich Jochen in das nicht ganz unkomplizierte Gebiet der Li-Ion-Akkus eingearbytet in dem Bemühen, selbst einen Akkupack für seinen Zaurus zu bauen.
Natürlich braucht man dann dazu auch noch einen Laderegler (siehe Bild oben die kleine Schaltung in der Leitung)- und das war das größte Problem: Li-Ions sind sehr kritisch was das Laden angeht- steigt die Spannung über einen bestimmten Schwellwert an (hier 4,1V), dann steigt der Strom plötzlich exponential an und die Zellen können sogar explodieren (:eek:)! Nach langem Hin und Her fand Jochen dann heraus, warum die meisten Akkus drei Anschlüsse haben: da auf der Lastleitung (Fachsprache: Force) beim Laden ein hoher Strom fliesst, fällt je nach Widerstand der Leitung eine gewisse Spannung daran ab, so dass man dies kompensieren muss indem man die Spannung der Quelle entsprechend erhöht und die Spannung am Akku über eine dritte Leitung (Fachsprache: Sense) misst und als Regelgröße für den Regler benutzt. Ein wenig mehr dazu findet man hier.
Stolz konnte er also das Ergebnis präsentieren:

Der Akkupack wird wie ein gewöhnliches externes Netzteil an den PDA angeschlossen:

Linux@Thinkpad 770X

Einen Veteran der Thinkpad-Serie (High-End-Ausführung) (:wink:) hatte Doc für einen Kumpel dabei: dieser möchte mal in Linux hineinschnuppern und hat Xubuntu 9.04 auf dem Gerät installiert.
Jedoch blieb der Lautsprecher stumm und auch der Bildschirm zeigte nicht die mögliche Auflösung von 1024x768 an sondern blieb auf 800x600 beschränkt.
stesie löste beide Probleme als alter Thinkpad-User souverän: das richtige Kernel-Modul brachte den Sound zum Erklingen und das Aufbohren der Frequenzen in der xorg.conf überredete den X-Server dazu, die volle Auflösung anzuzeigen.
Gerade noch rechtzeitig, denn die etwas angestaubte Festplatte mit einem hörbaren Lagerschaden nervte die Anwesenden mit einem unangenehmen Sirren und bremste das System durch die langsamen Transferraten ganz schön aus (:sad:)

Wanderlust ohne ZAN

Damit Menschen ohne ZAN-Zugang auch in den Genuss der Wanderlust-Pakete für die iPAQs kommen hat stesie den Feed, der bisher nur unter http://wanderlust.zo/ (und damit im ZAN) verfügbar war, jetzt für den Rest der Welt abrufbar gemacht. Hintergrund ist die gewisse Not an öffentlichen IP-Adressen, auf Grund derer einige unserer Maschinen nur über private IP-Adressen bzw. IPv6 erreichbar sind.

Umgekehrt soll, bzw. muss, die Trennung der Maschinen beibehalten werden, d.h. die Pakete müssen auf einer Maschine entstehen und von einer anderen ausgeliefert werden. Kurzum ein Datenaustausch ist nicht zu vermeiden -- wenn das Umkopieren nur nicht immer so nerven würde. Gut, Not macht bekanntlich erfinderisch. Eine Brainstorming, wie man das Problem lösen könnte, brachte zunächst auch nur Scheinlösungen hervor: von einer domU zur anderen mounten (NFS), aber was passiert, wenn eine domU ausfällt; mit rsync und cron, ... alles nichts ...

Nach einer Weile kam die Idee: wir exportieren von der dom0 aus ein Verzeichnis via NFS und alle domU greifen darauf zu. Dann kann beispielsweise die domU wanderlust ihre Päckchen dort abliefern und die domina liefert sie via HTTP an die dankbaren Abnehmer. Und wenn der NFS-Daemon auf der dom0 nicht läuft, laufen die domU wohl ebenfalls nicht. Also brauchen wir nur noch einen Namen für das Ganze. In jeden Sudkessel [Name der dom0, Anm. der Redaktion] gehört bekanntlich Malz...

Gesagt, getan, stesie hat ein ausreichend großes NFS-Share auf sudkessel eingerichtet und auf allen domU als /malz gemountet, Pfade umgebogen usw. Langer Rede kurzer Sinn, die iPAQ Feeds liegen jetzt alle unter http://domina.zerties.org/malz/feed/ wie gewohnt zum Abruf bereit. stesie's Versuch einfach das ganze Home-Verzeichnis via NFS zu verteilen, auch an die Rundfunkempfangsgeräte zu Hause, war weniger erfolgsreich. Die Netzwerkbandbreite reicht einfach nicht aus. Alles viel zu lahm, also doch weiter auf IMAP setzen (:mrgreen:)

Nachdem der iPAQ-Feed nun wieder erreichbar war, hat sich stesie noch um Doc's Diva, den widerspenstigen iPAQ, gekümmert. Das Paket mit dem Kernel-Modul ext2 sollte installiert werden, in der Version 2.6.15. Allerdings bildete sich das gute ipkg ein, dass ein 2.6.17-er Paket installiert sei, dieses aber weder deinstallieren noch downgraden könne. Für Abhilfe hat letztlich ein beherztes Editieren der Status-Datenbank gesorgt. Danach ging die Installation des richtigen Pakets dann schmerzfrei wie gewohnt.

OSM-Radtouren

Da Doc sich jüngst ein Rennrad gegönnt hatte, wollte er das Angenehme mit dem Nützlichen verbinden und die doch noch sehr löchrige Karte der näheren Umgebung in OSM ergänzen. Hierfür hat er seinen Tomtom-GPS-Empfänger am Lenker befestigt:

Der hx4700-PDA in der Rückentasche empfängt via Bluetooth die Daten und reicht diese an Navit durch, das einen gpx-Track aufzeichnet.
Die ganze Sache hatte nur einen Haken: der interne Akku des Tomtom hält nur ca. 3h, das reicht für längere Radtouren bei weitem nicht aus. Deshalb muss ähnlich wie bei Jochens PDA ein externer Akkupack als Energiequelle herhalten; das ist natürlich keine sehr elegante Lösung.
Dann wurde ich auf dieses schöne Gerät aufmerksam:

es wird eine Akkulaufzeit von bis zu 10h versprochen, lässt sich über USB wieder aufladen und hat einen 52-Kanal(!)-Empfänger. Der Hersteller behauptet, man könnte es problemlos am Schlüsselbund baumeln lassen oder sogar in der Handtasche verstauen, der Empfang funktioniere dann immer noch- naja erstens hab ich keine Handtasche und als nächstes behaupten sie noch, es funktioniere auch in der U-Bahn (:rolleyes:).
Nichts desto trotz verliefen die ersten Tests sehr vielversprechend, dank SPP-Protokoll wurde das Device wie der alte Empfänger auch als /dev/rfcomm0 eingebunden und reicht dann die Daten an Navit weiter. Heraus kommen dann Tracks im gpx-Format, die z.B. mit JOSM weiterverarbeitet werden können:

Dann ging's ans Eingemachte: ich habe in den vergangenen Wochen schon Tracks gesammelt und möchte nun fehlende Strassen und Ortschaften in OSM einpflegen.
Dabei stieß ich aber auf ein neues Problem: Navit legt seine Bookmarks in einem etwas eigenwilligen Format ab, das JOSM nicht interpretieren kann (:sad:)- man könnte umständlich die Koordinaten in Navit herauslesen und dann auf JOSM übertragen.
Wesentlich mehr hack value hat aber navit2gpx, ein Python-Script, dass sich stettberger mal eben so aus den Fingern saugte (:santa:)- vielen Dank dafür! Es wandelt die komplette bookmarks.txt in ein gpx-File um, das in JOSM eingeblendet werden kann.
Alsbald war ich nach einem Crashkurs durch Didi dabei, die ersten Einträge in OSM einzupflegen:

Falls jemand von Google-Maps hier mitliest: die Ortschafft bei Bruckberg heisst Wustendorf und nicht Wüstendorf (:biggrin:)