Strange arithmetic problem

[Ingo]

I cannot figure out why I get different results for an arithmetic function from PICED and a PAC. Below is what I am trying to achieve.

LightLevelRear : Real;

if GetUnitParamStatus("Local Network", 16, ptLightLevel) then
begin
LightLevelRear := GetUnitParameter("Local Network", 16, ptLightLevel) / 13.2; { Get Light level in approximate CBUS level }
SetLightingLevel("Group 245 - LightLevel - Rear", Round(LightLevelRear), "0s");
Delay("00:02:10");
end;

What the above is supposed to do is take the Lux reading from the LightLevel meter, convert it to a CBus level of between 0 and 255. My max light level is 3370 and my minimum is 25. If I run through the arithmetic manually I get 255.3 as max and 1.9 as minimum.

Now, when I use the Round() function to populate Group 245 it ends up as either 255, for Max, and 2, for Min, which is absulutely what I intend.

When I download this code to the PAC it gives me 250 as max and not 255. As soon as I run PICED in simulation mode and run the logic code ONCE it changes Group 245 from 250 to 255. After a short while the PAC updates the counter back down to 250.

I have fried my brain trying to figure this out, and I will feel pretty stupid if I missed something, but why is this behaviour different between the two units?

Ingo

[Mark]

Hi Ingo,

I suspect the problem is with the range of Light Level values. PICED runs on a machine with grunt, so it can do an accurate floating point calculation of the light level. PAC has limited resources, so it uses a look up table and a multiplier to approximate the same calculation.
Exactly how the Light Level is calculated depends on the sensor you are using (SENLL or Multisensor), so if you let me know which you are using i can give more details. Otherwise, just check the max value you actually get in the PAC and adjust your calculations accordingly.

Sorry for the troubles!
Mark.

[Ingo]

Hi mark,

I am using a SENLL. I'll relook at my calculations but I get 3370 from PICED and if I reverse the calculation and work out what the PAC must give me then it will be 3300. Is that possible??

PICED: 3370 / 13.2 = ~255 and in reverse for the PAC:
PAC: 250 * 13.2 = 3300.

If this is actually true then why would the PAC report 3300 on Max light if PICED reports 3370?

Ingo

[NickD]

If this is actually true then why would the PAC report 3300 on Max light if PICED reports 3370?


The error is in the conversion of the (8 bit) reading from the light level sensor into lux.

The conversion involves a calculation of e^n (where e is the natural logarithm)... PICED is running on a PC and does this properly using it's big grunty processor and math libraries. The PAC's much more modest processor uses an integer lookup table which has some rounding errors.

Nick

[Ingo]

Ok, I understand. So for me to 'correct' this problem I should assume the PAC will always return 250 and adjust my calculations from there. 3300 is close enough to 3370 anyways.

Ingo