Frsky updates
-
- Posts: 238
- Joined: Tue Dec 25, 2018 3:19 am
- Country: United States
Frsky updates
I see that frsky has issued update ACCST D16 2.0.0 for a bunch of their transmitters , modules and receivers ..Since I run ERSKYTX I'm not going to upgrade until Mike B Says all is fine and will work with the changes (it all works now) .
Thanks
Allen
Thanks
Allen
Re: Frsky updates
Nothing is supposed to change outside of the actual RF transmission.
- MikeB
- 9x Developer
- Posts: 17993
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: Frsky updates
I've updated an internal XJT on a Taranis plus and a X8R (LBT), and they bind and operate OK (on the bench).
Mike
Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
-
- Posts: 238
- Joined: Tue Dec 25, 2018 3:19 am
- Country: United States
Re: Frsky updates
Will it make a difference when using a multi module (especially on a 9xr pro) ? I use mainly x8r and s8r receivers
Thanks
Allen
Thanks
Allen
Re: Frsky updates
You will not be able to control updated FrSky receivers with a multiprotocol module anymore, at least not until someone reverses/reimplements the new protocol.
-
- Posts: 238
- Joined: Tue Dec 25, 2018 3:19 am
- Country: United States
Re: Frsky updates
I fly mainly with my Taranis ..So what advantage is it to upgrade ? Sounds like it will knock my 9xr pro's out of commission unless I want to fly dsm2/dsmx..I went frsky and have over 30 x8r and s8r receivers. Hmm. might have made the wrong choice
Allen
Allen
- MikeB
- 9x Developer
- Posts: 17993
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: Frsky updates
I would expect the multi-protocol module to support D16 V2 quite soon. I already have some dumps of the protocol and I think I can see what is needed.
Mike
Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
-
- Posts: 238
- Joined: Tue Dec 25, 2018 3:19 am
- Country: United States
Re: Frsky updates
That would be Fantastic
Thanks
Allen
Thanks
Allen
Re: Frsky updates
That is great Mike thanks
João
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9
Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9
Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW
Re: Frsky updates
Hi guys,
I would like to discuss some findings here. I'm unsure, how to interpret this. I'm not a fanboy of the CRC-story, which caused the big update. I'm watching the issue for a long time and I'm convinced it is a lockout for about 0.8s sometimes together with a wrong channel value (unwanted servo movement). From my pov this happens only with newer TX, never with X9D/E Taranis. We started to discuss this in fpv-community in Germany and it seems, that some TX suffer a frequency drift. The standard is about 40kHz below the binding frequencies 2404/2405MHz and the TX in question have a deviation, in one case it was 25kHz above. This Xlite pro caused some heli-crashes, where no other cause could be found.
To track this down, a forum member flew with Tadangos linkquality sensor and indeed we could see one lockout with his Horus X12S, short before failsafe. 5100(red) is showing good frames in %, RSSI was good, when this happened (also typical for this issue). To make the long story short, I've tested today old firmware vs. new (201) firmware with a X4R walking down the stairs in my house.
XJT170317 LBT: XJT201 LBT: I think FrSky is cheating here and this is dangerous. By the way, a lot of quads with R-XSR fell out of the sky (with new TX also) and FrSky published a new firmware recently, which solved this (BF did show a solid linkquality). But the green LED still flickers as before This was, when I first thought about cheating.
I lost my trust in FrSky, what do you think?
I would like to discuss some findings here. I'm unsure, how to interpret this. I'm not a fanboy of the CRC-story, which caused the big update. I'm watching the issue for a long time and I'm convinced it is a lockout for about 0.8s sometimes together with a wrong channel value (unwanted servo movement). From my pov this happens only with newer TX, never with X9D/E Taranis. We started to discuss this in fpv-community in Germany and it seems, that some TX suffer a frequency drift. The standard is about 40kHz below the binding frequencies 2404/2405MHz and the TX in question have a deviation, in one case it was 25kHz above. This Xlite pro caused some heli-crashes, where no other cause could be found.
To track this down, a forum member flew with Tadangos linkquality sensor and indeed we could see one lockout with his Horus X12S, short before failsafe. 5100(red) is showing good frames in %, RSSI was good, when this happened (also typical for this issue). To make the long story short, I've tested today old firmware vs. new (201) firmware with a X4R walking down the stairs in my house.
XJT170317 LBT: XJT201 LBT: I think FrSky is cheating here and this is dangerous. By the way, a lot of quads with R-XSR fell out of the sky (with new TX also) and FrSky published a new firmware recently, which solved this (BF did show a solid linkquality). But the green LED still flickers as before This was, when I first thought about cheating.
I lost my trust in FrSky, what do you think?
Re: Frsky updates
Should i understand your idea, that you think FrSky cheating becuase LED still flickes ?
Re: Frsky updates
That's what I want to discuss. I think it is very unusual to have inhouse no framelosses with LBT most of the time. The idea is, that the lost frame bit does not represent the truth anymore, but the LED still does. This started with the new R-XSR/G-RX8 firmware 191112 "1.Fixed the problem of abnormal high frame loss rate."
Since this did not happen with X9D/E I presume, the losses were indeed caused by frequency drift in some TX modules and FrSky is masking them now instead of addressing the root cause.
Since this did not happen with X9D/E I presume, the losses were indeed caused by frequency drift in some TX modules and FrSky is masking them now instead of addressing the root cause.
Last edited by Carbo on Fri Jan 17, 2020 5:34 pm, edited 1 time in total.
Re: Frsky updates
I will call to FrSky to make FW with solid LEDs OK?
Re: Frsky updates
I'm happy to meet an expert
Re: Frsky updates
Well, you have make sensor from Tadango what reads SBUS, but SBUS is not real reading of the line quality, do you know how this really works?
Probably not.
Probably not.
Re: Frsky updates
What is your theory for the drastical reduced frame losses? Especially considering, that this happened already with 191112 firmware?
And what does the frame loss bit in FrSky SBus represent? And why did frameloss not happen with X9D/E?
And what does the frame loss bit in FrSky SBus represent? And why did frameloss not happen with X9D/E?
Re: Frsky updates
Well if a packet was lost and there is no new data then the SBUS frame lost bit should be set, that's the whole point of it. If it is not then it is "cheating".
Re: Frsky updates
I have no theory i know it LOL. Unfortunately cant tell you more because of NDA.
Anyway. Each trasmission have some frame losts, more on weaker signal. Sbus is consistent of 2 frames, if one is good and secon is bad, we have bad Sbus. It can happend even on solid line. Now if comes bad frame we drop it and use prevous frame what was good. So we reconstruct good sbus signal. Thanks to new transmission tunning we also have less lost frames so we get more good frames.
This is limited to a few frames and in rate what comunication comes it is irrelevant to mean the data are old. As well it will stop disturbong some FC what had issue with sbus.
Anyway. Each trasmission have some frame losts, more on weaker signal. Sbus is consistent of 2 frames, if one is good and secon is bad, we have bad Sbus. It can happend even on solid line. Now if comes bad frame we drop it and use prevous frame what was good. So we reconstruct good sbus signal. Thanks to new transmission tunning we also have less lost frames so we get more good frames.
This is limited to a few frames and in rate what comunication comes it is irrelevant to mean the data are old. As well it will stop disturbong some FC what had issue with sbus.
Re: Frsky updates
I do not think, this is the way it should work. Presumably I can show easily a stuttering servo, while SBus LQ is still 100%.
Re: Frsky updates
It can do the opentx as well about your servo issue. There are some errors in lattest bouilds
Re: Frsky updates
If the issue is distance related, it is clearly not an OpenTX issue.
Re: Frsky updates
Then you have bad servo. I am affraid you not undestand. If there will be bad frames and bits says signal is OK then you get bed signal for servo. But if the sbus signal is good because lost frame was reconstructed you cant get bad signal for servo.
Re: Frsky updates
Carbo, could you provide log files to the charts which you posted?
Re: Frsky updates
That isn't exactly correct, when people use D16 with only 8 channels they should have new data every frame for the 8 channels that are in use. For 16 yes transmission takes 2 packets so on every sbus frame half the channels change and the other stays held.
Re: Frsky updates
Sure. The additonal "LED" csv is in rangetestmode, where LQ was always 100% while the LED was flickering a lot.
- Attachments
-
- Test-LED.zip
- (8.45 KiB) Downloaded 212 times
Re: Frsky updates
And the flight logfile with lockout in 4th session (GPS column removed - it is not my own file).
- Attachments
-
- SkyMule-2020-01-16-GPS.zip
- (275.19 KiB) Downloaded 194 times
Re: Frsky updates
You will understand, when you see it. If the servo gets a constant changing signal like a servotester signal and the channel information is the same for several frames, the servo movement will stutter. Of course I do not get a bad signal, but I get an "old" signal repeatedly without knowing it, since the information is hidden. This is not an issue for a wing, but racecopter will notice it. And I want to know, if frames get lost.
Betaflight LQ shows perfect signal in this case, even though 50% of the frames are missing. Not OK.
Re: Frsky updates
It is not you logs? And are modified? Sorry but i think i waste my time here.
Re: Frsky updates
Yes, but these {if true} logs was done on 16ch setup like it looks.
Re: Frsky updates
I had a look at Carbo's log file SkyMule.
Hmm, there is about 1s telemetry loss, can be seen from the GPS data. Nothing special, there would be no warning yet.
But I cannot find any evidence of controll loss.
The pilot stick values seems to be normal, no sudden attempt by the pilot to correct the model position.
Thats what pilots would instinctively do, when the model does not react as usual.
I dont understand what is the point? FrSky cheats?
Sounds more like a conspiracy theory.
Hmm, there is about 1s telemetry loss, can be seen from the GPS data. Nothing special, there would be no warning yet.
But I cannot find any evidence of controll loss.
The pilot stick values seems to be normal, no sudden attempt by the pilot to correct the model position.
Thats what pilots would instinctively do, when the model does not react as usual.
I dont understand what is the point? FrSky cheats?
Sounds more like a conspiracy theory.