Your correct the X was wrong and it should be i but the result is was not as expected.
If i correct the X for i then after the switch point the line goes straigth roof high. See screenshot.
In the case I use the other line without the curve it is nice and straigth.
However in both cases when I use the lookuptable we never start at the startspeed value but always higher as soon as the trigger leaves the deadband zone.
If I do not use the lookptable we nicely start at the startspeed point.
Any thoughts about this all?
As you can see the graphing at the PC is working now as intended.
As soon as on the controller we change either startspeed or X or Y point up or down this is shown in the graph so we know what we are doing.
backbone:
If i correct the X for i then after the switch point the line goes straigth roof high. See screenshot.
If you're trying to store a curve in the array, why don't you just calculate the values you want and put them in a static initialiser?
If you're trying to approximate the curve with three straight lines then I don't see the benefit of the lookup table - you might just as well do a range check, scale and offset. If execution time is critical then you could implement that logic during setup and cache the result, but I'd still calculate it doing three linear transforms rather than trying to write it as a single expression. But the circumstances where it's sensible to pre-calculate a linear transform are pretty unusual imo.
Do not fully understand what you mean with Offline calculation of the mapping.
PeterH
This whole slotrace controller project is not standard so we try the things step by step.
Currently all controllers that have an exponential curve just run from the startspeed point to full speed.
For those just stepping in and try to help.
With the selectable XY switchpoint we try to be different and this has not been tried or tested before.
Now for this step in the project we like only to curve the last straight line by changing a curve value.
1 is a straight line and 3 a full curve.
We have to test if good slot race drivers can benefit from this last line to be linear or to be curved.
Also even if the lines are linear we not yet tested with drivers if this would be enough and the curving is not needed at all.
But I like to have it already and then test drive all possible options at one day to have comprehensive comparising with same drives and track conditions.
All settings to XY and curve value need to be changeable while the controller is plugged in and in use.
This is where the project currently stands and we are not ready yet.
I am eager to learn but my level of programming and mathematics in not at the same level you guys are.
Your given options are acabadabra to me so I cant say if this or that would be better or give an other result that is desired.
Can you chime in?.
SpeedfinaleValue never starts at speedstartValue when the lookuptable is used.
VB nicely shows the lookuptable is filled with correct values.
If startspeed is 100 and Y value is 175 as soon as the trigger leaves deadband zone it jumps to 183 instead of 101.
Looks like it does not use the first part of the line from startspeed to XY point.
void fillLookupTable()
{
speedstartValueold = speedstartValue;
switchpointXValueold = switchpointXValue;
switchpointYValueold = switchpointYValue;
Serial.print("B,");
Serial.println(speedstartValue);
Serial.print("C,");
Serial.println(switchpointXValue);
Serial.print("D,");
Serial.println(switchpointYValue);
switchpointXValue = constrain (switchpointXValue,deadbandXvalue, 255);
switchpointYValue = constrain(switchpointYValue,speedstartValue, 255);
for (int i=0; i<256; i++)
if (i < deadbandXvalue)
{
lookupTable[i] = 0;
}
else
//++ knicked powerline at X and Y value ++ SETTING
if (i < switchpointXValue)
lookupTable[i] = map(i, 0, switchpointXValue, speedstartValue, switchpointYValue);
else
lookupTable[i] = map(i, switchpointXValue, 255, switchpointYValue, 255 ); // this could get replaced by a curve after all is working
streamUp();
}
It looks as it does not use the lookupTable[i] = map(i, 0, switchpointXValue, speedstartValue, switchpointYValue);
Rob the output of the function I read too into the VB application for displaying where the immidiate screen nicely show the lookuptable values to be correct and start at 104 and go upto 255.
See the screenshot.
Output is the same.
The lookuptable is filled correctly again.
I checked with Serial.print and the first speed value outside deadbandXValue is 104.
in the Void loop this where the speed values which use the lookuptable are coming from.
// +++++++++++++++ regular speed - brake mode +++++++++++++++
sensorRawValue = analogRead(sensorspeedPin); // read the raw value from the linear hall sensor
sensorRawValue = constrain(sensorRawValue, sensorMin, sensorMax); // constrain the maximum value to 255
sensorValue = map(sensorRawValue, sensorMin, sensorMax, 0, 255); // map the calibration to the sensor reading from the hall sensor
sensormappedValue = map(sensorValue, deadbandXvalue, 255, speedstartValue, 255); // full linear control mapped with startspeed
// ++++ curve section +++++++
//speedfinalValue = sensormappedValue;
speedfinalValue = lookupTable[sensormappedValue];
// ++++ curve section +++++++
Codewise the speedfinalValue clearly looks into the sensormappedValue or am I mistaken?
By removing one line and chaning one variable inside the lookuptable.
here the correct code.
// +++++++++++++++ regular speed - brake mode +++++++++++++++
sensorRawValue = analogRead(sensorspeedPin); // read the raw value from the linear hall sensor
sensorRawValue = constrain(sensorRawValue, sensorMin, sensorMax); // constrain the maximum value to 255
sensorValue = map(sensorRawValue, sensorMin, sensorMax, 0, 255); // map the calibration to the sensor reading from the hall sensor
// ++++ curve section +++++++
speedfinalValue = lookupTable[sensorValue];
// ++++ curve section +++++++
That's very redundant. Your problem really is to map a [0..255] value to [0..255] logarithmically. If you need speed, you calculate the logarithmic transformation offline and store that results in a lookup table.
So something like this would be much faster / simpler:
// ++++ curve section +++++++
speedfinalValue = lookupTable[analogReed(sensorspeedPin) >> 2]; //read the sensor and return the highest 8 bits.
// ++++ curve section +++++++
lookupTable[] is also very easy to calculate: for sensor value 0..255, you want the lookupTable to return (255/log(255)) * log(sensor value), other than for sensor value 0, the lookupTable should return 0.
So the table should look like this (using natural base, not 10 base):
Thanks for your explanation.
We already use offline lookuptable filling.
The lookuptable is filled with data in a seperate function. "void fillLookupTable"
See the code in the response 120 from Rob.
I will post the full code as attachment now too.
Rob also said he liked to view the whole code.
Problem is it is so large now to place here in code tags.
Threrefor the snippets are less confusing...........?
So I attach the last code I have as zip.
It is dirty as you can get from a low level programmer like me.
Could be faster in the end.........
Rob, I read progmem reference but also memory section.
You mean to BURN the table in the flashrom?
What I understand this will only work if you have only one curve to use.
If that is the case it will not work?
During use of the controller the lookuptable will change by changing startspeed, X and Y pointvalue and if we use an real exponential curve the curveValue.