JJRC H26D

Hi,

Here are the SPI capture for the new JJRC H26D.

mon-partage.fr/f/7ynIDjiO/

- Controls are taken in expert/100% mode

This quad have:
-Headless
-RTH
-Flips
-Photo
-Camera
-2-axis gimbal control (pan & tilt)

Please try binding with MJXQ protocol WLH08 option. Bind address and packet size is the same. Let's see how far that gets us before digging in deeper.

hexfet wrote: Please try binding with MJXQ protocol WLH08 option. Bind address and packet size is the same. Let's see how far that gets us before digging in deeper.

Well I tried first all XN297 protocols ... and even the MJXq/WLH08 is not working (no binding)

The RF channels are different

I've uploaded at test build titled H26D. It has a protocol option under MJXQ. Please give that a try. Unfortunately this build no longer fits in the 7e...

hexfet wrote: The RF channels are different

I've uploaded at test build titled H26D. It has a protocol option under MJXQ. Please give that a try. Unfortunately this build no longer fits in the 7e...

Harg I got only my Devo 7E on hands actually ....

Ok I found my Devo10 ... but it doesn't bind

I'll have to look in greater detail. Might take a few days.

hexfet wrote: I'll have to look in greater detail. Might take a few days.

No problem ... I can capture anything you need in case

One more quick try. I updated the test build to force the txid to the same value in your capture.

It would be helpful if you could export the existing captures to csv

hexfet wrote: One more quick try. I updated the test build to force the txid to the same value in your capture.

It would be helpful if you could export the existing captures to csv

Not working too

Missed the forest for the trees It's a Beken chip, not XN297. Test build is updated.

hexfet wrote: Missed the forest for the trees It's a Beken chip, not XN297. Test build is updated.

Now it's binding ... Ok I will check all associated channels now

Ok ... so what I managed to test

Lights ok


Flips probably yes (I can't test too windy))

photo ok

camera ok

Headless ok

Can the gimbal controls be added to last channels ?


headless ok

The pan/tilt is implemented with a series of bit transitions. Need a little time to figure out the best implementation.

How about RTH? It looks like there's a capture for an altitude hold function too. We're about out of channels.

hexfet wrote: The pan/tilt is implemented with a series of bit transitions. Need a little time to figure out the best implementation.

How about RTH? It looks like there's a capture for an altitude hold function too. We're about out of channels.

I will make some deeper testing.
Can you list me associated channel number with corresponding features ? to be sure ?


For your combo ... maybe it's time to give up some very unpopular protools ? (CFLY ?)

I've implemented the pan/tilt controls. Took a stab at making them proportional but don't know if the quad will respond appropriately. A channel value of 50 should give about the same gimbal rate as stock. At the low end should be twice as slow. At the high end the bits toggle every packet - no telling if the gimbal will keep up. If it works at all please judge the desirability of proportional control - it's messy and requires a good bit of code.

I also changed the txid code to add the fixed id to your stock tx value. Setting the fixed id to zero will give same txid as the previous version. Please try with a non-zero value and see if it binds. If it doesn't we've got the txid<-->rf channel mapping to figure out.

Here's the channel assignments. If the H26D does not have LED control we could use channel 5 for altitude hold.

hexfet wrote: I've implemented the pan/tilt controls. Took a stab at making them proportional but don't know if the quad will respond appropriately. A channel value of 50 should give about the same gimbal rate as stock. At the low end should be twice as slow. At the high end the bits toggle every packet - no telling if the gimbal will keep up. If it works at all please judge the desirability of proportional control - it's messy and requires a good bit of code.

I also changed the txid code to add the fixed id to your stock tx value. Setting the fixed id to zero will give same txid as the previous version. Please try with a non-zero value and see if it binds. If it doesn't we've got the txid<-->rf channel mapping to figure out.

Here's the channel assignments. If the H26D does not have LED control we could use channel 5 for altitude hold.

#define CHANNEL_LED         CHANNEL5
#define CHANNEL_FLIP        CHANNEL6
#define CHANNEL_PICTURE     CHANNEL7
#define CHANNEL_VIDEO       CHANNEL8
#define CHANNEL_HEADLESS    CHANNEL9
#define CHANNEL_RTH         CHANNEL10
#define CHANNEL_AUTOFLIP    CHANNEL11  // X800, X600
#define CHANNEL_PAN         CHANNEL11  // H26D
#define CHANNEL_TILT        CHANNEL12

Some good news: Gimbal controls works (I associated them with AUX4&5)
Even if the light controls is not present with the original radio, it's working here ... so basically we would need 13 channels !!! to add the the "pseudo altitude hold/height" for the 13th ...

I bound with ID = 1111 w/o problem

That is good news Does the speed of the gimbal increase with larger channel values? If so, at what value does it reach maximum speed?

We could add a protocol option to swap functions of one of the channels. Probably exchange either LED or flip control with altitude hold.

Also good news on the ID. Thanks for testing!

hexfet wrote: That is good news Does the speed of the gimbal increase with larger channel values? If so, at what value does it reach maximum speed?

We could add a protocol option to swap functions of one of the channels. Probably exchange either LED or flip control with altitude hold.

Also good news on the ID. Thanks for testing!

Well ... to be honest, there is a small variation is speed around the central pot values. In practice, you have to be very precise to "stop" spinning... so probably the dynamic should be adapted when used with pots..... I should try with some trim buttons too... it can be a different storry.

What's a pity the HexFet devo7E combo is full for this protocol .... I was planning to use my Devo7E... Definitively, we are reaching the memory limits now.
We should do Force walkera to deliver 7E with a 256Ko chip

Out of topic... I will also capture the JJRC X1 spi data asap

There's no info in the altitude hold or flip captures - just the bind sequence followed by unchanging data. Need to get the altitude hold info.

I've updated the test build with the following changes. Please check and let me know.

The gimbal code is changed to just use the fixed rate same as the stock tx. If the channel is outside +/-50 the gimbal will move, otherwise it will not. See if this is easier to work with than the previous version.

The txid code is changed to same as the x800 (basically ignored). Should still work.

I was able to build a 7e version with gcc 4.8.4 Cannot build the 7e with 4.9.3 due to space.