Autosport Labs

Hi, can you confirm the name of the firmware zip file you downloaded?

What if you downgraded to 2.13.5 firmware? Make sure you install the firmware that is labeled RaceCapture/Pro MK3, not mk2.

I probably won't be able to help much in fixing your problem, but I can tell you what I wound up doing to work around it for a little bit, and I have an idea that might help you fix it.

With my unit, if I recall correctly, the line you have in your print "ESP8266 Driver] Init failed " is the same as it was on mine, and it means the wifi is not initializing - basically meaning it's not working correctly within the data logger unit. I had to send it back for repairs, and they found the wifi was defective - they wouldn't tell me in what way, so I don't know.

However, here is one thing to consider looking at. With mine, I had a rattle inside the case that should not have been there. I did not take it apart for concern of voiding any warranty. I strongly suspect that was the cause, and it might have been as simple as the WiFi antenna or card might have come unplugged. Consequently, if you aren't concerned about warranty, I would suggest taking the case off (looked easy enough to do) and look for anything that might have come loose. Otherwise, I suspect you are SOL until you can send it in and get it fixed.

Unfortunately, I wound up giving up on using the cell phone for a dash, since it wouldn't connect, and operated the camera manually. Of course, this meant i had no Tach, which was one of the biggest issues. Thank goodness, I had mechanical temp and pressure gauges and direct wired idiot lights. So, I was shifting blind, but I was able to make it work, and was able to keep an eye on the engine parameters - other than RPM of course.

From what I've been able to find out, a cell phone will ONLY connect via wifi or bluetooth (not USB), and I found that it is VERRRRYY slow on Bluetooth, and carrying a laptop in a race car isn't really an option, which is the only real option for connecting via USB - unless I'm missing something, which I've been told I'm not.

As I recall, it took me over a month from the time I started trying to get help, until I had a working unit in hand again. I am not happy with the support on these units at all. If I were to do it over again, I would probably pay the extra money and get a more expensive unit that has better customer support.

I wish you luck.

I see Brent replied. He helped get mine fixed. If anyone can help you, he probably can - just a matter of how quickly.

Hi ProtoTim35,

I'm sorry your experience didn't feel like the best possible. When we did receive your unit, we turned it around as quickly as possible around the weekend, it seemed like it did take some time to get to the point where we determined we needed to see it. We'll take it as feedback on how to tighten that response time up in the future.

Regarding bluetooth:

Bluetooth should be *lightning fast*. Here's an example video:
https://www.youtube.com/watch?v=ByPJgSU7klE

Note we are visualizing this with a fast response sensor, with RaceCapture's built-in accelerometer + gyro. Slow OBDII data or other slow data sources will not highlight the performance.

If the data appears sluggish, try a different Android device for comparison.

WiFi should have similar responsiveness; here's another demo:
https://www.youtube.com/watch?v=Lpveh34LKI8

We've poured a tremendous amount of work into ensuring the connections are both fast and reliable as possible. It is conceivable there are some combinations of tablet / phone hardware where an issue might arise; this is typically the challenge when making system A talk to system B.

If you do have some testing data and comparison between your current device and others, we welcome you to create a new thread to share your results. Thank you!

Hi Brent,

I'm glad that you will look at the response time to see what you can do. That was definitely a large part of the time consumption of getting the unit communicating with my other devices. However, I felt the C/S was less than it could/should have been when I needed the unit ASAP (and I let you know that), and it was a brand new unit and you wouldn't send out a replacement unit so I could get up and going rather than make me wait for it to arrive at your shop, and fix it. Worse, after I knew you got it, I asked how soon I could expect it, your response left me feeling you weren't in any real hurry to troubleshoot it or fix it until I let you know how frustrating that was to me. Then, yes, you did get it taken care of and shipped quickly.

Something else that I find frustrating on the unit is the Lua Scripting. I really doubt that many racers have any idea how to use it. Also, your support is nearly non-existent, and a lot of capabilities on this unit have to either not be used, or the programmer has to do tons of work to either find someone to help me, or pay someone to do it - as the one person who attempted to help me suggested. The lua he wrote didn't work either, so I gave up on it. I opted to find another way (which I still haven't gotten done yet), since it appeared I wasn't going to get the help I needed from Autosport Labs.

I'm a bit of an engineer myself (I built my prototype road race car nearly single handed from scratch, placing 2nd place overall in the final race I was in, the first weekend the car was ever on the track, after being out of the cockpit for 7 years myself). I wired the entire car, with plenty of electronics in it myself as well, and everything else worked great - except the MK3 - which only recorded one track event.

Being an engineer, I understand how it can easily be overlooked when you are describing things to other people, that they have no clue what you are talking about. Thus, to be effective in communicating, you must assume that the audience has no understanding of what you are discussing unless you know otherwise. If you are going to put something on the open market, I believe that it should have ample literature with it that explains in layman's terms (in very organized great detail) - especially great detail where there is any potential for confusion or misunderstanding) how to set it up and use it - and not just the basics, or the unit has very limited use. This unit is clearly missing a lot of essential instruction. If you aren't capable of writing instructions in detail in layman's terms, it might be wise to hire someone who can.

Another thing that is difficult is that the information available isn't organized very well, and in some cases is out of date (minor example that comes to mind - the wire color codes aren't really that important in this case, but the instructions don't match the supplied wiring). When I need help, I look all over for help on your site, and if I ever find what I'm looking for, it often isn't in what I would think would be an obvious location, but I often never do find what I'm looking for, and have to spend a lot of time trying to find other ways to get things done.

Back to the lua scripting. If you are going to require lua scripting be used, in order to get the most out of the unit, it would be VERY helpful if you were to give a tutorial of some sort in how to use it. Yes, it's nice that you have a couple of scripts in there. I was able to use one of them to get my shift light to work.
I had learned at least enough to get a couple things working. Then, the lua that the person "helped" me with caused enough trouble that none of my lua items worked, and the only way I was able to fix it was to delete the new script and insert my old lua. Even then, something was apparently wrong in the background somewhere because out of 3 times on the track, I only got one event logged - not sure how I got it - after previously checking to be sure the auto-logging was working. I then deleted all lua scripting, and the logger still wasn't working right. I'll have to do some more trouble shooting to see what I can find might be causing the issues.

Then, the analysis part of the software, I have yet to be able to analyze the one event that was recorded. I know it was recorded because it has a descent size log file. I can't find any instructions on how to analyze it. Am I supposed to analyze it while the card is in the MK3, and the laptop hooked up to the MK3 via USB, or insert the log file in a USB card reader? I've tried both, but can't get any data out of it.

After considerable monkeying around with the unit, I had previously been able to at least read some data from a previous log file, but this one it shows no values when I open the file. It shows the file there, but I have yet to find a way to display the data in any form.

This unit should NEVER be this difficult to use. I have to say that I haven't tried it since the night of the race because I've been too busy. I'll try some more, but the fact remains, I spent about 2 hours trying to open the file, and gave up and went to bed.

I am quite computer literate, and rarely ever have any problems with typical computer related issues. I understand computers well enough that I used to write a lot of HTML coding, and have built several computers, do all of my own computer maintenance - hardware and software - both android and Windows based. But, this MK3 just drives me crazy trying to get it to do what I want. Is the MK3 that much different from Android and Microsoft platform type usage? If so, is it really necessary to be that different?

I don't know what it is, but if you want this unit to succeed very well, I recommend that you find a way to make it user friendly, and give ample instructions, and good C/S. I would love to see it do well, because it looks like it's very capable, but at this point, I see it as more of a very time consuming, and very frustrating boat anchor than a useful unit.

So, absolutely, this has been a very frustrating experience that I'm not sure will end until I give up and get something different. If it was just more user friendly and had better C/S, I think it would be a tremendously better unit. One thing that would help a lot would be to have help files loaded in the program, so when the user has problems, they can click an icon (gear or ? for example) and helpful instructions would pop up. Another thing would be to have a wizard for doing the lua scripting. That would make it so that the user could do the scripting without hours and hours of trying get things to work, and not really understanding what is needed to make it work. I understand a little bit about it now, after several hours, but certainly not enough to do very much with it. I think that's crazy to think that the average user would know how to use a language that I personally hadn't even ever heard of before the MK3. I guess a lot of gamers understand it, but how many race drivers are gamers that write their own code?

These are just some things you might want to think about if you really want to make your product successful. Without the necessary support, in so many areas that it is currently lacking so badly, I don't expect to see these units ever gaining the popularity they could achieve.

Hi, Thank you for the feedback, it is appreciated.

We are not ready to showcase it yet, but we are working on a major improvement to the analysis capabilities. We will unveil this soon.

What function are you needing Lua scripting for? CAN mapping, OBDII mapping, and Lap timing do not require scripting, which represents 90% of the systems capability.

it appears my post didn't get posted for some reason, so I'm posting it again. I'm glad I copied it before trying to post it. Or, maybe it's delayed, and it will be posted twice for some reason? Anyway, here it is. Thanks for any help on this.

I was wanting to have my shift light to be able to do "normal" up-shift advisory lights, and down-shift lights. The up-shift lights, I was wanting them to have the initial sequence (levels one and two by design, I wired together as one), with one level at 10,500 RPM, and level two at 10,800 RPM. Downshift, I'm not picky about which lights are used, and I can adjust all values as i find values I prefer), I would like either (one and two together) or 3 to be on between 7,000, and 9,000 RPM. I would also like to have my gear position displayed. I was able to program that into the analog sensor, but the map doesn't have enough positions, so I had to leave two gears out. I was hoping lua could be used to fix that.

Below is the scripting that MikeD sent me that never did worked, so I deleted it.
I supplied him the gear voltage values, and decided later that I would rather use the above RPMs for the shift lights. I had also requested that the downshift lights be associated with throttle position, which might be at least part of the problem with it not working, and have since decided to leave throttle position out of the equation, to simplify it, and to help avert potential issues that might be associated with it.

I had forgotten I can control the auto-logging function via the internal switching, so that scripting isn't necessary, so it won't need to be written in. I wonder if there could be some sort of conflict between the below scripting and enabling or disabling the auto-log via the internal switching - even though the scripting is no longer there.

These are some of the issues I've been dealing with, and with or without assistance, i believe I will get it all working at least close to what I want eventually, but I would appreciate any help I can get.

The lights don't need to blink. In fact, if I remember right, I hadn't even thought about it. However, that might be a good idea, since a blinking light often catches the eye better than a solid light.

For the gear indicators, he said there is no way of displaying "N" for neutral, so he set "0", which works for me. I thought it would be helpful for you to know the purpose of the "0".

blinkRate = 10 --blinkfrequency in Hz

setTickRate(25)
gearId = addChannel("Gear", 10, 0, 0, 6)
LastUpT=getUptime()
blinkTime=0

function onTick()
looptime=getUptime()-LastUpT
LastUpT=getUptime()
local speed=getGpsSpeed()
if speed > 20 then
startLogging()
elseif speed < 15 then
stopLogging()
end
shiftlight()
gearcalc()
end

function shiftlight()
local rpm=getTimerRpm(0) --read RPM
local blink=1
if blinkTime > (1000/blinkRate) then blinkTime=0 end
if blinkTime > (350/blinkRate) then blink=0 end
blinkTime = blinkTime+looptime
local led1=0
local led2=0
if rpm > 7500 and rpm < 8500 and getAnalog(0) < 15 then --assign TPS input
led1=1
end
if rpm > 10500 then led1=1 end
if rpm > 11000 then led2=1 end
if rpm > 11400 then
led1=blink --start blinking
led2=blink
end
setGpio(1,led1)
setGpio(0,led2)
end

function gearcalc()
local gearvolt = getAnalog(3)
local gear = -1
if gearvolt > 1.61 then gear = 1 end
if gearvolt > 2.15 then gear = 2 end
if gearvolt > 2.75 then gear = 3 end
if gearvolt > 3.50 then gear = 4 end
if gearvolt > 4.19 then gear = 5 end
if gearvolt > 4.70 then gear = 6 end
if gearvolt > 5.00 then gear = 0 end
setChannel(gearId, gear)
end

Hi,

What you describe sounds like a cool application for Lua scripting - and something that highlights the powerful extensibility of the RaceCapture system, allowing very user-specific customization to the system that would not normally be part of the standard firmware.

We've been amazed at some of the creative things people have come up with - stuff we just could not imagine to include as a standard feature - and things that are very specific to that customer. Customizing the behavior of the system via scripting is one of the most powerful and innovative parts of the RaceCapture system.

We use Lua scripting to test new ideas, and if they become popular enough, we raise them to first class features. Example: Automatic Logging control, Automatic Camera control, and soon, control for ShiftX2/3 directly via the app/firmware. See: https://www.autosportlabs.com/help-beta ... ed-alerts/

Happy to help with your script. However, would you please make a post for this under the Lua scripting section, and we can follow up there? Just so we can keep this thread on topic for things related to WiFi and Bluetooth.

Thanks!

Hi ProtoTim35,

I spent a fair bit of time providing you as much help as possible, and answered all of your questions... however it seems that you never got to the point where it would run correctly... in fact I never provided you a working configuration but just an example script of how your script could look like... The script that I posted in the other thread viewtopic.php?p=28969&highlight=#28969 worked for me 100% sure, because I had it running on the bench exactly like this (just with simulated RPM and TPS values and not real sensors as we didn't talk about your sensor config but only about how the script may look like).

Now for some special functions to make them work and troubleshoot it also needs some effort from your side as well as feedback, at least a feedback that it doesn't work because of whatever reason... that feedback of yours seems to have arrived only accidentially right now because you posted some of your troubles, but you never came back at the time when we were in contact.

Now if you want then I will help you once more, we can follow up in the thread linked above, as that is the correct place.

Please just answer one question here:
What do you mean with the quotation mark around the word HELPED as you wrote

Then, the lua that the person "helped" me with caused enough trouble that none of my lua items worked...

I'm no native speaker but when someone just reads your post then at least in my country the quoation mark would not mean something good in this context but it rather looks like I f*cked you up... so there is your chance to educate me on what you mean.

Finally regarding the BLINK function (that you didn't even requested): yes, I played a lot with the script to also integrate a dedicated blink function, so that visibility of the shift lights is even better.... I'm always striving for the best user experience, therefore it makes me a little sad that I never heard back from you at that time, in whatever way...

Mike, thank you for being a great example of a community member supporting other members. This endeavor is built around a collective supporting each other with ideas and help that can go far beyond what just we can do and imagine.

In one recent example in the Lua scripting section another community member made a simple and effective script for recording Max RPM, with a GPIO trigger to reset. There's no way we could've predicted that kind of requirement, much less make it a built-in feature of the system. The Lua scripting allows users to extend the capabilities of the system without changing firmware, and we're just thrilled to see the variety of ways it's being used.

Thanks again!