[TheOtherCliff]

I was waiting in a library for a few hours today, so I:
cloned the latest https://bitbucket.org/mindnever/librepilot.git
checked out omnibus_f3_f4 (9139f2fd)
built gcs bl_omnibusf4_hex omnibusf4
(starting with a new, untested board) flashed bl_hex with BF
rescue flashed fw_opfw with GCS
and I get nothing,
that is half dim blue LED solid for a couple seconds then it goes out
connects to GCS but no UAVOs, no blue LED

I went back to an old working version from Sept 13 (7466748c) and it works correctly so hardware is OK

Did I do something wrong or is F4 currently broken?

I could have asked in a PM, but I thought others might be interested.   

[mr_w]

Hey Cliff, I have messed this one up Forgot SETTINGS_INITIALIZE_ALL macro in omnibus f4 pios_board.c that was introduced in LP-173.

I have pushed the fix. Please try that one.

[TheOtherCliff]

Thanks, that fixed it.

================

I noticed just now that OmnibusF4 is sending MagSensor and MagState UAVOs when it doesn't have an onboard mag.  I would have guessed that MagSensor would be removed completely but MagState should stay in case an aux mag sensor is added.  Also I see that the GPS UAVO is sent even with the hwsettings.optionalmodules.GPS disabled.

So I viewed the System.DataObjects and watched which ones are active that shouldn't be for default settings (AttiEstAlgo=Basic, not armed, no modules enabled in hwsettings.optionalmodules, etc.)

These are the UAVOs that are sent that should not be.  The list is rather long, which would probably clog up the default telemetry data rate badly.  They are probably normally disabled because it is not armed, or the hwsettings.optionalmodule is not enabled or the sensor is not attached/configured (e.g.aux mag), or it is not using INS13 (ekf stuff), or the various pathfollowers are not being used, etc.

OmnibusF4 sends these UAVOs when it shouldn't:
accessorydesired
actuatorcommand
airspeedsensor
airspeedstate
altitudeholdstatus
auxmagsensor
debuglogstatus
ekfstatevariance (this should only be sent when INS13 is enabled?)
fixedwingpathfollowerstatus
flightbatterystate
gpspositionsensor
gpssatellites
gpstime
gpsvelocitysensor
manualcontrolcommand
pidstatus
pathdesired
pathstatus
pathsummary
poilocation
receiverstatus
stabilizationbank
stabilizationdesired
stabilizationstatus
systemalarms
systemidentstate
velocitdesired
velocitystate
vtolselftuningstats

[f5soh]

I noticed just now that OmnibusF4 is sending MagSensor and MagState UAVOs when it doesn't have an onboard mag.  I would have guessed that MagSensor would be removed completely but MagState should stay in case an aux mag sensor is added.  Also I see that the GPS UAVO is sent even with the hwsettings.optionalmodules.GPS disabled.

Disabling the GPS changes nothing because GPS module is already builtin.
Magsensor uavo can stay like that for compatibility reasons.

These are the UAVOs that are sent that should not be.  The list is rather long, which would probably clog up the default telemetry data rate badly.

This board is able to run EKF and do nav like a Revo.
Most UAVOs you mention are simply updated periodically, at low rates, like when you use a Revo so there will be no issue with telemetry.

[TheOtherCliff]

All UAVOs I listed are not sent by a default 16.09 Sparky2 configuration, but are sent by a default (15.09+#) OmnibusF4 branch configuration.

So for instance, default 16.09 Sparky2 does not send fixedwingpathfollowerstatus.

About 29 extra UAVOs are sent.  All the extra UAVOs probably add up to a much higher required telemetry data rate.  I can't believe that this is desired behavior.

[f5soh]

All the extra UAVOs probably add up to a much higher required telemetry data rate.

Maybe you can double check the effective Rx rate and compare with 16.09 ?
Rx rates seems similar and should not cause issues.

[TheOtherCliff]

Not at bench right now.

You think that sending 29 extra UAVO types is correct?   

[f5soh]

Seems just a different UAVOBrowser display between 16.09 and next, please do the test and compare effective Rx rates.

[TheOtherCliff]

The omnibus branch is based off of 15.09, not next, and sending wasteful unnecessary extra UAVO types is a bug.  I try to point this out so that it gets fixed for next.

[mr_w]

The omnibus branch is based off of 15.09, not next, and sending wasteful unnecessary extra UAVO types is a bug.  I try to point this out so that it gets fixed for next.

That seems quite odd. Omnibus f4 branch is regularly rebased on next. In fact that was the reason for this latest problem.

[f5soh]

You maybe miss a tag in your cloned repo
Version displayed uses latest tag in git + how many commits are added.

There is indeed a bug, but telemetry needs are the same as OP15.05 at least.

[TheOtherCliff]

Seems just a different UAVOBrowser display between 16.09 and next, please do the test and compare effective Rx rates.

Tests were run on the private dev branch in question (15.09+r1726-g9139f2f).

I had some time waiting in a lobby today.  Here are the results.  You can see from my previous list that there are many (29 or so) extra uavos being sent above the default set that is sent (by a 16.09 Sparky2).  Did 15.09 send all this extra data (and fixed in 16.09) or is this a new issue?

To temporarily correct the issue for testing I simply disabled FlightUpdatePeriodic for the 29 extra UAVOs and ran the dev branch again:
- approximate average/max with the extra uavos sent with default settings 1730/1773
- approximate average/max with the extra stuff disabled  650/675

About 2.66 times the amount of data when compared to what it should be sending.

Of course these numbers will be different if GPS enabled, if using INS13, if armed, etc. 

[f5soh]

OP15.05, LP15.09 and LP16.09 send the same UAVO set and total RX rates are similar.
LP16.09 do not display those extra uavo send but in fact they are sent.

Simple fix to improve bandwidth instead of disable by hand every UAVO is move those 'advanced' UAVOs from 'periodic' to 'throttled' > see PR.

[TheOtherCliff]

While discussing this, here are two more UAVO sending issues to consider:

cameradesired is sent even if camera module is disabled.

omnibusf4 has a current sensor and so no mag sensor.  It sends magsensor uavo but it shouldn't know anything about the magsensor.  If used, it would need magstate and auxmagsensor, but never needs magsensor at all.  I am guessing that would require some "#if defined" code changes since all INS13 capable FC's have previously had onboard mag.

[f5soh]

cameradesired is sent even if camera module is disabled.

Camera module is builtin, so disabling changes nothing same as GPS module 'disabled' you pointed above.
In your branch the camera module compute the CameraDesired at all times.  > Look Pull request fixing this.