Speedo out erratic

[Bernard Fife]

Tobmag,

I think I am making some progress on this, and hope to have some code to post in a day or so.

If I am on the right track, the problem is that we have colliding VSS and timer interrupts, and I am breaking these interrupt service routines into sections that run in a 'staggered' manner (i.e. in the 0.010 second section, all of the code runs every 0.010 seconds, but some of the code runs at 0.010, 0.020, 0.030, ... while other bits run at 0.003, 0.013, 0.023, 0.033, ... and yet others run at 0.007, 0.017, 0.027, 0.037, etc.). This allows more 'entry points' for non-timer interrupts like the VSS/comms/etc. which in turns smooths the interrupt reliant outputs.

I will put some code in this thread when I have something for you to try (I have also implemented the user duty cycle percentage fr the speedo output).

Lance.

[Bernard Fife]

Tobmag,

I have put 4.136 code here: http://www.msgpio.com/manuals/mshift/V41code.html Hopefully it will help both your speedo and line pressure issues. I haven't tested this code a lot, as I have to rebuild my test bench, which has become more than a little worn out and thus less reliable and more troublesome. I'll do that soon, and in the meantime let me know if things aren't right.

Lance.

[tobmag]

Lance,

Will test as soon as my laptop is back....hopefully tomorrow

BR//Tobmag

[tobmag]

Lance.

I have done some testing now with the 4136 code but that didnt help...
What I can see is that the output signal is still to noicy.
I also noticed that at about 1000hz I didnt need to change the time devider on the scope, that means to me that the frequency doesnt really change.
Made test with different duty cycle but makes no difference for the speedo, still only goes upto 140kph and starts moving backwards...

Frequency mentioned is input hz to the GPIO

500hz.png (9.64 KiB) Viewed 13060 times

1000hz.png (9.54 KiB) Viewed 13060 times

1500hz.png (9.73 KiB) Viewed 13060 times

[tobmag]

Some more screens, 2000hz looks very strange but was constantly repeated,,,

2000hz.png (9.45 KiB) Viewed 13060 times

2500hz.png (9.49 KiB) Viewed 13060 times

3000hz.png (9.64 KiB) Viewed 13060 times

[Bernard Fife]

Tobmag,

Did you try adjusting the filtering?

Lance.

[tobmag]

VSS input mask ?

No I didnt... but its set to 50

BR//Tobmag

[Bernard Fife]

Tobmag,

Okay, I think I need to do more work here. The issue is that with multiple timer events piling up (0.001, 0.010,0.100, etc.), the VSS interrupt is missed/late. I can fix this, but it will take a bit of work (which I will do, of course).

You could try setting the masking to zero (no masking at all), this might help (by allowing late interrupts to still be counted and averaged).

I'd also be interested to know if this is a problem in the real world rather than on a function generator. That's because the real VSS signal is much less likely to be stable and consistent enough to fall exactly on the timer interrupt schedule for any length of time. That doesn't mean it shouldn't be fixed, but might help define how much work ought to be done on this.

Lance.

[tobmag]

Lance.

I can do some more bench testing with the masking but my car wont be ready to run for at least another 2 months....

Br//Tobmag

[Bernard Fife]

my car wont be ready to run for at least another 2 months

Tobmag,

I am sure we will have it sorted by then. In addition to disabling the VSS input masking (with a zero value), you could try some 'odd' values for the VSS input (i.e. not multiples of 10, 100 milliseconds, etc., such as 1382 Hz, or 2411 Hz, ...) and see if that helps. If it does, we are on the right track.

I am not convinced this will actually be an issue in the car, but it is a good idea to make the code more robust wherever we can.

Lance.