I can log 2-byte airflow and load perfectly. However, I had to configure the protocol definition for 2-byte airflow in a strange way to make it work. Here are my definitions:
<datachannel id="#00" name="loadmsb" selected="1" units="load" min="0" max="255" expr="x" type="0"/>
<datachannel id="#01" name="loadlsb" selected="1" units="load" min="0" max="255" expr="x" type="0"/>
<datachannel id="#04" name="airflowmsb" selected="0" units="hz" min="0" max="3000" expr="x" type="0"/>
<datachannel id="#05" name="airflowlsb" selected="0" units="hz" min="0" max="3000" expr="x" type="0"/>

I would expect the "max" 2-byte airflow value to be 255 just like with load. If I use 255 as a max, I get weird airflow numbers when I run my Logworks calculation. Even though the bit data never exceeds 255, if I set the max to 3000, then the 2-byte airflow data log and calculation work perfectly. Anyone else notice this?

 

the max for any 1 byte value is 255. The max for any 2 byte value is much higher. 255 units would not be able to cover the full range of 2 byte airflow anyway without being evaluated.

See here for more info: https://www.evolutionm.net/forums/6863231-post2.html

 

No matter what I used in the lsb/msb lines, the 2bite product was twice as sloppy as the rest of the MUT logs in LW. Ended up logging hz another way directly as weel as IDC/IPW

 

May I ask how did you end up logging airflow?

 

the only problem with 2byte is the low/high mismatch that occurs sometimes...

 

Care to elaborate?

 

like when you see a spike upto like 400 load or drop down to 30..

ie when the high byte is transitioning from 0 to 1 and the low byte is transitioning from ~255 to ~0...

 

Seems like no one else has noticed this glitch with Logworks.