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

Status
Nicht offen für weitere Antworten.

careyer

DröhnOpaRähta
Heute kamen meine 5,8Ghz Single Patches von WA5VJB.


Habe daraufhin nochmal mit 5,8Ghz getestet... allderings bin ich etwas ratlos wieso ich so viele verlorene Pakete produziere. (war auch mit den anderen Antennen schon so - dito auf 2,4Ghz)
Bei 194.000 Paketen gehen knapp über 10.000 verloren (ca. 5%)
Empfangspegel lag durchgehend bei -30 bis -40dBm während des Tests, also nie eine schlechte Verbindung gehabt



Bei dir sah das deutlich besser aus rodizio (14 von 194.000) verloren. Hast du eine Idee woran das liegen kann?
 
Zuletzt bearbeitet:
Ich denke da liegst du richtig, allerdings sehe ich auch in der UDP Rohdaten am Tablet keine Heartbeats. Deswegen wundert mich so dass die Kombi anscheinend bei manchen Usern trotzdem funktioniert. Ich kann bei Gelegenheit den cmavnode Code ansehen, vielleicht ist da heartbeat einfach nicht implementiert, wobei das wär auch komisch.
Jetzt hab ich auch mal die CRCs im raw Log geprüft, schaut schlecht aus. Heartbeats kommen immer mit invalid CRC und deswegen schmeisst cmavnode die auch wahrscheinlich weg.

Code:
fe:09:bf:01:01:00:00:00:00:00:0a:03:51:03:03:a3:06
invalid MAVLink CRC in msgID 0 0x06a3 should be 0x1a72
--
fe:09:f4:01:01:00:00:00:00:00:0a:03:51:03:03:91:29
invalid MAVLink CRC in msgID 0 0x2991 should be 0x3540
--
fe:09:29:01:01:00:00:00:00:00:0a:03:51:03:03:c7:58
invalid MAVLink CRC in msgID 0 0x58c7 should be 0x4416
 
Ansonsten mal testweise in der /root/.profile nach diesen beiden Zeilen suchen:
TELEMETRY_BLOCKLENGTH=128
TELEMETRY_MIN_BLOCKLENGTH=20

und auf andere Werte setzen. Einfach blocklength 50, min blocklength 10 oder so. Auch in der Hoffnung, dass dadurch die Messages zufälligerweise irgendwie "richtiger" durchkommen.
Die Heartbeats sind normalerweise kleiner als 20 Byte, und der Parameter Min_Blocklength steht auf 20?
 
Alos wenn Euch das hilft, wenn ich mich recht erinnere, ist ein Mavlink-Heartbeat 15 Bytes lang.

Viele Grüße,
Stefan
Denke 15 Byte + 2 Byte CRC, aber warum kommen nur diese kurzen Nachrichten nicht richtig an? Hängt das mit dem Parameter min_blocklength zusammen?

Edit: Die Settings im 1.5 sind schon auf min_length 10 und packet 32. Allerdings heisst das nur das er unter 10 Byte nicht sofort sendet sondern erst nach dem zweiten Paket. Ich hab testweise FEC eingeschalten und min auf 8 und size auf 263 gesetzt, macht aber keinen Unterschied.
 
Zuletzt bearbeitet:
der-Frickler:
Es gibt da so eine "gehackte" Firmware bzw. Treiber für die Pi Onboard Wifi Chips: https://github.com/seemoo-lab/nexmon
Habe ich vor ein paar Wochen schonmal probiert, war alles total buggy und nicht zu gebrauchen. Hoffe das wird noch besser, irgendwann werde ich nochmal einen Versuch unternehmen, aber wird dauern.
Danke für die Info! Hatte das noch gefunden:
https://github.com/bortek/EZ-WifiBroadcast/wiki/Pi-Zero-W-support
 

rodizio1

Erfahrener Benutzer
Careyer: Kann es sein, dass Du noch zu nah warst? -30dbm ist so gerade die Grenze wo der Packetloss wegen zu starkem Signal aufhört. Probier mal ab -40dbm, dann sollte der Packetloss bis runter auf -84dbm bei Null bleiben, bei -86dbm fängt's dann langsam an mit leichtem Packetloss, ab -88dbm wird's zuviel und es gibt Glitches.

Edit: Achso, gilt nur für 5GHz, auf 2.4 in Wohngebieten gibts eigentlich immer Packetloss.

Rocket/StxShadow: Das ist echt seltsam. 17bytes incl. CRC sind richtig meines Wissens. Nur: Wie kann die CRC falsch sein wenn die Länge stimmt? Das heisst, Wifibroadcast muss irgendwie die Daten verändern? Eigentlich schwer zu glauben, das hätte doch schonmal auffallen müssen (?).

Edit: Die Settings im 1.5 sind schon auf min_length 10 und packet 32. Allerdings heisst das nur das er unter 10 Byte nicht sofort sendet sondern erst nach dem zweiten Paket. Ich hab testweise FEC eingeschalten und min auf 8 und size auf 263 gesetzt, macht aber keinen Unterschied.
Ups, hab' mich vertan, in der falschen .profile geschaut. Wie schon gesagt, Sinn macht das nicht, war nur die Idee dahinter, dass die Mavlink messages dann irgendwie anders auf die wbc Pakete verteilt werden. Die min length die man angeben muss ist 4bytes länger, 17 bytes heartbeat plus 4 =21. 20 passt also.

Der-Frickler: Ja, der Wiki Eintrag könnte falsche Hoffnungen wecken, ich schreib' nochmal dabei, dass das nicht für die onboard Karte ist, sondern nur damit er überhaupt läuft.
 
Zuletzt bearbeitet:

careyer

DröhnOpaRähta
@rodizio: Japp, das war's... War zu nah dran. Die 5,8Ghz Sticks sind einfach zu empfindlich. Auf die Schnelle mal 2 kompakte Testsender für 2,4 und 5,8 zusammen gehauen:




Gesendet von iPhone mit Tapatalk
 
Rocket/StxShadow: Das ist echt seltsam. 17bytes incl. CRC sind richtig meines Wissens. Nur: Wie kann die CRC falsch sein wenn die Länge stimmt? Das heisst, Wifibroadcast muss irgendwie die Daten verändern? Eigentlich schwer zu glauben, das hätte doch schonmal auffallen müssen (?).
Ich hab die Heartbeats direkt am Pixhawk mit denen am RX verglichen, es ändert sich immer genau ein Byte (MAV_TYPE), dadurch schlägt die CRC Prüfung fehl. Passiert allerdings ausschließlich bei Heartbeat, ansonsten funktioniert die Übertragung.

Direkt mit APM an der Seriellen vom Pixhawk:
Code:
fe:09:29:01:01:00:00:00:00:00:[COLOR="#008000"]0d[/COLOR]:03:51:03:03:c7:58
Message id 0
HEARTBEAT {type : 13, autopilot : 3, base_mode : 81, custom_mode : 0, system_status : 3, mavlink_version : 3}
Am RX im telemtry raw log:
Code:
fe:09:29:01:01:00:00:00:00:00:[COLOR="#FF0000"]0a[/COLOR]:03:51:03:03:c7:58
invalid MAVLink CRC in msgID 0 0x58c7 should be 0x4416
Edit: Zufall das die sich ändernden Bytes genau CR und LF bedeuten? Verdächtig...
 
Zuletzt bearbeitet:
D.h. aus einem CR wird immer ein LF gemacht? Hmm. Falsche stty optionen? Könnte vielleicht so ein Problem sein: https://superuser.com/questions/714078/wrong-newline-character-over-serial-port-cr-instead-of-lf

Ich schau' mir das später mal an ...
Ganz genau, aus CR wird LF gemacht, das betrifft nicht nur Heartbeats sondern eigentlich alle Messages. Mein MAV_TYPE wäre Hexacopter, und wahrscheinlich klappt das bei Usern die andere (z.B. Quad) fliegen ganz normal und es fällt gar nicht auf das hie und da Messages verschwinden.

pi@wifibroadcast(ro):~$ stty -a | grep icrnl
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff

pi@wifibroadcast(ro):~$ man stty | grep -A 1 icrnl
[-]icrnl
translate carriage return to newline

Also genau das ist das Problem.
 
Zuletzt bearbeitet:

rodizio1

Erfahrener Benutzer
Könntet Ihr mal bitte probieren in der /root/.profile "-icrnl" zu den stty optionen hinzuzufügen?

Diese Zeile suchen:
Code:
FC_TELEMETRY_STTY_OPTIONS="-imaxbel -opost -isig -icanon -echo -echoe -ixoff -ixon"
und so ändern:
Code:
FC_TELEMETRY_STTY_OPTIONS="-icrnl -imaxbel -opost -isig -icanon -echo -echoe -ixoff -ixon"
Edit: Oder mal "raw" mode probieren (sollte theoretisch alles genauso durchleiten wie es reinkommt ohne irgendwas zu interpretieren wenn ich das richtig verstehe)

Code:
FC_TELEMETRY_STTY_OPTIONS="raw"

Edit2: Oh, Dein Post in der Zwischenzeit übersehen. Ja, das scheint es wirklich zu sein. Nicht -ocrnl, sondern -icrnl.


Edit3: Das Problem muss schon die ganze Zeit bestanden haben, die stty Optionen hatte ich von hier übernommen: https://befinitiv.wordpress.com/2015/07/06/telemetry-osd-for-wifibroadcast/

D.h. auch, das ist bei _allen_ Protokollen bzw. sämtlichen Daten aufgetreten sobald da ein 0x0a bei war. Immer wenn zufällig ein 0x0a vorkam, wurde das in 0x0d geändert. Ist wohl bei den anderen Protokollen (oder bei mavlink mit anderem MAV_TYPE) nie aufgefallen, dann ist halt ab und zu ein Paket kaputt. In Eurem Fall war es so, dass das 0x0a zufällig in jedem Heartbeat vorkam.

Nice find, rocket :)
 
Zuletzt bearbeitet:
Könntet Ihr mal bitte probieren in der /root/.profile "-icrnl" zu den stty optionen hinzuzufügen?
Das klappt, jetzt stimmen alle Pakete die ankommen!
Super, dachte schon ich bekomm das nicht mehr hin. :D

Bzgl. min_block und blocklength... min_block 8 scheint besser zu funktionieren als 20.

Danke für die Hilfe!

Edit: Ein Thema hätte ich jetzt noch ;) und zwar verliert Tower nach ein paar Sekunden die Verbindung (Telemetrie), danach hilft nur neu verbinden (connect). Kennt das Problem vielleicht jemand?
 
Zuletzt bearbeitet:

rodizio1

Erfahrener Benutzer
Ist das auch mit QGroundControl so (Nur um es erstmal einzugrenzen)?

Cmavnode kommunziert über einen virtuellen seriellen Port mit dem wbc rx, vielleicht ist bei dem noch was nicht richtig (da habe ich keinerlei stty optionen gesetzt, muss mir das mal anschauen ...).
 
Ist das auch mit QGroundControl so (Nur um es erstmal einzugrenzen)?

Cmavnode kommunziert über einen virtuellen seriellen Port mit dem wbc rx, vielleicht ist bei dem noch was nicht richtig (da habe ich keinerlei stty optionen gesetzt, muss mir das mal anschauen ...).
Also bei QGC steht die Telemetrieverbindung stabil, komisch. Allerdings ist das Video da bei Bewegung stark gestört.
 

rodizio1

Erfahrener Benutzer
Macht mal bitte zur Sicherheit in der .profile auf dem RX hinter diese Zeilen:

Code:
ionice -c 3 nice socat -d -d pty,raw,echo=0 pty,raw,echo=0 & > /dev/null 2>&1
sleep 1
ionice -c 3 nice socat -d -d pty,raw,echo=0 pty,raw,echo=0 & > /dev/null 2>&1
das hier:
Code:
stty -F /dev/pts/0 raw 115200
stty -F /dev/pts/1 raw 115200
Um die virtuellen seriellen ports einzustellen.


Und zur Sicherheit noch den seriellen Port am TX auf raw setzen:
Code:
FC_TELEMETRY_STTY_OPTIONS="raw"
Damit sollte hoffentlich alles 1:1 übertragen werden.
 
Hi, ich möchte smartport Telemetrie im OSD Anzeigen. Empfangen wird das von der Taranis und per BT (hc05) weitergesendet. Typisch benutze ich ein weiteres hc05 zum Empfang (z.B. im Antennen-Tracker), aber ich frage mich ob das nicht auch mit dem internen BT des Rx-Pi3 geht. Hat das schon jemand gemacht? Einen Tip dazu? Mit dem Pi habe ich noch nicht viel gemacht..
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten