Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Park10 branded (wltoys) a160 J3-cub skylark #1069

Open
bad-andy-rc opened this issue Jan 31, 2025 · 50 comments
Open

Park10 branded (wltoys) a160 J3-cub skylark #1069

bad-andy-rc opened this issue Jan 31, 2025 · 50 comments

Comments

@bad-andy-rc
Copy link

Recently picked up a Park10 branded version of WLToys' a160 j3-cub rc plane. I would love to bind to it using TX16s 4-in-1. I tried latest stable release v.1.3.4.0, and test release v1.3.4.27 under all protocols known to have worked with prior WLToy's versions. No luck, this board is different. It says P710x on it.

Image

Image
@pascallanger
Copy link
Owner

Which type of multi module do you have? External by any chance?

@bad-andy-rc
Copy link
Author

bad-andy-rc commented Jan 31, 2025 via email

@pascallanger
Copy link
Owner

Do you have a 3.3V FTDI/serial converter that you can connect on your internal module? It requires to open the radio but the pins to connect to on the module are accessible.

@pascallanger
Copy link
Owner

pascallanger commented Jan 31, 2025 •
edited
Loading

That's the 2 pins which need to be connected on your serial converter to use the debug mode and display the result on your PC: Image

@bad-andy-rc
Copy link
Author

bad-andy-rc commented Jan 31, 2025 via email

@pascallanger
Copy link
Owner

A 3.3V USB serial adapter is only a few euros/dollars and most likely available in a few days wherever you are.
Image

@bad-andy-rc
Copy link
Author

bad-andy-rc commented Jan 31, 2025 via email

@pascallanger
Copy link
Owner

Yes perfect

@bad-andy-rc
Copy link
Author

bad-andy-rc commented Feb 4, 2025 via email •
edited
Loading

@pascallanger
Copy link
Owner

You have to switch the voltage to 3.3V on your USB to serial adapter using the strap, right now it's on 5V on the picture.
The connection looks good. You need to connect both GND together and connect the module TX to the USB serial RX.
Yes the pins won't fit but you could remove the pin and solder the wire directly on the module. You can then leave this connector in the radio if we ever need it for another model.
You can use your Mac to do the dumps. What you need a serial terminal to display what the module sends. There are many like Arduino has one built in if you already have it installed or use putty which works on Mac: https://www.puttygen.com/download-putty

@bad-andy-rc
Copy link
Author

bad-andy-rc commented Feb 4, 2025 via email •
edited
Loading

@pascallanger
Copy link
Owner

The picture is wrong...

Module Serial
GND GND
TX RX

I don't know what the STM32CubeProgrammer can do but I don't think it will do it. Install putty if you don't need Arduino.
If you follow this: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/blob/master/docs/Advanced_XN297Ldump.md you should see the module booting when powering on the radio with a model that has your internal module enabled for Multi.

@bad-andy-rc
Copy link
Author

bad-andy-rc commented Feb 4, 2025 via email

@pascallanger
Copy link
Owner

pascallanger commented Feb 4, 2025 •
edited
Loading

The software in the pic is Arduino. But you can take any serial software...
For the module you need to install the latest firmware ftdi debug which is in this zip file : https://nightly.link/pascallanger/DIY-Multiprotocol-TX-Module/workflows/main/master/multi-test-build.zip

@bad-andy-rc
Copy link
Author

bad-andy-rc commented Feb 4, 2025 via email

@bad-andy-rc
Copy link
Author

bad-andy-rc commented Feb 5, 2025 via email •
edited
Loading

@pascallanger
Copy link
Owner

pascallanger commented Feb 5, 2025 •
edited
Loading

Please test this firmware: multi-stm-ftdi-1.3.4.28.bin.zip

@bad-andy-rc
Copy link
Author

bad-andy-rc commented Feb 5, 2025 via email

@pascallanger
Copy link
Owner

pascallanger commented Feb 5, 2025 •
edited
Loading

Have you configured putty to open the serial port of your USB converter (COM port that appears when you plug it) and set the baudrate to 115200?

@bad-andy-rc
Copy link
Author

bad-andy-rc commented Feb 5, 2025 via email

@pascallanger
Copy link
Owner

Try this version: multi-stm-ftdi-1.3.4.28a.zip

@bad-andy-rc
Copy link
Author

bad-andy-rc commented Feb 5, 2025 via email

@pascallanger
Copy link
Owner

That's strange...
Can you take a picture of your setup?
The module should write some outputs when you select a model which is using it or boot the radio with a model using the module.

@bad-andy-rc
Copy link
Author

bad-andy-rc commented Feb 5, 2025 via email •
edited
Loading

@pascallanger
Copy link
Owner

That's really strange. Let me reproduce it when I'll be home this WE and get back to you.

@bad-andy-rc
Copy link
Author

bad-andy-rc commented Feb 6, 2025 via email

@pascallanger
Copy link
Owner

I would assume yes since the module sends something each time you change from one protocol to another.
What happens when you open putty and select a model with the LEDs changing? Don't hesitate to change from one model to another using a different protocol.

@benlye
Copy link
Collaborator

benlye commented Feb 7, 2025

@pascallanger I've been working on a board definition for internal serial debugging. I modded one of my radios so I could connect an FTDI adapter to the internal module for testing. I confirm that neither of the builds you posted generates serial debug output.

However, using the new board definition I compiled this binary, which does provide serial output.

@bad-andy-rc, give this binary a go. You should see readable serial output with baud set to 115200. If you don't get anything with this file then you should take a look at your wiring and connections.

multi-stm-ftdi-1.3.4.30-ben.zip

@pascallanger
Copy link
Owner

@benlye thanks!!!

@bad-andy-rc
Copy link
Author

bad-andy-rc commented Feb 7, 2025 via email

@pascallanger
Copy link
Owner

Few questions:

  • How do you put the TX in bind mode?
    • Is it in bind each time you power it up?
    • Do you exit bind mode when you go up and down on throttle? Something else?
    • Does the TX needs to have the plane powered on to exit bind?
  • Does the TX need the plane to be on for the led to change its pattern after power on?

For the dumps, it depends a little on the above but you can do this anyway:

  • power on the TX in bind mode
  • create a new model, select the protocol XN297Dump and subprotocol auto
  • You should see on the output the module scanning all frequencies and bitrate. Let it do its thing. When it finds something it will start to analyze. When it finishes to look at the RF part, it will switch to identify features. At this stage, save the content of everything that has appeared and store it in a text file that you post here.
    For the second dump, you do the same but in normal mode (exit bind). Just reload the model, it will start scanning again... Save the content and call it normal.txt.
    At this stage we should see what bind and normal packets look like. The next step is to identify what the packet content is. When the module states identify sticks and features, move slowly the throttle down->up->down, save that to a throttle.txt file. Repeat the action with aileron, rudder, elevator and any other switches/buttons/special features that the plane has every time in a different file.

@bad-andy-rc
Copy link
Author

bad-andy-rc commented Feb 7, 2025 via email

@pascallanger
Copy link
Owner

pascallanger commented Feb 7, 2025 •
edited
Loading

It's a variant of the XK2 protocol.
The dump you've sent is what the plane sends to the TX to initiate the bind.
The plane is currently waiting for an answer from the TX... So like if your TX is not turned on or not in bind mode or...

Extract from my XK2 protocol notes:

Bind

Plane sends these packets:
RX: 0us C=71 S=Y A= CC CC CC CC CC P(9)= 9C BB CC DD 38 12 10 00 19
P[0] = 9C bind phase 1
P[1] = Dummy TX_ID
P[2] = Dummy TX_ID
P[3] = Dummy TX_ID
P[4] = RX_ID[0]
P[5] = RX_ID[1]
P[6] = RX_ID[2]
P[7] = 00
P[8] = sum(P[0..7]) + BF

The bind RF frequency is different since yours is 69 instead of 71
In your case the plane ID is 84 24 20
The checksum calculation is also different P[8] = sum(P[0..7]) + CF. They've just added 10 so may be it's +10 everywhere?

Normally the TX answers with its ID (replacing the dummy bytes) and the plane acks before switching to normal packets.
Since they've changed the bind RF frequency and the checksum, I'm wondering how much they've changed the protocol... Without all the dumps it's hard to answer.

As you can see you must be crystal clear on which state the TX is, which state the plane is and so on when doing the dumps. Usually the LED on the TX and plane changes to indicate the different phases so use this to report.

@bad-andy-rc
Copy link
Author

bad-andy-rc commented Feb 7, 2025 via email

@pascallanger
Copy link
Owner

pascallanger commented Feb 7, 2025 •
edited
Loading

If you have powered on only the TX, yes you get nothing... This is what I've explained you... The TX doesn't send anything until it "hears" from the plane. The plane is talking first.
Power on both the TX and the plane. Make sure you have control from the original TX and you'll get some outputs. Send the requested dumps.
For the other bind phases we will see later...

@bad-andy-rc
Copy link
Author

bad-andy-rc commented Feb 8, 2025 via email

@pascallanger
Copy link
Owner

pascallanger commented Feb 8, 2025 •
edited
Loading

Sorry but you are not following the instructions neither answering the questions... What you are providing so far is not useful and does not allow me to work on it.
So let's try again. You MUST follow each line at the letter and provide either a text file or an answer.

Here is the process you need to follow for the dumps below:

  1. Power on the plane
  2. Power on the original TX
  3. Make sure that you can control the plane
  4. Turn off the plane
  5. At this stage the original TX is still powered on and transmitting -> do not power off the original TX

Once the above is done:

  1. Relaunch a dump (by switching model or sub_protocol)
  2. Wait for the text "Identifying Sticks and features" to appear
  3. Move extremely slowly Aileron from mid->right->mid->left->mid
  4. Copy the output in a text file and save it with the name Aileron.txt
  5. Repeat step 1 to 4 replacing Aileron by Throttle, Elevator, Rudder
  6. Repeat step 1 to 4 replacing Aileron by 4 slow presses of each button on the original TX, example press slowly 4 times the 3D/6G button and save the content in the file 3D6G.txt. Some buttons have short press and others long press to activate the features, please adapt.
  7. Turn off the TX
  8. Post all the text files here

@bad-andy-rc
Copy link
Author

bad-andy-rc commented Feb 8, 2025 via email •
edited
Loading

@pascallanger
Copy link
Owner

I have a hard time to believe that when the plane is bound and surfaces move when you touch the TX, that if you shutdown the plane the TX stops sending anything on any RF channels.
This would be catastrophic since it would mean that if the plane goes too far or something blocking the signal and the TX doesn't receive the plane anymore it will stop sending anything, which means that you just lose the plane even on a temporary event...
Are you sure that you are really following:

  1. Power on the plane
  2. Power on the original TX
  3. Make sure that you can control the plane
  4. Turn off the plane and do not power off the original TX
  5. Launch a dump using the sub protocol Auto
  6. Launch a dump using the sub protocol 1M and RF frequency=-1

@pascallanger
Copy link
Owner

I've tried to code the protocol but there are too many unknowns to hope that it will work right away and even if it does don't fly with it...
That said try the test version 1.3.4.31 protocol XK2/P10.

@bad-andy-rc
Copy link
Author

bad-andy-rc commented Feb 9, 2025 via email •
edited
Loading

@pascallanger
Copy link
Owner

pascallanger commented Feb 9, 2025 •
edited
Loading

Ok for the features, you need to do some dumps:

  1. Power on the plane
  2. Power on the original TX
  3. Make sure that you can control the plane
  4. Launch a dump using XN297DP sub protocol Auto
  5. Wait for the text "Identifying Sticks and features" to appear
  6. Press one button 4 times on the original TX with a PAUSE in between each press.
  7. Save the content in a file with the name of the feature.
  8. Repeat steps 4 to 7 for all the buttons/features (not the trims but things like 3D/6G, rate, hover, light, ...)
  9. Post all the files

I can't even see on your manual how to switch the lights on the plane despite the fact that there is a light icon on the LCD. You might need to long press some buttons to find this "hidden" feature.

@benlye benlye mentioned this issue Feb 10, 2025
Open
@bad-andy-rc
Copy link
Author

bad-andy-rc commented Feb 10, 2025 via email

@pascallanger
Copy link
Owner

I'm struggling to understand the issue. You've already provided the same kind of outputs I need in this post #1069 (comment) as an example. I'm not asking more than that.

What I really need is on all the lines that you see scrolling like this:
P: 32 32 00 32 20 40 01 C8 EE
P: 32 32 00 32 20 40 00 C8 ED
P: 32 32 00 32 20 40 01 C8 EE
P: E8 25 3B 00 00 00 00 00 24
P: 32 32 00 32 60 40 00 C8 2D
P: E8 25 3B 00 00 00 00 00 24
P: 32 32 00 32 60 40 01 C8 2E
P: 32 32 00 32 60 40 00 C8 2D
P: 32 32 00 32 60 40 01 C8 2E
P: 32 32 00 32 60 40 00 C8 2D
First, the lines starting with P: E8 25... can be ignored. When you press a button you should see some values moving in the P: 32 lines. This is what I really need: when I press the button X this value changes momentary or permanently from Y to Z when I press it again it goes from Z to Y.

@bad-andy-rc
Copy link
Author

bad-andy-rc commented Feb 10, 2025 via email •
edited
Loading

@pascallanger
Copy link
Owner

I don't understand why the fast scrolling is challenging... I was not asking you to look at the data on the output specifically, let it scroll quickly press the button four times and save the full putty output then restart putty to clear the previous data and repeat...

Anyway, I've looked at your files and all the flags look to be correct in the test version you tried out.
The channels are setup like this: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/blob/master/Protocols_Details.md#sub_protocol-p10---1
You need to test and really look at what the plane is doing after you power on the motor at least once to enable the gyro and all the compensations. For example going from 6G to 3D can be identified since 6G will move the elevator to put the fuselage level where in 3D the elevator will stay flat and only move to counteract sudden movements.

@bad-andy-rc
Copy link
Author

bad-andy-rc commented Feb 11, 2025 via email •
edited
Loading

@pascallanger
Copy link
Owner

The protocol is final from my perspective and has said yesterday I haven't touched anything since the test version from 3 days ago as everything I see in the dumps are already in there.
Channels setup: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/blob/master/Protocols_Details.md#xk2---99

@bad-andy-rc
Copy link
Author

bad-andy-rc commented Feb 12, 2025 via email

@pascallanger
Copy link
Owner

For bind, the protocol doc and the X4 sub protocol : "The plane does not need to be bound each time if it is powered on after the radio/protocol is on.". Since both protocols are similar I would expect that it works the same. Basically if the plane is bound and controlled, turn it off and turn it back on, it should reconnect immediately. If not then I can modify the doc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@pascallanger @benlye @bad-andy-rc