Page 1 of 3
NXC: faulty SENSOR_TYPE_CUSTOM ?
Posted: 26 Feb 2011, 15:29
by 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?
Re: NXC: faulty SENSOR_TYPE_CUSTOM ?
Posted: 28 Feb 2011, 09:39
by 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
Re: NXC: faulty SENSOR_TYPE_CUSTOM ?
Posted: 28 Feb 2011, 10:11
by 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?
Re: NXC: faulty SENSOR_TYPE_CUSTOM ?
Posted: 28 Feb 2011, 10:39
by 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?
Re: NXC: faulty SENSOR_TYPE_CUSTOM ?
Posted: 28 Feb 2011, 10:47
by 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)
Re: NXC: faulty SENSOR_TYPE_CUSTOM ?
Posted: 28 Feb 2011, 11:07
by 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.
Re: NXC: faulty SENSOR_TYPE_CUSTOM ?
Posted: 28 Feb 2011, 11:14
by HaWe
so no setting "SetSensor(S2....)" or "SetSensorType(S2....)" at all??
Re: NXC: faulty SENSOR_TYPE_CUSTOM ?
Posted: 28 Feb 2011, 11:22
by 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.
Re: NXC: faulty SENSOR_TYPE_CUSTOM ?
Posted: 28 Feb 2011, 11:43
by 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)
Re: NXC: faulty SENSOR_TYPE_CUSTOM ?
Posted: 28 Feb 2011, 18:43
by 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);
}
}