QGC with ASL_HIGH_LATENCY message problems

[philipoe]

Small bugs observed while testing SatCom. This is just quick-notes made together with @mhugentobler :

• Analyze widget needs to get HighLatency-messages too. Until now, upon reception of a SatCom message, QGC changes only the map and primary flight display views/widgets. However, the Analyze widget does not receive these values. This needs to be changed (i.e. the ASL High Latency Message values need to be shown there). Note: Most probably, this issue was only due to flawed/too short testing. Keep an eye on this however.

• Energy Widget budget needs to be resized once after launching it. This is a bug. Probably, we just need to issue something like "Draw()" once after the Analyze widget is opened. Check this.

• energy widget update -> does not update when open before first message arrives -> fix! Note that the energy widget

  • is NOT updated when you have it open before the first satcom message arrives
  • is NOT updated when you have it closed before the first satcom message arrives but you had it open when QGC started
  • is CORRECTLY updated only when you never had the energy widget open after starting QGC and then the first satcom message arrives (i.e. you might need to close the widget -> close qgc -> restart qgc -> wait for first satcom message -> then reopen widget).

• Two clients connected to the server via udp2rabbit "steal" satcom-messages from each other, i.e. if client nr. 1 receives a certain message then client nr. 2 will not receive that respective message.

• Increase "Communication lost" warning to ca. 1.5x satcom message sending period (if not already done so). This would mean that if we don't loose satcom messages (and their delay is constant), then we should never get the "communication lost" warning.

• Energy Widget shows weird values for quantities that are not received via SatCom -> Set these to N/A.

[mantelt]

I never noticed that ASL_HIGH_LATENCY would not appear in analyze, except when the mavlink messages were not built in properly...

[mhugentobler]

Right now the communication lost timeout is set to 60s, while we are sending every 40s. So the rate of 1.5 is already there. It was probably a problem only when we both were connected to the iridium server and stole each other every second message. Of course this value can be set to whatever we want with Vehicle::setConnectionLostVariable('timeout in milliseconds').

The analyze widget showed stuff correctly last time we checked.

I will work on fixing the other points once the batteries are soldered.

[philipoe]

How is this progressing?

[mhugentobler]

i pushed the branch fix/energybudget (to be tested in flight) where i fixed points 2 and 6.

will take a look at point 3 next.

i can take a look at point 4 as well but i am not familiar with tcp or udp

[philipoe]

@acfloria Just left this issue open here because the "receive satcom on two different clients" issue is still open.