From linear to exponential PWM output

Hi Mitch,

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.

Cheers, Paco

Now I like to make this output not linear but exponential

Calculate the mapping offline and load the value in a table into your code. Much faster than any calculation you can find any mcu.

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.

Dhenry

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. :frowning:

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.

Cheers, Paco

Mitch,

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);

and always starts from the XY Value point set.

Paco

Can you post the output of the function?
What are the values used in the function??

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.

Paco

try this variation of the code

void fillLookupTable()
{
  speedstartValueold = speedstartValue; 
  switchpointXValueold = switchpointXValue; 
  switchpointYValueold = switchpointYValue;
 
  switchpointXValue = constrain (switchpointXValue,deadbandXvalue, 255);
  switchpointYValue = constrain(switchpointYValue,speedstartValue, 255);
  
  Serial.print("B,"); 
  Serial.println(speedstartValue);
  Serial.print("C,");
  Serial.println(switchpointXValue);
  Serial.print("D,");
  Serial.println(switchpointYValue);
  Serial.println(deadbandXvalue);

  for (int i = 0; i < deadbandXvalue; i++) 
      lookupTable[i] = 0;

  for (int i = deadbandXvalue; i < switchpointXValue; i++)  
      lookupTable[i] = map(i, 0, switchpointXValue, speedstartValue, switchpointYValue);

  for (int i = switchpointXValue; i < 256; i++)  
      lookupTable[i] =  map(i, switchpointXValue, 255, switchpointYValue, 255 );  
     
    streamUp();
}

makes the code a bit more straightforward, as it has clearly 3 parts

What is the output of above function? as expected?

Hi Rob,

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?

Paco

Thanks to Rob the problem is solved.

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  +++++++

here the correct code.

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):

0
0
31
50
63
74
82
89
95
101
105
110
114
118
121
124
127
130
133
135
137
140
142
144
146
148
149
151
153
154
156
158
159
160
162
163
164
166
167
168
169
170
172
173
174
175
176
177
178
179
180
180
181
182
183
184
185
186
186
187
188
189
189
190
191
192
192
193
194
194
195
196
196
197
198
198
199
199
200
201
201
202
202
203
203
204
204
205
206
206
207
207
208
208
209
209
210
210
210
211
211
212
212
213
213
214
214
215
215
215
216
216
217
217
217
218
218
219
219
219
220
220
221
221
221
222
222
222
223
223
223
224
224
225
225
225
226
226
226
227
227
227
228
228
228
229
229
229
229
230
230
230
231
231
231
232
232
232
232
233
233
233
234
234
234
234
235
235
235
236
236
236
236
237
237
237
237
238
238
238
238
239
239
239
239
240
240
240
240
241
241
241
241
242
242
242
242
243
243
243
243
244
244
244
244
244
245
245
245
245
246
246
246
246
246
247
247
247
247
247
248
248
248
248
249
249
249
249
249
250
250
250
250
250
251
251
251
251
251
252
252
252
252
252
252
253
253
253
253
253
254
254
254
254
254
255

Dhenry,

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...........? :slight_smile:

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.........

Thanks, Paco

slotracecontroller_305_ino.zip (6.39 KB)

The lookuptable is filled with data in a seperate function.

Unless you have a mcu with lots of ram, that would be the wrong thing to do.

Dhenry,

Currently use a Mega so enough Ram or am I mistaken.
An UNO or Nano would be on the edge of Free ram.

Paco

It uses at least 256 bytes of ram, as coded.

It may not be an issue for your platform but in general, you want to store constant data in the rom.

You mean to write the lookuptable data everytime it changes in the EEProm and read it from there instead of the lookuptable using sRAM?

Paco

You can use PROGMEM - to put the table in ROM - see reference section.

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.

Paco

you are right, if the LUT changes runtime you cannot use PROGMEM.