AlertPulse -- checkpoint

[gcmcnutt]

ok, gui prototype is in place -- and this works for bluetooth ch7 at least.

[gcmcnutt]

so other things:

• what is the workflow for updating screen shots for README.md, docs, etc. -- I changed fields in the general tab of the gui
• what is process for updating online docs/help to explain this new field?
• when it comes time to release, i see there are DBs of releases, etc. -- for now, perhaps @dlktdr can do this

[gcmcnutt]

(also I didn't base this on top of the most recent fix as that seemed to have a couple of regressions on my tests)

[dlktdr]

so other things:

• what is the workflow for updating screen shots for README.md, docs, etc. -- I changed fields in the general tab of the gui

You would need to fork the wiki and make a PR to update the graphics in there. Or I can do it when released.

• what is process for updating online docs/help to explain this new field?

Sent you a link so you can do edits on gitbook.

• when it comes time to release, i see there are DBs of releases, etc. -- for now, perhaps @dlktdr can do this

I can take care of this. Before we release this & the other new items,

1. Fix debug in the GUI for sure. So you can just click the values you want to monitor.
2. Gyro Calibration on boot needs more real world testing, it might be set to tightly to wait for zero. Also maybe something more obvious in the GUI too so the user knows there is no output because they haven't let it sit still.

[gcmcnutt]

I did rebase my change on the prior commit as the system wasn't running that well to the GUI -- once I get closer, will rebase on the top of master and debug from there.

Question, this additional field (alertch) seems extensible, e.g. it should just work if someone updates firmware but doesn't change the saved settings. But I'm not sure that upgrade pattern worked. I'll need to test that case a bit more.

I am looking more at the mechanisms for sending data back to the unit (sort of a master/slave bidirectional thing, or s-bus, etc. This feels like an OpenTX challenge, so I will dig a bit.

[gcmcnutt]

I was thinking of moving the README graphics into the source, vs being a reference out to media/gui -- that way updates track the version. Does this look right or am I missing something here?

Originally there was a bunch of graphics in the source, and was difficult to keep the Wiki updated, so they got moved to the wiki. Now that it's all on gitbook it does make sense moving it back as it's just a single screenshot graphic now. If you want to do a PR for this too I'm good with it.

Sent you a link so you can do edits on gitbook.

Ok, this works, I will work on the updates here.

👍 Just make notes what version it's coming with 2.2 in this case.

1. Fix debug in the GUI for sure. So you can just click the values you want to monitor.
2. Gyro Calibration on boot needs more real world testing, it might be set to tightly to wait for zero. Also maybe something more obvious in the GUI too so the user knows there is no output because they haven't let it sit still.

got it

Did you have any issues with the gyro calibration while testing. Did the red light didn't stay on excessively long on startup at all or seem pretty fluid?

[gcmcnutt]

I haven't rebased to the topmost changeset yet, as it wasn't working quite right -- so yeah, might be the IMU init stuff. I'll take a look (I see tonight the debugger passed US customs, so could be soon now).

And I haven't changed the version yet -- still prelim. Let me try out the rebase to top of master next.

Also regarding the README -- it references githubusercontent.../media/... What if we move this into a dir in the source so the images? Then the images follow the version at least for the top level readme...

[dlktdr]

This looks good to me, gave it a test works as it should, My radio now plays "Armed" when the camera is reset. Didn't have a Centered sound in there ;)

Thx for the contribution keep the ideas coming. Appreciate the help.