Model data

More
24 Apr 2012 13:47 - 24 Apr 2012 13:48 #12 by PhracturedBlue
Model data was created by PhracturedBlue

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?
Last edit: 24 Apr 2012 13:48 by PhracturedBlue.

Please Log in or Create an account to join the conversation.

More
24 Apr 2012 14:20 #14 by FDR
Replied by FDR on topic Re: Model data

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. :pinch:


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.

Please Log in or Create an account to join the conversation.

More
24 Apr 2012 19:15 #19 by rcH4x0r
Replied by rcH4x0r on topic Re: Model data
I think we should have one universal model data format. I particularly like FDR's idea of specifying the radio protocol as part of the model data :)

Backwards compatibility would be nice but it's going to get ugly quickly in the Tx FW if we try to support importing/exporting multiple Walkera formats and our own format

A PC based conversion tool would be my preference, then our FW can have one unified format and no overhead because Walkera release more TXs

How about documenting the model data? I am going to start an "article" for the settings data...

Please Log in or Create an account to join the conversation.

More
24 Apr 2012 19:50 #21 by FDR
Replied by FDR on topic Re: Model data
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...

Please Log in or Create an account to join the conversation.

More
25 Apr 2012 09:51 - 25 Apr 2012 09:52 #32 by FDR
Replied by FDR on topic Re: 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... ;)
Last edit: 25 Apr 2012 09:52 by FDR.

Please Log in or Create an account to join the conversation.

More
07 May 2012 15:04 - 07 May 2012 15:22 #210 by FDR
Replied by FDR on topic Re: Model data
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...
Last edit: 07 May 2012 15:22 by FDR.

Please Log in or Create an account to join the conversation.

More
08 May 2012 00:07 #216 by PhracturedBlue
Replied by PhracturedBlue on topic Re: 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.

Please Log in or Create an account to join the conversation.

More
08 May 2012 05:16 - 08 May 2012 05:25 #222 by FDR
Replied by FDR on topic Re: Model data
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! :lol:

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! :(
Last edit: 08 May 2012 05:25 by FDR.

Please Log in or Create an account to join the conversation.

More
08 May 2012 05:57 #223 by MatCat
Replied by MatCat on topic Re: Model data
What about json if you want a readable format, it's more compact then xml, though can be tricky for windows users :P

Please Log in or Create an account to join the conversation.

More
08 May 2012 06:09 - 08 May 2012 06:21 #224 by FDR
Replied by FDR on topic Re: Model data
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...
Last edit: 08 May 2012 06:21 by FDR.

Please Log in or Create an account to join the conversation.

More
08 May 2012 16:44 #225 by PhracturedBlue
Replied by PhracturedBlue on topic Re: Model data
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.

Please Log in or Create an account to join the conversation.

More
08 May 2012 19:17 #226 by MatCat
Replied by MatCat on topic Re: Model data
Looking over the model specs trim sensativity is how many 'clicks' of movement a single click of the trim will provide, default is 4.

Please Log in or Create an account to join the conversation.

More
09 May 2012 00:08 - 09 May 2012 00:09 #229 by rcH4x0r
Replied by rcH4x0r on topic Re: Model data
We will almost certainly have to go with a binary format just to keep the IO code down to a reasonable size.

I don't see a need to limit it to 4K tho, a native FAT filesystem will really help here. There is the issue of the flash sector size and slack space _but_ we could

1) Allow > 1 model per file (ugly) or
2) Allow lower bpp for gfx or even different bpp for different images (needs better bmp file support)
3) Restrict the number of languages to 1 (simply load the required language - who needs > 1 at any given time???)

All of these things would allow us to use the available flash more efficiently
Last edit: 09 May 2012 00:09 by rcH4x0r. Reason: fix typo

Please Log in or Create an account to join the conversation.

More
09 May 2012 00:13 #230 by rcH4x0r
Replied by rcH4x0r on topic Re: Model data
We should add to the model data
- Protocol
- Option to replace icon with picture of the model, a la high end Futaba gear...

Please Log in or Create an account to join the conversation.

More
09 May 2012 00:43 #231 by MatCat
Replied by MatCat on topic Re: Model data
I take it the 4 megs available is total available space for graphics, model data, etc right? Even at 10k a model file you would have room for roughly 400 models not counting space needed for images and such.

Please Log in or Create an account to join the conversation.

More
09 May 2012 00:51 #232 by PhracturedBlue
Replied by PhracturedBlue on topic Re: Model data
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.

Please Log in or Create an account to join the conversation.

More
09 May 2012 06:16 - 09 May 2012 08:03 #234 by FDR
Replied by FDR on topic Re: Model data
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... ;)
Last edit: 09 May 2012 08:03 by FDR. Reason: language

Please Log in or Create an account to join the conversation.

More
09 May 2012 08:11 - 09 May 2012 08:12 #236 by FDR
Replied by FDR on topic Re: Model data
I think is better to send my model data xls for better understanding, even though it is not complete...
Attachments:
Last edit: 09 May 2012 08:12 by FDR.

Please Log in or Create an account to join the conversation.

More
09 May 2012 08:26 #237 by FDR
Replied by FDR on topic Re: Model data
...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...

Please Log in or Create an account to join the conversation.

More
09 May 2012 10:26 #238 by FDR
Replied by FDR on topic Re: Model data
...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?

Please Log in or Create an account to join the conversation.

Time to create page: 0.151 seconds
Powered by Kunena Forum