View Single Post
  #156   Spotlight this post!  
Unread 17-02-2015, 12:18
Thad House Thad House is online now
Volunteer, WPILib Contributor
no team (Waiting for 2021)
Team Role: Mentor
 
Join Date: Feb 2011
Rookie Year: 2010
Location: Thousand Oaks, California
Posts: 1,106
Thad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond repute
Re: ANNOUNCING: navX MXP Robotics Navigation Sensor

Quote:
Originally Posted by slibert View Post
Fascinating. Congratulations on some nice sleuthing...

Our LabView SPI longevity test has run 16 hours now w/no problems - glad there's an edge case identified we can chase down.

Using the RoboRio Brownout and Understanding Current Draw article as a reference, there are three stages of RoboRio brownout. Do you know which stage was reached in the case you've reproduced? It'd be interesting to know if Stage 2 (which would remove the power from the MXP 5V rail) was hit or not.

Also, could you please post the driver station logs that document the case when this occurs? That should help clarify the details of the scenario. The goal is to try to reproduce this behavior with a benchtop power supply, so the more info on the dynamics, the better. Once reproduced, we can run through various configurations and characterize the behavior more thoroughly.
I will check to see how low the battery voltage was getting when this was happening. I will also get the driver station logs later today. It seems like the NaVX is rebooting, because when we do the RoboRIO code restart, if we do it within 16 seconds, the navx reports its in calibration mode, just like it does on startup.

Note that this for us was not just limited to SPI. I2C had the same issue, but it happened earlier. I would guess that when it happened on I2C, it was because the pullups were being forced high by stage 1. I don't know if SPI has that same issue, but the issue seemed to happen with a much lower battery on SPI then I2C.
__________________
All statements made are my own and not the feelings of any of my affiliated teams.
Teams 1510 and 2898 - Student 2010-2012
Team 4488 - Mentor 2013-2016
Co-developer of RobotDotNet, a .NET port of the WPILib.
Reply With Quote