EZ-Wifibroadcast, HD FPV in günstig und einfach

[herbs]

Hallo, hab das Hitzeproblem in den Griff bekommen, Kühler rauf und kein Ausfall mehr bei 0 db. Erster Test gestern mit ori Antennen, 500 m full HD sehr gut, dann weiter weggefahren - 1269 m auch noch ein Bild aber mit aussetzer, teste jetzt mit 3,5 dpi Rundstrahlantennen sobald es das Wetter zulässt.

@Gravity der 52er als RX wird bei mir auch nicht warm, nicht mal ansatzweise, aber funktioniert.

RX und TX

 

[rodizio1]

Gravity: Monitor mode war das nicht mit dem Tool. RSSI Werte sollten aber die gleichen sein wie im Monitor mode. Treiber sollten eigentlich dabei keinen Unterschied machen, bin aber nicht sicher. Gibt eigentlich nur zwei mögliche Erklärungen: Karte kaputt oder unterschiedliche Werte durch Reflexionen (indoor ist das extrem auf 5.8Ghz) bzw. übersteuern wegen zu hoher Empfangsstärke. Nochmal die Frage: Läuft es ohne Packetloss? Läuft es ansonsten "normal"? Reichweite (durch 3 Wände) scheint ja erstmal okay zu sein. Ich würde das vielleicht nochmal draussen auf freiem Feld testen (oder warten bis ich Zeit habe das mal nachzustellen).



herbs:
Hehe, okay, DER Kühklörper sollte wohl reichen Aber trotzdem wundert mich es immer noch, dass die Karte bei Dir so heiss wird ohne.



Careyer:
Ich will eigentlich lieber kein Datum nennen, dass ich dann sowieso wieder nicht einhalte

Telemetrie TX/RX ist auf jedenfall fertig, muss das ganze noch in die Skripte einbauen, Packetloss/RSSI Anzeige zum OSD hinzufügen, alles nochmal testen und dann sollte es fertig sein.

Changelog sieht im Moment so aus:
- Kernel, Pi firmware and Pi userland updated (Kernel 4.9.35, Raspbian 2017-07-05, Pi0W should work out-of-the-box)
- Latency lowered slightly (Kernel 4.9.35 improves scheduling and jitter, wbc rx -d 1 should work again)
- Mavlink R/C support (thanks dino_de!))
- Support for RTL8192CU cards added (only RX, not tested, for experimenting)
- Support for RTL8812AU cards added (only RX, not tested, for experimenting)
- Bitrate measuring on TX, simplifies FEC and bitrate settings, allows for higher bitrates
- Bitrate display on RX, shows bitrate set on TX as well as live received bitrate on RX
- New downlink and Uplink tx/rx improve telemetry down- and uplink considerably
- OSD renders only (and instantly) when receiving attitude frames, artificial horizon is smoother and less CPU/GPU load
- More efficient tx_rawsock using raw sockets instead of libpcap injection, higher bitrates possible with Pi0/1
- CPU clock lowered to 900Mhz and overvoltage lowered to "3" for less heat and power consumption
- Atheros short preamble mode: Improves CTS protection and R/C link, allows to use 11 and 5.5Mbit datarate "long-range" wifi bitrates
- Atheros medium access parameter THRESH62 lowered from 28 to 24: should improve R/C link
- Atheros medium access parameters SIFS, AIFS, CWMIN, CWMAX, etc. are configurable now
- Increased max. framesize, Atheros wbc payload 1550 bytes, Ralink wbc payload 2278 bytes
- Support for 802.11b 11mbit and 5.5mbit modes added (lower quality/higher range)
- Support for CDC ACM added (for Pixhawk USB port)
- Support for BCM2385 I2C and Toshiba TC358743 added (not tested, for B101 experimenting)
- Made video UDP port configurable (for Missionplanner)
- Cosmetic fix: cat write error message removed when ramdisk full
- Cosmetic fix: socat init messages removed
- Cosmetic fix: German "O" for "Ost" in OSD compass changed to english "E" for "East"
- Cosmetic fix: OSD RC_RSSI option re-named to WBC_RC_RSSI
- Bug fix: Serial telemetry data corruption due to wrong stty settings
- Bug fix: Pi1A+ turned out not to be 100% stable at 1000MHz CPU clock

 

[nique]

Can't wait ;-) vor allem bin ich auf Mavlink R/C support SEHR gespannt. Will heissen, Joystick/Taranis an MavlinkPC und nicht direkt an RX?

 

[Gravity]

Joystick am PC oder am RX-Pi?

 

[herbs]

hmmm,

52er Stromaufnahme vom TX ohne das er ersendet ca 40 mA, wenn er sendet 1500 mA, das wären P=U*I 5*1,46 = 7,3 Watt.

Wirkungsgrad muss sehr schlecht sein weil er so heiss wird, aber selbst bei 25% sind das noch 1850 mW, wie kann man die abgegebene Sendeleistung richtig messen?

Wenn ich den 52er an eine USB 2.0 betreibe dann bekommt er doch nur max 500 mA, die USB gibt doch nicht mehr her.

Geh jetzt is freie und mach Praxis Tests

 

[careyer]

@Gravity/nique : Joystick / Taranis (im USB Joystick mode) direkt am USB-Port des RX ;-)
@rodizio: Respekt! Geiles ChangeLog

 

[herbs]

@Gravity und an alle die es interessiert

Frequenz 5540 MHz, 2x ALFA AWUS052NH als TX und RX, RPI3 als TX, Rpi2 als RX, Stromversorung 2x UBEC 3 A, 2x Kühlkörper ICK PGA 53.3X53.3X16.5MM

Praxistest 954m und 1235m zuerst mit 3dpi Antennen am RX, und dann wechsel auf 5dpi am RX. Der TX hatte immer 3dpi Antennen.
Erster Stop 954m :



Zweiter Stop 1235m :



[video=youtube_share;DHoZ7_Y_Y68]https://youtu.be/DHoZ7_Y_Y68[/video]

Wechsel der Antennen auf Original 5 dbi



[video=youtube_share;7oaA5pqub9g]https://youtu.be/7oaA5pqub9g[/video]

und wieder beim TX



bin sehr zufrieden, Dankeschön

 

[Gravity]

Hat jemand eine Idee warum beim Zero keine Telemetrie ankommt aber beim Pi B+ schon?

 

[herbs]

auf welchen serial port hast angeschlossen?

ok serial 4 was ich sehe, schalte mal nur Bat Anzeige ein, der zero wird überlastet sein

 

[Gravity]

Nur Batterie anzeige über MAVlink geht leider auch nicht...
In der Zwischenzeit konnte ich gestern einen ersten Testflüg mit dem Equipment im Opterra machen.
Grundsätzlich vielversprechend. Aktionsradius auf Schicht .
Der 51er muss bei mir allerdings aus dem Rumpf raus den ab 400m höhe kam keine Telemetrie mehr über Hott zurück. Für den Sender war die Verbindung unterbrochen aber steuern ging immer noch.
Ich musste aber die Bitrate auf 2 ändern um immer ein störungsfreies Bild zu haben.
Ich denke das wird sich ändern wenn der TX in die Fläche kommt.
Mir ist aufgefallen das wenn man Kurven fliegt das Bild rücktet, also wie man es von Ego-Shootern kennt die Framerate einbricht. Liegt das alles nur am Zero?
Leider bekomme ich die Kamera nicht richtig eingestellt.
http://www.ebay.de/itm/Kamera-Kamer...e=STRK:MEBIDX:IT&_trksid=p2060353.m2749.l2649
Die Parameter treiben mich in den Wahnsinn. Ich bekomme kein gutes Gleichgewicht zwischen Himmel und Boden.
Negative Erinnerungen an die Runcam Swift.

 

[rodizio1]

Habe mittlerweile auch nochmal mit dem 052NH als RX getestet. Funktioniert bis ca -67dbm. Scheint also normal zu sein, zeigt wohl durch die LNAs zu hohe Werte an. Ansonsten funktioniert der ganz normal, bis ca. -65dbm null packetloss, dann packetloss, ab ca -67dbm Empfang ganz weg.

Herb: 49dbm ist bei 1.2km aber auch (selbst mit der zu hohen Anzeige des 052NH eingerechnet) nicht realistisch, seltsam.

Was auf jedenfall nicht normal ist, ist soviel Packetloss (zweite Zahl) sollte bei freiem Kanal praktisch null sein. Wenn das auf verschiedenen Frequenzen im 5Ghz band ist, dann stimmt irgendwas noch nicht, würde vielleicht mal einen Low-ESR Elko direkt an den 052nh machen.


Gravity: Serieller Port am Zero W ist wahrscheinlich ein bug bedingt durch die firmware. Auf github hat noch jemand das Problem. Wegen der Störungen: Wie schon mehrfach geschrieben, schau erst dass alles vernünftig und ohne Packetloss läuft bevor Du Einstellungen änderst. Wenn Du packetloss hast, stimmt was nicht, und es bringt nichts die Einstellungen zu ändern. Bitrate 2 bringt zwar mehr Reichweite, aber trotzdem sollte es auch stabil mit bitrate 3 laufen. Wenn nicht, stimmt was nicht mit Deiner Verdrahtung etc. Lass auch die Raspivid Einstellungen am besten erstmal auf default.

 

[rodizio1]

Hier noch ein Video mit 722n als TX und 3x 722n als RX:
https://youtu.be/UNp1QCkg6J8

 

[nique]

Nice - und das in dem Gehölze? War die Steuerung auch über wbc oder noch altmodisch ;-) ?

 

[rodizio1]

Der nutzt eine Spektrum Funke auf 2.4Ghz und wbc auch auf 2.4Ghz. Hat dadurch zwar jede Menge packetloss, aber durch die FEC Parameter auf 768/12/6 und bitrate 2 wird das im Bild nicht sichtbar (keine badblocks).


Nochmal zum OSD: Mir ist noch aufgefallen, dass der Mavlink- und Render-Code im OSD für den künstlichen Horizont mit integers (ganze Zahlen, ohne ab- oder aufrunden) läuft und damit unnötig 'grobe Schritte' gemacht hat.

Auf Kommazahlen umgestellt, jetzt sind der Horizon und die Ladders wirklich absolut butterweich und jede kleinste Lage-Änderung wird perfekt flüssig dargestellt.

 

[careyer]

Hallo rodizio, geht das mit dem künstlichen Horizont nicht ziemlich auf die GPU? Unsere Erfahrung hat gezeigt dass die GPU so ziemlich am Anschlag ist... wenn man zu viel/zu schnell darstellt, dann friert das System schon mal gerne ein. dino_de kann dir da genaueres zu sagen... er hat das Phänomen lange untersucht.

 

[rodizio1]

Macht keinen Unterschied für die GPU, habe nur die ints durch floats ersetzt, wird nicht mehr oder schneller gezeichnet, nur mit genaueren Werten.

Seit dem neuen telemetry tx/rx und der 'nur zeichnen wenn Attittude Pakete hereinkommen Änderung' (10x pro Sekunde üblicherweise), ist die Last deutlich reduziert. Vorher wurde bei jedem empfangenen Paket gerendert, auch unötigerweise wenn nur ein 'halbes' Mavlink Paket ankam (und damit keine neuen Daten zur Verfügung standen) oder auch bei Paketen die das OSD garnicht interpretiert (Knueppelstellungen oder Heartbeats z.b.).

 

[careyer]

Ahhh.. alles klar! Sehr cool! =) Danke für die Erklärung - Die Erfahrung hat gezeigt, dass man mit den Ressourcen der GPU extrem vorsichtig umgehen muss, da das ein echter Flaschenhals beim Raspi ist. Deshalb hatte dino_de in der Version die er dir zugesandt hatte das OSD schaltbar gemacht (mehrere Screens durchschaltbar sodass nicht alle Infos auf einem Screen gerendert werden müssen).

Wird zuviel gerendert kann es passieren, dass die GPU einfriert und der Prozess abstürtzt und zum Zombieprozess wird. dino_de hatte daraufhin eine Möglicheit gefunden die GPU durch eine Art Warmstart wiederzubeleben. Das sollte man als Notnagel vieleicht irgendwo noch mit einbauen ;-)

 

[nique]

Leicht OT. Wieviele USB-Ports hat ein Pi3? Klar, physisch sehe ich deren 4. Aber sind das effektiv 4, oder hängen die alle parallel am gleichen Port?

Ich verbaue den in ein grosses GCS-Gehäuse . Jetzt ist die Frage, ob ich am Boden alle 4 zum Gehäuse ziehe muss, oder nur einen und am Gehäue selbst einen Hub verbaue (damit ich auch einen Tannnbaum mit 300er Sticks habe ;-) )

 

[aBUGSworstnightmare]

Leicht OT. Wieviele USB-Ports hat ein Pi3? Klar, physisch sehe ich deren 4. Aber sind das effektiv 4, oder hängen die alle parallel am gleichen Port?

Ich verbaue den in ein grosses GCS-Gehäuse . Jetzt ist die Frage, ob ich am Boden alle 4 zum Gehäuse ziehe muss, oder nur einen und am Gehäue selbst einen Hub verbaue (damit ich auch einen Tannnbaum mit 300er Sticks habe ;-) )

Genau einen! An dem hängt dann der LAN9514 (http://www.microchip.com/wwwproducts/en/LAN9514)

 

[nique]

Tnx, aber genau dieser ist ja ein 4Port hub. Wenn ich jetzt an einem Port nochmals ein 4Port Anhänge, dann kann ich ja nicht von der gleichen Performance profitierten, wie wenn ich alle separat raus führe, oder? Wobei der datendurchsatz von einem ja schon genügen sollte...
Danke erst mal