Apr 02

OpenwebRX / WebSDR aufsetzen

Elektronik, Fun, Ham, Linux Kommentare deaktiviert für OpenwebRX / WebSDR aufsetzen

Ziel: Einen SDR aufsetzen, der per Browser erreichbar ist.

Am Ende dieser Anleitung hat man einen WebSDR wie bspw. diesen: https://sdr.dj7nt.de

Neben der eigentlichen WebSDR-Funktionalität, bietet openwebRX u.a. die Möglichkeit, dass WSPR/FT8/FT4/etc. Signale automatisch im Hintergrund dekodiert und auch an die entsprechenden Portale wie pskreporter.info / wspr.rocks weitergeleitet werden. Sehr schön um Langzeitstudien des eigenen QTHs / der eigenen Antenne durchzuführen.

Zutaten:

  • Raspberry Pi 3 oder 4
  • Netzteil für den Pi (5V / 1,5A)
  • SD-Karte (min. 4 GB)
  • SDR-Hardware (Auswahl)
    • RTL-SDR (Für den Anfang ok, aber recht instabil / unsensitiv)
    • SDRPlay (RSPdx bspw.)
    • HackRF
    • PlutoSDR
    • …
  • PanAdapter, sofern der SDR an derselben Antenne wie der Shack-TRX betrieben werden soll
  • USB-Kabel
  • Antennenkabel

Kochrezept:

Zunächst openwebrx herunterladen und das ZIP entpacken. Anschliessend den “Raspberry Pi Imager” herunterladen und starten. Dort dann unter “OS wählen” die image-Datei aus dem openwebrx-ZIP auswählen. Da es einige – wenige – Dinge gibt, die wir direkt auf dem Pi ohne das WebInterface zu Anfang erledigen müssen nun auf das Zahnrad unten rechts clicken.

Hier kann bspw. der Hostname u.a. angegeben werden. Wichtig ist aber, dass ein Haken bei “SSH aktivieren” angeclickt wird, und bei “Benutzername und Passwort setzen”. Benutzername/PW ist frei wählbar, sollte man sich jedoch merken 😉

Wer fit in der Linux-Welt ist, kann natürlich auch seinen SSH-PublicKey hinterlegen. WiFi-Konfiguration kann man machen, muss man aber nicht. Ich bin ein Freund von LAN-Kabeln. Ist stabiler als WLAN.

Nun kann man die SD-Karte einlegen und im Imager die korrekte Karte auswählen. Anschliessend auf “schreiben” drücken. Jetzt wird das openwebrx-Image auf die Karte geschrieben.

Aufbau der Hardware hier wie folgt:

Während all das passiert können wir uns der Hardware widmen. Ich nutze hier einen SDRPlay-RSPdx, aber wie oben beschrieben funktioniert auch ein günstiger (<20 Euro) RTL-SDR-Stick. Beim RTL-SDR wird – um die Kurzwellenbänder zu Empfangen – noch ein UpConverter benötigt. Beispielsweise der HamItUp von Nooelec.

Szenario: SDR soll die selbe Antenne wie der Transceiver nutzen:

Blockschaltbild

Kurze Erklärung: Der Panadapter sorgt dafür, dass der SDR zur Antenne durchgeschaltet wird, so lange der TRX nicht auf Sendung ist. Wird am TRX PTT gedrückt, trennt der Panadapter instant das Signal zum SDR. Wird nicht gesendet, so bekommen sowohl SDR als auch TRX das Antennensignal. Ich habe mich für einen simplen Panadapter aus China entschieden. Bei meinem Model musste noch ein Jumper umgesteckt werden, damit die Trennung auch vollzogen wird. Der Adapter verfügt über eine HF-VOX (ich traue diesen VOX-Dingern nicht) oder aber über einen PTT-Cinch-Anschluss womit man den Adapter mit dem TRX verbinden kann (die aktuellen Transceiver haben alle ein PTT-Out). Es empfiehlt sich das ganze unbedingt vor Anschluss des SDRs zu testen. Im Worstcase geht die volle Leistung des TRX nämlich sonst in den SDR – und das wird der garantiert nicht mögen

Szenario: SDR bekommt eine eigene Antenne:

Das alles entfällt natürlich, wenn man dem SDR eine eigene Antenne gönnt. In dem Falle wird die (eigene) Antenne einfach an das SDR-Gerät geklemmt, und der SDR per USB an den RaspberryPi und fertig.

Der erste Start / Boot:

Nachdem alles wie oben beschrieben verkabelt/angeschlossen ist (LAN nicht vergessen ;), können wir den Pi das erste mal mit Strom über die USB-Buchse versehen. Sobald der Raspberry hochgefahren ist, suchen wir uns die IP-Adresse die das Gerät bekommen hat. Hier gibt es mehrere Wege, die von der Architektur des (Heim-)Netzwerks abhängen:

  • Suchen des Geräts in der Fritzbox/Speedport/Plastikrouter der die IPs im LAN vergibt und jeweilige IP merken.
  • Je nach Netzwerk ist der Pi sogar schon über den o.g. Hostnamen (siehe Kochrezept, zweiter Absatz) erreichbar.

Ein kurzer Test ob das Gerät anpingbar ist (ping [hostname] (s.o.) bzw. ping [IP] auf der Kommandozeile des PC’s/Mac) gibt Aufschluss ob die Maschine erreichbar ist. Jetzt wird es – für nicht Linuxer – ganz kurz etwas komplexer, denn wir müssen auf dem Pi einen neuen Nutzer/Kennwort für das Websdr anlegen.

Nutzer anlegen

Linux und Mac-User haben es einfach, hier wird ein Terminal/Shell aufgemacht und anschliessend kann man sich per ssh [user]@[hostname] (user/hostname bitte den verwenden, der unter Kochrezept Absatz 2 vergeben wurde) auf den Pi verbinden.

Als Windowsnutzer wird noch ein SSH-Client benötigt. Als Leichtgewichtig hat sich Putty herausgestellt. Also herunterladen und unter Host den Hostnamen bzw. die IP-Adresse eintragen, sowie anschliessend unten im Fenster auf “Connect”/”Verbinden” drücken.

Ist man auf der Shell des Pis angekommen, lässt sich nun ein Nutzer anlegen. Das geschieht durch die Eingabe des folgendes Befehls/Kommandos:

sudo openwebrx admin adduser adminuser

Es wird also ein neuer (Web-)Nutzer mit dem Namen “adminuser” angelegt. Andere Namen sind natürlich auch möglich. Nach dem Abschicken des Befehls fragt das Tool nach einem zu vergebenden Passwort. Ist das erledigt, kann man die Shell wieder schliessen (logout).

Damit wäre das komplizierteste geschafft.

Login/SetUp/Test

Unter http://[hostname oder IP] kann man sich nun auf dem WebSDR einloggen. Der zuvor genannte Admin-Nutzer wird für den Login der Settings-Seite (oben rechts im Webinterface) benötigt. Dort lassen sich Bänder/Profile und Co. für die jeweiligen SDR-Empfänger einstellen. Wer hier tiefer einsteigen mag, dem sei die Doku von openwebRX ans Herz gelegt. Auch Funktionen wie die eingangs erwähnte Dekodierung der DigiModes ist dort erklärt.

Weitere Dinge, wie bspw. Update des Raspberries oder explizite Konfiguration der SDRs sind in der Regel nicht erforderlich. Die Images von openwebRX werden sehr häufig aktualisiert, sodass man an sich immer eine aktuelle Version bei der Installation vorfindet. Die SDRs werden direkt beim booten erkannt, Feineinstellungen können über die bereits erwähnte Settings-Seite (Zahnrad oben rechts) erledigt werden.

Settings-Seite von openwebRX

Viel Spass mit dem eigenen WebSDR

Fallstricke:

Ein kleiner “Annex” über die Fallstricke, die es beim aufsetzen geben kann:

Problemggf. Abhilfe
Stick wird nicht erkannt– Stick im Webinterface nicht aktiv(iert) -> Aktivieren
– Pi neu booten
– tiefere Analyse auf der Shell durchführen (lsusb, syslog, etc.)
– Stick ggf. inkompatibel
WebSDR nicht aus dem Internet erreichbarWar auch nicht Teil dieser Anleitung 😉
Stichpunkte zum googlen / selber erarbeiten:
portforwarding, fritzbox, dyndns, ...
Bänder in der Auswahl fehlenBänder unter Setttings / passender SDR hinzufügen
Wasserfall zu “rot”/”dunkel”In Settings / “SDR Devices & Profiles” / passender SDR mit dem Wert “Gain” herumspielen
SDR wird erkannt, aber es wird kein/ein zu gedämpftes Signal angezeigtIn Settings / “SDR Devices & Profiles” / passender SDR über “Additional / Optional Settings” den richtigen Antenneneingang wählen (bspw. bei SDRPlay oder Geräten mit mehreren Antenneneingängen)
Dekodierung/Spotting funktioniert nicht.In Settings die Einstellungen zum “Background-Decoding” sowie “Spotting und Reporting” prüfen. Ferner unter “SDR Devices & Profiles” / passender SDR einen “Scheduler” hinzufügen und bei “Run Background-Services” einen Haken setzen.
Tagged with: • • • • • • • • • •
Mai 24

Raspberry A Bewegungsmelder reloaded

Allgemein, Linux No Comments »

Wie hier im Blog schon beschrieben, habe ich mir mit einem Pi A einen kleinen Statusscreen gebastelt, der sich immer dann anschaltet, wenn jemand in die nähe des Pi’s kommt. Realisiert wurde das mit der PiCam – basierend auf Helligkeitsänderungen beim Snapshot. Soweit so gut. Seit 2 Monaten hängt sich der olle Pi jedoch regelmässig auf. So schlimm, dass ich Ihm einen crontab-Eintrag verpasst habe, mit dem er jede Nacht neu bootet.

Zeit der Sache mal auf den Grund zu gehen. Das Problem war: Zu wenig RAM. Der Pi A hat gerade 256MB davon (eigentlich mehr als genug, für soetwas). Dummerweise hängt in PiCam direkt an der GPU des kleinen Rechners. Was bedeutet, dass man dem Ding in der /boot/config.txt den Parameter gpu_mem=128 mitgeben muss. Heisst: 128MB für die GPU (drunter funktioniert die cam nicht) und 128MB für das OS. Sofern man nun nicht eine extraschlanke Distribution mit busybox und dem ganzen Small-Mem-Footprint-gedönse nutzt, ist das verdammt mau. Erst recht mit der extrem aufgeblasenen Raspianedition.

Also mussten Lösungsansätze her. Die Cam mit weniger als 128MB GPU-RAM zu betreiben funktioniert also schon mal nicht. Dann halt komplett anders.  Für gerade mal 1,10 Euro/Stück gibt es bei Amazon PIR-Sensoren. PIR steht für Pyroelektrische Passive Infrarot Sensoren. Die Dinger, die man aus den Bewegungsmeldern an Aussenlampen kennt. Das besondere an diesen PIRs ist, dass sie out-of-the-box mit dem Pi über GPIO spielen können.

Obwohl das Chinaware ist, ist es relativ gut dokumentiert. In dieser Grafik findet sich alles, was man wissen muss:

Wir sehen zwei Potentiometer, mit denen man die Empfindlichkeit und eine Art “Nachlaufwert” einstellen kann. Den Timer stellt man am besten auf “0” (Anschlag ganz links), das “Distanz”-Poti nach Gusto. Nun zum elektrischen:

  • VCC bei dem Ding ist 5V – der kommt also an PIN2 des GPIO’s (+5V OUT)
  • GND auf GND – PIN 6
  • OUT ist der PIN, der “HIGH” wird, wenn sich was vor dem Sensor bewegt. Und coolerweise spuckt das Ding ca. 3,3V aus – also genau richtig für den GPIO. Den hängen wir an GPIO18 (PIN 12)

Hier eine Übersicht der GPIO-PINs des raspis:

Nach dem das nun alles Erledigt ist, geht es zum simpleren Teil. Der Software. Ich habe das ganze, wie bereits beim Cam-Script in Python realisiert:

#!/usr/bin/python
import subprocess
import os
import time
import RPi.GPIO as io
from datetime import datetime
delay=60
monitor='on'
pir_pin = 18
io.setmode(io.BCM)
io.setup(pir_pin, io.IN)         # activate input

def turnMonitorOn(extrarg):
  global monitor
  monitor='on'
  subprocess.call("/usr/bin/screen.sh on "+extrarg, shell=True)

def turnMonitorOff(extrarg):
  global monitor
  monitor='off'
  subprocess.call("/usr/bin/screen.sh off "+extrarg, shell=True)
   
# Reset last capture time
lastCapture = time.time()
# added this to give visual feedback of camera motion capture activity.  Can be removed as required

while True:
  time.sleep(0.5)
  if io.input(pir_pin):
    lastCapture = time.time()
    if (monitor == 'off'):
      turnMonitorOn("y")

  if (time.time()-lastCapture > delay):
    if (monitor == 'on'):
      turnMonitorOff('x')

In der Variable “delay” kann man einstellen, wie lange der Screen nach einer Bewegungserkennung angeschaltet bleiben soll. Es sind natürlich auch andere Pins als GPIO18 möglich (bspw. GPIO4 / Pin7)

Das Shellscript, “screen.sh” ist dasselbe, wie im Cam-Post:

#!/bin/bash
tvstat=$(tvservice -s |grep off)
if [[ $tvstat == *off* ]]; then
TV=OFF
else
TV=ON
fi

if [ "$1" == 'on' ] && [ "$TV" == "OFF" ]; then
/usr/bin/tvservice -p;
#fbset -depth 8;
#fbset -depth 16;
chvt 2;
sleep 1
chvt 1;
chvt 2;
chvt 1;
#echo 'Switched Screen ON!'
fi
if [ "$1" == 'off' ] && [ "$TV" == "ON" ]; then
/usr/bin/tvservice -o
echo 'Switched Screen OFF!'
fi

Nun noch in der /boot/config.txt den Wert gpu_mem auf 32 oder gar 16 stellen, rebooten, und wir haben wieder mehr als genug RAM. Dass die CAM nun nicht mehr funktioniert, sollte jedem klar sein – aber das war ja auch Sinn und Zweck der Sache.

Tagged with: • • • • • • • • • • • • • • •
Apr 26

1wire mit dem Pi

Allgemein, Linux, Wetterstation No Comments »

Ich betreibe hier seit über einem Jahrzehnt ein paar von diesen netten günstigen Dallas-1-Wire Dingern (DS1820) an einer Linuxkiste mit samt USB-Host-Adapter im sog. “Parasite-Mode” (Ausser GND und Data benötigt man da nichts, und kann ein paar von den Sensoren – an bspw. im Haus liegenden Telefonkabeln – abfragen).

Der USB-Host-Adapter ist eigentlich überflüssig, da der Pi das mit seinen GPIO’s von Haus aus kann. Und das ganze ist derartig trivial, dass ich es hier kurz erklären will. Man nehme:

  • den o.g. DS1820 (da gibts div. Variationen von, die sich in der Präzision unterscheiden – kosten ca. 2 Euro)
  • Einen Pi – mit Linux drauf.

 

Den 1820 wie folgt mit dem Pi verbinden:

GND auf GND // Vdd auf 3,3V // VDQ (Data) auf GPIO 4

(Hier eine Ansicht des 1820, und hier eine des GPIO-Ports vom Pi)

Dann ab auf die Shell und kurz 2 Kernel-Module nachladen:

 pi@rasbberrypi ~ $ sudo modprobe w1-gpio pullup=1
 pi@rasbberrypi ~ $ sudo modprobe w1-therm

Wenn alles richtig gelaufen ist, gibt es unter /sys/bus/w1/devices nun ein neues Verzeichnis mit der Unique-ID des 1820 (Die haben alle eine Art Mac-Adresse, die die einmalig macht) in dem wiederum eine Datei mit dem Namen “w1_slave” liegt. Angenommen der 1820 hat die ID “28-0000041234567” so heisst unsere Datei : “/sys/bus/w1/devices/28-000004593386/w1_slave”. Wenn man sich diese anzeigen lässt (zB via cat), kommt (etwas unsexy) der platte Temperaturwert als ASCII zum Vorschein.

Den hübschen wir nun noch auf, und schon haben wir einen Wert, den man weiterverarbeiten kann (snmp, website, wo auch immer):

cat /sys/bus/w1/devices/28-000004593386/w1_slave |\
grep -e 't=' | \
awk -F't=' '{print $2}'

Günstiger kann man keine Temperaturen messen – und erweiterbar und flexibel ist es auch noch. (Es sei denn man will unbedingt 100 Euro für das neueste, hippe, bunte Temperaturmessdevice, dass nur mit App läuft, ausgeben und die Werte alle Nasen lang in die Cloud pumpen…)

Tagged with: • • • • • • • • • • • • • • •
Dez 23

Statusscreen mit dem Pi und Bewegungserkennung

Linux No Comments »

Es ist mal wieder Zeit für ein kleines Urlaubsprojekt.
Hier lag seit 3 Jahren, neben einem RaspberryPi und nem alten 17″ Eizo-Screen, so ein Wandhalter für TFT-Screens herum. Da kann man doch was raus machen.

Also fix den Wandhalter an die Wand gedübelt und den Pi mit NFS-Root (siehe Eintrag hier) aufgesetzt.
Der Pi selbst ist mit dem Cam-Modul ausgestattet, und hängt per HDMI 2 DVI an dem o.g. Eizo.

Folgende Ziele habe ich verfolgt (und umgesetzt):
– Autologin nach reboot, sowie automatisches einloggen auf nem Server und attachen an tmux
– Sobald sich was vor der Cam bewegt, soll der Monitor “aufwachen”, nach 60s. wieder ausgehen.

Ist an sich recht einfach. Fangen wir mal mit dem Autologin an:
via /etc/inittab sagen wir dem Pi, dass er sich – anstelle des logins – auf dem tty1 als “pi” einloggen soll:

#1:2345:respawn:/sbin/getty --noclear 38400 tty1
1:2345:respawn:/bin/login -f pi tty1 /dev/tty1 2>&1

Dazu die obere Zeile auskommentieren, und die untere einfügen.
Nach einem reboot sollte der pi nun direkt auf der Shell als User “pi” landen.
Alles weitere (ssh-login) und Co. machen wir in der ~pi/.bashrc (letzte Zeile einfach anfügen)

ssh -t [user]@[machine wo tmux rennt] "tmux att"

Nun sollte nach dem Reboot (ssh-keys und laufender tmux auf “machine” vorrausgesetzt) direkt der tmux erscheinen. Den kann man dann vom “normalen” Rechner aus mit content bestücken (top, iftop, tail aufs log, etc.)

Wer noch Hintergrundbild und höhere Auflösung auf dem pi haben möchte, dem seit fbterm ans Herz gelegt.

Weiter gehts mit der “Motiondetection”. Dazu habe ich mir erstmal ein kleines Shellscript gebaut, welches den Monitor an/ausschalten kann, und dieses unter /usr/bin/screen.sh abgelegt:

#!/bin/bash
tvstat=$(tvservice -s |grep off)
if [[ $tvstat == *off* ]]; then
TV=OFF
else
TV=ON
fi

if [ "$1" == 'on' ] && [ "$TV" == "OFF" ]; then
/usr/bin/tvservice -p;
#fbset -depth 8;
#fbset -depth 16;
chvt 2;
sleep 1
chvt 1;
chvt 2;
chvt 1;
#echo 'Switched Screen ON!'
fi
if [ "$1" == 'off' ] && [ "$TV" == "ON" ]; then
/usr/bin/tvservice -o
echo 'Switched Screen OFF!'
fi

Nicht von den chvt verwirren lassen. mit tvservice wird der Monitor an/ausgeschaltet, mit chvt auf das entsprechende (Virtuelle) Terminal umgeschaltet. Quasi das Shell-pendant zu “ALT-F1 bis ALT-F10” zum Console wechseln. Ohne das hin- und herschalten via chvt geht der Moni zwar an, aber es wird nichts angezeigt.

Die eigentlich Motiondetection ist in Python gebastelt (wie üblich: Kurz und schmutzig):

#!/usr/bin/python
import StringIO
import subprocess
import os
import time
from datetime import datetime
from PIL import Image
threshold = 10
sensitivity = 180
monitor='on'

# Capture a small test image (for motion detection)
def captureTestImage():
    command = "raspistill -n -w %s -h %s -t 1 -e bmp -o -" % (100, 75)
    imageData = StringIO.StringIO()
    imageData.write(subprocess.check_output(command, shell=True))
    imageData.seek(0)
    im = Image.open(imageData)
    buffer = im.load()
    imageData.close()
    return im, buffer

def turnMonitorOn():
  global monitor
  monitor='on'
  subprocess.call("/usr/bin/screen.sh on", shell=True)

def turnMonitorOff():
  global monitor
  monitor='off'
  subprocess.call("/usr/bin/screen.sh off", shell=True)

# Get first image
image1, buffer1 = captureTestImage()
# Reset last capture time
lastCapture = time.time()
# added this to give visual feedback of camera motion capture activity.  Can be removed as required
while (True):
    # Get comparison image
    image2, buffer2 = captureTestImage()
    # Count changed pixels
    changedPixels = 0
    for x in xrange(0, 100):
        # Scan one line of image then check sensitivity for movement
        for y in xrange(0, 75):
            # Just check green channel as it's the highest quality channel
            pixdiff = abs(buffer1[x,y][1] - buffer2[x,y][1])
            if pixdiff > threshold:
                changedPixels += 1
        # Changed logic - If movement sensitivity exceeded then
        # Save image and Exit before full image scan complete
        if changedPixels > sensitivity:   
            print "change "+monitor
            lastCapture = time.time()
            if (monitor == 'off'):
                turnMonitorOn()
            break
        continue
    if (time.time()-lastCapture > 60):
  if (monitor == 'on'):
          turnMonitorOff()

    # Swap comparison buffers
    image1  = image2
    buffer1 = buffer2

Wenn man das Ding nun laufen lässt, macht es im dauerloop ein Bild in niedriger Auflösung von der Cam, und vergleicht die Helligkeitswerte mit denen des vorherigen Pics. Ist der Unterschied grösser als “threshold”, dann macht das Script den Monitor an. Nach 60s ohne Bewegung wird er wieder ausgeschaltet.
Jetzt nur noch das Script mit “start-daemon” in ein init.d Script packen und beim booten automatisch starten, und fertig.

Wie immer gibt es zig Wege dahin, dies ist nur einer von vielen. Das ganze kann man sicher noch immens optimieren. Für hier ist es mehr als in Ordnung.

Tagged with: • • • • • • • •
Mai 19

RasberryPi mit XBMC via NFS mit 32MB SD-Card

Fun, Linux 2 Comments »

Eigentlich hab ich mich ja immer gewehrt den schönen “Experimentiercomputer” RaspberryPi zum “MediaCenter” zu degradieren. Andererseits hatte ich ein wenig Not hier. Bis vor 2 Jahren hatte ich ‘nen MacMini am TV-Gerät. Der ist dann irgendwann rausgeflogen und musste einem AppleTV (3) weichen.

Dummerweise kann das ATV3 sich nur bei Apple bedienen. Sprich alle fein säuberlich gekauften Filme und MP3s auf dem Fileserver konnten nur umständlich abgespielt werden, in dem immer irgendein olles iTunes auf dem Arbeitsplatzrechner lief. Zeit das zu ändern. Also Pi bestellt und RaspBMC draufgeknallt. Erster Begeisterung folgte direkt die Ernüchterung. Zu langsam, und zu buggy. Wenn bspw. der Pi hängt, hilft nur noch Strom raus und wieder rein, was die SD-Karte mit “Could not mount Root-FS” oder so quittiert. Blöd alles. Doch es gibt eine Lösung für alles.

Ziel sollte es sein im Raspberry nur noch den Bootloader auf der SD-Karte zu haben (den braucht der leider, da der Pi kein Bootp/PXE beherrscht), und diese am besten auch noch mit ‘nem Schreibschutz zu versehen. Gesagt getan. Was ist also notwendig?

  • 2GB SD-Karte fürs erste Setup
  • 32MB SD-Karte für den späteren Betrieb
  • Fileserver mit NFS-fähigkeit
  • Irgend ‘ne Linux-Büchse um die Karten entsprechend zu präparieren (Mit OSX oder Windows ist das echt Schmerz)

Vorgehensweise:

  1. RaspBMC ganz normal auf der 2GB Karte installieren (dd if=[imagefile] of=/dev/sdz bsize=16M) wobei sdz das SD-Kartendevice ist.
  2. Rasbperry ans Netz hängen und booten/Erstkonfig durchführen.
  3. Während der konfiguriert setzen wir den NFS-Server auf (gehe mal davon aus, dass die Grundlagen zu NFS dem Leser bekannt sind)
    1. Directory, in dem das Rasberry-Rootfs wohnen soll erstellen (mkdir /rasberryrootfs)
    2. Directory in die /etc/exports aufnehmen:/rasberryrootfs          IP.VOM.RASP.BERRY(rw,async,no_root_squash,no_subtree_check,anonuid=65534,anongid=65534,insecure)
    3. exportfs -rv aufrufen
  4. Wenn Raspberry fertig, dann:
    1. per ssh einloggen (pi/raspberry)
    2. xbmc stoppen: sudo sudo initctl xbmc stop
    3. NFS-Filesystem mounten: mount IP.VOM.FILE.SERVER:/raspberryrootfs /mnt
    4. Kram umkopieren (sudo cp -axv /. /mnt/.
      sudo cp -axv /dev/. /mnt/dev/.      )
    5. In der /mnt/etc/fstab folgende Zeile AUSkommentieren (also ein “#” davorschreiben):
      /dev/mmcblk0p2  /               ext4    defaults,noatime 0       0
    6. NFS-Filesystem umounten (sudo umount /mnt)
    7. Raspberry herunterfahren (sudo init 0)
    8. Karte entnehmen und in die o.g. Linuxbüchse stecken, sowie das vfat-Filesystem der Karte mounten.
    9. Kram aus dem vfat-Filesystem irgend wo auf die Platte kopieren.
    10. Karte umounten / Brauchen wir jetzt nicht mehr.
    11. Jetzt die 32MB Karte in die o.g. Linuxbüchse stecken und ein vfat-Dateisystem auf einer Primären Partition vom Typ “MSDOS/VFAT” erstellen.
    12. Den Krempel aus 9 auf die Karte kopieren.
    13. Jetzt noch die Datei cmdline.txt auf der 32MB Karte wie folgt anpassen:
      dwc_otg.lpm_enable=0 root=/dev/nfs rootfstype=nfs nfsroot=192.168.1.100:/raspberryrootfs,v3 ip=192.168.1.49:192.168.1.1:192.168.1.0:255.255.255.0:rpi:eth0:off smsc95xx.turbo_mode=N noatime rootwait loglevel=1 zram.num_devices=2
      Wobei folgendes gilt:

      1. Anstelle der 192.168.1.49 die IP des Raspberrys eintragen
      2. Anstelle der 192.168.1.100 die IP des NFS-Servers eintragen
      3. Anstelle der 192.168.1.1 die IP des Routers eintragen
      4. Anstelle der 192.168.1.0 die Netztadresse des Heimnetzes eintragen
    14. Karte umounten
    15. In den Pi stecken, und freuen 🙂

Wenn alles klappt, noch den nupsi für den Schreibschutz an der 32MB Karte aktivieren, und dann geht das Filesystem dort garantiert nicht mehr kaputt. Noch ein paar Tipps/Anmerkungen zur Performance von dem XBMC:

  • Alle überflüssigen Visualisierung sollten (so schick sie auch sein mögen) deaktiviert werden.
  • Krimskrams wie Samba-Server, Avahi, ftp auf dem Pi auch deaktivieren.

Viel Spass damit.

Tagged with: • • • • • • • • • •
preload preload preload