RPM noise filtering for MK2, beta available

[Brent Picasso]

If you're running MK2 and you're experiencing noise in the form of high RPM spikes, you should try this firmware patch.

Where it should help:

* If you're using CoilX tapping directly into your ignition coil, and you're still seeing periodic spikes

* If you're tapping into low voltage ECU tach signal that *should* be a clean square wave, but significant noise on that line triggers high RPM spikes

The filter works by triggering on the falling edge of the signal, and ignoring short signal spikes for a period of 4.5 ms  after the primary pulse triggers. If you have an inverted signal that should trigger on the rising edge then this RPM filter patch will likely not work.  Also, this filtering is only enabled for RPM mode.

The attached image shows the case where this filter will help - top part of the diagram showing a falling edge trigger. In the 2.9.0 firmware release we will add a configuration option which will let you select rising or falling edge triggering. For 2.8.8, we selected falling edge as we expect this is the most likely case with most applications.

We've tested this release with a standard signal generator as well as the noise directly from the ignition flyback (primary coil signal) with good results. 

Please test and let us know your results!

-Brent

[Julian Cordle]

Is this also a fix for the "RPM shows a >0 value after engine is off" issue?

--
You received this message because you are subscribed to the Google Groups "AutosportLabs Beta Testers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to autosportlabs-beta-...@googlegroups.com.
To post to this group, send email to autosportlabs...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/autosportlabs-beta-testers/03b3ee45-832d-4d74-aa64-064253b77974%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrew Stiegmann]

Yes.

To view this discussion on the web visit https://groups.google.com/d/msgid/autosportlabs-beta-testers/CAKE%3DX8F3h%3DX8PQS4Az7YzeX9Fu%2B3dS_T1xkig-OGq8vmazaJQw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

[Brent Picasso]

Worth noting; when you load this firmware it will still show up as v2.8.7. 

-Brent

[Ben Wright]

Uptdated it to mine this morning fired it up and rpm there and threw all revs, all good

[Brent Picasso]

Thanks for the update! Did you see rpm spikes before this update?

Brent Picasso
Autosport Labs
Technology for Race and Street

--

You received this message because you are subscribed to the Google Groups "AutosportLabs Beta Testers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to autosportlabs-beta-...@googlegroups.com.
To post to this group, send email to autosportlabs...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/autosportlabs-beta-testers/8e534ed6-6f0b-4b0b-ac1f-b48edd5ff050%40googlegroups.com.

[BJ Meyer]

Downloaded and installed the firmware.  I have been experiencing RPM spikes since mid-last year.  (prior to that, they weren't present)  I'm using an RPM signal on my R53 MINI Cooper.  I will be at the track this weekend and I will report if this resolves the issue.

I should know pretty quickly, because I get spikes every session and every laps prior to the beta.

-bj

[Andrew Stiegmann]

Cool BJ.  FYI I hope to drop a new RC for 2.9.0 out before EOD Thursday for all to test.  It has some enhanced filtering from the first version (uses the maximum channel value + pulses per revolution to calculate the largest filter value it can use), so hopefully you and anyone else headed to track this weekend can give it a quick spin.  Gotta do some internal validation tomorrow on our test gear first though.  Stay tuned!

--

You received this message because you are subscribed to the Google Groups "AutosportLabs Beta Testers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to autosportlabs-beta-...@googlegroups.com.
To post to this group, send email to autosportlabs...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/autosportlabs-beta-testers/5737dd17-008c-4bb3-ada0-eb63a4251e0e%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

[Brent Picasso]

Echoing the thanks for testing. 

How is RPM connected in the Mini? one thing to note is that the filtering is designed for a falling edge pulse, which would work with most systems. In the upcoming 1.5.0 app we'll expose those values in the configuration view.

-Brent

To view this discussion on the web visit https://groups.google.com/d/msgid/autosportlabs-beta-testers/CAEPJ%2BDpvDOMQtqwTTCvPVq3FcaEy-P3mzXu41GH-%2B2FR12VBhg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

[BJ Meyer]

I thought I included the connection method, but I guess I missed it.

I am pulling the RPM signal from the OEM ECU.  I think the filter will help because I have a shift light that uses the same signal and it does not show any spikes.

I guess the shift light could be causing the noise, but about a year ago both the RPC and shift light were hooked up without the spikes in the data.  The spikes began to show up immediately after a firmware upgrade, but it was so long ago that I don't remember what I was upgrade from and to.

Alternatively, I could get RPM from CAN bus, but I had this signal hooked up prior to integrating can bus, so I just continued to use it.

I'll happily test 2.9.0!

-bj

[Andrew Stiegmann]

Ok Beta testers... its here.

Attached is the RC2 version of MK2 firmware version 2.9.0.  This is beta-software, but has been pretty stable so far in our tests and is ready for a run in the field.  A few notes for those who want to try it out:

1.  BACKUP YOUR CONFIGS!!!11  This will reset them to their defaults.

2.  This has more advanced RPM filtering in it.  This newer algorithm uses your 'pulse per revolution' settings and the 'maxium' value (found in the gear icon when setting up the rpm channel).  Ensure that the maximum is set to your red line plus a little extra.  For example, if I redline at 7K, set it to 7500 or 8K.

3.  In case anyone out there was running a different version of 2.9.0, you will need to reset your config with this one as the ABI changed internally.  You can do that using the serial console over USB.

4.  This release standardizes the Accel unit on the SAE J670E standard.  You may need to re-configure your units X, Y, and Z axis as a result.  Check it before you go on track.

And that is it.  For those of you with the RPM spikes, this release should solve it (among many other issues).  Full change log and testing notes below.  Please include feedback in this thread so we can fix any major issues before the final release.  And, as always, THANK YOU to those who help test beta stuff. It really does help quality here and allows us to deliver quickly.  Cheers!

= v2.9.0-rc2 =

* Fixed Lua stack overflow bug by increasing Lua Stack size (Issue #411)
* Fixed timer input so it resets to 0 when no input detected (Issue #418)
* Added RPM filtering in software to get rid of unrealistic engine speed
  values (Issue #430).  NOTE: The new quiet period logic uses your maximum
  and pulse per revolution values to calculate the quiet period. Ensure
  your maximum RPM and pulse per revolution values are set correctly.
* Fixed Lua onTick timing bug that was causing Lua to wait longer than it
  should between onTick events. (Issue #433)
* Quieted various Lua memory alloc/free messages (Issue #410)
* Fixed virtual channel issue where if the virtual channel sample rate was
  faster than other channels, it would not record. (Issue #444)
* Added new OBD-II PIDs into our OBD-II system.  Special thanks to
  Justin Imhoff (https://github.com/imhoffj) for the patch.
* Improved `addChannel` method in Lua environment to validate all inputs.
  Now it will error with detailed information if a user supplies an invalid
  input parameter or an invalid sample rate. (Issue #424)
* Fix USB suspend bug that causes device to go non-responsive when put into
  suspend mode. (Issue #426)
* Fixed timer prescalar skew caused by varying timer speeds settings.  Now all
  timer speeds report correct values (when frequency is within the timer
  measurement range of course.  A good test is 100Hz). (Issue #435)
* Fixed telemetry destination.  Currently set to telemetry.race-capture.com
  (Issue #341)
* Removed MK1 platform from build tree.
* Improve unit test infrastructure to compile all firmware code strictly in
  C (was C compiled as C++) and test accordingly.
* Improved unit test platform to be able to directly include C files to test
  static methods and other non-visible methods as part of the unit test suite.
* Fixed serial device pass-through watchdog event.  (Issue #352)
* Remove obd2SampleRate structure from LoggerConfig since deprecated (Issue #164)
* Standardized accelerometer on SAE J670E vector axis spec and adjusted internal
  mappings of RCP units to ensure that default orientation of MK2 matches this
  exactly.
* Added Lua method to get GPS altitude in Lua runtime. (Issue #397)
* Fixed timeout support on Lua CAN tx method.  (Issue #404)
* Merged RaceCapture codebase into this mainline project.
* Add dynamic cellular modem support.  This allows us to support both our current
  sim900 card and the new ublox-sara 3G cards. (Issue #182)
* Added support for up to 100 virtual channels in Lua.  Up from 30. (Issue #414)
* Adjusted internal process priorities so that the logging snapshot process
  runs with this highest priority.  This is to ensure that we never miss time a
  snap-shot operation.
* Improve `onTick` method in Lua to be able to run at 1000Hz maximum rate.  Not
  gauranteed to run at that rate (depends on how much Lua code there is to parse)
  but local testing shows its possible to do if code is optimized. (Issue #423)
* Added a new `getChannel` method in Lua so users don't have to maintain virtual
  channel values in Lua environment variables if they want to later calculate
  additional channels using the recorded virtual channel values. (Issue #456)
* Add additional version information to the firmware.  Now include build type
  (release, beta, dev) and a git description string. (Issue #436)
* Fixed up LED mappings, added deterministic LED control code to firmware.  This
  prevents us from turning the wrong LED on or off due to different LED mappings
  between RaceCapture platforms. (Issue #437)
* Fixed up Lua setLed method to be consistent on which LED is set and to also allow
  the user to specify an LED based on a string identifier to be able to control it.
  (Issue #437)
* Improved our timer by adding support for selecting which edge we want to use for
  timing measurements (Default is falling).  Also allows the user to specify the
  a quiet period for filtering if they wish to override the automatically calculated
  value.  A value of 0 will disable the filtering altogether.  A value < 0 sets the
  code into automatic calculation mode. (Issue #464)

TEST NOTES
* Test virtual channels recording at 50Hz
* Test the new OBD-II pids.  Ensure they work as expected.
* Test the addChannel, setChannel and getChannel features in Lua
* Test that timers all report the same (or very close too) values for the various timer speeds.
* Test that axis after upgrading to 2.9.0 follow SAE J670E standard
* Test Lua getting altitude of GPS
* Test Lua onTick method running at 1000Hz
* Ensure getChannel methods is added to Lua wiki.
* Ensure note on checking for Lua errors shows up in Wiki
* Ensure that LEDs are working correctly.
* Ensure Lua LED notes are in the wiki for Lua
* Ensure that RPM filtering works on a noisy signal.  Also ensure that it is adjustable and that it works.  Test extreme cases like 20K RPM and 5K RPM noisy signals.

--

[Andrew Stiegmann]

Anyone have a chance to run the new firmware this weekend?  Any feedback?  Usually no news is good news.

--

[Andrew Stiegmann]

Howdy folks.  Another weekend has come and gone.  Anyone else run the 2.9.0 RC over the weekend?  If so, feedback would be most welcome at this time as we try to wrap things up for the next release.  Cheers.

On Mon, Mar 21, 2016 at 9:15 AM, Andrew Stiegmann <and...@autosportlabs.com> wrote:

Howdy folks.  Another weekend has come and gone.  Anyone else run the 2.9.0 RC over the weekend?  If so, feedback would be most welcome at this time as we try to wrap things up for the next release.  Cheers.

On Tue, Mar 15, 2016 at 9:39 AM, Ben Wright <benwri...@googlemail.com> wrote:

Will be out next friday

--
You received this message because you are subscribed to a topic in the Google Groups "AutosportLabs Beta Testers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/autosportlabs-beta-testers/ZdTfovZJ_Qk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to autosportlabs-beta-...@googlegroups.com.

To post to this group, send email to autosportlabs...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/autosportlabs-beta-testers/CAEPJ%2BDrGmzyWVNvm%3D84SNGScqr1AzNF0ZEkPMLJ1mEeinruzTg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

--