Hello Fellow Yuneec Pilot!
Join our free Yuneec community and remove this annoying banner!
Sign up

ST10+ permanent USB debugging on. Is this possible?

Joined
Sep 28, 2020
Messages
1,295
Reaction score
514
Age
55
Location
Kozloduy, Bulgaria
Hi!

I do some experiments with one ST10+. Unfortunately, the launcher is wrote not so good and in case of an error in the database, the device just informs everyone about this issue. At the same time, I know where is the mistake and can repair it, to keep experiments furder, but I have no way to enable USB debugging and to connect the controller via ADB. With the help from one good guy, I reflashed the device to its initial state, but this is a relatively long process, so I can't do it after every test.

So, can I do something to have USB debugging always on? Android version is 4.0.3, build 31c.
 
Tap rapidly to Android version in the System settings/About Flight Mode Control.
You will get a hidden screen. Tap on Developer Option.
Set check box USB debugging.

Hope that's it.

br HE
 
Yes. I do the same. Check this option after the restart of the controller, please.

Unchecked, yes? If not, probably your build is different from mine. But I want to use the last build because the model database structure differs between builds.

I see the solution in these ways. One, to find a bug in the kernel, which I remember for 4.0.x is persisting, or to implement some software in the middle of the startup process.

There is not clear yet when the check goes out. Until shutdown or in the time launcher starts up. On the GitHub sources are available, but this is not an easy solution, so give ideas, boys and girls!
 
Done!

Prerequisites:
mount -o remount,rw /system

chmod 666 for both files


echo "persist.service.adb.enable=1" >> default.prop
echo "persist.service.debuggable=1" >> default.prop
echo "persist.sys.usb.config=mtp,adb" >> default.prop

echo "persist.service.adb.enable=1" >> /system/build.prop
echo "persist.service.debuggable=1" >> /system/build.prop
echo "persist.sys.usb.config=mtp,adb" >> /system/build.prop

You can change mode back to 644 and remount system to ro.

Until the launcher is not started I have ADB connection. When starts, it kills the USB debugging, but this is not so important I hope. Important is it does this stupid thing before checking database integrity or after that.

One good solution can be to halt the startup process with some command, but for now, I have no idea how without debugging software, but I'll seek.
 
Last edited:
To clarify...

Booting time is more than enough to replace DB with stock one if you have messed something. (Definitely, the model type should NOT be 401, stupid launcher crashes in this case.)

The bad news is that flight mode switch is hardware coded to send flight mode commands without relation to DB values. These values are related to limit the curves from sticks in different modes. This is good too, but only when I arrange a packet sniffer to see what I'm doing. To check curves in the sky is a bad idea, I guess.

In the worst-case scenario, apk should be recompiled with some minor improvements, but this is not today's task.
 
Hi vaklin,
you wrote „With the help from one good guy, I reflashed the device to its initial state“

Can you please advice how?
I bricked my backup ST10+ While i tried to flash the TRWP and all my tries to get control back was fail.

It connects to my pc, but no drivers will be found.
I tried the one you offered in the Unbrick thread but without success.

Now it starts until the yuneec screen comes up, than a short break and the vibration alarm occurs permanently no more reaction.

I was today on a trainings flight, where suddenly the Video link in my ST10+ from my copter collapsed down to just 20 meters distance.
The transmitter (mk58) works still on the ipad link but no more longer on the original ST10+.
So i like to doublecheck what is happen, also the screen on my original is very scratchy.
 
Last edited:
May this thread will help you

 
To clarify...

Booting time is more than enough to replace DB with stock one if you have messed something. (Definitely, the model type should NOT be 401, stupid launcher crashes in this case.)

The bad news is that flight mode switch is hardware coded to send flight mode commands without relation to DB values. These values are related to limit the curves from sticks in different modes. This is good too, but only when I arrange a packet sniffer to see what I'm doing. To check curves in the sky is a bad idea, I guess.

In the worst-case scenario, apk should be recompiled with some minor improvements, but this is not today's task.
Would the UAV Simulator work, using the ST10+, the commands should be the same? Then you can avoid In-Flight Testing.... Just a Thought...;)
 

Members online

Forum statistics

Threads
20,973
Messages
241,794
Members
27,357
Latest member
Bech