J-Log.eu - Forum

JLF ------ SPAM Bots! Bitte nach Registrierung eine Email an mich zur Freischaltung! / After registration drop me an email please for clearing! ===Nenne/name the NICK you used to register with!=== Email address: -> http://j-log.eu/impressum
Aktuelle Zeit: 13. Mär 2020, 10:52

Alle Zeiten sind UTC + 1 Stunde




   [ 11 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Autor Nachricht
 Betreff des Beitrags: SPEKTRUM SRXL
Verfasst: 18. Feb 2017, 03:33 
The Madman from Laboratory 4

Registriert: 8. Jun 2011, 14:28
Beiträge: 4760
Release Notes:
Zitat:
Note 34: 18.02.2017: S32 app 1.35, S32T 2.1.1.32 ==> SPEKTRUM SRXL (Rx SPM4649T) Telemetrie und S32 gleichzeitig als Remote Receiver (“Sat”) –> FBL. siehe


"siehe" ist das: http://j-log.eu/s32/s32-de/telemetrie-spektrum-srxl


_________________
Tom


Nach oben
   
 
 Betreff des Beitrags: Re: SPEKTRUM SRXL
Verfasst: 18. Feb 2017, 12:51 

Registriert: 3. Jan 2017, 16:29
Beiträge: 70
Hi Tom,
hört sich alles gut an!
Also wird im FBL in den Sat Eingang eingespeist selbst wenn das FBL einen SRXL Eingang besitzen sollte oder?
Dann könnte man doch den meist ohnehin vorhanden zweiten Sat Eingang mit einem weiteren Sat versehen?
Ich habe auch gelesen das der SPM 4649T selbst keine Empfängerspannung (Anschlußspannung des 4649T) überträgt wie es das TM1000 ja macht.
Wird die RX Spannung jetzt irgendwo angezeigt? Für mich wäre es wichtig das man in diesem Sender Display einen Alarm für die RX Spannung eingeben kann (im ESC Display wäre dies zB. nicht möglich).
Da ich die Linus Caps installiert habe würde ich ohne live Alarm des RX dessen Ausfall nicht mitbekommen.

Gruß
Werner


Nach oben
   
 
 Betreff des Beitrags: Re: SPEKTRUM SRXL
Verfasst: 18. Feb 2017, 14:35 
The Madman from Laboratory 4

Registriert: 8. Jun 2011, 14:28
Beiträge: 4760
Man kann in einen SRXL Eingang eines FBL einspeisen oder in einen Sat Eingang (Remote Receiver), das ist momentan noch dasselbe, wenn man es one-way betrachtet, Empfänger (oder S32) an FBL.

Mein 4649T liefert überraschenderweise keine Empfängerspannung, was er ja standalone tun müsste, also wenn er nur ON ist, sonst nix dran.
Ich liefere daher die Betriebsspannung von S32 stattdessen, erscheint im selben Display als Rx Spannung, - also die Spannung, wie sie an Port 3, 4 oder 8 reinkommen kann.
Man muss "QOS" senden (S32), könnte aber alle Daten invalidieren, indem man 0xFF sendet. Da tue ich, vor allem für Fades und Holds, die der Rx besetzt, aber für Rx Spannung nicht, weil die sonst eh auf "----" stehen würde:
Zitat:
A = 0
B = 0
L = 0
R = 0
F = fades
H = holds
rxV = 0xFFFF

Auch aus A, B, L, R halte ich mich raus, obwohl die fix auf Null stehen.

Von seinen lokalen Sensoren kann der 4649T nur Volts liefern, was er aber nicht tut. (was eh entweder ungenau oder issue-prone (ground loop) ist)
Also benutze ich auch das Display, indem ich hier Daten von S32 reinsende, - das Paket senden MUSS ich ja auf SRXL:
Zitat:
// RPM/Volts/Temperature
microseconds; // microseconds between pulse leading edges <-- rpmMotor
volts; <-- Ubat
temperature; // degrees F <-- tFET

Ansonsten dann eben die Displays, die ich auch auf dem X-Bus bemühe: Strom, ESC, Flight Pack, Airspeed, Rx Pack, 14S LiPoMon.

----------

Weiteren Sat Rx an FBL:
Könnte gehen.
Eigentlich ist das anders gedacht: Es gibt jeweils EINEN internen Remote Receiver, oder einen externen, der als Main=="intern= definiert wird, wenn es intern keinen Rx gibt (am FBL), - und n externe. Nur der interne speichert die Bindungsinformationen, - die externen benutzen/bekommen diese.
Der 4649T ist ein standalone Receiver, betrachtet sich ergo als interner, und gibt sich als solcher aus beim Binden, bzw. will einen internen Bind Request sehen.
Es könnte nun gehen, indem man den 4649T irgendwie an den "Main Sat" Anschluß eines FBL bringt, die anderen Sat an die anderen Anschlüsse. Dann ist aber S32 außen vor.
Das Konstrukt wäre auch nicht im Sinne des Erfinders des 4649T.
Man könnte nun einfach den 4649T separat binden (Bind Plug). Nur wird es nun möglicherweise(?) nicht möglich sein, weitere Sat auf das Modell im Sender zu binden in Schritt 2 bis n..
Dann ginge nur: 4649T an "Main Sat", und einen "echten" Sat an "Secondary Sat", und binden. Dann 4649T von "Main Sat" abmachen und S32 dazwischen.
(Es braucht eh ein Adapterkabel Sat-Buchse auf Servostecker zum FBL, ähnlich wie es der 4649T mitbringt, weil er keinen Servo Connector hat.)

_________________
Tom


Nach oben
   
 
 Betreff des Beitrags: Re: SPEKTRUM SRXL
Verfasst: 18. Feb 2017, 18:37 

Registriert: 3. Jan 2017, 16:29
Beiträge: 70
Danke Tom,
ich glaub ich werde mir lieber einen AR8010T zulegen und diesen per SRXL ans FBL und klassisch den S32 dranhängen.
Dann habe ich auch die Antennenwerte auf dem Sender und kann die Antennen besser räumlich platzieren. Für die 700er Heli Größe ist das Gewicht auch nicht so relevant.

Was heist denn oben die Antennewerte beim SPM4649T stehen Fix auf Null. Werden da keine Antennendaten zum Sender übertragen?

Gruß
Werner


Nach oben
   
 
 Betreff des Beitrags: Re: SPEKTRUM SRXL
Verfasst: 18. Feb 2017, 19:02 
The Madman from Laboratory 4

Registriert: 8. Jun 2011, 14:28
Beiträge: 4760
Antennenwerte.. Wo finde ich die denn im Sender?

Was ich sah, sind die Counter "Fades" und "Holds".

Diese Nulldefinition stammt aus den X-Bus Specs von Miguel (Horizon), - k.a., was "QOS" und "RPM" überhaupt darin zu suchen haben.
Der Kreis schließt sich aber mit SRXL, wo Sensoren perverserweise sogar "QOS" und "RPM" senden MÜSSEN, um gehört zu werden.
Wie gesagt, so richtig rund ist der Quatsch noch nicht, und die ganzen Specs sind so gemacht, wie leider im Modellbau allgemein usus. Wer einen Zugang zur Klapsmühle sucht, muss nur solche Specs inhalieren. Bisher dachte ich immer, Extreme seien Asiaten aufgrund anderer Logik vorbehalten, - Futaba (Japan), Graupner/SJ (Korea), Frsky (China), Hobbywing (China), Scorpion (Taiwan (National-China)) usw. Tja.., vielleicht nicht seitens der Form, aber in Bezug auf Konfusion kann man es offenbar auch in US (Illinois) recht gut.

_________________
Tom


Nach oben
   
 
 Betreff des Beitrags: Re: SPEKTRUM SRXL
Verfasst: 18. Feb 2017, 19:44 
The Madman from Laboratory 4

Registriert: 8. Jun 2011, 14:28
Beiträge: 4760




_________________
Tom


Nach oben
   
 
 Betreff des Beitrags: Re: SPEKTRUM SRXL
Verfasst: 18. Feb 2017, 22:06 

Registriert: 3. Jan 2017, 16:29
Beiträge: 70
Cool das du es hinbekommen hast das die RX Spannung (bzw. die S32 Spannung) am richtigen Ort Angezeigt wird. Da ist natürlich ein Sender Alarm einstellbar!!
Das haben die Italiener beim Brain noch nicht hingekriegt!
Mit Antennenwerte meinte ich die Fades, Frame losses und Holds sowie die RSSI Werte.
Und das jetzt die Drehzahl auch im Telemerie Display angezeigt wird finde ich auch klasse.
Hmm..., evtl sollte ich dem Empfänger doch mal eine Chance geben.
Nur die kurzen Antennen sin etwas schlecht zu positionieren. Da diese ja gesteckt sind könnte ich die ja gegen 15cm Antennenlänge austauschen.
Mit einem zweiten Sat würde ich dann einfach mal probieren ob ich es hinkriege.

Das im Modellbau nichts richtig rund ist brauchst du mir nicht zu sagen.


Nach oben
   
 
 Betreff des Beitrags: Re: SPEKTRUM SRXL
Verfasst: 19. Feb 2017, 00:30 
The Madman from Laboratory 4

Registriert: 8. Jun 2011, 14:28
Beiträge: 4760
Total OT: "Italiener"

Sie bedienen den alten JIVE?

Wie geht das? Wenn denen nicht K Sourcen gegeben hat (evtl. sogar von mir, 2010 war ich noch blauäugig ), dann kann man nur unvollständig durch Reverse Engineering Daten identifizieren im Protokoll. Für die State Machine im Leser (Brain 2) nicht unwichtige Daten bleiben verschlossen.

Dann aber: Der Strom! Was sie dort ausspucken, sollte man mal kontrollieren. Der JIVE liefert nur Hausnummern, unprozessiert völlig wertlos.
Es war ein verdammter Aufwand, eine Formel zu entwickeln, die dann situations- und parameterabhängig an x Stellen on-the-fly modifiziert wird, damit der Strom dann auch verwertbar ist in jedem Setup, bei jedem Flugstil. On top kommt, dass der Temperaturkoeffizient des nicht kalibrierten Shunt-Widerstands (ist ja nur ein Trace auf dem PCB) nachträglich zu kompensieren ist, wofür man ihn erst mal ermitteln muss..
Die ganze dafür erforderliche Kiste ist IMMENS aufwändig, erfordert sehr viel Messen im Lab, wofür man sich erst mal das loggende Equipment für Vergleichen bauen muss.

Ich kann mir eigentlich nicht vorstellen, dass jemand das auf sich nimmt für einen ESC, der EOL ist.. (einen anderen Weg von Reverse Engineering will ich mal ausschließen..)
Sprich, ich nehme an, dass es mehr Dröhnen als nutzbares Ergebnis ist.

-------
EDIT: Da ich bei HF immer mit deren Werbebanner belästigt werde, eben wieder. Das lass ich mir nicht nehmen:


Dateianhänge:

TelemetryIsHere_haha.png [ 53.35 KiB | 9357-mal betrachtet ]

_________________
Tom
Nach oben
   
 
 Betreff des Beitrags: Re: SPEKTRUM SRXL
Verfasst: 20. Feb 2017, 13:13 
The Madman from Laboratory 4

Registriert: 8. Jun 2011, 14:28
Beiträge: 4760
SPEKTRUM "Bidirectionales SRXL"

Zitat:
Single Line Protokoll (Summensignal), Konfusion möglich

SRXL.org, wo sich Walter Meyer von Freakware engagiert, beschreibt einen Protokollrahmen, der es ermöglicht, den Vendor einer Aussendung zu erkennen, die enthaltenen Daten damit richtig interpretieren zu können. Jeder Vendor, wie Multiplex, Freakware (Beast), JR (X-Bus B), Graupner (HoTT SUMD), Horizon (SPEKTRUM) hat eine ID, oder mehrere, wenn es mehrere Datenformat-Varianten geben sollte. (SRXL ist die digitale Alternative zum bekannten Summensignal PPM.)

Das Protokoll ist unidirektional (one-way), nur Kanaldaten übertragend. SPEKTRUM allerdings, bisher nicht SRXL verwendend, sondern sein eigenes “Remote Receiver” (aka “Sat” Protokoll), erfand jetzt sein “Bidirectional SRXL”. Der erste Empfänger, der es spricht, ist der SPM4649T. Jedoch ist das nicht nur ein aufgebohrtes SRXL, es ist gleichzeitig KEIN SRXL momentan: Kanaldaten werden nach wie vor im Remote Receiver (Sat) Protokoll gesendet, nicht als SRXL! Man sagt, man hätte SRXL auch für diese Richtung im “Bidirectional SRXL” auf dem Radar, ein Updater für den 4649T würde kommen.

Da kann man nur hoffen, dass dieses SRXL für den eigentlichen Zweck, Kanaldaten, dann auch wirklich SRXL-konform sein wird.. Es gibt bereits auch SPEKTRUM Empfänger, die reines SRXL (one-way) sprechen, allerdings nicht konform, mit der Checksumme (CRC16) machte man Fehler. Der SRXL-Anteil im “Bidirectional SRXL” des 4649T ist jedenfalls auch nicht SRXL-konform bezüglich der Checksumme: CRC nur über den Payload (Kanaldaten), die beiden Bytes des CRC16 in der verkehrten Reihenfolge mit Bezug zu SRXL.org.

Nun sollte klarer sein, warum ein Gerät den 4649T als “Sat” lesen können sollte. Fraglich bzgl. dieses Gerätes ist dann nur jeweils, ob es damit klar kommen wird, wenn in der Gegenrichtung Sensoren in SRXL senden. Schließlich kann so ein Gerät ja nicht ursprünglich darauf vorbereitet gewesen sein. Es könnte also passieren, dass Sensordaten als Kanaldaten interpretiert werden! Das ist der Grund, weshalb ein S32 im Setup für Telemetrie “SPEKTRUM SRXL” optional anbietet, auf einem anderen Port als Remote Receiver (“Sat”) die enthaltenen Kanaldaten wieder auszusenden.

_________________
Tom


Nach oben
   
 
 Betreff des Beitrags: Re: SPEKTRUM SRXL
Verfasst: 26. Feb 2017, 20:01 
The Madman from Laboratory 4

Registriert: 8. Jun 2011, 14:28
Beiträge: 4760
Walter Meyer sagt (am Tel) zu dem Wiederaussenden der Remote Receiver (Kanal)Daten:
"Hey, das ist eine zusätzliche Verzögerung, Knüppel zu Bemerken durch das Beast! Wir berechnen die Knüppeländerungsgeschwindigkeit, lassen Knüppelbeschleunigung in das Verhalten des Beast einfließen."

Tja.., das stimmt, aber es ist mMn ziemlicher Peanuts:
Das Beast kann in einem 11ms Systems nach 22ms frühestens die nächste Änderungsgeschwindigkeit berechnen, in einem 22ms System nach 44ms. Grund: Es sind zwei Kanaldatenpakete, jeweils 7 Kanäle, weshalb SPEKTRUM's Angabe "11ms" oder "22ms" eigentlich irreführend ist, es sind 22 bzw. 44ms.
Will man sicher sein bzgl. festgestellter Knüppelbeschleunigung, müsste man eigentlich zwei Messungen nehmen, was zu 44 bzw. 88ms Verzögerung Hand-zu-Beast führt.

S32 liest das ganze Paket ein, bevor er es wieder aussendet. Das macht zusätzliche 1.4ms Delay aus. Da sage ich daher: Peanuts.
Ich könnte natürlich auch nach dem Empfangen des ersten Bytes der Kanaldaten bereits beginnen, wieder auszusenden: 80us Verzögerung. Das ginge, weil SPEKTRUM's Sat Protokoll leider keinerlei Integritätscheck (Checksumme) hat.

_________________
Tom


Nach oben
   
 
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
   [ 11 Beiträge ]  Gehe zu Seite 1, 2  Nächste

Alle Zeiten sind UTC + 1 Stunde


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 6 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de