Link Quality Sensor von Tadango

FJH

Erfahrener Benutzer
#21
@Alfons Ich werde dann mal sowas als wünschenswertes Feature für die neuen ARCHER Empfänger vorschlagen. Es müsste also ein Wert auf Basis der angekommenen/verlorenen Frames/Datenpakete sein und zusätzlich zum bisherigen RSSI. Was würde für diesen Kennwert am meisten Sinn machen? Ab einer gewissen Anzahl verlorener Frames geht ja der Empfänger in Failsafe, aber so bedeuten zB 50% dann doch nicht in jedem Fall dasselbe. Ob jedes 2, Frame verlorengeht, oder ob 55 Frames hintereinander verlorengehen macht effektiv einen Unterschied und der sollte dann doch auch in der Bewertung zum Ausdruck kommen. Mit purer Anzahl der Lost Frames können die wenigsten User was anfangen und würde nur zu endlosen Nachfragen führen. Für einen solchen Qualitätswert muss es dann auch ein für den User klares Kriterium geben, wo dann mit lustig Schluss ist.
 
#22
Hallo - hat nicht irgendwer gefühlt Dutzende von Rangetests in den Failsafe veröffentlicht, mit RSSI, Lostframes und Entfernung? ;) :)
 

FPV-AH

Neuer Benutzer
#23
Hallo FJH,

Carbo hat Erfahrung mit dem Arduino Link Quality Sensor gesammelt und hat sicherlich auch die dahinter stehende Logik bzw. den Programm Code verstanden.
Ich habe da zu wenig Wissen.

@carbo,
könntest Du etwas zu dem Thema sagen und erläutern, ob Du eine Implementierung in die Empfänger-Firmware für sinnvoll erachtest und falls ja, welche Anforderungen Du vorschlägst?

Gruß

Alfons
 
#24
Gerade gesehen, für das MPM wurde mein Vorschlag Telemetrie RSSI und LQI anzuzeigen, also die Daten für den Rückkanal, gemerged. Dann kann man sich das mal vom Prinzip her anschauen. Hin- und Rückkanal verhalten sich ja sehr ähnlich. @FJH dann kansst du FrSky schon zeigen, wie so etwas aussieht ;)
 

FJH

Erfahrener Benutzer
#25
Ja, aber das spricht doch nicht gegen den Wunsch, endlich eine bewertete Anzeige der Signalqualität zu bekommen, Gerade mit dem aktuellen Hintergrund sollte man dafür jetzt mit Nachdruck pushen, Das könnten die bei Engel involvierten Spezialisten dort auch tun und Engel sollte das wohl auch als Forderung unterstützen und weitergeben an FrSky. Oder liege ich mal wieder falsch und sollte mir besser ein Bier holen? :rolleyes:;)
 
#27
Wir sollten nicht gleichzeitig posten, wie soll da ein Leser klarkommen :D
 

Sigimann

Erfahrener Benutzer
#28
Jeti stellt bspw. genauso wie Crossfire die LQ (Link Quality) dar. Ist also bei anderen Systemen wohl schon "Standard".
Da weist du aber nicht, was du bekommst. Vermutlich eine Märchenstunde.
Da gibt es wohl Auswertungen, dass erst ab >3 aufeinanderefolgende LostFrams ein Lostframe zählen.

Mit dem Tadango Zähler hast du das einzig Wahre, gnadenlos Gut.
Selbst ein einziger LostFrame wird über 100 Taktzyklen durchgereicht und zieht den Wert für 1,8 sek auf 99%.
Der Frame mit 99% wird dann bis 100 mal gesendet,
Die Information über ein einzelnes LodtFrame geht also auch in der Telemetrieverzögerung/priorität nicht verloren.

Sigi
 

Sigimann

Erfahrener Benutzer
#29
Nachtrag

Tadango macht eine gleitende Mittelwertbildung und Prozentberechnung über 100 SBus Frames.
Bei 16 Kanäle wird der SBus bei jedem zweiten Sendezyklus aktualisiert.

Bei der Überlegung wird mir der Engel-Bug immer zweifelhafter, b.z.w. nicht immer noch unvollständig Kommuniziert. Kurz: Die FrSky Strategen Mauern wie gehabt.
Sigi
 

QuadCrash

Erfahrener Benutzer
#31
Da weist du aber nicht, was du bekommst.
Das kann man so sehen, ohne Einblick in den Sourcecode zu haben.

Ohne jetzt den Source von Tadango angesehen zu haben und ggfs. die Interna zu verstehen, weiß ich aber auch nicht, ob seine Berechnung oder auch schon seine Datenquelle korrekte Werte liefert. Das "einzig Wahre, gnadenlos Gut" würde ich jedenfalls so nicht unterschreiben.
 

Sigimann

Erfahrener Benutzer
#32
Das kann man so sehen, ohne Einblick in den Sourcecode zu haben.

Ohne jetzt den Source von Tadango angesehen zu haben und ggfs. die Interna zu verstehen, weiß ich aber auch nicht, ob seine Berechnung oder auch schon seine Datenquelle korrekte Werte liefert. Das "einzig Wahre, gnadenlos Gut" würde ich jedenfalls so nicht unterschreiben.

Ich benutze den Tadango Sketch seit 3 Jahren und habe den Code gründlich angeschaut. Hier weis ich dass die Berechnung korrekt ist. Was ich nicht genau beurteilen kann, ist ob der Arduino wirklich alle Sbus Frames verarbeitet, da das nicht synchronisiert wird. Aber wenn der Arduino nichts anderes macht, sollte es reichen.

Die Datenquelle ist halt der SBus Ausgang.

Sigi
 
#33
@carbo[/USER],
könntest Du etwas zu dem Thema sagen und erläutern, ob Du eine Implementierung in die Empfänger-Firmware für sinnvoll erachtest und falls ja, welche Anforderungen Du vorschlägst?
Natürlich ist so ein Wert sinnvoll, sonst hätte ich mir den Sensor nicht gebaut. Letztlich ist das die entscheidende Information. Bisher war ich der Meinung, dass es reicht, wenn man einmal je Empfänger/Firmware auf das Verhältnis RSSI/LostFrames im Grenzbereich schaut, aber bei einem technischen Problem ist es sicher sinnvoll, die Lost Frames immer im Zugriff zu haben. Zusammen mit dem RSSI natürlich.

RSSI für die Funkstrecke, LostFrames für die Datenqualität. Die Implementation in Prozent als gleitender Durchschnitt macht sicher am meisten Sinn.

Edit. Ab Morgen wird der Sensor für den Telemetriekanal = Rückkanal des MPM funktionieren. Der ist sehr hardwarenah. Ich bin mal gespannt, wie das realisiert wurde und wie es sich "anfühlt".
 
Zuletzt bearbeitet:

oshatt

Neuer Benutzer
#34
Ist der 2N7000 richtig ? Das ist doch ein Mosfet, oder? Damit funktioniert der Sensor bei mir nicht.
Mit einen 2N2222 aber schon. Übrigens auch mit dem günstigeren Pro Mini 168..
Olaf
 
#35
Ja, ist ein MosFet, aber der funktioniert. Ich habe 2 Stück mit 2N7000 im Einsatz. Beim iNav telemetry viewer hatte ich ihn zum ersten Mal eingesetzt, auch da funktioniert er. Auch die bidi Inverter baue ich damit, das ist mein Standard.

Schaltplan
 

oshatt

Neuer Benutzer
#37
Ja, ist ein MosFet, aber der funktioniert. Ich habe 2 Stück mit 2N7000 im Einsatz. Beim iNav telemetry viewer hatte ich ihn zum ersten Mal eingesetzt, auch da funktioniert er. Auch die bidi Inverter baue ich damit, das ist mein Standard.
Sorry, der 2N7000 geht doch. Hatte wohl 2 madige im Sortiment. Beim 3ten Aufbau mit dem 2N2222 funktionierte der Sensor sofort. Deshalb die Frage.
Noch ne Frage: was ist ein "bidi Inverter" ?
Olaf
 

FPV-AH

Neuer Benutzer
#40
Das ist meine aktuelle Evolutionsstufe zum Einschleifen.
Inverter mit 2N7000 und einem 1/10W 10k Widerstand. Der 2N7000 liegt mit der flachen Seite auf dem Ardu, der linke Anschluss geht an RX zusammen mit dem 10k, der rechte wird in GND gelötet, der mittlere ist SBus Eingang. Der 10k wird dann noch zusammen mit 5V in VCC gelötet. GND und SPort (D3) fehlen noch. Der Sketch muss vor dem Anschluss von RX aufgespielt werden.

Anhang anzeigen 178913

Hallo Carbo,

wegen meinen begrenzten Elektronik-Kenntnissen habe ich mich lange Zeit nicht getraut, den Link Quality Sensor von Tadango nachzubauen.

Am verregneten Wochenende habe ich den Bau doch mal in Angriff genommen auf Basis der sehr guten Anleitung von Carbo.
Verwendet habe ich einen Arduino Pro Mini, für den SBus Inverter den 2N7000 und einen 10K Widerstand.
Wie ich anderweitig gelesen hatte soll der 2N7000 sehr empfindlich gegenüber statischen Entladungen sein, daher beim Bau etwas auf statische Entladungen achten, sonst hat man das Teil schnell gehimmelt.

Eines hat mich verwundert:
Der Link Quality Sensor funktionierte auf Anhieb ohne Murren und Knurren.

Ich habe nachfolgend mal einige Fotos von den Bauphasen angefügt.
Vielleicht animiert das noch jemanden, das Modul nachzubauen.
01.jpg

02.jpg

03.jpg

04.jpg

Gruß

Alfons
 
RCLogger

FPV1

Banggood

Banggood

Oben