Logworks plugin for SMEC/SBEC/LM

[risen]

I am using the usb-txrx-g usb-ttl interface from the knowledgebase on my 87 LM. I haven't changed the baud rates. The laptop is a 1.6GHz centrino 512mb ram windows xp pro sp3. I downloaded portmon, I will run it next time I log. If theres anything special I need to know about that, let me know. Yeah the gauge measures vac in inches HG. Should I change my boost table to only the values above 0?

You just need to make sure that portmon is only set to monitor the serial port you have the ecu connected to and have it log to a file. Also, you can stop logging to the screen if you don't want to waste cpu or aren't going to watch it. You can send me the portmon log afterwards, it would also help if you can send me the logworks session, too. Your laptop is about the same as my dev machine, so it's got enough juice.

I think it's up to you how you want to handle the mapping, you just need to be aware of what the value represents. I normally just set 0=-14.7 and 255 to 30.0 and let it be a linear scale. It's a little more straightforward of a mapping and is easier to use when you adjust stuff in dcal/chem.

[risen]

For those interested in performance numbers I did some testing tonight and I get around 33 samples/s. So, total time is around 33 ms/sample. By way of comparison, this is almost 3x the rate a lc1 is sampled at. From what I've seen on innovate's site their serial protocol updates at 12.2 hz.

Maybe I'll be able to figure out how to get it to run faster in the future but I'd need to understand exactly what it takes to get the smec to respond to my query on the 1st try every time. The limit is seems to be around 15 ms/sample since that's how long it takes the smec to send a response to a single query (correct or incorrect).

[ShelGame]

Actually, I just looked at the TOC1 interrupt code again. The timer compare it uses is actually variable, but the min interval is 32.3ms. Which corresponds nearly exactly to 33 samples/sec. The variable compare time is also possibly to blame for the unreliable byte reads. I don't really understand the variable timer purpose. I'll have to look into it more. Regardles of why, it doesn't look like we can get more than 33 samples/sec (total) from the 0x12 DRB protocol.

[risen]

Actually, I just looked at the TOC1 interrupt code again. The timer compare it uses is actually variable, but the min interval is 32.3ms. Which corresponds nearly exactly to 33 samples/sec. The variable compare time is also possibly to blame for the unreliable byte reads. I don't really understand the variable timer purpose. I'll have to look into it more. Regardles of why, it doesn't look like we can get more than 33 samples/sec (total) from the 0x12 DRB protocol.

So is it actually set to compare to TOC1A/B/C or does it compare to some other variable in memory in the interrupt somewhere (like an overflow counter)?

From what I can tell, It seems like the smec I have always spits back a response every 15 ms. Maybe this is due to a mismatch between the speed at which the serial tx routine runs and the speed at which the new 0x12 value is loaded? I guess I should be pretty happy with myself for getting it so close to the limit

However, in the quest to make it faster, if the interrupt is run on a timer compare match, couldn't we reset the compare value each time it's run? Or is the granularity of the timer such that each tick is 32 ms? I suppose we'd need to make sure it wouldn't cause too heavy an interrupt load if it was possible.

[wowzer]

i vote for either a new routine or just use the high speed logger! it is such a simple routine to use and i was getting more than 600 bytes/sec at 9600 baud. the only downside (as mentioned before) was a strange blip (every 5 or 10 seconds) but still so much better than the drb crap.

[ShelGame]

The only problem is, the high-speed logger routine will not work on the SBEC without some major re-work. The SBEC already has a serial interrupt routine. That would have to be replaced, or at least have a command parser added so that it can have 2 modes - normal and logger. But, it's possible...

[wowzer]

For those interested in performance numbers I did some testing tonight and I get around 33 samples/s. So, total time is around 33 ms/sample. By way of comparison, this is almost 3x the rate a lc1 is sampled at. From what I've seen on innovate's site their serial protocol updates at 12.2 hz.

Maybe I'll be able to figure out how to get it to run faster in the future but I'd need to understand exactly what it takes to get the smec to respond to my query on the 1st try every time. The limit is seems to be around 15 ms/sample since that's how long it takes the smec to send a response to a single query (correct or incorrect).

on what platform? smec t1, smec t2, (or lm)

[wowzer]

For those interested in performance numbers I did some testing tonight and I get around 33 samples/s. So, total time is around 33 ms/sample. By way of comparison, this is almost 3x the rate a lc1 is sampled at. From what I've seen on innovate's site their serial protocol updates at 12.2 hz.

Maybe I'll be able to figure out how to get it to run faster in the future but I'd need to understand exactly what it takes to get the smec to respond to my query on the 1st try every time. The limit is seems to be around 15 ms/sample since that's how long it takes the smec to send a response to a single query (correct or incorrect).

as a followup, using the drb II protocol, MPScan, hi baud = 9600, 15 bytes per sample, i was getting a throughput of 25 bytes/sec. i didn't try different sample sizes but as noted i doubt i'll get much more speed. comparatively, i got over 600 bytes/sec at 9600 baud using the high speed logger! just food for thought. seems like it would be a better use of effort to look at something other than the drb stuff, at least for the lm and smec

[risen]

on what platform? smec t1, smec t2, (or lm)

88 t2 smec. I really need to get a LM on the bench for testing. Eventually I'll socket the smec so I can try different cals.

as a followup, using the drb II protocol, MPScan, hi baud = 9600, 15 bytes per sample, i was getting a throughput of 25 bytes/sec. i didn't try different sample sizes but as noted i doubt i'll get much more speed. comparatively, i got over 600 bytes/sec at 9600 baud using the high speed logger! just food for thought. seems like it would be a better use of effort to look at something other than the drb stuff, at least for the lm and smec

Well, I guess if there's a need for that level of resolution then I can try and support it in a future version of the plugin. I'd just ask that whatever upgraded routine is used, that it's consistent across the various ecu types.

Still, 33 samples/s isn't that bad unless you have something that only happens at 7500 rpm.

[wowzer]

i agree. as far as the innovative stuff that resolution is probably ok. for my purposes with MPScan i may need to log up to 24 addresses at a time. so that would limit me to 1 to 2 samples per second so i need quite a bit more resolution. also, looking at the real time update stuff that rob's module (hopefully) will support. i know my hptuner software works best (based on ecu) at 10 samples per second, with each sample being 24 bytes.

i just looked at your sim stuff again. that is so cool. can't wait to get my hands on it.

[cs daytona]

Well i finally got my lc1 hooked up last night, and after work today i was messing with the logworks 3 with the plugin. Awesome work!! I love it, but the its a p.i.t.a. That i have to enter the values everytime i start the plugin and lw3. I just to confirm that the lw3 works flawlessly (for me, at least). Has anybody had luck with saving the channel configurations so i dont have to run that dumb wizard? I saved the channel configuration but once i exit the plugin, everythings lost again. Otherwise, its great!

Travis

[risen]

Well i finally got my lc1 hooked up last night, and after work today i was messing with the logworks 3 with the plugin. Awesome work!! I love it, but the its a p.i.t.a. That i have to enter the values everytime i start the plugin and lw3. I just to confirm that the lw3 works flawlessly (for me, at least). Has anybody had luck with saving the channel configurations so i dont have to run that dumb wizard? I saved the channel configuration but once i exit the plugin, everythings lost again. Otherwise, its great!

Travis

The plugin should retain it's settings after you hit the 'start' button. The plugin does retain which channels you have checked, correct?

I don't think I did anything special for logworks3 to make it save the config. Every time I start it up I hit cancel on the configuration of the logging chain (I believe this is the wizard you mentioned) and it pops up the last screen I had setup with the scaling and everything.

I haven't used it in-car yet, but I don't think there should be any difference.

[cs daytona]

your plugin saves everything just fine. the channel configuration in logworks3 is what was not saving automatically. but now i was going to reply that i have to load the configurations from a saved file everytime i start the lw3 with the plugin, which is not bad now that i found where i needed to go to load the channel config file. the users manual comes in handy sometimes hehe. so now that being said, i dont have any complaints. just love. thanks for the program!

travis

[TFmech]

Hey does anyone have the stim mts.dll file to make logworks work with out the LC-1. Inovates forum has said it is in transition forever now and I was wanting to see if this thing will work like it should. If someone could email it to me at kris@claymillican.com that would be great.

Thanks,
Kris

[Stratman]

I planned to play with this Friday, but UPS dropped the FTDI cable off at wrong business address.....

Got to play tonight though!
Thank you very much for this plugin!!!!! This has been a fantasy since 2004....logged for 30 min with no drops outs.
The ignition timing reads 31 deg adv at idle in Logworks, but the OTC scanner reads about 18 deg adv at idle. IPW eems to be right. I did choose the 89 T1 TSMEC which is correct for what I am running. Would there be a difference between the scanner and the scale of the plugin?

EDIT: If I stop the scan, I have to close the plugin and open it again or it gets stuck at initializing logworks(?).

EDITx2: Sorry, reread the first post about restarting plugin.

[risen]

I planned to play with this Friday, but UPS dropped the FTDI cable off at wrong business address.....

Got to play tonight though!
Thank you very much for this plugin!!!!! This has been a fantasy since 2004....logged for 30 min with no drops outs.
The ignition timing reads 31 deg adv at idle in Logworks, but the OTC scanner reads about 18 deg adv at idle. IPW eems to be right. I did choose the 89 T1 TSMEC which is correct for what I am running. Would there be a difference between the scanner and the scale of the plugin?

Glad to hear it worked well for you.

As to the advance, I'm not 100% sure what the issue is there, it's been a long time since I looked at it though. I don't believe that there's any translation currently being done by the plugin, so you may have to map it. There's a thread around here where Rob mentions exactly what the format of the advance variable is (as it's a signed value), but I can't seem to recall what thread it was.

EDIT: If I stop the scan, I have to close the plugin and open it again or it gets stuck at initializing logworks(?).

EDITx2: Sorry, reread the first post about restarting plugin.

Unfortunately I haven't found a way around that issue yet and I don't know that I will be able to.

[Stratman]

Thanks. Maybe Rob can chime in with his knowledge of scaling.

[ShelGame]

Advance is not signed, but the scale is 0-127degrees. So, if you get a 'raw' reading of 31, that's actually 15.5 deg.

[Stratman]

Advance is not signed, but the scale is 0-127degrees. So, if you get a 'raw' reading of 31, that's actually 15.5 deg.

Thank you Rob. Is there other documented scales? It seems it should be easy enough to go by table scaling in the cal. Correct?

Which address should I check if I wanted to log fuel trim or adaptives? I was playing with the autocal addresses and CAC this morning, but there are so many I could make heads or tails which one to watch. CAC was logging zero.

[ShelGame]

Most of the scales are documented in T-SMEC. You can just copy them from the template or from the .tbl file after it's compiled.

For the 2.5 cals, or T-SMEC, the autocal values are from 0x0F to 0x1B. Basically, they are mapped like this:

 
AutoCalCell0 == 0x000F
AutoCalCell1 == 0x0010
AutoCalCell2 == 0x0011
AutoCalCell3 == 0x0012
AutoCalCell4 == 0x0013
AutoCalCell5 == 0x0014
AutoCalCell6 == 0x0015
AutoCalCell7 == 0x0016
AutoCalCell8 == 0x0017
AutoCalCell9 == 0x0018
AutoCalCell10 == 0x0019
AutoCalCell11 == 0x001A
AutoCalCell12idle == 0x001B


*****************************************
; Auto Cal Factors Table
; *****************************************
;
;  closed throttle = cell 12, otherwise:
;  $ff
;	 +-----+-----+-----+-----+-----+-----+
;	 |  1  |  3  |	5  |  7  |  9  |  11 |
;    R1  +-----+-----+-----+-----+-----+-----+
;	 |  0  |  2  |	4  |  6  |  8  |  10 |
;  rpm^  +-----+-----+-----+-----+-----+-----+
;  map>       MP1   MP2   MP3	MP4   MP5     $ff
;
; *****************************************

Where R1 and MP1-5 are the Map cell boundaries as defined in the cal data (template).

Also, there are these 2:

PointerIntoAdaptiveMemory == 0x008A
ValueFromAdaptiveMemory == 0x008B

The pointer is the active autocal cell cell above (0-12), and the value should be a copy of the value in that cell. Though, there may be some discrepancy when it's updating.

The scale of the autocal factors is in signed %. So, it goes from -25% to +25%.