JUMPER Jumper T16

Norbert

Erfahrener Benutzer
"This subprotocol makes a clone of a TX identifier transmitting FrSkyD/D8, FrSkyX/D16 v1.xxx FCC/LBT and FrSkyX/D16 v2.1.0 FCC/LBT. "
Es sieht so aus, als wenn ich den Sender meines Freundes emulieren kann. Also um mal eben auch sein Modell zu fliegen.
Ist sicher praktisch, aber hebt den Sicherheitsvorteil von modernen Übertragungsverfahren auf.
Klar - grundsätzlich hast du recht - wenn man nicht weiss was man tut. Für mich ist das ein SUPER Feature, wenn ich in den Urlaub oder in die Berge fahre. In den Bergen will ich einen kleinen leichten Sender, den ich auf den Berg schleppe. Es ein Riesenaufwand in meinen Bleistiftfliegern den Empfänger rauszupopeln, eventuell noch Jumper zu setzen und neu zu binden.

Dito im Urlaub, wenn ein Sender kaputt gehen sollte.

Nur nicht 2 Sender gleichzeitig einschalten :cool::eek::eek:

Norbert
 
Das mit dem Zweit-Sender für den Urlaub oder wenn man mal leichter unterwegs sein will, ist auch für mich ein Argument. Allerdings will ich das über ein externes MPM lösen ,indem ich die dann einfach alle Modelle daran binde unddas Modul in den entsprechenden Sender stecke - oder spricht da etwas dagegen ?
LG Uwe
 
Hallo,
hab seit letzter Woche ein neues Laptop mit Win10 (das bringt mich insgesammt zur Verzweiflung, frag mich echt, warum man andauernd irgendwas verschlimmbessern muss) und natürlich auch gleich ein Problem mit der T16 bei OpenTx.
Hab das INAV - LUA - Skript in Gebrauch. Mit meinem alten Laptop Win7 läuft da in der Simulation alles bestens.
Mit dem neuen Win10 kommt in der Simulaton nur ein leeres Fenster und es ist erscheint auch nicht in der Auswahl (obwohl es im Wizzard natürlich nach wie vor drin steht )
Alle Anderen LUA - Skrit's funktionieren übrigens tadellos.
Hatte schon einmal einer dieses Problem?
Hab schon gegoogelt wie ein Weltmeister aber noch keine Lösung gefunden.
 
Zuletzt bearbeitet:

helle

Erfahrener Benutzer
Hy,

die FrSky V2.1.0 ist doch schon in der T16 Firmware für das interne / externe Hf-Moduls
ab V1.3.0.85 schon einstellbar und getestet.

aktuell ist schon V1.3.0.91
 

reialt

Neuer Benutzer
Hy,

die FrSky V2.1.0 ist doch schon in der T16 Firmware für das interne / externe Hf-Moduls
ab V1.3.0.85 schon einstellbar und getestet.

aktuell ist schon V1.3.0.91
Hallo,

Entweder ich mach etwas verkehrt, aber bei mir geht keine Bindung mit Jumper T16.
Sender Jumper T16 Version V1.3.0.9
Empf. mit Version RX8R_Pro_ACCST_2.1.0_LBT.frk geht Nicht.

FrSky Sender X9E mit Version XJT_ACCST_2.1.0_LBT.frk
Empf. mit Version RX8R_Pro_ACCST_2.1.0_LBT.frk alles OK

Was mache ich verkehrt? oder geht Jumper und FrSky V2.1.0 in Combi nicht.
 
Zuletzt bearbeitet:

reialt

Neuer Benutzer
Hallo,

Entweder ich mach etwas verkehrt, aber bei mir geht keine Bindung mit Jamper T16.
Sender Jamper T16 Version V1.3.0.9
Empf. mit Version RX8R_Pro_ACCST_2.1.0_LBT.frk geht Nicht.

FrSky Sender X9E mit Version XJT_ACCST_2.1.0_LBT.frk
Empf. mit Version RX8R_Pro_ACCST_2.1.0_LBT.frk alles OK

Was mache ich verkehrt? oder geht Jamper und FrSky V2.1.0 in Combi nicht.
Habe es gerade herausgefunden. Aufruf beim Multisoft ist FrSkyX2,:ding: mann darauf muss man erst kommen.
 

Elyot

Erfahrener Benutzer
Für die, die nicht "drüben" auf RCG mitlesen. Die Jumper-Module (intern und extern) haben scheinbar einen Fake-NRF Chip verbaut. Daher gibt es teilweise Probleme bei Protokollen, die den NRF verwenden.
 
Erhaltene "Gefällt mir": meute

actron

Well-known member
Zitat von Pascal (hab ich mal übersetzt):

pascal bei rcgroups

Ich habe endlich verstanden, was das lang anhaltende Problem mit all den Jumper-Modulen ist.
Die 3 Module, die ich von ihnen habe - alte Generation, T16 extern oder T16 intern - leiden
unter dem gleichen Problem.

Der NRF24L01, den sie verwenden, ist nicht das Originalteil. Es sieht aus wie ein SI24R01 oder ein anderer Klon derselben Linie

Was betroffen ist:

- Alle Protokolle, die den NRF24L01 verwenden, laufen bei 250 KBit/s:
Für die meisten (nicht alle) Protokolle gibt es einen Workaround, indem der CC2500 verwendet wird, um
den NRF24L01 für diese Geschwindigkeit zu emulieren.

- Alle Protokolle, die die Auto-Ack-Funktion des NRF24L01 verwenden:
Für die meisten Protokolle, die ohne die Auto-Ack-Funktion arbeiten können, wurde eine Umgehungslösung
eingerichtet.
Aber z.B. das neue PROPEL-Protokoll verwendet auto ack zusätzlich zu einem speziellen Modus und kann
daher (trotz langer Versuchszeiten) nicht funktionieren.

All diese Arbeit zu erledigen ist echte Zeitintesive Aufgabe, wie Sie sich vorstellen können.

Ich habe mich mit Jumper in Verbindung gesetzt, die erklärt haben, dass sie Originalteile kaufen/verwenden,
aber ich habe jetzt einen Beweis mittels SDR, dass sie es nicht tun.

Ich glaube nicht, dass sie es absichtlich getan haben, aber so ist es nun einmal.

Wenn Sie also Probleme mit NRF24L01 und emulierten XN297-Protokollen haben, gehen Sie einfach zu Jumper, um Unterstützung zu erhalten.

Ich habe sowohl meine iRangeX- als auch meine RadioMaster-Module getestet.
Sie verwenden ein echtes NRF24L01.
 
FPV1

Banggood

Oben Unten