JimStim Wheel Pattern Issues/Inaccuracies

Discuss MegaSquirt, VEMS and other non-free hardware and software here.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

JimStim Wheel Pattern Issues/Inaccuracies

Post by Fred »

EDIT: Fred-verified pattern library online now: viewtopic.php?f=6&t=1344

Issues below are fixed, as are some others. Performance limitations of JimStim+Pattern combos noted.

Please report other JS pattern issues in this thread and I will add them to the errata and/or provide a replacement.

Hello Jean and James,

It is now 308am, and I've just been trying to use my JimStim to avoid cranking over an engine at this time. I have to say, I'm a bit disappointed in the 4and1 pattern labeled "4/1 CAS" in mtx at least. Attached are some datalogs of it using the FreeEMS LA function and cutecom to record the stream:

http://stuff.fredcooke.com/Screen%20sho ... 2%20AM.png
http://stuff.fredcooke.com/Screen%20sho ... 3%20AM.png

These were taken from 0 and 1 files (not in order, unsure of order) from this archive:

http://stuff.fredcooke.com/ticks.vars.out.jimstim.tgz

The real pattern, measured from a vehicle without spark plugs is as follows more or less:

http://stuff.fredcooke.com/high.res.4an ... .trace.png

Anyway, for proper testing with all edges involved, you need that CAS pattern to be accurate. My code won't even sync on that, let alone give good RPM readings and scheduled times.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
jbelanger
LQFP144 - On Top Of The Game
Posts: 387
Joined: Sat Feb 23, 2008 8:58 pm
Contact:

Re: JimStim Wheel Pattern Issues/Inaccuracies

Post by jbelanger »

The JimStim patterns have been developed to test and work with the MS decoder. While an effort has been done to have the patterns reflect the real ones, there are limitations due to the JimStim code, the MS decoder code, the limited (or total lack of) accurate data, or a mix of all these. There is also the fact that the same generic pattern can be used for different models and manufacturer where the actual positions are different but the relative positions (and of course some key absolute positions) are shared.

So the patterns will work with the MS decoder but they may not work with another ECU. And I don't think there has been any claim to the contrary. While I understand your frustration, I assume you can see why this was done this way. Moreover, you can add/modify the patterns to suit your purpose.

So if you can derive the exact position of all edges from your posted traces then you can generate the same pattern from the JimStim. And if you have problems deriving the positions, you'll have one example of why the patterns may not always be exact. Another issue is that the JimStim CPU is not that fast so if you have edges that are apart by less than a few degrees, you'll have stability issues at a rather low RPM.

Jean
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: JimStim Wheel Pattern Issues/Inaccuracies

Post by Fred »

Yeah Jean, I totally understand all of that, but the reality is, that the ms decoder code could be broken if being tested mainly with this! Also, if it's not using some of the state information available from these CAS units, then it sucks at sync, and probably has less scheduling resolution available too. No surprise I guess. I should never have expected any ms code to be thoroughly or well done :-)

Anyway, I put this up as an opportunity to fix the defaults. It should be possible to make it pretty accurate at least at low rpm, shouldnt it? As for phase, these CAS units are identical across different vehicles and engines and manufacturers, I've had them in my hand, mazda, mitsi and hyundai all use them. There are two varieties only, and the Hall one MAY be different to the optical one, and if so, I will include two decoders in FreeEMS for that labeled appropriately. If you want to avoid doing any work to include the correct (for optical, which is the majority) pattern into jimstim, take a look at the eventAngles array in the Mitsi4and1-CAS.c decoder. They are done modularly, and the figures in them are vehicle tested as of yesterday to produce good stable RPM figures when using the last edge to calc from (this technique sucks, but the first RPM got by the decoder will always be done this way because its the first info available, subsequent ones will be done in a nicer way.

As for the close edges, yeah, fair enough, but if the edges are close, then they are close, and that's how it is. i think 18 degrees was the narrowest gap? In any case, it's morning now, so I can test on the real deal again :-)

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: JimStim Wheel Pattern Issues/Inaccuracies

Post by Fred »

My current values which are as close as possible for an optical sensor are 69 for an outer slot, 111 for an outer solid, 526 from the start for the inner slot beginning and 140 long for the inner slot. The start is the beginning of the outer slot that arrives just after the inner one. The main feature that is badly wrong is that the fourth outer slot should be contained within the inner slot. If that is true, and the offset within is close then it should function OK at static RPMs.

I've heard my engine do some funky shlt on the 4and1 4 year old ms decoder, but that could be for many reasons. However, if it was developed against the jimstim, mainly, then that could be a big factor too...
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
jbelanger
LQFP144 - On Top Of The Game
Posts: 387
Joined: Sat Feb 23, 2008 8:58 pm
Contact:

Re: JimStim Wheel Pattern Issues/Inaccuracies

Post by jbelanger »

The MS decoder works correctly and the JimStim signal is correct for validating it. As far as I know, the decoder looks only at one edge of the outer slots and the state of the inner slot at these outer slots edges.

I'm not saying this is optimal or not in either the MS or the JimStim implementation but both work as intended for their purpose in this specific case. So your issues would have been caused by something else either in the code, the hardware, your configuration or your installation.

I can appreciate that the pattern as it is in the latest release is not true to the real signal for all edges and that this may be causing you issues. I am also willing to look at correcting this in a future release but I don't think discussing the MS code is relevant or necessary here.

In the mean time, you can update the JimStim pattern if you have access to the JimStim serial port. I can even give you some pointers on how to do that if needed.

Jean
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: JimStim Wheel Pattern Issues/Inaccuracies

Post by Fred »

Vehicle runs on FreeEMS today, Jean, no need, I have a real live test car now ;-)

If the code works like that, OK, but that means it is, by definition, slow to start! There are 5 distinct opportunities to start sync from 10 total events, if ms is using only one edge, it is not doing the best job it can, and that, is the end of the story.

I think while discussing this decoder and this emulator in this non-free section ms implementation observations are pretty relevant, but if you disagree, you'll hear nothing further on it from me in this thread.

In any case, if it is using state, and not flaggedness for sync, then it may not be working correctly. Didx you look at the higher (not high, just higher) screen shot??? it shows TWO inner pulses, and that is no good no matter how you look at it.

In any case, it's fine. FreeEMS will soon have self emulation capabilities, which will be really good for anyone to bench test with minimal hw fuss. Thanks for all your efforts getting to this point, Jean, you have no idea how much I appreciate them!

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
jbelanger
LQFP144 - On Top Of The Game
Posts: 387
Joined: Sat Feb 23, 2008 8:58 pm
Contact:

Re: JimStim Wheel Pattern Issues/Inaccuracies

Post by jbelanger »

Fred,

You're right that the MS decoder won't sync as fast as it could since it could take up to 2 full rev to do it. So if FreeEMS can improve on that then it's a good thing. But are you taking angular information from all the edges? That may not be as good because there may be more variation but I don't know if that's the case here.

As for the two inner pulses, I have no idea how you got that but that's not the pattern in the code. It's either a display problem in whatever you're using or some other problem but that's not how it should be. The second picture is what it should be.

Jean
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: JimStim Wheel Pattern Issues/Inaccuracies

Post by Fred »

Yes, it is a good thing :-)

Currently the RPM and ADC stuff will run on either only leading edge of outer OR only trailing edge of outer, not both, otherwise map would vary too much. However during initial sync and starting there is no information for that, so the first RPM figure is taken from the previous event angle and elapsed time. This ONLY occurs at sync time for faster initial info. Output events can be scheduled on any edge, which I think is reasonable as they are physically connected and more = better in that case, unless there is variation, which I strongly doubt. If there is variation, in a consistent way, multiple identical code variants can be built with only the header angles differing.

As for the two inner pulses, you MUST trust me, Jean, that is what the JimStim was putting out! I have NO idea how/why the device/code would do that, but my recording mechanism is foolproof and totally passive, WYSIWYG. Hence I was a bit confused/upset at that time of the morning to see that on my screen...If you don't wanna investigate/fix, no probs, I don't mind much, I have physical CAS units laying around and access to drills, oh, and that running truck out the front ;-)

Anyway, discussion of the 4and1 pattern is probably done and dusted, do what you wish with the info, including nothing :-)

The thread can hang around and I'll log some more patterns to see if they are dodgy or good and post here.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
jbelanger
LQFP144 - On Top Of The Game
Posts: 387
Joined: Sat Feb 23, 2008 8:58 pm
Contact:

Re: JimStim Wheel Pattern Issues/Inaccuracies

Post by jbelanger »

Having the time scale on this would be useful. Also, using different RPMs to see if that is related to it or if you always get the same pattern. Finally, just make sure the DIP switches are correctly set :)

I'm curious to know how you could get such an output from a correctly functioning and configured JimStim. I can accept and explain some limitations on the pattern accuracy but an obviously wrong pattern is not acceptable.

Jean
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: JimStim Wheel Pattern Issues/Inaccuracies

Post by Fred »

The files are available, it's approximately 1000 samples per second, load them and have a play. you can get a better time frame from looking at the byte count between the packets that have significant changes in them. IE, the stream is at 115200 (see the freeems source for more accurate timing) and you can calculate the RPM of the signal seen by the pins from that :-) i'd hazard a guess at 5k for the dual tooth one? Purely a guess, though. I hope that helps! :-) The four logs ARE different RPMs, too. If when things settle a bit I can do some testing for you, I will, but I can't see why you can't fire this up and get it to do it for you, unless my 2.0.3? chips has different firmware to yours? Or the settings somehow matter? Good luck! :-)
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Post Reply