typedef struct
{
FullPulse_t SparkOff; // Position of spark pulse trailing edge - the spark
FullPulse_t SparkOn; // Position of spark pulse leading edge - coil charging
uint16_t PulsePeriod; // The time(us) between engine timing pulses
uint16_t InjDuration0; // Pulse duration in us
uint16_t InjDuration1; // Pulse duration in us
FullPulse_t InjAdvance; // Position of injector
uint8_t MapIdx_; // The index of the map entry being used ( lower left )
uint8_t fy; // The fraction throttle from base map entry
uint8_t fx; // The fraction RPM from base map entry
} TimingInfo_t;

typedef struct
{
    uint16_t    TimeWait;        // Time in us after the pulse
    uint8_t     Pulse;            // The pulse number - 0..47 for My16M
}   FullPulse_t;


=1129601138C020FED02C00BC00B0000230735F722

=1 12 9601_13 8C02_0F ED02 C00B C00B 0000_23 0 7 35 F7 22

RPM: 3337
PulsePeriod: 749
Injduration: 3008
InjAdvance: Pulse=35 TimeWait=0  =>  525
SparkOn: Pulse=15 TimeWait=652
SparkOff: Pulse=19 TimeWait=406
Map: (7.96 , 0.21) or (7 and 247 , 0 and 53)

I have yet to figure out the FullPulse_t struct.

If InjAdv 525 is reported as pulse 35 + 0 us, the following formula seem to work:

(Pulse + (TimeWait / PulsePeriod)) * (720 / PulsesPer)
=
(35 + (0 / 749)) * (720 / 48)
=
525

But that don't work out for SparkOff. Besides, SparkOn is lower than SparkOff so is there some other reference than TDC for them? Should I substract Pulse from the 0x16 for my TDC?
(22 - Pulse + (TimeWait / PulsePeriod)) * (720 / PulsesPer)

This is the last puzzle to solve before my LogWorks plugin is ready to fly. Well, it already flies but it lacks SpkAdv.

WRT to your previous query, BaroAdjust is referenced to 16K and not 1K.
SparkOn is when the coil is turned on so it will be earlier than SparkOff.
SparkOff 19:406 is roughly 19.5
TDC=0x16= 22 so SparkOff is 2.5 before TDC. This gives advance of about 2.5*15=37.5 degrees

Thanks! I was pretty close, just the wrong side of a paren...

(22 - (Pulse + (TimeWait / PulsePeriod))) * (720 / PulsesPer)

I'll release the plugin and its source within a few days, stay tuned

Just out of curiosity, what are the lines prefixed "d" occasionally seen in the serial data?

d0B0104000000B6193F3A250072

I thought they were line garbage until I realised they have a correct length byte and pass the checksum test...

They are diagnostic outputs. Like an assert statement firing.

You might see a few of these at startup but you shouldn't really see them in normal running.

This is the structure. I'll leave it to you to see if you can figure out which fields are changing.

typedef struct
{
    uint8_t Alert:1;
    uint8_t res:3;
    uint8_t BadPulse:2;
    uint8_t BadSyncs:2;

    uint8_t MissedPulse:2;
    uint8_t InvSync:2;
    uint8_t Noise:2;
    uint8_t Noise1:2;

    uint8_t InvSpk0:2;
    uint8_t InvSpk1:2;
    uint8_t InvInj0:2;
    uint8_t InvInj1:2;

    uint8_t xSpk0:4;
    uint8_t xSpk1:4;
   
    uint8_t xInj0:4;
    uint8_t xInj1:4;

    uint16_t p0;
    uint16_t p1;
    uint16_t p2;
    } Diag_t;

Cool, thanks. So if the first byte is 01, BadSyncs is 1? Or is it Alert? Here is my current parsing, is it correct?


Code:

DiagnosticInfo d0B0100100000BC425600230088 Alert: 0 res: 0 BadPulse: 0 BadSyncs: 1 MissedPulse: 0 InvSync: 0 Noise: 0 Noise1: 0 InvSpk0: 0 InvSpk1: 1 InvInj0: 0 InvInj1: 0 xSpk0: 0 xSpk1: 0 xInj0: 0 xInj1: 0 p0: 17084 p1: 86 p2: 35

If it is, what does it tell you?

I found some of these messages in a couple of old logs, at near redline speeds. Apart from that I have a couple of Noise/Badsyncs when cranking.

Turns out I was hitting 100% duty cycle for the injectors, that's why I got them at speed...

So p0 is InjDur including all compensations and deadtime, right? What are p1 and p2?

And what is the difference between InjDur in TimingInfo and the one in CompensationInfo?


Code:

SensorInfo =00EE700EF003603A603A803ED01170169 O2: 1.13 V OilT: 74.2 °C AirT: 9.5 °C AirP: 4.56 V Thr: 936 Bat: 13.7 V TimingInfo =112E200132F010B5901293E293E000023BEFF376F RPM: 7246 PulsePeriod: 345 us between pulses (23 us per degree of rotation) Injduration: 15913 us (691.9°), Duty Cycle: 96.1% SoI: Pulse 35 plus InjDur of 15913 us plus InjDeadTime of 0 us  =>  1216.9 °BTDC EoI: Pulse 35  =>  525 °BTDC SparkOn: Pulse 11 plus TimeWait of 303 us   =>   151.8 °BTDC SparkOff: Pulse 19 plus TimeWait of 226 us   =>   35.2 °BTDC Map: (14.2 , 12) CompensationInfo =310FF039A4400E58F018F010004DF3100E5DE AirP: 1023 mBar BaroAdj: 107.2 % O2Adj: 25 % CL: 1, O2[6], 1.95 V => Lambda: 0.9 => AFR: 13.2 InjDur: 12767 us

Is the lower figure in CompensationInfo the raw (but probably interpolated) figure from map? That almost makes sense, if I add O2Adj I get close to the TimingInfo figure. But then I haven't added BaroAdj, so I miss something here.

I'd like to know the exact difference so I can send both (adjusted to same meaning) to LogWorks in order to get a higher sampling rate.

Edit: Of course, CompensationInfo's InjDur is including BaroAdj and lacking O2Adj. This all makes sense.

No you're reading it wrongly.  The bitfields are least significant bits first so the 01 is
Alert: 1
res: 0
BadPulse: 0
BadSyncs: 0
then 00
then 10
InvSpk0:0
InvSpk1:0
InvInj0:1
InvInj1:0
The p's are parameters specific to the alert.
In this case p0 is the desired injector pulse width and p1 is the actual. This alert is triggered if they differ by too much.

BaroAdj is already included in the first injduration.

Why is your injduration so high and the closed loop pegged +25%.
Injectors should only be run upto about 80-90%.

Thanks, I had a feeling the Alert bit should be set...


_Cliff_ wrote on 09/16/09 at 17:40:43:

Why is your injduration so high and the closed loop pegged +25%.

The example log was from a ride when my sensor went bezerk a couple of years ago, one of the very first rides with sensor. Serious grounding problems if I recall correctly. So it is not interesting at all except that it had bursts of alerts to try my parser against.

I think I got it now but I'm dizzy from byte-order, bit-order and byte-spanning overloading  :o


Code:

DiagnosticInfo d0B0104000000B6193F3A250072 Alert: 1 res: 0 BadPulse: 0 BadSyncs: 0 MissedPulse: 0 InvSync: 1 Noise: 0 Noise1: 0 InvSpk0: 0 InvSpk1: 0 InvInj0: 0 InvInj1: 0 xSpk0: 0 xSpk1: 0 xInj0: 0 xInj1: 0 p0: 6582 p1: 14911 p2: 37

This is from a recent log of just starting the engine. It started without problems and I guess the Alert is not dramatic at all. In context this Alert was fired right before the first non-zero rpm reading.

Is my parsing of 04 into "Invsync: 1" correct? If it is, I believe the rest is correct too, except I'm not sure about what bit order I end up parsing for 'res' and I don't think I ever will be.

Anyway this was just an interesting parantesis. I'll just let my Logworks plug indicate (to its window, not to Logworks) the number of alerts received so I know there is something to look at in the .dmp file that will also be produced.

_Cliff_ wrote on 09/16/09 at 17:40:43:

In this case p0 is the desired injector pulse width and p1 is the actual. This alert is triggered if they differ by too much.

So it wanted 17084 us including deadtime which was 86 us more than the time available? No wonder it complained.

This was an error case but I plan to really push it next spring, tuning for E85. In theory the injectors will suffice except for approaching redline (8143 rpm) at very near WOT, just the two upmost cells in the rightmost column. Those cells will be a little lean but OK if I set them to open loop with the map value plus the deadtime summing up to exactly the time available. That is about 95% duty. Any positive BaroAdj will push it over the edge though. Lowering the rev limiter to 8000 or slightly lower should produce the slack needed.

Out of curiosity, what was the actual result when that diagnostic message triggered? Was it actually an 86 us pulse sent? That would mean there is a dynamic premature rev limiter which is probably the best, for safety. Cutting it to zero would be even "better looking" but there should be no difference.

I think the consensus is to keep duty cycles less than 90%. Maybe you should increase the fuel pressure a little.

Yes, absolutely. Or replace the injectors. But my idea was to just try it out below 7000 rpm or so, and see if it is worthwhile before making any such mods.

If the effective result of this situation will be a complete fuel cut off as that diag message indicated, I'll be safe while experimenting. Alternative behaviors, like continuos squirting while still being lean, could mean I'll ruin injectors, drivers and/or pistons. So it would be good to know the ECU does the best of the situation!

I have been running my 130hp monster on single injectors more then 2 years. Rev limit is 10500 and it runs out of fuel just above 8000RPM. Above that it is 100% duty cycle so it is not a perfect situation and I am loosing a bit of power there.

I advanced the inlet cams about 15 degrees to move down the powerband a bit to "detune" the engine and gain more midrange.

The bike is however still running good and I have not had any issuse due to this. No reliability problems. After all the time that I am on 100% duty cycle is just a second or two during full power acceleration.

I am not sure if I am going to increase the fuel pressure or go to double injectors to sort this. I have some new camshafts to install this winter and I estimate that I will need about 20% more fuel to be on the good side.

Going up from 3 bars to 4,5 bars will sort this as it will give about 22% more fuel. My main concern is pump reliability with 4,5 bar fuel pressure.

Jocke...........

jocke wrote on 10/21/09 at 22:32:34:

I have been running my 130hp monster on single injectors more then 2 years. Rev limit is 10500 and it runs out of fuel just above 8000RPM. Above that it is 100% duty cycle so it is not a perfect situation and I am loosing a bit of power there. I advanced the inlet cams about 15 degrees to move down the powerband a bit to "detune" the engine and gain more midrange. The bike is however still running good and I have not had any issuse due to this. No reliability problems. After all the time that I am on 100% duty cycle is just a second or two during full power acceleration. I am not sure if I am going to increase the fuel pressure or go to double injectors to sort this. I have some new camshafts to install this winter and I estimate that I will need about 20% more fuel to be on the good side. Going up from 3 bars to 4,5 bars will sort this as it will give about 22% more fuel. My main concern is pump reliability with 4,5 bar fuel pressure. Jocke...........

Sounds like the actual result is continuos squirting. So it's still willing to rev up to the limiter? How lean does it get?

http://virdung.net/DynorunS4.jpg

She is very willing and able. Smooth response, killer mid/top range. 3:d gear power wheelies above 6500RPM.

If it was not for the fact that I know that she needs more fuel I would not be able to say that she needs more fuel by the feeling of how she is runing.

I think that if I had 10-12% more fuel it would be okay for the moment and with the new camshafts and modified camtimimg I think that 4,5 bars pressure (+22,5% fuel) will be perfect.

As you might have guessed blue graf is after engine upgrades and red is before

Jocke..........

Jocke, if you were using my Logworks plugin, which would you prefer? I can't decide.

1. A reported duty cycle of 100% means the actual pulse, including deadtime, equals all time available. This way it will never exceed 100% however stupid we map it. A value of 99% should be considered unknown territory because we really don't know how the injector will behave at an off-time shorter than deadtime.

2. A reported duty cycle of 100% means the effective pulse, excluding deadtime, equals all time available. This way the reported value may exceed 100% if we're really pushing it. On the other hand, any value below 100% should behave as expected.

Currently I report it as #2 but I'm very ambivalent.

raz wrote on 10/24/09 at 05:09:46:

Jocke, if you were using my Logworks plugin, which would you prefer? I can't decide. 1. A reported duty cycle of 100% means the actual pulse, including deadtime, equals all time available. This way it will never exceed 100% however stupid we map it. A value of 99% should be considered unknown territory because we really don't know how the injector will behave at an off-time shorter than deadtime. 2. A reported duty cycle of 100% means the effective pulse, excluding deadtime, equals all time available. This way the reported value may exceed 100% if we're really pushing it. On the other hand, any value below 100% should behave as expected. Currently I report it as #2 but I'm very ambivalent.

I have never been thinking about it but I would guess that the # 2 is the one I am used to. #1 will have some advantages but it what about if you change to different injectors that behaves differently? I will not be correct then.

I dont think it is a bit problem anyway as long as you know how it works.

I vote for #2


Jocke........

jocke wrote on 10/24/09 at 17:29:04:

I have never been thinking about it but I would guess that the # 2 is the one I am used to. #1 will have some advantages but it what about if you change to different injectors that behaves differently? I will not be correct then. I dont think it is a bit problem anyway as long as you know how it works. I vote for #2

Hm, I screwed that up. This is the correct descriptions of course:

1. A reported duty cycle of 100% means the actual pulse, including deadtime, equals all time available. Any value below 100% should behave as expected.

2. A reported duty cycle of 100% means the effective pulse, excluding deadtime, equals all time available. A value approaching 100% should be considered unknown territory because we really don't know how the injector will behave at an off-time shorter than deadtime.