Analog ADXRS450 not working in LabView

I have two of the Analog XR450 Gyros.
FRC Accelerometer & Gyroscope (Rev. A) and FRC Gyro with Chip Select Jumper (Rev. B)

Both are the previous models that came in old kit of parts for previous games.

I have all the 2019 LabView for FRC installed and was trying to get one of them working and LabView seems to know they are there but I can’t get any readings from them.

The power LED lights up but not the “Ready” LED.

Have tried both of the designs on two different RIOs.

In software I get TRUE when I query the “Device Found” status after I open it.
I do get a couple of different errors in the driver station console.

“Error -61073 Invoke Method: FIFO.Read in>>>Robot Main.viLabView FPGA: The number of elements to read or write must be less than or equal to the depth of the host memory DMA FIFO”

I’m just opening the gyro in and do a Get in periodic tasks in a 10ms loop.

Anyone getting either of these to work this year?

@AfterTen you might be running into a Known Issue:

Hi @AfterTen, I believe you’re running into a bug introduced when the kickoff version of the RoboRIO image was compiled by NI. As @oscarfonloz mentioned, you can implement the workaround linked if you’re handy with SSH or you can download and run a special utility made to patch the fix automatically. The utility can be found at:

This workaround should only be necessary until NI releases a new update, so please be sure to watch the FRC team updates for more details. If you run into any issues with the utility or getting your sensor working, please reach out to me via this thread or PM.

Sorry for all the trouble!

@AfterTen The FRC 2019 Update Suite [FRCLabVIEWUpdate2019.1.0] has been posted and should fix this problem :smiley:

  1. Download and install from
  2. Reimage your roboRIO with the new FRC_roboRIO_2019_v13 image

FYI @juchong

Didn’t work for us. Same error. Two different Gyros, two different roboRIOs, two different driver stations. USB and ethernet connections.

DS: 19.0
RIO: FRC_roboRIO_2019_v13
Lib: 2019 LabVIEW Update 2019.1.0

Also tried the SSH re-compile; still no joy.

Hi @ayeckley, does the power LED on the sensor boards turn on when the RoboRIO is powered?

Yes, but I think we may be on to something on our end. Gyro/Open (in still throws the -61073 error as it did before the update, but we do appear to be getting valid data from Gyro/Get Angle (in now and it’s not generating any errors. Is that expected behavior?

We are getting massive drift (0.5 deg/sec) from the Rev A H/W variant as well despite the usual countermeasures. Our other gyro (a Rev B variant) is only drifting 0.01deg/sec which is much more in line with historical drift. Is Rev A still supported in S/W?

I don’t think I’ve ever seen that error before. Maybe one of the NI guys could add more insight since they developed the software. As for the massive drift, be sure to not move the robot when code is starting since the gyro driver automatically performs an offset calibration on boot. We’ve put together a guide on the website here. Rev A and Rev B hardware are identical aside from the accelerometer onboard, so there should be no difference in performance.

The error is the same one the OP of the thread reported. We’ve done all of the usual tricks associated with the boot-up calibration; I don’t think that’s the issue. I suspect we’ve got a cracked wirebond inside the package.

Unfortunately we weren’t awarded a new A-D gyro this year thru First Choice, leaving us with only one working unit (and no way to buy more). I’m sad to say we’re going to have to bail on using the A-D gyro this year in favor of something else we can get spares of. Thanks for your help…

Send me a DM with your email and contact info. I’ll be happy to provide an RMA.

Thanks - much appreciated. I’ll be in touch with you directly.

Here’s a potentially-interesting update for anyone following along:

We found that whenever the Gyro/Open error was generated during it would prevent our USB camera stream to the default dashboard from working properly. Not sure what the connection between the two are: we weren’t getting any errors from anything in Periodic Tasks (where Gyro/Get is polled at a leisurely 100ms and resulting data placed into a Global Variable), Teleop (where the Global Variable is displayed) or Disabled (where we will occasionally run a Gyro/Reset).

We did find that reducing the Gyro/Open calibration time from the default 2 seconds to 1.6 or less (or turning “calibrate on open” completely off) eliminated the error. Once the error was eliminated, the camera stream worked properly.

So, we’ve got a workaround, but the root cause is still a bit of a mystery.

1 Like