Test scenario:
VRRSIM running on DOS v6.22 on P3/550 desktop.
Config software running on seperate laptop.
MJLJ connected to EDIS6 module, no coil pack connected.
Tachometer (as used in car) connected MJLJ tacho output.
MJLJ and tacho powered from common 13.8V 20A power supply.
When varying the RPM output from VRSSIM the config tacho display and the real tacho correspond very closely.
When either spacebar (pause output) or Q (quit) are selected in VRSSIM the real tacho drops to zero exactly as expected but the config tacho display simply stops tracking the input and remains displaying the last input.
Example:
VRSSIM is set at 3000RPM, real tacho and config tacho display both show 3000.
Press Q and the config tacho display continues to display 3000 (or as close to that as it happened to be at the time) whereas the real tacho drops to zero.
v3.1.0 configurator bug
Moderators: JeffC, rdoherty, stieg, brentp
configurator tacho display
I think I remember seeing this effect with the old Java configurator, so it could be a 'feature' of the MJLJ firmware. Maybe the RPM value is not updated when there is no PIP signal from the EDIS?
configurator tacho display
I do believe you are right!
Seems that on loss of the VRS input there is no update to reflect an RPM value of 0.
It doesn't appear to affect anything adversely so not to worry.
An item to put on my list for a cold winter night going over the source code.
Seems that on loss of the VRS input there is no update to reflect an RPM value of 0.
It doesn't appear to affect anything adversely so not to worry.
An item to put on my list for a cold winter night going over the source code.
Does anyone have v3.0 and can test?
If not then I guess a re-install of v3.0 might be necessary, at least on a temporary basis.
On v3.1 the runtime data does change as expected with MAP input, provided there is some valid VRS signal to EDIS.
Bench-test run with VRSSIM giving any specific fixed RPM and varying the pressure applied to the MAP sensor results in the display tracking correctly.
The pressure gauge display works as expected regardless of VRS or even the presence of an EDIS module.
Can't confirm TPS since I don't use it.
I suspect it is an artifact of the firmware that has been there since day one and hasn't been introduced with v3.1
It's just that no-one has happened to use VRSSIM to drive the EDIS module while using another PC to display the MJLJ RPM while verifying the accuracy/compatibility of a real tacho.
I wouldn't have done it either except that the real tacho has a complete replacement driver board of my own design in it so I'm always interested in testing it against any available source.
Since it isn't detrimental I don't feel it's worthwhile pursuing, just something to be aware of and maybe fix sometime in future.
If not then I guess a re-install of v3.0 might be necessary, at least on a temporary basis.
On v3.1 the runtime data does change as expected with MAP input, provided there is some valid VRS signal to EDIS.
Bench-test run with VRSSIM giving any specific fixed RPM and varying the pressure applied to the MAP sensor results in the display tracking correctly.
The pressure gauge display works as expected regardless of VRS or even the presence of an EDIS module.
Can't confirm TPS since I don't use it.
I suspect it is an artifact of the firmware that has been there since day one and hasn't been introduced with v3.1
It's just that no-one has happened to use VRSSIM to drive the EDIS module while using another PC to display the MJLJ RPM while verifying the accuracy/compatibility of a real tacho.
I wouldn't have done it either except that the real tacho has a complete replacement driver board of my own design in it so I'm always interested in testing it against any available source.
Since it isn't detrimental I don't feel it's worthwhile pursuing, just something to be aware of and maybe fix sometime in future.
Installed v3.0.0 firmware and used v3.0.0 configurator.
No detectable difference to the behavior exhibited in v3.1.0 so it would appear to be an artifact that has been there for some time.
Re-installed v3.1.0 and used v3.1.0 configurator to re-test.
I don't think I'll be using the option switch anytime soon - currently one map is being treated as 6 cylinder and the alternate as 4 cylinder!
Luck would have it that at this point the car has been trailered to the test track so only the primary map has actually been used with the car mobile, so no chance of mishaps or damage.
I will be doing some very extensive testing with an accurate mockup of the installation before trusting v3.1.0!!
No detectable difference to the behavior exhibited in v3.1.0 so it would appear to be an artifact that has been there for some time.
Re-installed v3.1.0 and used v3.1.0 configurator to re-test.
I don't think I'll be using the option switch anytime soon - currently one map is being treated as 6 cylinder and the alternate as 4 cylinder!
Luck would have it that at this point the car has been trailered to the test track so only the primary map has actually been used with the car mobile, so no chance of mishaps or damage.
I will be doing some very extensive testing with an accurate mockup of the installation before trusting v3.1.0!!
with the map switching know that whole independent configurations are switched in and out. think of it as two separate personalities.
what happened in your case is that you did not set the cylinder value in the secondary map. to do this, switch to the other map, load the config from the controller (if it didn't do it already) update your values, write to the controller and flash as you would normally.
Aside from the new features, 3.1 offers better rpm calculation stability and bug fixes.
what happened in your case is that you did not set the cylinder value in the secondary map. to do this, switch to the other map, load the config from the controller (if it didn't do it already) update your values, write to the controller and flash as you would normally.
Aside from the new features, 3.1 offers better rpm calculation stability and bug fixes.
Re-installed the v3.1.0 firmware and now stores cylinder data OK. No idea why!!
RPM gauge display still doesn't zero on loss of VRS and in fact doesn't initiallise as zero. That would suggest that the firmware doesn't update the current RPM status at all unless there is a VRS signal present. Can't see that as being a significant issue, just something to be aware of.
btw, using VRSSIM on a P3/550 the limit seems to be about 5000 where MJLJ loses the signal. That would be a combination of too slow a PC and the rather basic VRSSIM interface circuit.
RPM gauge display still doesn't zero on loss of VRS and in fact doesn't initiallise as zero. That would suggest that the firmware doesn't update the current RPM status at all unless there is a VRS signal present. Can't see that as being a significant issue, just something to be aware of.
btw, using VRSSIM on a P3/550 the limit seems to be about 5000 where MJLJ loses the signal. That would be a combination of too slow a PC and the rather basic VRSSIM interface circuit.
Last edited by aarc240 on Sun Mar 04, 2007 11:41 pm, edited 1 time in total.
VRSSIM
That's interesting. My EDIS 4 seems to work ok up to about 8000 RPM using a 100MHz pentium, so I would have expected it to work better on your P3/550. There is considerable jitter on the signal at high RPMs though. I am planning a new version of the VRSSIM software - this will use the timer interrupt and should provide a much more accurate signal regardless of PC speed. Haven't had time to do much towards it recently, but hopefully it will be done soon.aarc240 wrote:btw, using VRSSIM on a P3/550 the limit seems to be about 5000 where MJLJ loses the signal. That would be a combination of too slow a PC and the rather basic VRSSIM interface circuit.