Reverse engineering CGO3+ UART

[h-elsner]

I tested four scenarios for startup camera.
1. The normal startup, FC (flight controller aka autopilot) switch the power for both, FC and camera.


2. FC alone, no camera


3. FC booted up, camera switched on later


4. Camera switched on, later FC powered up


Seems that the mysterious start pulse does not come from FC but is an effect to initialize the UART pins IMHO.

 

[1midniterider]

Part of the issue, is that ESP32 module is powered on ahead of the camera. So, I reset the esp32 and then connect power to the camera. I've reduced the time to send the cgo3 init sequence to within 500ms while the camera powers up. Once, I can be assured that it will work, then I will connect everything in normal operation mode and can probably reduce the init cycle time...

 

[1midniterider]

I changed the capture to using hardware UART and the CGO3+ output is different. The leading zero is missing. and the line after the very last line is one very, very, very ling line, since there were no more "0XFE" preceding the sequences. I'm looking to see if there is a way to parse the line or maybe there is a buffering issue.

 

[h-elsner]

This surprises me. Because this message normally is sent by Autopilot, not the camera. And SysID is 1 (=Autopilot) as expected. The sequence number counts correctly until synchronisation stops in line 21. The complete fix part is missing in this line. Later it regained the synch and the squence number is already 128. Then it counts up to 135 (line 29) and then the data are lost. Somewhere inbetween there also should be a heartbeat message. I don't see any messages from camera.

Question: Is the Typhoon H flight controller somewhere with the camera connected? Can it be that from line 29 on the flight controller switches to PWM? This would be my only explanation for this recording.
The good news: It records something that I have seen too.

 

[1midniterider]

The FC is not connected. The CGO3+ is connected directly to the ESP32 RX/TX and powered by the drone battery. This is my test setup. I've been using it to test various components. I posted a photo earlier. Should I ever get this working, it will be connected to an ESP32 module. The FC will be a PixHawk 6C.

 

[h-elsner]

The question is who sends the messages in the name of the autopilot? I saw those messages too but only from the autopilot as expected.

Here is what happens (or should happen) when camera is alone in the world and looking for a partner.

 

[Vaklin]

Check the CRC of discussed frames before do any conclusions.

 

[1midniterider]

Oddest thing... With only the RX/TX connections, my capture program started reading data from the CGO3+. I had not connected power... I'll re-verify later...

 

[Vaklin]

You're supplying gimbal MCU via UART lines. Before do any communication you should supply the unit and wait to have a proper gimbal initialization. See Helmut's diagrams.

Anyway these are only preliminary problems but your passion is remarkable.

 

[1midniterider]

On another front... The TH480 landing gear is PWM controlled. Looks like basically a pulse to raise and lower, correct?

 

[h-elsner]

It is a 250Hz PWM signal. Puls width 1ms is gear down,

Puls width 2ms is gear up

 

[1midniterider]

The PWM definitions has always been a source of confusion on my part. For instance you said that up requires a pulse width of 2ms and down requires 1ms at 250Hz. So then I pull out my handy dandy function definitions and they talk a completely different language duty cycles, resolution, frequency, etc. It's a good thing you put the diagrams up there. So, it turns out duty cycle = Time on / (Time on + Time off) * 100 as explained here. For the landing gear, based on the info you provided that would 50% for up and 25% for down, but it doesn't end there. Now you would think that you can pop those numbers into the function and call it a day. Nope, The function required to send the pulse uses values of 0 - 255 for duty cycle. So more calculations, so up now means (256 * 0.5) -1 (zero offset) or 127 and down is 63. And they wonder why we need aspirin. lol lol lol I apologize for the rant... And just to add to the confusion, sometimes the "pulse width" is given in microseconds vs milliseconds.

In the TH480 landing gear code the "pulse width" is given in microseconds and then throw in in twist of using 20000 - "pulse width". What is that all about?

        if( _call_times == 1)
        {
            px4_arch_gpiowrite(LDG_PIN, true);
            hrt_call_after(&_call, (20000-_pwm_pulse), (hrt_callout)&Typhoon_ldg::BitBang, this);
        }

        /*Send a low "reset" pulse*/
        if( _call_times == 2)
        {
            px4_arch_gpiowrite(LDG_PIN, false);
            hrt_call_after(&_call, (20000), (hrt_callout)&Typhoon_ldg::BitBang, this);
        }

 

[h-elsner]

Old analog servos have 50Hz pulse frequency. A cycle is then 20ms or 20000µs. 50% would be a pulse width 10000µs.

The gear servo has 250Hz, cycle = 4ms or 4000µs. 50% would be a pulse width by 2000µs.
There are servos on the market that have 400Hz maybe more.

Somehow the PX4 SW must have a definition what servo will be controlled. From this the pulse width depends.

However I can imagine that the gear servo will also deal with 50Hz. I will check this soon. I need to setup a thunderbird test system...

 

[1midniterider]

There are several settings in the landing gear code. In another section of the code you can see where down is set to 1000 microseconds and up is 2000 microseconds. How is frequency related to cycle or duty cycle?

 

[1midniterider]

There are several settings in the landing gear code. In another section of the code you can see where down is set to 1000 microseconds and up is 2000 microseconds. How is frequency related to cycle or duty cycle?

Looks like: cycle length (ms) = 1000 / frequency (Hz) or something like this.

 

[h-elsner]

Wikipedia says:
The period (symbol T) is the interval of time between events, so the period is the reciprocal of the frequency: T = 1/f.

1/50Hz = 0.02s or 20ms or 20000µs

Looks like: cycle length (ms) = 1000 / frequency (Hz)

Correct.

 

[1midniterider]

When using PWM control for the CGO3+, does it also use 250Hz as the frequency or does it use 50Hz?

 

[h-elsner]

PWM for camera tilt is a 50Hz signal. It contains not only the PWM pulse but always a start pulse 4500µs + a gap 500µs followed by the PWM puls between 660µs (cam 0°) and 3400µs (cam down -90°). This repeats all 20000µs (20ms or 50Hz).

If the ST16 is off the PWM pulse is very short, the oscilloscope can barly see it (~0µs). This let me think the values of the channels represents the µs: 0 -- 683 -- 2048 -- 3412 -- 4095 stands for n/a -- 0° -- -45° -- -90° -- also n/a for cam in tilt mode 'Angle'.

No signal with all other timings (ST16 off, interpreted as 0):

Channel value 0

Camera looks straight forward (0°):


Camera looks down (-90°):


A middle position ~ -45°:

Channel value ~2048

 

[h-elsner]

The landing gear servo signal from Thunderbird FW looks similar to camera PWM from Typhoon H above:
50Hz Starts with a fix pulse 4.5ms + gap 500µs = 5ms Start sequence followed by a PWM pulse 3400µs for gear down. I guess it will be around 683 for gear up (not seen because to read this it must flying).

 

[1midniterider]

Yuneec doesn't make it easy...