DM002 protocol (contains captures)

Tested on my devo 7e. Perfect! Much better than previous ver. 6328af8. Now there is no drift. Very stable. Great overing. Thanks. Good job!
Just a question: In the channel mapping "low rate" is ch11. In my devo7e the protocol dm002 give to me max ch10. Where i am wrong?
I refer to this mapping:

DM002 - 33
Autobind protocol
Only 2 TX IDs available, change RX_Num value 0-1 to cycle through them
CH1 A
CH2 E
CH3 T
CH4 R
CH5 FLIP
CH6 LED
CH7 CAMERA 1
CH8 CAMERA 2
CH9 HEADLESS
CH10 RTH
CH11 RATE_LOW

p.s. led channel is ch7 for me. Ch9 ok headless. Other channel work in progress.......

Sorry for my english.

There are only 10 channels defined in dm002 protocol:

num DM002_FLAGS {
// flags going to packet[9]
DM002_FLAG_FLIP = 0x01,
DM002_FLAG_LED = 0x02,
DM002_FLAG_MEDIUM = 0x04,
DM002_FLAG_HIGH = 0x08,
DM002_FLAG_RTH = 0x10,
DM002_FLAG_HEADLESS = 0x20,
DM002_FLAG_CAMERA1 = 0x40,
DM002_FLAG_CAMERA2 = 0x80,
};


// For code readability
enum {
CHANNEL1 = 0, // Aileron
CHANNEL2, // Elevator
CHANNEL3, // Throttle
CHANNEL4, // Rudder
CHANNEL5, // Leds
CHANNEL6, // Flip
CHANNEL7, // Camera 1
CHANNEL8, // Camera 2
CHANNEL9, // Headless
CHANNEL10, // RTH
};

#define CHANNEL_LED CHANNEL5
#define CHANNEL_FLIP CHANNEL6
#define CHANNEL_CAMERA1 CHANNEL7
#define CHANNEL_CAMERA2 CHANNEL8
#define CHANNEL_HEADLESS CHANNEL9
#define CHANNEL_RTH CHANNEL10

For devo's rate is always set to high:


// Features
packet[9] = DM002_FLAG_HIGH // high rate
| GET_FLAG(CHANNEL_FLIP, DM002_FLAG_FLIP)
| GET_FLAG_INV(CHANNEL_LED, DM002_FLAG_LED)
| GET_FLAG(CHANNEL_CAMERA1, DM002_FLAG_CAMERA1)
| GET_FLAG(CHANNEL_CAMERA2, DM002_FLAG_CAMERA2)
| GET_FLAG(CHANNEL_HEADLESS,DM002_FLAG_HEADLESS)
| GET_FLAG(CHANNEL_RTH, DM002_FLAG_RTH);

Use mixer on devo to set up rates if required.

Thanks!

Hey guys, i couldnt find a clear awnser, stock devo 7e, or do you need modules?

Thanks

Ian, I tried your recommended settings for removing the deadband but not having any success

Would you please share your model.ini file? Thanks

lani wrote: 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?