Adding Kyosho KT-17 support (not FHSS/Hype)

[steff-wink]

Hello @pascallanger, as shortly commented in #379 I got an old Kyosho Minium Edge 540 plane that has a KT-17 remote that does not bind with either Kyosho FHSS or Hype, the Protokoll seems to be older. As in the old Kyosho issue done, I prepared several dumps of the SPI interface. Only CLK, MOSI and MISO are used, SS is not connected to TX modul. The TX module is a NRF24L01. I prepared dumps for Binding and Channels 1-3 in the negativ 100 position and positiv 100 position, as the stick direction would be shown in OpenTX. I also included Ch4, which is noch implemented in the plane, and also stick centered dump. The dumps are made with 24Mhz resolution. I shortly looked into the code if I could fix something together, but I see that my programming skills are not enought on this hardware level. I found at least 2 other users that where searching to bind their OpenTX remote to these kind of models. I will gladly buy you another coffee :) Kyosho KT-17.zip

[pascallanger]

It's kinid of strange that CSN is not connected... That would be ok for CE but CSN... Anyway, I need to change my parser so it can use the data format without CSN. Give me some time. I'll come back to you if I need anything else.

[madbananagit]

Hey @pascallanger

Just wondering if you have been able to make any progress with this please - I too have a Kyosho KT-17 transmitter and would really to be able to control the plane via. a multi-module transmitter.

Thanks in advance for your fantastic support!

[pascallanger]

Sorry I dropped the ball. Are you still interrested?

[madbananagit]

Absolutely no problem at all! Thank you for taking the time to respond. Yes, I am still interested. I would really like to get my Koyosho Minium Citabria which binds ok to a KT-17 working with my Jumper T16 with internal multimodule. I believe the protocol to be identical to the Kyosho Minium Edge 540 at the start of this thread. Many thanks for your support. Michael

[steff-wink]

Still interested as well, although I'm on vacation for the next 3 weeks, so I can't test or provide any other data logs of the bind process. I'll be back in August and could try again then. No problem on dropping the ball, as I understand this is a spare time project, so all request are no more than wishes on my side ;)

[pascallanger]

I'll give it a go early next week. @madbananagit will you be able to test? @steff-wink Let me work with what you've dumped so far.

[madbananagit]

Of course, as long as you give me some direction please! Thank you so much for your support.

[pascallanger]

Bind The bind is done on address: 69 53 10 AC EF RF Channel: 0x50 Bitrate: 1Mb CRC: 2 bytes Period: 1600µs, duration 20sec Payload: 28 bytes!!!!! 01	02	05	08	1A	2B	3C	4D	0A	BD	31	DF	00	00	00	00	00	00	00	00	00	00	00	00	00	00	00	00
??	??	??	??	??	??	??	??	A0	A1	A2	A3	A4?	A5?	-	-	-	-	-	-	-	-	-	-	-	-	-	-

The TX is then looking at the following channels to see if it's busy or something is sending data: 13, 4A, 14, 4F, 15, 2E, 16, 33, 17, 38,18, 3D, 19, 42, 1A, 47, 1B, 4C, 1C, 2B, 1D, 30, 1E, 35, 1F, 3A, 20, 3F, 21, 44. I think this is the frequency table that the RX is also using. How to calculate this specific frequency table?

• The frequencies work in pairs like seen in normal mode.
• The first frequency 13 increments by 01 on every iteration.
• The second frequency starts with 4A, the next value is if(4A+05<50) then f=4A+05 else f=4A-21=> f=4F, and you repeat: if(4F+05<50) then f=4F+05 else f=4F-21 => f=2E and so on.

I think this table is built from the information given on the first unknown bytes of the payload but I have no idea how... I assume that we can keep them constant which will give the same frequency table, at least I hope otherwise if the ID is included in the calculation I don't know how to reverse it without dumping the RX side.

[pascallanger]

Normal Address: 69 53 10 AC EF RF Channels: 13,13,4A,4A and repeat Bitrate: 1Mb CRC: 2 bytes Period: 1120µs Payload: 28 bytes!!!!!

Payload description: 0A	BD	31	DF	00	00	13	4A	01	A4	03	2D	01	EF	02	16	00	00	00	00	00	00	00	00	00	00	00	00
A0	A1	A2	A3	A4?	A5?	RF_CH1	RF_CH2	CH3_H	CH3_L	CH1_H	CH1_L	CH2_H	CH2_L	CH4_H	CH4_L	-	-	-	-	-	-	-	-	-	-	-	-

CH1 0x032D=-100% CH1 0x0003=+100% CH1 has an offset of 03 which I think is the trim or just that the sticks are not accurate...

CH2 0x005C=-100% 01 A4 01 9E 00 5C 02 15 CH2 0x0383=+100% 01 A3 01 9E 03 83 02 17 CH2 is reversed compared to CH1 and has an offset of 5C which I think is the trim or just that the sticks are not accurate...

CH3 0x0017=-100% CH3 0x0333=+100% CH3 is reversed compared to CH1 and has an offset of 17 which I think is the trim or just that the sticks are not accurate...

CH4 0x03AB=-100% CH4 0x0083=+100% CH4 is the same as CH1 and has an offset of 83 which I think is the trim or just that the sticks are not accurate...

This protocol has been designed to send a total of 10 channels but only 4 are in use here.

From a second dump, the center is between 01FF and 0203. So I think the TX is in fact coding the sticks position on 1024 ie 0000...01FF...3FF. The previous stick values looks ok if we consider that the trims can shift the center value in one or the other direction without clamping but we don't care for Multi.

[pascallanger]

I'm going back to the bind since I must have over looked something. There are 5 different phases in the bind dump. I think I messed up on my previous statement about the bind since I might have taken the 5th phase which is then normal mode. Ok I stop here, it's 2:45am... Time to go to sleep.

[pascallanger]

I can't stop... Phase 1: read status register=0x0E->nothing, write status register 0x2E->clear data sent=>it is already at 0 and anyway nothing has been sent yet. So Phase 1 does nothing... Phase 2: Switch to RX mode on address 69 53 10 AC EF & RF ch 13, then read if a carrier has been detected -> no. It has not received anything so it goes to phase 3. Phase 3: read status register=0x0E->nothing, write status register 0x0E->nothing So Phase 3 does nothing... Phase 4: Switch to RX mode on address 69 53 10 AC EF & RF ch 4A, then read if a carrier has been detected -> no. It has not received anything so it goes to phase 5. Phase 5: normal mode packets

So basically, it checks if another transmitter is already sending on channels 13 and 4A, if nothing is received then it switches to TX.

2 solutions:

• the RX when in bind mode sends something to the TX but the RX was not on during this dump so I don't see the data exchange
• the RX does not require the TX to be in bind mode, it attaches with the first TX nearby like what's being done in Futaba/SFHSS

Without knowing how the bind works for the KT-17 TX/RX I can't progress anymore...

It's now 3:10am, going to sleep.

Pascal

[steff-wink]

I'm flying out on Sunday, I'll try to get another dump Saturday evening. The scan was quite some time ago, although I'm pretty confident I did a complete bind and not just a reconnect I'll do it again, "tomorrow". I'll also check again if any trim was set, which I also think I checked back then. There is no process on the RX to set it into Bind-Mode you just switch it on. So it might just be, if RX started up and old TX is not present and there is a TX in bind mode, then the RX will connect to the new TX. Very interesting to live view the analyse process!

[madbananagit]

Wow @pascallanger, this is above and beyond - thank you!

Apologies I can't provide any dumps - I don't have the equipment.

[pascallanger]

This is the manual, correct? http://www.kyosho.com/jpn/support/instructionmanual/minium/pdf/10655_Edge_540_m.pdf Bind procedure is described on page 8.

[madbananagit]

10652-Minium-Citabria-m.pdf

@pascallanger yes - the one linked above is the 540, the Citabria should be attached, I believe they both work in the same way.

[pascallanger]

Ok the bind is on the same page 8 with the same method. @steff-wink Can you follow exactly the process and do a dump? Make sure to record before the radio is even powered. Also pay attention to the receiver in the plane, there should be a LED on which the pattern should change during the different phases. If you could detail what's happening that would be great.

[pascallanger]

From the doc, you power on the plane and wait long enough so that it goes in bind mode -> look at the LED on the RX it should show this transition. Then you power on the TX while pushing on the stick, from the description the TX sends some bind packets (which I don't have in the bind dump) then switch to listen for the RX confirmation (this is in the bind dump but there was no reply from the RX) to stop the bind process and then switch to normal mode (this is in the bind dump). So the impression I have is that the RX was not (yet?) in bind mode when you have taken the dump and you might have recorded after powering on the TX therefore missing the first part of the bind.

[steff-wink]

Good evening fellas, Kyosho KT-17_Bind.zip ok Pascal all your assumptions where right. I did not do a full bind last time, this time it looked definitly different, and the sticks where not centered Attached is a new dump, which runs a full 33 seconds. (16Mhz resolution):

• TX Switch-on in bind-mode at 1,2s (TX starts beeping)
• RX Switch-on at around 3s
• RX starts beeping an bind process is starting.
• TX ends bind-mode after 20s at 21,5s
• RX continues beeping and ends bind mode after 30,3s the last two events correlate with clear points in the scan

I hope you can also see the stick position in last part and check if the trim is gone. Sry I don't have time to do a full nicely formated dump with all stick positions again, I hope this one helps I'll also attach a picture of the binding page from the manual

Now I'm off to vacation and will not have access to github over the next 3 weeks

[madbananagit]

Thank you @steff-wink, have a great break!

[pascallanger]

I have all the information needed to write the code. Check these 2 posts for all the details: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/issues/658#issuecomment-1179436461 and https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/issues/658#issuecomment-1179444149 .

[madbananagit]

Thank you!!

[pascallanger]

Are you able to compile the code by yourself? If yes the protocol Kyosho2/KT-17 is available on master using @steff-wink ID for now. If not then you'll have to wait since I don't really know what to do because it doesn't fit anymore in flash for some modules when all the protocols are selected...

[benlye]

Are you able to compile the code by yourself? If yes the protocol Kyosho2/KT-17 is available on master using @steff-wink ID for now. If not then you'll have to wait since I don't really know what to do because it doesn't fit anymore in flash for some modules when all the protocols are selected...

Time to look more closely at #538? I do all my firmware builds with the devel board and gcc-8.3.1, but have no real flight time with them. The devel board compiles the current master at 98%. I know it's still tight, but it gets it in (for now).

arduino-cli compile -b multi4in1-devel:STM32F1:multistm32f103cb:debug_option=none /mnt/c/Users/blye/GitHub/DIY-Multiprotocol-TX-Module/Multiprotocol/Multiprotocol.ino --output-dir /tmp/build/
Sketch uses 119304 bytes (98%) of program storage space. Maximum is 120808 bytes.
Global variables use 4456 bytes (21%) of dynamic memory, leaving 16024 bytes for local variables. Maximum is 20480 bytes.

Long-term, we still need to come up with a way to make it really easy for users to access custom firmware builds with just the protocols they need. I'm going to have to think about that some more.

[pascallanger]

Hi Ben, I was going to contact you exactly for this😁 i haven't used your latest version. I'm thinking the link to the board is in the thread you mentioned. I'll use it to fly this weekend most of my models. If I don't notice an issue, I think we will be ok. Would you be able to get the test versions using it? Like this we can ask people to test it too, what do you think?

[benlye]

Would you be able to get the test versions using it? Like this we can ask people to test it too, what do you think?

I'll see if we can. We might have to separate the build procedures or create a secondary one, but I'll figure something out :+1:

[madbananagit]

Are you able to compile the code by yourself?

There's a first time for everything and I believe I've achieved that! The new protocol appears in the menu ok - however it fails to bind. It appears that it isn't going through the initial bind process (i.e. the equivalent of pushing the LH stick down when powering on the KT-17 TX). The red LED on the RX continues to flash and it bleeps. I noticed that after trying to bind with the multi-module, the KT17 binds immediately on power on - without the need to push down the LH stick.

Is there a specific way to force this initial bind from the multi-module?

Thank you so much for getting to this point.

[pascallanger]

Let me ask a stupid question: have you pressed the bind button on the GUI while the plane was in bind mode?

[madbananagit]

Let me ask a stupid question: have you pressed the bind button on the GUI while the plane was in bind mode?

Nothing is a stupid question!

To give you the complete picture so as avoid any doubt, I'm running a Jumper T16 Pro with OpenTX. I've compiled the code from master and flashed the internal 4 in 1. I've selected Koyosho2 --> KT-17 protocol. I then power on the RX, then select Bind on the TX screen. The TX shows 'Binding' but the RX continues to beep / flash LED. I've tried different sequences with powering on TX & RX etc.

[pascallanger]

Ok let me check.

[mamaretti]

Hi. i tested ist with a Kyosho Cessna an a Radiomaster Zorro. First, I tested a lot and it doesn't work. but now it works! But the Blind-Process of the Tx is to short. After pressing the Bind-button on the TX-screen, the TX Binding-Beeps are only 1-2 seconds. I could bind, within the 1-2 Seconds. So pressing Bind-button and shortly after power the RX.

@pascallanger. thx a lot! know, my girlfriend have a new plane! :)

[pascallanger]

Ok that's a good news. I can increase the bind time, not an issue at all. Is everything else working as it should? Like channels order, and directions? I think I only have implemented one ID so far (only one plane can be down at the time...). Will you be able to test if I enable more IDs?

[pascallanger]

@mamaretti @madbananagit @steff-wink Could you test the latest build here: https://downloads.multi-module.org/latest-test/ Since there is only 1 ID for now you need to bind with the original radio <-> multi to verify that the bind works as it should and the control. Once I have your feedback I can look into trying different IDs.

[madbananagit]

Setup and controls appear to be working perfectly with a Citabria on a Jumper T16. Bind is immediate whereas before I didn't manage to bind once in many tries.

So thank you very much @pascallanger, it will be great to be able to fly this model with a decent TX!

[mamaretti]

@pascallanger i only needed to to flip the rudder. throttle seams to work at the middle of stick position. probably there is a way to calibrate the esc.

[pascallanger]

@mamaretti ok let me look at throttle, that might be me... And I'll switch rudder direction.

[mamaretti]

the KT-17 throttle stick is always centered via spring. (Like elevator). so it seams to be correct that throttle will work at center.

[pascallanger]

Then what happens when you move it down ?

[madbananagit]

@pascallanger, the KT-17 TX with the center-biassed throttle stick only outputs from mid-position upwards, pulling it down has no effect. Whilst this sounds a bit strange, the TX is switchable between mode 1 & 2 so both sticks have centre-bias.

In OpenTX, the motor responds only from 0 to 100% (1500us to 2012us) and not -100 to +100%, therefore at just above mid-stick the motor starts up. Below mid-stick, there's no impact on the motor. This mimics the KT-17 correctly, but ideally I guess would operate the motor over the full stick deflection.

I'm yet to test-fly, but I'm really happy that it works as it does!

[pascallanger]

Ok, I will leave everything as it is for the channels as you can use OpenTX to do all these little adjustments. Can someone compile and test the firmware with #define FORCE_KYOSHO2_ID (Kyosho2_nrf24l01.ino line 29) commented out?

[steff-wink]

Hi @pascallanger, I see some activity here since you integrated the new protocol into the main build. After a long long time I finally found the time to test it out. Works perfectly on my end, bind process was a breeze -> first power on the plane, then press the bind button on the TX. Now I can finally throw that KT-17 away (broken apart anyway from the dump ;) ) I had to reconfigure some channels, but that might just be the firmware update on my end.

@mamaretti you could configure the channel 1 output on the TX. I have the subtrim set to 50, min at 0 (orig. -100) and max at +100 this pulls the "center" output to the bottom of the stick and you have the full stick path for throttle

@pascallanger thx a lot for your efforts, I think I promised a coffee on another Kyosho issue shortly before I started this topic, so your next coffee is on me ;)

From my perspective this issue is closed (apart from the single ID issue, which is no problem for me)

[pascallanger]

@steff-wink thanks for the coffee ;-) Are you able to recompile the code with #define FORCE_KYOSHO2_ID (Kyosho2_nrf24l01.ino line 29) commented out? @mamaretti and @madbananagit if you don't use your old original TX, consider to send it my way so I can add your IDs. I just need the PCB, feel free to remove all the plastic bits so it fits in an envelop and will be cheap to send.

[mamaretti]

hi @pascallanger

I can send the TX to you. I found 4 TX, one of them is definitly damaged. the other 3 should work.

[mamaretti]

@pascallanger : where I can send it?

[pascallanger]

@mamaretti Contact me : pascal _ langer @ yahoo . fr

[dakhnod]

Does this work for the EU aswell?

[dakhnod]

Also, wenn I turn on my plane it just constantly beeps. It's not a beep beep beep, but rather a constant beeeeeeeeeeeeee...

Can anyone confirm this is normal?

[mamaretti]

you have to turn on the TX first. then press "bind" on the TX. immediately after that connect battery to plane.

like here https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/issues/658#issuecomment-1179608867

[twoz12]

just checked the protocol on different AETR radios and the channels are a bit mixed up. A->T; E->R; T->E and the direction of rudder is going in the opposite direction. Correct channel order for AETR: 4312 Apart from that; binding, control works on a Kyosho Cessna 210.

[pascallanger]

@twoz12 the others in the thread have not reported this channel issue. Could it be that your plane is different ?

[twoz12]

It's possible, but the Kyosho Perfex KT-17 (from the set) has no option to change channels or directions. This would mean Kyosho selling KT-17 radios with different channel orders and directions.

Kyosho Minium CESSNA 210 Centurion RTF set