Closed saimat closed 4 years ago
@goebish is the Q90C protocol working? Can I simply port it or there is still work to be done? Thanks, Pascal
I see that goebish was asking for more dumps. @saimat Do you have an external module to do XN297 dumps?
iirc I couldn't get it to work reliably, lots of dropouts, a bit like emulating 250kbps xn297 with nrf24l01, except I was using the cc2500 and tuned frequency and deviation with SDR to be the same than stock TX.
here's a dump (no timings ...): https://gist.github.com/goebish/afa73c94069ee85849af274d8c885716
@saimat I've just pushed on master the version 1.3.1.3 including the Q90C protocol. You need to compile the code, test and report.
@pascallanger: Wow, I didn't expect such a quick reaction, thank you!! I will try to compile and give you a feedback.
@saimat Note that you should (nearly must) change the RF frequency (OpenTX GUI) to at least 1 (instead of 0) to use the CC2500 instead of the NRF to emulate the XN297 at 250K.
@pascallanger I compiled the version 1.3.1.3 and tried to bind with the Q90C Protokoll. Not luck so far, tried RF frequency 1 and 0.
Just found out that goebish's checksum code does not match the dump... It only matches a small part of the checks. I'm currently figuring it out.
Ah, that's probably the issue I had ... but at least it was able to bind and somewhat control it if I remember correctly. Unfortunately I do not have this machine anymore.
You might have been able to bind once but not with the current code since the checksum is wrong on the bind packet when using the fixed ID. Anyway, I've just published the corrected version v1.3.1.3 which match the checksum of the dump for bind and normal packets. The issue is for bind packets since I have only one dump I can only assume what it can be. But let's see if it already binds and control with the current fixed id. @goebish You haven't coded the flags, any dump or anything you have where we could get the information from? @saimat Can you test and report?
I've no dumps with flags (I remember they're a bit weird since it works with an old hacked cleanflight or betaflight version). Perhaps I can get the machine again to make extra dumps but that won't be before one or two weeks.
@saimat you haven't responded if you have an internal or external module on your T16. If it's an external we can dump easily the packets sent by your original TX. If it's internal it's a little more challenging since you need a FTDI and cable to connect to the internal module. It's on my todo list to be able to send the information and display it on the radio but not for now...
@pascallanger I have the Jumper T16 Pro V2 with internal module :( The binding works now with your latest update and Channels 1-4 are working. Arming (Stick arming with roll left) works also. Only weird thing is, that the Jumper TX Beeps and Vibrates everytime I move the pitch (channel 2).
What I also don't understand is how they change the flight modes. On the original TX there are 3 buttons (angel,horizon,acro) but in betaflight there are no aux channels visible. As @goebish mentioned this model is really weird. It runs with betaflight but you cannot change any settings. If you do the model freaks out and flips over...
The binding works now with your latest update and Channels 1-4 are working. Arming (Stick arming with roll left) works also.
Great news. Do you have to reverse any channel?
Only weird thing is, that the Jumper TX Beeps and Vibrates everytime I move the pitch (channel 2).
This is not a Multi thing but a config on the model on your side. You might have checked beep on center by mistake on the 1st page.
What I also don't understand is how they change the flight modes. On the original TX there are 3 buttons (angel,horizon,acro) but in betaflight there are no aux channels visible.
It's not possible for now. I need a dump with someone pushing the 3 pos and VTX button to understand how they are done.
Can you do a test, open the file Q90C_nrf24l01.ino, change the line:
#define FORCE_Q90C_ORIGINAL_ID
to: //#define FORCE_Q90C_ORIGINAL_ID
Try to bind and see if it still works.
@saimat please see above. Also please confirm that you really don't have the USB to serial adapter which would enable you to do a dump.
@pascallanger sorry don't have a USB to serial adapter but I could buy one.
Do you have to reverse any channel?
Yes, channel 1 (roll) and channel 4 (yaw)
This is not a Multi thing but a config on the model on your side. You might have checked beep on center by mistake on the 1st page.
You are so right, thanks for that hint! :-)
With //#define FORCE_Q90C_ORIGINAL_ID
I'm not able to bind anymore.
@pascallanger sorry don't have a USB to serial adapter but I could buy one.
@saitmat This would be mandatory if goebish can't get hold of the original TX... FYI, this is a $5 item and good to have in your back pocket.
Yes, channel 1 (roll) and channel 4 (yaw)
Both inverted in v1.3.1.5 .
With
//#define FORCE_Q90C_ORIGINAL_ID
I'm not able to bind anymore.
Could be my mistake... Please try again with v1.3.1.5 . If that doesn't work then we really need a dump from one or more TXs...
@pascallanger Did you commit the change already?
@saimat sorry forgot to push the button...
Depending on the last test, I might try something else. The checksum of the normal packets is the sum of the bytes in the packet xor 0xA4. And interstingly enough, if you xor the first 4 bytes of the ID you get 0xA4. That's worse a try. @saimat when you bind the model with the #define commented, I know it doesn't work but are the LEDs on the Q90C doing anything different before and after the bind?
@saimat any news?
@pascallanger Today I found the time to test. The inverted channels are working great.
No binding with #define FORCE_Q90C_ORIGINAL_ID
and no light changes.
With //#define FORCE_Q90C_ORIGINAL_ID
everything is fine.
I'm thinking your comment is reversed isn't it? it works when you have #define FORCE_Q90C_ORIGINAL_ID. Can you confirm? We really need to dump your original TX to find out how the ID and extra features are working. Have you purchased a cheap USB to serial adapter and the cable?
Oh, yes its reversed.
No binding with //#define FORCE_Q90C_ORIGINAL_ID
and no light changes.
With #define FORCE_Q90C_ORIGINAL_ID
everything is fine.
Don't know what adapter I need for dumping, is it that one mentioned on the compiling wiki ? https://www.ebay.co.uk/itm/FTDI-USB-to-TTL-Serial-Converter-Adapter-FT232RL-Module-5V-and-3-3V-Arduino-ARM/231918152528
A logic analyzer is required, search for "8ch logic analyzer" on ebay, it costs around $6 usd. ... and get prepared for some soldering ;)
A logic analyzer is required, search for "8ch logic analyzer" on ebay, it costs around $6 usd. ... and get prepared for some soldering ;)
We can use the XN297dump here so a USB to serial adapter with cable is perfect in my opinion, no soldering required.
Oh, yes its reversed. No binding with
//#define FORCE_Q90C_ORIGINAL_ID
and no light changes. With#define FORCE_Q90C_ORIGINAL_ID
everything is fine.Don't know what adapter I need for dumping, is it that one mentioned on the compiling wiki ? https://www.ebay.co.uk/itm/FTDI-USB-to-TTL-Serial-Converter-Adapter-FT232RL-Module-5V-and-3-3V-Arduino-ARM/231918152528
Looks good and you need this: https://www.ebay.co.uk/itm/5-PAIRS-5-PIN-Micro-JST-GH-1-25-Connector-Plug-Socket-1-25mm-150mm-Cable/273110735668
Oh sorry, I thought he wanted to directly dump the xn297 spi bus inside the stock transmitter since he has no external multi module ... but yes it can be done with a ftdi soldered (or plugged if he has the right connector) to the internal module
Both would work I agree. @saimat your choice.
FTDI has been ordered and should arrive at the end of next week.
Hi @pascallanger the FTDI has arrived. Is there somewhere a dokumentation how to do the dump?
Use the auto mode
@pascallanger I can not compile with Debug "Serial/FTDI":
c:/users/aw18380/appdata/local/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: C:\Users\aw18380\AppData\Local\Temp\arduino_build_234947/Multiprotocol.ino.elf section .rodata' will not fit in region rom
c:/users/aw18380/appdata/local/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: region rom overflowed by 8288 bytes
collect2.exe: error: ld returned 1 exit status
exit status 1
Fehler beim Kompilieren für das Board Multi 4-in-1 (STM32F103CB).
As pointed in the doc you need to comment a number of protocols for the code to compile with debug enabled
@pascallanger This is what I get in the serial monitor:
,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84
XN297 dump, address length=5, bitrate=1M
Trying RF channel: 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84
XN297 dump, address length=5, bitrate=2M
Trying RF channel: 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84
XN297 dump, address length=5, bitrate=250K
Trying RF channel: 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36
Packet detected: bitrate=250K C=36 Enhanced pid=1 S=Y A= 4C 0A 02 01 4B P(2)= 00 FF
--------------------------------
Identifying all RF channels in use.
Trying RF channel: 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36
RX on channel: 36, Time: 0us P: 00 FF
RX on channel: 36, Time: 18975us P: 00 FF
RX on channel: 36, Time: 18977us P: 00 FF
RX on channel: 36, Time: 18921us P: 00 FF
RX on channel: 36, Time: 18978us P: 00 FF
RX on channel: 36, Time: 18982us P: 00 FF
Trying RF channel: ,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84
1 RF channels identified: 36
--------------------------------
Identifying RF channels order.
Time between CH:36 and CH:0
Channel order:
36: 0us
--------------------------------
Identifying Sticks and features.
Strange output... Are you sure the Q90C remote was on before launching? Can you run it multiple times to see if you get the same result?
Tried it a lot of times now... On most runs it just finds nothing, on other runs only one channel. At least there are a few runs where mostly channel 23,36,53 were found. But I also had outputs with channel 33 and 54?!? Here are some saved outputs: https://github.com/saimat/q90c_dump
@saimat This is far better:
Packet detected: bitrate=250K C=23 Enhanced pid=2 S=Y A= 4C 0A 02 01 4B P(12)= 00 77 81 85 1E 1E 1E 1E 00 00 01 B3
3 RF channels identified: 23 36 54
--------------------------------
Channel order:
23: 0us
36: 6200us
54: 12440us
Strangely the packet period is not the one we are using today... Anyway, you need to do 2 things:
Ok from the above, it confirms that the xor key from the normal packets is the xor of the first 4 bytes of the ID (0xA4 for Goebish's TX, 0x45 for saimat's TX).
@saimat please test if you can bind and control your model using the new version on master. This version is using the module's ID and not from the dump(s).
Thats the bind output on channel 51:
XN297 dump, address length=5, bitrate=250K
Protocol selected: 63, sub proto 0, rxnum 0, option 51
Proto=XN297DP, nbr_sub=4, Sub=250Kbps, Opt=8
Channel=0,0x00
Channel=51,0x33
RX: 0us C=51 Bad CRC
RX: 47444582us C=51 Enhanced pid=1 S=Y A= 4F 43 54 81 81 P(0)=
RX: 6423us C=51 Enhanced pid=2 S=Y A= 4F 43 54 81 81 P(0)=
RX: 71116us C=51 Enhanced pid=0 S=Y A= 4F 43 54 81 81 P(0)=
RX: 6485us C=51 Enhanced pid=1 S=Y A= 4F 43 54 81 81 P(0)=
RX: 6197515us C=51 Bad CRC
Next I will try your new version on master. I own two of this stupid TX, so if it helps I can also do a dump with the other one.
The bind dump is not good there are no data... But try first master, if it works then we don't need bind data.
No bind possible with the latest master :(
@saimat ok then you need to dump good bind packets
@pascallanger Does that looks better?
XN297 dump, address length=5, bitrate=250K
Protocol selected: 63, sub proto 0, rxnum 0, option 51
Proto=XN297DP, nbr_sub=4, Sub=250Kbps, Opt=8
Channel=51,0x33
RX: 0us C=51 Enhanced pid=0 S=Y A= 4F 43 54 81 81 P(12)= 4C 0A 02 01 17 24 36 2E 00 00 4B 4E
RX: 478290us C=51 Enhanced pid=3 S=Y A= 4F 43 54 81 81 P(12)= 4C 0A 02 01 17 24 36 2E 00 00 4B 4E
RX: 2363921us C=51 Bad CRC
Another one:
XN297 dump, address length=5, bitrate=250K
Protocol selected: 63, sub proto 0, rxnum 0, option 51
Proto=XN297DP, nbr_sub=4, Sub=250Kbps, Opt=8
Channel=51,0x33
RX: 0us C=51 Enhanced pid=1 S=Y A= 4F 43 54 81 81 P(0)=
RX: 6412us C=51 Enhanced pid=2 S=Y A= 4F 43 54 81 81 P(0)=
RX: 101627us C=51 Enhanced pid=2 S=Y A= 4F 43 54 81 81 P(12)= 4C 0A 02 01 17 24 36 2E 00 00 4B 4E
RX: 1504718us C=51 Enhanced pid=3 S=Y A= 4C 0A 02 01 4B P(12)= 00 77 81 85 1E 1E 1E 1E 00 00 E7 99
RX: 37868us C=51 Bad CRC
RX: 300093061us C=51 Enhanced pid=0 S=Y A= 4C 0A 02 01 4B P(12)= 00 77 81 85 1E 1E 1E 1E 00 00 F0 A0
RX: 113749us C=51 Enhanced pid=2 S=Y A= 4C 0A 02 01 4B P(12)= 00 77 81 85 1E 1E 1E 1E 00 00 02 B2
RX: 56923us C=51 Enhanced pid=3 S=Y A= 4C 0A 02 01 4B P(12)= 00 77 81 85 1E 1E 1E 1E 00 00 0B 45
RX: 18934us C=51 S=N A= C9 E0 49 B0 A8 P(17)= A5 A7 BA B5 63 4B 69 30 EE 77 F8 DB 5A 80 22 29 A6
RX: 56927us C=51 Bad CRC
RX: 300358454us C=51 Bad CRC
RX: 75912us C=51 Enhanced pid=0 S=Y A= 4C 0A 02 01 4B P(12)= 00 77 81 85 1E 1E 1E 1E 00 00 20 50
RX: 171859us C=51 Bad CRC
RX: 300491307us C=51 Bad CRC
RX: 209740us C=51 Bad CRC
RX: 300510299us C=51 Bad CRC
RX: 228731us C=51 Bad CRC
RX: 300548217us C=51 Bad CRC
RX: 266665us C=51 Bad CRC
RX: 300586098us C=51 Bad CRC
RX: 285652us C=51 Bad CRC
RX: 300624030us C=51 Bad CRC
RX: 380465us C=51 Bad CRC
RX: 300642970us C=51 Bad CRC
RX: 399456us C=51 Bad CRC
RX: 300680909us C=51 Bad CRC
RX: 590725us C=51 Bad CRC
RX: 300698212us C=51 Bad CRC
RX: 761417us C=51 Bad CRC
RX: 301192905us C=51 Bad CRC
RX: 1044253us C=51 Bad CRC
RX: 301251414us C=51 Bad CRC
RX: 1137468us C=51 Bad CRC
RX: 301482627us C=51 Bad CRC
RX: 1308133us C=51 Bad CRC
RX: 302220613us C=51 Bad CRC
RX: 1385607us C=51 Bad CRC
RX: 302296429us C=51 Bad CRC
RX: 1461470us C=51 Bad CRC
RX: 302486116us C=51 Bad CRC
RX: 1480433us C=51 Bad CRC
RX: 302637850us C=51 Enhanced pid=2 S=Y A= 4C 0A 02 01 4B P(2)= 80 7F
RX: 151691us C=51 Bad CRC
RX: 304156206us C=51 Bad CRC
RX: 437222us C=51 Bad CRC
From the second TX :
XN297 dump, address length=5, bitrate=250K
Protocol selected: 63, sub proto 0, rxnum 0, option 51
Proto=XN297DP, nbr_sub=4, Sub=250Kbps, Opt=8
Channel=51,0x33
RX: 0us C=51 Enhanced pid=3 S=Y A= 4F 43 54 81 81 P(12)= 34 13 02 01 18 26 37 1E 00 00 4B 4E
@saimat please test to bind with 1.3.1.19
Hello, I can't get my Eachine Q90C to work on my Jumper T16. Which protocol do I have to use? Or maybe it isn't supported?
I found something here, where some guy cracked the protocol, but thats for DeviationTX: https://github.com/goebish/deviation/blob/protocol_q90c/src/protocol/q90c_cc2500.c
Was posted here: https://www.rcgroups.com/forums/showthread.php?2949868-Eachine-Q90%28C%29-Flyingfrog-FPV-Racing-Quadcopter-%28Brushed-with-Rate-Mode%29/page8
Maybe you can help me?