Advanced Search

...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?

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

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

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

Deep in working on window redraw... got slowed down by some pointer issues I am still working out...

I tried to create a pointer on the guiObject struct to guiBox inside of gui element struct however it doesn't seem to want to work right . But I am gonna figure it out.

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.

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.

We should add to the model data
- Protocol
- Option to replace icon with picture of the model, a la high end Futaba gear...

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

Nice work, I am sure mass storage is going to be one of the killer features of the Deviation FW.

Now, if I can just remember which box I packed my Devo 8 in I could check it out.... (and maybe do some more work on the protocol stack too)

Looking over the model specs trim sensativity is how many 'clicks' of movement a single click of the trim will provide, default is 4.

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.

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

What about json if you want a readable format, it's more compact then xml, though can be tricky for windows users

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!

I may need to install some plugins first, I will set it to 20 globally now though.

I don't suppose you know how to change the # of posts per page as a user setting? I looked through all the settings I can find, and I don't see anything like that. I generally set it to 25 for most boards.

Yeah, I do believe there are personal settings for how many posts per page, though I will change the default to 10? (I personally set it to 20 myself).

I will look into the smileys, and for sure the edit window could be made bigger.

The forum software is pretty, and overall I'm satisfied with it, but I'd really like to be able to change the number of posts/page. 6 posts per page is a ridiculously small number.

I'd also like the ability to disable smileys in a given post.
also, the font used for the edit window is very small.

Any chance we can fix some of this stuff?

Yep was there on pull .