ROFL :-)nitrousnrg wrote:Yep, my Inj Time (now PW) is the total fuel delivery time, and my duty % is what you said. If you think it could have a better name, tell me and I'll change it. You shouldn't leave the naming in hands of a inexperienced latin american :PWith regards inj time and PW, consider dead time, and multiple shots per cycle. You want to display something like "total fuel delivery time" which I provide as a value in the log, I think. And also actual PW which includes dead time, and combined with number of shots per cycle, and time per cycle, gives duty cycle %.
Total Fuel Delivery Time
Electrical Pulse Width
Electrical Duty Cycle and/or Fuel Duty Cycle - these numbers will always be different.
The trick is that the name matches what the code does! (obviously).Good good! Those are much better than mine.What you probably want to stat are :
Good packets
Bad checksums
Length mismatch
Partial packets
Bad data between packets
Escaped byte invalid
Partial packet = found start, found another start later.
Bad data between packets = any bytes found before a start byte.
Escaped byte invalid = escape byte found, and following byte isn't an escaped escapable byte.
The others are obvious.
I find extra stop bytes because of the way I search the stream, starting backwards from the first stop byte occurrence (instead of searching forwards from the first start occurrence, as you do).
Marcos, if you start backwards from the first stop, you'll never see another stop, by definition. The only cases there are :
* find no start before stop
* find a start at the end of the buffer
* find a start before the end of the buffer
The first means absolutely nothing (partial packet when connecting or stray data in between that happened to include a stop. The second should be the normal case where you find a packet and only a packet. The third just means that you found some stray data before the first packet when connecting, or between two packets if mid stream.
Theoretically I can't see a problem with what you are doing, except that to handle it properly, you need an arbitrarily large sized buffer! IE, if you're getting garbage and looking for a stop, you may never see a stop, and you need to save all data until you can retraverse back through it to find the start. If you look for a start, dump everything before a start, and buffer from start until stop, the hand off to another stage of processing and repeat, that seems to work more cleanly.
Can you explain why you're doing it the way you are and what benefits that has?
That is true, however under some circumstances it should be categorised differently.Don't mind me, any data between packets is bad, no matter if it is a random byte, or a start/stop one.
Fred.