Erratic RPM, incorrect configuration?

barkerdm · Post by **barkerdm** » Thu Apr 25, 2013 2:40 am

I've also noticed that the pulse per rev adjustment for RPM did not scale the reading accordingly.

Post by **brentp** » Thu Apr 25, 2013 1:34 pm

Noted - I'll provide an update with our finding here as well. I'm sure there's a firmware update coming soon

GTIspirit · Post by **GTIspirit** » Sun Apr 28, 2013 7:59 pm

So I changed the signal input to use the blue trace in my scope picture above. No go, reads a constant 997rm, even when I revved it up to 2000rpm. I'm really surprised that not even the blue trace can be read as a valid rpm signal.

What are the input characteristics? What is the threshold to register a high signal? Low threshold? Minimum or maximum pulsewidth to register the signal? Or is it just edge detection and time period between the edges?

GTIspirit · Post by **GTIspirit** » Sat May 11, 2013 12:52 am

Alex W wrote:I can't get it to read anything other than 2x the actual speed. I initially set it up for 2 pulses per rev, saw that it was reading at 2x, so I changed it to 4 pulses per rev, but the reading is still double what it should be. How is that possible?

I made some tests to see which Clock Divider was best for my application. It looks like Clock/128 is best for the distributor rpm signal on an '87 VW GTI 16V, the blue square pulse in the screenshot above.

But now I have the same problem as Alex W. I had originally set the divider to 2 and the log showed rpm numbers double what they should have been so I changed the per revolution to 4, but the rpm numbers are still double.

Anyone else have this problem, and if so, how did you solve it?

Post by **brentp** » Sat May 11, 2013 12:54 am

I believe this probably needs to be fixed in the firmware. Let me check over the weekend.

Are you getting a stable RPM reading with the source you have now?

GTIspirit · Post by **GTIspirit** » Sun May 12, 2013 12:32 am

brentp wrote:I believe this probably needs to be fixed in the firmware. Let me check over the weekend.

Are you getting a stable RPM reading with the source you have now?

Here's what the test with the different clock divider settings looks like, just off by a factor of 2..... Looks pretty stable to me, I'm generally happy with the results now.

Clock/128 is clearly the best for my application. Four vane distributor with hall effect sensor on a 4-cylinder engine.

My only suggestion would be to implement a user adjustable PT1 filter on the RPM signal to filter out the irregularities, such as when starting and blips when the signal goes wonky for a moment.

Oh, and I couldn't figure out how to adjust the scaling or "time" err, sample axis in Race Analyzer, hence the Excel plots.

jacmifish · Post by **jacmifish** » Fri May 17, 2013 7:15 pm

Hi I'm sorry to but into this topic but you guys seem more knowledgeable then me. I'm having RPM issues with my unit could someone please assist with their opinion? Thank you.
http://www.autosportlabs.org/viewtopic. ... 8969#18969

Tango · Post by **Tango** » Mon Jun 03, 2013 1:17 pm

barkerdm wrote:I've also noticed that the pulse per rev adjustment for RPM did not scale the reading accordingly.

Hi Barkerdm,
We are running into the same issue as you on our E30. We tapped into the Black / Blue wire on the 3-pin connector from the ECU and then connected it to the #20 pin on the race capture pro. We were unable to get a proper RPM reading.

We had a reading of 997 with the engine off and once at idle, was around 2,200 - 2,500RPM according to the RCP real time sensor reading (which is awesome by the way!)

Did you have any success with your RPM readings on your E30 yet?

Another options that we might investigate is a signal from the crank position sensor. I'm hesitant to tap into this signal because it communicates with the ECU for fuel and spark and do not want to create a lag or false signal.

If we come up with something, we'll let you know. Thanks in advance.

Post by **brentp** » Tue Jun 04, 2013 6:18 pm

The input to RaceCapture/Pro must be reasonably clean, otherwise any noise may be interpreted as a valid signal. We're looking into some software based filtering. If you have an oscilloscope you'll be able to visualize the signal.

the 997 reading is basically 'zero' - i.e. 'lowest possible reading' with the internal timer overflow. A future firmware release will snap that reading to 'zero' when the timer overflows.

We're also looking into the pulse-per-rev divider issue. Thanks for the updates and feedback!

Tango · Post by **Tango** » Tue Jun 04, 2013 6:23 pm

brentp wrote:The input to RaceCapture/Pro must be reasonably clean, otherwise any noise may be interpreted as a valid signal. We're looking into some software based filtering. If you have an oscilloscope you'll be able to visualize the signal.

the 997 reading is basically 'zero' - i.e. 'lowest possible reading' with the internal timer overflow. A future firmware release will snap that reading to 'zero' when the timer overflows.

We're also looking into the pulse-per-rev divider issue. Thanks for the updates and feedback!

Thank you Brent and to your team!
I know there is a bunch of input and feedback from all of us and we're learning along the way.

I'll wait for the firmware update. For now, I'm going to investigate using a secondary crank position sensor and use that to feed the RCP frequency / pulse input.

Post by **brentp** » Sun Jun 16, 2013 2:48 pm

Hi,

We have a preliminary fix for this issue; you can find the 1.1.11 firmware here:

http://dropcanvas.com/bthz0

I didn't do a general release as there are some new API stuff mixed in to enable the mobile app. It's mostly additive stuff with mostly sane refactoring of existing code; please test it as much as possible. If its at least as good as 1.1.10 + pulse per rev bug resolved, I'll do a general release.

There's also a fix for Race Analyzer in there to possible address crashy situations with the real-time logging view.

Please let me know how it works!

mattlqx · Post by **mattlqx** » Mon Jun 17, 2013 1:00 am

I tried out the 1.10.11 because I'm having issues trying to get the tach signal interpreted correctly. It seems a little worse off because I could send cellular data before the upgrade, but now I just get a red light when I tried and start logging. Same setup as before cellular with no sd card.

Trying to hook up the tach on an E30. Black wire from the right (blue) connector on the gauge cluster. Can't seem to get the RC to read anything meaning full. It reads one 997 value and that's it.

Post by **brentp** » Mon Jun 17, 2013 3:23 am

mattlqx,

Thanks for the update. With the older firmware did you actually get some sort of tach signal, but with the reading off, as described in the other posts? or is this the first time you're trying to get a tach signal in general?

Will check out the telemetry functions more deeply with the new firmware.

mattlqx · Post by **mattlqx** » Mon Jun 17, 2013 3:14 pm

First time trying to get tach signal. The prior fw seemed to have the same results. I don't know for sure which one I was running before but I was part of the initial batch of RCs that were sent out last month.

Post by **brentp** » Mon Jun 17, 2013 3:27 pm

Got it.

The tach signal does have to be quite 'clean' in order to get a good reading. See some of the posts where people were able to get a clean signal from different sources.

I verified there is a flaw in the firmware around telemetry that will be fixed rather quickly. In the meantime I would fall back to the older version. Sorry for the hassle!

Will post here and elsewhere when we have an update.

Autosport Labs

Erratic RPM, incorrect configuration?

Help request