Sie benötigen das Kabel SPMA 9580 von Horizon für das Verbinden des SPEKTRUM TM1000 mit S32!
Konfigurieren Sie die im Terminal als “Displays” benannten “Sensoren” im Sender:
“Rx Pack” wird nur verwendet, wenn ein CVS16 im Setup ist, sollte aber immer konfiguriert sein im Sender. “Air Speed” kommt zur Anwendung, wenn ein Speed Sensor im Setup des S32 ist.
“Konfigurieren” heißt, Sensor im Sender freischalten und Alarmschwellen (auch Drehzahluntersetzung) nach Bedarf einstellen.
Port 8 wird im Augenblick als dediziert für Horizon SPEKTRUM betrachtet. Er funktioniert also immer, auch wenn man SPEKTRUM nicht als Telemetrie gewählt hat. Als passionierter Gigantomane kann man somit durchaus drei Telemetriesysteme gleichzeitig bedienen, z.B. SPEKTRUM + Futaba oder FrSky + DisplayBox==”JETIbox” für JETI EX. Ein ESC passt parallel in’s Setup.
Beispiel:
Im Beispiel haben wir sogar noch eine vierte Telemetrie im Spiel, Multiplex (SM GPS-Logger), nur dass S32 dabei der “Empfänger” (Busmaster) ist. Telemetrie #5 ist das Interface zum JIVE Pro, S32 als “TelMe”.
Horizon lässt gerade jede Menge neuer Empfänger erscheinen. Die “Menge” sind Empfänger mit der Bezeichnung AR<nummer>T. Sie sind gewissermaßen ein Merge eines SPEKTRUM Empfängers mit einem TM1000. Zusätzlich haben sie einen SRXL Anschluß. Der ist aber nur unidirektional, in der Form, wie es srxl.org propagiert. Telemetriedaten sind darüber nicht übertragbar, dafür hat der Empfänger den üblichen X-Bus (I²C). Der Single Line Receiver (nur “Summensignal”) SPM4649T (“SPEKTRUM Quad Race”) ist bisher der einzige Empfänger mit dem von SPEKTRUM modifizierten SRXL, – bidirektional, Sensordaten auf dem Rückweg. Dieser Empfänger hat keinen X-Bus. Leider muss man momentan (Jan 2017) feststellen, dass die unidirektionalen SRXL Implementierungen in den Empfängern der “T” Serie durch FBL nur nutzbar sind, wenn sie Workarounds gegen Bugs implementieren. (Es gibt ein Problem mit der Checksumme. Nun scheint sich aber herauszustellen, dass die richtig ausgegeben wird durch die neuen Empfänger, – die vorherigen Empfänger machten es falsch.)
S32 wird demnächst auch das bidirektionale SRXL als alternative Telemetrieanbindung zu SPEKTRUM unterstützen. Allerdings muss man annehmen, dass z.B. Helikopterpiloten kaum den 4649T verwenden werden.
Dafür hatte S32 jetzt auch ausreichend Aufwand mit dem X-Bus der “T” Empfänger… Will man so einen Empfänger in der bisher vom TM1000 gewohnten Weise mit S32 verwenden, nämlich beide Geräte gleichzeitig starten (Rx bekommt Spannung, versorgt S32 via X-Bus), dann braucht S32 dafür einen modifizierten Bootloader Version 1.8 (oder später evtl. höher). Führt man das Update nicht durch, verwendet weiterhin Bootloader Version 1.6 oder 1.7, dann kann man sich nur dadurch behelfen, dass man S32 ca. 10 Sekunden VOR dem Empfänger Betriebsspannung gibt. Ansonsten kann der Sensor Scan des Rx nichts finden. — Für JLog 2.x muss man diesen Workaround grundsätzlich anwenden, Modifikation seines Bootloaders ist unmöglich.
“Modellbau”… eigentlich ein disqualifizierendes Wort in Bezug auf die Qualität von Design und Ausführung so mancher angebotener Geräte.., leider. Dokumentation bzw. Storyboard, so etwas scheint den Entwicklern allgemein ein Unwort zu sein. Wie kann es sonst kommen, dass sich die Developer bei JETI seit vielen Jahren nicht einmal darauf einigen können, ob ihre Terminals (Sender, Profibox) große, kleine oder beide Buchstaben als Alarmcode akzeptieren? Kleine Teams brauchen nicht automatisch auch nur kleine Organisation. In der Softwarentwicklung funktioniert es nicht ohne.
Bei Horizon in der SPEKTRUM Empfängerentwicklung,scheint es nicht anders zuzugehen. Obwohl via Andy Kunz, rühriger Entwickler der Transmitter Devision, seit 2011 mehrfach übermittelt, wie unsinnig der Sensor Scan des TM1000 designed ist, dass er einen Multisensor wie JLog (5 Sensoren (Busadressen) in einem) vor unnötige Spezialaufgaben stellt, …, – alles in den Wind. Wir machen alles neu, nur noch viel schlimmer:
TM1000: Der Sensor Scan startet unmittelbar nach Powerup des TM1000. Ein komplexeres Gerät mit Bootloader und etwas ToDo (oder Warten, nämlich auf eine SD Card) beim Startup, wie JLog, bekommt dadurch Trouble. Schließlich erwartet der Scan komplette Datenpakete als Antwort.. und wenn das nun nicht in den Speicherbereich des Bootloaders passt? (JLog2.x) — JLog2.x, bis heute auch S32 (JLog3), behalfen sich damit, dass sie den Bus aufhielten, bis sie bereit sind, im verfrühten Scan zu antworten. Das ist einfach und busprotokollgerecht, indem man die SCL Leitung auf Low zieht. – Das Unsinnige an dem Scan ist: a) unnötig früh nach Powerup ausgeführt, b) ganz schnell die wesentlichen, heute und in 100 Jahren Sensoren (Displays) zugeordneten Adressen abgefragt, nämlich zuerst. Wer nicht anwortet, dessen Daten werden im Weiteren nicht abgefragt, das Display im Sender bleibt inaktiv. Beim TM1000 ist nach 3,6 Sekunden der Drops gelutscht, wenn man nicht das Bremspedal findet.
TM1000
Bis zum Start des Scan nach Powerup dauert es nur 60ms:
dann fragt man im Abstand von 13ms jede Sensoradresse zweimal, – und zwar in aufsteigender Reihenfolge, die wichtigen (zugewiesenen) Adressen zuerst, – der Karteileichen der fernen Zukunft später:
(Oben: Man sieht JLog eine Abfrage beantworten. Unten: Zweimal gefragt.)
.
Doch die Developer der “T”, frisch importiert oder zuvor “geblitztdingst”, verstanden es hervorragend, Third Party ignorierend, noch ein ganz dickes Ding oben drauf zu setzen. “Was heißt hier <schlimm>, – es geht schlimmer.”
Den Bus über SCL anzuhalten: Das geht noch von Hand, aber nicht mehr durch einen Microcontroller als Buspartner, jedenfalls nicht, wenn es kein Spielzeug ist. Grund: Zwei Geräte werden gleichzeitig erweckt, indem sie Betriebsspannung erhalten, – werden vom Zombie zum “bewussten Wesen”. Es ist völlig normal, dass auf einer Leitung wenigstens ein Spike erscheint, bevor diese funktionsbereit ist. Mit ATMEL, Microchip &Co. der alten Fasson konnte man eventuell Glück haben, bzw. das durch Fummeln unterdrücken. Mit den heute üblichen ARM Architekturen der Microcontroller geht das nimmermehr. Eine komplexe Taktzentrale muss anlaufen, bestehend aus x PLLs (Phase Locked Loop) und Teilern, Power Domains sind zu aktivieren, dann die Komponenten der Pin-Funktionen zu initialisieren. Der SPEKTRUM-Entwickler sollte das wissen, sind doch in den “T” Empfängern STM32F0. Eigentlich ist das alles nicht der Rede wert, sofern der Buspartner korrekt implementiert ist. Sofern.., ist er aber nicht. Sobald er auch nur einen winzigen Spike auf SDA sieht, während man SCL als Scan Bremse auf Low zieht, dreht der Service Handler des Empfängers durch, indem er selbst SCL bis in alle Ewigkeit auf Low bringt, den Bus blockiert, Amen:
AR9030T
(Wir haben Glück mit dem CVS16 mit der “SPEKTRUM direct” Firmware, obwohl es auch ein ARM ist.)
Man ist ja nicht schadenfroh, – trotzdem freue ich mich auf den nächsten Sensor von SPEKTRUM. Der wird einen ARM als MCU haben, 100 Pro. Da kommt dann selbst eingebrockte Freude auf bei den Entwicklern, - in etwa so wie bei JETI, indem man 9 Datenbits, plus Parity, plus 2 Stopbits unbedingt verwenden musste, bzgl. dessen ein UART in einem ARM die Trillerpfeife zeigt. Bingo, Software-UART lässt grüßen (REX Empfänger), also schnell die Flucht nach vorn antreten, schön brav mit 8 Datenbits: EX “Bus”.
Ok.., da hilft nur, sofort zu Diensten zu sein für den fehlerhaften Empfänger. Eigentlich ist das ungewollt, weil man zuvor wichtigere Dinge zu tun hat.. Zum Glück passt es noch in den Bootloader des JLog3 (S32), im Bootloader Memory des JLog2.x aber keine Chance. Da haben wir den Scan des Empfängers, 5x antwortet S32:
Hey, 75ms für alles, nach 35ms sind alle existierenden Sensoren abgefragt. Wie gesagt, der Empfänger “leidet” selbst unter ARM. Er beginnt sein Werk nicht nach 60ms wie der TM1000, sondern braucht selbst >320ms:
Schade, dass er nicht länger braucht.. Zwischen den Abfragen unterschiedlicher Sensoradressen liegen nicht 13ms, wie beim TM1000, sondern es sind nur ca. 0,4ms:Das hier ist dann schon die Härte, denn JLog ist ein Multisensor, muss sich zwischendurch uminitialisieren, um auf weitere Adressen zu antworten: ca. 14 Mikrosekunden, eher noch viel weniger bezüglich I²C:
Da muss man doch mal fragen: Tut denn das Not?! Rhetorische Frage.. — Jede Adresse wird auch nur noch 1x gefragt:
Ok, wenn’s dann doch endlich geht (Danksagung Richtung Horizon für den Stress), guckt man verzückt auf ein funktionierendes System:
Vorn der Scan (dicker Strich), mit dem man es so supereilig hat, dann als Lohn der Angst die Abfragen.
Da einem keine Zeit gelassen wird, zuerst seit Setup auszulesen, stellt man beim Scan das Bein in die Tür, antwortet für alle potentiell zu verwendenden 5 Sensoren. Später aber antwortet man nur noch auf Datenabfragen im Setup wirklich verwendeter, wodurch ein anderer Sensor auf dem Bus die Chance hat, den dann frei werdenden Sensor zu nutzen. Im folgenden Screenshot sieht man es (die dünnere Linie), — aber eigentlich soll es etwas anderes zeigen:
Die im Scan gesehenen Sensoradressen werden reihum abgefragt, 64ms jeweils dazwischen. Bedeutet bei z.B. 5 Sensoradressen (JLog-Standard): 5x 64ms = 320ms zum Updaten eines Datensatzes. Schon lustig.., erst hat man es so unsinnig eilig, dann trieft man? Oder ist das einfach der eingangs mutmaßten Tatsache geschuldet, dass man kein eindeutiges Lastenheft hatte? — Jedenfalls, der TM1000 kann es schneller: Alle 64ms ein Datensatz zur Abfrage, 20ms zwischen den Abfragen der zum Satz (laut Scan) gehörenden Sensoren. Ergo bei 5 Sensoren: 64ms + 4x 20ms = 144ms:
Soweit FYI. Nichts menschliches ist uns fremd, – im Modellbau schon gar nicht.
Dank an Markus für das Bereitstellen seines Empfängers!
———————————————————————————
Leute.., ich habe eben bei rc-heli gelesen, wie man sich aufgrund meines Inputs über SPEKTRUM “echauffiert”. Ja, ich gebe zu, ich habe mich erst mal mächtig echauffiert. Grund dazu bekomme ich aber als “gebeutelter JLog zwischen allen Stühlen” alle naselang, und zwar potentiell durch jeden Hersteller eines Telemetriegeräts oder ESCs. In diesem Sinne ist SPEKTRUM nicht das Übel, sondern das Übliche. – Heutzutage ist Software die Funktion, Hardware nur das Mittel zum Zweck, – wenn beide auch genau “zueinander passen” müssen. Software kann dem Gerät viel mehr und viel flexibler Funktion einhauchen. Entsprechend komplex wird es in der Software.. Geeignete logistische Mittel für Planung und Ausführen der Softwareimplementierung (und des Testens!) sind eigentlich erforderlich. Diese liegen quasi auf der Straße.., JIRA, Git/Bitbucket, Jenkins, Confluence etc.pp. Allerdings.., als einzelner Entwickler eines Projekts muss man deren Benutzen schon mit der Muttermilch aufgesogen haben, um es auch für sich allein zu tun. Man muss ziemlich jung sein, gewissermaßen damit aufgewachsen sein. Dreimal könnt Ihr raten, wie meinereiner mit seinen 61,5 eigentlich dazu steht. Dann, ziemlich wichtig, zu erwähnen, – man hängt dabei auch vom Tun anderer Beteiligter ab! Irgendwer muss ja mal das Storyboard definiert haben (Lastenheft), – am Ende muss das ein anderer (Marketing) auch zur Benutzung zum Kunden transportieren.. An der Stelle hapert’s einfach noch allenthalben. Die Technik entwickelt sich grundsätzlich rasant schnell, die Organisation meist nicht. Deshalb war mein “nichts menschliches ist uns fremd” durchaus im Sinne von kollegialem Verständnis gemeint. – So was fällt schwer, klar, wenn man eingangs das Messer wetzte. Wenn man den Workaround dann aber hat, lehnt man sich zurück und versteht, warum der Anlass entstehen konnte. Alles klar?
———————————————————————————
Was mich von Anfang an an der RC-Anbieterszene störte, ist dieses vorherrschende Abstecken eines Claim. Bloß nicht über den Tellerrand des eigenen Portfolios schauen. (Es gibt Ausnahmen, die versuchen es zumindest.) Dabei kann man technisch kooperieren, ohne sein eigenes Geschäft zu schmälern, – im Gegenteil, da es zum Wohle der Käufer wäre, wäre es auch gut für’s Geschäft beteiligter Parteien. Ok, das ist höchstens ein Biertischthema, – es ist, wie es ist, momentan. —- Jetzt hält aber “Datentechnik” massiv Einzug in die Modelle. Gerade im Timing des Startup, siehe so einen Anlass oben, ist es einfach erforderlich, über den selbst limitierten Horizont zu schauen. Ganz profanes Beispiel, was gerade die Gemüter bewegt: Es ist unüberlegt, als FBL sofort nach Powerup an den Servos (allen!) rumzumachen. Braucht eine vernünftige Stromversorgung vielleicht ein paar Millisekunden, bevor man sie massiv belasten kann? Könnte es sein, dass die “Intelligenz” eines modernen Servos auch nicht instantly nach Powerup auf der Matte steht? Für den User ist sein Setup immer ein System, in dem die Komponenten sinnvoll miteinander tun sollen. Man kann es leider nicht erzwingen nach dem “Allesauseinerhand”-Prinzip, also darf einem der Kram des Mitbewerbs nicht schnuppe sein, weil es der Kunde nicht ist.
———————————————————————————
–> Bootloader 1.8
Nur durch Update auf diesen Bootloader kann S32 parallel mit einem
der neuen SPEKTRUM Empfaenger mit X-Bus gestartet werden, und die
Sensoren des S32 werden vom Scan des Empfaengers gefunden.
(Mit einem aelteren Bootloader des S32 funktioniert der Scan durch
einen dieser neuen Empfaenger nur, wenn S32 ca. 10s VOR dem Empfaenger
Betriebsspannung erhaelt!
Der TM1000 ist nicht betroffen, er funktioniert auch mit einem aelteren Bootloader.)
–> Bootloader 1.9
Fuer SPEKTRUM X-Bus: S32 stellt nun einen sechsten Sensor dar: 14S LiPo
wenn CVS16 in der Konfiguration ist.
Das hat eine Aenderung am Bootloader erforderlich gemacht.
Korrespondierende App Mindestversion: 1.33
(Enthaltenes voriges Update: 1.8)
S32 als Sensor 14S LiPo
Minimal darstellbarer Wert: 2,56V, Maximum: 5,10V. Zelle 2 bis 14: Ein Zellendisplay und das der nachfolgenden verschwindet, wenn die Spannung der korrespondierenden Zelle unter 2,56V fällt.
CVS16 im sog. “Pack Mode”: Nur aufeinanderfolgende Zellen werden angezeigt.
CVS16 nicht im Pack Mode, als 16-Pin Voltmeter: Alle 16 Pin Spannungen werden angezeigt, “2,56V”, wenn unterhalb eines bestimmten Wertes, “5,10V”, wenn darüber: Pins 1..8: 2,56 bis 5,10V, Pins 9..14: 25,6 bis 51,1V, dargestellt als “2,56V bis 5,10V”
“Rx Pack” wird nur verwendet, wenn ein CVS16 im Setup ist, sollte aber immer konfiguriert sein im Sender. “Air Speed” kommt zur Anwendung, wenn ein Speed Sensor im Setup des S32 ist.
——————————–
(JLog2.x) — JLog2.x, bis heute auch S32 (JLog3), behalfen sich damit, dass sie den Bus aufhielten, bis sie bereit sind, im verfrühten Scan zu antworten. Das ist einfach und busprotokollgerecht, indem man die SCL Leitung auf Low zieht. – Das Unsinnige an dem Scan ist: a) unnötig früh nach Powerup ausgeführt, b) ganz schnell die wesentlichen, heute und in 100 Jahren Sensoren (Displays) zugeordneten Adressen abgefragt, nämlich zuerst. Wer nicht anwortet, dessen Daten werden im Weiteren nicht abgefragt, das Display im Sender bleibt inaktiv. Beim TM1000 ist nach 3,6 Sekunden der Drops gelutscht, wenn man nicht das Bremspedal findet.
