Megasquirt III Prototype
 

Apparently, they have a prototype just about worked up, according to the ms3efi site and a grassroots article. Seems like its going to have a whole lot more inputs and outputs, USB support, SDCARD data logging and even more. That upgrade card is HUGE.

It was noted that the first version of 1.0 will be ready by summer, possibly in a price range of double of what the MSII board costs. I've been procrastinating on installing an MSII to use stock sensors, but im a little glad now that this new news has developed.

Attachment 206239

Megasquirt 3 !: Grassroots Motorsports forum: Grassroots Motorsports Magazine

Discuss?

oh man, I'd want this just for onboard datalogging. How many hours can I put on a 32GB SD-card?

DIY has jacked with this MS3 stuff for about a month according to their facebook page.

Than sounds cool no more lap top in the car at the track, but will it have larger VE and spark tables?

How the hell big of a table do you need? 512x512?

I like how they have made it an expansion board and not a totally new system. I really believe those folks at MSHQ have the end user in mind when designing upgrades rather than $$

Hydra is using 16x16 now. Most of us don't care, but if you are looking for perfection the resolution doesn't ever hurt.

edit: Or is it 24x24 for v2.6? Matt?

Damn, and I just got a MS-1 (for the second time). I was talking about resolution with a shop guy one day and he said that it really helps when you have some of the bigger cams - at least on the LSx platforms. From my limited experience with the gto, the stock cam is pretty good in a turbo car unless you're trying to squeeze out the last few % (or just want lope).

Does Hydra allow you to edit the bins though? I was under the impression they were static?

IMO above 16 x 16 unless you have a full on race engine more cells don't actually help any, especially if there's intorpolation in between them.

MSIII looks hot, It might be out in the summer but It's gonna be at least another 12 months IMO before it's close to viable for our use. it's taken 3+ years for a full release of extra code to come out for MSII!

in for astounding logic / entertainment.

So has the MS2 for the past couple of years. It was 12x12 before that, which is what the MS1 runs currently on the Extra code. Heck, the good ole' Link only had six MAP rows.

I think we're hitting diminishing returns, here. Beyond a certain point, more cells is just more tuning. It's not like the engine's VE is changing radically within the space of 250 RPM. Folks need to remember that MAP is still the primary input into the equation. Even if the VE table were 4x4, it'd still run reasonably well.


Could be, we'll have to see how things go. I'm pretty excited to see that MS3 is up and running at all, given that they're still debating how the memory is going to be mapped on the FreeEMS.

Assuming it does everything they claim (VVT, knock windowing, blah blah blah), and gets here within a reasonable space of time, this is going to be THE engine management system to have.

Its no a matter of how big you need the table to be its just that every other engine managment system Ive looked into offers much larger tables. My car runs fine with the HR code, but it would be cool to have a larger table.

In all seriousness- why?

well in an 8,300 RPM graph it would be nice to have 4 cells per 1,000 rpm rather than 1 or 2

maybe now the will have mspnp for 99-up

But why? Does the engine's VE actually change dramatically within a space of 250 RPM, or do you just want to create extra work for yourself?


That said, no idea what MS3's table size is. Probably bigger than is necessary.

See Joe's far more eloquent replies than I could muster. For our uses, beyond 16x16 interpolated cells just becomes a pain in the arse/more expensive to pay someone else to tune.

Shouldn't you be off somewhere worrying about breaking your car? :fawk:

And the FM LINK cars still put out serious power. More doesn't always equal better :)


I lost track on FreeEMS, it's a nice concept and all, but way over my understanding, it also looks a LONG way away from being useful at the moment.

The VVT/Knock stuff is MSIII V2 so another 6-9 months ontop of this summer. Still sounds a very tight timescale to me but we'll see.

I agree, once it's out, it'll be very very hard to resist, at the very least it might put pressure on other ECU manufacturers to bring prices down a tad, which is good for everyone :)

I don't know why everyone thinks they need more resolution...most people don't even use what they have effectively. Too many people have VE table with these big blocks of linear change. Make that all one step (row) since it interpolates the shit anyway. Then use that saved resolution elsewhere, like where you have non-linear VE changes (eg. boost onset, where the motor "comes on cam").

I never thought about it that way. I am surpirsed about the SD ard support myself, possibly other ECUs may start incorporating it as well.

Here's a crazy question, would this make it easier/possible to add telemetry data?

There are GPS USB antenna's and there are also readily available accelerometers (Wii remote for example). Just an idea from a MS newb.

Chris

It's possible if you're willing to write drivers for it, otherwise one component is speaking moon-language and the other is Sun Ra.

Joe, it's mostly for total nit-pickers. For instance, I'd like to have a couple more rows in the 20-35kpa range, since my light-throttle cruise is forced rich due to a lack of resolution. I've fiddled with it a bunch and could never get it right (and now I don't care). If you're adding another thousand RPM or going beyond 230kpa, it would be nice to have the same resolution as an MSII setup across a wider range.

For many, yeah, it's just unnecessary, but you can always just ignore the top few rows/columns if the dyno clock is ticking a bit quickly.

At the MegaMeet, the developers indicated it would still be 16x16. The presentations they gave are on DIY's site, I believe. Interesting stuff, and looks very promising.

Probably not.

For one, the USB port on the MS3 is a type B receptacle, typically found on client devices (DCE, for you old-timers) such as printers. Such devices typically are incapable of acting as hosts to other peripheral equipment, but only as clients to a host (ie, a PC.) Additionally, my suspicion is that this particular USB device is simply a virtualized RS232 connection. There was talk of implementing it that way at several points in the discussion, and doing so would have reduced its burden on the CPU to almost zero, whereas implementing the full-blown USB protocol in software would have chewed up considerable processor resources, which is not something you want to do in a mission-critical realtime system.

Joe hit the nail on the head. From further reading, its only a simple USB --> Serial connection.

Correct. It's basically a copy of the circuit on the eMS-Pro.

Ok, that explains the physical size of the connector, which I was wondering about. In the past, I've used a device which was packaged as a slightly oversized USB-B connector and integrated the electronics into the package. You spoke to the device in standard RS-232, and it presented itself to the host as an RS-232 port. Saved a tiny bit of board space, as it was only one device instead of two.

I can't really tell from the pictures, are they using one of the FTDI "FT232" series transceivers? Most of those are QFPs, but the only square chip I see is the processor.

I'm pretty sure it is an FTDI.