https://www.rc-heli.de/board/showthread.php?t=259674Es wäre schon wichtig, möglichst keine elektromagnetischen Störungen auf dem Kabel einzufangen.
Zur Erklärung:
Das ist I²C, auch TWI genannt, weil es ein 2-Draht-Interface ist.
Im Gegensatz zum sonst in RC verbreiteten "dummen" asynchron-seriellen Interface auf einem 1-Wire (z.B. SPEKTRUM SRXL) ist das störanfälliger, hat mehr Resynchronisationsprobleme.
Der generelle Grund ist zunächst, dass, - wenn kein sog. "Bitbang" gemacht wird (in Software, Assembler Code). was man nur tut, wenn man kein I²C mehr frei hat am Microcontroller (JLog2.6's Datenbus-Interface ist Bitbang), und man tut es besser nicht, wenn man nicht Busmaster ist, als Slave interruptgesteuert sein muss, - dann ist Hardware auf beiden Seiten beteiligt, ein I²C Controller im Microcontroller. (sorry für den Schachtelsatz
)
Diese Hardware im Prozessor und ihre relativ komplexe Driver Software kann durch harten Eingriff in die Signale u.U. in einen Deadlock getrieben werden. Aus bis zum Repower oder Watchdog Reset des Interfaces.
Hier, beim Xbus kommen aber noch andere Aspekte hinzu, die ein Aufhängen des Busses noch mehr befördern:
Ein Datenpaket, woraus ein Sensor nach einem Interrupt, weil seine (Sensor-)Adresse angesprochen wurde, aussenden muss, besteht aus 16 Bytes.
Wenn jetzt die Abfrage eines Bytes durch Störung nicht ankommt, oder der Master (TM1000) die Antwort nicht hört, dann kann das Ganze asynchron werden. Grund: Die Bytes werden nicht adressiert, man fragt sie einfach nacheinander ab.
Mit JLog kommt hinzu, dass der nicht ein Sensor (Adresse) ist, sondern im Augenblick bis zu 6 (S32). Einem I²C Interface im Microcontroller kann man maximal 2 Adressen sagen, auf die er als Slave hören (antworten) soll. Weil es aber 6 sind, schalten diese sich ebenso sequentiell durch: Eine Reihe von Adressen, - immer, wenn eine 16Byte-Abfrage bedient wurde, bereitet man sich auf die nächste Adresse vor, initialisiert das I²C Interface entsprechend. Zum Glück weiß man, dass die Adressen (Sensoren) vom TM1000 nicht wahllos abgefragt werden, sondern in aufsteigender Abfolge.
Es gibt also 16*6=96 mögliche Anlässe zum Asynchronwerden, wenn jemand die Leitung stört.
JLog (und S32==JLog3) hat Mechanismen zur Resynchronisation eingebaut, die erschöpfend funktionieren. Das sind Watchdogs, die sein Interface und die das Xbus Interface kontrollierende State Machine resetten, wenn 200ms Dunkeltuten war.
(Ich habe jetzt eben Tests gemacht und noch etwas nachgelegt in S32, doppelt hält besser. Das wird dann gleich die Firmware (S32 app) 1.41)
Nun ist aber natürlich auch die andere Seite der I²C Kommunikation zu betrachten, der TM1000.
Der hat noch eine andere Hürde zu meistern: Der Sender bestimmt, ob er abfragt oder nicht. Der Sender bestimmt sogar, welche Adressen in der Reihe er fragt, - nachdem TM1000 dem Sender nach seinem initialen Scan mitteilte, welche Sensoren da sind (im Scan antworteten).
Somit ist auch das Handling der aktivierten Telemetrie-Displays im Sender beteiligt, - und dessen State Machine ist nicht wirklich fehlerfrei.
Jedenfalls passiert folgendes:
Ich stecke S32 während des Betriebs x-mal ab/an, versorge ihn dabei über einen anderen Port mit Betriebsspannung (Port 3 oder 4). Damit simuliere ich böse Störungen.
Simuliere ich immer nur einzelne Störungen (ab/an/ab/an/...), dann kann ich das ewig treiben.
Dann werde ich aber gemein: Ganz schnell immer nur ganz kurz Verbindung. Und bald: Dunkeltuten.
Wer ist schuld, wer hat sich bzgl. Xbus aufgehängt? S32?
Nö. Logic Analyzer ran, und man sieht, dass der TM1000 meist gar keine Adresse mehr fragt, manchmal noch 1..3.
Ob der TM1000 der Schuldige ist oder ein verwirrter Sender.. Who knows? Das Ganze kriegt sich nicht mehr ein, solange der TM1000 dem Sender keinen neuen Scan mitteilen darf. Dazu müssen aber beide 1x aus gewesen sein, was schon mal auf Sender-Beteiligung deutet.
Da sind wir dann als JLog am Ende mit unserem Latein, so weit geht die "Freundschaft" nicht, dass man uns die Sourcen von Sender(n) und TM1000 überlässt, um Ursache und Fix zu finden.
Offenbar gibt es keine Watchdogs dafür in den beiden, Tx und TM1000.
EDIT: Es könnte allerdings auch anders sein, sieht mir inzwischen fast so aus: Mein fickriger Wackelkontakt, der ganz böse Störungen simulieren soll, führt einfach dazu, dass die Antworten aller abgefragten Sensoren Schrott sind. Ob nun TM1000 selbst oder Sender, offenbar lautet dann die endgültige Entscheidung seitens SPEK: Die sind wech, die fragen wir nich mehr. Bingo!
Ich kann das sogar einem bestätigenden Test unterziehen: Mache ich das böse Spiel nicht zu lange, bleiben einzelne Sensoren aktiv im Sender.
Tja.., da kann ich nur untiges wiederholen: Lass das nicht SPEK sehen. dass Sensordaten zur Ungültigkeit verstümmelt werden. Also tu' alles, um Interferenzen fernzuhalten.
Das Problem für SPEK ist nicht, wenn ein beim Scan festgestellter Sensor nicht antwortet, das kann offenbar ruhig lange der Fall sein.
Das Problem ist, wenn dessen Antwort ungültig ist. (Da gibt's dann auch eine Ungereimtheit im Tx: Oft frieren die letzten Werte das gerade angezeigten Displays nur ein, statt Timeout "----" zu zeigen. Dabei bleibt es dann auch, besonders gern "Strom" und "ESC". Schaltet man dann auf das Display eines anderen Sensors im Sender, dann zeigt das Timeout.)
Ich rufe bei Meier an, jemand geht ran, ich verstehe Müller, und daraufhin beschließe ich, nie mehr beim vermeintlichen Meier anzurufen.
Wer weiß..., vielleicht haben die Entwickler mal negative Erfahrungen gemacht, das deshalb eingebaut.. z.B. massiv Fehlalarme. Das Protokoll hat ja auch keinerlei Checksumme..
Die Quintessenz ist also: Nicht der Bus hängt sich auf, - SPEK (TM1000 und/oder Sender) sind eingeschnappt wg. verstümmelter Daten.
Damit bleibt dann nur, zu sagen: Bitte mach die Strippe nicht zu lang, verdrillt und kein Drahtverhau. Bitte meide Nähe des Motors und Verlegung parallel zu Leitungen, die von dickem Strom durchflossen sind.
Vermeide auch Erdschleifen! Eine Masse! Besonders kritisch ist die Masse am Spannungssensor des TM1000. Nicht anschließen!
Anmelden
Registrieren
FAQ
Suche
, Fe und Ni. 