-
-
Notifications
You must be signed in to change notification settings - Fork 398
chore: refactor "Flysky gimbal" to "Serial gimbal" #5713
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
The issue I can see is there might be other serial gimbal protocols looming around.. |
As the same proto was used by also other companies as FS, the name seemed not appropriate anymore. |
IMO... yes and no... if the same protocol is being used... and Flysky came up with it first... then it is still Flysky serial protocol... but I think perhaps it is more that new radios, i.e. GX12 is using serial gimbals, not necessarily Flysky protocol, so instead a new specifier is needed to cover that case, or at least a generic specifier. i.e. perhaps "flysky serial gimbal" is a subtype of "serial gimbal" ;) |
GX12 is using flysky serial gimbal protocol, I was thinking about another manufacturer which serial gimbal will use a completely different protocol. I'm personally not too fussed that the first to bring up a feature/standard/code gets his name for it, we call CRSF the radio to module ELRS protocol too |
I have concern about this. Flysky has a new version of protocol which supports sync sampling. And I am working on it, and I cannot guarantee that this change is compatible with other serial gimbals. I think the best way is to split the implementations. |
That's a possibility, but then how do we select which one to use ? Ok, Flysky radio get FS one, RM rm; Jumper jumper, but what does it mean for say FrSky radio that wants to add one of those 3. Do we include none and provide a compilation option for user to build their own custom firmware ? |
Also, what if non-FS radio is modded with FS gimbals, like is possible: https://github.com/EdgeTX/edgetx/wiki/Flysky-Hall-Sticks-Mod Ideally, our code should auto-detect the gimbal attached. |
Ideally I would agree, but I don't think any of those protocols actually allows that |
The present FS implementation has a checksum, which could be one way to validate if present non-sync FS protocol is being used, or not. |
RM serial gimbal use 100% the same code, but for synchronisation where they use a dedicated line, so at this point in time, I have forced it on GX12 to assume it is a RM gimbal, so it uses Flysky serial code, and forces RM synchronization |
And my opinion is not necessary to do this renaming at this moment. RM just made a Flysky protocol compatible gimbal with sync enhancement. Not quite original to worth any refactoring effort just for a name! |
Can we get consensus on this? I am of the opinion of "flysky gimbals" can be a subset of "serial" gimbals, but this is contingent on a second serial gimbal being present, requiring slightly different handling. Otherwise, very much, whatever. |
I am with you that the top-level description for serially attached gimbals should be SerialGimbals, which could then have subdescriptors for variants, like SerialGimbalFS/SerialGimbalFlysky and so on. |
First take a look at #5869 Now there are gimbals that implement:
Now auto detection is only done for Flysky v2.0 protocol, maybe we need to figure out a way to distinguish 1 and 2 as well. And I think the change should be made on top of #5869 |
No description provided.