[Alpha] RPI Ausgabeplugin

Hier einer der seinen Pi mit einem Buffer-Kondensator am USB Port selbst ausgerüstet hat.

http://rasberrypiblog.blogspot…pannung-fur-usb-port.html

Denke mal dass hier unstabile Spannungen oder HF Einstreuungen schon instabilitäten erzeugen können.
Wenn man dann noch direkt einen USB-DVB an der Antennenanlage hat dann ist die Gefahr sich da allen möglichen Mist einzufangen schon groß.
Da hilft dann nur den Raspi separat in eine Metallbox zu packen und sauber zu Erden. Und die Spannungsversordung sauber zu filtern.

lg,
joe

Zitat von Mreimer

Das ändert nichts daran, dass ein *richtigs* 1A-Netzteil für den Raspberry reicht.

die Tauglichkeit und Potenz von Netzteilen steht auf einem anderen Blatt. Ich wollte nur erklären, wie Ströme über dem Nennwert zustande kommen können, und das stärkere Netzteile dann von Vorteil sind

Zitat

Hier einer der seinen Pi mit einem Buffer-Kondensator

Hm, Goldcaps haben einen recht hohen RI, ob die bei Peaks wirklich was bringen?

(Vielleicht sollten wir alles Hardware-OT in einen RPI-Hardware Thread auslagern)

Lieber Reufer,

Zitat von reufer

Also diese Aussage lässt mich zweifeln, ob dein Raspberry überhaupt stabil läuft. Hast du das denn mal getestet, so wie hier beschrieben?

Ich bin sehr daran interessiert, allfällige deadlocks oder Designfehler zu debuggen, die durch irgendwelche besondere Umstände plötzlich sichtbar werden. Aber für instabile, tiefergelegte Hardware mit Ralleystreifen mangelt es mir an Langeweile.

also zunächst zur Stabilität: Diesen Test habe ich bisher nicht gekannt, kann ich gerne machen. Aber ich kann Dir versichern, dass der Raspberry mit vompclient und xbmc absolut stabil läuft. Auch beim VDR sind die Abstürze ja immer in der selben Art und Weise gewesen (ursprünglich mit Hängen des ganzen VDR, mit Deinen neuen Patches nur noch mit fehlendem OSD).

Mir ist schon klar, dass Du nicht meine Hardware debuggen willst, aber das Verhalten sieht ja schon so aus, dass es da einen Fehler in Code gibt, zumal der Einbau von Sleeps an den Stellen dazu führt, dass es wieder vollständig stabil läuft.

Viele Grüße

Tim

Zitat von reufer

Ich benutze u.a. mein iPhone-Ladegerät

hat es die Modellnummer A1300 --> http://www.infosat.de/digitale…e-netzteile-europa-zur-ck

Hallo,

Ich habe hier ein kleines Problem und zwar habe ich alle 30-40 sekunden oder manchmal auch nur alle Minute haenger oder auch manchmal abstuerze.

Ich bekomme folgendes im Log

Jun 18 01:09:14 raspbmc smbd[5367]:   failed to retrieve printer list: NT_STATUS_UNSUCCESSFUL
Jun 18 01:09:50 raspbmc vdr: [5326] rpihddevice: buffer stall!
Jun 18 01:10:03 raspbmc vdr: [5327] rpihddevice: audio parser skipped 2441 of 2827 bytes
Jun 18 01:10:03 raspbmc vdr: [5327] rpihddevice: failed to decode audio frame!
Jun 18 01:10:06 raspbmc vdr: [5326] rpihddevice: buffer stall!
Jun 18 01:10:06 raspbmc vdr: [5327] rpihddevice: audio parser skipped 1598 of 1600 bytes
Jun 18 01:10:06 raspbmc vdr: [5327] rpihddevice: audio parser skipped 430 of 870 bytes
Jun 18 01:10:09 raspbmc vdr: [5361] rpihddevice: failed to pass buffer to video decoder!
Jun 18 01:10:09 raspbmc vdr: [5361] rpihddevice: failed to pass buffer to video decoder!
Jun 18 01:10:09 raspbmc vdr: [5361] rpihddevice: failed to pass buffer to video decoder!

Das Problem tauch mit Streamdev auf, aber anscheinend nicht mit einer lokalen DVB Karte die direkt am Raspi haengt. Die Probleme habe ich nur bei SD Sender getestet.
Ich benutze die 0.0.9 er version des plugins und streamdev 0.6.1.git20131129.

HAt jemand eine Idee woran das leigen kann ?
Ich denke Netzteil kann mann ausschliessen da es nur mit streamdev auftaucht.

Gruss,

Franz

Danke Thomas

Kann ich dir irgendwie helfen beim Testen oder mit einem ssh zugang ?
Soll ich mal die aktuelle git version bauen ?

Gruss,

Franz

ich hatte schon immer audio plops bei LiveTV auf HDMI, auch wenn der rpi nicht übertaktet ist.
Verbesserung bringt der next-branch, könnt ja mal ausprobieren:

wget https://raw.github.com/Hexxeh/rpi-update/master/rpi-update -O /usr/bin/rpi-update && sudo chmod +x /usr/bin/rpi-update
BRANCH=next rpi-update

dwc_otg.fiq_enable=1 dwc_otg.fiq_fsm_enable=1 dwc_otg.fiq_fsm_mask=0x7

coherent_pool=6M musste bei mir aus cmdline.txt entfernt werden.

Durch die Übertaktung läuft das menu (skinnopacity mit scraper2vdr) auch recht flüssig.

Jetzt würde ich mir noch einen fix für das Deinterlacing Problem auf den ZDF HD Kanälen wünschen

Zitat von stevie101

dwc_otg.fiq_enable=1 dwc_otg.fiq_fsm_enable=1 dwc_otg.fiq_fsm_mask=0x7

Zitat von stevie101

coherent_pool=6M musste bei mir aus cmdline.txt entfernt werden.

rpi-update ist klar, aber wo muss ich die angegebenen Parameter eintragen? Habe auch Tonaussetzer am HDMI.

Gruß,
Robsta

das sind kernel parameter, die musst Du in die cmdline.txt im boot Verzeichnis eintragen.

Robsta hat es bei dir funktioniert ?

Gruss,

Franz

Hi Stevie101,

Zitat von stevie101

Durch die Übertaktung läuft das menu (skinnopacity mit scraper2vdr) auch recht flüssig.

Da Du ja offensichtlich den Raspberry auch etwas schneller laufen lässt, als es der Default ist, könntest Du mal schreiben, ob Du auch meine Probleme mit nicht mehr bedienbarem VDR hast. Durch so eine Rückmeldung könnte ich vielleicht das Problem weiter einkreisen...

Ich habe gestern den halben Tag immer wieder Einstellungen geändert und versucht herauszubekommen, wann der VDR instabil wird. Aber am Ende bin ich zu dem Schluss gekommen, dass fast jede Art von Abweichung vom Default zur Instabilität führt. Aber tatsächlich ist er bei den Standardwerten stabil...

Vielen Dank

Tim

Meine beiden laufen recht stabil mit folgenden Einstellungen:

#Overclocking
force_turbo=1
arm_freq=1100
gpu_freq=550
#isp_freq=490
#core_freq=500
sdram_freq=600
over_voltage=8
over_voltage_sdram=3

gpu_mem_512=128

Das geht aber nur mit UK Version und Samsung Speicher - ich habe auch ein China Teil, das Ding ist wesentlich instabiler und hatte mich letztes Jahr in den Wahnsinn getrieben.
Den China RPI verwende ich jetzt mit einem DAC zum Musik hören (und immer noch eine Betty um MPD zu steuern).

Wichtig ist nach meiner Erfahrung ein gute Spannungsversorgung - ruhig 2A Netzteile verwenden.
Und alle meine 512MB Versionen laufen besser, wenn sie über einen USB Anschluss bestromt werden.
Im Zweifelsfall kann ich Dir nur raten einen neuen zu kaufen - bei dem Preis lohnt sich der Zeitaufwand für eine Montagsversion nicht.

Hi Stevie,

das mit den Chinateilen habe ich auch gehört, meiner ist aber von Farnell und Made in UK. Ich bin ja noch immer nicht überzeugt, dass es an der Hardware liegt, da XBMC und vompclient auch problemlos übertaktet laufen. Aber möglich ist es natürlich schon, deshalb werde ich das auch mal testen und einen anderen Raspberry probieren.

over_voltage habe ich mich bisher nicht getraut, aber vielleicht probiere ich Deine Einstellungen dann auch mal aus.

Meine Stromversorgung ist der USB-Port des Fernsehers, durchaus auch eine mögliche Fehlerquelle, aber auch hier gilt obiges bezüglich anderer Software. Aber da Deine Raspberries ohne meinen Patch stabil laufen, muss es ja an irgendwas bei mir liegen...

Ich werde Deine Punkte jetzt einzeln testen, zunächst mal die Stromversorgung über den normalen USB-Port.

Vielen Dank!

Tim

force_turbo=1

Hi Stevie,
das würde ich mit meinen rpi nicht machen, da man dadurch seinen rpi ins E-Nirvana schicken könnte! Aber ich hoffe du weißt, was du tust...
Poste doch mal die Ausgabe von

cat /proc/cpuinfo

Viele Grüße, Uwe

Das Risiko ist mir bewusst, allerdings wäre der Schaden tragbar.
Beide laufen seit ca. Januar mit 1100Mhz 24/7:

processor : 0
model name : ARMv6-compatible processor rev 7 (v6l)
Features : swp half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xb76
CPU revision : 7

Hardware : BCM2708
Revision : 100000e

root@raspberrypi:~# bcmstat.sh
Config: v0.1.6, args "", priority lowest (+19)
Governor: powersave
Memory: 512MB (split 384MB ARM, 128MB GPU) plus 100MB Swap
HW Block: | ARM | Core | H264 | SDRAM |
Min Freq: | 1100Mhz | 250Mhz | 0Mhz | 600Mhz |
Max Freq: | 1100Mhz | 250Mhz | 250Mhz | 600Mhz |
Voltages: | +8, 1.40V | +3, 1.28V |
Other: temp_limit=85, force_turbo=1
Firmware: Apr 24 2014 18:50:58, version 6b392a1ba3592998a8436f54759b8c7f1403f5ec (clean) (release)
Codecs: H264 WVC1 MPG2 MJPG
Booted: Sat Jun 21 08:22:25 2014

Time ARM Core H264 Core Temp (Max) IRQ/s RX B/s TX B/s
======== ======= ======= ======= =============== ====== ========== ==========
20:08:42 1099Mhz 550Mhz 550Mhz 59.45C (59.45C) 6,108 1,884,711 6,995
20:08:44 1100Mhz 550Mhz 550Mhz 59.45C (59.45C) 5,258 1,792,714 6,501
20:08:46 1100Mhz 550Mhz 550Mhz 58.91C (59.45C) 5,318 1,895,577 6,761
20:08:48 1100Mhz 550Mhz 550Mhz 58.38C (59.45C) 5,366 2,030,288 6,293

Allerdings hab ich einen Kühlkörper verbaut.

Gruss,

ach, und leider hab ich auch mit dem next branch wieder ab und an audio plobs.
Schade, dass alsa nicht per rpihddevice unterstützt werden kann.

Hi Stevie,
Bei dir ist das sticki bit gesetzt, dadurch hast du keinerlei Garantie Ansprüche mehr...

You can tell if your Pi's sticky bit is set by running the following command from a shell prompt and reviewing the Revision value: cat /proc/cpuinfo 
The word on the street is that any Revision value above 1000 means that your sticky bit is set and  ...

Würde es nicht reichen, wenn du das force_turbo deaktivierst? Dadurch wird nur hochgetaktet, wenn es benötigt wird und das sticki bit wäre noch ok....?