@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.
Link Quality Sensor von Tadango
- Themenstarter Carbonator
- Beginndatum
- Status
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
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
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? 
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
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
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
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
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.
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
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".
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:
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
Schaltplan
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.
Gruß
Alfons
- Status
