DriverStation::GetAnalogIn - what range?

From the C++ reference manual:
DriverStation::GetAnalogIn returns the analog voltage on the input. The analog values are returned as UINT32 values…

Let’s keep it simple, ignoring noise:

  1. when an analog input is at ground, what value is returned?
  2. when an analog input is at +5V, what value is returned?

The Driver Station has a 10 bit ADC. This means that the possible range of values is from 0 to (2^10)-1, or 0 to 1023.

I just looked at the source code for the DriverStation, and I’m actually a little confused about it. FRCComm.h describes the analog inputs like this:

struct FRCControlData{
	//Analog inputs are 10 bit right-justified
	UINT16 analog1;
	UINT16 analog2;
	UINT16 analog3;
	UINT16 analog4;

That makes sense. However, DriverStation::GetAnalogIn() looks like this:

 * Get an analog voltage from the Driver Station.
 * The analog values are returned as UINT32 values for the Driver Station analog inputs.
 * These inputs are typically used for advanced operator interfaces consisting of potentiometers
 * or resistor networks representing values on a rotary switch.
 * @param channel The analog input channel on the driver station to read from. Valid range is 1 - 4.
 * @return The analog voltage on the input.
float DriverStation::GetAnalogIn(UINT32 channel)
	wpi_assert ((channel >= 1) && (channel <= 4));
	switch (channel)
	case 1:
		return m_controlData->analog1;
	case 2:
		return m_controlData->analog2;
	case 3:
		return m_controlData->analog3;
	case 4:
		return m_controlData->analog4;
	return 0;

Why does the documentation say the values are returned as a UINT32, yet the function returns a float? Also, as seen in FRCComm.h, the control data actually represents these inputs as 16-bit integers. Note that m_controlData is of type FRCControlData, meaning that analog1…4 are all UINT16 values. Perhaps this was an oversight.

The @return comment implies that it returns the actual voltage on the analog port – but how does it do this? It doesn’t look right to me, and could be an oversight by the WPI Library developers. If it’s not, perhaps someone else could help explain this…

For reference, I’ve posted about this on the official FRC Control System forum here:



We are using these with version WPILib 3.0, and have tested and used on our production bot.

Not that this is the intended behavior, but that is what it returns.