Track Map wrong in GPS view

[pmacduffie]

I seem to be having many problems with RaceAnalyzer.

First issue I experience is that it will not display the GPS data since the scale is SO LARGE. If the first cells in the GPS column are not populated then I have to go in and manually delete them. This is a pain, but it still works and had I not searched the forum I would never know that.

Second problem is also with scale, Data like "AFR" has a scale of 0 - 1024. This is a gigantic range for something that operates 9-16. When I make a line chart its difficult to see it do anything.

On to the next issue. The track shown is Sebring. It is mirrored in the Y axis showing 17 as a left. Its a right hand corner so something is wrong.

I'm finding these small issues to make RaceAnalyzer basically useless to do any analysis if something like scale cannot be changed from 10 bit to something rational. Or temperature from having a range of -1000 - 1000 when its measuring something 200-300.

When I use the telemetry module the web tool can scale a chart to some degree, but when the cell signal at the track is crappy the SD card data is all I have to look at.

Am I missing something that fixes these issues ? I have RaceAnalyzer 1.1.15 which I understand to be the newest as V2 doesnt do any analysis but is just a pretty looking configuration tool at this time.

Thanks In Advance

[pmacduffie]

Don't get me wrong the race capture is a fantastic value for live telemetry but am I the only one questioning why we are developing racecapture v2 hardware when the v1 system still isn't finished?

Are people actually using this hardware in a racing environment? I think Brent has a lemons car right? If I'm correct you guys can't be oblivious to these issues.

Look the product has fantastic potential and I know you guys are a small company. I also can't do what you have done on my own. I can accept all that but it doesn't make it finished when you can't chart data on your own custom tools.

[gizmodo]

Don't get me wrong the race capture is a fantastic value for live telemetry but am I the only one questioning why we are developing racecapture v2 hardware when the v1 system still isn't finished?
...

No, I've thought the same thing. I have been able to get the RCP to do most of the stuff that I want but it really feels like a product that is beta at best. The fact that a new version is already in the works has me a bit puzzled too. The one thing that has kept me on board is that Brent has always been really helpful when I've asked him for help.

[pmacduffie]

gizmodo,

I am sorta in the same boat. I'm interested in the megajolt as well, but is it unfinished too? Will it not do what I think it should ? I'm skeptical.

Philip

[andylaurence]

Ditto here. I've pulled mine out and bought a replacement. It's been in the car for over a year and I've barely used it because getting the data out is such hard work. I've relied upon the logger that it was supposed to replace for data logging, which somewhat defeats the purpose. A friend is borrowing it for a while, but I'll be selling as soon as he's finished with it.

[pmacduffie]

Maybe I need to look elsewhere too but it's the live telemetry that brought me here and there just are not that many options I can afford that do that. A motec costs more than my race car does, so that option doesn't help much.

What are you using now? Tracdash?

Phil

[andylaurence]

I don't need telemetry as sprinting is a short discipline of less than 3 minutes duration and sometimes barely 30 seconds. If your car's OBD2, then WifiLapper is the cheapest telemetry system.

I've been using my RacePak G2X but have now invested in a Xoombox which is a mature product with a brilliant analysis program. On the plus side, it also does traction control, launch control and pneumatic gearbox actuation. I just need something robust and it's pretty cheap too. If I didn't need all the features, I'd be tempted by a Race Technology Dash2.

[pmacduffie]

My car has a carb so no ODB2

Since we run races so long with multiple drivers the live telemetry is very usefull to us. But there are many tracks with bad cell coverage and sometimes the SD card data is all we have to work with.

I am interested to see what the Autosport lab staff has to say about the v2 development cycle. The device is a "race capture" not a "data capture" if I wanted to just log data and manipulate it in excel I would use a dataq.

I really expected the analysis tools to be better by now but it seems that is way low priority.

-Pm

[andylaurence]

The lack of cell coverage is where WifiLapper wins out. It still gives GPS speed and I believe it also does lat/long G as well. You just put a WiFi access point on the pit wall and it bursts the data to your laptop as it passes the pits. It's rather effective and you can use an IOIO to get analogue data in, but the IOIO was a bit too fragile for my liking.

The lack of development in the analysis tools is the main reason I'm leaving the RCP bandwagon. Being able to see the revs on a tablet is great, but I've got a rev counter for that and there are not many waterproof tablets on the market! All I really want to know is where I'm losing/gaining time and what the values of the inputs are at that point so I can establish the cause. That means being able to easily sync two runs (I do standing starts), perform a timeslip analysis and plot the results on a graph or three.

[brentp]

Thanks for your feedback.

The V2 app is where we're going to put all of our analysis efforts and the goal is to make it absolutely comprehensive, both in off-line analysis and in real-time with telemetry. This is very important to us, although I can imagine from your vantage point you're not seeing much activity. In actuality, we've been building a tremendous amount of foundational work to get us to this point.

Full information here:
http://autosportlabs.net/RaceCapturePro_V2_software

pmacduffie - I'd recommend trying out the new firmware and app when you can.

Note the big spots reserved for "Analysis" and "Dashboard"



First that was released on the beta are the configuration features and a suite of improvements to make the system easier to use (auto track-map detection, channel configuration, etc) and a variety of stability and usability improvements.

Next wave on the beta release is to enable the dashboard features, and then an initial suite of analysis features - all tablet / mobile based so you don't have to bring your laptop track-side - a unified world.

In combination with this we are releasing the next generation hardware, RaceCapture/Pro MK2 http://www.autosportlabs.com/racecapturepro-2

The MK1 and MK2 systems will share a common firmware codebase and app, so all of the high level software and analysis features will be shared across both platforms.

Thanks for your patience and support; this type of technology involves a tremendous amount of work to do properly. Much coming soon!

[brentp]

To answer the questions about "why is there MK2 hardware" ?

The simplest reason is that we are taking advantage of:

1) improved hardware robustness on the inputs and power supply based on what we've learned on MK1 and customer feedback
2) addition of CAN bus channels which the community has been clamoring for
3) leveraging newer technologies that are about as cost effective as the current tech (CPU, GPS, accelerometer)
4) improving the hardware design to eliminate having to open the unit to switch jumpers and dip switches
5) integrating the telemetry module as an add on option *inside* the unit since this option is so popular with users.

There are also business reasons to switch to the MK2 hardware. For example, certain components require minimum purchases from suppliers, like having to buy a quantity of GPS modules. We were coming to an inflection point where we needed to buy more of the same inventory, or make that jump. We made the jump.

While from the outside it looks like the MK2 is a big change, in the big scheme of things, it is not. Understand that 90% of the work is in high level software / firmware / application side, and we've designed it in such a way to separate the hardware specifics from the logic that makes it a "data acquisition and telemetry system".

So in terms of effort, developing the new hardware is a much smaller effort in the big scheme of things. Again, I understand this is hard to see from your vantage point, so you will have to trust us.

Now that we've laid the foundation for the V2 app and firmware, we'll be seeing some big strides in the near future in the areas of analysis and dashboard features.

Again, I thank you for your feedback, and I hope this has been helpful.

[pmacduffie]

Thanks for your feedback.

The V2 app is where we're going to put all of our analysis efforts and the goal is to make it absolutely comprehensive, both in off-line analysis and in real-time with telemetry. This is very important to us, although I can imagine from your vantage point you're not seeing much activity. In actuality, we've been building a tremendous amount of foundational work to get us to this point.

Full information here:
http://autosportlabs.net/RaceCapturePro_V2_software

I write code for a living, but not at the C type level. DDC stuff with proprietary languages. I fully understand that the race-capture is a huge project and I'm sure for a lot of that time it was just you working on it. Its not that I don't see activity on the subject; I just see the analysis tool lacking. Specifically the scale function, which makes it hard to look at the data for everyone, not just me. I have to export the data to excel to really view it. That isn't fast and I can't do that at the track. We are so busy there I need to use the 15 minutes I have to read data from the car just after a pit and then go back to work.

pmacduffie - I'd recommend trying out the new firmware and app when you can.

First that was released on the beta are the configuration features and a suite of improvements to make the system easier to use (auto track-map detection, channel configuration, etc) and a variety of stability and usability improvements.

Next wave on the beta release is to enable the dashboard features, and then an initial suite of analysis features - all tablet / mobile based so you don't have to bring your laptop track-side - a unified world.

I did, I use the xp netbook to take to the track but could not run the software for some reason. I posed about the error.
http://www.autosportlabs.org/viewtopic.php?t=4207

Since the V2 software only does config I see no reason to change at this point to a beta release. The config in my 1.1.15 works just fine. I have not encountered any issues with LUA yet. I probably will when I implement some new logging functions and calculations, but for now I am letting in go until v2 is around with the quoted better LUA stability.

In combination with this we are releasing the next generation hardware, RaceCapture/Pro MK2 http://www.autosportlabs.com/racecapturepro-2

The MK1 and MK2 systems will share a common firmware codebase and app, so all of the high level software and analysis features will be shared across both platforms.

Thanks for your patience and support; this type of technology involves a tremendous amount of work to do properly. Much coming soon!

Its good to know, but I have never seen any mention of that until now. I just assumed my hardware would become obsolete and not supported leaving me with 1.1.15 or perhaps the early versions of v2. The 1.1.15 analysis as we have discussed isn't really useable yet, and I'm sure I'm not the only one thinking that.

If I had to guess the reason for new hardware is to allow two CAN streams for newer vehicles that would allow sensors to be shared from the ECU. Which is a very marketable feature for the future.

I guess developing new hardware, new CAN features, and a new interface and analysis tool seems like an awful lot to commit to when small problems seem to be the plague.

[brentp]

As a software engineer I'm glad you understand the amount of work it takes. Thank you.

The reality is, MK2 work effectively started in an indirect way with the beginning of the V2 software project. A number of analysis related features have been added to the firmware which yet have to be exposed - the big ones are predictive and sector based timing, two things that have been requested repeatedly, soon to be exposed in the user interface.

Now that we've announced MK2 hardware it would be helpful to create a blog post that describes how the V2 software applies to both MK1 and MK2 hardware so people understand our style - that is, supporting existing platforms and not dropping existing customers like a hot potato.. so they can have warm fuzzies when MK3 comes out. We hope this will be our differentiation compared to other companies, on top of being open source, of course.

Regarding your specific points about scaling channels, we're laying the foundation for supporting that. Exhibit A:


Here's the configuration view for the list of channels, where we're staging up that support. Again, building a solid foundation for the analysis features.

There is a big plan, everything is happening *extremely intentionally*, and the puzzle pieces are falling into place.

Regarding the Megajolt - this is a very mature and robust system with many thousands of units world wide. The RaceCapture/Pro is our 2nd major project.

Regarding taking on big things - we are playing a big game, and we have the team to support it, with more team members to come. http://autosportlabs.com/about

[pmacduffie]

As a software engineer I'm glad you understand the amount of work it takes. Thank you.


Regarding your specific points about scaling channels, we're laying the foundation for supporting that. Exhibit A:


Here's the configuration view for the list of channels, where we're staging up that support. Again, building a solid foundation for the analysis features.

So this "channel configuration" is this part of the race capture config or is it part of the analysis tool as a chart setting? I can see both being useful..

The "config" side as a filter. Stopping something like RPM 164,958 RPM.


Or perhaps let all the trash in and let the computer filter it during the datalog import.

While these ideas are nice, I would just be happy with shrinking the chart down graphically.


Phil

[brentp]

So it's actually both, acting as the RCP configuration and for setting defaults system wide so when you create a chart in analysis mode or a gauge in dashboard mode it will automatically show the correct min/maxes and digits of precision - built in smarts.