Recent Posts

That that you point it, it makes sense.

Thanks

If you enable fast telemetry through the iridium link then you are asking for fast telemetry over Iridium, which cannot support the bandwidth.  If you want fast telemetry over the UHF link then you need to use that link to enable it.

-Bill

Well, Mr. Fisher has hit the nail squarely on the head, here. I tried an old version of the plugin, built with VS2005, (and referencing only the 8.0 CRT), and it caused no problem with GimbalUI startup.

So, the solution seems to be either get a copy of VS2005, make VS2008 think it's VS2005, or rebuild the SDK libraries with VS2008.

Thanks very much for the help. I doubt I'd have solved the problem without it.

Carl "clueless" Gustafson

For posterity, it appears the RPM sensor went bad and caused the altitude hold problem.  Thanks Marius.

Hi,
We established an Iridium connection to Piccolo using the PCC and noticed whenever we enabled the fast telemetry setting the PFD would freeze and eventually the connection would shut down.
This is not supposed to happen, right?
We should be able to get fast telemetry through the UHF link even if we add an Iridium connection, right?

Regards,

Carl,

I believe that your problem is that you built your plugin using Visual Studio 2008, which is causing it to include version 9 of the C runtime alongside version 8. I've seen problems like this before - one thing that can happen is that an object can be allocated using, say, version 9's new operator but then deallocated using version 8's delete operator. Somehow this can kill the application, although it's hard for me to imagine what could possibly have changed so drastically between the two versions...

I did  HIL for new configuration of my aircraft.  I followed steps you advice in Piccolo Setup Guide Document but during prelaunch state I switched CH5 on pilot consol (AP off), I moved Pilot Stick and Surface values changed both on PCC Surface Telemetry and Simulator Surface Mask. After I launched my aircraft from Simulator (Launch Button)  values of PCC Surface Telemetry changed but Simulator Surface valus didn’t change (Latency Value on simulator was 15-16). For this reason during HIL my aircraft crashed but in SIL the same aircraft flown correctly.
How was possible? What was my mistake?

N.B. Hardware configuration was ok. Can simulation was checked in Simulator and Can Device indicator was green.


Best Regards
Mauro Tafuro

Thanks for the reply, I appreciate it.

However, the plugin dll *was* built in release configuration, the dlls in the manifest (copied and pasted below) embedded in the plugin exist in the side-by-side directories on the target system, and it doesn't use QT.

I'm sure this isn't a Cloud Cap issue, but something in what I'm doing, but I can't figure it out.

manifest:
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
      </requestedPrivileges>
    </security>
  </trustInfo>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.4053" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>

If by roll graph you mean dCl/dBeta (called the dihedral effect) as a function of alpha, then yes that is not expected to be a straight line.  The dihedral effect is a function of the dihedral angle, the location of the wing on the fuselage, location of vertical and horizontal tail, etc.  It also strongly depends on wing sweep; and for swept wings the dihedral effect is a function of the lift coefficient, i.e. a function of alpha

-Bill

Email us the binary telemetry file, not the Piccolo log, as the latter can always be generated by replay. It could have been caused by significant error in the vertical velocity estimate, but I'd better review the telemetry first and comment on it later.

Thanks,
Marius