Questions about various lap time values and sending over CAN

[thoraxe]

I have a RCP/MK2 integrated with an AEM CD-7. I have two routes I can go

1) The AEM dash can calculate all of the timing stuff on its own via GPS data. I can simulate AEM's GPS unit (already partially done -- https://gist.github.com/thoraxe/37b7e3c ... lua-L3-L67 ) but I have to add "course" which I think is really just direction. Need to check with them

2) I can use the RCP lap data and send it over CAN and then display it on the CD-7. While this is easier, the CD-7 supports more lap functions than the RCP.

https://wiki.autosportlabs.com/RaceCapt ... Statistics

Here are the RCP lap functions:
4.7.1 getLapCount()
4.7.2 getLapTime()
4.7.3 getPredTime()
4.7.4 getAtStartFinish()
4.7.5 resetLapStats()

Here's what the dash supports:
* previous lap time
* predicted lap time
* lap count
* fastest lap time
* current running lap time (elapsed time in the present lap)
* last lap's delta against fastest lap
* +/- prediction bar

It looks like some of these align with existing functions, but some do not. All would need to be sent over CAN. The question is whether or not it makes sense to just calculate the current course/heading (to use the built-in AEM functions) or to do it via the RCP (which will require a lot more scripting).

Let's go through the above:

previous lap time
getLapTime()

predicted lap time
getPredTime()

lap count
getLapCount()

That's it for the builtins...

fastest lap time
RCP doesn't calculate this according to the Lua guide. So a variable would need to be created and then a small scriptlet (is getLapTime() < fastest_lap_var) to maintain this value

current running lap time (elapsed time in the present lap)
this one seems like it'd be complex. you'd have to use getAtStartFinish() as a conditional to then mark the current time in terms of when the start/finish was crossed (and hope that you actually caught the start/finish) and then you'd have to calculate the elapsed lap time from the start/finish time.

197MPH (theoretical gearing top speed of my car - never gonna happen) rounded up to 200MPH is 293ft/s. At a tick rate of 20 (20 samples per second) that means the vehicle moves ~15ft per tick. What is the "window" through which getAtStartFinish is calculated? Would this require a higher tick?

Last lap's delta against fastest lap
Once you have fastest lap you can calculate this

* +/- prediction bar
Once you have the fastest lap you could do math against the predicted lap to calculate a delta for this

Is it worth it to write all these scripts/calculations?

[thoraxe]

Building on my own question, here's the AEMnet CAN protocol document:

https://www.aemelectronics.com/files/pd ... Public.pdf

GPS_Course is a 16-bit unsigned integer whose value represents 0.01deg/bit

That being said, I'm not sure if I need to be sending these values in the raw format AEM expects the VDM to output or not.

So, the real question here is to calculate the direction of travel of the vehicle as far as the RCP is concerned, but then that likely needs to be "converted" into whatever the AEM dash is expecting. For example, I don't know if those degrees are calculated in reference to true north or in reference to the orientation of the device or what. Gotta wait for a response from AEM on that.

[thoraxe]

Still waiting for answers to some of my questions. I can use defined track start/stop points on my street to make a hillclimb-type course (Different start/finish) but I have no idea how or even if that will work for predictive timing -- it would require that the RCP remember time across power cycles...

Code: Select all

function sendLapData()
  -- build lap data
  local lapcount = getLapCount()
  local lastlap = getLapTime()
  local predlap = getPredTime()

  -- calculate if last lap is better than best lap
  if lastlap < bestlap then
    bestlap = lastlap
  end

  -- delta between predlap and bestlap in seconds
  local lapdelta = bestlap - predlap

  -- current elapsed lap time in miliseconds
  local elapsedtime = getUptime&#40;&#41; - lapstarttime

  -- scale values by 1000 to make integers, scale down in AEM CD-7
  local lastscale1,lastscale2 = split16&#40;lastlap * 1000&#41;
  local predscale1,predscale2 = split16&#40;predlap * 1000&#41;
  local bestscale1,bestscale2 = split16&#40;bestlap * 1000&#41;
  local deltascale1,deltascale2 = split16&#40;lapdelta * 1000&#41;
  local elapsed1,elapsed2 = split16&#40;elapsedtime&#41;

  -- send data
  sendcan&#40;2, 1430, &#123;lastscale1, lastscale2, predscale1, predscale2, bestscale1, bestscale2, deltascale1, deltascale2&#125;&#41;
  sendcan&#40;2, 1431, &#123;lapcount, elapsed1, elapsed2&#125;&#41;
end

bestlap = 0
lapstarttime = 0

function onTick&#40;&#41;
  
  -- check whether or not we are moving and then enable logging
  setLogging&#40;&#41;

  -- send GPS data to AEM CD7
  sendGPS&#40;&#41;
  sendImu&#40;&#41;

  -- check if we're at start finish to build lap runtime
  if getAtStartFinish&#40;&#41; then
    -- start time is current time in miliseconds
    lapstarttime = getUptime&#40;&#41;
  end

  -- send the lap data to the AEM CD7
  sendLapData&#40;&#41;

end

Looks better in a gist:
https://gist.github.com/thoraxe/dc2f28d ... 82cc40786b