2.x JimStim Support Request

MegaTunix is a cross-platform tuning application written and maintained by David J. Andruczyk. Discuss all things MTX here!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: 2.x JimStim Support Request

Post by Fred »

With freeems we can automate tuning in a different way by swapping out the core vars reader and pulling ADC values in from the serial port just as if they were real. I'll try mtx + jimstim + ms2e 303x later :-)

Great work, Dave! :-)

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!
dandruczyk
LQFP112 - Up with the play
Posts: 100
Joined: Sun Apr 06, 2008 6:30 pm

Re: 2.x JimStim Support Request

Post by dandruczyk »

I've finished up dynamic RPM control and don some testing on Fred's box. it appears to work , more testing to follow after he plugs in his freeems and we can see if rpm is sweeping or not.

Jean: wouldn't it be better instead of using "i" for interactive mode then streaming RPM values, to just send the rpm values in normal mode, as in that way i can STILL get realtime data back where as i can NOT do that in interactive mode, the only negative i can see is that the number of RPM changes per second would be lower due to the increased overhead of sending W+offset+highbyte, W+offset+lowbyte, i.e. 6 bytes per rpm change vs 2, but with the added option of slipping in a rtvar request, though it may not be needed.

-- David
User avatar
jbelanger
LQFP144 - On Top Of The Game
Posts: 387
Joined: Sat Feb 23, 2008 8:58 pm
Contact:

Re: 2.x JimStim Support Request

Post by jbelanger »

David,

The idea was to reduce the overhead as much as possible so that you could simulate the smoothest transistions possible.

You can still use the non-interactive mode but it can at best be 3 times slower (but that may be sufficient). As for getting the realtime data, there is no true realtime data from the JimStim and it pretty much mirrors what you set so not having access to the latest data is not a real problem.

Jean
User avatar
jbelanger
LQFP144 - On Top Of The Game
Posts: 387
Joined: Sat Feb 23, 2008 8:58 pm
Contact:

Re: 2.x JimStim Support Request

Post by jbelanger »

I should add that the logic for RPM change in the JimStim is as basic as it can be, i.e., when the new RPM is received the next computed interval will reflect this new RPM.

So if you want to have a more realistic RPM variation, you want to have the smallest RPM increment for each new RPM value transmitted. That's why the lower overhead is a desirable feature.

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

Re: 2.x JimStim Support Request

Post by Fred »

My thoughts too. I'm awake now, and shall go downstairs and give it a whirl :-)
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: 2.x JimStim Support Request

Post by Fred »

OK, on 4g63 rpm below 60 do not work, I assume this is a math issue in the JS firmware? Possibly a lack of logic to configure timer to max if rpm below X? It's most likely a design decision to keep the code fast, which I can accept. It'd be nice to have it documented, either the math, or the limits for each wheel before the pattern deteriorates (for non even patterns) etc.

MTX has some issues too, or the JS does, or both.

If you set:

sweep start = 100 (higher than 60...)
sweep stop = 16000
time = 1 (what unit is this? decimals ok?)

You can make it work with step size = 1 - 9 but not higher. If it's higher it just does nothing or defaults to the pots or something. If you go high, eg 10, and then low again, you get nothing. You need to go to 1 again, then start it, then back to whatever above one, then start it. When it's not working, the red light is going, so stuff, something, is being sent. And nothing is being received (no green light).

Additionally, because the runtime tab can't show the RPM from the normal feed, can we have a counter on the sweep control screen showing where it's at? Or at least, where it thinks it's at. Then it's in one place, too.

Feature wise, I know when you asked I said "do something more important" but while I'm thinking about it, I'll post, how about just a file that is read in and the steps inside are executed in sequence? it could literally be as simple as number newline repeat. The number could be rpm or rpm step. RPM would probably make the most sense? How often does it update the device? What happens when you set time too short? does it just go as fast as it can? it'd be nice to set something like 0 and have that mean "fast as possible".

How about logging what was done and showing it in the log graph? Kinda boring now, but if you accept rpm sequence files of some sort, then it would be nice to see it visually over time.

OK, I'm out of thoughts. I'm not going to have my jimstim back online until Sunday or late saturday night nz time. Probably best to work on something else in the mean time unless you can convince someone else to help you test?

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: 2.x JimStim Support Request

Post by jbelanger »

The 60 RPM lower limit was a design decision to simplify the timer configuration and avoid some inconsistencies when changing the pre-scale. As for the rest, as far as I can tell it's all external to the JimStim. It will handle any data that can be sent to it at configured data rate.

By the way, the data rate can be changed from the default 9600 baud up to 57600 baud. But as you increase the data rate, you also increase the interrupt servicing time so that means you can add some jitter and ultimately you will lower the RPM limit of whatever wheel pattern you're using. That's also why it is difficult to give a hard maximum for each pattern because if you simply send one value to the JimStim you'll get a significantly higher maximum than if you're constantly sending data and/or requesting data logs. That's where it was interesting to see the difference between MT and TS because MT stops requesting real time data when a configuration window is open where as TS always requests data which slows things down.

And Dave's new CPU is on its way (with a spare).

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

Re: 2.x JimStim Support Request

Post by Fred »

OK, that's good to know :-) I guess Dave should make the box not accept values under 60 except for 0 then. Just to avoid user confusion (like me!).

I knew about the baud speed and (obvious, to me, anyway) associated downsides. It's interesting that the pulling data out of it screws it up slightly. Dave should probably make it switchable, if it's not already, to obtain a jitter free pattern where possible and when the user desires.

I guess with a higher data rate we could more smoothly ramp up and down the rpm and at lower values of rpm the extra isr load from uart wouldnt make much difference, or at least, would be worth it in some circumstances.

Good info, Jean, thanks for the feedback/support! :-)

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!
dandruczyk
LQFP112 - Up with the play
Posts: 100
Joined: Sun Apr 06, 2008 6:30 pm

Re: 2.x JimStim Support Request

Post by dandruczyk »

Committed and pushed limit fixes for min rpm.

The way it works is follows:
Set min and max RPM
Set the rpm STEP (this is the granularity of the sweep (i.e. the "resolution"))
Set the sweep TIME, i.e. how many seconds between the start and ending RPM's, this allows decimal places(to a tenth of a second). MTX will figure out how often to feed new data to the jimstim. Since the jimstim runs at 9600 baud, thats about 960 bytes/sec, and each update takes 2 bytes, so that's about 480 theoretical updates/second max, assuming the jimstim can handle that rate, and there's no overhead whatsoever. I have megatunix configured to limit this to about 100 updates/sec theoretical max. If you set something unreasonable, like

1000 - 10000, 1 rpm delta per step in 1 second, (9000 updates/second), mtx will update the controls to suit the max update rate THEN execute it.

I have added a entry showing the "commanded" rpm as well.

I do NOT like the baud rate change ability in the gui, as if you do that mtx will no longer be able to talk to it without editing a config file to reconfigure the baud rate. (/usr/local/share/MegaTunix/Interrogator/Profiles/JimStim/details.cfg). I'd prefer to remove that option entirely (from the gui at least), as you know some idiot will do it thinking higher is better, and then lock themselves out of the unit.


Jean: is it possible to reprogram (i.e. reflash) the jimstim cpu via the ftdi cable?
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: 2.x JimStim Support Request

Post by Fred »

At the risk of having my head removed, how hard would it be to reconfigure the serial port to a different speed and rewrite the config (which seems to get overwritten anyway, i made some by-hand changes and they got nuked!! :-p)? It seems like you could just pass a message to whatever handles that and have it quickly re-init and carry on. Maybe something structural in mtx means thats not possible, but...

As for reflash, no. I believe that A (from above post) it's a different clock rate B you need a bdm C the code/binary isn't available anyway. I asked James the same question several days ago.

Thanks for the explanation and fixes. I'll try them out soon :-)

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!
Post Reply