I use a datalogger and dash from the company Race Technology.
Race Technology sold the display with what they name "Vems interface", without testing. Unfortunately it does not work.
Warning: only purchase from Race Technology after they show a video of the given unit with a given Race-tech firmware version working with the intended device
- good news: Race-Tech is likely to be able to provide firmware and procudure to upgrade/fix devices (that can be done at home, or sent back for fix .. I heard ~maybe 40 GBP ?).
Alternative displays that can, for sure, read the AIM stream and display it properly:
- [AIM Dash, AIM - RS232 protocol]
- this caused a bit confusion, because it looks almost exactly the same as the Race-tech, but the AIM dash actually can read the aim stream, so it works
- hundreds of [round] and [displayonly round] are configured to display the received AIM - RS232 data perfectly - ** latter has no sensor inputs of it's own, so it can only display data from this stream (including RPM, temps, etc...).
- http://vems.hu/android/ rather new
- nowadays when android (with min 640x480 or better display, nexus7 being a nice example) connected to VEMS v3 (usually via bluetooth-serial adapter) is using the proprietary "triggerframe protocol" when v3 has firmware 1.2.x (higher refresh rate than with AIM, and therefore using with recent 1.2.x is encouraged and supported)
- vems.hu/android can also read AIM stream (previously before the triggerframe format was implemented it could only read that, and displayed properly). Although the triggerframe format is encouraged now, courious users can timetravel back and try with old 1.1.x firmware as an experiment.
- note for developers: PC was also used for reading and displaying the AIM stream - it was coded in VT, ment for developers for debugging/verification
- ... add other devices known to display the AIM-RS232 stream properly ....
Protocol details
- VEMS firmware sends data via [AIM protocol],
- the scalers were made according to [AIM-protocol.pdf] with only minor corrections to match the Race-Tech Motec interface (which was found to deviate slightly from the protocol.pdf, eg wheelspeed 10x multiplier).
- The AIM-channels scalers for most common variables and units (eg MAP/kPa, MAP/psi) are self-documented and can be easily configured with the [wizard dialog] in the freely downloadable VemsTune (also documented in above protocol.pdf Can somebody varify that the v3 actually sends the AIM signal according to the specs in the pdf? Because Race Technology informed med that they don't have a Mo-tec interface which complies to the protocol in the pdf...??
- unfortunately Race Technology made an interface for VEMS which
- was completely unnecessary as the VEMS AIM stream => AIM Dash motec interface was already implemented, tested and in use
- seems to not comply the [AIM-protocol.pdf] specs
- was unfortunately released by race-tech without any testing and sold, what they call as "interface for VEMS". It's sold by Race Technology (not even cheap) although it does not work:
- data displayed on the dash (AIM data from the vems to display RPM, temps, etc.) is all wrong, even if the data sent by VEMS complies the [AIM-protocol.pdf],
- One can easily verify that for example correct RPM value is sent by VEMS in channel 1 as in [AIM-protocol.pdf]. VEMS round displays it correctly (or any other device configured to display AIM channel1). Race Tech (if ordered with VEMS interface) displays incorrect value (and good value is displayed if ordered with Motec display).
- However Race Technology analysed my data which I had logged from the ECU, and they informed me that it's not the signal it was supposed to be.
- That is blabla without any information. Let's see the RPM example: Where EXACTLY do they expect RPM if not in AIM channel1 (as in the [MembersPage/NanassyPeter/AIM_support/AIM-ECU protocol.pdf AIM protocol.pdf] ?
They mention that the v3 outputs unknown messages in the column 0. Which is indintifiers in HEX, anybody know what that means?
Here is a link to a txt file with my logged output:
Im running v3 firmware 1.1.96
Some of the channels within the AIM datasream are correct.
- TPS displayed good (AIM channel 45)
- RPM (sent by VEMS in AIM channel 1). Examples sniffed in hex from terminal - shows vems firmware sends correctly:
- (03EB=) 1003RPM - 01 A3 03 EB 92
- (07D6=) 2006RPM - 01 A3 07 D6 81
- reads wrong on Race Tech (when ordered with what they call "VEMS interface")
- CLT (sent by VEMS in AIM channel 17) reads wrong on Race Tech
- MAT (sent by VEMS in AIM channel 97) reads wrong on Race Tech
order Race Tech with "Motec interface" (wether used for Motec or VEMS) not with what they call "VEMS interface" (because latter is sold by Race-Tech untested, and it does not work, and not needed anyway)
Thanks for the well documented answers.
Race Tech offers a few different kinds of interfaces for the MO-Tec ECUs. One CAN interface and 3 different serial interfaces.
info can be found here:
http://www.race-technology.com/wiki/index.php/ECUType/
- Checked many serial interfaces (not just Motec), and found none that reads the AIM-RS232 stream (maybe someone else found one ?)
- [VEMS-ecu interface]
- it says "Note: AIM protocol used" but it obviously is not using the [AIM - RS232 protocol] that v3 properly sends (when enabled)
- it also says conflicting info at the same place: "The VEMS ECU outputs 56 byte sequence of data at 19200bps baud rate." - this suggests the Race-Tech display does NOT actually use AIM, but relies on the 'A' command that old firmwares (before 1.1.96) used for sending real-time data to VemsTune and megatune. (offsets found in global.h and megatune.ini, and everyone knows runtime data sending works, but for longterm compatibility AIM-RS232 is a much better choice to rely on).
- new v3 firmwares (eg. 1.2.x) only act on CRC-protected commands ("triggerframe protocol") to prevent corruption (due to serial noise). In other words it does NOT reply at all on non-CRC-protected commands like the 'A' command.
- if someone reports that his RaceTech works with old (pre 1.1.96) firmware (AFAIK not, but maybe with new Race-Tech firmware... who knows) but not with v3 / 1.2.x, we can help him this way: we offer to work out a v3 config bit to "enable unprotected communication for A-command", that would answer maybe after AAA, to make it easier for RaceTech