Rückschau Bastelabend (61st day of Confusion in the YOLD 3174)

RFM12-Speedup Reloaded

und ein paar andere Spielereien (:biggrin:):

...und nächstes Mal befassen wir uns mit der kalten Kernfusion :-) - nein im Ernst, unter Weiterlesen gibts mehr zu RFM12, Teslaspulen und Ipaqmania...

Teslaspulen

Mehr hierzu gibt´s wie immer in der Wikipedia.

Im Dunkeln kommt der Effekt natürlich besser, insbesondere wenn man Leuchtstoffröhren und Energiesparlampen "drahtlos" zum Leuchten bringt- und wenn Jochen wieder während der Belichtungsdauer das Arrangement änder XD kommt auch ein interessantes Bild dabei heraus: 8-)

pimping that f*cking RFM12 driver

Nachdem stesie bereits am vorangegangenen Wochenende sowohl den Funk2Duo als auch das EtherSex so modifiziert hat, dass über RFM12 Pakete größer als 254 Bytes übertragen werden können, war jetzt noch unser Liebling, der iPAQ, fällig. Gesagt getan, 11-bit-Zähler sind auf einem 8-bit-Controller einfach kein Spaß, zumindest wenn man sich auf Assembler beschränkt :-)

Aber gut, den AVR wieder einmal modifiziert, den zugehörigen Kerneltreiber gleich mit. Geht, okay, ein bißchen. Lustiger Effekt: man konnte den iPAQ von außen pingen, aber der iPAQ konnte seine Außenwelt nicht pingen. Nachdem stesie viel Zeit mit der Fehlersuche zugebracht hat, war klar, der Fehler ist im EtherSex, nicht im iPAQ-Code. Na klasse, die Änderungen im Assembler-Code waren fehlerfrei, aber bei der Modifikation des EtherSex hat sich eine Off-By-One-Fehler eingeschlichen. Das letzte Byte wurde beim Empfang nicht gespeichert, sondern der Empfang vorher als erfolgreich quittiert und beendet. Von Außen konnte man pingen, weil das letzte Datenbyte dabei nicht modifiziert werden muss und so noch richtig im Speicher lag ...

Diesen Fehler behoben, zeigte sich unmittelbar das nächste Problem: Ziel war bzw. ist es ja, dass der iPAQ nur Pakete von max. 173 Byte senden kann (mehr lässt der Speicher des AVR leider nicht zu), aber wesentlich größere Pakete empfangen kann, da diese unmittelbar durchgeleitet werden können. Beim Aufbau einer TCP-Verbindung empfehlen sich die beiden Gegenstellen jeweils eine maximale Segmentgröße. Nachdem der Kernel des iPAQ weiß, dass er maximal 173 Byte senden darf, orientiert er sich bei seiner Empfehlung an diesem Wert. Ist natürlich recht unschön, wenn die Empfehlung nur wenige hundert Byte lautet, aber auch locker ein Kilobyte über den Äther dürfte. Die Manpage von ip ist vielversprechend, es gibt eine Option advmss, die eben diese Empfehlung steuern helfen verspricht, nur geht das leider ausschließlich für IPv6. Nach einiger Sucherei hat stesie dann die Datei /proc/sys/net/ipv4/route/min_adv_mss gefunden, mit der man da ein bißchen nachhelfen kann 8-)

Zum Leidwesen von stesie war's das aber immer noch nicht: nachdem die TCP Window-Size größer als die MSS ist, kommen gern zwei, drei Päckchen unmittelbar nacheinander. Ist nur blöd, wenn der iPAQ sich nach dem ersten Paket überlegt, dass er eigentlich auch mal ein ACK senden könnte... die Lösung dieses Problems hat stesie dann auf den Folgetag (bzw. auf den selben Tag aber nach einmal Schlafen) vertagt ...

Illuminierte Zitterdisplays

Jochen hat sich zusammen mit stesie und dessen Oszi noch auf die Suche nach dem "Zitterproblem" seines iPAQs gemacht ... seit dem Einbau des Funkmoduls zittert der Mauszeiger, während man den Stylus aufgesetzt lässt, wild in alle Richtungen. Dieses Verhalten beschränkt sich bei Jochen aber nicht auf ein einzelnes Pixel hin oder her (wie bei stesie der Fall), sondern das kann durchaus mal ein Zentimeter werden ...

Am Oszilloskop fiel schnell auf, dass das Signal äußerst unsauber ist, aber komischerweise nur wenn das Funkmodul nah an der Hauptplatine des iPAQ liegt, und auch dann nur manchmal. stesie bemerkte dann eher zufällig, dass das Signal sauber wird, wenn man längere Zeit das Display nicht berührt ... da war's plötzlich klar: die Störungen rühren von der Displaybeleuchtung. Die HF-Abstrahlung der Beleuchtungselektronik wird an der Diode am Funkmodul gleichgerichtet und belustigt dann als Gleichspannung die Umgebung ... ein paar Abblockkondensatoren später war das Signal dann astrein, Zitterei vorbei. Dass die Zitterei bei stesie weniger wild ausfällt hat seine Ursache darin, dass er die Displayhelligkeit auf etwa 30% eingestellt hat, Jochen sich aber lieber ein wenig blenden lässt :-)

Bleibt die Frage, wie das Modul nebst Kondensatoren in den iPAQ passen soll %)

Ipaqmania

Und wieder ist unser jüngster Abhängiger burned dran: neben dem h3800 hat er auch noch einen h3600 mit Cradle und CF-Sleeve erstanden, welche aber ein wenig merkwürdig ist: die CF-Medien passten in beide Richtungen hinein (:exclaim:)- sogar ein schicker CF-Bluetooth-Dongle war Bestandteil des Pakets 8-) Nachdem ein paar Schwierigkeiten (die CF muss zwingend mit fat16 formatiert sein!) überwunden waren kam der große Moment- say goodbye Windows:

und hello Familiar:

Am Rande sei erwähnt, dass burned und stesie gemeinsam noch ALSA auf dem hx3800 zum Laufen gebracht haben. Mit dem aktuellen Distributionskernel (hh37) geht die SD-Karte nicht sonderlich, dafür mit dem von stesie kompilierten hh42, für den stesie bislang den ALSA-Kram jedoch nicht kompiliert hatte.