so, I've been in contact with josh (speeduino creator). And he has this available finally, but as beta. For that kinda price, it seems like it's worth some risks. But what kinda risks should I expect being a beta tester? I know a decent amount about tunerstudio and tuning. And the Miata is still NA, so no boost issues to deal with.
I worked in product development for boats and ships. With a new product, we'd approach the point where it was ready for consumer release in asymptotic fashion.
Over time, the really dangerous, life-threatening problems would be discovered less and less frequently. The initial development stages were a lot of work, but were also very rewarding, because clear issues were being discovered and worked through. The march toward product readiness was a brisk one at this stage.
Things get more challenging, or at least challenging in a different way, later in the product development process. The new thing will never be perfect, without pitfalls that could cause an unwise user to destroy it and maybe even himself.
How good is good enough? How idiotic is the idiot in the phrase "idiot-proof?" The product development team has spent man-decades with this new thing, and they cannot even begin to answer these questions. They can install and operate it blindfolded, and also describe a dozen ways to break it.
So, these people are not qualified to tell you if the new product is worth a damn. Some real-world data is necessary for that, and that's where the beta tester comes into play.
I think you are qualified for this. Many of your posts have made me scratch my head. Others have made me shake my head. But in any case, I think that if you acquire this new Miata thing and fight through making it work, that will end up being worthwhile for them and for you.
I have beta tested all the ms versions since ms2 and nearly all the /extra code revisions. Be prepared for things to NOT work correctly, be able to notice, and provide good, detailed feedback. If this is your first speedy, hard pass.
In reply to Paul_VR6 :
Fully expecting "non OEM" quality. Things like idle, idle up, etc, are the scenarios you have to be ok with.
In reply to b13990 :
Hhhhhhwut? You're not...."up to speed" with speeduino, are you?
If it's not your daily then go for it. I mean I've been getting paid to be a beta tester so to pay to do the work for them, well idk about that.
Know your baseline, annotate any anomalies, provide as much data back to the tuner as possible, repeat. Documentation is key.
So if you want to be a good beta tester, when you find errors, you need to do your best to figure out what the problem actually is- taking massive amounts of data to show the coders where they made a mistake. Which actually puts more responsibility to the developers, too- as they need to provide you with a lot more documentation than normal.
Well, I say normal for the aftermarket. For the area that you will be developing, OEM's pass that info out handily to the calibrators, and we can figure out what needs to be recorded- even knowing what to record if there's an error in something that is a temporary term and can't be even looked at.
Doing all of that benefits both of you- the developers make a better tool, and you really, really, really get to understand how the speeduino works.
One thing I will suggest, find a really good data plotter- where you can easily have many items on a page at once and it all makes sense. Not excel- to cumbersome for your needs.
In reply to alfadriver :
This is what I needed to hear. The other issue I see is Josh is in Oz and I'm in US. So any live data dumps or remote monitoring will be difficult to line up. Assuming he labors like the average Joe.
Im willing to do the leg work there. Just might be more harder than if he beta tested Someone in Oz. OTOH, he might need testing in USA, not sure how different our miatas are from the rest of the world....
In reply to _ :
Actually, if you can work on a system to supply the data, the fact that you guys will be working on opposite times of the day may work out better. Working at the same time can be tough- rarely do we get the software people out in a vehicle the same time we can be- so you may be able to work on a pattern of work, discovery, fix and the back to you to work.
In terms of the differences- I'm not a Miata specialist, but I'd be shocked if the module differences were enough to be a problem. Other than wiring/module differences, the world Miatas are identical when you look at what Speeduino is capable of doing. Just the specific numbers may be different but operation will be the same.
Any data will be limited by the logging done inside speedy, and the speed that is available. You will (likely) be wanting to log all the time. Most of the issues I have seen with this sort of thing is quite intermittent and hard to pin down without a lot of data. I am assuming a separate logging system for cross checking isn't in scope. It can be helpful for firmware debugging more than hardware though. I am assuming that is the primary goal here.
You'll need to log in to post.
