I have a Race Capture Pro2 and I want to use the Pulse/analog output to sent a GPS based speed signal to my ECU.
The application is offraod rallying where we have a speed limits that we can set into the ECU system. The speed signal has to be very accurate and fast responding as we get a penalty if we go over 2Kmh speedlimit.
Can this be done and how to do this?
GPS based speed signal output frequency/analog based
GPS based speed signal output frequency/analog based
Last edited by tall boy on Sun Mar 22, 2015 8:31 am, edited 1 time in total.
Yes I can configure the ECU how I want as I’m writing the control strategy my self so I can calibrate to tago output or GPS navigation but a like to us one of the 4 ECU speed inputs working on frequency as I only got one channels left from the 16 analog ones on the ECU and any ground reference change will be resulting an a speed deviation and 2 x over speeding means exit rally or race. Main worry is temperature change as the data logger can hot @ >70 degrees centigrade….. so PWM/Hz will eliminate analog drifting of 0-5V DC output/ECU input.
Also when the GPS signal is not healthy I need a zero so the ECU knows and will use the last GPS to wheel speed calibration while driving
The speed limit is set to 150Kph for off road and 170Kph race.
On offroad we have 4 speed limits 30 50 90 140 so I need a lager range on things.
For race we only looking a 150 to 170Kph.
Also when the GPS signal is not healthy I need a zero so the ECU knows and will use the last GPS to wheel speed calibration while driving
The speed limit is set to 150Kph for off road and 170Kph race.
On offroad we have 4 speed limits 30 50 90 140 so I need a lager range on things.
For race we only looking a 150 to 170Kph.
Hi, I think this is the script we were helping you with, so other people can see the answer:
Note, the minimum settable PWM clock frequency is 320Hz.
[pre]
function onTick()
local s = getGpsSpeed() --lees gps snelheid
local p = 12 --puls per km/u
s = s*p --gps snelheid maal puls per km/u
setPwmClockFreq( s ) --output snelheidsfrequentie
setPwmDutyCycle(0,50) --zet dutycycle op 50%
end
[/pre]
Note, the minimum settable PWM clock frequency is 320Hz.
[pre]
function onTick()
local s = getGpsSpeed() --lees gps snelheid
local p = 12 --puls per km/u
s = s*p --gps snelheid maal puls per km/u
setPwmClockFreq( s ) --output snelheidsfrequentie
setPwmDutyCycle(0,50) --zet dutycycle op 50%
end
[/pre]
Thanks for the script it’s working and for testing I chance it to an RPM channel.
The PWM/Hz output is very slow in response as my data log form the ECU shows Kph steps and I set the sample rate from 1Hz to 100Hz and this makes no change on the PWM output.
I need to have over 10Hz to get this working and 250 to 300Hz is what we normally use so is there way to get the output faster to respond?
Also can you give me an example on how to set-up this function with a 0-5V DC analog output speed based?
The PWM/Hz output is very slow in response as my data log form the ECU shows Kph steps and I set the sample rate from 1Hz to 100Hz and this makes no change on the PWM output.
I need to have over 10Hz to get this working and 250 to 300Hz is what we normally use so is there way to get the output faster to respond?
Also can you give me an example on how to set-up this function with a 0-5V DC analog output speed based?
Hello,
for increasing the responsiveness of the script, you can update the frequency of the onTick() function by placing the following at the top of the script:
setTickRate(10)
http://autosportlabs.net/RaceCapturePro ... .28rate.29
We will have support for switching between Metric / KPH in a near future firmware and app release. Thanks!
for increasing the responsiveness of the script, you can update the frequency of the onTick() function by placing the following at the top of the script:
setTickRate(10)
http://autosportlabs.net/RaceCapturePro ... .28rate.29
We will have support for switching between Metric / KPH in a near future firmware and app release. Thanks!
Test with PWM/Hz output. As you can see the speed signal is freaking out @ low speed.
Last test on GPS with an analogue output. Output is jumping. 0-5V is not a lot of resolution. Would suggest taking 0-5000 point to set an output of 0-5V
setTickRate(10)
function onTick()
local s = getGpsSpeed(0) --lees gps snelheid
local p = 0.01 --vermenigvuldigingsfactor
s = s*p --gps voltage per km/u
setAnalogOut( 1,s )
end
Last test on GPS with an analogue output. Output is jumping. 0-5V is not a lot of resolution. Would suggest taking 0-5000 point to set an output of 0-5V
setTickRate(10)
function onTick()
local s = getGpsSpeed(0) --lees gps snelheid
local p = 0.01 --vermenigvuldigingsfactor
s = s*p --gps voltage per km/u
setAnalogOut( 1,s )
end
Some more feedback on reading GPS speed.
Running 50Hz sampling on GPS dos not provide a good speed signal but why? Here is how this happens. The GPS antenna also travels in more than one direction as the vehicle dos not travel on even ground so for off road you need to go back to 10Hz and on some circuits we can run 20Hz but we have dropouts on GPS signal mostly in industrial areas and on low speed you notice this as we use it for max speed governing.
If the need for a hi sample rate on speed is there a fair bit of programming is needed as of incorporating the gyro and G force sensor into the speed calculation making it into a so called speedpot able to calculate speed very accurate and able to maintain speed calculation for a short time even when GPS fix is lost for a short time.
getGpsQuality() yes it works getting the GPS fix up but dos not want to come down easy as you see the NR of satellite drop to a point a GPS fix is not there but the datalogger dos not drop from a 3 status to zero. Also getting a GPS fix takes more time than all other GPS devices we use but maybe things improved on the later versions of firmware?
Running 50Hz sampling on GPS dos not provide a good speed signal but why? Here is how this happens. The GPS antenna also travels in more than one direction as the vehicle dos not travel on even ground so for off road you need to go back to 10Hz and on some circuits we can run 20Hz but we have dropouts on GPS signal mostly in industrial areas and on low speed you notice this as we use it for max speed governing.
If the need for a hi sample rate on speed is there a fair bit of programming is needed as of incorporating the gyro and G force sensor into the speed calculation making it into a so called speedpot able to calculate speed very accurate and able to maintain speed calculation for a short time even when GPS fix is lost for a short time.
getGpsQuality() yes it works getting the GPS fix up but dos not want to come down easy as you see the NR of satellite drop to a point a GPS fix is not there but the datalogger dos not drop from a 3 status to zero. Also getting a GPS fix takes more time than all other GPS devices we use but maybe things improved on the later versions of firmware?