HoTT Telmetriesensor auf Jeti

enKo
Offline Autor
Senior Mitglied
Beiträge: 67
Dank erhalten: 12

enKo antwortete auf Re:HoTT Telmetriesensor auf Jeti

Posted 07 März 2017 13:58 #19

Hallo onki,

die geschätzten 5s von rchajue sind plausibel:

- 3s warten bis der HoTT-Sensor initiiert ist
- bis zu 5 Sensortypen abfragen, bis der Richtige gefunden ist. Jede Abfrage hat ~0,1s Timeout, also bis zu 0,5s gesamt
- weitere 0,5s warten. (Optimierbar)
- weitere Wartezeit durch die JetiEX

Gibt nach einem Neustart in Summe bis zu 4s, bis überhaupt was passiert und Werte gesendet werden.

Das könnte man deutlich reduzieren, wenn man den Übersetzer so gestaltet, dass er genau für ein bestimmtes HoTT-Gerät übersetzt. Ist halt dann nicht mehr flexibel.

An der Erkennungszeit beim ERSTMALIGEN anstecken will Bernd arbeiten. Bei jedem weiteren Neustart sollten es die knapp 5s von oben sein.

Was genau meinst du mit "die Werte frieren ein"? Woran genau erkennst du das?
Dass bei ausgeschaltetem Motor die Drehzahl 0 ist, versteht sich. Das Verhalten des Reglers, den BEC-Strom nicht zu berücksichtigen, muss ich leider bestätigen. Demzufolge ändert sich auch die entnommene Kapazität nicht und die Spannung auch nicht nennenswert. Es sieht also so aus als wären die Werte fix.
Oder "friert" der Übersetzer komplette ein und zeigt auch nach erneutem Motorstart nix an? Die Software stürzt quasi ab? Blinkt denn die LED noch (kurze Intervalle)? Blinken die Werte im Display der DC/DS..?

VG,
Norbert

von enKo

Bitte Anmelden oder Registrieren um der Konversation beizutreten.

enKo
Offline Autor
Senior Mitglied
Beiträge: 67
Dank erhalten: 12

enKo antwortete auf Re:HoTT Telmetriesensor auf Jeti

Posted 07 März 2017 15:08 #20

Oh je, ein Doppelpost.
Sorry.

von enKo

Bitte Anmelden oder Registrieren um der Konversation beizutreten.

onki
Offline
Platinum Mitglied
Beiträge: 2286
Dank erhalten: 791

onki antwortete auf Re:HoTT Telmetriesensor auf Jeti

Posted 07 März 2017 17:04 #21

Hallo Norbert,

so - ich habe vorhin die "richtigen" Pro mini (5V/16MHz) bekommen und mit der aktuellen Version geflasht und verdrahtet.
Als Widerstand verwende ich 4k7, weil die gerade als SMD vorhanden sind.
Ziemlich gleiches Verhalten. Nach dem anstecken blinken die Anzeige Werte am Sender ziemlich lang. Erst wenn ich Gas gebe, bekomme ich reale Werte auf den Sender.
Wenn ich das Gas wieder auf Null stelle bleiben meistens die Drehzal irgendwo stehen und auch der Strom bleibt auf ca. 2A (teste mit einer PeggyPepper ohne Prop als max. 3-4A). Wenn ich nun den Regler erwärme, ergibt das keine Änderung der Werte am Sender. Erst wenn der Motor wieder läuft springt die Temperatur auf den aktuellen Wert.
Es scheint das nur bei laufendem Motor Daten übertragen werden. Das könnte aber auch am Regler selbst liegen. Die LED blinkt recht schnell zu jeder Zeit (egal ob Motor an oder aus). Regler ist ein +T60 am R3L mit aktuellster FW. Regler FW ist mir leider nicht bekannt weil ich gerade keine Smartbox zur Verfügung habe. Leih mir vom Kumpel immer seinen Handsender zur Programmierung.

Gruß
Onki

Gruß aus dem Nordschwarzwald
Rainer aka Onki
www.onki.de
gepostet unter Verwendung von 100% recycelter Elektronen.

von onki

Bitte Anmelden oder Registrieren um der Konversation beizutreten.

enKo
Offline Autor
Senior Mitglied
Beiträge: 67
Dank erhalten: 12

enKo antwortete auf Re:HoTT Telmetriesensor auf Jeti

Posted 08 März 2017 00:40 #22

Hallo Onki,

ich teste mit einem Uno und einem Prototype-Shield bzw. Micro wegen des USB-Schnittstelle, Pro Mini's sind in den Fliegern selbst.
Die funktionieren alle, d.h. an dem Board liegt's nicht
An Empfängern habe ich RSat2's, R6, REX6, R9 und CB200 mit jeweils aktueller Firmware getestet. Versionsnummern der Firmware kenne ich nicht.
Falls das wichtig wird, prüfe ich das.

Deinen Widerstand verwenden auch viele, das sollte auch passen. Das kannst du ja mit der Jetbox oder dem Emulator in der DS/DC... probieren.
Es sollte dir

Code:

= HoTT2Duplex =
  Version 0.2

angezeigt werden.

Wenn die Sensorwerte im Senderdisplay blinken, heisst das meines Wissens, dass für diesen Sensor gerade keine Werte empfangen werden.

Dass (kurz) blinken des Übersetzers bedeutet, er hat einen Durchlauf "Werte vom HoTT-Sensor lesen" -> "übersetzen" -> "an den Empfänger weiterleiten" gemacht. Dann blinkt er einmal. Er läuft also und macht auch scheinbar seinen Job.

Kann es sein, dass der Regler bei Motor aus tatsächlich keine Werte liefert? Finde ich zwar komisch, aber hört sich so an.
Meine Brushless Control 70 +T liefern permanent Werte. Sie haben alle eine 4.x Firmware drauf.
Es gibt wohl auch eine 3.x Firmware, die habe ich aber nie getestet.

Vielleicht hilft folgendes um die Ursache zu finden:

entferne mal in der Datei "HoTTClient.h" in Zeile 33 die "//" am Zeilenanfang, so dass die Zeile beginnt mit "#define ..."
bei HoTTClient ist auch ein Beispiel-Sketch dabei. Lade den mal z.B. auf einen Uno und schließe einen HoTT-Sensor wie beschrieben an
im Arduino SerialMonitor sollte sowas in der Art zu sehen sein (hier mit einem Vario getestet:

Code:

HoTT-Test Debug connection established. Logging activated. Send any character to begin: begun. Sensor port is listening! Probing... EAM ...Response timeout GAM ...Response timeout GPS ...Response timeout Vario ... BYTE: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 Calc: 7C 89 00 90 00 F3 01 F5 01 F0 01 12 75 26 75 3A 75 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7D BE HoTT Vario found. AirESC ...Response timeout Polling... BYTE: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 Calc: 7C 89 00 90 00 F3 01 F5 01 F0 01 4E 75 30 75 30 75 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7D FA Höhe: -1m, Steigrate: 0.30m/s Polling... BYTE: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 Calc: 7C 89 00 90 00 F3 01 F5 01 F0 01 12 75 26 75 30 75 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7D B4 Höhe: -1m, Steigrate: 0.30m/s Polling... BYTE: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 Calc: 7C 89 00 90 00 F3 01 F5 01 F0 01 1C 75 1C 75 30 75 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7D B4 Höhe: -1m, Steigrate: 0.20m/s

Die Werte in der Zeile beginnend mit "Calc" sollten sich ändern, wenn am Sensor was passiert.
Bitte nicht vergessen, die Zeile 33 wieder in den Ausgangszustand zu versetzen.

VG,
Norbert

von enKo

Bitte Anmelden oder Registrieren um der Konversation beizutreten.

onki
Offline
Platinum Mitglied
Beiträge: 2286
Dank erhalten: 791

onki antwortete auf Re:HoTT Telmetriesensor auf Jeti

Posted 08 März 2017 07:16 #23

Hallo Norbert,

vielen Dank für deine Mühen. Ich bin auch gerade dabei mir eine SmartBox zuzulegen um den Reglern etwas auf den Zahn zu fühlen.
Leider bin ich nächsten beiden Tage unterwegs. Ich melde mich dann, wenn ich Neuigkeiten habe.

Für den Fall dass ich eine neue Firmware benötige. Wie ist denn der Graupner USB-Adapter verschaltet? Ich hab das Firmware Studio installiert und erkannt, dass nur USB-Seriellwandler von Silabs ordentlich erkannt werden. Kann am Regler aber kein Update anschubsen. Habe Masse und Rx angeschlossen und Tx mit 4k7 gebrückt. Die nutzen doch auch Halbduplex wie Jeti auch nur eben mit SiLabs - oder?

Gruß
Onki

Gruß aus dem Nordschwarzwald
Rainer aka Onki
www.onki.de
gepostet unter Verwendung von 100% recycelter Elektronen.

von onki

Bitte Anmelden oder Registrieren um der Konversation beizutreten.

Sepp62
Offline
Elite Mitglied
Beiträge: 294
Dank erhalten: 153

Sepp62 antwortete auf Re:HoTT Telmetriesensor auf Jeti

Posted 08 März 2017 12:48 #24

Hallo zusammen,

dieser Beitrag richtet sich primät an Norbert als Hott-Konverter-Entwickler, aber auch alle anderen sind eingeladen, sich an der Diskussion zu beteiligen.

- Die Library wird im Moment so refactored, dass wesentlich weniger Speicher verbraucht wird. Die Sensordefinition liegt dann vollständig im sogenannten "PROGMEM". D.h. man kann die Definition nicht mehr dynamisch vom Code aus beeinflussen. Es werden immer alle Sensoren verwendet, die sich in der Sensor-Struktur befinden. Damit sollten die Speicherprobleme beseitigt sein.

- @Norbert: Gibt es die Notwendigkeit Sensoren zu deaktivieren ? Würde das in der Praxis Sinn machen ? Der Sender hat die Sensoren ja zu einem bestimmten Zeitpunkt eingelernt. Eine nachträgliche Änderung macht keinen Sinn, es fehlen dann nur Werte. Wenn man die Sensoren z.B. aus dem Vorhandensein der HOTT-Sensoren ableitet, muss man zum richtigen Zeitpunkt den Sender einlernen. Doch wann findet das statt ? Man müsste dann z.B. einen Schalter vorsehen, den man drücken muss, wenn man den Einlernvorgang am Konverter aktivieren will. So richtig bedienungsfreundlich ist das nicht. Wenn das so sein soll, müsste die Library eine Funktion vorsehen, um die Übertragung des Sensorverzeichnisses explizit zu aktivieren.

Ich denke, dass ich in ca. einer Woche eine Betaversion der Library bereitstellen kann, die Speicher spart. Bei der verzögerten Sensormeldung weiss ich noch nicht was ich machen soll.

VG Bernd

von Sepp62

Bitte Anmelden oder Registrieren um der Konversation beizutreten.