Countdown to release [updated 2012-08-15]

Before releasing the 1st alpha that can be loaded onto the Tx, I want to release the emulator so we can get feedback and hopefully more testing on it. Since things seem to be coming along nicely now, so I thought I'd start a list of tasks that need to be completed before releasing the 1st version.

Before releasing the emulator:
* Save state such that transmitter starts on the last-used model
* Implement timers
* Implement swash settings
* Allow main page to be configurable
* Implement menuing
* hook up the trims
* implement predefined-templates
* show protocol based default channel assignments
* Get a few bigger fonts
* Replace Walkera icons with our own

There is a bunch of additional work needed before releasing the 1st alpha that can go on the Tx:
* Wait for all switches to be in safe-state before enabling Tx
* Implement a channel-selection scheme
* Verify channel mappings on each Rx
* Enable changing the transmit power
* Ensure transmit reliability
* Do Range checks

If anyone has any comments or additions, please add them here.

This is a lot of things to do!
I will try to reflect one by one...

PhracturedBlue wrote: * Wait for all switches to be in safe-state before enabling Tx

It is a bit contradictional thing for me.
These are computers. If something goes wrong, you can't do anything but restart it. If the restart is blocked, because the keys are on, you will fall out of sky for sure. True, the restart only works if you use fixed ID's and they determine which channels are used.
@PB: knowing all the protocols already, can the restarting work at all, or it is just a bad idea of mine?

There is at least one switch, that can be on, the throttle hold switch. But since we do not configure a throttle hold directly, but it is only a final mix if I'm right, it will be difficult to decide, if that switch can be on at startup or not.

What, if we check some channel value on startup, i.e. is the throttle is on?

FDR wrote:

PhracturedBlue wrote: * Wait for all switches to be in safe-state before enabling Tx

It is a bit contradictional thing for me.
These are computers. If something goes wrong, you can't do anything but restart it. If the restart is blocked, because the keys are on, you will fall out of sky for sure. True, the restart only works if you use fixed ID's and they determine which channels are used.
@PB: knowing all the protocols already, can the restarting work at all, or it is just a bad idea of mine?

You can't restart your radio with the model in flight without catostrophic failure. The 1st thing the radio does after botup is to determine the transmit frequencies. I'm not aware of any rceiver that will accept changing the frequency after binding. The radio could theoretically save the last used frequencies, and restart with them if you start while holding a designated button, but really, this isn't worth it. Especially with the Devo8 where you need to pull the battery to recover from a hang...

There is at least one switch, that can be on, the throttle hold switch. But since we do not configure a throttle hold directly, but it is only a final mix if I'm right, it will be difficult to decide, if that switch can be on at startup or not.
What, if we check some channel value on startup, i.e. is the throttle is on?

Yes, my thought was to ensure that all channels are in the 'safe' state as opposed to having all switches in a specific state. Since you can map each switch how you want, there is really no other option.
I haven't figured out yet exactly how I'll do it though.

PhracturedBlue wrote: You can't restart your radio with the model in flight without catostrophic failure. The 1st thing the radio does after botup is to determine the transmit frequencies. I'm not aware of any rceiver that will accept changing the frequency after binding. The radio could theoretically save the last used frequencies, and restart with them if you start while holding a designated button, but really, this isn't worth it. Especially with the Devo8 where you need to pull the battery to recover from a hang...

OK, nevermind...
I just remembered, that I've read somewhere, that they use the same 3 channels if you use fixed ID. It might be about the 2801? Probably that wasn't correct anyway...

Ok, so I think the emulator is basically good to go. I'm definitely interested in any additional feedback.

I've also created a stub article for the user's guide. The deviation firmware is quite complex, and I think we need some training docs to help get folks started.

Using an article didn't seem like it was going to work for me, so here is a PDF with a rough outline.
I did it in Word, but I'll try exporting it as ODT and including it in the deviation repo.

Hmm...do attachments not work? I'm not sure how to provide the PDF at the moment...

PhracturedBlue wrote: Using an article didn't seem like it was going to work for me, so here is a PDF with a rough outline.
I did it in Word, but I'll try exporting it as ODT and including it in the deviation repo.

Hmm...do attachments not work? I'm not sure how to provide the PDF at the moment...

Well, here's a temporary link until the attachments are fixed:
dl.dropbox.com/u/52854517/Deviation%20Users%20Manual.pdf

Edit: I installed the source document into the repo. I'm using a .fodt file-format because it plays well with Hg, however, it is only readable by OpenOffice/Libre Office. Oh well, In the end we'll only distribute the PDF so it should be fine.

Perhaps there should be a version number, which can be referenced later...
It could be shown on the USB screen for example...

Well, I'm making progress towards the 1st alpha release. Getting safety switches enabled is my next priority

Some more features to consider:

- tx battery alarm (customizable alarm voltage), and indication (for example different customizable color for the alarm level);

- indication of auto binding (how to bind is the more confusing thing for those, who are new to Walkeras);

- telemetry.

I don't plan to implement telemetry for the 1st release. It requires a lot of work to figure out how to handle it properly.

OK, what about the other two?

FDR wrote: - indication of auto binding (how to bind is the more confusing thing for those, who are new to Walkeras);

What exactly are you thinking for this?
Just some sort of indication for the 1st 10seconds (or whatever) when binding is in process? Some sort of indication when it is done? something else entirely?

PhracturedBlue wrote:

FDR wrote: - indication of auto binding (how to bind is the more confusing thing for those, who are new to Walkeras);

What exactly are you thinking for this?
Just some sort of indication for the 1st 10seconds (or whatever) when binding is in process? Some sort of indication when it is done? something else entirely?

The original fw shows a splash screen, and animates a progress bar while binding. But nobody knows, that it is actually binding! Everybody think it inicializes itself...

So basicly I would like a screen with the loaded model name, and a message, that it is binding now.
The best would be the empty main screen with all the header loaded, and the message in the middle.
After binding is done, it would change to the normal main screen...

One more thing about it: the original could cancel the binding process with a stick move or button press. However I don't know, how it stopped the binding countdown in the packages...

I implemented a binding dialog. It isn't the same as what Walkera does, but I think it clarifies the process. The dialog can be cancelled, but binding cannot (i.e. closing the dialog does not stop the binding process but does provide access to the Tx controls)
I also implemented a tone that will fire when binding is complete. this tone is completely independent of the binding dialog.

I have not yet implemented a way to initiate a manual binding though. that is upcoming.

EDIT: Also, in the emulator the binding timer will be inaccurate. It should be reasonably close on the Tx though.

PhracturedBlue wrote: I implemented a binding dialog. It isn't the same as what Walkera does, but I think it clarifies the process. The dialog can be cancelled, but binding cannot (i.e. closing the dialog does not stop the binding process but does provide access to the Tx controls)
I also implemented a tone that will fire when binding is complete. this tone is completely independent of the binding dialog.

I have not yet implemented a way to initiate a manual binding though. that is upcoming.

EDIT: Also, in the emulator the binding timer will be inaccurate. It should be reasonably close on the Tx though.

There are some glitches...

The binding dialog doesn't always come up when I switch models.
It doesn't always close itself.
Escpecially if I close it before time with the button...

EDIT: I investigated it further.
So the problem only appears, if somebody clicks on OK and selects another model within the binding period. Then the binding message won't appear, but the binding time restarts, so if someone keep switching models, then there will be no message at all. If I wait more then 10s since the last model switch, then the binding message appears again.

EDIT 2: Not too important, but could you size the dialog to hide all the controls, or even to fill the page? Then some message lines could be separated with a blank line too for grouping the information in it. For example after the first two, and before the last...

I fixed the issue of the dialog not resetting.
I also added some spaces in the text, though I'm not sure why I'd want to expand the dialog. If anything I'd rather make it smaller so it looked more like a dialog pop-up

PhracturedBlue wrote: I fixed the issue of the dialog not resetting.
I also added some spaces in the text, though I'm not sure why I'd want to expand the dialog. If anything I'd rather make it smaller so it looked more like a dialog pop-up

Well, I didn't think there will be that much text!
But there are only a few pixels visible from the main page controls, which is not too nice...

FDR wrote:

PhracturedBlue wrote: I fixed the issue of the dialog not resetting.
I also added some spaces in the text, though I'm not sure why I'd want to expand the dialog. If anything I'd rather make it smaller so it looked more like a dialog pop-up

Well, I didn't think there will be that much text!
But there are only a few pixels visible from the main page controls, which is not too nice...

Feel free to change the text and/or the size however you like.
It is in dialogs.c