How does RSA3 set the session times (and select the time zone) in the report?
I remember seeing something during one of the webinars.
Is it based on the GPS location of the track? Zip code of track? Settings in the device?

I'm getting some oddball times (some right, some wrong), and wondering if I can fix.

 

It is supposed to be from the location of the track and GPS time, but it has room for improvement. I have good success with the dashes. Cameras are not as good with being accurate.

 

GPS location should set the time zone with the latest software and firmware. I would still check the “time zone” in your device.

 

I have good luck with the cameras and dashes.

 

Thanks guys, looking at details, the sessions with the incorrect times are for a track configuration I made, which didn't include a zip code in the track description, that's the only thing I can see that's different. I didn't touch the devices date/time settings during the day, but I'll double check. I'll also add the zip code to the track, reload into device, and re download the sessions to see if that fixes it. If not, I'll report to AiM as a bug.

Not a biggie, but thanks! Just trying to figure out how to not let it happen again.

 

Well, nothing I tried worked to fix the session-times. Just kinda odd.
But, what's very frustrating, is that I deleted the sessions in RSA3 beta, and reloaded from the MXm, and now it's incorrectly assigning track maps, and not associating the SCHD vids with the sessions correctly. These were from sessions I downloaded from the MXm only 2 days ago, and nothing else has changed except I added a zip-code to my map to try to fix the date thing.

I guess I'll send a note to AiM, but I have no idea how to describe this in a way that'll help them, and it'll go into a black hole.

Yes, I'm frustrated that downloading data from the device kinda works (but wrong times), then downloading the same data again, creates all sorts of issues, uses different track maps than it did before (and the wrong ones), etc. And of course, the lap times changed because it's now using a different S/F.

I guess it's time to stop bitching, cause "beta". And just go back to RA2 and use SCHD vids independent of the MXm files, or shop a different solution.

 

Please don't give up! I lead the world in reports and emails, but they really are reading each one and working on all the problems that are identified. The track ID and application in RS3 is still not perfect, but they are making improvements. I know they have been working on some other areas in the last few days, but they will be off that soon. I'm happy to help you report the problem if you want too. Feel free to copy me on the email.

 

Thanks for the voice of reason Matt,
I've calmed down a bit. LOL.

RSA3 has associated a counter-clock-wise map from the MXm with a CW lap from the SCHD. Funny watching the dot on the map go in the opposite direction of the movie.
There's lots of stuff clearly wrong, duplicate sessions, laps that are literally over 800,000,000 hours long, etc. I may delete/reset all , and reload just to see if I can get to a point I can use some of the data from last weekend. I had it there once.

 

I’ve recommended since RS3A beta has been released a year ago, to use the standard RS2 Analysis, standard firmwares and standard maps and configs from RS3, NOT the beta.

It’s nice that it’s a standalone installation so you can do that safely.

But, there is a reason why fw and sw releases come fast and furious from Italia.

It’s been particularly trying in the last year, doubly so since the GPS initialization issues.

There are plenty of other options, but I would stick to using RS2A and make sure the sw and fw releases match (latest with latest).

 

The opposite maps is a bit interesting. You've certainly had some problems and I know that the software team wants to fix things like this. Please email the info in and copy me. I've been poking about some things and will keep on them. The problems you are having are odd and they have tested a lot of files over the last 3 years making sure things work. The 800 million hour session is interesting.

There is no question there have been some growing pains with the Beta, but I think you would benefit from using it some more and understanding the similarities and differences from the production copy. I know you're down on AiM right now and think they have lost their way from the things you post here and talk about in the webinar, but I can assure you that is a misunderstanding.

 

Guys guys guys, freeride should sell his smartycam and mxm to the nearest miata driver he can find. At a steep discount.

We've been over this.

 

It’s a beta, Matt.

Utility, feature sets and reliability are improved all the time. RS3A beta is not ready for prime time. Most dealers, the importer and the manufacturer are very clear about this. Most users are, too.

When James makes clear in his webinar last week that he can’t reliably load both video and data at the same time, same as me, that’s an issue. James and I are pretty up to speed, too.

As a dealer, trainer and supporter of this type of technology back to the beginning for club level drivers, I have a wider experience base and enjoy the pros and cons of each system’s use, in-the-field.

Racelogic had issues early on until they were able to sort auto-track maps and build their CAN library. MoTeC, given their rather mission-critical applications in most installations, has a high bar to be met before releases of anything., in my experience.

In each case, all these companies, including AiM, are receptive and solicit feedback that will help improve utility, feature sets and reliability. That’s pretty normal.

Tracing hardware development, sw and fw releases across three large brands has helped being able to compare the pros and cons of each, as well as gain keen insight into the workings and execution of each company’s business and technical planning.

There is no emotion to it, just a constant weighing of the pros and cons of each offering in the marketplace. The balance between those continually shifts, some quicker than others. It doesn’t matter the intentions, only what is able to be delivered in terms of dependability, reliability and ease of use.

When using the equipment gets in the way of easily obtaining and benefitting from the valuable information collected by that equipment, whether it’s a software stumble, an incompatibility between the release versions of software and firmware, or more recently, hardware and QC, that’s an issue.

That's just a fact, not a feeling.

 

 

The portions that are in the production release, like configs, download, tracks, and custom sensors, are all the same. They are not beta. The CAN protocol section in the beta includes the DBC import feature (which isn't finished).

I would say AiM's, and specifically the Software team's, reception to feedback is exceptional. Having used this the Dev and Beta for over 2 years, they have read every piece of feedback supplied. I think Emiliano is in a very small group of software developers that goes live in webinars to answer questions and take any criticism (and compliment) thrown at him. That is a very rare thing. As to users, I guess we have a very different experience at all levels. I have tons of people that use RS3A constantly and find ways to not only drive faster and safer, but to save their engines and race weekends.

Either way, change can be scary. I choose to embrace it and use the features and tools to grow personally and professionally. It's all certainly different from my first AiM experience in 1999!

 

Update. I got everything back into a usable state. (Deleted database, deleted profiles, changed some settings, reloaded from logger/SCHD, recreated.)

The good news, problems are minimal (RSA3 is quite useful) when;
Using AiM supplied maps that don't have bugs (some do), AND ensuring only one track is/was loaded into the data logger and SCHD, AND only one track configuration was driven for all sessions for the day.

The problems multiply quickly for sessions where there are multiple track configurations run the same day, or where I failed to delete all maps in the logger and SCHD except the one being used, or, using user generated maps.
So. Track maps. Still.

Question:
If downloading data from logger and from SCHD, is the "merge files logged the same day" setting in "data download preferences" supposed to work ?