DM002 protocol (contains captures)

I've modified the Multi source file on GitHub to include all the features you have listed as well as both ID/RF.
Channels and details are listed there: github.com/pascallanger/DIY-Multiprotoco...etails.md#dm002---33

Please report.

Pascal

goebish wrote: I'll port it to Deviation, for now using an odd TX id will use the first txid/rf set and using an even one will use the 2nd set ...

I am ready to test for 7E

goebish wrote: test builds available: www.dropbox.com/sh/fswbehxnvd14cpy/AABQq...FnXWOtd9kvezBDa?dl=0
diff: github.com/goebish/deviation/commit/3865...8770719a65463d47ea89

protocol: DM002

mapping:
CHANNEL5, // Leds
CHANNEL6, // Flip
CHANNEL7, // Camera 1
CHANNEL8, // Camera 2
CHANNEL9, // Headless
CHANNEL10, // RTH

Not sure what CAMERA 1 & 2 means.

Missing DM002.mod file in the 7E build

I've looked quickly at your code
I don't think this will work: GET_FLAG(!CHANNEL_LED, DM002_FLAG_LED)
You need your GET_FLAG_INV macro instead (not sure of the name).
Pascal

goebish wrote: Thanks Pascal

@SeByDocKy, I updated the builds, should be fine now.

Yes it's working .... checking the extra channels now

LEd Ok

Headless ok

Flip Ok

I've left the cameras just in case there is another compatible quad out there needing them.
Strange that they appear in the doc if not used anywhere.

Pascal

Working fine ....


But the yaw command is presenting a lot of deadband, the same as for the original radio ..... No miiracle with the Devo

Tested with Taranis 9XD + multiprotocol module - everything works as expected

Some notes:
* Custom curve with deadband removal of -35..35 fixed the lazy yaw
* Rate modes LOW (default) and HIGH (ch11) are enough, with the plastic controller HIGH was too wild but with Taranis it is just great
* Difficult to achieve perfect trim with the control ranges at least in the HIGH rate (one click left causes left drift, one click back creates right drift). This might be just a feature of the quad but the analogue knobs in the TX could perhaps be mapped to the trims to achieve best effort. I sort of believe the trim steps have a lot smaller effect to the control than actual control steps.
* Bind on powerup seems not to work when selected from OpenTX. Would there be something i need to tweak in the protocol file or multiprotocol config?

However all this was great success, thanks guys!

Few more questions:
* How does the protocol enumeration get updated to the OpenTX software, do they include directly something from the multiprotocol repo?
* In the SPI captures, why was there data on the line at moments when the clock pulse was not active?

goebish wrote: Protocol trims are not implemented, because that would require 3 extra channels, they're set to default (0x7f), try to recalibrate the accelerometer to fix the issue.

The multimodule seems to have 16 channels and now the protocol only uses 1..11 so there would be room. In fact, the pitch and roll trims would be enough since yaw works just fine. The accelerometer calibration does not help here, tried it.