Model file switch conversion utility

I've started work on a tool to help convert model files from on Tx to another. The major problem in doing this is that the switches change drastically from one model to another (unless you're dealing with an 8 and a 10, anyway). So the first step is trying to automate that.

At this point, it's just automates switch/src renaming. There's a config file (documented in the included default.ini file, which is included in the upload) that lets you set up some defaults, select from different conversions via command options, and add one-time switch mappings at invocation time.

A command line binary for windows is attached. Building from source is a bit complicated yet, as it's using an unreleased library for ini file parsing. Getting that release to simplify building is next on the list. If you want to try building it, sources and instructions can be found at chiselapp.com/user/mwm/repository/straight/home . You can also create bug reports and feature requests there.

No comments from me on future plans yet - I'd like to see what others think of before tainting the waters.

Edit: delete the file download. Download binary from drive.google.com/file/d/0B72nhihrc01MS0F...dVU/view?usp=sharing instead.

New edit: here's a 32-bit Windows binary as well: drive.google.com/file/d/0B72nhihrc01MT0F...Y2c/view?usp=sharing

I have an OSX binary available, but will need to put it elsewhere if someone wants it.

Would you mind posting a link to the binary? I'd love to try it out. Finally with the java uploader we can get rid of Windows. Except for the Model file manager

mwm wrote: I have an OSX binary available, but will need to put it elsewhere if someone wants it.

mwm wrote: I've started work on a tool to help convert model files from one Tx to another. The major problem in doing this is that the switches change drastically from one model to another (unless you're dealing with an 8 and a 10, anyway). So the first step is trying to automate that.

Wonderful idea. Perhaps model files could add an entry for the transmitter type they came from.

Thanks!

OSX binary (and default.ini) file is at: drive.google.com/file/d/0B72nhihrc01MSTV...Slk/view?usp=sharing

As for having the transmitter in the model file, I'm not sure how useful it will be. The ability to specify alternate/extra sections is really there to support multiple target transmitters.

It's not clear there's much use in knowing the source transmitter, since they basically come in three variants: 12/10/8, the 6, and the 7E variants. The 12 & 7E have a HOLD switch. The 6 has a DR switch instead of the AIL/ELE/RUD DR switches. I don't think you really need different configs for different source transmitters; you just need to build your cofnig carefully. If it turns out to be really useful to know the source Tx, I can add the ability to figure out which one it is.

Assuming this gets a some traction, I'll be working on letting users talk about functions instead of switches, so you can configure where you want throttle hold, flight modes, dual rates, and so on, and then convert the input model to match that.

New version available from drive.google.com/file/d/0B72nhihrc01MS0F...dVU/view?usp=sharing .

Mostly minor tweaks, though it should be a bit easier to use. But it matches the better documentation at chiselapp.com/user/mwm/repository/straight/doc/tip/README.md describing how to use it now.

How many people would be more interested in this if it had a GUI?

New update at drive.google.com/file/d/0B72nhihrc01MQlR...SGc/view?usp=sharing .

This one adds support for variables as switch names, and makes it easy to set up things from the command line. This gives me what I want, which is an easy way to convert models between my two Tx's. It also makes converting someone else's model easy by being able to specify things like "GEAR=hold" on the command line.

Given the lack of response (no one even mentioned that the Windows binary didn't actually implement the default file finding code!), I'm probably going to move on. If you're actually using it and would like to see features like a GUI, automatic detection of some of the switches, or the ability to deal with trim button switches, let me know. Otherwise - it's what I want, so I'm done.

It worked fine for me as well, thanks for your effort. I personally wouldn't need a GUI, but like stated somewhere else, I still believe we should upgrade the deviation uploader into a more powerful deviation manager. It should be able to upload firmware updates but also manage model files (as the model file manager utility) and do model file conversions for different DevoTXs. I think this would make Deviation a lot more user friendly!

This is a great facility. Haven't had a chance to give it a spin yet. (It's only been 4 days.)

Most appreciative of your efforts.

How about reassigning a function from a switch to a button or trim?

Thanks very much.

Reassigning switches to buttons or trims - and creating virtual analog inputs for the AUX sources - is handling trims. Just need to figure out what the name of such a thing would look like. I think it's going to be a language all it's own. I also need to figure out how to allocate trims and virtual channels for it. And since the number of trims varies depending on the target Tx, that has to be dealt with.

I think it's doable, it's more than a simple matter of programming.

Those facilities have an enormous amount of value. Even when you have a model all set up, it seems natural to want to move things around. Especially after you find some features turn out to be more important than you thought they would be.

Cramming the functionality of a fancy setup from a large radio into a 7e with a few simple steps seems very liberating, too.

Ok, I've just uploaded a new version.

This one automatically detects switch usage, and sets variables based on them. It should be able to automatically import many model files (6-channel helis, hobby-grade quads, and a lot of the toy quads) and have most things working.

I believe this is sufficiently automated that adding an "Import" feature to the model file manager would be worthwhile. You'd have to create a configuration for your setup that looks like:

ail dr=DR
ele dr=DR
rud dr=DR
timer=Virt1 -- to make the timer reset button a virtual channel
hold=HOLD
stunt=...
flip=...
light=...
video=...
still=...
headless=None -- to make sure you never actually use this feature!

then the model manager would have an "import" button for a model that would let you select a file from somewhere, and run straight to convert it to a model file. But I can't make those changes, so you'll have to bug greenfly (?) about it.

Advanced features (recalibration, rate setting on some of the toys, or hobby-grade quads that need more than a single switch for the flight mode channel) aren't handled. They may be to so irregular as to require individual handling anyway.

The toy-grade stuff is nearly that way. I wish I could bill whoever decided that the Flysky V6x6 extensions should use a different channel->feature order than the existing Flysky V9x9 extensions for the time that cost me.

As usual, see chiselapp.com/user/mwm/repository/straight/doc/tip/README.md for the latest info.

I'd be interested in implementing an import feature based on your model generation app. Let me download it and play with it first and I'll give it a shot.

Well, if there's something you'd like it to do for that, let me know. I haven't gotten a lot of feedback with explicit request changes.

What I could use are a couple of sample files to test with. Both starting files as well as what the resulting file should be. I am an RC newbie so I am not sure I could come up with very good tests for the utility.

Well, if you just want sample tests and don't care about whether they are actually useful, grab the source (instructions are in the "Building" section of the readme at chiselapp.com/user/mwm/repository/straight/doc/tip/README.md ), and look in the "tests" directory. There's a config file and a couple of input files. The ".test" files have a bunch of example runs and along with the output from them. The test proper probably won't work on windows, because they rely on being able to write to /dev/stdout to compare the results to what's in those files.

If you want examples of it actually converting from one thing to another, I could provide those as well, but don't have them handy.

I was just testing straight.exe and noticed that it changes the line endings in the model.ini from <LF> to <CR><LF>. Will the model file still work in Deviation with those line endings?

Hmm. That seems to be a feature(?) of the Windows build. The Unix & Mac versions don't do that.

Honestly, I don't know if that will work or not. If it doesn't, let me know and I'll build a version that fixes that.

The model files seem to work fine with a <CR><LF> as line endings.

Another issue may be the path separator you use to find the default.ini.




In Windows, you will need to use the backslash to define the path.

Have they changed Windows so it no longer accepts the forward slash in names? Or maybe that only works from the command line?

Anyway, it should be using backslashes on Windows. It should also be using AppData, not .config. It looks like it's getting the default config location - which is for Unix-like Systems - and not the Windows version. I'll poke at that some tonight.

Thanks for the report!