Matt Romanowski

I'd suggest still reporting what you needed to do. This helps AiM to know what is going on and make changes. If it happened to you, it could be happening to others.

On a related note, I spent a bunch of time with Emiliano, the software lead, and the other guys from AiM. They are very interested in always improving their product - whether software, hardware, or user experience. It's essential to communicate things to them so they can work on it.

freeride

I'll send them a note. To be blunt, AiM is a black hole when it comes to software bug reporting, status, feature requests, etc. Which doesn't encourage pro-active feedback.

Matt Romanowski

No question they can be a black hole. But, they do read them and act upon them.

ProCoach

I’ve been impressed with both AiM Sports, Inc (the US arm) and Racelogic USA and UK, which both use Zendesk or other CRM software to assign and track a reference number to a bug/hardware or software issue. That way, there’s definitive tracking and follow up. Not sure AIM Sportline (Italy) has integrated that.

NaroEscape

interestingly we’ve sent a dozen things in about the beta bugs and gotten a response on every one.

freeride

I'd expect they'd be more responsive to a vendor.
I've sent in dozens of bugs and suggestions via RS3A. I received a followup question on one. Nothing else.
I sent a bug/question to support@aimsports.com in early Dec. I've heard nothing.
Maybe I'm blacklisted.

NaroEscape

I’m not 100% convinced Italy knows who we are…especially Nadine who owns the account we use for the track laptop.

ProCoach

Not necessarily, but it does take time and some persistance. Numbers count, too.

Nah...

freeride

Then, I'm definitely blacklisted. lol.

Matt Romanowski

If anyone gets blacklisted, it'll be me My volume of emails outstrips anyone that I've heard about.

Use software@aim-sportline.com for the software related emails and tracks@aim-sportline.com for anything track map related. I'm not sure who is on the receiving end of support@, but I know who gets the others and it's the people you want.

freeride

Matt Romanowski

A nice video of the PRI booth with Bryc. Bob and Nadine are even seen!

https://fb.watch/9Wn-SAia3D/

jigga009

I'm sorry to make it seem like it's "dunk on AiM week" here, but I also have run into many issues with RS3 3.38.03 with latest available MXG dash firmware on Windows 10.

Some of the issues are insidious - such as random un-commanded changes to the parameters selected being displayed on the MXG (e.g. RS3 takes it upon itself to remove certain set parameters such as turbo boost, and replace it with something else that is already on the page, such as differential fuel pressure, so now I have differential fuel pressure showing up twice on the page).

It seems that almost every time I connect RS3 to the dash, some un-commanded change is made to how things appear on the display page. On some occasions that I catch RS3 in the act, the program will literally not allow me to change those parameters back, as when I select the correct parameter for a particular position on the display page, nothing happens when I click on the parameter I want in the particular spot on the dash.

Another issue is more concerning and irritating: constant crashes/shutdowns of RS3 while connected to the MXG, especially while saving or applying canbus protocols to existing configs when there is more than one canbus protocol tab open. This is a pain due to the time it takes to write custom canbus protocols, and the need to have more than one canbus protocol tab open (especially in cases where one is comparing and contrasting protocols). I know I'm not the only one experiencing this. I've spoken to others using RS3, and even tech support at Link ECU's end (who market and support a Link version of the MXS display running on RS3), and their tech support and forum members confirm that they are running into this issue also with RS3.

These crashes occur so often and are so repeatable that I find it hard to believe that someone on AiM's end did not know about them before pushing the software out. After all, it isn't as if I am doing anything esoteric when I run into these issues; I'm simply creating canbus protocol. When the crashes occur, any changes that were saved *prior* to the crash are lost! The work around I have been using is to save my work before it crashes, then close RS3 completely, and then reload the program and then continue where I left off, knowing that I will lose anything I am working on if the program (even if I hit the save button) if/when the program crashes/automatically shuts down.

Another bug I run into on the canbus protocol side is that some canbus protocols or even the config file sometimes stop working/develops a bug out of nowhere, necessitating you to start again from scratch cooking up a new one with the exact same settings as the previous protocol or config file, which will mysteriously work. I noticed this bug after fighting for 4 days with RS3 trying to get it to display a canbus stream it was receiving on Canbus 2. The program keeps crashing while you have more than 1 canbus protocol tab open while transferring settings over.

Another bug I have run into is strange behavior when it comes to setting up the dash to receive incoming canbus streams. The "Gain" and "Offset" features within the "Can Measure Settings box" do not consistently work in a predictable manner. In trying to display "differential fuel pressure" from a Link G4+ standalone ECU, you can input almost any "gain" value in that box, and RS3 and dash displays the same live value for that channel. On the occasions that a change is made to the output number on the dash, the resulting number bears no relation to the offset or gain value input into the RS3 software. You could put in a Gain value of 1, 100, 1000, 0.1, 0.001, 0.0001, etc.., and there is very little effect on the numbers being displayed for that particular parameter on the dash, or no real relationship between the gain input and output value. A shortcut I am using to get around this issue at the moment is to create custom math channels to do what the gain and offset values within the canbus protocol setup section should be doing, but the problem with this is that one can only create so many custom math channels on RS3.

Another bug I have run into relating to canbus operation is that certain parameters sent from the ECU do not appear on RS3/dash as one might expect, given the gain and offset values of the raw data sent. Add to this a lack of functionality of the offset and gain on the RS3 side, and you simply cannot display certain parameters on the dash, even though it is receiving the raw data from the ECU. Foe example, the ECU might send canbus raw data to the dash multiplied by 10 (at which point you would usually need to apply a gain of 0.1 in order to get the numbers reading correctly on the dash end), but what appears on RS3 is anything but...

Another bug I have noticed is that the selections that are input within the custom can section are not consistently saved or applied to the configuration, even when you hit the "save" button. You can see this by making a change in the custom config, saving it, and then attempting to apply the altered canbus protocol to the main config map, only to find that RS3 is silent about the new additional parameter you added to the canbus protocol. You then go back to the custom can protocol only to find that the additions you made and saved were not actually saved or applied.

Another bug I have noticed is that some trigger commands stop working, but typically after a software update. Fortunately I don't have the MXG running anything mission-critical on the car, but I am quite certain that one could end up with an expensive engine rebuild bill if it were controlling something important such as a water/methanol injection, or even an auxiliary fuel pump.

In my experience, the dash and its software have always been plagued with odd bugs since day one. Typically AIM would release new software to kill certain bugs, but can't seem to resist producing novel ones in the process. This makes updating software and firmware a process full of trepidation, because what Forrest Gump said (about life being like a box of chocolates) applies to AIM's RS3 - "you never know what you're gonna get" when update time comes around.

The frustrating part about all of this is that I would very much like to get deeper into the AIM ecosphere with more of their equipment, but my experience so far with how RS3 works with the MXG, and the relative lack of display customizing options on the colour display devices has me firmly holding on to my wallet.

Having contacted AIM in the past about other bugs that I have run into, I was met with silence, and not until esteemed vendors here such as Matt (TrailBrake) and ProCoach put me in touch directly with Roger Cadel (sp? apologies for butchering that....) that I was able to make inroads, only to be later told by AiM in Italy that the issues I was running into at the time were my fault due to having too many alarms in my configuration (funny, considering I am only able to create as many alarms as RS3 allows), and that I need to re-write my entire configuration again (with the same number of alarms that was supposedly problematic before...) from scratch without importing anything from the previous config file. So when I do run into the same issue typically after a software/firmware update, the work around has been to simply rewrite my entire configuration file from scratch (with new alarm and canbus configurations included).

Matt Romanowski

jigga009 -To be completely honest, it sounds like you are having some odd problems that might be hard to produce on other computers. I had a little trouble following everything, but I have not found RS3 to be unstable and certainly not have multiple open CAN configs make anything crash. I have also not had configs change on their own.

I'm willing to try and help you out with this. Shoot me an email - matt@trailbrake.com and lets see what we can figure out. If you have some odd crashes, we'll get Italy involved and see what we can do.

ProCoach

You know, I’ve experienced most of what you report. And yes, since RS3 configured hardware has been released (in 2015), the equipment hardware, firmware and software has not been as rock-solid and reliable as it has been in the past.

Sometimes, hardware component changes have introduced reliability problems (most recently the Solo 2/Solo 2 DL GPS initialization issues earlier this year, where units work fine one event or session and not the next, or bitmap fields disappear with firmware updates in the early models of the MXL2), but AIM Sportline (Italy) has stepped up and fixed all those issues! God bless them.

I do understand that compilation, especially in an existing operations stack, is a hard thing, but there are a fair number of issues. It’s not “great,” as some vendors are so fond of saying.

That said, I have found Roger Caddell, “the Mikes,” Robbie, Robinson, Cameron, Bryc and all the US AiM Sports Inc staff to go consistently above and beyond what is required to help folks solve or at least minimize their issues. I’ve been proud to be a leading AiM dealer for more than a decade now, even though both mine and more than a few of my thousands of customers have had their patience tested.

There is no question AiM has made great strides in the power and configurability of their offerings, but with that comes complexity and the likelihood of more bugs, not less. It’s a sign of the times…