Beiträge von sparkie

wuerde mich interessieren inwieweit die CPU bereits am Anschlag ist wenn Daten ueber 2 Ethernetports mit jeweils 1 Gbit geforwarded werden (z.B. mit iptables) Welches Standard OS laeuft da eigentlich drauf? Oder braucht man wieder irgendeine Spezialvariante?

- sparkie

wer den RPi unbedingt komplett ausschalten (und remote auch wieder anschalten will - quasi als WOL Ersatz) macht das z.B. mit Komponenten des FS20 Systems:

dieser hier: ELV FS20-UART Sender FS20 US, Komplettbausatz | ELV-Elektronik passt noch locker in das RPi Standardgehause und kann direkt auf die GPIOs aufgeloetet werden. Damit kann sich der RPi beim Runterfahren eigenstaendig Mithilfe der ELV Funk-Schaltsteckdose FS20 ST | ELV-Elektronik abschalten. Clean Shutdown wird z.B. durch verzoegertes Abschalten per 30s Timer Feature der Schaltsteckdose- geloest.

- sparkie

ich kapier' nicht wo das Problem ist. EInfach aus

/lib/udev/rules.d/75-persistent-net-generator.rules:
[...]
KERNEL!="eth*|ath*|wlan*[0-9]|msh*|ra*|sta*|ctc*|lcs*|hsi*", \
[...]

das eth* rauspatchen - fertig

KERNEL!="ath*|wlan*[0-9]|msh*|ra*|sta*|ctc*|lcs*|hsi*", \

entspricht zwar nicht mehr der urspruenglichen Philosophie hinter den Regeln, aber verhaelt sich genau so wie vom TO gewuenscht.

Wenn's schee macht

- sparkie

und auf dem RPI laeuft was - statt dem Xserver? was sagt denn 'xset q'? Funktioniert das vielleicht?

da hilft nur nen kleiner Binary-Patch im master boot:-)

ccontavalli/grub-shusher · GitHub

Zitat von gehlhajo

Das mit dem Rüberkopieren der Binaries auf dem RPI wurde aus Deinem ersten Post nicht ganz klar.

sorry, meine Beschreibung ist ja auch wirklich etwas duerftig:-) war nur als Hinweis gedacht wie es so ungefaehr gehen koennte.

Zitat von gehlhajo

Da ich aber meine (selbst gelötete) Peripherie über i2c-Bus ansteure hilft mir eine chroot Umgebung nicht wirklich weiter. Aber für große (GUI) Projekte sicherlich sinvoll...

verstehe ich nicht. Ich mache nur Hardwareentwicklungen mit dem RPI. Natuerlich alles in CLI. GUIs sind mir ein Graus.

Ein SD Image muss man im Normalfall nur einmal generieren. Im weiteren Verlauf mache ich alle Aenderungen in meiner Raspbian-chroot Umgebung und kompiliere nur dort. Anschliessend werden die Binaries (ohne Source natuerlich) automatisiert per rsync auf den RPI gebracht - fertig. Geht alles ruckzuck. Und sollte der Super-GAU eintreten und die SD Card mal geschrottet werden - kein Problem. Der Master ist ja auf dem Entwicklungrechner.

- sparkie

die optimalste Methode fuer den RPI zu entwickeln geht IMHO ueber eine chroot-Umgebung auf einem schnellen Rechner. Dort kann man sich nach Lust und Laune seine Entwicklungsumgebung einrichten. Zudem wird so bei Bedarf das Kernel-Kompilieren in endlicher Zeit fertig. Der RPI selbst ist fuer solche Aktionen einfach nicht gedacht. Hat man alles zum Test fertig baut man sich ein eigenes SD Image und bootet das vom RPI.

Eine Super-Beschreibung was im einzelnen zu tun ist findet sich hier:

build your own basic Raspberry Pi Debian image | Hödlmosers' Hard- and SoftwareCuisine

Insbesondere das Script wie man ein eigenes SD Image bauen kann ist sehr lehrreich fuer denjenigen der sowas zum ersten Mal macht.

- sparkie

Zitat von _Martin_

Daher war ich auf der Suche nach einen günstigen root-Server, diese liegen aber außerhalb meiner Preisklasse

wie waer's mit einem Atom-Server fuer 25EUR/monat bei ip-projects.de?

IP - Projects - Root-Server Privat Atom
evtl. ist es bei den Restposten sogar noch guenstiger:
Foren: Angebote | IP Projects - Forum

...und schon hast du dein eigenes mini-itx (Intel® Atom™ D525) Board mit vernuenftiger hardware dran. Ueber den Rescue - Boot kannst du jedes beliebige System from Scratch neu aufspielen. Bei mir ist das ein debootstrapped Debian-wheezy (was sonst )

Ich bin seit 2012 Kunde dort und kann ip-projects.de nur empfehlen. Sehr freundlicher Support und Super-kurze Reaktionszeiten Anfragen.

Der RPI waere mir als Root-Server etwas zu windig obwohl ich fuer den Hausgebrauch von dem Teil absolut begeistert bin:-)

- sparkie

fuer Hausautomatisierung verwende ich normalerweise ELV Produkte. Speziell mit Rollaeden habe ich aber keine Erfahrung.

Rollläden automatisieren | ELV Elektonik

Rollladen / Markise | ELV-Elektronik
Rollladen | ELV-Elektronik

fuer den RPI gibt es fuer die FS20 Serie diesen genial kleinen Sender:
ELV FS20-UART Sender FS20 US, Komplettbausatz | ELV-Elektronik

den kannst du direkt an die serielle Schnittstelle und die 3V3 Stromversorgung am P1 des RPI anschliessen. Fertig ist die eigene CCU.

- sparkie

na dann

Zitat von mike777

Du meintest wohl über Rechner B auf Rechner A, oder?

danke ja, habe es oben korrigiert

Zitat

Das sind ja erst mal zwei verschiedene ssh-Sessions auf B ... Kann ich die koppeln?

nimm dir einfach drei Rechner zum Testen

home (heimrechner)
server (vserver)
remote (dein laptop fuer unterwegs)

auf Maschine 'home' rev-tunnel nach 'server' einrichten:

@home:~> ssh -R 444:localhost:22 server

von Maschine 'remote' aus auf dem 'server' einloggen:

@remote:~> ssh server

wenn du jetzt auf dem 'server' bist die oben aufgebaute rev-tunnel Verbindung zu Maschine 'home' nutzen:

@server:~> ssh -p 444 localhost

und schon bist du auf der 'home'. Fuer den taeglichen Gebrauch kann man alles natuerlich automatisieren.

das Ganze hat den Vorteil, dass man so Kruecken wie 'dyndns' & Co. erst gar nicht braucht. Denn alle abgeschotteten Ziel-Rechner auf die du vom Internet aus zugreifen willst sind anhand der bekannten Portnummer (im Beispiel 444) identifizierbar.

Solange du den Reverse-Tunnel von 'home' -> 'server' bauen kannst ist alles gegessen. Egal ob 'home' vom Provider nur eine private IP-Addresse bekommt oder wie ueblich abgeschottet hinter einer Firewall liegt.

- sparkie

dann logge dich (automatisiert) von deinem Heimrechner A per ssh auf einem Rechner deines Vertrauens B im Internet ein. Mit dieser ssh richtest du nebenbei per '-R' Option einen Reverse-Tunnel vom Rechner B auf A ein. Ab jetzt kannst du dich von ueberall im Internet ueber Rechner B auf Rechner A einloggen. Funktioniert immer. Auch z.B. wenn Rechner A nur ueber eine Mobilfunkverbindung mit privater IP Adresse angebunden ist. Also wie in deinem Fall von aussen nicht erreichbar ist. Fuer Rechner B eignet sich z.B. ein vserver/root-server mit oeffentlicher IP Adresse.

- sparkie

Zitat von nobanzai

wie meinst du das?

wenn du schreibst

's/(\s+)0+([0-9]+)$/\1\2/'

dann ist nicht eindeutig, welche Nullen zu '0+' oder bereits zu [0-9]+ zaehlen sollen. Deswegen ist es besser zu schreiben

's/(\s+)0+([1-9][0-9]*)$/\1\2/'

Zitat von nobanzai

Oder?

stimmt auch noch nicht ganz:-) weil nicht eindeutig ist wieviele Nullen unterdrueckt werden sollen.

Zitat von nobanzai

var=$( echo "$text" | sed -r -e 's/(\s+)0+([1-9]+)/\1\2/g' )

dieses Program ist nicht richtig. Bei Input von z.B. 'Ein anderer Beispieltext0 07770s' wird eine Null abgeschnitten, obwohl am Schluss keine Zahl steht

sowas macht man mit awk

awk '{ print gensub("([^0-9])0+([1-9][0-9]*)$", "\\1\\2", "g") }' \
\
\
<< !
Beliebiger Text 01
Ein anderer Beispieltext 03
Ein anderer Beispieltext 0003
Ein anderer Beispieltext 4
Ein anderer Beispieltext0 45
Ein anderer Beispieltext0 0777
Ein anderer Beispieltext0 07770
Ein anderer Beispieltext
Ein
!

liefert

Beliebiger Text 1
Ein anderer Beispieltext 3
Ein anderer Beispieltext 3
Ein anderer Beispieltext 4
Ein anderer Beispieltext0 45
Ein anderer Beispieltext0 777
Ein anderer Beispieltext0 7770
Ein anderer Beispieltext
Ein

wie versprochen ein paar Bildchen.

API: libusb-1.0
lirc-basis: lirc-0.9.0~pre1 (debian V7.4)
patch: lirc-0.9.0_ya_usbir_v3.5.diff.tar.gz
hardware: yaUsbIR V3
conf:

/etc/lirc/lircd.conf:
begin remote
  name  SONY_RM_U304
  bits               12
  flags SPACE_ENC|CONST_LENGTH
  eps                30
  aeps              100


  header           2403   520
  one              1250   518
  zero              640   518
  gap             44000
  min_repeat          2
  toggle_bit_mask   0x0
  frequency       38000
      begin codes
          BTN_AUX                  0xB81
          BTN_DVD                  0xBE1
          BTN_CD                   0xA41
          BTN_UP                   0x481
          BTN_DOWN                 0xC81
          VIDEO3                   0x421
          TV/SAT                   0x561
          MD/TAPE                  0x961
          DAT/TAPE                 0xC41
          TUNER                    0x841
          PHONO                    0x041
          MULTI_CH                 0x4E1
          MPX/DUAL                 0xE81
          ANALOG_DIRECT            0x921
          MUTING                   0x281
          ON_SCREEN                0xCA1
          SYSTEM_STANDBY           0xA81
      end codes
end remote

Original-FB kurzer Tastendruck:

das Gleiche mit yausbir sieht ok aus (insbes. wenn man den Signalverlauf hochaufgeloest vergleicht). Erzeugt mit

irsend SEND_ONCE SONY_RM_U304 BTN_DOWN

liefert:

Soweit so gut. Die Fehler passieren bei Mehrfach-Tastendruck:

wenn ich auf der Original-FB die BTN_DOWN so kurz als moeglich druecke, so dass aber genau 1 zusaetzlicher Tastendruck generiert wird bekomme ich:

wenn ich das mit yausbir nachbilden will, geht das nicht:

irsend --count 2 SEND_ONCE SONY_RM_U304 BTN_DOWN

liefert:

hier wird irgendwas vermanscht. Zudem versucht er nicht 1 Signalfolge fuer BTN_DOIWN dranzuhaengen sondern 2 oder vielleicht 3?

die vermanschte Stelle sieht hoeher aufgeloest dann so aus:

Hier kann man sehen, dass evtl. der naechste Tastendruck ohne jedes Gap einfach drangehaengt wird. ABer warum gleich 2 statt 1?

Wenn ich versuche einen count > 9 zu setzen, um z.B. das Volume ganz runterzudrehen wird das mit Fehler abgebrochen:

irsend --count 10 SEND_ONCE SONY_RM_U304 BTN_DOWN

gibt Fehlermeldung:

lircd: accepted new client on /var/run/lirc/lircd
lircd: yaUsbIr: Initializing yaUsbIr (libusb-1.0 API)
lircd: yaUsbIr: idVendor=10C4, idProduct=876C
                Manufacturer: UG Development Lab
                Product: yaUsbIR V3:IR transceiver with power switch
                hid interface (generic)
                SerialNumber: 0003
lircd: yaUsbIr: entering send()
lircd: yaUsbIr: set carrier frequency = 38000 Hz
lircd: yaUsbIr: entering send()
lircd: buffer too small
lircd: yaUsbIr: init_send() failed
lircd: removed client
lircd: yaUsbIr: close device

ein Befehl wie

irsend SEND_START SONY_RM_U304 BTN_DOWN

geht leider auch nicht. Auch hier wieder die Fehlermeldung "buffer too small" wie vor.
Ausserdem wird dann genau nur 1 einziger Tastendruck generiert statt eine endlose Folge (bis zum STOP). IR-Sendepattern dann aehnlich dem allerersten Bild.

- sparkie

also ich sollte vielleicht noch hinzufuegen es geht hier nicht um Einfach-Tastendruck per irsend. Mit dem Workaround 'LIRCD_EXACT_GAP_THRESHOLD 200000' wird ja jetzt der 'gap xxx' fuer 'min_repeat' richtig ausgewertet. Auch ansonsten ist das SIgnal verglichen mit der Originalfernbedienung praktisch identisch.

Es geht hier ausschliesslich um die Mehrfachtasten per 'irsend --count xxx' was ab bestimmtem count nicht mehr funktioniert.
Der 'irsend SEND_START xxx' geht generell nicht (siehe Daemon Fehlermeldung oben). Da brauche ich auch keine Bilder beilegen:-)

Darum wollte ich, bevor ich hier weiter Zeit investiere, erst man checken ob Mehrfachtasten mit yausbir ueberhaupt unterstuetzt werden. Bilder werde ich morgen nachliefern.

- sparkie

wie laeuft eigentlich die Synchronisation zwischen child_process() und dem tatsaechlichen Ende des IR-Sendevorganges?
Ist also sichergestellt, dass wenn er im Code an Stelle

+       read(pipe_tx2main[0], ya_usbir_txbuf, 1);// wait for child process to be ready with it

ankommt, alle Daten gesendet sind?

Ich frage deswegen, weil bei irsends mit Mehrfachtasten, z.B.

irsend --count 7 SEND_ONCE SONY_RM_U304 BTN_DOWN

der Gap der sich rechnerisch aus obigem Sync-Punkt und der Wartezeit im lircd/send_core (wegen repeat_timer.it_value.tv_usec = remote->min_remaining_gap; ) ergibt schon rein gar nicht mit der Realitaet uebereinstimmt. Es sieht so aus als wenn der child_process() dem ya_usbir_send() schon vor Ende der Sendung die Kontrolle zurueckgibt.

Oder sind Mehrfachtasten sowieso verboten?

Ein

irsend SEND_START SONY_RM_U304 BTN_DOWN

scheint gar nicht unterstuetzt zu sein. Im Daemon kommt dann:

Mon Apr 28 18:23:08.845367 buffer too small
Mon Apr 28 18:23:08.846511 yaUsbIr: init_send() failed

Wieviel Puffer existiert eigentlich auf dem Board? Ein

irsend --count 7 SEND_ONCE SONY_RM_U304 BTN_DOWN

wie oben scheint gerade noch zu gehen.

Bei count==8:

irsend --count 8 SEND_ONCE SONY_RM_U304 BTN_DOWN

ist das Sendesignal komplett verstuemmelt. ABer diesmal ohne Fehlermeldung vom Daemon.
Bei Bedarf kann ich jederzeit Bilder vom Speicheroszi nachliefern.
Falls Obiges eigentlich haette funktionieren sollen:-)

- sparkie