Posted on Leave a comment

2.9.0 is Available (and it’s Full of Hotness)

3G is Fast. Photo courtesy of flickrfavorites
3G is Fast. Photo courtesy of flickrfavorites CC BY 2.0

MK2 firmware version 2.9.0 is now available and it’s a big release. This version includes over 31 unique improvements & bug fixes. That is YUUUUUUGGEE! The result: the most stable firmware we have release to date.

Download and update your RaceCapture/Pro MK2 today | How to update firmware

3.5G Support

We have evolved and adapted our technologies to a much more modern and responsive cellular transport. 2.9.0 adds support for the new 3.5G module, enabling you to upgrade from 2G to 3G via a simple hardware swap. And the results from 3.5G are fantastic. The 3.5G module demonstrates sub-second lag and a data rate that is over 10x faster than its predecessor. This new technology will enable us to continue adding new features on our cellular backbones to better enhance your racing experience.
3G_Module on bottom. Fits in the same spot!

Lua Improvements

Many improvements to the Lua subsystem are present in this release. For example, the Lua subsystem will no longer hang up while waiting for a buggy Lua script to complete. This solves a significant number of programming issues users were having in the field while testing out new Lua scripts. We have also improved the Lua diagnostic feedback in the logs, enabling better feedback while programming. The run time is also more strict now and alerts you if your script fails via the red error LED, helping you know if your scripts are unstable so you can fix them. We also drastically increased the callback rate of the onTick method, increasing the maximum value from 30Hz to 1000Hz! And finally, the maximum number of virtual channels supported has been increased to 100, more than 3 times its original limit. Now you can log ALL THE DATA!

Timer Improvements and Filtering

RPM spikes have been a big annoyance for our users for a long time, for this release we added powerful, automatic RPM filtering for any timer channel set to measure RPMs. We also spent many days fine-tuning it to handle various types of noisy tach signals. It turns out that RCP is so sensitive that noisy tach signals (which don’t show up on mechanical gauges) frequently show up; and this yields non-ideal data. To have it work best, simply set the maximum RPM value to your red line value and the correct pulse per revolution for your engine, and filtering is automatically enabled and adjusted. The result is a more stable reading and the near elimination of RPM spikes except for the noisiest of signals. This release also includes the snap to 0 feature; when you stop feeding data into a timer channel, it will reset to 0.

Where to set the Maximum value
Where to set the Maximum value for RPM channels

Lots More

The above sections only touch on the highlights of what is included in this release. In truth there is much, much more. Improvements to our accelerometer orientation have been implemented. We also have addressed several issues raised by our users. Check out the release notes below for a more comprehensive list of what has changed in this release. We hope you enjoy this release! As always, let us know your thoughts and feedback on our Facebook page or via our forums. Cheers!

2.9.0 Change Log

  • Fixed Lua programming hang because stuck in infinite loop or non-responsive (Issue #403)
  • Clear all virtual channels on Lua script load (Issue #471)
  • 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 malloc/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 guaranteed 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)
Leave a Reply

Your email address will not be published. Required fields are marked *