Reverse engineering CGO3+ UART

[1midniterider]

I was just amazed that AI wrote anything remotely useful. The first iteration assumed 50Hz. The 2nd iteration based on 250Hz used the following to assign the pulse widths:

dutyCycle = map(flightControllerSignal, 1000, 2000, 0, 180);  // Mapping to servo position

Then used the write function with the duty cycle. I haven't analyzed it any depth.

Edit:

The 2nd iteration ChatGPT used the ESP32Servo Library which is essentially a wrapper for the ledc functions for Arduino from Espressif. The AI code probably could have be written or modified to explicitly set the frequency at 250Hz.

 

[1midniterider]

Today my oscope will arrive, so then I will be able to "see" what's going on with these Yuneec components.

 

[1midniterider]

Question... There is blue LED on the landing gear module. What is it's purpose? Sometimes it's rapidly flashing other times it's solid.

 

[1midniterider]

Just checking in... How goes things?

 

[h-elsner]

I made some updates in github. Link above. The sensor messages (msgID 255) are pretty clear now, stuff moved to q500log2kml - decoding sensor files.
Also could read some data from camera as calibration tool does. But I have no idea what to write or how the calibration process goes.
ToDo: The first part of the control message (msgID 1) still unclear (except velocity). Measurement units needs clarification, Gimbal position is not confirmed, only guessing.

 

[1midniterider]

At least you've made some progress. I've been taking a break. I'll jump back in soon.

 

[1midniterider]

Just for fun I had CluadeAI take a crack at CGO3+ UART dump. This is what it said about it.

Edit: Added MavLink comparison.

 

[h-elsner]

Typical AI nonsense. It takes some information found in different sources in the internet and offer it in a differnet structured (sometimes well structured) way. Some misinterpretions occur per default from AI.
AI is based on neuronal network that is trained with a huge amont of data. Training means it stores probabilities of decisions in the neuronal network (OK, a pure simplification but may help to understand). AI is NOT a knowledge database. All results are highly probable but not reallity.
Example:
Many people (and me too) put a time stamp when it was taken before the recorded data. For the AI this makes it highly probable that time is part of the message but it isn't while AI says it is. Same for CRC. CGO3 UART protocol has a CRC (16bit CCITT) but AI says it has not. The experts call this hallucinating (no joke).

All what is written there we already know. But on the other hand, the AI results as it was made are a good base for a documentation if you know the reality and edit it.

 

[1midniterider]

I was surprised that AI even came close to understanding what I fed it. As for the CRC unless it knew which bit/field contained it, AI would be best guess.

 

[h-elsner]

Now I can read some text messages from CGO3+. That may help to identify problems. Hoever that is far away from a calibration procedure
Here is a startup from a working CGO3:
Static Start!
APP:
CGO3 PLUS
HARD:

APPV: 1.25FIREV: 0.00BLV: 0.00
No EEPROM!
Sixface is OK!
Temperature Offset is OK!
Encode Set is OK!
Motor Zero Set is OK!
Front Set is OK!
Acc Offset is OK!


And this came from my defective cam:
Static Start!
Debug Start!
APP:
CGO3 PLUS
HARD:

APPV: 1.25FIREV: 0.00BLV: 0.00
No EEPROM!
Sixface is OK!
Temperature Offset is OK!
Encode Set is OK!
Motor Zero Set is OK!
Front Set is OK!
No Acc Offset!

The last messages seems to be the problem.

 

[h-elsner]

The tool is now here:

GitHub - h-elsner/CGO3p_control: Send control data to CGO3Plus

Send control data to CGO3Plus. Contribute to h-elsner/CGO3p_control development by creating an account on GitHub.

github.com

 

[h-elsner]

It looks like Pre-Front-Calibration is working now (at least it gives a success message). It needs no additions data.
All other calibration procedures needs data which are currently unknown.

 

[WTFDproject]

No Acc Offset!

The last messages seems to be the problem.

I think the "No ACC Offset" is absence of the same calibration data as created by "Gimbal Calibration" on the ST16. I do not know if it will run from the ST16 if the gimbal will not initialize.

 

[h-elsner]

Good point! I will check this. If so, I think we now have a tool for gimbal calibration (without any warranty - usage at own risk). Also YawEncoderCali and ZeroPhaseCalibration gave success message. Only the AccCali did not react at all.
I have uploaded the latest version to GitHub some minutes ago.

 

[h-elsner]

I think the "No ACC Offset" is absence of the same calibration data as created by "Gimbal Calibration" on the ST16.

Yes, this calibration did that thing. So, if you did AccErase and the calibration procedure did not end, then the GIMBAL CALIBRATION on the ST16 will help.

I do not know if it will run from the ST16 if the gimbal will not initialize.

Also yes, it will not work if the gimbal will not initialize. Also all calibrations do not have effect in this case. The gimbal entered debug mode. HW or magnet ring may be the root cause. But this is my camera for parts and crazy tests....

 

[h-elsner]

If you nothing have to lose and a camera on the table that needs calibration then you can give it a try.

 

[Vaklin]

Yes, this calibration did that thing. So, if you did AccErase and the calibration procedure did not end, then the GIMBAL CALIBRATION on the ST16 will help.


Also yes, it will not work if the gimbal will not initialize. Also all calibrations do not have effect in this case. The gimbal entered debug mode. HW or magnet ring may be the root cause. But this is my camera for parts and crazy tests....

You can add the sequence as done by ST16's gimbal calibration in your toll. Something like "calibrate via drone".

 

[h-elsner]

Good point! In Calibration mode (Act as gimbal checker) this didn't work. But if you act as flight controller the command will be accepted. I have added a button on the FC page in YTHtool. I will upload this version soon.

 

[h-elsner]

Upload done:

GitHub - h-elsner/CGO3p_control: Send control data to CGO3Plus

Send control data to CGO3Plus. Contribute to h-elsner/CGO3p_control development by creating an account on GitHub.

github.com

 

[1midniterider]

You've been busy...