Posts by Heinrich

    Tja, das ist nun schon ein Weilchen her,

    aber ich stolpere nun wieder über den Faden und wollte das noch ergänzen:

    Es gab mehrere Programme, die sich plötzlich, nach Updates ähnlich zäh

    verhielten und auf einmal unglaublich viel CPU Zeit fraßen;

    Dazu gehörte, neben dem erwähnten "hatari", auch das von mir sehr geschätzte "sunvox".


    Ich bin nun auf etwas eigentlich Naheliegendes nicht gekommen: Der Grafiktreiber.

    Die erwähnten, neuen Versionen der Programme laufen nurnoch mit dem "experimentellen GL Treiber"

    vernünftig und flutschen, ist der über die /boot/config.txt mit dem Eintrag:

    dtoverlay=vc4-kms-v3d geladen, sogar besser als die vorherigen Programmversionen

    mit dem Standardtreiber, der sonst per default geladen wird.

    Der mplayer und vlc lassen sich dann überhaupt erst sinnvoll nutzen,

    genau wie der Atarisimulator "hatari" in der Version >= 2 und neuerdings auch "sunvox".


    Das wirklich Ärgerliche ist aber, das dann das Youtubefilmgucken mit dem GL-Treiber und dem chrome-browser

    überhaupt keinen Spaß mehr macht. Der ruckelt dann schon fürchterlich nur beim Seitenscrollen

    und Filme gucken kann man so absolut vergessen.


    Irgendwelche Updates muß ich also ergo garnichtmehr verhindern, weil die Programme

    neuerdings mit den richtigen Treibern wunderbar laufen.

    Hey,

    ich danke Euch.

    Ich bin DBVs Tip nachgegangen.

    Synaptic habe ich natürlich installiert:

    Dort das Paket suchen und selektieren,

    dann unter Pulldownmenü "Paket"

    "Version sperren" anklicken und

    das Upgrade läßt das Paket in Ruhe.

    Thx!

    Hi,

    ich wollte gerade ein apt-get upgrade laufen lassen und

    habe glücklicher Weise nochmal durchgeguckt, was "geupgraded"

    werden soll.

    Ich habe hier den Atari-ST Emulator "hatari" auf einem Raspi 3 mit dem

    aktuellen "Stretch", Kernel 4.9, am laufen und brauche den

    für einen speziellen MIDI-Synthesizereditor.

    Die einzig einigermaßen brauchbare Version, hatari 1.9 hatte ich als Binärpaket

    für Raspbian irgendwo im Netz gefunden und per dpkg installiert.

    Die unter Jessie mitgebrachte Version hatari 1.8 wollte auch nicht richtig.

    Version 2, die in den aktuellen Raspbian Repositories für Stretch angeboten wird,

    verursacht eine unglaubliche Prozessorlast, braucht etliche Minuten

    fürs Starten und läuft entsprechend so zäh, daß man damit kaum arbeiten kann.


    Da ich hatari immer aus der Konsole aufrufe,

    sehe ich auch bei der Version 1.9 ständige Fehlermeldungen

    im Hintergrund, in der Konsole:

    Code
    1. Exception 2 (4a68 e014f8) at e014f6 -> e014fc!
    2. Bus Error at address $ff8a00, PC=$e014f6 addr_e3=e014f8 op_e3=4a68

    Das wiederholt sich ständig mit unterschiedlichen Adressen,

    scheint den Programmablauf aber nicht sonderlich zu stören

    und die Prozessorlast steigt beim Ausführen von YSEDIT.PRG unter hatari 1.9

    kaum über 20%.


    -soweit so mäßig,

    nun will aber apt-get upgrade mein schönes hatari 1.9 wahrscheinlich wieder

    auf die träge Version 2 upgraden.

    Wie kann ich das verhindern und trotzdem alles andere upgraden?


    Der Vorteil dieser 40xx CMOS Analogschalter liegt darin, daß sie schon ab
    einseitigen +3V UB arbeiten.
    Mit der Onboardspannung des Raspi von 3,3V sollte man fürs Schalten also schon gut auskommen.
    Bei den etwas teureren von Maxim: DG401, DG403, DG405 z.B. -wenn man die überhaupt noch bekommt-
    wird lt. Datenblatt eine höhere Betriebsspannung von +/- 15V vorausgesetzt.
    Letztere bedeuten also einen beträchtlich höheren Schaltungsaufwand,
    da man dafür schon extra Spannungsquellen bräuchte und die Schaltspannung vom Raspi
    wahrscheinlich auch wenigstens auf TTL-Pegel verstärkt werden müßte.
    Bei den 40xx ist auch darauf zu achten, daß die Spitzen- oder Scheitelspannungen
    des Eingangssignales die Betriebsspannung auf keinen Fall überschreiten.
    Da hat man bei 3,3V Peak to Peak -das sind etwa 1,17V effektiv- nicht sehr viel Luft,
    d.h. das Audiosignal darf keine große Dynamik haben, sonst zerrts.
    Eine einfache Schaltung mit den 40xx würde dann auch recht hochohmig
    und hat eben die kleine Betriebsspannung,
    was mehr Rauschen, Brummen und induktive Empfindlichkeiten mit sich führen könnte.


    Ich habe das selbst noch nicht probiert und das ist nur so meine
    Kosten-Nutzenabwägung. Ist also wirklich zu überlegen,
    ob man sich nicht doch lieber diese ca. 100 Euronen ans Bein bindet.


    Quote

    "mechanische" Muxer gibt, die ihren Zustand auch ohne Spannung beibehalten können


    Gibts: Diese Relais nennen sich "bistabil".


    Ich glaube aber, wenn Du komplexere Schaltereien mit ner Masse von Relais realisierst,
    bekäme die Kiste den Charm einer Telefonschaltanlage aus den Sechzigern :)

    Quote

    Gibt es ICs für sowas?


    Die Billigversionen wären C-MOS Analog-Schalter, wie 4066, oder 4051 z.B.
    Das braucht allerdings schon Einiges an Entwicklungsarbeit,
    damits einigermaßen klingt.

    Quote

    Täusche ich mich, oder gilt das nur den Anschluss an die Klinkenbuchse des Raspi?


    Das gilt, in der Tat, nur für die PWM-Wandlung des Raspi, wirkt allerdings Wunder
    am Klinkenausgang.
    HiFi-Puristen werden da sicher immer noch was zu meckern haben,
    aber ich höre mit diesen Parametervorgaben kaum noch dieses eklige
    Quantisierungsrauschen in den leisen Passagen.
    Mich wundert es nur, daß die in keiner Distri, die ich kenne, schon per default
    so vorgegeben sind.

    Auf alle Fälle füge ich immer folgenden
    Paramerer hinter


    # Enable audio (loads snd_bcm2835)
    dtparam=audio=on


    in der /boot/config.txt ein:


    audio_pwm_mode=2


    Probiers mal, das wirkt schon Wunder und dann zerrt
    auch nichts mehr in den leisen Passagen.

    Hab vielen Dank,
    viele Wege führen nach Rom
    und ich habs mittlerweile mit "ntpdate" hingekriegt,
    allerdings ist es nicht schlecht, wenn der Port nicht benutzt wird.


    Hier nochmal meine Lösung komplett.
    Erstmal:
    systemctl disable ntp
    und:
    apt-get install ntpdate


    Timeserver suchen, ich habe den genommen:
    de.pool.ntp.org


    Dann kleines Skript geschrieben: " /home/pi/zeit.sh" :

    Shell-Script
    1. #!/bin/sh
    2. sudo xterm -hold -e ntpdate de.pool.ntp.org


    Das "-e" führt das folgende Kommando "ntpdate de.pool.ntp.org" aus.
    Das "-hold" läßt das Terminal offen, damit man lesen kann, was sich getan hat.


    Rechte auf das Skript setzen:
    Besitzer root: rwx, Gruppe pi: rwx, alle andern: r
    Oktal: 100774


    Skript automatisch starten.
    In der Datei:
    /home/pi/.config/lxsession/LXDE-pi/autostart
    folgendes anfügen:
    @/home/pi/zeit.sh


    Wenn ich mich jetzt als pi einlogge, erscheint ein kleines Terminal
    und das Skript wird sichtbar ausgeführt.

    Quote

    Ein 8 Ohm Lautsprecher direkt an die GPIOs ??!


    Der angegebene Widerstand auf dem Lautsprecher ist eine Impedanz,
    die entspricht meist dem realen Widerstand.
    -Soviel vorweg.
    Der Strom an nem nackten GPIO:
    I = 3,3V / 8 Ohm = 0,4125 A oder 412,5mA
    Zudem ist ein Lautsprecher eine Spule, die durch Selbstinduktion
    Rückspannungen erzeugt.


    Viel Glück!

    Soo,
    >systemctl disable ntp
    Hat er gemacht und ich habe dafür ntpdate installiert
    als root:
    >ntpdate de.pool.ntp.org>/root/timeserver
    stellt mir die Zeit 1x und beendet sich dann.
    in /root/timeserver steht dann die Ausgabe des Kommandos.
    Ich habe versucht, das in der /etc/rc.local unterzubringen,
    aber erstens ist da wohl leider das Netz noch nicht oben
    und zweitens meckert der systemd.
    Wie und wo kriege ich das denn automatisch gestartet?


    Desweiteren ist mir aufgefallen, daß dhcpcd oder dhcpd läuft,
    obwohl ich eine feste ip vergeben habe.
    Das scheint zwar neuerdings nötig zu sein um die feste ip zu vergeben,
    aber dann muß doch auch kein Dämon mehr geistern.
    Wenn ich Folgendes mache, nachdem die vorgegebene ip (wohl mittels dhcpcd)
    auf eth0 etabliert ist:
    >service dhcpcd stop
    ...bleibt sie persistent. Wozu dann also noch der Dämon?

    Och Kinder!
    Ich will hier keine Glaubenskriege auslösen.
    Der Pi läuft bei mir höchstens mal 6 bis 7 Stunden am Stück.
    Wenn der nun 1x nach der Zeit fragt und nach 7 Stunden dann um 2 Sekunden falsch läuft,
    pupst sich das flach!
    Also halte ich es für unnötig, daß der von jeder "datenbitch.de" (s.o.) unbedingt die Zeit wissen will.

    Quote

    Die "fake-hwclock" speichert nur (... zwischen boot und reboot)


    Danke für die Info.


    Quote

    Wieso stört dich das überhaupt so?


    Reine Gewohnheit.
    Mein Router steht neben dem Monitor und ist auf 6 Minuten Timeout gestellt.
    Als der nichtmehr den Hörer auflegte während ich nicht im Netz war,
    habe ich "iptraf" installiert und da konnte ich dann sehen,
    das er munter nach der Uhrzeit durch die Gegend schreit:

    Code
    1. | UDP (76 bytes) from localhost:ntp to maggo.info:ntp on eth0                                 │
    2. │ UDP (76 bytes) from maggo.info:ntp to localhost:ntp on eth0                                 │
    3. │ UDP (76 bytes) from localhost:ntp to stratum2-4.NTP.TechFak.Un:ntp on eth0                  │
    4. │ UDP (76 bytes) from stratum2-4.NTP.TechFak.Un:ntp to localhost:ntp on eth0                  │
    5. │ UDP (76 bytes) from localhost:ntp to static.132.14.76.144.clie:ntp on eth0                  │
    6. │ UDP (76 bytes) from static.132.14.76.144.clie:ntp to localhost:ntp on eth0                  │
    7. │ UDP (76 bytes) from localhost:ntp to datenbitch.de:ntp on eth0                              │
    8. │ UDP (76 bytes) from datenbitch.de:ntp to localhost:ntp on eth0


    ... usw.
    Ich denk mir eben, das muß nicht sein.
    Mir ist es sowieso völlig wurscht, ob der Pi weiß wie spät es ist,
    aber wenn die Zeitdifferenz zu heftig wird, weigert sich der Browser
    leider https-Seiten zu öffnen.


    Hab jetzt erstmal den Tip von ThomasL oben probiert:
    service ntp stop
    Unter "htop" sehe ich jedenfalls nichts mehr mit "ntp"

    Hi und Danke erstmal kann ich erst nachher ausprobieren.

    Quote

    Dann hat dein PI, aber evtl. nicht die richtige Uhrzeit. Ist das Absicht?


    Na, der soll sich beim Hochfahren die Zeit holen und dann den Dienst abstellen.
    Geht denn die "fake-hw-clock" so schnell falsch?

    Hi,
    weiß jemand, wie ich es hinkriege,
    daß der Raspi (Raspi 3b Raspbian Pixel)
    nur einmal beim Hochfahren seine fake-hw-clock
    nach ntp, ntpdate oder sonstwas einstellt
    und dann nicht mehr im Netz nach der Zeit rumfunkt?


    Dank im Voraus für Sachdienliches.

    Hi,
    ich habe hier einen Bluetooth Lautsprecher "xquisit xqbeat 2.0"
    und spreche den über den Raspi 3B an.
    Das funktioniert sehr unzuverlässig.
    Der längste, kontinuierliche Verbindungsaufbau
    dauerte höchstens 20 Minuten.
    Meist bricht die Verbindung aber schon nach ein bis zwei Minuten ab.
    Der Bluetooth Lautsprecher steht im Umkreis,
    höchstens einen Meter vom Raspi entfernt.


    Ich habe diesen Lautsprecher erst vor Kurzem geschenkt bekommen und sonst
    nix, womit ich Bluetoothverbindungen testen könnte.
    Daher mal allgemein die Frage, ob Bluetoothlautsprecher überhaupt das Wahre sind,
    wenn man z.B. kontinuierlich Hintergrundmusik hört.
    Hier ist über Bluetooth auch ne ganze Menge los, wenn der Raspi durch die Gegend scannt.
    Mindestens drei Geräte, die sich nicht in dieser Wohnung befinden sehe ich immer,
    ab und zu ne Smartwatch und weiß der Himmel, was die Leute im Umkreis noch so funken lassen.
    Vlt. spielt das auch ne Rolle?

    Ich muß nochmal nachfassen

    Quote

    Was rufst du da genau wie auf?


    Ich rufe das Programm "guvcview" auf!


    Und wie genau:
    Indem ich es entweder in einer unter X gestarteten Shell (wahlweise: xterm oder lxterminal)mit > "guvcview" [Ret]
    aufrufe, oder mit der Maus im Programmenü 1x anklicke.
    Letzteres muß ich wohl nicht genauer beschreiben?
    Das macht beides dasselbe, bis auf das ich, wenn ich es aus der Shell starte,
    die Fehlerausgabe des Programmes in selbiger beobachten kann,
    während es läuft.


    Das hier:

    Quote

    Ein Update ist bei einem funktionierendem geschlossenem System nie notwendig.


    ... ist mir neu, um nicht zu sagen "fremd".

    Na,
    ich zieh mir erstmal das letzte Image, schreibs auf die Karte,
    fahre dann damit den Raspi hoch.
    Nach den Einstellereien mit raspi-config kriegt pi erstmal ein anderes password und root überhaupt eins.
    Danach gibts prinzipiell als root ein "apt-get update" und dann ein "apt-get upgrade".
    Letzteres mache ich als root so jede Woche mal.


    Diese erwähnten *.mkv-Dateien habe ich mir mit VLC auf meinem Großen mal angeguckt,
    man hört nur den Ton, ein Bild erscheint nicht.
    vlc hatte ich früher mal auf dem Raspi probiert, aber das war zum einen ein riesiger Softwareklotz
    und zum zweiten lief das im Verhältnis zum omxplayer unglaublich zäh
    und so habe ich keine Lust mir die Karte damit nochmal zuzukleistern,
    obwohl ichs schade finde, da VLC ja eigentlich alles könnte, was ich möchte.
    Deswegen war ich froh, guvcview für die Kammeras gefunden zu haben,
    was Anfangs ja auch brav lief .
    Da zeigte es mir sogar die Audioaussteuerung im Monitorbild bei der Aufnahme.
    Jetzt steht das Monitorbild bei der Aufnahme, und ein Videobild wird offensichtlich nicht aufgenommen, egal,
    was ich in der GUI einstelle und gespeichert wird nurnoch *.mkv.

    Hi,
    ich hoffe, daß sich hier jemand etwas mit Videoaufnahmen auf dem Raspi beschäftigt hat
    und mir weiterhelfen kann:
    Ich habe hier 2 USB-Webcams, die Anfangs, als ich "guvcview" unter raspbian- "Pixel"
    auf nem Raspberry Pi 3b installiert hatte zwar zäh, aber einigermaßen funktionierten.
    Nun stürzt das Programm, aus mir unerfindlichen Gründen ständig ab und Aufnahmen
    macht das Ding nurnoch mit irgendnem "matroska-codec".
    Es spuckt *.mkv -Dateien bei der Aufnahme aus, egal welchen Codec ich in der GUI wähle.


    Ich habe das Programm nun aus der Kommandozeile gestartet
    und wie es scheint, versucht V4L_2CORE da irgendwas mit diesem "matroska-codec" zu veranstalten,
    obwohl ich im Programm mpg1-Kodierung ausgewählt habe:

    Code
    1. ENCODER: (matroska) packet buffer [9] is in use: flushing cached data
    2. ENCODER: (matroska) packet buffer [10] is in use: flushing cached data
    3. V4L2_CORE: ioctl (-1069263343) retried 4 times - giving up: Die Ressource ist zur Zeit nicht verfügbar)
    4. V4L2_CORE: (VIDIOC_DQBUF) Unable to dequeue buffer: Die Ressource ist zur Zeit nicht verfügbar


    Folgendes ist der Inhalt der Datei [Zuhause]/.config/guvcview2/video0


    Ich les da nirgendwo was von "matroska",
    obwohl ich -wie gesagt- meine, daß das Anfangs, nach der Installation von guvcview,
    sogar als Auswahl für nen Codec in der GUI vorhanden war.


    Hab ich da irgend ne Verschlimm-Besserung geupdatet?
    Mir ist nun gesagt worden, daß man kein dist-upgrade
    oder raspi-update mehr machen soll,
    aber "apt-get update", "apt-get upgrade" -ist das noch erlaubt?

    Neues Image -neues Glück!
    Et pfundste! -erstmal
    und das Gerät meldete sich sogar mit "Your device is connected."
    Aber sehr zuverlässig ist es nicht.
    Die Verbindung brach mehrmals nach einigen Minuten ab,
    obwohl die Lautsprecher nur etwa 30cm vom Raspi entfernt stehen.
    Aber ich freue mich, daß es überhaupt funktioniert.
    :)