KN protocol adaption for Feilun helicopter?

Is here anyone working on a KN protocol, suitable for the Feilun helicopter FX 071C or FX 070C, fixed pitch, FBL, 6 axes_gyro_system?

www.feiluntoys.com/EN/feilun/product_lis...&class2_ID=&keyWord=

I was ask for help from some members of rcgroup.com who own these birds. But I am no coder, the only thing I can do is asking here in this community for an adaption, based on the existing KN protocol of the WL V977.

These helicopters seem to bind to the V977 TX, but with slow action on the swash plate.
A TX and a RX (board) will be shipped to work with.

Some photos. A better one of the TX will follow

i.imgur.com/2szinhh.jpg
static.rcgroups.net/forums/attachments/4...a6909168-216-PCB.jpg

Thanks guys for your attention.

If it does bind and can be flown by 977 TX then it is already compatible with Deviation KN protocol. The only thing needed is the appropriate setup of the model parameters. If you are certain that 977 and FX071C can exchange TX to fly, at least in 6G mode for 977.


977 is a micro heli which doesn't need a lot of throw like larger heli to make it goes fast. Also it is intended to be a stable, easy to fly, beginner friendly 6ch heli.

Hi Victor, I managed to bind my fx071/70 to the v977 tx. It don't bind on demand, it takes lots of attempts before it binds. When I first did it awhile back, I thought the swash was working different and assume the swash type needed changing. I did the binding again last night and observed it differently. What I observed was the servos moving at a much slower rate and was acting sticky during operation. The servos would stop or stick for a fraction of a second. On a full movement up to down - down to up it sticks about three times. The heli will fly with the v977 tx, but servos operated as describe above. The throttle curve seems different too, throttle hold switch works, 3d/3g switch works. So, not getting it to bind on demand and slower servo operation seems to be the glitches for me.

Ric...

Hi Ric, then it is time to solder. Get a NRF24L01+ from e.g.BG and give Deviation a chance.
www.banggood.com/DEVO-Transmitter-Tuner-...ys-V922-p-89812.html
The Devo was already planned, wasn`t it?

As Victor told, it only needs specific parameter to get the heli working.

Once I know devo 10 will bind on demand then its a go. Would the software need some code fix for the binding issue. Or do you think it should bind on demand with modules and software update. Still plan to get a devo 10 before year ends, so by then, someone with the fx and devo 10 might test it and confirm. When you say specific parameters, what parameters are you referring to? I guess you mean the rates, travel, and curves. I'm new to some of this, so some of my questions will show. I also video recorded servo movement from the stock tx and v977 tx and posted them here. www.rcgroups.com/forums/showpost.php?p=29658411&postcount=529

Thanks for the tx tuner link and it looks like two tuner being installed, but one in the package. What is the other tuner or module?

Ric...

These are examples. Forget about it, they are mixed without any comment. Especially the soldering for the A7105-D03 (FlySky)is not listed, only V911 tx modul.
What you need is a NRF24L01+ (Hisky)(with PA & LNA) which is shown above on
the mainpage.
Additionaly there is a CC2500 shown ( Skyartec).

Success.
www.rcgroups.com/forums/showthread.php?t...page=37#post29664958

sure looks like the modulation and channel setup matches, but if it hops on different frequencies, and there is some overlap, this will control it temporarily.
If the bind procedure will not do a two-way communication (likely not) then the receiver must have an algorithm or a look-up table to hop from. If they are completely different, no bind, some overlap = bind.
If it hops on three different frequencies and you happen to get overlap on one, which of course could roll to the other ones as time goes on, then you have control 33% of the time.

I too have successfully bound my FX071C RX with my devo 7e. As suggested above, there is room for improvement.

I have to put my NRF24F01 antenna within an inch to the FX071C antenna, then I can have them bound almost at will.

I guess my 7E is not listening correctly or it uses the wrong TX power at initialization, or background wifi signals somehow prevent the hopping.

My stock TX can bind a lot further away. Perhaps it listens/transmit better or it has more insight on hunting for the signals initially.

After binding, even though FX071C is a 4 channel FP, we still have to configure the model on 7E as 8 channel to make sure the flag bits mapped onto channel 5 to 8 are acceptable. In particular channel 6 maps to TH, channel 7 to idleup and channel 8 to auto-levelling. The 4CH with D/R template maps pitch (tied to throttle stick) to channel 6 by default. It would shut down both motors at half stick.

BTW, we haven't had a night build or hg update for a long time. Looking forward to some new code soon.

It did lose throttle once 5 feet from the TX once, cyclics remained OK. Had to rebind to get throttle working again. Hence it is not really reliable, more work required.

Moving this here from the RC Groups discussion...logic analyzer is on it's way to do the spi traces. I hope some of the experts have time to look at them, since it should only need minor modifications to the current nightly KN-protocol to make it work for the FX071 (and probably the other FX series copters). This is a conclusion of what we know so far:

Basically channels are mapped the same way as the V977:
CH1 THR
CH2 AIL
CH3 ELE
CH4 RUD
CH5 Dual Rate
CH6 Throttle Hold
CH8 3G/6G Gyro-mode

For me, binding works consistently with a Devo 7e and a fixed id of 12345, which means that the binding channel is definitely the same as in the V977. Different ID's give either incomplete binding or stuttering servo movement. This is most likely due to a different channel hopping pattern compared to the V977. Going through the sources (using my marginal C knowledge) I saw, that in deviation the FH channels are randomized from the (fixed) ID as well as a manufacturer ID of the microprocessor. This may be the reason why some people have had success so far while others, especially Devo10 Users, are still without success.

More updates as soon as the LA is running...

Getting the LA up and running was easy, so attached you will find the SPI traces after running them through format_spi.pl.

If someone needs the logicdata files, just drop me a note.

Although really a newbie to this coding stuff, I quickly put together a new protocol based on the current KN protocol including the patch from mcheli.blogspot.de/2015/02/wltoys-v977-kn-protocol-mod-v2.html .

So far it seems, the protocol is a little simpler but close to the v977 one, although it has some different timings. I guess the hopping channels are derived from the TXID sent during the binding process. How the channels are calculated I don't know yet, some more SPI traces will be necessary for that.

Anyone willing to be really experimental (I am not responsible for any damage to helicopters or mankind! can try the attached DFU vor devo7e or devo10 including the new protocol (called KNFX) and a basic model file. This build uses a permanently fixed ID and RF channels, so it is basically just to see if binding is consistent with different FX helicopters. Switch A1 controls the 3G/6G gyro, FMOD ist for the original FX-Dual rate. Feedback is welcome!

I will make a fork in the repository once I get the code cleaned up and documented.

@Moeder
...good luck!
..nearly took ten month to find someone to do this SPI snoop.
.

Thanks, now I have to wait for feedback from users, if this very basic protocol (fixed id fixed rf channels) actually works on other than my own helicopter.

BTW, sources are now available here
bitbucket.org/Moeder/knfx-protocol/branch/knfxsupport

Doing some more SPI traces I found out, that the ID on my TX is always the same, and so are the channels.
ID cd 35 00 00 is what the stock tx sends and then it hops between channels 2 and 34 (or 0x02 and 0x22)
I played with some different fixed ID's, these are the results:
ID 35 cd 00 00 -> binds and feels like the stock id
ID 00 cd 00 00 -> no bind
ID cd 00 00 00 -> no bind

I guess I'm stuck here, since I only have this one tx and rx combo available.

Also, I don't know if my protocol adaption is really correct concerning timings, but it works pretty well. Any of the experts is welcome to have a look at the traces (I will upload logicdata
tomorrow).

P.S.: I'm new to Mercurial and bitbucket, something went wrong, the module compiled from my repo doesn't work right now. I will find out later...

aMax wrote: @Moeder
...good luck!
..nearly took ten month to find someone to do this SPI snoop.
.

Many of us are electronic and software retards!

I guess developers always think simple...
After a little trial and error it seems the protocol just takes the sum of the 4 TXID values and then subtracts 256 to calculate the fist hopping channel. hopping channel 2 is hopping_channel_1 + 20
Working on the code, maybe this module is actually pretty close to finished

But I still need people trying out the firmware I posted above!

Flyingboats wrote:

aMax wrote: @Moeder
...good luck!
..nearly took ten month to find someone to do this SPI snoop.
.

Many of us are electronic and software retards!

I see,...was unaware of this.
Thought, give them a hand and push things forwards......, was really delighted when Craig finally got his LA....
Anyway, to cut the long story short, I will be happy if you guys are posting feedbacks on success now......and fine flying videos.

Ok, updated sources are available here:
bitbucket.org/Moeder/knfx-protocol/

Unfortunately, due to my very basic programming knowledge, I still have trouble getting the randomization of TXID bug free. I hope some of the deviation experts can help me here to finish the protocol. Problem lies in
bitbucket.org/Moeder/knfx-protocol/src/7...l01.c?at=knfxsupport
function kn_calculate_tx_addr
The current version doesn't give a bind with several Fixed IDs setup in the model config, for example 123451 gives a perfect bind, while 12345 doesn't. What am I doing wrong?

Edit:
Some further testing:
12340 bind
12341 bind
12342 bind
12343 bind
12344 bind
12345 no bind
12346 bind