Travis, just make sure you have "Disable MultiThreading" ticked in the logging menu.

 

I'll give that a try! Is there a way to read serial wideband data from the 2.5mm jack in Evoscan? I selected my wideband in the menu but it wants it connected to a serial com port

 

Well I can grab the 4 x 8 byte packages with standalone logging and I've just about gotten them all converted into readable data but it looks like standalone logging is capped at 10 rows per second so it's really only useful if you want to log a lot of items that would normally slow it down without this patch


If that makes any sense to anyone

 

We can do better than 10 lines a second... try this...

That will align the standalone logging optimisations with my default EvoScan XML.

Rich

 

I don't think we can get data from the OP2.0 serial jack in EvoScan.


Buy a serial-USB adapter. EvoScan should be able to read the wideband feed that way.

Rich

 

Bummer, I was hoping for an easy way to switch back and forth between standalone and evoscan. My wideband output cable is just the 2.5mm plug but I could probably find another cable to convert it to a db9 and then to usb, but in the mean time I'm trying to get my standalone converter working. It's almost there I'm just having some trouble figuring out the bit order. I'm guessing the BITS(32,8) formula in evoscan means either the lower most 8 bits or the highest 8 bits, but neither way is really working out for me yet

 

BITS(32,8) gives you the 8 most significant bits, so if the 4-byte package was 0x12345678, you'd want to end up with 0x12.

The easiest way to check is to look at RAX_F_Dat. The top 8 bits are TPS, 0-255 value. You can sit with ignition ON but engine OFF. The OP2.0 will log standalone when ignition is on, as long as it's not plugged into a laptop via USB. Go from zero throttle to full throttle a few times while logging your non-running motor, then grab the log, process, review.

One thing to watch is "signed" vs. "unsigned" in the 4-byte package read. The above test should reveal all, as the top bit will be 1 at WOT.

Rich

 

Going to try this out tonight. I think I found the error in the formula I was using to grab the bits but I won't be able to compile it until I get home tonight. I'm doing a right shift and an AND with 2^(numBits) - 1. I wasn't taking into account that the right shift would be different if the number of bits wasn't 8. Should be fixed now

I added the sampgroup lines you posted and I got it up to about 14 lines a second. Still not quite as fast as evoscan

 

Cool - good luck. Hope the 4-byte data is usable!

If it is, perhaps you could look at a way to add a ".rax" type to Windows file type, and associate your tool with it. Then, all we'd need to do would be to rename (say) "log0001.csv" to "log0001.rax", and then double-click on it. The tool could then run, and generate "log0001.csv" again... in readable format.

Just an idea.


Also, see if you can generate all of the "LogEntryDate", "LogEntryTime" and "LogEntrySeconds" items favoured by EvoScan graph reader... and maybe a dummy "Custom" item at the very end.

We can then load the output into ES, and it will all work as if it had logged it.

All the processed variable names would need to be exactly the same, I think.


Interested to see how you get on...

Rich

 

One step at a time!

If my new formula works tonight I will post a screenshot of what I have so far. I only picked out about 8 parameters to convert from packages but if they work it's only a matter of adding in the conversions for the rest, and then outputting everything either in another file or on screen that can be copy/pasted into excel

 

Success! RPM and knock are screwed up but everything else looks good I think. Is there something different about RAX_C? It seems to be the only one that's not converting correctly

 

RAX_C_Dat and RAX_D_Dat aren't all "8-bit" packaged values like the rest. Double-check your shifting, ANDing, etc.

Rich

 

Right, RPM should be the lowest 11 bits of RAX_C, so if RAX_C = 322962000 in decimal, which is 10011010000000000001001010000 in bin, the lowest 11 bits are 01001010000 which is 592, multiply that by 7.8125 and you get 4625 which is a bit too high for idle rpm

I read map and baro just fine from RAX_D and it has the values split up in 9, 7, and 8 bit chunks

 

It could be OP2.0 can't properly read 32-bit values, full range.

Try test-reading it as two 16-bit values, and review the data.

If you have to do all of it as 2-byte "packages", you'll get around 6-7 lines a second for total data coverage. Not really brilliant, but not so bad for 24/7 logging of absolutely everything.

Rich

 

I'm pretty sure it's reading the 32 bit values just fine. RAX_D is a bigger number than RAX_C and it gets converted just fine. I'm probably just overlooking something dumb.

Everything should be unsigned, right? I shouldn't get any negatives until after the scaling formulas