NXC: faulty SENSOR_TYPE_CUSTOM ?

[afanofosc]

The standard firmware and (currently) the enhanced NBC/NXC firmware do not read the ADRaw value from the AVR unless the sensor type is one of these values:

SENSOR_TYPE_TOUCH
SENSOR_TYPE_TEMPERATURE
SENSOR_TYPE_LIGHT
SENSOR_TYPE_ROTATION
SENSOR_TYPE_LIGHT_ACTIVE
SENSOR_TYPE_LIGHT_INACTIVE
SENSOR_TYPE_SOUND_DB
SENSOR_TYPE_SOUND_DBA
SENSOR_TYPE_CUSTOM

So you have to set the type to one of these values in order to get the ADRaw value out of the input module IOMap structure using the SensorRaw API function. And you have to give the firmware enough time to get the port out of the invalid data state. That's 20ms for normal sensors, 300 ms for the Sound sensor, and 400 ms for the Color sensor.

The SensorValue API function always returns the Scaled value even when you configure the sensor in RAW mode. The firmware massages the resulting value. It should never be used if you want the actual AD raw value. In RAW mode the Scaled value is the Normalized Raw value which is not the raw AD value. The normalized raw value is what comes out of the cInputCalcFullScale function and the way the raw value is massaged by this function depends on the zero offset and the percent full scale values that are sensor-specific.

Code: Select all

void      cInputCalcFullScale(UWORD *pRawVal, UWORD ZeroPointOffset, UBYTE PctFullScale, UBYTE InvStatus)
{
  if (*pRawVal >= ZeroPointOffset)
  {
    *pRawVal -= ZeroPointOffset;
  }
  else
  {
    *pRawVal = 0;
  }

  *pRawVal = (*pRawVal * 100)/PctFullScale;
  if (*pRawVal > SENSOR_RESOLUTION)
  {
    *pRawVal = SENSOR_RESOLUTION;
  }
  if (TRUE == InvStatus)
  {
    *pRawVal = SENSOR_RESOLUTION - *pRawVal;
  }
}

John Hansen

[afanofosc]

BTW, TRUE is passed in to the cInputCalcFullScale function's InvStatus parameter for all the sensor types that use this function except custom. Touch and Temperature types do not massage the raw value via cInputCalcFullScale before calling cInputCalcSensorValue. I would not ever recommend configuring a port that has a touch sensor attached as a sound sensor. There is no good reason at all to do that.

John Hansen

[HaWe]

me buzzing the skull...too many words...to much input...#*?=$&'*'!=%
John, so what do I have to write if I want the one and only real raw AVR A/D value - no matter what's plugged to it?
(and possibly by the fastest reading speed: if possible every 2-4 msec)

Code: Select all

SetSensorType(S1, SENSOR_TYPE_SOUND_DBA);
SetSensorMode(S1, SENSOR_MODE_RAW);
int val = SensorRaw(S1);

yes or no?

[mightor]

The delay is only during initialisation, just add a small wait 20 or so after you configure your sensors. Use the touch or temp sensor as your sensor type to get un-massaged values

It would look something like this:

Code: Select all

SetSensorType(S1, SENSOR_TYPE_TOUCH);
SetSensorMode(S1, SENSOR_MODE_RAW);
Wait(20);  // as per John's instructions
int val = SensorRaw(S1);

This should give you the values that are as uncooked as they're going to get.

- Xander

[HaWe]

thx a lot, that was the information I was looking for.

[mattallen37]

The standard firmware and (currently) the enhanced NBC/NXC firmware do not read the ADRaw value from the AVR unless the sensor type is one of these values:

SENSOR_TYPE_TOUCH
SENSOR_TYPE_TEMPERATURE
SENSOR_TYPE_LIGHT
SENSOR_TYPE_ROTATION
SENSOR_TYPE_LIGHT_ACTIVE
SENSOR_TYPE_LIGHT_INACTIVE
SENSOR_TYPE_SOUND_DB
SENSOR_TYPE_SOUND_DBA
SENSOR_TYPE_CUSTOM

So you have to set the type to one of these values in order to get the ADRaw value out of the input module IOMap structure using the SensorRaw API function. And you have to give the firmware enough time to get the port out of the invalid data state. That's 20ms for normal sensors, 300 ms for the Sound sensor, and 400 ms for the Color sensor...

John Hansen

Ok, thank you. Where in the IOMap is the RAW ADC value for the sensors? Couldn't I just read it myself, directly? Then it shouldn't matter if it is even in highspeed mode, right?

[afanofosc]

What I was trying to say is that the input module code does not bother to populate the ADRaw field in the input module IOMap from the AVR data if you use one of the sensor types that I did not list. So you can't get it period. If it was in the IOMap you could get it via SensorRaw(). I could change this in the enhanced firmware but at the moment it acts just like the standard firmware does.

John Hansen

[HaWe]

thx John,
but I honestly don't understand a single word of what you mean by "does not bother to populate ADRaw field in the input module IOMap from the AVR data if you use one of the sensor types that I did not list. So you can't get it period. If it was in the IOMap you could get it via SensorRaw()". My English simply is far too poor and neither GoogleTranslate nor BabelFish could light up the darkness.
I need(ed) uncorrupted raw data - is it too much to ask for a programming language? Please tell me what I have to do.

ps: And maybe you can tell me why SENSOR_TYPE_CUSTOM doesn't work at all with analog sensors and how it can be made working (in very very very simple words)...?
the Lego firmware is softly killing me... :(

[afanofosc]

Perhaps we can start this thread over? I don't believe that the custom sensor type is faulty. Can you provide me with proof that it is?

You can't read raw AVR AD values when you configure the port as any of these types: SENSOR_TYPE_LOWSPEED, SENSOR_TYPE_LOWSPEED_9V, or SENSOR_TYPE_HIGHSPEED.

John Hansen

[HaWe]

???

I need(ed) uncorrupted raw data - is it too much to ask for a programming language? Please tell me what I have to do.

You can't read raw AVR AD values when you configure the port as any of these types: SENSOR_TYPE_LOWSPEED, SENSOR_TYPE_LOWSPEED_9V, or SENSOR_TYPE_HIGHSPEED.

does the following what I need - read unfaked uncorrupted raw values -

Code: Select all

SetSensorType(S1, SENSOR_TYPE_TOUCH);
SetSensorMode(S1, SENSOR_MODE_RAW);
Wait(20);  // as per John's instructions
int val = SensorRaw(S1);

Just say yes or no.