CRC Errors

[d1000006]

We need help determining why we are seeing a lot of CRC error messages when we use the navX MXP.  The seem to occur, on average, roughly once per second.  The errors look like this example:

SPI CRC err.  Length:  108, Got:  31; Calculated:  127

We are using the SPI port via the RoboRIO MXP connector.  We're using C++

Our AHRS object construction was taken from the Rotate to Angle example:

    ahrs = new AHRS(SPI::Port::kMXP);

and we are requesting the angle every loop to view on the smart dashboard with:

    SmartDashboard::PutNumber("Heading", GetAHRSAngle());

We updated to the latest navX firmware and I believe the RoboRIO firmware version is 3.0.0f0 (I'll have to verify this).
WPI plugins version:  Robot C++ Development    0.1.0.201603020231

Does anyone know what would cause these CRC errors so regularly?

Thanks!
Dan

[d1000006]

Also, I left this function definition out:
float SysDrivetrain::GetAHRSAngle() // total accumulated, no discontinuity over 360deg
{
    if(!ahrsIsConnected) return 0.0;
    return ahrs->GetAngle();
}

[admin]

CRC errors would typically be caused by signal integrity issues along the SPI bus communcation path.  These are not typically seen for a navX-MXP directly connected to the MXP connector on the RoboRIO, but become more frequent in cases when an extension cable is used.

The two related issues involved here would be the strength of the signal, and the timing of the pulses.  So in addition to a long cable, issues could also occur at higher SPI bitrates. So you might see improved error rates at a lower bitrate (the latest libraries use 2Mhz, which can be lowered if you'd like through one of the alternate constructors for the AHRS class in the roboRIO navX-MXP library.

In addition to cable signal integrity issues, and timing issues, it's also theoretically possible that if the POWER and especially the GROUND signals (on the MXP connector, and on the navX-MXP) were having noise injected into them by other connected devices on the RoboRIO, or on the navX-MXP expansion port, and since these are used as reference voltages by which the "HIGH" and "LOW" states of the SPI bus communication are referenced, that these would be potential noise sources might cause data corruption.  To detect this type of noise source, an oscilloscope could be used to probe each of the POWER, GROUND, MISO, MOSI and SCL pins on the SPI connector.

All of that said, do note that because all numerical integration of key values occurs directly on the navX-MXP (yaw, pitch, roll as well as the integrated velocity and displacement values), a CRC error once a second is likely not to be noticed within the system, and likely won't cause any problems.  Of course it's not optimal (since it means that about once a second, your robot software will "miss" an update), but it's certainly not going to cause any incorrect calculations.

[Jeff Hutchison]

When you say "miss" an update, do you mean GetYaw(), for example, will just return the most recent good reading?

[admin]

In the case of a CRC error, the update in question will be discard (as the data is corrupt).  Until the next update is received, the last valid yaw angle will be returned by GetYaw().  Upon receipt of the next update, GetYaw() will return the latest yaw angle.  During this time, the onboard microcontroller is continuing to integrate the yaw angle.

Thus, the impact to the robot application of a CRC error is that the absolutely latest yaw angle is not available to the robot application until the next valid update.

[Chester Marshall]

I'm having the same problem with CRC errors when directly connected on the MXP port with no other connections.  Like you said, it does not seem to affect the operation at all.  My only problem is a desire to turn off the trace errors so I can monitor what is happening in autonomous routines with printf statements.  Is it possible to disable the trace for the SPI bus?

[admin]

There's not currently a way to do this, we've got an issue on github to resolve this; we're at the point where we are trying to avoid "gratuitous" changes as we head into FRC compeititions. However, if you'd like we can create a build in a week or so that addresses this.

[Chester Marshall]

I guess I'll try cutting back on the rate to see if they go away.  Would be nice to have this option in the future.

[admin]

What rate are you using?

And are you using TTL UART?

[Chester Marshall]

I'm using SPI and I have set it to 60hz and still get the CRC errors.

[admin]

Hi Chester,

There's a new build (3.0.327), this should alleviate the issues w/the CRC errors printing out to the Drive Station logs.

Aloha,

-scott