New JimStim firmware V2.0

Discuss MegaSquirt, VEMS and other non-free hardware and software here.
Post Reply
User avatar
jbelanger
LQFP144 - On Top Of The Game
Posts: 387
Joined: Sat Feb 23, 2008 8:58 pm
Contact:

New JimStim firmware V2.0

Post by jbelanger »

I have posted what follows on the msextra forum (http://www.msextra.com/viewtopic.php?f=102&t=31012) but I thought this might be of interest to people here. Of particular interest to some may be the new 360 tooth CAS patterns.

There is a new firmware available for the JimStim CPU. This V2.0 firmware will now be provided with all the new JimStim boards and kits (the JimStim board is still the V1.4) and it is compatible with all JimStim board versions.

This new firmware includes more wheel modes than before (42 modes now) and one of the invert switches has been converted to be used as an additional mode selection switch. So now, DIP switches 2 to 7 are used for wheel mode selection which allows up to 60 wheel modes to be selected through the switches (the 4 modes which have switches 3 to 6 set to "on" are either reserved or invalid). The single remaining invert switch now invert both the primary and secondary tach signals together. The wheel modes correspond to what is currently available in the MS2/Extra code as described here. In addition to the new wheel modes, the clock speed has been increased which makes all wheel modes perform more consistently and at a higher RPM limit.

The new firmware now makes full use of the serial communication capability available on the JimStim board. It is now possible to remotely configure the JimStim from a PC by using either Megatune or TunerStudio. TunerStudio is the preferred interface since there are limitations in Megatune that prevent the selection of all the wheel modes (at least directly by name). What can be configured on the PC are the wheel mode, the tach signal polarity (primary and secondary tach signal polarities can be set independently as opposed to what can be done using the DIP switches), the RPM, and the communication baud rate. One side benefit of this is that the RPM is now only limited by what the CPU can handle and is not artificially limited to about 16500 RPM by the RPM pots. The actual limit depends on the wheel mode and can be from about 4000 RPM (with the 360 tooth CAS modes) to more than 50000 RPM (with the EDIS mode).

Another new feature, is the possibility of upgrading the wheel patterns without having to change the code. There is now a small utility that takes a text file (which uses a pre-defined format) and converts it into the binary data and then sends this data to the CPU. The default wheel patterns can be modified, removed, or moved and new patterns can be created. There can be up to 240 wheel modes in theory but the actual limitation becomes the available memory. However, the wheel patterns can be changed as often as desired so unless someone needs to work with a lot of big patterns at the same time, the memory limitation is not a big problem.

The last new feature is the possibility of having a dynamic RPM control. The V2.0 firmware has a command that allows new RPM values to be sent as fast as the serial port will allow and the generated tach signal will be adjusted accordingly. This allows the creation of RPM patterns for bench testing different ECU functions. There is a small example program provided on the web site that uses this feature to vary the RPM from 1000 RPM to 12000 RPM and back down to 1000 RPM. The source code is provided and can be used as a basis to generate more patterns. Hopefully this feature will be integrated in some way in a future release of TunerStudio (thanks Phil :) ).

For more information, you can have a look at the V2.0 firmware web page.

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

Re: New JimStim firmware V2.0

Post by Fred »

Awesome work Jean! I'll have to get my A into G and get one of these things at some point. I think Aaron should get one too so he can make FreeEMS-Tuner talk to it, I'm guessing the ini is a stack simpler than a ms one? Thanks for posting it up here too.

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
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: New JimStim firmware V2.0

Post by jharvey »

Ah that looks great. I'm reading up on your release now.

I see the TunerStudio MS. Does that imply there could be TunerStudio FreeEMS? I know Fred is a fan of Java, and it appears this is well written. Perhaps a different plugin for the back-end could make this a useful starting point for FreeEMS. I don't see a note about licencing, does this fellow like GNU? Looks like a nice interface, and well rounded.

About the MS links, I'm still banned, so I can't read them, or contribute to them. Speaking of that, I'm surprised MS folks allow that on the MS forums. It notes integration of OBDII. I know that MSadmin have a strong objection about OBDII.
User avatar
jbelanger
LQFP144 - On Top Of The Game
Posts: 387
Joined: Sat Feb 23, 2008 8:58 pm
Contact:

Re: New JimStim firmware V2.0

Post by jbelanger »

Jean, I thought I was posting my own post, but I edited and saved yours and lost it, sorry :-/ Please fix if you remember what you said. Fred.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: New JimStim firmware V2.0

Post by Fred »

TunerStudio is not an open source project so any modification would have to be done by Phil Tobin (the designer).
Or illegally, he doesn't (didn't?) obfuscate it so you could just mod it yourself if you were willing. I wouldn't bother though. Writing it from scratch would be easier and more productive in almost every way.

Sorry for accidentally removing your post! :-(

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
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: New JimStim firmware V2.0

Post by jharvey »

I can't help but ponder the use of the JimStim as more than just a dia tool. I see many wheel patterns can be generated. I can't help but think of the JimStim as a dev tool. Using it can allow dev without having the actual hardware. I'm sure that's not a novel though, and I wouldn't be surprised if others have already done initial dev this way. What I wonder, could the JimStim induce some more real world parameters?

For example, I know many folks (including OEM) have noise issues, where a sporadic and random noise spikes cause pulses that are outside an expected window. I've seen in Fred's draft code, he's added window error checking to increase the robustness of the EMS. If a pulse happened outside the possible range, it acts differently, than when a pulse happens at the correct time. As well a short noise spike often won't make it past the de-bounce features often used in such circuits, the pulse has to be long enough to be valid.

If the JimStim had one or two random values that could be added to the noise of the tach signals, it would allow development of more robust signal capture.

I seem to recall jbelanger inquired a while back about what features might be handy for future versions. I'd bet this is already on the list, but if it's not, I'll toss it out there as a handy one to add.
User avatar
jbelanger
LQFP144 - On Top Of The Game
Posts: 387
Joined: Sat Feb 23, 2008 8:58 pm
Contact:

Re: New JimStim firmware V2.0

Post by jbelanger »

That's interesting because I actually did do a version which has the possibility to add pseudo-random spikes to the signal. The problem is that the JimStim CPU has a rather limited processing power and to make this really useful would require the possibility of modeling the noise characteristics such as distribution, frequency, spike width,...

It might be more interesting to introduce noise using some circuitry which would generate noise more representative of the real noise of the target environment.

Jean
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: New JimStim firmware V2.0

Post by jharvey »

I'd bet there is a way to do it. Perhaps an add-on of some sort. Perhaps it could be a stack on the existing MCU, but I'm not really a fan of that approach. Perhaps it could be an extension such that you connect to the DB37 with an extender that adds the noise.
Post Reply