LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Vehicle Accelerator Pedal serial pulse output value

If you can get clean measurements (i.e. get accurate estimates of the time, probably to the nearest microsecond, of the rising and falling pulse edges (which means that you need to have pulses, square-looking things, not "triangular" waveforms that you illustrated), you may be able to deduce (a.k.a. "guess") the algorithm.  I would not be surprised if the "pre-pulse" (which I think serves as a "Here it Comes!" signal) doesn't carry with it the time standard.

 

Bob Schor

Message 11 of 16
(1,338 Views)

Thanks! Not sure about the condition of the pulse. Definitely not a square wave. However I'm measuring the output directly from the accelerator pedal output pin with a Tektronix TDS 744A oscilloscope attached through a 1X 1Mohm 105pf Tektonix probe. Not that the probe seems to matter. I get the same signal shape with a direct input to the scope and with a direct input to a NI cDAQ 9205 module in a cDAQ-9132. If I switch the probe input to 10X 10 meg-ohm 14pf the signal is attenuated but the shape is the same. I'm wondering if the signal is actually inverted? or without inverting, it appears that you can accurately measure the pulse width if you were to expand the time domain.

0 Kudos
Message 12 of 16
(1,335 Views)

The only problem of measuring pulse width is if you have "sloping sides", as you need to decide where the value changes from 0 to 1.  If the pulse is "relatively square", and if 5V is High, 0V is low, then most digital input circuits will register "1" when the voltage is, say, >3V, 0 if it is <2V, and won't change if it is between 2 and 3 (the numbers vary with implementation, but there is usually a "grey zone" in the middle).  If your input device has a Digital I/O port and you can take sufficiently fast measurements, you might try to determine the time of rising and falling edges (you know how to make a sub-VI that returns True if you feed it a Rising Edge, don't you?  With this, you can easily make two arrays, one with the elapsed Tick Times for Rising Edges, one for Falling Edges, then take a look and see if you can deduce something useful from the numbers).

Suppose you got the following times between Rising Edges (in "time units") -- 1000, 100, 103, 104, 102, 114, 106, 110, 105, 1000, ...  You might say "I see a pattern of a long pulse and 8 shorter pulses.  I'm going to guess that the Long Pulse is the "Start" Pulse, and the 8 bits of data are contained in the intervals of the shorter pulses.  Let's make some guesses and see if they make sense ..."

 

Good Luck.  Keep us posted.

 

Bob Schor

0 Kudos
Message 13 of 16
(1,315 Views)
I will follow your advice! And I will keep you guys posted! It will be awhile, this is one of my many high priority projects! 🙄Thanks again, so much, for all your help!
0 Kudos
Message 14 of 16
(1,310 Views)

 I was able to find quite a bit of information on the SENT protocol. And, I was able to transfer the duration of the pulse information into values. However, I could not, with confidence, make sense out of the results:

The data values for idle in HEX: x01, x03, x03 or binary: 0001 0011 0011, or decimal: 307

The data values for WOT in HEX: .x04, x06, x05 or binary: 0100 0110 0101, or decimal: 1125

 It appears I'll need the spec from the manufacturer of the pedal to determine the output values. Or is there some common spec for accelerator pedals? I'm going to post a question for the National Instruments - SENT Driver API to find out how it knows the spec of the SENT transmission it reads. 

Please refer to attachments.

 

0 Kudos
Message 15 of 16
(1,276 Views)

I discovered there is an explanation about the workings of the SENT Driver API and it appears that the output is merely the pulse duration of the various nibbles. No actual data values!

0 Kudos
Message 16 of 16
(1,270 Views)