Fred's firmware development diary comments thread

[Fred]

Fair enough :-)

[davecramer]

Serial communications options on a mac

http://hints.macworld.com/article.php?s ... 9133825654

I actually use zterm, while not a great app it works

minicom works as well.

Dave

[jbelanger]

What's the point in going with 0.02 degree of timing resolution? What are the actual requirements for this? And I'm not being facetious but I simply don't see the point unless you're thinking of doing direct injection and even then I'd be interested in seeing actual requirements.

Jean

[Fred]

This is the granularity of the calculations in the scheduler. IE, if the resolution was 10 degrees it would step by that much and never be in between, and so on. 0.02 is the smallest round number that fits inside 16 bits, there is no need for it to be this fine, but no or very small cost to doing this over any other arbitrary granularity. I hope that answers your question suitably. :-)

[jbelanger]

I understand that and it was obvious that this was to have the finest resolution in a 16-bit variable. I can see the use in doing computation using the finest resolution possible to minimize any computation errors but my question is more related to how you use this value. Are you going to try to schedule events at that resolution and what impact does using this have on other computations and processes down the line.

It's just that you seemed so concerned about saving memory and going through the (desired) software development process of getting requirements for the timing tables yet you seem to just go with that resolution for the scheduler just because it fits. I may well be wrong since I haven't looked at the code at all or anything related to it but hopefully you see my point. A 0.02 degree resolution represents 0.417us at 8000RPM so it's definitely not something you'd use for an angle clock for example (not that I'm saying you would).

Jean

[Fred]

It's worth noting that my diary thread contains things from meta to micro and everything in between. I talk about tiny code implementation details and broader issues. If you read this garbage that I write, which you seem to, then you know that :-)

and what impact does using this have on other computations and processes down the line.

This is the end of the line! :-)

It's just that you seemed so concerned about saving memory and going through the (desired) software development process of getting requirements for the timing tables yet you seem to just go with that resolution for the scheduler just because it fits.

This is an internal implementation detail. I can change the multiplier to any number from 1 - 91 (or is it 92?) and it will continue to work the same, just more or less well... The requirement was determined empirically when I could not specify the angles of the decoder events accurately enough to give reasonable RPM calcs on small angle differences because the 0.5 degree difference (worst case) was a sufficiently large percentage of such small angles to screw up the numbers entirely. I determined this a month ago, maybe more, and posted about it then. You didn't comment then, though :-)

Fred.

[MotoFab]

I determined this a month ago, maybe more, and posted about it then. You didn't comment then, though :–)

As you do all the determinin', it may not have mattered if he had. :–)

Jim

[Fred]

As you do all the determinin', it may not have mattered if he had. :–)

Others are always welcome to do ground work, research and provide genuine fixes and contributes ;-)

All I did was take readings with code and data and figure out that there was no possible data point that was perfect, both 68 and 69 were wrong, despite mitsi/mazda recommending 70. 68.7 will be my next guess, probably. I can't fine tune it without a real sensor, though.

Fred.

[Fred]

I have to say, it was really nice the night before last to adjust the decoder to engine offset (ms calls it "trigger angle") by 0.02 degrees and have it EXACTLY correct :-) We needed 1.52 degrees to correct it after the final course change. Of course, you'll say I couldn't be that accurate with my eyes, but you forget the CNC nature of my body, esp eyes and elbows :-) It was rock solid and perfectly centred, one degree would not have gotten us an exact base timing. 0.1 would probably have been good enough, but the extra finesse came at no cost, so...

[Fred]

RPM and sync on the LT1 today, but the base firmware needs some changes before it can run Sean's engine. I'll get it done over the next few days while we wait for some parts to arrive. Exciting times! :-)