[Chucko]

I'm tweaking on GUFB to get rid of unneeded resolution in some datalog payload items.

On the datalogging, one example is voltages like TPS and VMAF. The 8061 only has a 10-bit A/D converter, and these voltages are 5V full scale, so at most 3 digits after the decimal point are valid. I'm applying that philosophy to numbers calculated from A/D inputs, such as MAFV and RATCH, as well.

Some of the internal calculations (e.g. DASPOT) are similarly logged with more digits than are justified. A 2-byte field means at most 5 digits are valid.

Not writing those excess digits to the datalog makes logs smaller, and (I hope) makes datalogging faster as a result.

This is not a request for GUFx revisions - yet. I'm just letting you know I am experimenting with this.

On Quarterhorse payload generation - is BE smart enough to group and batch payload items by their addresses? Or does it just grab them in definition file order, 1 or 2 bytes at a time? For example, LAMBSE1 and LAMBSE2 are consecutive in memory, so it would make sense to have the QH grab them as a 4-byte chunk. Being smart about building the payload could mean an increased sample rate.

I wonder if there would be any benefit to sorting the payload items by address in the definition file.

Where are items like LTFT1/2 and STFT1/2 defined? I don't see them in the GUFB file, and the raw logs show far more digits than are justified.

I'm sure I'll come up with more questions later.

[cgrey8]

I spent some time doing this for the scalar/function/tables, but never did it for the datalogging items.

As for the STFT/LTFTs, they are calculated by BE from the LAMBSE/KAMRFs. Thus they are not within the definition's control to manipulate.

[Chucko]

I spent some time doing this for the scalar/function/tables, but never did it for the datalogging items.

Yeah, I've added a digit of resolution to a couple of the functions in my copy of the GUFB def, because the rounding was preventing full resolution. I found a couple more places where this was the case. Hint: look for anything with X/128 as the formula... generally 2 digits is NOT enough for full resolution in those cases.

The thing is, the extra resolution on the tuner side doesn't cost anything. The worst it can do is mislead you into thinking you have more precise control than you actually have.

As for the STFT/LTFTs, they are calculated by BE from the LAMBSE/KAMRFs. Thus they are not within the definition's control to manipulate.

I guess we'll have to wait for Clint to chime in then.

[EDS50]

Subscribing. This is interesting and I would like to see if this grows wings and what direction it goes in.