Model data

Telemetry:
We need support for Walera's telemetry module(s) and telemetry capable receivers, that's one protocol. But if we will support other receivers, we should support other telemetry modules and their protocols too, I guess (at least in the distant future ).
So universally we need to configure the protocol, the number of values (aka channels) to receive, unit for all of them, and a configurable alarm bound to...

Oh yeah, I forgot about some settings:
- Power Amplifier;
- Fixed ID;
- Stick position switch (better would be a "Channel Value Switch");
- Timers with alarm;
- Trainer settings...

I was thinking about the file format.
I will try to describe one possible format came to my mind (it is a bit like dfu):

- It should start with some readable mime-type-like, for example 'DEVI'
- Then there should be a version first, to assure future extensibility with backward compatibility.
- after that may be the size;
- a name on fixed length;
- contents entry count;
- here begins the content table (with unified entry sizes);
- the actual binary data;
- and the last four bytes is CRC.

The key is the entry record. It would contain:
- a unique lookup string or value, which identifies a setting (group);
- data structure type, for example i8, u8, i16, u16, i32, u32, or more complex ones like curve points;
- number of such a structures in row;
- offset to that data;
- data length perhaps.

This structure probably has to be changed in the future, that's why the version number is so important. Walkera missed to version it, they may have difficulties in the future if they want to add features...


EDIT: Almost forgot, the most difficult part is that some settings are repeated by some factors we should know about. It is the channel most of the time or the flight mode, or even by both! Of course the code could know this by hardcoding the setting code, or we can include this in the entry record for a more universial approach...

My idea for the format was probably close to what rcH4x0r has in mind. A header followed by a table describing which features are present and their offset in the file (generic data, type-specific data, location of each channel,...)
you'd then have a parser that dealt with each capability.
This makes it easily extensible (add a new type, and you can add more data).
Each data type has something similar. a list of configurations defined, followed by the data.
Thus a channel that needs no curve settings, but instead only max/min would be realy small, whereas a rudder control with separate curves for normal and D/R, trim settings, etc would be as big as needed. Again using a key to define the setting (rather than a hardcoded 'struct' format) allows for extensibility.
I understand the benefit of a database, but I am concerned it would be harder for users to manage their models since we'd need external programs to build and maintain the database, and sharing would be harder. Since we'll likely be using our own format, having the ability to easily share model data is important.

All that said, I think it is better to finish the list of what capabilities we need. It will make it easier to define a format which is likely to last.

All right!
I just worried about the size of the data description. However if some of the data is optional it will help, but if somebody makes a lot of changes, the file size might go large...
Actually the Walkera format has a lot of redundancy in it. For example a program mix is either normal or curve, but both settings take their own space...

Will my XLS help in that?
Now I rather use the model configurator , because it is much easier to see, what settings are there...

I'll try to address all the questions about model data here...
I'm in agreement with rcH4x0r, defining the channel type has little value. treating switches as analog should work fine.

Honestly, I haven't flown anything other than 4ch planes and 6ch helis, so I don't have a good feel for everything that is needed.

General stuff:

The file names need to be 8.3, but there is no need that model names be limited to 8 characters. Given the desir to support other languages, I'd say we should not use filename as the model name.

Protocol is radio-protocol. so it'll be devo, dsm2, flysky, frysky, etc. It has nothing to do with number of channels.

I could see it being useful to have a different theme for airplanes, helis, and ground vehicles (I'm mostly thinking about the layout of the main-screen)


Transmitter power: Why would thissetting be per-model? Wouldn't this be a transmitter config vs a model config?

Fixed ID: again, why isn't this a transmitter setting? If I want to share models between users, then saving the fixed-id doesn't make sense. Or maybe I have it backwards. is Fixed ID unique to a given receiver?

Stick position switch/channel value switch: I'm not sure what you mean here. Is it like transmitter mode1 vs mode2? That would not seem to be model specific to me. If you mean how channels are mappedto hardware, I think that should also be abstracted so that the same model data can work on multiple transmitters.

Timers/Alarms. What are these used for? Are they really model specific? An example of a use would be helpful.

Trainer Settings: What types of settings do you have here?

Model specific:
I expected that mixing could be generalized rather than needing special code for helis vs planes. so we could define a generic mixing capability that could handle collective, ailerons, etc. I'm not sure I understand the need for pitch curves. If the mixing capabilities include curves, then I don't really need to predefine specific sets. So this stuff may not actually be model specific, but instead mixer settngs would go into their own section.

Channel data:
What does 'trim value' mean? You mean what value it should start up as? Yes we need that
Limited mode seems to mean that the trim only applies over part of the range. so at full thrown, the trim doesn't apply. We could probably do that by setting a trim max/min limit

Forget about the 'expo' part of the curves. we need to be able to define curves for high vs low rates. I was thinking that having a set of curves for high and low rates would give full control, and not require any additional 'expo' settings. With curves, I don't really need max/min channel values, since the curves will define this for us. If we define 100% as the 'real' maximum value, then low rate curves would just peak out at 75%

I've made various updates to the article. Please feel free to directly modify it.

rcH4x0r wrote: Well, I am thinking more in terms of how C++ and derived classes or TCP/IP packets work. Think onion skins and you won't be far off. The onion skin model would help us to avoid a lot of redundant data since it simply wont be present.

The alternative is probably lots of code like this:

if(airplane)
{
}
else if(helicopter)
{
}
else if (...)

I agree that we want a data format that minimizes duplication/unnecessary info, and that I really don't want if/then/else conditions in the firmware for the model type. That is why I was thinking we may have different 'themes' (think main window layout) for different models. However, there are things like showing an icon for flaps/gear/etc that we need to design to not need if/then/else cases to display. I think that moves into trying to define a GUI spec, though it will likely be tied to the model data in some way.

PhracturedBlue wrote: General stuff:

The file names need to be 8.3, but there is no need that model names be limited to 8 characters. Given the desir to support other languages, I'd say we should not use filename as the model name.

Agree.

PhracturedBlue wrote: Protocol is radio-protocol. so it'll be devo, dsm2, flysky, frysky, etc. It has nothing to do with number of channels.

Not really. It would be great if we could support the old Walkera protocols. The whole old Walkera userbase is obset about the DEVOs are not backward compatible.
Those protocols of 24xx, 26xx and 28xx transmitters are bound to be 4, 6 and 8 channel. Yes it is obsolete, but a lot of helis out there use these protocols. Some RCGroups users have 20-30 of them...

PhracturedBlue wrote: I could see it being useful to have a different theme for airplanes, helis, and ground vehicles (I'm mostly thinking about the layout of the main-screen)

Ah, I see. Don't know how useful it is, but no need to drop good ideas just because they seem useless for some. They might be very important for others.

PhracturedBlue wrote: Transmitter power: Why would thissetting be per-model? Wouldn't this be a transmitter config vs a model config?

It is model based, because one doesn't need the whole 100mW power for an indoor micro heli, while it definitely needed for large airplanes. The full power drains power faster and cause unwanted radiation indoors...

PhracturedBlue wrote: Fixed ID: again, why isn't this a transmitter setting? If I want to share models between users, then saving the fixed-id doesn't make sense. Or maybe I have it backwards. is Fixed ID unique to a given receiver?

Fixed ID in Walkera word means no auto binding, i.e. faster bind process. You can set the fixed id value from 1 to 999999 (it default some value unique for the transmitter). The transmitter sends that id to the receiver, which memorize it, and can only cleared by plugging a "bind plug" (should be called unbind plug) into the receiver. One can assign different id for all of his models, avoiding to control it with the wrong model selected, which can be catastrophic.

PhracturedBlue wrote: Stick position switch/channel value switch: I'm not sure what you mean here. Is it like transmitter mode1 vs mode2? That would not seem to be model specific to me. If you mean how channels are mappedto hardware, I think that should also be abstracted so that the same model data can work on multiple transmitters.

Timers/Alarms. What are these used for? Are they really model specific? An example of a use would be helpful.

Now the DEVOs have two definable stick position switches. They are software switches. It means that when the choosen stick reach a defined position the SPS changes it's value from off to on (or vice versa). It can be used to turn on/off a lot of things, for example a mix can be activated when aileron is 50% left. However the most use they get for starting the timers. When you raise the throttle to 5% it starts the countdown timer, which is programmed for 4:30, because you know, that after that you should land before the battery goes flat. That's the only way you can dependantly measure flight time. (Actually it would be better if it was Channel Value Switch, so throttle hold can stop it in case of the throttle, and it would be more reliable in idle up modes too...)
So the timers are model specific, because each model has different flight times.

Telemetry data for the battery voltage is a better way, but not always available. More about it later...

PhracturedBlue wrote: Trainer Settings: What types of settings do you have here?

You can set which channels controls the trainer.

PhracturedBlue wrote: Model specific:
I expected that mixing could be generalized rather than needing special code for helis vs planes. so we could define a generic mixing capability that could handle collective, ailerons, etc. I'm not sure I understand the need for pitch curves. If the mixing capabilities include curves, then I don't really need to predefine specific sets. So this stuff may not actually be model specific, but instead mixer settngs would go into their own section.

The mixing (as far as the standard program mix goes) is very much alike for helis and planes, but for planes it is a bit more complicated. All the other mixes are the comfortable/lazy/stupid ones (choose as you wish ).
But the users are used to them...
I think most of the users couldn't do a proper program mix.

PhracturedBlue wrote: Channel data:
What does 'trim value' mean? You mean what value it should start up as? Yes we need that
Limited mode seems to mean that the trim only applies over part of the range. so at full thrown, the trim doesn't apply. We could probably do that by setting a trim max/min limit

I think trims are mostly for helis (+quads) hovering. I correct the mid sticks so without any input it can hover in place. They complement the mechanical setup as a fine tune setting. They retain their values between flights, that's why they are model specific settings.

PhracturedBlue wrote: Forget about the 'expo' part of the curves. we need to be able to define curves for high vs low rates. I was thinking that having a set of curves for high and low rates would give full control, and not require any additional 'expo' settings. With curves, I don't really need max/min channel values, since the curves will define this for us. If we define 100% as the 'real' maximum value, then low rate curves would just peak out at 75%

It's a long story, and it is like the question of mixes: all the min/max + expo values can be simulated with a multi point exponential curve, but it is much more complicated.
I wish my model configurator can draw curved lines, but as I don't know the algorytm they used, it only draws straight lines. It would be good for practicing with these settings, because it is much simpler and quicker to use, than the tranmitter.
But until that, you might want to flash it back to the original fw and play with that a bit...

FDR wrote:

PhracturedBlue wrote: Protocol is radio-protocol. so it'll be devo, dsm2, flysky, frysky, etc. It has nothing to do with number of channels.

Not really. It would be great if we could support the old Walkera protocols. The whole old Walkera userbase is obset about the DEVOs are not backward compatible.
Those protocols of 24xx, 26xx and 28xx transmitters are bound to be 4, 6 and 8 channel. Yes it is obsolete, but a lot of helis out there use these protocols. Some RCGroups users have 20-30 of them...

I think we're talking past each other here.it doesn't matter if we are emulating 24xx, 26xx, Devo, DSM2. Each of those are (probably) a different protocol, and the maximum # of channels supported by the protocol is fixed. So protocol will just be one of: devo 24xx, 26xx, etc. The 'number of channels' field represents the number of channels used by the model. It obviously can not be larger than the number of channels supported by the protocol, but it very well can be less.

FDR wrote:

PhracturedBlue wrote: Transmitter power: Why would thissetting be per-model? Wouldn't this be a transmitter config vs a model config?

It is model based, because one doesn't need the whole 100mW power for an indoor micro heli, while it definitely needed for large airplanes. The full power drains power faster and cause unwanted radiation indoors...

Fair enough, but it probably belongs in a 'radio' or 'protocol' specific section (still part of the model data). Not all radios have control over the Tx power. I guess it'll depend on how many radio/protocolo specific settings there are as to whether we need different handlers, or just ignore unneeded values.

FDR wrote: Fixed ID in Walkera word means no auto binding, i.e. faster bind process. You can set the fixed id value from 1 to 999999 (it default some value unique for the transmitter). The transmitter sends that id to the receiver, which memorize it, and can only cleared by plugging a "bind plug" (should be called unbind plug) into the receiver. One can assign different id for all of his models, avoiding to control it with the wrong model selected, which can be catastrophic.

Thanks, that makes sense

FDR wrote: Stick position switch/channel value switch:
Timers/Alarms:

Thanks, that makes sense.

FDR wrote: The mixing (as far as the standard program mix goes) is very much alike for helis and planes, but for planes it is a bit more complicated. All the other mixes are the comfortable/lazy/stupid ones (choose as you wish ).
But the users are used to them...
I think most of the users couldn't do a proper program mix.

Remember, we are talking only about the data format here. How the information is displayed to the user is not necessary the same. It will be much easier programatically to convert user input into a curve, and use a single translation function. I honestly don't know enough about the types of mixing we need to be able to specify requirements for it, but I'd hope the same applies (we give the user a friendly interface, but store the data in a standard way

FDR wrote: But until that, you might want to flash it back to the original fw and play with that a bit...

The problem for me is that I don't have any models that actually can bind to my Devo8. So yes I can play with the settings, but I can't easily see how they translate into real-world use.

PhracturedBlue wrote: The problem for me is that I don't have any models that actually can bind to my Devo8. So yes I can play with the settings, but I can't easily see how they translate into real-world use.

I see, but at least you can see on the graphs what it will do.
A more scenic way is to go into the monitor mode and watch what the output channels do depending on some mixes and/or expos. Not too scientific, but illuminating...

The whole thing can be quite complex, since everything depends on flight mode, on the applied mixes, which for example can only affect in some part of the transfer function, or even activating on a value like an agent Smith from the Matrix...

But other then expo curves you can visit my model configurator too, to dive into the deeps of all the settings.

Otherwise I agree, that most of the mixes can be stored in an universial form, but is it worth it? However I would do that in case of model data conversions if there is not direct subtitution for a mix setting.

I installed ER9x on my Flysky 9x (it turns out that a old Mouse PS/2 connector fits perfectly into the antenna hole, so I have a nice plug for connecting the programmer port now). Having played with it a little, and getting it setup to fly my V911:
a) I haven't yet found an equation based expo, but haven't looked too hard
b) They use 5 or 9 point piecewise-linear curves
c) They define curves separately from the channels (so you define a curve and then assign it to a channel). I'm not convinced of this approach. How often would you want multiple channels to have an identical curve?
d) The interface is not very user-friendly at all. Figuring out how to assign channels and set channel-reverse isn't where I'd look for it. I was constantly referring to the manual.
In short, I don't think it would be a good idea to take the design interface from this project.

I have started to discover the airplane settings.
So far known: 762/912

What a mess is there!

I've got all the model data!
OK, except one byte, and also guessed quite a few from the pattern...

I've update the article on model data with the results of implementing the mixer. It will be an interesting task to try to map models from the Walkera format to the mixer-based system. We'll probably want some sort of program that can do that to make it easy to move existing models. I'm not yet sure it can be automated though.