Link Quality Sensor von Tadango

Mit 2.01 siehst du nur die gefakten Lost Frames, also erst kurz vor Failsafe. Geh zurück auf die Vorgängerfirmware und mach den Test noch mal. Die Alternative ist, den Sensor auf die ReinhardZ Firmware zu flashen und einen "Servotester" im Sender laufen zu lassen. So sieht man dann auch mit 2.01 die Wahrzeit.
Storchy.jpg
 
Man muss mit meiner SW den 'Servotester' nicht unbedingt laufen lassen. Wenn man das nicht macht, haben die Sensorwerte 5102,5103 halt keine Bedeutung. Der Tadangowert auf 5100 und der Wert von Kanal 8 (was auch immer da drauf liegt) stimmen aber.
 
Danke für die Info. Aber das ist mit 2.01 dann trotzdem sinnlos. Ich habe ein bisschen Hemmungen, deinen Sketch immer draufzumachen, weil er den SPort schon ziemlich stresst. Das ist OK zum Testen, aber dauerhaft würde ich den Sensor so bei mir mit der restlichen Hochleistungs ;) Telemetrie nicht nutzen wollen.

Ich denke FrSky muss einfach wieder den echten Wert auf den SBus geben, alles andere ist Betrug. Deine Firmware soll dabei helfen. Ansonsten rühre ich V2 nicht mal mit spitzen Fingern an.
 
Der SPort wird nicht gestresst, der sendet immer alle 12ms seine Daten, egal ob ein Sensor angeschlossen ist oder nicht. Nur die Update Rate für die Sensor Info kann runtergehen, wenn mehrere Sensoren angeschlossen sind (z.B. eine zusätzliche Flight Control mit Telemetrieausgabe oder ein zusätzlicher OpenX-Sensor).

Wenn ein Sensor auf dem SPort liegt, läuft das SPort Timing folgendermaßen:

ms
0 ------ 'bekannter Sensor A' sendet einen 32Bit Wert, z.B. ID 5100
12 ---- Empfänger fragt 'unbekannten Sensor' #1 an (keine Antwort, wenn nicht angeschlossen)
24 ---- 'bekannter Sensor A' sendet einen 32Bit Wert, z.B. ID 5101
36 ---- Empfänger fragt 'unbekannten Sensor' #2 an (keine Antwort, wenn nicht angeschlossen)
48 ---- 'bekannter Sensor A' sendet einen 32Bit Wert, z.B. ID 5102
60 ---- Empfänger fragt 'unbekannten Sensor' #3 an (keine Antwort, wenn nicht angeschlossen)
72 ---- 'bekannter Sensor A' sendet einen 32Bit Wert, z.B. ID 5103
84 ---- Empfänger fragt 'unbekannten Sensor' #4 an (keine Antwort, wenn nicht angeschlossen)
96 ---- 'bekannter Sensor A' sendet einen 32Bit Wert, z.B. ID 5104
108 --- Empfänger fragt 'unbekannten Sensor' #5 an (keine Antwort, wenn nicht angeschlossen)
120 -- 'bekannter SensorA' sendet einen 32Bit Wert, z.B. ID 5100
132 --- Empfänger fragt 'unbekannten Sensor' #6 an (keine Antwort, wenn nicht angeschlossen)
usw.

Der Sensorwert 5100 wird hier also bei jeder 5. Abfrage aktualisiert. Bei der Original Tadango SW wird der 5100 Wert auch nur bei jeder 5. Abfrage des Tadango-Sensors aktualisiert (k.A. warum, vielleicht hatte Tadango in seiner 1. SW Version Probleme alle 24ms einen aktuellen Wert zur Verfügung zu stellen. Seine Pufferspeicher waren mit long Variablen indiziert, jetzt sind sie aber auf 100 Werte reduziert, was die Prozentberechnung sehr einfach macht), dazwischen wird der Wert auf 'nicht verfügbar' gesetzt.

Ich bin auch mal gespannt, ob FrSky bei dem FL-Bit in der V2.x einen Rückzieher macht. :unsure:
 
Zuletzt bearbeitet:
Habe mir auch mal einen solchen Sensor gebaut...
LinkQualitätSensor.jpg

SMD, tolle Idee :wow:

gelötet, geflucht, programmiert und funktioniert sogar :D

Sensor2.jpg

Für den Fall, das jemand etwas mit einer Beschriftung zum aufhübschen anfangen kann, hänge ich sie mal hier an. Das .dxf kann nach Bedarf angepasst werden.

LinkQuality.zip
 

Anhänge

Hast du einen 3,3V ProMini genommen (weil du auf RAW die 5V Versorgung hast) ?
Da läuft dann nur die Original Tadango SW.
Ich habe auch den Ardu über RAW mit 5V versorgt. Das geht auch mit deinem Sketch einwandfrei. Und man muss nicht so aufpassen, wenn man den Sensor mal mit höherer Spannung versorgt. Mein GPS/Vario läuft sogar noch mit 3V, dann natürlich über VCC eingespeist.
 
OK. Wir hatten ja mal beim Stromsensor über die Versorgung diskutiert. Da hatte ich auch erst über RAW versorgt und dann auf Vcc gewechselt. Da macht das auch Sinn. Aber ihr habt recht, wenn die 5V nicht als Referenzspannung benötigt werden, kann man auch über RAW versorgen. Muss ich schon wieder umlöten :(
 
Ich habe die SW für den FL-Sensor nach @bionicbone Methode nochmal etwas überarbeitet:
1. Verwendung von adaptiven Triggerschwellen für bessere Übereinstimmung FrSky/BB Frame Loss
2. Failsafe Handling für BB-Bit verbessert
3. Auf speziellen Wunsch ;) Ansteuerung der LED auf dem Arduino um entweder
- LED nicht benutzen
- Frame Loss nach @bionicbone Methode anzeigen
- Frame loss entsprechend dem FL-Bit vom SBus anzeigen
Mit den #define Anweisungen kann man das gewünschte Verhalten definieren:
1581863930919.png
Man könnte auch eine externe LED anschließen (Anode an Pin des Arduino über 330 Ohm, Kathode an Masse). Dann muss der entsprechende Digital-Pin des Arduino mit der #define PCB_LED Anweisung umdefiniert werden.

Hier ein Testlog:

1581864083921.png
 

Anhänge

Gruni

Erfahrener Benutzer
@Stoschek : Ich bau den Inverter auf einem separaten Stückchen Lochrasterplatine auf und schließe mit kurzen Litzen an. Das erspart mir das rumbraten auf der Arduinoplatine.
Haste aber trotzdem am Ardu gebrutzelt, Dann hätte ich, was ich wohl auch mache, Headerpins reingelötet und die Chaouse auf Raster gesetzt. ;->
Jetzt sollte der Messwertepool langsam zusammenkommen und an entsprechende Zweifler weitergereicht werden.

Grüsse Gruni
 
Ich finde die Stelle nicht mehr wo die "Klicks" definiert wurden und die entsprechende Frequenzdrift. Sind das die +/- Schritte auf dem MPM?

Reinhards LQBB4 macht nur Sinn, wenn man 2.x geflasht hat, ansonsten zieht das Tadango, richtig?
Wenn das klar ist, werde ich mal meine RXen auch dem Prozedere unterziehen und die Ergebnisse hier zur Verfügung stellen.
 
Ich finde die Stelle nicht mehr wo die "Klicks" definiert wurden und die entsprechende Frequenzdrift. Sind das die +/- Schritte auf dem MPM?
Genau, 1 Klick sind 1,5kHz. Schön, dass noch mehr Daten kommen!
Reinhards LQBB4 macht nur Sinn, wenn man 2.x geflasht hat, ansonsten zieht das Tadango, richtig?
Ich sehe es ach so. Mich machen die vielen Daten von @ReinhardZ nervös, aber man kann seinen Sketch auch für V1 nutzen. Aber da V1 noch ehrlich ist, mache ich V1 mit Tadango und das große Geschütz kommt erst mit V2 auf den Ardu :)
 
Ihr braucht nicht nervös werden, meine SW und Tadangos erzeugen die gleiche Bus-Last.Ich werde bei Gelegenheit nochmal den Logic Analyzer anschmeißen. Aber ich verstehe, dass man bei V2 (bzw. V4) Software erstmal skeptisch ist ;)
 
Ich hab 3 TXe (1x MPM) . Nehme mal an, dass keine der abgestrahlten Frequenzen identisch ist und jede Bindefrequenz eine andere. Was verwendet ihr für bezahlbare Messmittel um festzustellen wo nun die tatsächliche Frequenz liegt oder genau liegen soll? Außer beim MPM kann man keinen Fangbereich bestimmen/ermitteln, um hinterher die Drift zu sehen. Wäre dies auch bei den internen HF Modulen möglich, so könnte ich auf jedenfall den Abstand untereinander bestimmen und abschätzen, welcher TX zu den außreißern gehört (siehe flackernde Led).
 
Wenn du die Empfänger schon gemessen hast, dann binde doch einfach die Extremsten (vorzugsweise die neuen Typen) an alle Sender. Dann siehst du, ob die Kombinationen alle im Fenster sind.
Bindefrequenz genau messen ist schwierig.
 
Wer es sich zutraut, kann seinen Sender tune-bar umbauen, z.B. mit Poti S1.
Der optimale Poti-Wert läßt sich in OTX für jedes Model speichern und anzeigen.
Poti Einstellung / Abstimmung manuell für jedes Modell.
(Für das MPM macht das OTX automatisch)
Sieh Schaltplan.
Damit läßt sich die Senderfrequenz zwar nicht absolut messen, aber optimal auf den Empfänger einstellen, wie beim MPM.
 

Anhänge

Zuletzt bearbeitet:
RCLogger

FPV1

Banggood

Banggood

Oben