FPV Wifi Broadcasting HD Video - Thread zum Raspberry HD Videolink von Befi
- Themenstarter trailblazer
- Beginndatum
- Status
Meinen TX habe ich jetzt leidlich am laufen... Yeppi!
Probleme habe ich jetzt jedoch mit meinem RX.
Hatte bislang einen A+ als RX gentuzt und an dem taten es 2Stk. 722N Sticks im Diversity Betrieb problemlos.
Nun wollte ich auf den Pi2 umsteigen und an einem 4-fach USB-Hub 4 Stück 722N nutzen.
Leider funktioniert das nicht. Der Pi2 bedient sich irgendwie nur 3 Interfaces:
3 WLAN Sticks leuchten, 1er bleibt dunkel
Ich nutze das Pi2 Image von DerKlotz, Pi2 und die WLAN Sticks hängen an einem aktiven USB-Hub mit 5V 3A.
Hat jemand eine Idee woran es liegen könnte, dass er nur 3 Interfaces nutzt?
Besten Dank!
Probleme habe ich jetzt jedoch mit meinem RX.
Hatte bislang einen A+ als RX gentuzt und an dem taten es 2Stk. 722N Sticks im Diversity Betrieb problemlos.
Nun wollte ich auf den Pi2 umsteigen und an einem 4-fach USB-Hub 4 Stück 722N nutzen.
Leider funktioniert das nicht. Der Pi2 bedient sich irgendwie nur 3 Interfaces:
Code:
root@raspberrypitx:/home/pi/wifibroadcast_fpv_scripts# ./rx.sh
Starting without recording
DLT_IEEE802_11_RADIO Encap
DLT_IEEE802_11_RADIO Encap
DLT_IEEE802_11_RADIO EncapIch nutze das Pi2 Image von DerKlotz, Pi2 und die WLAN Sticks hängen an einem aktiven USB-Hub mit 5V 3A.
Hat jemand eine Idee woran es liegen könnte, dass er nur 3 Interfaces nutzt?
Besten Dank!
Zuletzt bearbeitet:
Careyer, da würde ich wohl mal einen genaueren Blick auf den Bootvorgang werfen, ob da eventuell eine fehlermeldung kommt.
Kommt denn mit dreien ein Bild, oder fehlt das auch noch?
Denn mitunter ist es eher einProblem, dass der RX gar kein Signal findet, weil die mitunter auf unterschiedlichen Kanälen arbeiten, oder gar wie es hier schon öfter angesprochen wurde, die Kanaeinstellung auskommentiert wurde "#".
Was auch sein kann, dass irgendwie beim Kanal z.B. mit dem "-" etwas nicht stimmt, auch wenn es normal aussieht.
Wurde hier auch schon erwähnt, dann einfach mal alles innerhalb der "" löschen, speichern, und neu aufrufen zum ändern und es dann selbst von hand rein schreiben.
Das Sind jetzt mal so die üblichen Verdächtigen und mal ins Dunkle hinein getippt.
Wenn das alles ausgeschlossen werden kann, dann kann man mit Linux Kommandos sicherlich checken, welcher der Sticks nicht angesprochen wird.. warum auch immer.
Am Ende, müßten alle Sticks blinken, nicht nur leuchten und es sieht für mich, nach falschen Kanälen aus.
Kommt denn mit dreien ein Bild, oder fehlt das auch noch?
Denn mitunter ist es eher einProblem, dass der RX gar kein Signal findet, weil die mitunter auf unterschiedlichen Kanälen arbeiten, oder gar wie es hier schon öfter angesprochen wurde, die Kanaeinstellung auskommentiert wurde "#".
Was auch sein kann, dass irgendwie beim Kanal z.B. mit dem "-" etwas nicht stimmt, auch wenn es normal aussieht.
Wurde hier auch schon erwähnt, dann einfach mal alles innerhalb der "" löschen, speichern, und neu aufrufen zum ändern und es dann selbst von hand rein schreiben.
Das Sind jetzt mal so die üblichen Verdächtigen und mal ins Dunkle hinein getippt.
Wenn das alles ausgeschlossen werden kann, dann kann man mit Linux Kommandos sicherlich checken, welcher der Sticks nicht angesprochen wird.. warum auch immer.
Am Ende, müßten alle Sticks blinken, nicht nur leuchten und es sieht für mich, nach falschen Kanälen aus.
mach mal
das zeigt alle im system gefunden wlan devices. der befehl steht auch im rx-script zum definieren der variablen NICS.
wenn da nicht alle 4 sticks auftauchen hat das zumindest nix mit wifibroadcast zu tun.
dann kannst du ja der reihe nach sticks rausziehen/reinstecken und wieder schauen, wieviele wlan-devices noch angezeigt werden.
so kannst du zumindest rauskriegen, welcher die problem macht. vielleicht liegt's ja auch an einem port des usb hubs oder an der stromversorgung des hubs.
Code:
ls /sys/class/net | grep wlanwenn da nicht alle 4 sticks auftauchen hat das zumindest nix mit wifibroadcast zu tun.
dann kannst du ja der reihe nach sticks rausziehen/reinstecken und wieder schauen, wieviele wlan-devices noch angezeigt werden.
so kannst du zumindest rauskriegen, welcher die problem macht. vielleicht liegt's ja auch an einem port des usb hubs oder an der stromversorgung des hubs.
Kompilieren hat funktioniert, allerdings erkennt er jetzt den Stick nichtmehr. Kann nichtmal mehr ins Internet einloggen.
Denk es liegt villt am Kernel, vorher war 3.11.18 drauf jetzt der 4.1.1. Werde es nochmal mit Cross-Compiling versuchen und mit dem alten Kernel.
Vorher teste ich aber mal dein Image.
Lad es gerade runter, dauert mit 120kb/s etwas, aber werde dann berichten.
Edit: jetzt läd er mit 300, das passt
Denk es liegt villt am Kernel, vorher war 3.11.18 drauf jetzt der 4.1.1. Werde es nochmal mit Cross-Compiling versuchen und mit dem alten Kernel.
Vorher teste ich aber mal dein Image.
Lad es gerade runter, dauert mit 120kb/s etwas, aber werde dann berichten.
Edit: jetzt läd er mit 300, das passt
Zuletzt bearbeitet:
hallo schalonsus, ich hab meinen tx mal noch auf das aktuelle debian 8 (jessie) hochgezogen.
ist auch der 4.1.10 kernel drauf. bootet etwas schneller mit systemd statt upstart.
das ist aber auch der einzige vorteil den ich feststellen konnte.
bei mir läuft es etwas instabiler als das debian7 mit 3.18er kernel. zumindest hat sich das wlan-device jetzt schon ein paar mal aufgehängt.
ich lad es gerade mal auf google drive und schick dann den link. passt wie gehabt auf eine mind. 2gb karte, gepackt waren es glaube ich um die 800mb.
hat eigentlich schonmal jemand das mavlink osd von digaus probiert? bei der binary fehlt bei mir beim starten eine lib und beim kompilieren fehlt die mavlink.h. kann da jemand helfen.
vg
ist auch der 4.1.10 kernel drauf. bootet etwas schneller mit systemd statt upstart.
das ist aber auch der einzige vorteil den ich feststellen konnte.
bei mir läuft es etwas instabiler als das debian7 mit 3.18er kernel. zumindest hat sich das wlan-device jetzt schon ein paar mal aufgehängt.
ich lad es gerade mal auf google drive und schick dann den link. passt wie gehabt auf eine mind. 2gb karte, gepackt waren es glaube ich um die 800mb.
hat eigentlich schonmal jemand das mavlink osd von digaus probiert? bei der binary fehlt bei mir beim starten eine lib und beim kompilieren fehlt die mavlink.h. kann da jemand helfen.
vg
Hi tomm, vielleicht kannst du dir die fehlenden Dateien aus den beiden Images mopsen, die digaus ebenfalls bereitgestellt hat? Da müssten die doch eigentlich drin liegen -- Könntest du mir das Jessie Image ebenfalls bereitstellen? -- ich Kämpfe hier immer noch mit den Backports und der gcc Inkompatibilität.... Vollkommen neu kompilieren möchte ich mir wenn's irgend geht vermeiden... 18h warten ist nicht in meinem genetischen Bauplan enthalten. ;-) -- lieben Dank.
Grüße
Thomas
Grüße
Thomas
here you go.
https://drive.google.com/file/d/0B9tK1ig77P_YN2RZNUJkZ19OMkk/view?usp=sharing
md5sum 521a9d4b464dae875dce3ae40717844b wbc-23ghz-debian8-kernel4-tx.img
debian8 jessie für pi A, A+,B, B+, kernel 4.1.10, ath9k_htc per backports gepatcht auf 2,3ghz/30dbm, region-database ebenfalls angepasst
basis: raspbian-netinstall, keine grafische oberfläche
user: pi
pass: pi
scripte jetzt "standard"-konform, also nicht mehr für root angepaßt sondern so wie befi das hatte für user pi
tx startet als dienst beim booten auf kanal -6, lässt sich aber problemlos auf rx umkonfigurieren.
bin gespannt auf eure ergebnisse, bei mir läuft es nicht so stabil wie mit debian 7. woran es liegt bin ich noch nicht dahinter gekommen.
https://drive.google.com/file/d/0B9tK1ig77P_YN2RZNUJkZ19OMkk/view?usp=sharing
md5sum 521a9d4b464dae875dce3ae40717844b wbc-23ghz-debian8-kernel4-tx.img
debian8 jessie für pi A, A+,B, B+, kernel 4.1.10, ath9k_htc per backports gepatcht auf 2,3ghz/30dbm, region-database ebenfalls angepasst
basis: raspbian-netinstall, keine grafische oberfläche
user: pi
pass: pi
scripte jetzt "standard"-konform, also nicht mehr für root angepaßt sondern so wie befi das hatte für user pi
tx startet als dienst beim booten auf kanal -6, lässt sich aber problemlos auf rx umkonfigurieren.
bin gespannt auf eure ergebnisse, bei mir läuft es nicht so stabil wie mit debian 7. woran es liegt bin ich noch nicht dahinter gekommen.
Gracias!
ich glaube bei meinem Pi2 handelt es sich um ein Stromproblem, dass er die 4 Sticks nicht findet. Der Pi2 stand-alone (ohne irgendwelche Peripherie angeschlossen) zeigt beim booten schon dieses bunte Quadrat in der oberen rechten Bildschirmecke an... das deutet doch auf ein Stromproblem hin richtig? Dabei speise ich die 4-Kern Himbeere schon über ein 5V 3A Netzteil über den MicroUSB Port.... wieviel Strom will der denn bitteschön noch haben?
ich glaube bei meinem Pi2 handelt es sich um ein Stromproblem, dass er die 4 Sticks nicht findet. Der Pi2 stand-alone (ohne irgendwelche Peripherie angeschlossen) zeigt beim booten schon dieses bunte Quadrat in der oberen rechten Bildschirmecke an... das deutet doch auf ein Stromproblem hin richtig? Dabei speise ich die 4-Kern Himbeere schon über ein 5V 3A Netzteil über den MicroUSB Port.... wieviel Strom will der denn bitteschön noch haben?
Zuletzt bearbeitet:
Fürs kompilieren musst du die mavlink c_library in das entsprechende Verzeichnis (musst mal im Makefile gucken) clonen: https://github.com/mavlink/c_library
So, ich betreibe den Pi2 jetzt direkt über die Stiftleiste (Pin 4+6) mit einem BEC 5V 2,5A. Die Stromwarnung beim Booten (buntes Quadrat in der rechten oberen Ecke) ist jetzt weg.
Jetzt wo der Pi2 stabil läuft habe ich die 4Stk. TP-Link 772N und den aktiven USB-Hub (4-Port, 5V 3A) wieder ins Spiel gebracht.
Folgendes Bild stellt sich dar:
Da sich Anzahl der erkannten WLAN-Schnittstellen immer zwischen 2-3 bewegt: Könnte es sein, dass hier ein Timing-Problem auftritt? Der Pi2 rennt ja förmlich durch den Boot-Prozess durch?
Ich hänge mal einen Ausschnitt aus dem Bootlog mit an, dies hier (rot) sieht mir nicht richtig aus:
UPDATE 1 Es scheint sich hier um ein bekanntes ath9k_htc Treiberproblem zu handeln (siehe hier: https://github.com/qca/open-ath9k-htc-firmware/issues/1) .... @tomm: Das könnte auch der Grund sein wieso sich die WLAN Adapter in deiner Jessie Version von jetzt auf gleich aufhängen?
UPDATE 2 Auch mit frischen Weezy und Jessie Rasbian images tritt o.g. Fehlermeldung auf. Ebenfalls ist das Lubuntu Image betroffen... (wobei der PC es erstaunlichweise machmal schafft alle 4 Sticks zu aktivieren).... hier werden bei "iw dev" auch 4 phys. Geräte angezeigt.
Hier bin ich mit meinem frisch erworbenen Linux-Latein leider am Ende und hoffe, dass jemand helfen kann... DANKE!
Jetzt wo der Pi2 stabil läuft habe ich die 4Stk. TP-Link 772N und den aktiven USB-Hub (4-Port, 5V 3A) wieder ins Spiel gebracht.
Folgendes Bild stellt sich dar:
- aus den 4 eingestecken Sticks werden entweder nur 2 oder (seltener 3) aktviert (welche ist immer unterschiedlich)
- das Kommado "lsusb" gibt grundsätzlich immer alle 4 eingesteckten Sticks aus (Linux ist sich also dem Vorhandensein aller 4 Sticks bewusst)
Code:pi@raspberrypitx:~$ lsusb Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 008: ID 0835:8502 Action Star Enterprise Co., Ltd [b]Bus 001 Device 009: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n Bus 001 Device 010: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n[/b] Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. Bus 001 Device 004: ID 0835:8500 Action Star Enterprise Co., Ltd Bus 001 Device 005: ID 0835:8501 Action Star Enterprise Co., Ltd [b]Bus 001 Device 011: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n Bus 001 Device 006: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n[/b] Bus 001 Device 007: ID 0835:8500 Action Star Enterprise Co., Ltd
- das Kommando "iw dev" gibt hingegen immer nur 3 phys. Geräte aus: (wo bitte ist no.4 ?)
Code:pi@raspberrypitx:~$ iw dev phy#2 Interface wlan2 ifindex 5 wdev 0x200000001 addr c4:e9:84:10:72:21 type monitor channel -13 (2342 MHz), width: 20 MHz (no HT), center1: 2342 MHz phy#1 Interface wlan1 ifindex 4 wdev 0x100000001 addr c4:e9:84:10:71:6a type monitor channel -13 (2342 MHz), width: 20 MHz (no HT), center1: 2342 MHz phy#0 Interface wlan0 ifindex 3 wdev 0x1 addr c4:e9:84:10:71:77 type monitor channel -5 (2382 MHz), width: 20 MHz (no HT), center1: 2382 MHz
- gemapped werden auch nur 3 auf ein WLAN Interface
das Kommando "ls /sys/class/net | grep wlan" gibt diese jeweils aus
Code:pi@raspberrypitx:~$ ls /sys/class/net | grep wlan wlan0 wlan1 wlan2
- Zum Test habe ich mal einen 2. Aktiv USB-Hub angeschlossen und die 4 Sticks gleichmäßig auf beide Hubs verteilt. Das Bild bleibt das gleiche: Er aktiviert über die beiden angeschlossenen Hubs immer nur 2 bis 3 Sticks.
- Ein Stromversorgungsproblem der Sticks kann bei 2 aktiven USB-Hubs a 3A wohl ausgeschlossen werden
Da sich Anzahl der erkannten WLAN-Schnittstellen immer zwischen 2-3 bewegt: Könnte es sein, dass hier ein Timing-Problem auftritt? Der Pi2 rennt ja förmlich durch den Boot-Prozess durch?
Ich hänge mal einen Ausschnitt aus dem Bootlog mit an, dies hier (rot) sieht mir nicht richtig aus:
Code:
...
[ 6.416756] usb 1-1.5.5.4: New USB device found, idVendor=0cf3, idProduct=9271
[ 6.430444] usb 1-1.5.5.4: New USB device strings: Mfr=16, Product=32, SerialNumber=48
[ 6.445246] usb 1-1.5.5.4: Product: USB2.0 WLAN
[color=red]
[ 6.455971] usb 1-1.5.5.4: Manufacturer: ATHEROS
[ 6.455982] usb 1-1.5.5.4: SerialNumber: 12345
[ 6.457346] usb 1-1.5.5.4: ath9k_htc: Firmware htc_9271.fw requested
[ 6.527037] usb 1-1.5.5.3: ath9k_htc: Transferred FW: htc_9271.fw, size: 51008
[ 6.775210] usb 1-1.5.5.4: ath9k_htc: Transferred FW: htc_9271.fw, size: 51008
[ 7.574616] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[ 7.784983] usb 1-1.5.5.3: Service connection timeout for: 258
[ 7.797091] ath9k_htc 1-1.5.5.4:1.0: [b]ath9k_htc: Target is unresponsive
[ 7.809464] ath9k_htc 1-1.5.5.3:1.0: ath9k_htc: Unable to initialize HTC services
[ 7.823279] ath9k_htc: Failed to initialize the device
[ 7.836036] usb 1-1.5.5.4: ath9k_htc: USB layer deinitialized
[ 7.847910] ath9k_htc: Failed to initialize the device
[ 7.861987] usb 1-1.5.5.3: ath9k_htc: USB layer deinitialized[/b][/color]
[ 7.908587] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[ 9.092062] ath9k_htc 1-1.5.4:1.0: ath9k_htc: FW Version: 1.4
[ 9.104965] ath9k_htc 1-1.5.4:1.0: FW RMW support: On
[ 9.116045] ath9k_htc 1-1.5.3:1.0: ath9k_htc: FW Version: 1.4
[ 9.128365] ath9k_htc 1-1.5.3:1.0: FW RMW support: On
[ 9.183040] ieee80211 phy1: Atheros AR9271 Rev:1
[ 9.196230] ieee80211 phy0: Atheros AR9271 Rev:1
[ 9.207414] cfg80211: Calling CRDA for country: CN
[ 9.258040] cfg80211: Regulatory domain changed to country: CN
[ 9.270032] cfg80211: DFS Master region: FCC
[ 9.274421] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[ 9.297788] cfg80211: (2302000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 3000 mBm), (N/A)
[ 9.313548] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2300 mBm), (N/A)
[ 9.329385] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2300 mBm), (0 s)
[ 9.345678] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 3000 mBm), (N/A)
[ 9.360192] cfg80211: (57240000 KHz - 59400000 KHz @ 2160000 KHz), (N/A, 2800 mBm), (N/A)
[ 9.375089] cfg80211: (59400000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 4400 mBm), (N/A)
[ 9.390131] cfg80211: (63720000 KHz - 65880000 KHz @ 2160000 KHz), (N/A, 2800 mBm), (N/A)
Raspbian GNU/Linux 7 raspberrypitx ttyAMA0
raspberrypitx login:UPDATE 2 Auch mit frischen Weezy und Jessie Rasbian images tritt o.g. Fehlermeldung auf. Ebenfalls ist das Lubuntu Image betroffen... (wobei der PC es erstaunlichweise machmal schafft alle 4 Sticks zu aktivieren).... hier werden bei "iw dev" auch 4 phys. Geräte angezeigt.
Hier bin ich mit meinem frisch erworbenen Linux-Latein leider am Ende und hoffe, dass jemand helfen kann... DANKE!
Zuletzt bearbeitet:
@tomm
also das 3.18er Image bootet schonmal nicht, hängt sich nach crda auf.
Hab das Image mit Win32DiskImager geflasht.
also das 3.18er Image bootet schonmal nicht, hängt sich nach crda auf.
Hab das Image mit Win32DiskImager geflasht.
Code:
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Initializing cgroup subsys cpuacct
[ 0.000000] Linux version 3.18.0-trunk-rpi ([email protected]) (gcc version 4.7.2 (Debian 4.7.2-5+rpi1) ) #1 PREEMPT Debian 3.18.5-1~exp1+rpi19 (2015-08-08)
[ 0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[ 0.000000] Machine: BCM2708
[ 0.000000] cma: Reserved 8 MiB at 0x07000000
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
[ 0.000000] Kernel command line: dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708.boardrev=0x12 bcm2708.serial=0x2ef3dee5 smsc95xx.macaddr=B8:27:EB:F3:DE:E5 bcm2708_fb.fbswap=1 bcm2708.disk_led_gpio=47 bcm2708.disk_led_active_low=0 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0xec00000 vc_mem.mem_size=0x10000000 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 elevator=deadline root=/dev/mmcblk0p2 rootfstype=ext4 rootwait
[ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.000000] Memory: 107696K/131072K available (5769K kernel code, 477K rwdata, 1696K rodata, 332K init, 446K bss, 23376K reserved)
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xffc00000 - 0xffe00000 (2048 kB)
[ 0.000000] vmalloc : 0xc8800000 - 0xff000000 ( 872 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xc8000000 ( 128 MB)
[ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB)
[ 0.000000] .text : 0xc0008000 - 0xc0752838 (7467 kB)
[ 0.000000] .init : 0xc0753000 - 0xc07a6000 ( 332 kB)
[ 0.000000] .data : 0xc07a6000 - 0xc081d5f4 ( 478 kB)
[ 0.000000] .bss : 0xc081d5f4 - 0xc088ce7c ( 447 kB)
[ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] NR_IRQS:522
[ 0.000024] sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 2147483648000ns
[ 0.000073] Switching to timer-based delay loop, resolution 1000ns
[ 0.000362] Console: colour dummy device 80x30
[ 0.001679] console [tty1] enabled
[ 0.001728] Calibrating delay loop (skipped), value calculated using timer frequency.. 2.00 BogoMIPS (lpj=4000)
[ 0.001814] pid_max: default: 32768 minimum: 301
[ 0.001952] Security Framework initialized
[ 0.002079] AppArmor: AppArmor disabled by boot time parameter
[ 0.002136] Yama: disabled by default; enable with sysctl kernel.yama.*
[ 0.002303] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.002369] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.003477] Initializing cgroup subsys memory
[ 0.003571] Initializing cgroup subsys devices
[ 0.003637] Initializing cgroup subsys freezer
[ 0.003695] Initializing cgroup subsys net_cls
[ 0.003751] Initializing cgroup subsys blkio
[ 0.003804] Initializing cgroup subsys perf_event
[ 0.003864] Initializing cgroup subsys net_prio
[ 0.003994] CPU: Testing write buffer coherency: ok
[ 0.004217] ftrace: allocating 19046 entries in 56 pages
[ 0.125347] Setting up static identity map for 0x537ce8 - 0x537d44
[ 0.141900] devtmpfs: initialized
[ 0.160707] VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 5
[ 0.172083] pinctrl core: initialized pinctrl subsystem
[ 0.173193] NET: Registered protocol family 16
[ 0.178806] DMA: preallocated 4096 KiB pool for atomic coherent allocations
[ 0.189601] cpuidle: using governor ladder
[ 0.201669] cpuidle: using governor menu
[ 0.202229] bcm2708.uart_clock = 3000000
[ 0.202308] of_platform_populate failed: -22
[ 0.207899] hw-breakpoint: found 6 breakpoint and 1 watchpoint registers.
[ 0.207976] hw-breakpoint: maximum watchpoint size is 4 bytes.
[ 0.208055] mailbox: Broadcom VideoCore Mailbox driver
[ 0.208229] bcm2708_vcio: mailbox at f200b880
[ 0.208864] bcm_power: Broadcom power driver
[ 0.208927] bcm_power_open() -> 0
[ 0.208960] bcm_power_request(0, 8)
[ 0.709709] bcm_mailbox_read -> 00000080, 0
[ 0.709765] bcm_power_request -> 0
[ 0.710091] Serial: AMBA PL011 UART driver
[ 0.710331] dev:f1: ttyAMA0 at MMIO 0x20201000 (irq = 83, base_baud = 0) is a PL011 rev3
[ 1.130540] console [ttyAMA0] enabled
[ 1.186524] usbcore: registered new interface driver usbfs
[ 1.192346] usbcore: registered new interface driver hub
[ 1.197910] usbcore: registered new device driver usb
[ 1.205799] Switched to clocksource stc
[ 1.314111] NET: Registered protocol family 2
[ 1.320089] TCP established hash table entries: 1024 (order: 0, 4096 bytes)
[ 1.327377] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[ 1.333856] TCP: Hash tables configured (established 1024 bind 1024)
[ 1.340387] TCP: reno registered
[ 1.343714] UDP hash table entries: 256 (order: 0, 4096 bytes)
[ 1.349647] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[ 1.356419] NET: Registered protocol family 1
[ 1.361503] Unpacking initramfs...
[ 2.144416] Freeing initrd memory: 5236K (c7ad3000 - c7ff0000)
[ 2.164259] bcm2708_dma: DMA manager at f2007000
[ 2.169378] bcm2708_gpio: bcm2708_gpio_probe c07b5ae0
[ 2.175325] vc-mem: phys_addr:0x00000000 mem_base=0x0ec00000 mem_size:0x10000000(256 MiB)
[ 2.186485] futex hash table entries: 256 (order: -1, 3072 bytes)
[ 2.192943] audit: initializing netlink subsys (disabled)
[ 2.198643] audit: type=2000 audit(1.884:1): initialized
[ 2.220812] zpool: loaded
[ 2.224347] VFS: Disk quotas dquot_6.5.2
[ 2.228865] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 2.238339] msgmni has been set to 236
[ 2.247218] alg: No test for stdrng (krng)
[ 2.252120] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
[ 2.260214] io scheduler noop registered
[ 2.264422] io scheduler deadline registered (default)
[ 2.270342] io scheduler cfq registered
[ 2.276326] BCM2708FB: allocated DMA memory 47400000
[ 2.281570] BCM2708FB: allocated DMA channel 0 @ f2007000
[ 2.293267] Console: switching to colour frame buffer device 82x26
[ 2.306705] bcm2708-dmaengine bcm2708-dmaengine: Load BCM2835 DMA engine driver
[ 2.316938] uart-pl011 dev:f1: no DMA platform data
[ 2.325045] vc-cma: Videocore CMA driver
[ 2.331213] vc-cma: vc_cma_base = 0x00000000
[ 2.338096] vc-cma: vc_cma_size = 0x00000000 (0 MiB)
[ 2.345613] vc-cma: vc_cma_initial = 0x00000000 (0 MiB)
[ 2.354358] vchiq: vchiq_init_state: slot_zero = 0xc7000000, is_master = 0
[ 2.364483] usbcore: registered new interface driver smsc95xx
[ 2.373499] dwc_otg: version 3.00a 10-AUG-2012 (platform bus)
[ 2.581866] Core Release: 2.80a
[ 2.587105] Setting default values for core params
[ 2.593907] Finished setting default values for core params
[ 2.801810] Using Buffer DMA mode
[ 2.807157] Periodic Transfer Interrupt Enhancement - disabled
[ 2.815013] Multiprocessor Interrupt Enhancement - disabled
[ 2.822604] OTG VER PARAM: 0, OTG VER FLAG: 0
[ 2.828931] Dedicated Tx FIFOs mode
[ 2.834897] WARN::dwc_otg_hcd_init:1047: FIQ DMA bounce buffers: virt = 0xc7414000 dma = 0x47414000 len=9024
[ 2.848678] FIQ FSM acceleration enabled for :
[ 2.848678] Non-periodic Split Transactions
[ 2.848678] Periodic Split Transactions
[ 2.848678] High-Speed Isochronous Endpoints
[ 2.873088] WARN::hcd_init_fiq:412: FIQ on core 0 at 0xc03b8328
[ 2.881020] WARN::hcd_init_fiq:413: FIQ ASM at 0xc03b85f4 length 36
[ 2.889230] WARN::hcd_init_fiq:438: MPHI regs_base at 0xc8808000
[ 2.897304] dwc_otg bcm2708_usb: DWC OTG Controller
[ 2.904740] dwc_otg bcm2708_usb: new USB bus registered, assigned bus number 1
[ 2.914088] dwc_otg bcm2708_usb: irq 32, io mem 0x00000000
[ 2.921591] Init: Port Power? op_state=1
[ 2.927499] Init: Power Port (0)
[ 2.933106] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 2.941980] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 2.951220] usb usb1: Product: DWC OTG Controller
[ 2.957922] usb usb1: Manufacturer: Linux 3.18.0-trunk-rpi dwc_otg_hcd
[ 2.966487] usb usb1: SerialNumber: bcm2708_usb
[ 2.974583] hub 1-0:1.0: USB hub found
[ 2.980554] hub 1-0:1.0: 1 port detected
[ 2.988776] mousedev: PS/2 mouse device common for all mice
[ 2.998105] bcm2835-cpufreq: min=700000 max=900000
[ 3.005426] sdhci: Secure Digital Host Controller Interface driver
[ 3.013657] sdhci: Copyright(c) Pierre Ossman
[ 3.020271] DMA channels allocated for the MMC driver
[ 3.053879] Load BCM2835 MMC driver
[ 3.061532] sdhci-pltfm: SDHCI platform and OF driver helper
[ 3.077415] ledtrig-cpu: registered to indicate activity on CPUs
[ 3.085731] hidraw: raw HID events driver (C) Jiri Kosina
[ 3.106389] usbcore: registered new interface driver usbhid
[ 3.114141] usbhid: USB HID core driver
[ 3.120596] TCP: cubic registered
[ 3.127261] NET: Registered protocol family 10
[ 3.136262] mip6: Mobile IPv6
[ 3.141481] NET: Registered protocol family 17
[ 3.148121] mpls_gso: MPLS GSO support
[ 3.156617] registered taskstats version 1
[ 3.162828] mmc0: host does not support reading read-only switch, assuming write-enable
[ 3.175057] vc-sm: Videocore shared memory driver
[ 3.181925] [vc_sm_connected_init]: start
[ 3.189230] [vc_sm_connected_init]: end - returning 0
[ 3.196875] Indeed it is in host mode hprt0 = 00021501
[ 3.204144] mmc0: new high speed SDHC card at address 59b4
[ 3.215131] mmcblk0: mmc0:59b4 NCard 7.51 GiB
[ 3.221933] /linux-3.18-3.18.5/drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[ 3.243630] mmcblk0: p1 p2
[ 3.255568] Freeing unused kernel memory: 332K (c0753000 - c07a6000)
[ 3.434492] udevd[67]: starting version 175
[ 3.470139] usb 1-1: new high-speed USB device number 2 using dwc_otg
[ 3.496675] Indeed it is in host mode hprt0 = 00001101
[ 4.003258] usb 1-1: New USB device found, idVendor=0cf3, idProduct=9271
[ 4.116611] usb 1-1: New USB device strings: Mfr=16, Product=32, SerialNumber=48
[ 4.270038] usb 1-1: Product: UB91C
[ 4.350577] usb 1-1: Manufacturer: ATHEROS
[ 4.426437] usb 1-1: SerialNumber: 12345
[ 4.591792] random: nonblocking pool is initialized
[ 5.203348] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[ 7.780405] udevd[270]: starting version 175
[ 8.695957] bcm2708_i2c_init_pinmode(1,2)
[ 8.810186] bcm2708_i2c_init_pinmode(1,3)
[ 8.895755] bcm2708_i2c bcm2708_i2c.1: BSC1 Controller at 0x20804000 (irq 79) (baudrate 100000)
[ 9.126444] bcm2708_spi bcm2708_spi.0: master is unqueued, this is deprecated
[ 9.257354] bcm2708_spi bcm2708_spi.0: SPI Controller at 0x20204000 (irq 80)
[ 9.279932] Loading modules backported from Linux version v4.1.1-0-g6a010c0
[ 9.436150] Backport generated by backports.git v4.1.1-1-0-g8286954
[ 9.865228] cfg80211: Calling CRDA to update world regulatory domain
[ 10.444961] usb 1-1: firmware: direct-loading firmware htc_9271.fw
[ 10.471918] usb 1-1: ath9k_htc: Firmware htc_9271.fw requested
[ 10.554679] usbcore: registered new interface driver ath9k_htc
[ 10.820591] usb 1-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 51008
[ 10.882043] pcm512x 1-004d: Failed to reset device: -5
[ 10.922797] pcm512x: probe of 1-004d failed with error -5
[ 10.961416] pcm512x 1-004c: Failed to reset device: -5
[ 10.998439] pcm512x: probe of 1-004c failed with error -5
[ 11.052558] cfg80211: World regulatory domain updated:
[ 11.060320] cfg80211: DFS Master region: unset
[ 11.064885] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[ 11.082161] cfg80211: (2302000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 3000 mBm), (N/A)
[ 11.095473] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 3000 mBm), (N/A)
[ 11.108541] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 3000 mBm), (N/A)
[ 11.121931] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A)
[ 11.136820] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
[ 11.151582] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
[ 11.165278] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
[ 11.178673] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
[ 11.197591] ath9k_htc 1-1:1.0: ath9k_htc: HTC initialized with 33 credits
[ 11.650872] ath9k_htc 1-1:1.0: ath9k_htc: FW Version: 1.4
[ 11.666027] ath9k_htc 1-1:1.0: FW RMW support: On
[ 11.892007] ieee80211 phy0: Atheros AR9271 Rev:1
[ 11.942207] cfg80211: Calling CRDA for country: GB
[ 12.022667] cfg80211: Calling CRDA for country: GB
[ 12.259958] cfg80211: Current regulatory domain intersected:
[ 12.294097] cfg80211: DFS Master region: unset
[ 12.306010] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[ 12.382091] cfg80211: (2302000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 3000 mBm), (N/A)
[ 12.422126] cfg80211: (2457000 KHz - 2482000 KHz @ 25000 KHz), (N/A, 3000 mBm), (N/A)
[ 12.466076] cfg80211: (2474000 KHz - 2482000 KHz @ 8000 KHz), (N/A, 3000 mBm), (N/A)
[ 12.510031] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A)
[ 12.554102] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
[ 12.598096] cfg80211: (5490000 KHz - 5710000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
[ 12.642112] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
[ 17.306778] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)@careyer
die fehlermeldung im kernel bootlog ist zumindest bei mir die gleiche ("Target is unresponsive") wie bei dir und in dem link.
allerdings verstehe ich nicht wirklich viel davon, was in dem bug-track alles drinsteht. vorallem ist das ja schon richtig alt, sprich 2 jahre aber immer noch ein open issue.
verwunderlich auch, dass der fehler bei meinem tx mit dem 3er kernel nicht auftrat (zumindest wäre es mir nicht aufgefallen) und mit dem 4er kernel jetzt relativ häufig, obwohl beide die gleiche firmware von befi verwenden.
und wie kommen wir da jetzt weiter?
die fehlermeldung im kernel bootlog ist zumindest bei mir die gleiche ("Target is unresponsive") wie bei dir und in dem link.
allerdings verstehe ich nicht wirklich viel davon, was in dem bug-track alles drinsteht. vorallem ist das ja schon richtig alt, sprich 2 jahre aber immer noch ein open issue.
verwunderlich auch, dass der fehler bei meinem tx mit dem 3er kernel nicht auftrat (zumindest wäre es mir nicht aufgefallen) und mit dem 4er kernel jetzt relativ häufig, obwohl beide die gleiche firmware von befi verwenden.
und wie kommen wir da jetzt weiter?
@tomm,
siehe da... da hatte ich offebar den richtigen Riecher was die Problemursache in deinem Jessie-Image angeht.
ja, es scheint sich hier um einen uralt Bug zu handeln, der aber nach wie vor für Probleme sorgt. Soweit ich das richtig verstanden habe tritt es vermehrt in Kombination mit aktiven Hubs auf. Scheint wohl eine Art Timing-Problem zu sein, dass beim Laden der ath9k_htc firmware der Stick nicht korrekt initalisiert wird und das dann erst wieder gelingt, wenn der Stick einem PowerCyle unterzogen wird (selbst mit einem Reboot des Pi ist es also nicht getan, da der aktiv-Hub den Sticks ja weiter Strom spendiert). Weiterns scheint das Phänomen verstärkt aufzutreten je mehr Sticks angeschlossen sind -- ist ja auch klar. Die Wahrscheinlichkeiten addieren sich (bei mir ist die magische Grenze wohl bei 3-4). E wird in dem Link aber auch mehrfach davon gesprochen, dass einzelne Sticks einfach mitten im Betrieb (z.b. nach 1h) plötzlich mit dieser Meldung ausfallen. Das ist für einen VideoDownlink zum Fliegen natürlich kritisch.
Soweit ich das verstanden habe kann man das Problem nur umgehen, indem man das Timeout-Verhalten im Treiber modifiziert und diesen neu kompiliert. Dafür reichen leider weder meine Linux noch meine "C" Kenntnisse aus.
Glaube aber, dass das eine wichtige Sache für alle hier ist - schließlich hat keiner Spaß daran, wenn das Bild vom Kopter plötzlich einfriert nur weil sich der Treiber des WLAN-Stick in den Kopf geschossen hat. So wie ich dich verstehe tritt das bei deinem Jessie Image ja sogar schon bei einem Stick auf, richtig?
Gibt es hier jemanden, der sich gut genug mit Linux, Treibern usw.. auskennt, der das Problem angehen könnte? Ich fürchte zu mehr als Ursachenforschung und Stöbern woran es liegt kann ich hier nicht beitragen. :-/. Ich kann aber gerne beim Testen helfen, da meine 4er-Stick Lösung hier auf dem 4. Stick reproduzierbar diesen Fehler wirft.
P.S: Mit dem Befi-WifiBroadcast Code hat das also überhaupt nix zu tun. Das ist eine grundlegende Sache die den Treber betrifft. So treten die Probleme genauso mit einem jungfreulichen Weezy oder Jessie Image auf. Auch auf dem Lubuntu kommt es hin und wieder vor (wobei hier deutlich seltener - schätze der Pi hat im Vergleich zu einem Notebook einfach ein sehr ungünstiges Timing-Verhalten)
siehe da... da hatte ich offebar den richtigen Riecher was die Problemursache in deinem Jessie-Image angeht.
ja, es scheint sich hier um einen uralt Bug zu handeln, der aber nach wie vor für Probleme sorgt. Soweit ich das richtig verstanden habe tritt es vermehrt in Kombination mit aktiven Hubs auf. Scheint wohl eine Art Timing-Problem zu sein, dass beim Laden der ath9k_htc firmware der Stick nicht korrekt initalisiert wird und das dann erst wieder gelingt, wenn der Stick einem PowerCyle unterzogen wird (selbst mit einem Reboot des Pi ist es also nicht getan, da der aktiv-Hub den Sticks ja weiter Strom spendiert). Weiterns scheint das Phänomen verstärkt aufzutreten je mehr Sticks angeschlossen sind -- ist ja auch klar. Die Wahrscheinlichkeiten addieren sich (bei mir ist die magische Grenze wohl bei 3-4). E wird in dem Link aber auch mehrfach davon gesprochen, dass einzelne Sticks einfach mitten im Betrieb (z.b. nach 1h) plötzlich mit dieser Meldung ausfallen. Das ist für einen VideoDownlink zum Fliegen natürlich kritisch.
Soweit ich das verstanden habe kann man das Problem nur umgehen, indem man das Timeout-Verhalten im Treiber modifiziert und diesen neu kompiliert. Dafür reichen leider weder meine Linux noch meine "C" Kenntnisse aus.
Glaube aber, dass das eine wichtige Sache für alle hier ist - schließlich hat keiner Spaß daran, wenn das Bild vom Kopter plötzlich einfriert nur weil sich der Treiber des WLAN-Stick in den Kopf geschossen hat. So wie ich dich verstehe tritt das bei deinem Jessie Image ja sogar schon bei einem Stick auf, richtig?
Gibt es hier jemanden, der sich gut genug mit Linux, Treibern usw.. auskennt, der das Problem angehen könnte? Ich fürchte zu mehr als Ursachenforschung und Stöbern woran es liegt kann ich hier nicht beitragen. :-/. Ich kann aber gerne beim Testen helfen, da meine 4er-Stick Lösung hier auf dem 4. Stick reproduzierbar diesen Fehler wirft.
P.S: Mit dem Befi-WifiBroadcast Code hat das also überhaupt nix zu tun. Das ist eine grundlegende Sache die den Treber betrifft. So treten die Probleme genauso mit einem jungfreulichen Weezy oder Jessie Image auf. Auch auf dem Lubuntu kommt es hin und wieder vor (wobei hier deutlich seltener - schätze der Pi hat im Vergleich zu einem Notebook einfach ein sehr ungünstiges Timing-Verhalten)
Zuletzt bearbeitet:
So, das mit dem Cross-compilen ist mal sehr angenehm. Wenn man nur Im Treiber etwas ändert und schon komplett kompiliert hat, werden nur die modifizierten Dateien neu kompiliert. Treiber ändern ist dann eine Sache von unter 5min.
Leider hat sich herausgestellt, dass die Variante von Befi als auch diese hier http://yo3iiu.ro/blog/?p=1301 nichts an Link Quality und Signal Level ändert. Auch am Stromverbrauch ändert sich nichts.
Das Einzigste wo ich einen Unterschied feststellen konnte war die Änderung der dBm in der regdb. Bei 20dBm hat der Pi mit Stick beim Senden 600mA verbraucht und bei 28dBm 680mA. Bei 20dBm war das Signal level bei ca -50 und bei 28dBm bei ca -60. Dafür war es aber egal ob der Treiber gepacht war oder nicht, also sehr suspekt die ganze Sache mit der Leistung
Leider hat sich herausgestellt, dass die Variante von Befi als auch diese hier http://yo3iiu.ro/blog/?p=1301 nichts an Link Quality und Signal Level ändert. Auch am Stromverbrauch ändert sich nichts.
Das Einzigste wo ich einen Unterschied feststellen konnte war die Änderung der dBm in der regdb. Bei 20dBm hat der Pi mit Stick beim Senden 600mA verbraucht und bei 28dBm 680mA. Bei 20dBm war das Signal level bei ca -50 und bei 28dBm bei ca -60. Dafür war es aber egal ob der Treiber gepacht war oder nicht, also sehr suspekt die ganze Sache mit der Leistung
@Schalonsus: Hast du das Image von tomm auch mal getestet (siehe meinen Hiwneis weiter oben wie du das ans Laufen bekommst)
Aber deine gemessenen Werte klingen doch schon mal nicht schlecht:
600mA bei 20dbm = 100mW
680mA bei 28dbm.... ergo @5V ein Mehrverbrauch von 400mW ... rauskommen sollten 630mW (nun sinds immerhin 500 (Wirkungsgrad von 100% vorausgesetzt)...
Aber auch -50 und -60 klingt doch nicht verkehrt.
bedenke: Je 3dB sind eine Verdopplung der Leistung...
Aber deine gemessenen Werte klingen doch schon mal nicht schlecht:
600mA bei 20dbm = 100mW
680mA bei 28dbm.... ergo @5V ein Mehrverbrauch von 400mW ... rauskommen sollten 630mW (nun sinds immerhin 500 (Wirkungsgrad von 100% vorausgesetzt)...
Aber auch -50 und -60 klingt doch nicht verkehrt.
bedenke: Je 3dB sind eine Verdopplung der Leistung...
Zuletzt bearbeitet:
Laut diesem Post soll es möglich sein, auch die WN722 auf 30dBm zu boosten. Kann das mal jemand ausprobieren? Weil dann bräuchte man ja die Alfas nicht mehr, die wesentlich teurer sind...
Mit 11,49€ sind die ja echt günstig und eine externe Antenne kann man auch dran machen.
Andere Frage ist dann natürlich, ob die 30dBm, die in Linux dann angezeigt werden, nur die maximal mögliche Leistung ist, oder ob der Stick tatsächlich mehr ausgibt. Wäre natürlich gut wenn derjenige, der das ausprobiert das auch messen könnte...
Mit 11,49€ sind die ja echt günstig und eine externe Antenne kann man auch dran machen.
Andere Frage ist dann natürlich, ob die 30dBm, die in Linux dann angezeigt werden, nur die maximal mögliche Leistung ist, oder ob der Stick tatsächlich mehr ausgibt. Wäre natürlich gut wenn derjenige, der das ausprobiert das auch messen könnte...
Zuletzt bearbeitet:
- Status
