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

careyer · Jun 22, 2017

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?

r0ck3t · Jun 22, 2017

r0ck3t hat gesagt.:

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

stxShadow · Jun 22, 2017

Jup. Genau das selbe wie bei mir in der raw Datei.

Gesendet von meinem SM-G928F mit Tapatalk

r0ck3t · Jun 23, 2017

rodizio1 hat gesagt.:

Die Heartbeats sind normalerweise kleiner als 20 Byte, und der Parameter Min_Blocklength steht auf 20?

Schlonz · Jun 23, 2017

r0ck3t hat gesagt.:

Alos wenn Euch das hilft, wenn ich mich recht erinnere, ist ein Mavlink-Heartbeat 15 Bytes lang.

Viele Grüße,
Stefan

r0ck3t · Jun 23, 2017

Schlonz hat gesagt.:

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.

der-Frickler · Jun 23, 2017

rodizio1 hat gesagt.:

Danke für die Info! Hatte das noch gefunden:
https://github.com/bortek/EZ-WifiBroadcast/wiki/Pi-Zero-W-support

rodizio1 · Jun 23, 2017

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 (?).

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.

careyer · Jun 24, 2017

@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

rodizio1 · Jun 24, 2017

Sieht gut aus. Wie sind denn die Connex Antennen angeschlossen?

Hier noch ein Video vom letzten Test auf 5.8Ghz, stabiler Empfang bis -86dbm:
https://www.youtube.com/watch?v=meaXxDybi-Q

careyer · Jun 24, 2017

Bisher noch gar nicht... Warte noch auf die RP-SMA auf MMCX Adapter

Gesendet von iPhone mit Tapatalk

r0ck3t · Jun 24, 2017

rodizio1 hat gesagt.:

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

rodizio1 · Jun 24, 2017

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

r0ck3t · Jun 24, 2017

rodizio1 hat gesagt.:

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.

rodizio1 · Jun 24, 2017

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

r0ck3t · Jun 24, 2017

rodizio1 hat gesagt.:

Das klappt, jetzt stimmen alle Pakete die ankommen!
Super, dachte schon ich bekomm das nicht mehr hin.

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?

rodizio1 · Jun 24, 2017

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 ...).

r0ck3t · Jun 24, 2017

rodizio1 hat gesagt.:

Also bei QGC steht die Telemetrieverbindung stabil, komisch. Allerdings ist das Video da bei Bewegung stark gestört.

rodizio1 · Jun 24, 2017

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.

markus1234 · Jun 25, 2017

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

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

DröhnOpaRähta

Benutzer

Erfahrener Benutzer

Benutzer

Erfahrener Benutzer

Benutzer

Fricklomane

Erfahrener Benutzer

DröhnOpaRähta

Erfahrener Benutzer

DröhnOpaRähta

Benutzer

Erfahrener Benutzer

Benutzer

Erfahrener Benutzer

Benutzer

Erfahrener Benutzer

Benutzer

Erfahrener Benutzer

CopterFail