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

Status
Nicht offen für weitere Antworten.

herbs

Neuer Benutzer
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
 

Anhänge

rodizio1

Erfahrener Benutzer
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

Legal-LongRanger
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

Erfahrener Benutzer
Joystick am PC oder am RX-Pi?:confused:
 

herbs

Neuer Benutzer
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:confused:
 

herbs

Neuer Benutzer
@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 :

MP_2.jpg erster_stop.jpg erster_stop_2.jpg erster_stop_3.jpg

Zweiter Stop 1235m :

MP_1.jpg zweiter_Stop_1.jpg

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

Wechsel der Antennen auf Original 5 dbi

zweiter_Stop_2_1.jpg

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

und wieder beim TX

home_1.jpg home_2.jpg

bin sehr zufrieden, Dankeschön:wow:
 
Zuletzt bearbeitet:

Gravity

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

herbs

Neuer Benutzer
auf welchen serial port hast angeschlossen?

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

Gravity

Erfahrener Benutzer
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

Erfahrener Benutzer
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.
 

nique

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

rodizio1

Erfahrener Benutzer
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

DröhnOpaRähta
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

Erfahrener Benutzer
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

DröhnOpaRähta
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 ;-)
 
Zuletzt bearbeitet:

nique

Legal-LongRanger
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 ;-) )
 
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

Legal-LongRanger
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
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten