Model data

FDR wrote: About the model data:
I made some progress in discovering the model data. I know the meaning of 582 bytes of the total 912. This is all that needed for a heli config. (If I haven't missed something... )
I still have a feeling, that this format will be a limiting factor after some time. It's definitely not nice or universial, but it is at least small...
One possible way to keep some compatibility would be to use a side-config in the rest of the 4KB model data, but that would be ugly too.
Spectrum's model config is in plain text (at least the downloaded part), but it is about 11KB!

Another option would be full custom format, and make an own updater, which can convert them, but if we want to keep the wireless model data transfer feature, then the tx itself should be able to convert too.
I think it deserves a separate topic...

I can see a few options here:

1) We could just stick with the DEVO8 format. This doesn't seem ideal as I heard that the DEVO6 and 12 use different formats

2) We could use an API in the firmware that can read multiple formats, thus allowingthe upload of model data for any supported radio

3) We could write translators on the host side to convert to our own format before upload, and use only that on the Tx. the problem with this is that it may be difficult to support radio-radio model transfer which I think is supported by walkera?

PhracturedBlue wrote: I can see a few options here:

1) We could just stick with the DEVO8 format. This doesn't seem ideal as I heard that the DEVO6 and 12 use different formats

2) We could use an API in the firmware that can read multiple formats, thus allowingthe upload of model data for any supported radio

3) We could write translators on the host side to convert to our own format before upload, and use only that on the Tx. the problem with this is that it may be difficult to support radio-radio model transfer which I think is supported by walkera?

1. Yep, all DEVOs use different model data "format", if we can call it a format anyway.
It is a simple binary storage, optimized for size. For example the throttle curve output value's range is from 0.0% to 100.0% in 0.5% steps, so they use one byte for it witch range is from -100 to +100. Nice, isn't it?

2. Yes, I think this would be the best solution. It could be used for the wireless transfer (from tx to tx) too...
The only problem, we don't know all the formats.
It can be reverse engineered from the fw itself, or in the change-and-compare way I do now, but both are very time consuming. Yeah, and the second approach needs all kind of tx...

3. Walkera's wireless model data transfer is half legged too: it only works between two identical tx type. I guess they simply send out the binary model data and save it on the other side after some checks... It is the lazy way: they do not care about their other own formats.


The possible fourth option would be the side-config, which meant we use the original DEVO format for the functions it supports, and a separate config "file" for each model data to store the added features.
I don't really like this, it is only explainable if we only would like to hack in some features into the original fw.

I collect the model data info into an XLS file. Should I convert it to ODS?

I'm a bit worried about the size of the new model data format.
A simple binary file (like the current one) is not universal, but if we add some codes, the size increases like hell. Probably we should name only known format and size chunks to achieve expandibility, but keep the size down.
The other possibility is to sacrifice some library space for the model data...

Does somebody know how they calculate the expo curves in dual rate settings and in the output curves?

I would like to draw the curves in my model configurator identically if possible...

I am through with my model configurator sub-alpha version.
So far only helicopters are supported.
There are some missing checks and some defaults differ, but it seems working.
And there are no expo curves so far, only straight lines...

Airplanes are ahead. They have quite a few more mixes, which are the tierce of the model data...

Have you documented your findings anywhere? It would be useful to have them so we can either support it natively in the transmitter, or write a translator to our own format.

We should also start thinking about what data needs to be saved in our model-files. Ideally files should be < 4096 bytes (so they fit in a single sector), and the format should be extensible for future needs. A list of necessary capabilities/data would be a good place to start.

I collect then in an XLS.
I wanted to post it when it is ready, but so far only 601 bytes of the total 912 is known. These are for helicopters, the rest is only for airplanes...
Do you need it uncompleted?

It will be a long page in html!

The storage space will be critical.
Walkera's format is so dense, but in the meantime not really extensible, at least not in a nice way...
The elegant way would be an XML, but it would give at least 20KB I guess...
Any kind of format description, or table of contents will be more then the data itself!

Yeah, it's fine too, but whatever readable format you use it will be much longer, then the current binary one. They use one byte per setting most of the time!

They probably use structures for some blocks and dump or read them binary.
I think more of some kind of additional data description for the binary stored data.
For example: it should be defined how much channels we have, and which is what. Then we can assing functionality for a block of data for each channel. For example we only must know where the reverse bytes begin, because we already know that there are eight of them in the appropriate order.
That way only the structure should be defined once, like a schema definition, and the data could stay binary...

Here is an initial spec for what needs to be stored in the model data.
deviation.letsfpv.com/articles/6-deviation-model-specification

Feel free to add/change whatever is appropriate; I didn't spend too much time on it yet. Getting a specification for needed features is needed before deciding how to store the data.

As far as storage goes, as mentioned above, we should shoot for < 4kB, and for a format that is general enough to support any transmitter. That probably will end up requiring a binary format, but let's get a spec of what information need sto be stored 1st.

a) remember that we likely need to keep all parameters in RAM, so keeping the data small is important
b) I want a specification that can work on models like the DEVO7 with fewer resources
c) Due to how the filesystem is implemented, it is very benefitial to keep the file on a single sector, thus 4K.

Wow!
A lot of things to talk about at once!

First, short comments for the model page:

Requirements
- Model Name
- Model Type
- Protocol
- Model Description? Is this valuable?
- Icon
- Number of Channels
- Theme (allow selecting a different theme for each model?)

Model Name: can be a little bit longer, or are we stucked with the 8 char filename limit?

Model Type: What about other types? D12 supports gliders too, but what about quads, tanks or submarines?

Protocol: Yep, that is what I missed first too... Hovever it may be connected with the number of channels. There are protocols with fixed number of channels.
There might be a different protocol for the telemetry though. More about it there...

Model Description: It would be a useful feature, if space wasn't in question.

Icon: or picture of the actual model instead.

Number of Channels: channels used by the model, supported by the tx, and the protocol may differ. More about later...

Theme: It doesn't needed by model I think. It's a tx setting.


To be continued...

I think is better to send my model data xls for better understanding, even though it is not complete...

...continued:

Heli Specific options
- Flight Mode switch
- Throttle Hold switch
- Swash type
- Heading Hold switch
- Mixing controls

Airplane specific options
- Flaps switch
- Landing Gear switch

I am relatively new to the rc hobby, so don't know for sure, rather asking:

Is the Flight Mode switch and Throttle Hold heli only?
I think Mixing is general too...
What is heli specific is the Swash Mix, Pitch Curve and probably the Mix to Throttle I guess...

However airplanes have wing type, and a lot of special mixing. Sometimes they use two separate channels for aileron AFAIK. Airplane pilots do complain about DEVOs missing servo speed setting.

In general, all the specific mixes can be done with the universal program mix, but it is more convenient to use the specialized ones. This can be a design decision...

...continued 2:

Channel Info
- Channel Type (analog, binary, trinary)
- Channel assignment (assign channel to an internally understood control...throttle, elevator, flaps, etc)
- Channel max/min limits
- Channel trim sensitivity (amount of change per trim 'click')
- Channel reverse
- Expo Curve
- Dual rate control (which, if any, hardware switch controls dual/rate functionality)
- D/R expo curve
- D/R max/min limits
- Fail-safe settings

Trim: It needs the trim value too, not just the trim step. I don't know about the others, but Walkera uses a Sub Trim too, for initial fine positioning the servo arms.
There are "limited" flags too, whatever it means, but it would be a good idea if the trim range could be limited to a certain value...

I am a bit confused about your "Expo Curve" vs D/R+expo. Do you mean the Expo Curve is like the Throttle Curve and the Pitch Curve, but for every channel?
Then it is good, but a bit confusing (at least for me) too. I think these two functions do overlapping each other. Every D/R expo curve can be reproduced by the curve function, the only limitation for now is that curves are limited in the +-100% range, but the D/R can go to 125%, i.e. it has an effect on the travel adjust too.
May be it would be more clear if it was handled like the current program mixes, which can be set in normal mode (like a D/R) _OR_ with curves. How others handle this?