Compass calibration needed?

[Dronea]

Hi,

I haven't flown my Q500 for a few months, and as I now powered the controller and the Q500, no telemetry is shown on the controller (all data seems to be N/A). The drone is fully operational nevertheless and the camera and flight control is working normally. Should I re-calibrate the compass to get all the data back on the ST10+ screen or what might be the problem?

Many thanks!

 

[DoomMeister]

I would suggest creating a new model and binding the aircraft and camera to it. Let us know the result.

 

[WTFDproject]

As implied by @DoomMeister, the problem is NOT related to calibrations at all. A new Model may help.

Also worth considering, is that transmission TO the drone and FROM the drone are two different wires between the drone reciever and the drone mainboard. (Telemetry is transmission FROM the drone.) On the Q500, both these wires (and two others) have a connector just inside the battery door. It is fairly common for wire pins in that connector to become partially or fully dislodged when sliding the battery in and out.
This picture shows a Q500 connector with the white pin fully disconnected as an example:

Note the wire colors DO NOT match up across the connector. (thanks, Yuneec) Attachment 32 in "Way To Fix Drones project" shows the wiring color changes associated with both Q500 and Q500 4K.

 

[Dronea]

I have created a new model as proposed, but I fail to bind with it. There appears to be no SR24_xxxxx model to choose from in the Flight settings? Any suggestions?

 

[WTFDproject]

If the rear main LED is flashing orange and there is still no binding, then the most likely answer is in Post #3.
Please check it.
Remember the affected pin(s) may not be fully disengaged from the connector. If they are partially pulled out, there is no connection. Ensure ALL pins are fully pushed into both sides of the connector.

If the rear main LED is NOT flashing orange, try the binding instructions provided by @DoomMeister in the post below.

 

[DoomMeister]

See page 27 in the following manual. The aircraft has to be placed in bind mode beforehand.

 

[Dronea]

Nope. None of this works. I have followed the binding instructions carefully several times (orange light blinking etc.), but, as said before, in the Flight settings sequence there's no SR24_xxxxx receiver model to connect with (no connection). Not even after creating a new model. Also, this is the 4K model, so there's actually no wiring, which could have come loose as with the previous model. I have updated the firmware for the drone via the USB programming port and also updated the firmware for the controller. No change. The drone isn't communicating with the controller as it should, I think. This is frustrating as everything worked fine last fall in previous flight sessions and I didn't change any settings afterwards. Anything else I could try?

 

[h-elsner]

Also, this is the 4K model, so there's actually no wiring, which could have come loose as with the previous model.

This is not true.
1st it depends not on the 4K model. There are (old) 4K models that don't have the Y-cable (need to disconnect the receiver to add the USB-to-serial connector for the GUI). And there are new 4K models that have a Y-cable.
2nd, the Y-cable has also connectors that may be loose. Sad, they are inside...

br HE

 

[Dronea]

Yes, I understand that the USB programming cable could have snapped on the other end inside the drone as well, i. e. when installing the battery, but as I have just re-installed the firmware successfully via that connection then this should not be the cause, right? Should I disassemble the housing to have a look inside?

 

[WTFDproject]

Yes, I understand that the USB programming cable could have snapped on the other end inside the drone as well, i. e. when installing the battery, but as I have just re-installed the firmware successfully via that connection then this should not be the cause, right? Should I disassemble the housing to have a look inside?

One of the 4 wires is communication TO the drone. Another is communication FROM the drone. Firmware update uses the wire TO the drone. Your issue is a problem involving communication FROM the drone. ANY of the various connectors and solder joints associated with the wire FROM the drone are the potential problem. Since your drone is a Q500 4K, the connector in the battery compartment is not likely the issue. Some additional information included in Post #3 may help. It will be necessary to open the shell to check further.

Since opening the shell is somewhat involved, it may be worthwhile to run the "Binding Verificaton" procedure first.
Please refer to Attachment 26 (Q500 Binding Verification) of the document in "Way To Fix Drones project". It may eliminate the wiring connections as the issue, and help us narrow in on the exact failure.

 

[Dronea]

Thanks. I actually did follow the binding verification procedure in the eforementioned document, but the end result was the same. So I guess I'll just have to open the shell to see inside...

 

[WTFDproject]

Thanks. I actually did follow the binding verification procedure in the eforementioned document, but the end result was the same. So I guess I'll just have to open the shell to see inside...

There are at least two places in your previous posts that suggest you may not have understood how the binding verification works.
The first is your use of the term "procedure" to refer to what is actually a verification process. To explain what I mean by this, a procedure is a document where you take a stated action, when that action is completed, you take the next stated action, and so forth until the procedure is completed. A "'verification process" is a little different. You are not so much focused on the action, as on the result. You take a stated action, but the next step is not another action, it is a verification of the expected result of the action you just took. If the observed condition does not meet the stated expectation, YOU DO NOT CONTINUE. Instead, you evaluate your finding, or in our case, you report the finding back to the Forum for evaluation.
So why do I think this is a sign you may not understand the process? Because of post #7. In post #7 you stated "there's no SR24_xxxxx receiver model". Verification of the receiver model was Step 37 of the verification. As a minimum, this is where you would have stopped and reported your finding back to the Forum. But your words above ("I actually did follow the binding verification procedure in the eforementioned document, but the end result was the same") make it sound as if you continued on in the process as if it were a procedure. Those words also lay a concern that Step 37 may not have been the FIRST verification that was not met.
If I am interpreting what I hear correctly, and if the explanation above changes your understanding of how the Binding Verification Document works, I would encourage you to run through the document again. If we can know the FIRST step where the verification fails, we may yet be able to pinpoint the failure.

And if totally misread what I think I see between the lines, please accept my apologies for wasting your time.

By the way, if the "from" wire is damaged as I expect, you would not have gotten past Step 30. But that would also mean you would ultimately have to pull the shell off to repair it anyway.

 

[Dronea]

There are at least two places in your previous posts that suggest you may not have understood how the binding verification works.
The first is your use of the term "procedure" to refer to what is actually a verification process. To explain what I mean by this, a procedure is a document where you take a stated action, when that action is completed, you take the next stated action, and so forth until the procedure is completed. A "'verification process" is a little different. You are not so much focused on the action, as on the result. You take a stated action, but the next step is not another action, it is a verification of the expected result of the action you just took. If the observed condition does not meet the stated expectation, YOU DO NOT CONTINUE. Instead, you evaluate your finding, or in our case, you report the finding back to the Forum for evaluation.
So why do I think this is a sign you may not understand the process? Because of post #7. In post #7 you stated "there's no SR24_xxxxx receiver model". Verification of the receiver model was Step 37 of the verification. As a minimum, this is where you would have stopped and reported your finding back to the Forum. But your words above ("I actually did follow the binding verification procedure in the eforementioned document, but the end result was the same") make it sound as if you continued on in the process as if it were a procedure. Those words also lay a concern that Step 37 may not have been the FIRST verification that was not met.
If I am interpreting what I hear correctly, and if the explanation above changes your understanding of how the Binding Verification Document works, I would encourage you to run through the document again. If we can know the FIRST step where the verification fails, we may yet be able to pinpoint the failure.

And if totally misread what I think I see between the lines, please accept my apologies for wasting your time.

By the way, if the "from" wire is damaged as I expect, you would not have gotten past Step 30. But that would also mean you would ultimately have to pull the shell off to repair it anyway.

Apologies, if I have been unclear in my previous posts. And yes, at Step 37. "Verify the receiver ID is displayed in white letters below the orange “Not connected” label in the "Model column" I stopped the verification process as there's no SR24_xxxxx receiver model to bind with. This is the problem. Also, as said before, when following the normal binding sequence outlined in the Q500 manual, for example, step by step, I get to the same point with no receiver model to bind with (even if I have just created a new model). Unfortunately I cannot make myself more clear than this on the issue. Luckily I have 3 weeks left of the 2-year warranty (close call!) so I took the drone kit to the seller, so they might come up with a diagnose. We'll have to wait and see.

 

[WTFDproject]

Unfortunately I cannot make myself more clear than this on the issue.

No problem. That makes it perfectly clear. And that eliminates the wires I was talking about. Having a warranty is great. The remaining possibilities would be a bad drone receiver, or possibly a similar issue on the controller end. Either way, getting it fixed under warranty is the way to go. Good luck, and happy flying.