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: • • • • • • • • • •
Jan 18

TTT – Trampel to Talk mit dem iCOM SM-30

Elektronik, Fun, Ham Kommentare deaktiviert für TTT – Trampel to Talk mit dem iCOM SM-30

Wenn es mal hektisch im PileUp wird, nervt es ziemlich, dass man die Hände nicht zum mitscribbeln/loggen frei hat.

Von einigen erfahrenen DXern hörte ich bereits von Fusspedalen. Kurz gegoogled und festgestellt dass es nichts bezahlbares “aus dem Regal” gibt. Aaaaaaber: Wofür hat man die Lizenz zum Löten? Selbstbau ist also angesagt. Vorweg: Der folgende Spaß hat unter 30 Euro gekostet.

Kurz mal das Innenleben und den Schaltplan des SM-30, sowie die iCOM-Steckerbelegung angesehen: Aha:

Wir wollen also Pin6 und Pin5 haben. Jetzt gibt es zwar fertige Kabel & Co. die die Pins herausführen, alllerdings scheinen da auch die Kontakte vergoldet zu sein – anders kann ich mir die Preise nicht erklären.

Mein Ansatz: Auf der Platine des SM30 ist ein Steckverbinder, wo alle Adern ankommen. Diese durchmessen. Bei mir war dann “blau” = PTT und der “obere schwarze” GND. An diese beiden Punkte habe ich mir eine Mono-3,5mm-Klinkenbuchse angelötet und diese im SM-30-Gehäuse festgeschraubt. Schaut dann so aus, und ist wirklich “minimalinvasiv” (Funktion des Mics in seiner Urform nachwievor gegeben):

Parallel habe ich mir – für einen schlanken Taler – einen Fusstaster für gerade mal 20 Euro geordert. Hier sollte man darauf achten, dass dieser möglichst schwer/massivst ist. In der Standardausführung kommt aus dem Taster eine Leitung mit drei Adern mit denen man den Taster wahlweise als “öffner” oder auch “schliesser” benutzen kann. Bei mir war “weiss” gegen “rot” die Schliesserfunktion. Sollte man – bei Nachbau – noch mal mit einem Multimeter prüfen. An das Ende der Leitung habe ich mir also einen 3,5mm Klinkenstecker gelötet und diesen dann in die neue Buchse des SM-30 gesteckt. Fertig ist der Fusstaster (TTT) mit dem man nun beim QSO die Hände frei hat.

Tagged with: • • • • • • • • •
Jan 12

Plattformübergreifendes HAM-Setup

Ham Kommentare deaktiviert für Plattformübergreifendes HAM-Setup

Ich mag kein Windows / Closed Source. Da mache ich auch keinen Hehl draus. Allerdings bringt das Hobby Hamradio da so einige Herausforderungen mit sich mit, da es viel Software leider nur für das Betriebssystem aus Redmond gibt. Zeit da mal etwas gegenzuwirken. Hier also ein grober Überblick über mein SetUp:

Abb. 1

Nun, womit haben wir es hier zu tun?

Alles was blau ist, läuft auf meinem Ham-PC (muss es jedoch nicht zwangsweise). Das Schöne daran: Alle Software kann auch unter Windows laufen, muss es aber nicht (Linux, MacOs geht genau so)

FLRig ist quasi die “Brücke” zum TRX. Unterstützt sehr viele Transceiver und bietet ein kleines aber feines UI, mit dem sich alle Dinge, die man am TRX einstellen kann, auch dort einstellen lassen. Zusätzlich bietet es die Möglichkeit eine Verbindung per TCP/IP (und nicht über (virtuelle) Serielle Schnittstellen) zu anderen Tools zu schaffen. Dazu im folgenden mehr:

CloudLogCat (für Windows) oder CloudLogCatQT (Linux/MacOs) ist ein Tool welches die aktuelle QRG und den Mode aus FLRig zieht und meinem Logbuchtool “CloudLog” bekannt macht. Man dreht also am VFO (Egal ob Hardware oder in der FLRig GUI) und im Log steht direkt alles richtig.

CloudLog selbst ist halt ein Logbuchprogramm, dass man selbst hosten kann. Benötigt wird PHP und ein wenig Linux-KnowHow, wenn man es “onPremise” hosten will. Muss man nicht, kann man auch als SaS für wenig Geld einkaufen.

DXHeat2FLRig habe ich selbst geschrieben. Es handelt sich um ein kleines Browserplugin, mit dem man eine Frequenz aus dxheat.com mit einem Click zum TRX “beamen” kann. Sehr hilfreich!

Für Freunde der DigiModes gibt es WSJT-X. Um nicht jeden Abend die ADIF-Logs aus WSJT-X per Hand in CloudLog hochzuladen, habe ich ein kleines Script modifiziert, was das quasi “live” übernimmt. Sprich: Nach jedem QSO wird automatisch über das kleine Helferlein das Logbuch befüllt.

Tagged with: • • • • • • • •
Sep 01

SDRConsole / Abbrüche beim TX / Buffer

Ham Kommentare deaktiviert für SDRConsole / Abbrüche beim TX / Buffer

Bei Direktverbindung des PC’s (SDRConsole) mit dem Adalm-Pluto (SDR) spielen beide Komponenten einwandfrei miteinander. Latenz ist erträglich (<=100ms) und auch sonst kommt es zu keinen Abbrüchen. Das jedenfalls war meine Erfahrung, wenn man das SetUp ausserhalb des Heimnetzwerks “portabel” betreibt. (Macht übrigens Spass).

Im LAN hier daheim allerdings gab es immer wieder “stuttering”, “cut off transmissions”, “TX Problems” die sich dadurch bemerkbar gemacht haben, dass der TX-Stream immer mal wieder für 100-300ms abreisst.

Erster Workaround: In der Console auf “Half-Duplex” umschalten. Ist allerdings eher suboptimal, da die AFC in der Zeit, in der gesendet wird, nicht arbeiten kann. Ausserdem will man ja ggf. auch mal sein eigenes Signal prüfen.

Abhilfe brachte dann der Tip von DG7YEO (Elmar), doch mal in den Settings der (Managed-)Switches im LAN zu schauen. Eine fast vergessene Funktion (802.3x – FlowControl), die man eigentlich nur noch aus 10MBit-HalfDuplex-Zeiten kennt, soll – bei Aktivierung – das Problemchen lösen.

Genau so war es dann auch. 802.3x auf den relevanten Ports aktiviert, und siehe da – die Probleme sind fort.

Tagged with: • • • • • • • • • •
Nov 16

POSTDATA mit mod_perl im Falle von chunked Posts

Allgemein, Linux, Work Kommentare deaktiviert für POSTDATA mit mod_perl im Falle von chunked Posts

Eure modperl2-Scripte verschlucken im Legacy-Mode (CGI-Emulation) POSTDATA wenn der Client den Payload mit “Transfer-Encoding: chunked” abkippt und ihr diesen per “my $payload=$cgi->param(‘POSTDATA’)” einsammelt?

Probiert mal folgendes: ($r ist das Apache::RequestRec-Object, dass Ihr per “shift” am Anfang des Scripts einsammelt könnt)

        my $content = '';
        my $cnt=0;
        my $offset=0;
        do {
                $cnt = $r->read($content,8192,$offset);
                $offset += $cnt;
        } while($cnt > 0);

Bei mir hats geholfen. Wenn man den Payload per read einsammelt, dann “dechunked” mod/perl den Kram automagisch.

Tagged with: • • • • • •
Apr 15

LongMessages vs Concatenated via SMSC

Linux, Netz, Work No Comments »

Kurzer Merker für mich (Bezgl.: Endgeräte werden in bestimmten Konstellationen bei überlangen SMS zugespammt.)

Beim Versand von SMSsen über UCP/EMI (Command 51) gibt es zwei Möglichkeiten wie man mit “überlangen” SMS (>160 GSM-Chars) umgehen kann:

  1. Concatenated Messages. Man teilt die Messages in 160er Chunks auf und sendet im UDH (User Data Header) folgendes für die Einzelteile:
    1. 0x00 = Concatenated Message
    2. 0x03 = Länge des Infoelements (Folgt jetzt)
    3. 0xC0 = Referenz-ID (kann ausgewürfelt werden. Ist Unique auf Receipient und diese ID)
    4. 0x02 = Anzahl der einzelnen Mulitpart-SMSsen
    5. 0x01 = Diese Message ist Part 1 von dem was in Byte 4 steht.
  2. LongMessage (Feature muss SMS-C seitig aktiviert sein). In dem Falle geht das Ding mit dem Standard UDH in einem Block raus (Maximale Länge ist beim SMSC zu erfragen – in meinem Fall waren 550 Chars durchaus machbar)

So, und nun wird es spannend.

Acknowledgehandling

Im Fall 1 wird

  • jeder einzelne Part fein vom SMSC eingequed,
  • ans SS7 überstellt und
  • für jeden einzelnen Part ein ACK generiert – SS7 generiert das Acknowledge, wenn die (Teil-)Message beim Empfänger angekommen ist, und übergibt das ACK dann ans SMSC welches dieses per UCP/EMI an mich weitergibt.

Das ist ne ziemlich zeitaufwendige Angelegenheit, die man wirklich extrem spürt. Der Durchsatz SMS/sec ist halt nur 1/n so groß wie wenn ich nur eine 160er Nachricht versende (n=Anzahl der Parts).

Fall 2 ist da schon (vermeintlich) eleganter. Wir überstellen den “Blob” ans SMS-C und bekommen (bei erfolgreicher delivery) genau ein ACK zurück. Und hier liegt der Hase im Pfeffer. Aufgefallen ist mir das ganze, weil es Empfänger gibt, die sich bei mir über nicht aufhörend wollende SMSsen beschwert haben (Empfänger bekommt die selbe SMS wieder und wieder. Hört so gut wie nicht auf. 2000 sind keine seltenheit). Also der Sache auf den Grund gegangen:

  1. die LongMessages werden per UCP/EMI mit ACK-Req (ohne geht nicht) ans SMSC übergeben.
  2. SMSC schiebt die LongMessage ans SS7 durch.
  3. SS7 merkt “Oh, ne LongMessage” und splitted die in 160er Chunks (Auch wenn es LongMessages gibt. GSM/SMS kann – egal wie – nur 160er Chunks)
  4. Gleichzeitig schiebt das SS7 ein(!) ACK ans SMS-C zurück, wenn der erste Part zugestellt wurde.
  5. ACK kommt via UCP/EMI bei mir an

Schaut man sich das jetzt genauer an, stellt man fest, dass das ACK schon beim ersten erfolgreichen Zustellversuch des ersten Chunks kommt. Jetzt gibt es da draussen irgendwelche irren Endgeräte, die das ACK in genau diesem Fall nicht sauber senden. Mit dem unschönen Nebeneffekt, dass das SMSC für die nicht geackten Chunks immer wieder dem SS7 auf die Füße tritt (“Send nochmal”). Je nach unglücklicher Konstellation ist das Endgerät nun in einem ewigen loop.

Fragt mich bitte nicht, warum das im Fall 1 nicht auch passiert. Laut meinem SMSC Kontakt liegt es am Zusammenspiel SMSC/SS7. Einzige Abhilfe war, alles auf MuPart umzustellen. Mit all den häßlichen Nebenwirkungen bezgl. Durchsatz und Co.

Ich denke die einzige Alternative dagegen wäre es, sich selbst ein SS7-Account zu besorgen. Ob man das aber will (zum rumspielen bestimmt mal gerne – aber produktiv)…

 

Vielleicht hat ja einer meiner Leser da ein paar mehr Hintergründe (Jetzt bitte kein: Nimm doch SMPP. Hat sich nämlich rausgestellt, dass überall wo “Simple” im Protokollnamen vorkommt, es alles andere als Simpel ist. Stehe nicht so auf irre XML/SOAP-Requests)

Tagged with: • • • • • • • • • • •
Mai 25

MX Master Scrollwheel unter Linux

Linux 1 Comment »

Die Logitech MX-Master ist eine echt nette Maus, die ich im täglichen Job schon seit letztem Jahr nutze. Unter Linux gefiel mir allerdings das Scrollverhalten der Ratte nie so richtig (zu langsam). Zeit sich damit mal auseinander zu setzen. Alle Ansätze mit “installiere imwheel” oder irgendeine andere Zusatzsoft waren nicht zufriedenstellend. Da ich eh mit xbindkeys arbeite muss es auch damit gehen. Die Lösung dazu also wie folgt:

Über die ~/.profile remappen wir die “Buttons” die beim betätigen des Scrollwheels (Bt. 4 und 5) gefeuert werden auf die nicht existenten Buttons 10 und 11:

logitech_mouse_id=$(xinput | grep "Logitech MX Master" | sed 's/.*id=([0-9]+).*/1/')
xinput set-button-map $logitech_mouse_id 1 2 3 10 11 6 7 8 9

In die ~/.xbindkeysrc folgendes (Handler, der auf den virtuellen Mousebuttons 10 und 11 – die wir vorher remapped haben, das Scrolling legt):

# Mouse Scroll up
"xdotool click --repeat 3 --delay 1 4"
b:10

# Mouse Scroll Down
"xdotool click --repeat 3 --delay 1 5"
b:11

Tagged with: • • • • • • • • • • • •
Apr 23

Websockets behind Apache

Linux, Work No Comments »

node.js ist nett. Vor allem, wenn man auf WebRTC/Sockets setzt. Komplex wird es, wenn man das ganze hinter einem Apache betreibt. Habe jetzt 2h damit verbracht die WS irgendwie an den internen node prozess weiterzuleiten, ohne dass socket.io sich verschluckt. Damit nicht der Nächste vor dem selben Problemchen steht und Stunden versenkt, hier der relevante Teil der apache-conf:

Annahmen:

  • Der interne node.js-prozess horcht auf Port 6543
  • Alles was Websocket ist, wird via /socket.io abgewickelt und hat auch den Transportheader auf “websocket”

<IfModule mod_proxy.c>
  RewriteEngine On
  ProxyVia On
  ProxyRequests Off
  ProxyPreserveHost on
  
  RewriteCond %{REQUEST_URI}  ^/socket.io            [NC]
  RewriteCond %{QUERY_STRING} transport=websocket    [NC]
  RewriteRule /(.*)           ws://internal.etherpad.ip:6543/$1 [P,L]
  ProxyPassReverse /socket.io ws://internal.etherpad.ip:6543/socket.io
  
  RewriteCond %{REQUEST_URI} !^/p/
  RewriteCond %{REQUEST_URI} !^/static/
  RewriteCond %{REQUEST_URI} !^/ep/
  RewriteCond %{REQUEST_URI} !^/minified/
  RewriteCond %{REQUEST_URI} !^/api/
  RewriteCond %{REQUEST_URI} !^/ro/
  RewriteCond %{REQUEST_URI} !^/error/
  RewriteCond %{REQUEST_URI} !^/jserror
  RewriteCond %{REQUEST_URI} !/favicon.ico
  RewriteCond %{REQUEST_URI} !/robots.txt
  
  ProxyPass / http://internal.etherpad.ip:6543/ 
  ProxyPassReverse / http://internal.etherpad.ip:6543/
  <Proxy *>
    Options +FollowSymLinks -MultiViews
    AllowOverride All
    Order allow,deny
    allow from all
  <Proxy>
<IfModule>

Tagged with: • • • • • • • • •
Feb 28

WS2812B Wecker

Elektronik No Comments »

Lange nichts mehr aus der Welt der Elektronik hier gepostet. Also dann mal 🙂

Es gibt seit 2-3 Jahren 5050-LED-Stripes (oder auch einzelne LEDs) mit aufgelötetem Controller (in SMD). zB diese hier. Das Coole an den Dingern ist, dass die über 3 Anschlüsse verfügen (+5V/GND Data-In, bzw. Data-Out) und man mit diesen 3 Anschlüssen zig Stück aufmal ansteuern kann. Technisch funktioniert die Schnittstelle so, dass man auf den D-In-Port des Strips ein 800kHz-Signal gibt, mit dem man dann jeder LED einzelnd den R/G/B-Wert mitgeben kann. Lauflichter, Uhren, alles was sich blinkt und bewegt sind damit also kein Problem. In der Community gibt es zig Libraries, die das Leben mit dem Ding etwas einfacher gestaltet. Hervorheben möchte ich die FastLED-Lib. Die ist zwar relativ gross (Ein Arduino/ATMEL mit min. 16kB Flash sollte es schon sein), man hat dafür aber an nahezu alles gedacht.

Im Code werden die LEDs per Array angesteuert. Das ist quasi ein Array of Arrays (untendrunter liegen noch jeweils 3 Elemente für RGB).

Jetzt hat der Arduino/ATMel als solches ein kleines Problem mit der Genauigkeit der internen Uhr. Um das zu umschiffen, gibt es RTC’s die per SPI ansteuerbar sind. 5er Pack am Fluss für ca. 10 Euro. Die Dinger sind deartig Präzise, dass ich – nach jetzt 1,5Monaten keinerlei (sichtbare) Abweichung feststellen kann. Zum Vergleich: Ohne RTC lief der Arduino nach etwa 24h um 30sek. falsch. Klar kann man versuchen den mC mit ein paar Tricks (bspw. dem OSCCAL) zu eichen. Aber sobald sich die Umgebungstemperatur ändert, war es das auch wieder.

Nun, was kommt raus? Kombiniert man, die bei Adafruit erhältlichen, 2812-Viertelkreise mit einem Arduino Pro micro, IKEA-Bilderrahmen, ein wenig Handarbeit und einem externen(!) 5V-Netzteil (die LEDs saugen da etwas) eine nette Uhr:


Den entsprechenden Code (schmutzig, as usual 🙂 ) hab ich mal bei  github abgelegt.

Tagged with: • • • • • • •
Feb 13

Keyboard / 60%

Allgemein, Fun 1 Comment »

Zuletzt hab’ ich mir vor ca. 9Jahren radikales Umlernen angetan. Damals bin ich von dem German-Keyboard Layout auf US-ANSI umgestiegen. Die Sonderzeichen zum Coden waren einfach viel leichter zu erreichen. Waren etwa 3 Wochen Schmerz, danach lief es wie am Schnürchen. Ich will auch nicht mehr mit nem deutschen Keyboard arbeiten 🙂

Einzig die Eigenheiten von OSX/Linux/Windows haben etwas genervt (Win: Layout per ALT-SHIFT_L umschalten um Umlaute tippern zu können // OSX: Sehr angenehm per Modifier-Key (Mod-” und dann a,u oder o))

Dummerweise ist mein Model-M damals auf der Strecke geblieben, und musste einem Mac-Keyboard weichen. Hab zwar noch mal ein paar Anläufe gestartet, und die Keycaps auf US-INTL gewechselt, war aber irgendwie nichts…

Nun ist es mal wieder an der Zeit etwas neues auszuprobieren. Ein 60% Mechanical-Keyboard. Ca. 2 Monate bin ich um das HHKB herumgetingelt und hab mich am Ende dann doch gegen das Teil entschieden. Hängengeblieben bin ich Schlussendlich beim Vortex Pok3r, für knapp 150Euro – nicht gerade billig.

vortex

Gut, was gibt es fürs Geld?

  • MX-Schalter (in jeglicher Ausprägung, meine Wahl fiel auf blues)
  • Backlight.
  • Ordentliche (+replaceable) Keycaps.
  • 4 Layer, die schnell umschaltbar sind und bis auf einen frei programmierbar sind (ohne Treiber, oder sonstigen Foo). Die Programmierung lässt, neben Makros, die freie Belegung von Tasten zu.
  • Alu-“Wanne” in der die Tastatur befestigt ist.
  • Austauschbare USB-Strippe (Die Poker 3 selbst verfügt über einen Mini (NICHT Micro!) USB Port)
  • All in all: Eine extrem wertige Tastatur (und wenn ich wertig sage, meine ich das auch. Also wertig im Sinne von: “MacBook Unibody ist gut verarbeitet…”.
  • 500g solide Tastatur halt.

Was gibt es nicht, bzw. was macht den Reiz aus?

  • F-Tasten – die fehlen komplett. Sind aber bspw. per “FN+1” (=F1) erreichbar. Das hatte ich mir persönlich schwieriger vorgestellt. Klappt aber super.
  • Multimedia-Keys. Hab ich – bis auf Laut/Leise – eh immer für extrem überflüssig gehalten. Am besten noch ‘ne EMailtaste, oder wie? Dank der Programmierbarkeit kann man sich den Kram auch auf FN+Irgendwas legen.
  • Cursor-Tasten. Das ist – ehrlich gesagt – der grösste Einschnitt. Ich kämpfe nun nach ca. 3 Tagen immer noch. Da ich recht viel im vim Arbeite, habe ich mich dazu entschieden das Cursormovement auf HJKL zu legen. Jetzt rächt es sich, dass ich Jahrelang im vi mit den “normalen” Cursorkeys navigiert habe. Gut, das wird sicher schon. Alternativ kann man sich, wenn man viel navigieren muss, immer noch die Cursortasten nativ (also ohne FN) auf Layer2 und dann WASD legen. Ein nettes Feature, dass ich gestern Abend erst entdeckt habe: R_ALT+Space macht R_CTRL,PN,FN und R_SHIFT zu Cursortasten. Nochmal auf R_ALT+Space gedrückt, und die Tasten sind wieder das, womit sie beschriftet sind.
  • Der gesamte Block Home/End/PgUp/PgDn fehlt ebenfalls. Auch hier übe ich noch mit FN+N (zB für End).

Das Teil macht derartig laune, dass ich gar nicht aufhören möchte zu tippen. Man wird auch echt kreativ damit (das war ja der Zweck des Spiels). Bspw. habe ich mir für den Chrome das vimium-Plugin installiert. Mit dem Teil bedient man den Chrome weitesgehends per Keyboard über die bekannten vim-KeyBindings. Das auf der Bash “set -o vi” da schon obligatorisch ist, versteht sich vermutlich von selbst 🙂

Wer sich also selbst mal wieder einen Tritt verpassen will, um vielleicht mehr vim-Keybindings in den Kopf zu bekommen, mehr Platz auf dem Schreibtisch zu haben, Rechnerunabhängige Makros bauen will oder auch einfach nur eine extrem feine mechanische Tastatur sein Eigen nennen möchte, dem sei die Pok3r ans Herz gelegt.

Weiterführende Links? Klar:

  • Reddit-Post, in dem beschrieben wird, wie man das Ding möglichst vim-gerecht umkonfiguriert.
  • Hersteller (Vortex) – dort gibt es manual und firmware-update – Treiber sind, wie oben beschrieben – nicht notwendig.
  • Vergleich der verschiedenen MX-Schalter.
  • Blog über mechanische Keyboards (gute Einstiegsmaterie)

[Update 28.02.2015]

So, nun habe ich das gute Stück seit ca. 2 Wochen. Was soll ich sagen? Jedesmal, wenn ich eine Rubberdome in den Fingern habe (auch so ein flaches Apple-Dings), denke ich: OMG! Mit anderen Worten ausgedrückt gewöhnt man sich sehr schnell (wieder) an mechanische Tasten. Einzig das Profil der KeyCaps ist etwas ungewohnt. Liebäugele momentan mit DSA-KeyCaps (z.B. diese hier von Signature Plastics). Haken ist: Der Markt für Caps existiert – ernstzunehmend – scheinbar ausschliesslich in den Staaten. In Europa bekommt man nur Ducky/Shiny-Caps. Die mögen für Gamer recht sein, für “Vieltipper” nicht.

So richtig geblickt habe ich das mit den unterschiedlichen Profilen aber noch nicht. Bei Logitech gibt man die Profile in “R”ows an, bei SP in DSA, SA, usw. Ein guter Anlaufpunkt, bei dem man aber definitiv Geduld mitbringen sollte, ist massdrop. Massdrop ist so eine Art Genossenschaftseinkauf. D.h. mehrere Interessenten schliessen sich zusammen, und wenn 200 Leute zusammengekommen sind, geht man auf den Hersteller zu, sodass dieser eine Kleinserie auflegt. Mal schauen, ob da was für mich dabei ist.

Tagged with: • • • • • • • • • • •
Dez 13

ipv6 via SIXXS und Telekom // Multihoming

Linux, Netz No Comments »

Hat man zwei ipv6-uplinks ist es wichtig, dass Connections die über Provider “A” reinkommen, auch über Provider “A” wieder rausgehen. Mit den default-settings ist das nicht der Fall. Wenn dort etwas via “A” reinkommt, die default-route aber “B” ist, versucht der Router die Antwortpakete via “B” rauszurouten. Das geht idR schief, da der ISP meint man würde die IP faken. Aber es gibt Abhilfe:

Folgendes SetUp nehmen wir mal an:

ppp0 (Telekom): 2003:1::2 mit aktiver default gw ppp0
eth0 (sixxs): 2001:2::2 mit NICHT aktiver default-GW 2001:2::1

Alles was nun via eth0 (hinter dem der sixxrouter irgendwo hängt) reinkommt, will linux via ppp0 beantworten.

Lösung: Eine rule anlegen:

echo "100 sixxs" >> /etc/iproute2/rt_tables
/sbin/ip -6 rule add from 2001:2::/64 lookup sixxs
/sbin/ip -6 route add default via 2001:2::1 dev eth0 table sixxs

Der Output von route und rule sollte am Ende dann wie folgt aussehen:

router:~# ip -6 rule
0:  from all lookup local 
16383:  from 2001:2::/64 lookup sixxs 
32766:  from all lookup main

router:~# ip -6 route
2001:2::/64 dev eth0  proto kernel  metric 256 
2003:1::2 dev ppp0  proto kernel  metric 256 
default via fe80::10ca dev ppp0  metric 1024  initcwnd 10 initrwnd 10

router:~# ip -6 route list table sixxs
default via 2001:2::1 dev eth0  metric 1024

 

Tagged with: • • • • • •
Mai 31

Ganze Netze bei ipv6 mit fail2ban blocken

Allgemein, Linux, Netz No Comments »

ipv6 ist nett. Aber der User bekommt halt jedes mal idR ein /64 Subnet. Für so Tools wie fail2ban, die einzelne IPs blocken, wenn irgendetwas komisches auftaucht irgendwie schlecht. Der Angreifer schnappt sich halt irgendeine neue IP, denn die unteren 64bit stehen ja voll zu seiner Verfügung.

Jetzt verhält es sich mit dem originalen fail2ban so, dass das nicht mal ipv6 kann. Zeit sich auf die Suche zu machen. In einem github-Repo bin ich fündig geworden. Der gute Mensch hat fail2ban so erweitert, dass es v6-fähig wird. Also flugs mal installiert, um direkt die Ernüchterung zu spüren: Es blockt mit /128 🙁

Also erweitern:

Die /etc/fail2ban/action.d/iptables-46-multiport-log.conf passen wir wie hier in diesem gist sichtbar an. Hinzugekommen ist lediglich <mask> bei der ban und unban-Regel sowie unter init. Das bedeutet, dass – sofern nicht anders angegeben – immer eine /32er CIDR-Mask gelegt wird, also die gesamte v4-IP (bei v6 halt ebenfalls /32 – aber dazu später mehr) geblockt wird.

Da die fail2ban-Variante von “usrweiss” im Wrapperscript nicht so granular zwischen v4 und v6 differenzieren kann, als dass wir da andere cidr-Masken drauflegen könnten, legen wir einfach in der /etc/fail2ban/jail.conf ZWEI Jails an:

[web_v4]
enabled = true
filter  = web_v4
action = ip64tables-multiport-log[name=web_v4, protocol="tcp", port="80,443", mask=32]
logpath = /var/log/apache2/web_f2b/fails.log
maxretry= 5
bantime = 60
findtime= 60

[web_v6]
enabled = true
filter  = web_v6
action = ip64tables-multiport-log[name=web_v6, protocol="tcp", port="80,443", mask=64]
logpath = /var/log/apache2/web_f2b/fails.log
maxretry= 5
bantime = 60
findtime= 60

Die benötigen wiederrum auch 2 Configs in der /etc/fail2ban/filter.d:

/etc/fail2ban/filter.d/web_v4.conf:

# Fail2Ban configuration file
#
#
# $Revision: 250 $
#

[INCLUDES]

[Definition]

failregex = Applikation: v4 (<HOST>) Detaillierte Fehlermeldung .*

/etc/fail2ban/filter.d/web_v6.conf:

# Fail2Ban configuration file
#
#
# $Revision: 250 $
#

[INCLUDES]

[Definition]

failregex = Applikation: v6 (<HOST>) Detaillierte Fehlermeldung .*

Der Haken ist, dass unsere Applikation, die die Events auslöst (hier eine Loginseite, die die Fehlversuche nach /var/log/apache2/web_f2b/fail.log wegschreibt) an die Zeile dranschreiben muss, ob es sich um v4 oder v6 handelt. Bezogen auf die o.g. Configs sieht das in dem fail.log der App so aus (Von der Applikation generierte Einträge. Erster: v6, zweiter v4)

[May 31 10:08:12] Applikation: v6 (2a03:2880:2130:cf05:face:b00c:0:1) fehlerhafter Loginversuch blabla
[May 31 10:09:12] Applikation: v4 (173.252.120.6) fehlerhafter Loginversuch blabla

Von nun an blockt fail2ban die Ports 80 und 443 sobald in der Logdatei der Applikation (/var/log/apache2/web_f2b/fail.log) 5 mal innerhalb von 60 Sekunden die selbe IP mit einem Fehler aufschlägt für 60 Sekunden. Und zwar bei einer v4 halt die v4, bei einer v6 das /64er Subnet der v6. Die gerade greifende Netzmaske wird in der/etc/fail2ban/jail.conf als Variable “mask” in der action mit angegeben – sollte dort nichts stehen, gilt der Defaultwert von /32 aus der iptables-46-multiport-log.conf

 

Wie üblich, geht das sicherlich noch eleganter. Bin gespannt, wann fail2ban endlich eine v6-Variante releast.

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: • • • • • • • • • • • • • • •
Mai 02

Beonderheiten des Mobilen Internets

Netz No Comments »

Für mich selbst als Merker, damit ich das nächste mal nicht wieder in Panik ausbreche.

Besonderheiten beim “Internet” via Telekom Hotspot:

  • Öffentliche IP’s gibt es per se nicht – man bekommt irgendwas privates aus dem 10er-Space zugewiesen.
  • V4 only
  • Jede Ziel-IP (egal ob Online oder Offline) ist aus dem Hotspot-Netz ein DNS-Server. Führt zu leichten Panikattacken, wenn man meint seine eigenen Kisten von aussen damit auditieren zu wollen. Vermutung: Alles was auf Port 53 rausgeht, wird von der T abgefangen und dann unter falscher Flagge beantwortet, als wäre es ein openrelay.

Besonderheiten beim “Internet” via Telekom LTE:

  • Öffentliche IP’s gibts mit LTE nicht mehr (LTE akzeptiert ausschliesslich “internet.telekom” oder “internet.t-mobile” als APN – und da gibts halt nur “Private-Address-Space”)
  • v4 Only
  • Port 80 und Port 8080 unterliegen irgendeiner Art Deep-Packet-Inspection (kann nur raten, ob das was mit diesem Zwangsproxy zu tun hat, der jpgs/gifs noch mal nachkomprimiert hat). Fakt ist: Egal ob die Ziel-Adresse offline ist, oder gar keinen Dienst auf den beiden Ports anbietet – es gibt IMMER einen sauberen 3-Wege Handshake. Interessant in dem Zusammenhang: Irgendein Netzelement leitet die Anfragen (so denn die “Echte Ziel-IP” online ist, und auch n Listener hat) mit leichtem Delay an die Richtige IP weiter. Wenn Ziel-IP offline / kein Dienst, gibts ein “FIN” per TCP – aber erst nach erfolgtem SYN/SYNACK/ACK.
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: • • • • • • • • • • • • • • •
Previous Entries
preload preload preload