M1 GPR limitations

[stevieturbo]

I see a business model where I develop M1 packages that customers want but MoTeC doesn't have the time or resources to do. I have to make the investment in the ECU's and development licenses, so I need to figure out what the market demand is for packages I might customize/create to determine the price.

I have to ask though. Why the need to "develop" something for a specific application requiring special programming and licenses to do so, when most other ecu's just simply allow anyone to do this ?

I really dont understand the whole notion behind the platform at all.

[mk e]

...but it's still a $5000 ECU so I kind of ...

And it is still about quality, not feature count.

You really, really, really, (omt) really get what you pay for.

Which part of non-functional when delivered makes it high quality?

This thing is going in a ferrari
viewtopic.php?f=42&t=1611

so I get the concept and it doesn't bother me at all that the car has no cup holder or the AC ...well suck is the only way to describe that feature.

Picture this discussion at the dealer
Salesman - listen to that engine, feel the hand stitched leather, see the very best tires!
Customer - I'll take it! Pull it out so I can dirve it home!
Salesman - Hold on there....you need to buy wheels
Customer - wait what? I see wheels right there
Salesman - no, no those are just shipping material to keep your tires in place, they look like wheel to help you imagine how nice it will be once you buy wheels.

The M150+GPR package is non-functional as sold. Yes its got some REALLY nice stuff...but it's still not functional without additional "upgrades"....so they aren't really upgrades they are simply missing/crippled features.

Almost every sensor gives you the option on analog or CAN so it's clearly possible. O2 doesn't give this option which begs the question as to why? The answer of course is that WBO2 has been a large source of revenue for MoTec but WB controllers are now really cheap so people are no longer buying the upgrade, they just connect to the input and go. MoTec's solution was to that was to claim WB)2 is included then simply kill the analog input so while it's technically true that the ECU handles WBO2, the ONLY way to make it work is to purchase additional and way over priced hardware.

Same thing only not quite as offensive on the logging. The claim is basic logging is now included which is technically true....but it's not the basic logging I used to get when I bought the basic logging option, it's sub-basic logging and to get the what used to be basic logging is still the same $375 up-charge.

So while on the surface the M150+GPR appears to be about the same price as the M800+upgades but without need all the expanders making it a better solution, it's actually the price of the M800+upgrades+expanders and still requires external boxes.....the works "bait and switch" come to mind.

[JamieA]

Guys,
Good to see such an interesting discussion here on M1. I will try to answer some of the topics raised where I can. Feel free to ask more....

The M1 ECU is actually less flexible than M800 in some ways by design. The tables in M1 are fixed to particular channels so that we are able to write code to use the output of the table that makes complete sense and is fast and efficient.

We have tried to cover how we would expect the function to work in the best and most common cases.

We are not trying to move people to Development ECU's, we are trying to produce a package which does the best possible job of running the functions required. We have very experienced ECU developers who have a thorough understanding of how this needs to work.

A development ECU is intended for someone who wants to work outside of what we would expect the common use is. We dont want to compromise the use of the ECU for 90% of customers for the 10% with unusual needs.

So for those with unusual needs, then use a Development ECU, which will cost around $1500 more than the same GPR ECU (price is country, exchange rate and region dependent but that is a ballpark figure)

when you have a development ECU, you are given full access to all of our build projects that we have publicly released (that is most of our public projects except R35 GTR and GPRP)

When you have access to the project, you can make any changes to the project that you need, such as adding in as many EGT, NLS, or other sensors as you like. you can change the control strategys, tables, axis's, basically anything.
With M1 build, we give you far more configuration that we ever could with M800. there is quite a learning curve to get the most out of build, but once you are there, it is the best thing in the marketplace by a long margin.

So if you want the ECU as designed, GPA, GPR, GPRP are all for you.
If you want to make customisations that we haven't allowed for, then a Dev ECU is for you.

Keep in mind that (allowing for regional price variances) an M130 with a Dev licence (which has the same pin count as M800) costs a bit less than an M800 with logging, Cam control, advanced functions and DBW. So an M130 Dev is actually more configurable, and costs less than an M800 with simmilar functions.

-Jamie

[mk e]

Guys,
Good to see such an interesting discussion here on M1. I will try to answer some of the topics raised where I can. Feel free to ask more....

The M1 ECU is actually less flexible than M800 in some ways by design. The tables in M1 are fixed to particular channels so that we are able to write code to use the output of the table that makes complete sense and is fast and efficient.

We have tried to cover how we would expect the function to work in the best and most common cases.

Question 1.
Looking through the GRP package I think I see every single sensor has an analog or CAN choice which the exception of lambda, that is not only CAN only but LTC only.

Is there functional reason for NOT including an analog lambda option?

So for those with unusual needs, then use a Development ECU, which will cost around $1500 more than the same GPR ECU (price is country, exchange rate and region dependent but that is a ballpark figure)

when you have a development ECU, you are given full access to all of our build projects that we have publicly released (that is most of our public projects except R35 GTR and GPRP)

When you have access to the project, you can make any changes to the project that you need, such as adding in as many EGT, NLS, or other sensors as you like. you can change the control strategys, tables, axis's, basically anything.
With M1 build, we give you far more configuration that we ever could with M800. there is quite a learning curve to get the most out of build, but once you are there, it is the best thing in the marketplace by a long margin.
-Jamie

Question 2.
My understanding was that to make changes you need BOTH a development license AND a development ECU which is more like $2800 + the $1500 up-charge to go from GRP to development ECU package.......do I have that wrong?

[Ben-S]

Question 1.
Looking through the GRP package I think I see every single sensor has an analog or CAN choice which the exception of lambda, that is not only CAN only but LTC only.

Is there functional reason for NOT including an analog lambda option?

My guess would be they want to know the calibration is accurate and the sample rate/timing is always predictable. Keep in mind there is virtually no processor power wasted on the LTC since it updates it's own status, heater, lambda value, etc. all through CAN instead of wasting resources on lookup tables, heater controls, etc. You could use a third party 0-5v analog output I guess but personally I'd rather have my ecu control my lambda sensor.

Question 2.
My understanding was that to make changes you need BOTH a development license AND a development ECU which is more like $2800 + the $1500 up-charge to go from GRP to development ECU package.......do I have that wrong?

There is no difference between a standard ecu and a development ecu besides the license. If you currently own any ecu all you need to do is buy the development license and your ecu becomes a development ecu. You don't even need to own or buy another package (gpr, gpa, etc.) the development license effectively lets you load those (except paddle shift and GT-R).

[JamieA]

Number 1
We made lambda input on M1 to suit our lambda products, the LTC (and PLM to some extent).
We didn't specifically choose to exclude lambda via analogue for any reason, rather we made it work with our products as we expect it to work.

We do not make any effort to stop people mixing and matching hardware brands, we always provide information about how to connect comms wise to other brands when they ask.

If a competitor makes a CAN lambda box, then it will work with M1 no problems. All they need to do is to transmit it using the standard lambda message format that we have used for 10 years (and is described in full in our dash software)

Number 2

If you are buying a Development ECU from scratch as a Dev ECU, you need only
1) M1 hardware
2) Development ECU license for that ECU.
That is all.

The other option is that someone already has GPR or GPA, and later on decides that they want to move to a Development ECU. In that case you already have the ECU and GPR.

So to make the transition more cost effective, MoTeC Offer customers an 80% trade in on the price of the package license already in their ECU (GPR or GPA for example) and that 80% comes off the price of the Development ECU license.
So in this example, you have this

1) M1 Hardware (that you already have)
2) GPR license (that you already have)
we trade in your GPR license
3) -80% of GPR price
4) + Development license.



That is all.

[mk e]

Number 2

If you are buying a Development ECU from scratch as a Dev ECU, you need only
1) M1 hardware
2) Development ECU license for that ECU.
That is all.

......

So to make the transition more cost effective, MoTeC Offer customers an 80% trade in on the price of the package license already in their ECU (GPR or GPA for example) and that 80% comes off the price of the Development ECU license.
......
That is all.

I didn't understand that, that's pretty nice. Still a lot of money, but it buys a very powerful solution.



I'm still troubled by the lambda question. You've now given me 2 or 3 conflicting and to be blunt nonsensical answers.

I will leave you with this thought.

MoTec makes some of the best products available and there are many very good reasons to buy an LTC.....the M1xx ECUs being intentionally crippled without an LTC shouldn't one of them.

Its frustrating and just plain embarrassing trying to explain to my friends why the $5100 ecu that does all this cool stuff and I was SOOOO excited to get, just flat can't be tuned without O2 info and it can't read an O2 senor without external upgrades or work-a-rounds.

Frustration and embarrassment are not a particularly satisfying custom experiences and you really should have thought that through better. Just sayin.......

[greenamex2]

"Its frustrating and just plain embarrassing trying to explain to my friends why the $5100 ecu that does all this cool stuff and I was SOOOO excited to get, just flat can't be tuned without O2 info and it can't read an O2 senor without external upgrades or work-a-rounds. "

Kind of agree with mk e.

The one thing that nearly stopped me buying the M130 was having to spend extra on LTC's when even the M84 can do one for free and two for not much extra.......and I only have two sensors to worry about, not mk e's TWELVE (I make that about £6000 in LTCD's.....which would certainly give my wife/bank manager a heart attack!).

Other features swung it for me but might be useful feedback to Motec management when considering future features for either firmware or hardware.

[PEI330Ci]

For those that have an M1 ECU, but don't have a dash to feed multiple Lamda to the M1 via CAN:

http://milspecwiring.com/store/index.ph ... uct_id=507

[stevieturbo]

it looks like AEM offer a 4 channel wideband controller and can communicate via CAN so should fairly easily allow you to monitor multiple cylinders at reasonable cost, or use the 0-5v outputs it offers too for simple analogue channels.

http://www.rywire.com/product-p/aem_30-2340.htm

http://www.aemeurope.com/articles.php?a ... _30-2340_1

I'm sure Innovate used to offer a multiple lambda controller too, although cant find it on their site. Dont think it ever did CAN though, and it'd probably eat sensors like crazy same as rest of their stuff.