Frsky updates

[antlerhanger]

I for one will not upgrade right now due to the loss of multi protocol module ..I have never had a problem . I use erskTX on 3 9xr pro's and 2 x9d + radios without a glitch.. I do have 5 multi modules that I use and 1 xjt external module that I just bought (hopefully old FW) ..I will upgrade if the guru's can fix the multi problem..I just find it funny how FRSKY is doing their best to disconnect their base customers that made them..But it's biz I guess..I want to say thank you to the people that work so hard to keep our equipment going.

Thanks again
Allen

[Carbo]

https://www.rcgroups.com/forums/showpos ... count=8272

I don't think they have encrypted the data as such. I believe part of the problem (servo glitches) was due to some transmitters frequency drifting. When this happens, the receiver can have trouble decoding the data, as it is at the wrong rate, particularly if there is a long string of 0s or 1s as the clock recovery cannot lock on to these. FrSky are modifying the data to avoid such strings occurring.

Why do you say it will be difficult? I've already worked out 90% of the normal transmission encoding!

If this is indeed the technical background, it explains nearly all observations. But it seems, that LBT is more affected than FCC, is there also an explanation?

And when FrSky solved this issue with a special encoding, why do they cheat with lost frames? If they give us the true information back, everyone is presumably happy.

[Deininju]

https://fpv-community.de/threads/vorsic ... st-1044311

@ janekx: It is my Log! You can see it in the above Post by fpv-community. I dont can add the File as a attechment in this Post. My english ist not good enough, sorry

Jürgen

[Carbo]

Juergen, don't worry about it. I only wanted to share some findings and to make clear, that people using SBus with V2.01 can not trust the lost frame information. Most users do not use it or do even not know, what it is. The few who know, have the chance now to read it here.

[antlerhanger]

So with the update you can't use the MPM ..Yet(I hope)...My question is will ErskTX work with a updated external XJT module on the 9xr pro ?

Thanks
Allen

I have not updated and may not since all my equipment works perfectly

[MikeB]

It should do, it is working OK with the internal modules on a X9D and a X9D+.

Mike

[antlerhanger]

I ordered 2 XJT modules and they work binding to a s8r ..neither updated .I just want to make sure I can still use my 9xr pro's if the MPM can't be made to work with the update.You never know , in the future we may be forced to update for some unknown reason ..I love ERSKYTX, It's fantastic to use ...Thanks so much

Allen

[jhsa]

I use the MultiProtocol module internally in all my radios, except one that has an old DHT module. if I depended on buying Frsky receivers, sooner or later I would have to get a new XJT module if they and their matching receivers couldn't be downgraded to old firmware. But I don't depend on them, thanks to a forum user (Midelic). He developed a complete DIY Frsky D16 compatible receiver, and it seems to work great. It has actually more features than the Frsky X receivers themselves
So, as far as I am concerned Frsky can do what they like with their software, I am covered Unless the law changes of course, and says that is forbidden to build your own gear. But people building their own gear, as far as I know, was how remote control started anyway. It was one of the foundations of remote controlled model flying. But you never know, the way the world goes, one day we won't be able to build our own models anymore. We will be able to buy only ready built certified model aircraft Will see.. I hope not..

João

[antlerhanger]

You are right , I need to build my own ..But while I can build openxsensors , building a rx is a daunting task for me ..I get hung up on how to order the boards .lol ..I'm afraid I would drive you crazy with questions..

Thanks
Allen

[jhsa]

No you wouldn't drive me crazy with questions
The only difficult thing about building the rx is to solder the 48 pin processor in place, and also its resonator.. It is the same used on the multiprotocol module.. The other components, even if small, aren't that difficult to solder.
But there is also the DIY D8 compatible receiver that uses a much easier to solder processor. Less pins, and a bit more spaced. I also built a few..

João

[Carbo]

If you do not want to build your own RX, Jumper R8 could be a good alternative to use alternative firmware.
https://www.rcgroups.com/forums/showthr ... e-firmware

Btw. interesting information from Pascal regarding V2 firmware: https://www.rcgroups.com/forums/showpos ... count=8340

Am I done with FrSky? Presumably yes ....

[antlerhanger]

I'll order a couple jumper rx's ..Will they only update with the st link v2 or will a USBASP work (prolly a dumb question but it shows I know nothing ) ?

Thanks
Allen

[antlerhanger]

No you wouldn't drive me crazy with questions
The only difficult thing about building the rx is to solder the 48 pin processor in place, and also its resonator.. It is the same used on the multiprotocol module.. The other components, even if small, aren't that difficult to solder.
But there is also the DIY D8 compatible receiver that uses a much easier to solder processor. Less pins, and a bit more spaced. I also built a few..

João

I will try to figure out what to order .That's the biggest thing for me . I can solder it , just have to figure out what I need .I would rather build, it's fun..

Allen

[MikeB]

I believe the Jumper R8 cannot support standard SPort for external telemetry sensors, although it may work with some flight controllers that use non-inverted SPort.

João: Please point me to the details of the DIY D8 Rx, I may look to see if my D16 firmware could run on it.

Mike

[jhsa]

Mike, here is the link. It runs on an ATMEGA328P. Same as the arduino. It can also use the one wire bootloader, so it is really easy to flash.. I built many. The RF module can still be bought from Banggood, and it seems to be reliable. The trickiest part is the Antenna switcher if you want to build it with antenna diversity. I did and it is really good. Midelic did a great job with it.

https://www.rcgroups.com/forums/showthr ... RX-Modules

João

[jhsa]

If you do not want to build your own RX, Jumper R8 could be a good alternative to use alternative firmware.
https://www.rcgroups.com/forums/showthr ... e-firmware

That Jumper RX, if it is the same as I have been following and people have been flashing the DIY Compatible firmware from Midelic, then it has some hardware issues as well.. How can those guys put out a product like that? Didn't they even test it??

João

EDIT: It is the same receiver i was talking about, just checked. But if you fix it, then it could be a good alternative to build your own. You won't have all features of the DIY receiver, and for some you will have to solder to the processor pins as far as I know.

[jhsa]

Btw. interesting information from Pascal regarding V2 firmware: https://www.rcgroups.com/forums/showpos ... count=8340

I said it many times, and I say it again, the MultiProtocol team and the DIY community in general should forget about the frsky protocol and create their own protocol, even if based on the actual frsky D16. We don't even need them for sensors as we have the OpenXsensor project, which is brilliant, and could only get even better. What is the point in keep hitting the same wall with out heads? Or is there any commercial interest from the Open source community?

João

[antlerhanger]

Btw. interesting information from Pascal regarding V2 firmware: https://www.rcgroups.com/forums/showpos ... count=8340

I said it many times, and I say it again, the MultiProtocol team and the DIY community in general should forget about the frsky protocol and create their own protocol, even if based on the actual frsky D16. We don't even need them for sensors as we have the OpenXsensor project, which is brilliant, and could only get even better. What is the point in keep hitting the same wall with out heads? Or is there any commercial interest from the Open source community?

João

++++1

[Kilrah]

I take the current effort as a demonstration that FrSky is wasting their time implementing useless protections, which they should rather be using to actually make their stuff better and more importantly test it so they stop releasing buggy stuff that frequently break compatibility and makes it a flashing hell for users...

But yeah it will likely end in an open source system being developed that is better than anything they make and that all their competitors will have access to.

[jhsa]

Should have done that long time ago. I am surprised that it took Frsky this long to start do what other companies always did. They have a business..
They did support the DIY community, and that was cool, but no one likes to see their own work and hardware being cloned and sold by other companies. Sorry, buy I can't blame them for that. Jumper for example, copied their hardware, uses their protocol, even if through the multi module, and still turns people against the legal owner of all that stuff. And I think it is a shame that I see so much hate, specially from open source software users against Frsky, many if not most, just relaying what they read on the forums, only because the open source firmware leaders said it.
If you don't like them anymore, please stop using their protocols. But stop all this hate, it is absolutely nonsense. Do your own stuff, you are clever enough.
As I always said, companies that want to make money and DIY and open source community do not mix. Stay away from each other.
That is why I build my own radios based on boards made specifically for existing radios like the 9x. And here is a good example of what I said above. We use flysky ancient 9x radio, they keep producing cos they know it sells, we never had anything to do with the company itself, and everybody is happy.
And another wonderful reason for using ErskyTX, is that despite the fact that it is at least as good as OpenTX, it is more DIY oriented, allowing for many more hardware possibilities, it has a smaller community that actually enjoys using it and it doesn't in general spreads hate on the forums. If there is an idea that Mike thinks is worth it, he just does it. No need to create stupid wars. If you don't like it, stop using it. I don't buy tx and receivers anymore, and will do so until some law forbids me..

João

[Carbo]

Some news from the CRC-group It seems, that V2.0.1 does not report 3 consecutive missing frames. Only the forth missing frame sets the lost frame bit.
The capture was published in fpv-community from a member of the Engel testteam.
https://fpv-community.de/threads/vorsic ... st-1044849

This is my evaluation:

My translation of the corresponding post:

ABBC3_SPOILER_SHOW

According to the previous procedure, the SBUS (consisting of 2 frames) is completely blocked if every second frame is a loss.
According to the new procedure, a valid frame is composed of the last three frames if a frame was not valid. So back to three frames, beyond that.
This is a major improvement in the SBUS latency.
Of course it takes some brain to understand that.
Everyone can retrace it here.

Any comments?

[MikeB]

Do we know if this only applies to LBT mode or does it apply to FCC as well?

Mike

[mak]

Should have done that long time ago. I am surprised that it took Frsky this long to start do what other companies always did. They have a business..
They did support the DIY community, and that was cool, but no one likes to see their own work and hardware being cloned and sold by other companies. Sorry, buy I can't blame them for that. Jumper for example, copied their hardware, uses their protocol, even if through the multi module, and still turns people against the legal owner of all that stuff. And I think it is a shame that I see so much hate, specially from open source software users against Frsky, many if not most, just relaying what they read on the forums, only because the open source firmware leaders said it.
If you don't like them anymore, please stop using their protocols. But stop all this hate, it is absolutely nonsense. Do your own stuff, you are clever enough.

Some are clever enough, and some are not - like Jumper / Hobby Porter. Instead they just blindly clone FrSky technology. So blindly, that they even copied X10 parts related and needed for FrOS only.

In the same time FrSky gathers all these rants, which are basically saying: you were copying others in the past, you grew on it, and so now you are not in a position to complain or take any action if somebody else is cloning you. Such a statement is wrong from the beginning to the very end. FrSky grew on own ACCST technology, starting from V, D series, later X. At the time it was real thing, offering long range, reliable link and telemetry at affordable price, not seen that low before. Other are bringing similar look of Taranis and JR radio. But nobody really know how FrSky came into it, under what agreement. Are there any JR complains about it? at least I never saw any (but not sure if they are not existing). Anyways, what would be a reason for FrSky to copy JR design illegally? Outer box of a radio is the easiest part to design from the scratch, and it is just a box - all RC radios looks basically the same. They did not copy the technology inside. There are also Crossfire claims, just because they were first in using particular Semtech chip, with certain capabilities. True, they were first, but they did not design this chip. This chip is standard product, open for any company to manufacture own applications (products, like RC receivers). FrSky put own protocols on this chip, not cloning Crossfire.

Regarding the D16 v2 topic: there is a recently discovered, known flaw, practically affecting EU-LBT firmware only, confirmed and identified by independent source (German/Swiss/Austrian team). FrSky was working with the team, released a fix, also for no longer supported receivers, which is positive. They could release the fix for only the newest lines or even say that ACCESS is the answer. They did not and we already have firmware for almost all affected receivers. In the same time they decided to introduce encryption, breaking down D16 v1 and v2 compatibility. But this is their protocol, their decision. They are not responsible for clone makers to catch-up.

Also there are voices that MPM will be affected. Truth is MPM module will not be affected for 99% of its protocols. Only one protocol - D16 - will be affected. So FrSky users using MPM are not harmed at all. Genuine FrSky users would not use MPM for D16 anyways. So only radios using MPM to clone D16 are affected. But again - this is not FrSky's fault or responsibility. I do not think FrSky aims MPM project as such - just cloners who are making money selling it, using FrSky protocols, without offering any value to the hobby.

FrSky have every right to protect themselves and fight clone makers.

There is one thing FrSky should do better. Better manage a change, especially better communicate and test.

[Kilrah]

They could release the fix for only the newest lines or even say that ACCESS is the answer.

No they could not. Well technically they could, but that would push most of their users to throw all their FrSky gear in the trash and switch to someone else.

[mak]

No they could not. Well technically they could, but that would push most of their users to throw all their FrSky gear in the trash and switch to someone else.

You are maybe right, and that may be one of the reasons they didn't. Another may be that they actually care about customers and didn't want to leave them behind with no solution.

Re switching to someone else, there is not too many options out there, offering similar variety of receivers and sensors at similar price tag. Not clones I mean. Only few can actually benefit from any D8/D16 receivers or open sensor DIY projects. Majority would need to switch to much more expensive options, which is not a real option for many.

[jhsa]

I agree. I think Frsky was ok with the MPM using their protocols until Jumper decided to use the MPM as their internal (main) module.. I even stopped following the MPM thread because it looks like it is now a jumper thread instead. At least it is the idea I get when I read it.
As I said, I do use the Frsky protocols, but I do build my radios, receivers and sensors, thanks to some excellent DIY projects. One of them being the MPM. Still running an old version of its firmware though as things are.going really fast and I am afraid it could affect reliability.

About the taranis radio case, I think Frsky bought the moulds from another radio that was probably very similar to the JR radio. That saved them from wasting time and money designing a case. They wanted the radio out as quick as possible, all this.if I am not mistaken of course..

João

[Kilrah]

Another may be that they actually care about customers and didn't want to leave them behind with no solution.

I doubt that one since last spring they released the X-Lite Pro and X9Lite with NO D16 backwards compatibility at all, only ACCESS, which led to them selling a radio that only had like 2 receivers it could work with at launch, with nothing more to expect before months. D16 was supposed to be discontinued entirely overnight.
They only backtracked, added D16 support back in and kept it alive because they got destroyed in reviews, nobody was buying the new products, and the few who did returned them because they had not noticed the change... which was kinda normal since FrSky hadn't mentioned it anywhere.
So since they've publicly committed to D16 being supported long term a few months ago they couldn't revert AGAIN by not fixing the current issue on all D16 equipment.

[mak]

I doubt that one since last spring they released the X-Lite Pro and X9Lite with NO D16 backwards compatibility at all, only ACCESS, which led to them selling a radio that only had like 2 receivers it could work with at launch, with nothing more to expect before months. D16 was supposed to be discontinued entirely overnight.
They only backtracked, added D16 support back in and kept it alive because they got destroyed in reviews, nobody was buying the new products, and the few who did returned them because they had not noticed the change... which was kinda normal since FrSky hadn't mentioned it anywhere.
So since they've publicly committed to D16 being supported long term a few months ago they couldn't revert AGAIN by not fixing the current issue on all D16 equipment.

I wrote if before, but I will repeat. FrSky should manage a change better.

There is nothing wrong with introducing new radio with no backward compatibility. At some point you need to move forward. But you should already have enough receivers to support new protocol. Otherwise it will not hold and they needed to change the approach. And fine, they listen to customers, nothing wrong with that.

Yet, it has nothing to do with their support provided even for older receivers to fix recently discovered D16 EU-LBT flaw.

[Kilrah]

It does because if you say "we're now going to support existing D16 receivers for several years", which they did, it would not have gone well if they hadn't done so for that fix.

[Carbo]

Do we know if this only applies to LBT mode or does it apply to FCC as well?

Mike

I've got no answer, needs to tested. It seems they have no clue about SBus. So it was an easy game for FrSky to sell them the suppressed lostframe information (until up to 3 frames in a row presumably, but I want to verify it).