Wifibroadcast - Geräte und Infosammlung

Status
Nicht offen für weitere Antworten.

rodizio

Erfahrener Benutzer
#41
#wieso max_... der Framebuffer ist immer die volle Auflösung. Du kannst ihn ja auch mal auf (w)1920 x (h)1080 setzen
#dann mit dem rotate Parameter drehen. Diese Einstellungen haben keinen Einfluss auf das Timing!
framebuffer_width=1080
framebuffer_height=1920
Ich weiss, gibt keinen Sinn und hat keinen Einfluss auf das Timing. Führt aber dazu, dass ich wenigstens eine Vollbild Konsole im Portrait mode hab. Nur framebuffer_width und height ohne _max klappt nicht, egal wie rum ich height und width definiere, egal wie rum ich mit display_rotate drehe, ist nie Vollbild. Ist irgendso ein Bug (steht im RaspberryPi.org Forum), ohne das max_ begrenzt der das wohl irgendwie intern. Klingt für mich so als ob die da irgendwo im Code gewissen Annahmen ("Bild ist immer breiter als hoch" z.B.) getroffen haben. Annahmen sind nur immer gefährlich ... Open source Frickelei halt ;)


Kämpfe gerade an drei Sachen, einmal das Timing, einmal die ganzen Bugs in Verbindung mit dem Portrait Mode und dann noch das Problem das 90 oder 270 Grad Drehung immer zu starkem tearing führt, ist völlig unbenutzbar für irgendwas mit bewegten Bildern.

Die Sache mit dem Tearing bei 90 oder 270 Grad Drehung hat ein Pi Entwickler bestätigt, ist normal und geht nicht anders. Werde dann wohl versuchen das Bild von hello_video.bin drehen zu lassen und hoffen das dass keine Nachteile hat.


Mit der Front- und Backporch Anpassung: Du meinst ich soll da einfach wild rumprobieren? Immer beide auf einmal oder einzeln? Das sind ja hunderte Möglichkeiten ... Was mich immer noch wundert ist, dass der X-Server auf meinem Notebook andere EDID Werte nimmt, als Dein Tool ausgerechnet hat. Und auch die Sache mit der Berechnung der Pixelclock, das deckt sich nicht mit der Doku. Und warum muss man die überhaupt selbst ausrechnen? Ergibt sich doch sowieso aus den anderen Werten. Jedenfalls wenn man nach der Doku geht.
 
#42
Ich weiss, gibt keinen Sinn und hat keinen Einfluss auf das Timing. Führt aber dazu, dass ich wenigstens eine Vollbild Konsole im Portrait mode hab. Nur framebuffer_width und height ohne _max klappt nicht, egal wie rum ich height und width definiere, egal wie rum ich mit display_rotate drehe, ist nie Vollbild. Ist irgendso ein Bug (steht im RaspberryPi.org Forum), ohne das max_ begrenzt der das wohl irgendwie intern. Klingt für mich so als ob die da irgendwo im Code gewissen Annahmen ("Bild ist immer breiter als hoch" z.B.) getroffen haben. Annahmen sind nur immer gefährlich ... Open source Frickelei halt ;)


Kämpfe gerade an drei Sachen, einmal das Timing, einmal die ganzen Bugs in Verbindung mit dem Portrait Mode und dann noch das Problem das 90 oder 270 Grad Drehung immer zu starkem tearing führt, ist völlig unbenutzbar für irgendwas mit bewegten Bildern.

Die Sache mit dem Tearing bei 90 oder 270 Grad Drehung hat ein Pi Entwickler bestätigt, ist normal und geht nicht anders. Werde dann wohl versuchen das Bild von hello_video.bin drehen zu lassen und hoffen das dass keine Nachteile hat.


Mit der Front- und Backporch Anpassung: Du meinst ich soll da einfach wild rumprobieren? Immer beide auf einmal oder einzeln? Das sind ja hunderte Möglichkeiten ... Was mich immer noch wundert ist, dass der X-Server auf meinem Notebook andere EDID Werte nimmt, als Dein Tool ausgerechnet hat. Und auch die Sache mit der Berechnung der Pixelclock, das deckt sich nicht mit der Doku. Und warum muss man die überhaupt selbst ausrechnen? Ergibt sich doch sowieso aus den anderen Werten. Jedenfalls wenn man nach der Doku geht.
Ich hab nicht von wild rumprobieren gesprochen bei Front- und Backporch; mir erschein es nur etwas seltsam dass die aktive Area genau symmetrisch liegen soll (hab schon einige Displays gesehen; deshalb macht mich das etwas stutzig). Nahm 4er Incremente und erhöhe Front- bei gleichzeitiger Reduzierung (selbe Größe!) des Backporch.

Doku hast du doch keine, oder? Eine Doku ist das Datenblatt des Displays, nicht was jemand in das EDID-EEPROM programmiert hat. setz den Pixelclock ebenfalls mal um 5-10% hoch. Ich fahre meine Displays die direkt am DPI hängen immer mit der max-Angabe aus den Specs.
Pixel clock muss nicht bloß active Area durchtackern, da kommt auch Front und Backporch it dazu. Hier mal als Beispiel die Timing eines 12.1in Displays mit 1280x800 pixels. Wie du da schön erkennen kannst werden für 1280 AKTIVE Pixel (max) 1880 clocks zur Übertragung benötigt.
timing.jpg

Wenn ich das richtig im Kopf habe kann der RPi max. 1920x1200 Pixels --> d.h. für den Porträtmode in FHD reicht das nicht. Mach dir doch mal ein Späßchen und nimm 1280x720pixels; wird ja auch unterstützt...
 

rodizio

Erfahrener Benutzer
#43
Hab's geschafft bei den CSL 300Mbit Sticks die Sendeleistung noch zu erhöhen. Werden jetzt richtig warm. Mit Kühlkörper auf dem Ralink Chip und ohne Gehäuse 58 Grad :D. Scheint aber sonst keine merkbaren Nachteile zu haben bis jetzt (Problem ist ja immer, dass die Signale unsauber werden können wenn man zu weit "aufdreht").
 
#45
Wie hast du das gemacht und wieviel haben sie jetzt? Geht das für 2.4G und für 5G?
Die Frage wollte ich auch gerade stellen?
Welchen Ländercode/Kanal hast du verwendet? Das höchste was ich bislang beim CSL300 gesehen habe (zumindest die Daten die er meldet) waren 30dB.

Edit: Legal sollten in DE 30dBm nur für 5,470 - 5,725 GHz nutzbar sein.
 
Zuletzt bearbeitet:

rodizio

Erfahrener Benutzer
#46
die db Zahlen die iw und iwconfig ausgeben stimmen eh alle nicht. Selbst die im Kernel bzw. im Treiber sind keine "echten", sondern nur welche zum "rechnen". Ist auch noch je nach Hardware und Treiber verschieden, von der Datenrate etc. abhängig. So ganz durchgestiegen bin ich da auch noch nicht, ist alles recht komplex.

Ländercode und Kanal ist egal wenn man das CRDA/wireless-regdb Zeugs wegpatcht und eine entsprechende db.txt nimmt.

Hab das ganze eher mit der "Holzhammermethode" gemacht.

Funktioniert für 2.4 und 5Ghz. Wieviel die Sticks jetzt absolut haben weiss ich nicht (lässt sich soweit ich weiss auch nur schwer ermitteln bei digitaler paketbasierter Kommunikation, das Medium ist immer nur wenige Mikrosekunden belegt ...), aber ich sehe ca. 4-5db mehr in der RSSI Anzeige.


In drivers/net/wireless/rt2x00/rt28000lib.c folgendes ändern:

power_ctrl immer auf 3 setzen:
Code:
	if (delta <= -12) {
		power_ctrl = [B]3[/B];
		delta += 12;
	} else if (delta <= -6) {
		power_ctrl = [B]3[/B];
		delta += 6;
	} else {
		power_ctrl = [B]3[/B];
	}

compensate_txpower funktion auskommentieren (kommt mehrfach vor)
Code:
[B]//[/B]		txpower = rt2800_compensate_txpower(rt2x00dev, is_rate_b, band,
[B]//[/B]					     power_level, txpower, delta);


CRDA/wireless-regdb wegmachen:

net/wireless/reg.c so abändern: :
Code:
/* We keep a static world regulatory domain in case of the absence of CRDA */
static const struct ieee80211_regdomain world_regdom = {
	.n_reg_rules = 8,
	.alpha2 =  "00",
	.reg_rules = {
		/* IEEE 802.11b/g, channels 1..11 */
		REG_RULE(2312-10, 2462+10, 40, 6, 30, 0),
		/* IEEE 802.11b/g, channels 12..13. */
		REG_RULE(2467-10, 2472+10, 40, 6, 30, 0),
		/* IEEE 802.11 channel 14 - Only JP enables
		 * this and for 802.11b only */
		REG_RULE(2484-10, 2484+10, 20, 6, 30, 0),
		/* IEEE 802.11a, channel 36..48 */
		REG_RULE(5180-10, 5240+10, 160, 6, 30, 0),

		/* IEEE 802.11a, channel 52..64 - DFS required */
		REG_RULE(5260-10, 5320+10, 160, 6, 30, 0),

		/* IEEE 802.11a, channel 100..144 - DFS required */
		REG_RULE(5500-10, 5720+10, 160, 6, 30, 0),

		/* IEEE 802.11a, channel 149..165 */
		REG_RULE(5745-10, 5825+10, 80, 6, 30, 0),

		/* IEEE 802.11ad (60gHz), channels 1..3 */
		REG_RULE(56160+2160*1-1080, 56160+2160*3+1080, 2160, 0, 0, 0),
	}
};



das userspace crda und wireless-regdb Zeugs de-installieren und im Kernel einkompilierte db.txt nehmen:
(Falls der Stick eine Länderkennung hat die nicht enthalten ist, die auch noch hinzufügen)
Code:
country 00:
	(2302 - 2494 @ 40), (30)
	(5170 - 5835 @ 160), (30)

country DE:
	(2302 - 2494 @ 40), (30)
	(5170 - 5835 @ 160), (30)

country US:
	(2302 - 2494 @ 40), (30)
	(5170 - 5835 @ 160), (30)

country BO:
	(2302 - 2494 @ 40), (30)
	(5170 - 5835 @ 160), (30)

country GB:
	(2302 - 2494 @ 40), (30)
	(5170 - 5835 @ 160), (30)

country CN:
	(2302 - 2494 @ 40), (30)
	(5170 - 5835 @ 160), (30)
 
Zuletzt bearbeitet:

Rangarid

Erfahrener Benutzer
#47
Naja ob das was bringt ist fraglich. Das sind auch wieder nur angezeigt Werte. Wenn der Chip im CSL300 nur 100mW kann bringt das auch nichts 200mW zu setzen weil dann immernoch 100mW das maximale ist was rauskommt...

Ob da mehr Leistung ankommt sieht man nur mit Messequipment.
 

rodizio

Erfahrener Benutzer
#48
Nein Rangarid, das sieht man auch ganz einfach mit einer anderen WLAN Karte als Empfänger. Sind halt nur keine absoluten Werte.

Das mit der Sendeleistung ist alles ein wenig komplexer als Du denkst und hängt von tausend Sachen ab. Ich habe nirgends geschrieben, dass ich jetzt 200mw aus dem Stick hole. Wahrscheinlich habe ich ihn nur näher an 100mw herangebracht.

Edit: Übrigens, auch mehr als vom Hersteller angegeben funktioniert durchaus. Mit dem Risiko, dass die Signale unsauberer (die "Schultern" werden breiter und streuen in Nachbarkanäle) werden bzw. irgendwas überlastet/zu heiss wird. Bisschen mehr geht aber meist.
 
Zuletzt bearbeitet:
#51
Jepp, echt klasse, gestern direkt mal einen bestellt bei Pihut.

Vielleicht mache ich dann endlich mal weiter mit dem Projekt....
Wäre damit ja fast was für auf nen kleinen Racer, fehlt nur noch ein kleiner und billiger 5.8er Sende-Stick der auch was taugt, hier hängt es glaub ich noch oder?
 

thomas41587

Erfahrener Benutzer
#52
Mal ein kleiner Erfahrungsbericht inklusiver zweiter Stolperfallen:

Auf der TX Seite:
Raspberry Pi 2
Alfa AWUS052NH

Auf der RX Seite:
Raspberry Pi 1 Modell B
Alfa AWUS052NH

Das v0.4 Image funktioniert ohne Konfiguration out of the box im 5Ghz Bereich, wenn da nicht die raspberry-Stolperfalle wäre ;)
Der Raspberry 2 liefert zu wenig Strom an den USB Anschlüssen, um den W-Lan Stick zu betreiben. Aber die Lösung hierfür ist ganz einfach:
Code:
sudo nano /boot/config.txt
max_usb_current=1
Nach einem Neustart klappts auch mit dem W-LAN Stick :wow:

Die zweite Stolperfalle:
Ändert man den Ländercode auf einem raspberry (OHNE Kanaländerung wohlgemerkt!), so funktioniert die Übertragung nicht mehr wirklich. Die Empfangsstärke wird noch angezeigt, das Bild war bei mir allerdings ein Farbengewirr.
Also immer den Ländercode auf beiden Raspberrys gleich einstellen :)
 

Schalonsus

Erfahrener Benutzer
#53
Mal ein kleiner Erfahrungsbericht inklusiver zweiter Stolperfallen:

Auf der TX Seite:
Raspberry Pi 2
Alfa AWUS052NH

Auf der RX Seite:
Raspberry Pi 1 Modell B
Alfa AWUS052NH

Das v0.4 Image funktioniert ohne Konfiguration out of the box im 5Ghz Bereich, wenn da nicht die raspberry-Stolperfalle wäre ;)
Der Raspberry 2 liefert zu wenig Strom an den USB Anschlüssen, um den W-Lan Stick zu betreiben. Aber die Lösung hierfür ist ganz einfach:
Code:
sudo nano /boot/config.txt
max_usb_current=1
Nach einem Neustart klappts auch mit dem W-LAN Stick :wow:

Die zweite Stolperfalle:
Ändert man den Ländercode auf einem raspberry (OHNE Kanaländerung wohlgemerkt!), so funktioniert die Übertragung nicht mehr wirklich. Die Empfangsstärke wird noch angezeigt, das Bild war bei mir allerdings ein Farbengewirr.
Also immer den Ländercode auf beiden Raspberrys gleich einstellen :)
Das mit dem Ländercode kann eigentlich nicht stimmen. Am tx hab ich GB und am rx CN und das funktioniert schon seit je her.
 

thomas41587

Erfahrener Benutzer
#55
Hab das mit dem Ländercode nochmal getestet. War letztes Mal wohl ein dummer Zufall, dass nach Umstellung des Ländercodes und anschließendem reboot die extremen Bildfehler da waren....
Was mir allerdings aufgefallen ist: Der Ländercode wird nach jedem reboot zurück gesetzt? Überschreibt wifibroadcast den Ländercode? Oder muss man den set Befehl noch mit einem Parameter (-persistent oder sowas) ausführen, damit er auch nach einem reboot bleibt?
 
#56
Ich bin ja ungern Spielverderber, aber war das hier mal die "Geräte und Infosammlung"? Reicht es nicht, das der ursprüngliche Thread immer länger wird, weil die Fragesteller zu faul zum lesen sind und somit Fragen mehrfach beantwortet werden?
Bitte nicht falsch verstehen.
 

rodizio

Erfahrener Benutzer
#57
Gerade gesehen, dass die Framerate mit der neuen V2 cam noch weiter erhöht wurde:

edit: As of rpi-update from 13/5/16, and raspbian update of 16/5/16, the mode list has been altered to more closely match the ordering on OV5647, and also to improve FOV for some modes.
- 1 - 1080P30 cropped (680 pixels off left/right, 692 pixels off top/bottom), up to 30fps
- 2 - 3240x2464 Full 4:3, up to 15fps
- 3 - 3240x2464 Full 4:3, up to 15fps (identical to 2)
- 4 - 1640x1232 binned 4:3, up 40fps
- 5 - 1640x922 2x2 binned 16:9 (310 pixels off top/bottom before binning), up to 40fps
- 6 - 720P binned and cropped (360 pixels off left/right, 512 pixels off top/bottom before binning), 40 to 90fps (120fps if overclocked)
- 7 - VGA binned and cropped (1000 pixels off left/right, 752 pixels off top/bottom before binning), 40 to 90fps (120fps if overclocked)

[...]

edit: The H264 encoder will now allow the app to request level 4.2, but will only achieve any significant gain with overclocking. An update to raspivid is in order to allow > 720P68. 720P120 is almost working reliably but requires a significant overclock (achieved on a Pi3, but not on a Pi2 yet). Settings for how much overclocking, and any other trade-offs that can be made, are still being determined.
https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=145815

720p mit 90-120fps klingt ja mal echt super.
 

rodizio

Erfahrener Benutzer
#58
Habe mal ein paar Sendeleistungen verglichen (die absoluten Werte nicht beachten, nur die Unterschiede)



2484 mhz, rx dongle 722n
---------------------------------
-45 csl 300
-41 alfa 036nh
-39 alfa 051nh
-38 tplink 822n v2
-37 tplink 722n
-31 alfa 036nha



5180 mhz, rx dongle csl-300
------------------------------------
-58-60 051nh
-76-78 csl 300


Auf 2.4Ghz ist der Alfa AWUS036NHA klar vorne, auf 5Ghz der AWUS051NH. Den AWUS052NH habe ich bis jetzt nicht zum laufen bekommen, der zieht 1.35A und dann gibt's nen USB disconnect wegen over-current. Muss mir da mal irgendwas basteln um den direkt zu versorgen.
 

brandtaucher

Erfahrener Benutzer
#59
Na toll, da habe ich mit csl300 also aufs falsche Pferd gesetzt.

Danke für den tollen Test! Kann man ohne Equipment kaum selber machen.

Der Asus052NH mit 2 Antennen sieht interessant aus. Aber was lese ich da: Export 1000mW. Hat einen Booster, den man in Deutschland abschalten kann. Interessant ....
 
Zuletzt bearbeitet:

ap103

Neuer Benutzer
#60
Habe mal ein paar Sendeleistungen verglichen (die absoluten Werte nicht beachten, nur die Unterschiede)



2484 mhz, rx dongle 722n
---------------------------------
-45 csl 300
-41 alfa 036nh
-39 alfa 051nh
-38 tplink 822n v2
-37 tplink 722n
-31 alfa 036nha



5180 mhz, rx dongle csl-300
------------------------------------
-58-60 051nh
-76-78 csl 300


Auf 2.4Ghz ist der Alfa AWUS036NHA klar vorne, auf 5Ghz der AWUS051NH. Den AWUS052NH habe ich bis jetzt nicht zum laufen bekommen, der zieht 1.35A und dann gibt's nen USB disconnect wegen over-current. Muss mir da mal irgendwas basteln um den direkt zu versorgen.
zum 052NH:
http://fpv-community.de/showthread.php?64819-FPV-Wifi-Broadcasting-HD-Video-Thread-zum-Raspberry-HD-Videolink-fon-Befi&p=922158&viewfull=1#post922158
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten