[tonyyng]

I am trying to use telemetry data (attitude) from a CC3D to send to another device on my FPV plane.  It is a combination OSD/pseudo flight controller.    I used the source code from minoposd as a starting point.  I had it working with on an Arduino Pro Mini connected to CC3D running version 14_10.  The attitude data seemed to drift a lot, so I upgraded the firmware on the CC3D to 15_09.  Things stopped working at that point.

The first issue I found when looking through these forums, was that telemetry needs to be 57600.   A bit of an issue for me, because my Pro Mini is a 3.3v/8Mhz, which my research says works best at 38400.  I'll need to see if it works okay at 57600.

Temporarily, I switched to a Mega 2560, which gives me a few more serial ports for debugging at my computer.

Now I'm able to connect to the CC3D, I'm finding that the only UAVObject I'm receiving is this one:

<object id="0xE33E5D4E" name="FlightStatus">
  <field name="Armed" values="Disarmed"/>
  <field name="FlightMode" values="Stabilized1"/>
  <field name="FlightModeAssist" values="None"/>
  <field name="AssistedControlState" values="Primary"/>
  <field name="AssistedThrottleState" values="Manual"/>
  <field name="ControlChain" values="true,false,false"/>
</object>

The data I want is the roll and pitch which is in this object:

<object id="0xD7E0D964" name="AttitudeState">
  <field name="q1" values="0.998124"/>
  <field name="q2" values="0.00168246"/>
  <field name="q3" values="-0.00758887"/>
  <field name="q4" values="-0.0177555"/>
  <field name="Roll" values="0.208602"/>
  <field name="Pitch" values="-0.864599"/>
  <field name="Yaw" values="-2.03982"/>
</object>

Has something changed in the way that telemetry is requested?  With 14_10, I was getting the AttitudeState object without doing anything special.  I didn't see anything obvious in the minoposd source code to request the AttitudeState data.

If I can't get this working, or the 57600/38400 speed is a roadblock, is there a way for me to change the CC3D firmware back to 14_10?

Thanks

[@marc]

Hi,

The Speed issue is fixed in "next", so you might try that.

As for the telemtry Flow, you have to make a sucessfull Handshake to get telemtry flowing. See the Wiki for details on that.

Also, are you using the correct object id's?

Regards,

Marc

[tonyyng]

Hi Marc,

Thanks for your suggestions:

The Speed issue is fixed in "next", so you might try that.

Is there a way to "try" next?  Are there binaries that I can download and install, which will update the firmware for the CC3D?

As for the telemtry Flow, you have to make a sucessfull Handshake to get telemtry flowing. See the Wiki for details on that.

I'm just doing what the minoposd is doing.  It has this comment in the code:
/* This OSD is not a GCS so we shouldn't participate in a connection protocol
 * which will update the stats being reported to one. If SEND_GCSTELEMETRYSTATS
 * is not defined then gcstelemetrystatus will simply reflect if attitudestatus
 * is being received.
 */
#undef SEND_GCSTELEMETRYSTATS
#ifdef SEND_GCSTELEMETRYSTATS
static unsigned long last_gcstelemetrystats_send = 0;

I did try it both ways.  I'm assuming this code enables the handshake. 

Also, are you using the correct object id's?

I'm only receiving one type of object with the id that I specified.  I confirmed the object ids using the approach described in another post (export UAVObjects to XML)

[@marc]

Hi,

you have to compile next from the sources yourself. The wiki gives info about that. You can revert to 15.9 Anytime you want.

Are the object ids in minoposd hard coded? You may want to check for gcstelemetrystats and flightelemetrystats object Id well.

Marc

[tonyyng]

you have to compile next from the sources yourself. The wiki gives info about that. You can revert to 15.9 Anytime you want.

I went through the steps to build next from source.  I am able to connect at both 38400 and 57600.  However, now the uavtalk message parsing logic doesn't seem to work.  It gets to the bottom of the function (uavtalk_parse_char) and returns 0, because the crc value doesn't match. 

Are the object ids in minoposd hard coded? You may want to check for gcstelemetrystats and flightelemetrystats object Id well.

Yes, the object ids are hardcoded in minoposd and they are correct.  However that isn't the issue.  The only uavtalk message coming through telemetry was 0xE33E5D4E (FlightStatus)

[TheOtherCliff]

Did you know that UAV object IDs change whenever anything inside the object changes?  This means that hard coded IDs must be checked and changed when necessary.