ST16 About Controller Version n/a

[h-elsner]

Now I found what I have done in the past related to a similar problem but not the same. But somehow some of those steps may help to try to overcome the situation by FW up- or downgrade. Down it is already ;-)

 

[Vaklin]

With the problematic camera he will not have coordinates in the EXIF data in taken pictures and redundancy control to the copter and probably more.

 

[h-elsner]

To extract the separate FW parts from the FW file here you can download the Typhoon H Firmware Tool from the download page:

Downloads

Download tools

h-elsner.mooo.com

 

[WTFDproject]

...some of those steps may help to try to overcome the situation by FW up- or downgrade. Down it is already ;-)

@Nicolai and @h-elsner ,
See direct message about file transfer box.

 

[h-elsner]

When I compare the screenshot from #7 and #17 then I see that something happened. Now the type "TyphoonH" was transferred from Autopilot to gimbal-> camera -> WiFi -> ST16.
The type comes from Autopilot as broadcast message over the UART (message ID 2, same as the telemetry over 5GHz WiFi message). This tells me that "something" is working over UART. This makes me think about a SW problem.

 

[WTFDproject]

When I compare the screenshot from #7 and #17 then I see that something happened. Now the type "TyphoonH" was transferred from Autopilot to gimbal-> camera -> WiFi -> ST16.
The type comes from Autopilot as broadcast message over the UART (message ID 2, same as the telemetry over 5GHz WiFi message). This tells me that "something" is working over UART. This makes me think about a SW problem.

I believe he used the good camera to do an update of the drone. He also updated the controller to current firmware. The current ST16 firmware displays the "Typhoon H" at the Autopilot line, even if the drone is not turned on. Why? I have no idea. But mine do it.

 

[Vaklin]

Very different versions between gimbal's and camera's FW can produce unpredictable results.

 

[Nicolai]

I believe he used the good camera to do an update of the drone. He also updated the controller to current firmware. The current ST16 firmware displays the "Typhoon H" at the Autopilot line, even if the drone is not turned on. Why? I have no idea. But mine do it.

Yes, exactly, I used both cameras for the two pictures, but I described this separately for the pictures so that there is no confusion.

 

[WTFDproject]

I'll check the pin assignment of the UART cable.
....

It would be a good idea to remove the rear arm cover and look for crushed wires near the screw holes. This is a common damage found on the UART cables. A cable that is damaged in this way can sometimes still show connectivity between the pins, but it is grounded and does not pass the signal.

 

[WTFDproject]

The camera used to make the document in the last post was (and still is) showing the same symptoms as the problem camera of this thread. As with the subject camera, it also checks good on the USB cable. So far it does not respond to firmware downgrade/update other than the camera firmware itself. It has shown no response to standard Yuneec update guidance, CGo3+ firmware replacement guidance, the guidance provided by @h-elsner above, or any of several random approaches that were attempted.
It is now midnight here. Tomorrow I hope to start swapping components between this unit and a working unit until a faulted component is identified. Perhaps there will be something found that can be useful.

 

[Vaklin]

Extremly useful will be to sniff the communication between the camera and the gymbal in time when the update is perfomed via SDcard in the camera. As we already has a gimbal update firmware in (probably) crypted format and we will have a chance to get a dencrypted copy, some new technologies can help us to have the encryption algorithm. This one should be the same as in FC flash file via GUI.

 

[WTFDproject]

... hope to start swapping components between this unit and a working unit until a faulted component is identified. Perhaps there will be something found that can be useful.

A known good gimbal board was installed on my problem CGo3+, and all versions immediately displayed with no other changes. For this one, it appears the issue is in the gimbal, but still nothing to say for sure if it is firmware or hardware. More looking to do, and maybe some playing around with the defective gimbal board.

 

[WTFDproject]

@h-

A known good gimbal board was installed on my problem CGo3+, and all versions immediately displayed with no other changes. For this one, it appears the issue is in the gimbal, but still nothing to say for sure if it is firmware or hardware. More looking to do, and maybe some playing around with the defective gimbal board.

The circuit is good from the UART1 wires to at least the first board component of each leg. There is no visible damage on the board. No idea if any of the components are bad. None LOOK odd.
@h-elsner, is the UART firmware part of the camera firmware, part of the gimbal board firmware, both, or is it all hardware driven?

 

[Nicolai]

It would be a good idea to remove the rear arm cover and look for crushed wires near the screw holes. This is a common damage found on the UART cables. A cable that is damaged in this way can sometimes still show connectivity between the pins, but it is grounded and does not pass the signal.

Thanks for the tip, I disassembled the camera further and checked the cables

 

[Vaklin]

is the UART firmware part of the camera firmware, part of the gimbal board firmware, both, or is it all hardware driven?

Explain a bit more what you have asked for, please.
To be simple, draw the communication lines from the copter to the gimbal and from the gimbal to the camera. Hold in mind they are two way. Also will help you to know about UART via WiFi from/to ST16 and camera.

 

[Nicolai]

Yes, but you now have the camera, controller and the drone all on current firmware. The gimbal firmware of the problem camera is the only thing you can't access. It is probably well out of date but at least it is working.
The good camera could be used for troubleshooting the bad cable, but I think I would not do so for the very little you would gain. The risk of damaging the good camera is too high.
Finding a parts camera on-line or someone sending you a cable are about the only options for getting a cable. It will do no good at all to replace the gimbal board unless you can find someone that can calibrate it to your camera system.

Why does another gimbal board that you install need to be calibrated?
The camera/gimbal can be calibrated via the ST16. Is this a different calibration?

 

[WTFDproject]

...The camera/gimbal can be calibrated via the ST16. Is this a different calibration?

The calibration on the ST16 is only a small part of an actual calibration. It will not help with introducing a new gimbal board into the system.

 

[WTFDproject]

Explain a bit more what you have asked for, please.
To be simple, draw the communication lines from the copter to the gimbal and from the gimbal to the camera. Hold in mind they are two way. Also will help you to know about UART via WiFi from/to ST16 and camera.

Yes, I know the flow path of the data. But I do not know what drives (controls) the flow. Is it driven by firmware, and if so, where does that part of the firmware reside?

 

[Vaklin]

Every source of data is activated by the part, where wires started. The same part accepts the messages from the counterpart. UART is point to point communication. Make a drawing with all MAVLINK affected components and just for simplification make the drone's FC as a central part. Every part has it's own number. Messages, as I already mentioned are point to point virtually and sometimes retranslation is needed due to hardware point to point UART.

Do some research and we can discuss further about units numbering types of messages and so on. Use Helmut's tool, I hope it will works as a sniffer in the middle between the gimbal and the camera. Ask him how to wire.

 

[h-elsner]

The UARTs from transport layer level is handled by the processors of each system component. The Autopilot controls a couple of them and among those is the UART to gimbal. Gimbal has to handle two of them one to Autopilot side and another to the camera. Camera has to control at least the one to the gimbal.
Each f those components has to "understand" the MAVlink messages. Processor has to distinguish what is for him, what he has to transfer to which other component.
And of course which message he has to create by itself. For example, gimbal sends its position every 1s.