Interne taranis XJT modulle updaten of niet?

Wel, ik heb vorige maand mijn x8r ontvanger, fas150 en flvss opgeblazen omdat ik mijn LiPo balanceerstekker verkeerd op de flvss telemetrie sensor heb gezet.
Ik heb dan maar een nieuwe ontvanger besteld maar omdat mijn taranis nog steeds op international firmware draait en geen LBT ontvangers lust moeten deze ontvangers dus van buiten de eu besteld worden.
Zodoende gedaan en bij ontvangst....... Ja, een LBT ontvanger.
Nu is de vraag of het de moeite loont om de interne XJT modulle van de taranis om te flashen naar LBT en daarmee ook alle andere ontvangers die ik heb, of gewoon alles zo te laten en enkel mijn nieuwe ontvanger te 'downgraden' naar international firmware.
Heeft het eigenlijk voordelen om de LBT te gebruiken?
Ik heb nooit problemen gehad met de vorige firmware en steeds een prima reikwijdte gehad.
Zal de reikwijdte met LBT hetzelfde zijn of minder?

 

Het maakt niet uit waar je de ontvangers koopt, iedere Frsky ontvanger kun je voorzien van de firmware die je wilt.

Zelf heb ik alles op LBT staan (is eigenlijk verplicht in de eu).

Ook heb ik alles voorzien van de laatste vrijgegeven versie, te vinden op de site van Frsky. Hierin zit een belangrijke fix.

 

Ik wou eigenlijk een ontvanger kopen die ik onmiddellijk kon gebruiken, daarom had ik deze bij ali besteld, tja.... 4 weken wachten op een ontvanger die dan uiteindelijk een LBT blijkt te zijn.
Ik veronderstel dat ik dan enkel de XJT en de ontvangers moet flashen?
Moet ik dan alle telemetrie sensoren wissen en terug instellen ( heb ik ergens gelezen)
Heeft LBT invloed op de reikwijdte ?

 

Klopt, je moet de XJT module en de ontvangers updaten.
Daarna opnieuw binden, en de telemetry opnieuw inlezen.

Reikwijdte veranderd niet, of dusdanig dat je er niks van merkt

 

Tijdens het zoeken op youtube naar het flashen van de interne xjt modulle ben ik verschillende waarschuwingen tegengekomen i.v.m. het flashen van de ACCST V2.XX firmware.
Met deze firmware zou het onmogelijk worden om bepaalde toestellen nog te binden als er geen frsky ontvanger inzit.
Dit kan gevolgen hebben als men b.v. een bind en fly toestel koopt.
Voorlopig heb ik dan maar besloten om de ontvanger te downgraden naar de ACCST V 1.XX international firmware.

 

Updaten: jazekers!

Waarom, Vorig jaar heb ik de "uncontrolled servo movement" bug mee gemaakt op een Trex 700, gelukkig kwam ik net in hover op een redelijke hoogte.
Waarbij er voor ongeveer 1 seconden aileron een volledig uitslag gaf naar links.
Dit was zelfs terug te vinden in het log van OpenTX.
Met die gedachte en wetenschap dat dit nu gefixt is, zou ik zeker updaten!

Voor bind & fly dingen zou ik het zeker niet laten, want voor 30-40euro heb je een 4in1 multi module waarbij je dit weer op kunt vangen, en nog veel meer leuke protocollen je tot je beschikking hebt.

En wat LBT en FCC betreft.
Deze functioneren qua reikwijdte allebei hetzelfde.
Alleen heeft LBT (Listen before Transmit) de functie dat hij eerst het frequentie spektrum afluitsterd en dan een verbinding maakt zoveel mogelijk buiten andere zenders in het spektrum.
FCC dumpt na het aanzetten van je zender gewoon direct signaal op de band.
Dit is dus verboden in de EU.

Dat er meer vermogen uit zou komen bij FCC dat is niet waar, althans niet voor 2.4ghz, dit geldt alleen voor het R9 systeem.. voor zowel FCC en LBT op 2.4ghz geld <=100mW (kleiner of gelijk aan)

 

Ik wil niet vervelend doen, maar denk niet dat de V1 bug in de logs van opentx terug te vinden is. Je kan natuurlijk een meting op de ontvanger doen, maar dat heeft niets met opentx logs te maken, en vraagt om zelfgebouwde extra sensors.

Dus tenzij ik het verkeerd begrepen heb, is jou vaststelling dat jij de versie 1 bug hebt zien gebeuren en in de logs hebt gezien niet correct, en is er in jou geval iets anders aan de hand geweest.

Er is in principe geen enkele reden je modules en ontvangers te upgraden, als je niet al tevreden was met de betrouwbaarheid van het oude vertrouwde D16 V1 protocol, dat jarenlang iedereen prima van dienst is geweest.

Enkel als je op de nieuwere ontvangers overgaat, zou je theoretisch beter kunnen upgraden. Die blijken mogelijk minder betrouwbaar op het oude protocol.

Kan het allemaal fout hebben hoor, maar dit is wat ik ervan begrepen heb.

 

Dat ik de bug heb zien gebeuren en exact de periode had die ook beschreven wordt is voor "mijzelf" het bewijs dat de bug er wel degelijk in zit/zat. Wat het log betreft het is mogelijk moeilijk terug te traceren in welke tijdspanne dat geweest is.

Even aan toevoegend dat ik na de bug heel lang bezig geweest ben met zowel de jongens van OpenTX alsmede Frsky in dit verhaal.
De konden niet anders concluderen dat het wel deze bug geweest moet zijn.

Om de ervaring van de bug te simuleren heb ik later een tricky truukje toegepast.
Aangezien ik een FBL unit gebruikt stuur ik daar gewoon een losse Aileron, Elevator,Rudder en Pitch kanaal heen.
Ik kan dus tijdelijk een override uitvoeren op mijn aileron kanaal.. dus voor 1 seconde volle uitslag naar links.

Dit heb ik op grote hoogte toegepast, en gaf exact hetzelfde beeld als wat ik toen gezien had.
Dit was voor mij duidelijk genoeg.

 

Het maakt mij allemaal niet uit hoor. Bug of geen bug. En ik geloof je direct als je zegt dat jij hem een keer hebt voorgehad.

Het is alleen veel makkelijker één ontvanger te flashen dan je hele vloot plus zender.

Die bug is daar geen argument bij, aangezien voor de door hem beschreven hardware die bug nooit vastgesteld is geweest zonder zeer uitzonderlijke testsituaties te creëeren.

P.s.
De reden waarom ik reageer is dat je duidelijk stelt dat je de bug kon bewijzen middels je logfile. Dat is nou net hetgeen niet kan, waardoor frsky ook zo lang niet heeft willen luisteren toen de bug op de nieuwere hardware werd vastgesteld. En ja, de bug KAN zich ook op de oudere hardware voordoen. Theoretisch dan, in extreme situaties (zeer veel wifi storing door streaming).

Wat FBL er mee te maken heeft snap ik niet. Kan toch gewoon de knuppel een seconde vol naar links gooien? Waarvoor heb je die ovverride nodig?

 

Tja, wat betreft die bug.... Ik heb een taranis van eind 2014 waarvan alleen een update van open tx is gedaan.
De xjt module heeft nooit een update gehad en heeft nog de originele software. Er zijn nooit problemen geweest met deze setup zelfs niet op 1.5 Km afstand.
Ik heb voorlopig geen zin in een update die er voor zorgt dat bepaalde dingen niet meer werken.
Als FRSKY dit verhelpt met een volgende update zie ik geen reden om geen update te doen.
Ik wou eigenlijk de update wel doen maar na het horen van de beperkingen die het met zich meebrengt, met een update zou je je moeten verbeteren, niet beperken.

 

De bug zat in alle zenders/ontvangers ongeacht de leeftijd van de ontvanger. Dus ook in het ‘oude’ vertrouwde kan dit gewoon voorkomen. Je kunt hier niet zeggen, dat als je oude ontvangers hebt, dat je het probleem niet hebt.

De nadelen van de update:
- Als je veel ontvangers hebt, ben je even druk.
- Het D8 protocol word niet meer ondersteund, dit protocol zat op sommige ontvangers bijv. D4R-II.
- Bind&fly producten kunnen niet als deze bijv nog D8 of D16 2.0.1 ondersteunen.
- je kunt de schuld van een crash niet meer bij de zender/ontvanger leggen....

De nadelen van de bind&fly mbt D8 heb ik opgelost met een 4in1 module, zodat ik de micro drones van AliExpress nog kan vliegen.

 

En de telemetry werkt niet meer naar behoren, en de nieuwe firmware is niet getest door duizenden gebruikers gedurende vele jaren, en de updates zijn nog steeds niet 'klaar' maar worden wel vrijgegeven, ...

En inderdaad, op de oude zenders kan het ook voorkomen. Alleen heeft niemand het ooit opgemerkt ......

Trek je eigen conclusies.

 

Ik vraag me wel af waarom je zo goed als niks hoort over die bug, als er veel mensen last van hadden zouden de forums er vol van moeten staan.
Ik wil niet zeggen dat het niet bestaat maar als je zou weten hoeveel frsky zenders en ontvangers er gebruikt worden zou ik toch denken dat je er meer over zou horen.
Als een product een probleem heeft ga je dit direct op internet horen omdat de consument nu eenmaal graag zijn gal spuwt.

 

Die bug was er wel, daar is ook veel over te vinden.
Probleem was; dat het best lastig was om vast te stellen.
Het kwam slechts zelden voor en voor een kort moment.
Een korte flinke uitslag op een servo van een zwever ga je waarschijnlijk niet eens zien.
Eens een keer een vreemde beweging op je gewone toestel geeft waarschijnlijk een paar gefronste wenkbrauwen.
En als je verder niets vreemds vind, vlieg je gewoon weer vrolijk verder.

Ik weet vrijwel zeker dat het mij een kist heeft gekost.
Met een, voor mij, bekende EDF kist. Op een 5 m hoogte tijdens het circuit om te landen.

De kist rolde (zonder opdracht) in een tegenovergestelde richting, dan wat ik een paar seconde later zelf zou ingeven.
Niets geen overtrek of stuurfout.
Geen mankement kunnen vinden omdat alles van de besturing na de crash gewoon werkte.

 

Een traditionele heli heeft een SWASH mixer in de zender zitten, 3 kanalen tegelijk direct uit de ontvanger zijn verantwoordelijk voor de werking van de swashplate.
Bij een FBL zit de SWASH mixing in de FBL unit, daar is maar 1 kanaal uit de ontvanger verantwoordelijk voor een seperate functie van de swashplate.,. niet 3 kanalen tegelijk uit de ontvanger. Stuur ik elevator dan regelt de FBL unit de mixing van de 3 servo's voor een Elevator uitslag.

Vandaar de override van 1 seconde,, daarmee simuleer ik een volle uitslag die zou lijken op wat ik gezien had.. en dat klopte ook.

Dat je er weinig van gelezen hebt wil niet zeggen dat het er niet is.
Ik weet niet hoe veel topics en berichten van RC groups je dagelijks bij houdt?
Maar daar is degelijk redelijk veel over te vinden.

Veel mensen weten niet eens dat als het gebeurd, het de bug betreft.. een kist met trage servo's daar merk je het niet eens op.. maar wel op een felle acro kist.. met snelle servo's.
Of een heli met zeer snelle servo's en felle uitslagen.

Dit is niet helemaal waar.

Ik merk sinds het hele v2.1.x verhaal dat ik juist geen problemen meer heb met telemetrie.
Voorheen had ik altijd problemen met een G-RX8, S8R/S6R waarbij telemetrie waardes door het dak gingen. vooral met OpenXsensoren. dit is verholpen sinds v2.1.0 uit kwam. sinds dien noooooit meer gezien.

Maar wat betreft het bewijs.. ik denk dat in dit geval, je het kan vergelijken met een UFO spotten.. je gelooft het pas als je het zelf ervaren hebt denk ik. ;-)

 

Dat D8 niet meer zou werken is echt onzin, D8 zit nog steeds in de firmware als je een upgrade doet van je XJT module naar ACCST v2.1.x. Als je D8 niet (meer) ziet heb je vermoedelijk het EU vinkje in Companion aan staan, zet dat uit en download en flash OpenTX opnieuw. Het D8 protocol wijzigt niet en blijft precies zo werken als het voorheen deed!
Gebruik je producten met een niet-originele FrSky ontvanger erin, dan kun je bij het D16 protocol problemen krijgen als er geen firmware update voor deze ontvanger beschikbaar is voor ACCST v2.1.x. Een oplossing hiervoor is gebruik maken van een losse XJT module (in het JR slot) of een zogenaamde MultiProtocol module (MPM; met alle bijkomende voordelen van dien)...

Voor wie twijfelt of denkt dat het wel meevalt...

Ik heb de USM (Uncontrolled Servo Movement) bug zelf meerdere malen mogen ervaren, vaak was het een volledige uitslag op de ailerons (Y-kabeltje) of een volledige uitslag op elevator. Het gebeurde eens in de paar maanden en ik wist nooit waardoor het kwam tot ik er over las op het Duitse FrSky forum (geloof dat ik er via MBF naartoe werd verwezen). In de logs zie je het niet terug, alleen als je zelf daarna volledig tegen gaat sturen, maar dan nog. Sinds ik over ben op ACCST v2.1.x sinds maart/april heb ik het probleem niet meer ervaren. Ik heb altijd geluk gehad voor zover ik weet (of het moet zich ook hebben voorgedaan toen ik nog aan het lessen was, maar dan denk je altijd aan je eigen onkunde als je toestel crasht), want de keren dat ik het bewust heb meegemaakt gebeurde het op voldoende hoogte en wist ik zeker dat ik geen rol deed of full elevator up trok. Bij een vliegmaat was het vrijwel zeker de oorzaak van een crash, net voor de landing full aileron...

Het probleem met de USM bug is dat je nooit weet waar of wanneer het zich voordoet, als het zich op een verkeerd moment voordoet ben je in het meest gunstige geval alleen je model kwijt, in een ongunstig geval heb je iemand anders schade of letsel toegebracht. Reken maar dat de verzekering er van alles aan zal doen om onder de schade uit te komen en als bekend is dat er een bug is die dit tot gevolg heeft gehad en je het kon weten dan keren ze als je pech hebt niet uit... Dus tja, wie dat risico wil lopen moet vooral ACCST v1 blijven gebruiken...

Er gingen ook onzin verhalen de wereld rond van mensen die dachten dat het FrSky alleen maar om het uitsluiten van klonen te doen was, maar de bug bestaat wel degelijk. FrSky heeft dan wel gelijk hun protocol iets beter beschermd tegen klonen, maar dat heeft niet heel lang stand gehouden want het zat binnen de kortste keren in de firmware voor de MPM modules, dus ook de zenders van Jumper, Radiomaster en opvolgende klonen ondersteunen het nu.

 

Ik houd Rcgroups zeker bij, en heb gezien hoe frsky hun klanten firmware na firmware heeft laten testen zonder enige echte communicatie.

Wellicht dat het nu 'werkt',maar dat kon niet gezegd worden van de eerste firmwares die werden vrijgegeven door frsky om de bug op te lossen.

Afhankelijk van wat je vliegt, is het risico op schade groter.

Ten aanzien van FBL. Ik snap het nu. Flybarless. Thanks.

Ik wilde echt niet deze discussie hier starten, maar vond het advies om maar even alles te flashen geen gebalanceerd advies.

Ik heb aangegeven waarom, en hoop dat mensen een keuze kunnen maken die voor hen het beste is.

Belangrijk is wel dat iedereen bij de feiten blijft. Ook ik.

 

Daar heb je zeker gelijk in.
Velen hebben daar problemen mee, ikzelf accepteer deze weg, en zal je van mij nagenoeg nooit een mening vinden over hun bedrijfsvoering.

Ik blijf er bij dat tot vandaag de dag een ander systeem niet kan tippen aan de zowat eindeloze mogelijkheden wat Frsky icm OpenTX, OpenXsensor etc te bieden heeft.
En dat het OpenSource is ben ik mij ook degelijk bewust van dat ook ik uiteindelijk een beta tester ben in het hele verhaal.
Ik neem de zo nu en dan voorbij komende Quirks voor lief. En veelal valt het allemaal wel mee.

Klopt, daarom vermelde ik ook vanaf v2.1.x.. toen v2.0.1 uit kwam zat die bug er nog steeds in.

Misschien dat mijn "jazeker" een te emotionele expressie bevat, dat komt meer door de ervaring die ik nu zelf heb gehad.. en de "bijna" ellende voor een ander wil besparen

 

Dat mensen niet zomaar even volledig overstappen is te begrijpen, maar je kan het ook testen in een schuimpje en dan wat ervaring opdoen ermee om vertrouwen te krijgen. Als je de USM bug zelf nooit ervaren hebt dan kan ik begrijpen dat men sceptisch is, zeker gezien hoe FrSky het hele proces van testen doorlopen is. Aan de andere kant, de discussies op RCGroups en FrSky-Forum.de voor wat betreft de nieuwe ACCST v2.1.x firmware zijn behoorlijk 'stilgevallen' t.o.v. een aantal maanden terug. Als er nog veel problemen zouden zijn zou er veel meer discussie gaande zijn...

Het weer is toch niet dusdanig om met grote dure kisteren te vliegen. Prima om dan te testen, toch?

 

Ik heb enkele maanden geleden de stap gezet om over te gaan o 2.1.x firmware. Het was een hele klus, maar het geeft me nu een gerust gevoel. Ik heb een aantal keer last gehad van de USM bug en er ook een kist aan verspeeld. Een clubgenoot van me idem.
Er gaat helaas veel onzin en bangmakerij rond over de update en de beperkingen die je daarna zou hebben. De enige echte “beperking” is dat clone D16 ontvangers niet meer gaan werken zonder eigen FW update.

Daarnaast is er verwarring met het nieuwe ACCESS protocol. Zenders die dat ondersteunen hebben geen D8 mode meer. D8 is een sterk verouderd protocol waarvoor door FrSky al jaren geen hardware meer wordt verkocht. Het wordt nog wel in sommige BNF drones gebruikt. Heb je D8 nog nodig dan is een multi protocol module de ideale oplossing.