Weitere Informationen

Höhere Mathematik, oder: Wer viel mißt …
Saturday, February 6, 2010, 17:38 - Geeks & Co., Verschiedenes, Linux, Hausautomation, DVB
Ich sag' mal so: irgendwas stimmt hier nicht. Ich wollte mal ermitteln, wieviel Watt (-stunden) denn so ein FSC Scenic Xs wirklich auf die Uhr bringt, denn die angegebenen Werte klingen doch recht verlockend:
Stromversorgung
GerätetypStromversorgung
Erforderliche NetzspannungWechselstrom 110/220 V ± 10% ( 50/60 Hz )
Gestellte Leistung80 Watt
Leistungsaufnahme im Betrieb27 Watt
Stromverbrauch Standby/Ruhezustand24 Watt
ProduktzertifizierungenEPA Energy Star

Nun, »im Betrieb« ist das Schätzchen seit ca. 16:03, …
root@vdr-2:~# w
16:57:51 up 54 min, 1 user, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
root pts/0 greebo.uu.org 16:57 1.00s 0.02s 0.00s w
… aber den Werten des EM-Systems von ELV/Conrad zufolge, ist der Verbrauch von 160 auf 220 Watt angestiegen mit dem Einschalten des Scenic Xs. Also braucht dieser Scenic Xs 60 Watt »im Betrieb«, schlapp das 2,222fache dessen, was avisiert wird.

Ich habe nun gegen 17:18 einen weiteren Scenic Xs auf dem Meßpfad eingeschaltet, der erste und der zweite Meßwert zeigen einen Anstieg der Last von 220 auf 250 Watt an (Meßwert 3: 240 Watt; Intervall 5 Minuten), was vollkommen im Rahmen läge; sofern sich das hält, muß der Mehrverbrauch des ersten Xs sich ergeben durch Unterschiede bei Hauptspeicher (gleich: 128 MB), Platte (vdr-2: zwei Jahre alte 500 GB-IDE; anderer Xs: irgendeine alte 40er oder 80er IDE), Mainboard (D1171 jeweils) oder … den beiden DVB-S1-Karten in vdr-2.
Da wäre mal ein deutliches »Whow!« fällig, denn je 15 Watt Energieverbrauch pro Technotrend-DVB-S-Budget-Karte – mithin 50% ders Grundverbrauchs des PC-Systems on top –, das ist schon ein Wort:
01:09.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
Subsystem: Technotrend Systemtechnik GmbH Device 100f
Flags: bus master, fast Back2Back, medium devsel, latency 123, IRQ 18
Memory at f4101000 (32-bit, non-prefetchable) [size=512]
Kernel driver in use: budget_ci dvb
Kernel modules: budget-ci

01:0b.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
Subsystem: Technotrend Systemtechnik GmbH Device 100f
Flags: bus master, fast Back2Back, medium devsel, latency 123, IRQ 19
Memory at f4101400 (32-bit, non-prefetchable) [size=512]
Kernel driver in use: budget_ci dvb
Kernel modules: budget-ci
Nein, es läuft keine Anwendung und nicht einmal die ZF-Eingänge sind derzeit beschaltet … Da ich noch andere, »billigere« DVB-S-Karten habe, werde ich wohl mal einsteigen in einen lustigen Hardware-Umbau-und-Energieverbrauchsmeßzyklus. Wünscht mir Glück ;)

Nexus Two – den Schuß nicht gehört?
Sunday, January 31, 2010, 09:58 - Android
Klasse, da phantasiert man schon über ein »Nexus Two«, wo das One noch nicht mal richtig in D angekommen ist; naja, was soll's, ein Telefon ohne Hardwaretastatur möchte ich auch nicht mehr haben …

Aber falls die Werte, die da im Raum stehen, stimmen, dann hat Motorola den Schuß echt nicht gehört:
Eine 8-Megapixel-Kamera mit HD-Aufnahmefunktion und ein HDMI-Port für digitale Übertragung von Audio- und Videosignalen stehen zudem auf der Ausstattungsliste des Motorola Shadow/Nexus Two. Wann, ob und zu welchem Preis das Gerüchte-Handy Wirklickkeit wird, steht noch nicht fest.

Ganz groß Jungs, wenn das stimmt; ich kann wirklich nur hoffen, daß Eure »8-Megapixel-Kamera« dann mal bessere Bilder macht als der 5-Megapixel-Dreck, den Ihr im Droid/Milestone verbaut habt. Verglichen mit dem Pixemmatsch, der da typischerweise zurückkommt, ist eine beliebige 2-MPix-Cam HD² … Schade, schade — wie man gute Telefone mit – für ein Telefon – guter Kamera baut, solltet Ihr Euch mal von Nokia zeigen lassen: das N95 ist für mich in der Hinsicht nach wie vor unerreicht (es komprimiert nur etwas zu stark).

Kein HTC Sense™ für mein HTC Magic
Saturday, January 30, 2010, 12:05 - Verschiedenes, Android, Servicewüste, GSM/GRPS/UMTS/...
Da hat Golem leider schlecht recherchiert:
HTC hat eine neue Firmware für das Android-Smartphone Magic veröffentlicht, die nun die Sense-Bedienoberfläche auf das Gerät bringt. Mit dem Hero wurde das neue Bedienkonzept von HTC im Sommer 2009 eingeführt. […] Die neue Firmware für das HTC Magic steht kostenlos als Download zur Verfügung. Erst nach Eingabe der Geräteseriennummer wird der Download freigegeben. […]

Rein technisch stimmt das, nur gibt es eben nicht nur ein HTC Magic, sondern derer (mindestens) zwei, und für eines davon, welches in Deutschland von Vodafone vertrieben wird, »with Google« steht hinten drauf, ist dieses Update leider »nicht geeignet« — so zumindest die Aussage nach Eingabe meiner (Vodafone-) Magic-Seriennummer (s. Screenshot).

Also nix mit neuer »Firmware für das Android-Smartphone Magic«, sondern nur für bestimmte Geräte … Locked in, mal wieder :(

Allein, nicht allein, doch allein und überhaupt: RRD cross-platform
Friday, January 29, 2010, 17:00 - Geeks & Co., Painseeker, Linux, Hausautomation, PlugComputing
Allein zu sein, das ist kein schönes Gefühl. Komischerweise bekomme ich das bei meinen Projekten des öfteren ;)

Nachdem ich nun einen meiner SheevaPlugs zum primären Hausautomatisationsknoten gemacht habe und FHEM darauf auch schön läuft, war der nächste logische Schritt, auch die Langzeitdatenaufzeichnung mittels RRD zu aktivieren, um den betagten, energiehungrigeren FSC Scenic xS entsorgen und einmotten zu können.

Und wenn man die Daten erst mal hat, das Auswerten kann ja auch von anderen System erfolgen, NFS und ähnliches macht's möglich … ja, aber nicht bei plattformabhängigen Datenbasen, wie sie RRD nun einmal leider erzeugt:
wusel@server-1:~$ rrdtool info /mounts/plug-2/rrd-fhem/Parkplatz_TH/temperature.rrd 
ERROR: This RRD was created on another architecture
Schön, daß wir drüber gesprochen haben … Ich hatte das in der Tat vergessen, aber für optimale Performance schreibt RRD nuneinmal die lokale Speicherabbildung des Daten in die Datei. Und die Darstellung unterscheidet sich leider zwischen Ubuntu auf armel und Ubuntu auf x86 — die Ausgabe ist keine rauspatchbare Schikane, denn rrdtool testet nach dem Einlesen einen »magischen Wert«, und der differiert, leider, obwohl beide Plattformen nach »little-endian«-Notation laufen.

Ich fühlte mich erst einmal allein gelassen, nachdem ich googelte und mehr so nichts deutlich neueres als eine Frage aus 2002 bzw. vage Diskussionen zu dem Thema fand:
Aber, niemals die Hoffnung aufgeben — und siehe, Überlegungen gibt es schon und ein Projekt für die Übergangszeit, welches mir helfen könnte — also doch nicht alleine!

Gelesen, gezogen, geinstalliert; geht nicht:
wusel@server-1:~$ tird-rrdtool -arch arm dump /mounts/plug-2/rrd-fhem/Huette_TH/temperature.rrd 
ERROR: This RRD was created on other architecture
Und wieder zu früh gefreut und auch wieder allein; armel wird augenscheinlich nicht unterstützt; klar, das Gros der bisherigen Router auf einer Embedded-Plattform waren vom Typ mips.

Tcha. Da habe ich also nun meine Daten auf einem kleinen, energiesparenden – aber eben FPU-schwachen – »Plug«, nur weiterverarbeiten unter x86 kann ich sie derzeit nur, wenn ich sie periodisch auf dem Plug ex- und dann auf x86 wieder importierte. Das hätte ich gerne *nur* auf x86 gemacht, aber dazu jetzt ein static binary unter qemu für meine arm5el-Systeme zu bauen, sprengt doch etwas den Rahmen; da wird das kleine Kistchen halt die eine oder andere CPU-Überstunde schieben müssen, bis rrdtool 1.5 cross-platform-Unterstützung mitbgringt … (Oder ich versuche mich an einem "repacking" der Daten beim Einlesen, aber wahrscheinlich ist's es soo einfach nicht, wenn man die Datenrepräsentation sich ansieht.)

Zu früh gefreut?
Wednesday, January 27, 2010, 23:57 - Geeks & Co., Verschiedenes, Linux
Mittlerweile ist einer meiner SheevaPlugs schon recht gut integriert in das, was er mal machen soll. Leider macht mir grade andere Software den Erfolg streitig:
wusel@cam-serv2:~$ rrdtool info /mounts/plug-2/rrd-fhem/Parkplatz_TH/temperature.rrd 
ERROR: This RRD was created on another architecture
Großes Kino mal wieder. Ich erstelle die Daten auf armv5tel und will sie lesen (weiterverarbeiten) auf i686. Tja, obwohl beides litle-endian-Setups sind, meckert rrdtool. Im Prinzip hat es auch recht; die Frage ist, wie relevant die Meldung tatsächlich ist … *seufz*


Zurück Weiter