HiSKY protocol

Yes, hisky would be better suited.

Much better "HiSky"

semantics

http://www.banggood.com/DEVO-Transmitter-Tuner-Modified-For-FBL80-FBL100-WLtoys-V922-p-89812.html

[img]http://http://img.banggood.com/images/upload/2012/chenjianwei/SKU099478.M1.jpg
Anyone seen this yet?

andmiller wrote: http://www.banggood.com/DEVO-Transmitter-Tuner-Modified-For-FBL80-FBL100-WLtoys-V922-p-89812.html

Anyone seen this yet?

I saw this last night and its in my shopping cart, just can't tell if it is the module with the PA. Did you see this one:

www.banggood.com/2_4GHz-NRF24L01P-+-PA-+...le-V3_1-p-88956.html

I just changed the names in the patch, published above, all occurrences "FBL100" to "HiSky" and "fbl100" to "hisky". I think it probably is better.

So when you make a model file, one should use HiSky or hisky for the protocol ?

Don't know if deviation is case sensitive anyway.

Does the module from FF120 works as hisky module for deViation? Anyone knows?

blackmoon wrote: So when you make a model file, one should use HiSky or hisky for the protocol ?

In the model file used "protocol=HiSky".

victzh can you compile the devo7E version with this patch ? and provite to us the compiled lib as you did few times ago ?

mmm I really don't like the capital letters in the protocol name, this is giving room to human error.

protocol=hisky would be better imho, or all capitals, but all this could be irrelevant if deviation isn't case sensitive.

Usually you should set the protocol inside deviation so it will be written correctly. If you decide to do that outside via USB, you have to take care.
The actual names are DEVO, WK2801, WK2601, WK2401, DSM2, DSMX, J6Pro, Flysky, Hubsan4, Frsky-1, Frsky-2, Skyartec, V202, PPM, USB HID.
So I think your concerns are reasonless.

EDIT: deviation is case sensitive.

I fly almost exclusively micros, and I always edit my files on the computer, I rarely use the gui to do so, just for curves adjustment and things like that.

I'm maybe in the minority that does so.

Until now I only use DEVO, Flysky and Skyartec.

But you're right this shouldn't be of much concern for the majority of people.

blackmoon wrote: mmm I really don't like the capital letters in the protocol name, this is giving room to human error.

protocol=hisky would be better imho, or all capitals, but all this could be irrelevant if deviation isn't case sensitive.

I also think that it is better to make protocol names in model files or all lowercase or all uppercase. Maybe lowercase better. But the names of other protocols contain both upper-and lower-case letters. For example J6Pro, Flysky, Hubsan4, Skyartec. In the source code there is no separation of what is written on the screen and what is written in the model file.

It gets off topic, but has to be said:

blackmoon wrote: I'm maybe in the minority that does so.
...
But you're right this shouldn't be of much concern for the majority of people.

I confess my impression is that more people use the text editor.
Although I feel having deep knowledge about the source code and preferring a shell window over a gui I did never get familiar with changing the ini files directly. For what purpose? It is much more complicated than walking through some screens and it is nearly undocumented.
For me I have some templates I use for most of my models. I am happy with copying them and adapting the few parameters to my needs.
I see that for may people the step from a toy transmitter to a fully programmable like Devo (or Spektrum, Graupner, Futaba and many more) is not easy. This is also reflected by the amount of wishes to get a working config for modelX or Y - it is hard to understand the new possibilities and even the new terms they have never seen before. I was at this point not so long ago and I remember good my first steps. And at this time the only gui was the advanced gui - an additional step to climb... But after some hard time you will use it with great obviousness as if you have never done another way.
And the config files shall be hidden behind the gui. You can work with deviation without ever having opened a ini-file. They might be changed, possibly without notice. So working with them directly is only a good idea / acceptable / free of risk (choose one) if you really understand what you, especially know what the code does with the data you enter.

Good point rbe, but I'm a complicated type of guy.

It took me a very long time (including a lot of sleepless nights) coming from windows to linux, to learn the shell, etc.. intricacies, and being able to admin my system the right way.

Event tough I really suck at programing I like to understand what behind the curtain.

Having the whole file in front of me in an editor makes it easier to grasp what it does to the model, not counting the time lost in going trough all the menu and make the changes I want (I know this argument is not a strong one, but I really hate going trough all those menus ).

It has worked for me until now, and I suspect it works like that for others.

To each their own.

Sorry, I lost the focus in the last week, but I will recompile it with HiSky name.

Once again, it's not finished, and while it will fly your model, it would not be wise to use many instances of this code in different transmitters simultaneously. No HiSky fly-sessions for a while

I just applied babay's patch and sllewji's two 2-way switches patch to the last nightly.

Compiled for devo7E with sbstnp's deviation VM (you gotta love linux ).

Can't test it tough, I'm waiting my switches from Hobbyking.

If someone has both, fly alone , and is interested, I'll post it.

As always, use it at your own risks.

I applied kaworu's 3 position switch patch. (Takes the two switch mod and turn it into a single 3 position switch)

Plus added HiSky protocol from BaBay's patch.

Now, to wire up the 3 position switch and test it out.

You can test for yourself here:
app.box.com/s/tpepkzrfx2vwieqh10pw

Here's the included readme:

Nice! Thank you.