NXC: faulty SENSOR_TYPE_CUSTOM ?

[HaWe]

Code: Select all

SetSensorType(S2, SENSOR_TYPE_CUSTOM);
SetSensorMode(S2, SENSOR_MODE_RAW);

gives with analog sensors no readings! what's wrong with this?

Is there a different "unfaked analog standard sensor / sensor type" by NXC?

[afanofosc]

The firmware uses this code for custom sensors:

Code: Select all

      cInputSetupCustomSensor(No);
      dInputRead0(No, &(IOMapInput.Inputs[No].DigiPinsIn));
      dInputRead1(No, &(IOMapInput.Inputs[No].DigiPinsIn));

      dInputGetRawAd(&InputVal, No);
      IOMapInput.Inputs[No].ADRaw = InputVal;
      cInputCalcFullScale(&InputVal, IOMapInput.Inputs[No].CustomZeroOffset, IOMapInput.Inputs[No].CustomPctFullScale, FALSE);
      cInputCalcSensorValue(  InputVal,
                            &(IOMapInput.Inputs[No].SensorRaw),
                            &(IOMapInput.Inputs[No].SensorValue),
                            &(IOMapInput.Inputs[No].SensorBoolean),
                            &(VarsInput.InputDebounce[No]),
                            &(VarsInput.SampleCnt[No]),
                            &(VarsInput.LastAngle[No]),
                            &(VarsInput.EdgeCnt[No]),
                            ((IOMapInput.Inputs[No].SensorMode) & SLOPEMASK),
                            ((IOMapInput.Inputs[No].SensorMode) & MODEMASK));

The dInputGetRawAD call is this code:

Code: Select all

#define   INPUTGetVal(pValues, No)      *pValues  = (UWORD)IoFromAvr.AdValue[No];     \
                                        *pValues &= 0x03FF

As far as I can see (without more digging) the ADRaw value in the input module IOMap is not massaged at all (other than AND-ing it with 0x03FF). The ADRaw field of the input module IOMap is what you get when you use the SensorRaw or SensorValueRaw API functions. When you use the Sensor function or SENSOR_1..SENSOR_4 or SensorValue function or SensorScaled function you get the SensorValue field aka ScaledValue. When you use the SensorNormalized function you get the SensorRaw field aka NormalizedValue.

The cInputCalcSensorValue function uses the adjusted AD value output by cInputCalcFullScale along with the sensor type and mode on input to calculate all the other values.

Even if your configured mode is not RAW you can still read the unmassaged ADRaw value for any analog device via the SensorRaw API function.

John Hansen

[HaWe]

thanks for your reply - although I must admit that I don't understand a word of the firmware constants or calculations.
But if I understand you correctly, this should work:

Code: Select all

SetSensorType(S2, SENSOR_TYPE_CUSTOM);
SetSensorMode(S2, SENSOR_MODE_RAW);
int val=SensorRaw(S2)

What about another way for defining a well-working standard analog sensor (~type) in order to read unfaked raw values?

[mattallen37]

I think that what John is saying, is that you don't need to set the sensor mode in order to read the RAW value with the SensorRaw function. In fact, I don't know if you even need to set the type in order to read the true ADC value. Why do you need another way of doing it? Isn't one (perfectly fine) way enough?

John, at times I like to be able to use a port as an I2C master, and sometimes as an analog sensor (read the ADC) in the same program. What I have been doing, is making a loop and setting it up as a touch and raw port, reading the ADC, and then setting it to lowspeed again to use I2C. This works, but it is a little slow, and I would like to be able to read the ADC when the port is in lowspeed mode. Is it possible to use the SensorRaw function even when the port is configured as lowspeed?

[HaWe]

Matt, please let's not get OT.

John, what do you mean then - how should I define a standard analog type and mode if TYPE_CUSTOM is falulty?
Please give me a code example.

(Recalling that TOUCH reads other way round from 1023...0 than analog like light and sound from 0...1023 - it should be the way like other analog sensors work and read raw values)

[mattallen37]

Sorry, but in my mind, it isn't really OT at all. If John answers my question with "Yes", that means that you most likely don't need the sensor port set to any specific type or mode to read the true RAW ADC value.

Just use the SensorRaw function to get true, unscaled, uncooked RAW vlaues.

In any true RAW mode, is should read 1023 if nothing is connected (due to the 10k pullup). Pulling it down (dividing the voltage) with a switch or other sensor (like a phototransistor), should then give a lower reading. The more conductive the pulldown sensor or material, the lower the voltage, and therefore the lower the ADC value.

If a specific sensor type reads 0 (when configured as RAW) when nothing is connected, then it is obviously messed with. However, using the SensorRaw function, it shouldn't matter the type or mode, it should just give you the true RAW value.

[HaWe]

so no setting "SetSensor(S2....)" or "SetSensorType(S2....)" at all??

[mattallen37]

Well, that is basically what I was asking John. I don't thing you need to, but it wouldn't hurt to set it up as some analog sensor, just to be sure. It does't matter if it is light, touch, or any other non-active analog type (don't use RCX light or rotation types). The type (if necessary to set) should be totally irrelevant; you will still get the true ADC value using SensorRaw, regardless of the type.

[HaWe]

ok, then I will try using Sound.
And I apologize, I didn't understand that that's the point you've been asking for (as far as I could translate your post I read it was about I2C)

[HaWe]

hi,
indeed, that's really odd:
In the test program I'm reading "raw" values in both cases from sound sensors,

S1 configured as: SetSensorType(S1, SENSOR_TYPE_SOUND_DBA); SetSensorMode(S1, SENSOR_MODE_RAW); val1 = SensorValue(S1);
S2 configured as: SetSensor(S2, SENSOR_SOUND); val2 = SensorRaw(S2);

attaching the sound sensor:
S1 shows (quiet) 13 ->->-> (loud) 1023
S2 shows (quiet) 988 ->->-> (loud) 263

taking touch sensors instead:
S1 shows (released) 0 -> -> -> (pressed) 999
S2 shows (released) 1023->->-> (pressed) 186

What the hell did the Lego people think when they established (at least) 2 completely different inverse "raw" measuring results for one and the same single sensor ?!?

Code: Select all

#define printf1( _x, _y, _format1, _value1) { \
string sval1 = FormatNum(_format1, _value1); \
TextOut(_x, _y, sval1); \
}
int val1, val2;

task main(){
  SetSensorType(S1, SENSOR_TYPE_SOUND_DBA);
  SetSensorMode(S1, SENSOR_MODE_RAW);

  SetSensor(S2, SENSOR_SOUND);

  while(true) {
     val1 = SensorValue(S1);
     val2 = SensorRaw(S2);
     

     printf1(0, LCD_LINE1, "%5d", val1);
     printf1(0, LCD_LINE2, "%5d", val2);

     Wait(10);
  }
}