new $EE tuning thing!

**kur4o** · 03-08-2016

I just finished some testing.
I made some flashing and reading. Tested most of the M4 commands for proper configuration.
Nothing seems wrong for now.
I accidently made a flash on auto bin with skip ff enabled, and it filled some transmission tables with ff-s.
You may take a look at that.
I noticed that on the raw interface when I enable loop with main program disconnected it always close the port when message is received and than reopens it. That way frequency drops alot.
I can`t wait for eside logging and for speed logging too.
On the main dashboard where it feeds all the info, from the main message 0 or from other tabs? You can make a speed tab and select to feed the dashboard from there or some other tabs that have the same data format. Make internal map for the same parameters from different feeds and feed the dashboard from what is available.That way resolution won`t suffer on the most imprortant stuff like rpm map tps. Ihave no idea is it possible but It looks like a good idea.

I haven`t played with the new interface yet and my fisrt impressions are simply amazing.
Major improvements over the previous version.

**kur4o** · 03-08-2016

Serial ports setting is not remembered when program closed and it has to be configured every time the program is open.
Mode 4 control is missing some clear all commands button.(raw command message is a great idea), I tried some keyboard shortcut witout success.
Mapping m4 commands on keyboard for fast access is another idea.
Do you have plans to add all M4 commands possible. I will make a list on what is available.
I have to put some effort for creating mode4 for eside.
Will be than possible to add one more m4 window for eside control.
Give me some hints on what will be most beneficial for tuning an engine.

Is it possible to re-configure some of the dashboard. Or create custom dashboard on separate window. It will benefit to add system voltage at the main dash.

**steveo** · 03-08-2016

for now I think mode4 clears when you close the mode4 window

very concerned about that auto trans flash can you post the bin you used?

**steveo** · 03-08-2016

how about three custom selectable fields on the dashboard? I will never offer full customization but a few "user" fields is no problem. I can reuse the parameter selection dialog from the graphing window

I will add more mode4 stuff later on. one bit at a time. there isnt much left though. We'll have to patch it.

looking deeper at the mode 1 datastream has been fun. our second o2 input is actually egr position for bbodies and my afr nerfs the vette oil temp sensor.

the corvette obd-ii module is very interesting. It does a lot of stuff off-chip. so it looks like there are four onboard diagnostic chips for electrical faults and two extra for obd-ii. this must have been thrown in late for testing the new upcoming regulations but it appears it would almost meet the requirements for a full obd-ii system. it throws cat errors with a rear o2, and does a crapload of running tests, but since no scanner checks for the obd-ii codes in the stream nobody notices.

of course, eehack does now..... if ya check the box

**kur4o** · 03-09-2016

I checked the bin and it is indeed a manual bin. I have no idea how it get loaded on the PCM and still can`t identify it.
16209647 eside cal id and 16209648 tside cal id.

I need some y-body 95 vins to grab some factory calibrations. I have checked all the bins I have on hand and there is no obd-2 possibility in the code or some changes and I assume it must be the onboard extra chip doing the job. I dont have a corvette 95 PCM to play with and see what it offers so for now it is a closed door. I did compare pictures of the y and f boards and found one extra obd2 chip close to flash and two extra chips close to o2 amplifiers[ these might be for the rear 02-s]

In message 0 there is two unidentified AD stream 0113 011b. Do you have any info on them. I suppose these are the rear 02-s even they are most likely to be at 012a and 012b

Pin d27 [byte_103] is mentioned as egr position sensor but is not used on all the schematics I checked so I decided it is not used and I suggest to use it for primary or second wideband channel.

I played with 98 ls1 pcm. It has odb2 channel at pin 2 and separate obd1 channel at ??pin 8?? to communicate with abs. I tried hard to make it response over obd1 with no luck. It must use different data structure. I wonder on corvette PCM does it have full obd2 channel to communicate with along with aldl stream.

3 custom parameters on the dashboard will be great.

**fbody_Brian** · 03-09-2016

Getting an error compiling

Code:

launcher.cpp: In member function ‘void launcher::load_datastream_defs()’:
launcher.cpp:486:60: error: ‘TRUE’ was not declared in this scope
     if(string_in.startsWith("NEW,",Qt::CaseInsensitive) == TRUE) {
                                                            ^
Makefile:14469: recipe for target 'launcher.o' failed
make: *** [launcher.o] Error 1

fixed that by changing to
if(string_in.startsWith("NEW,",Qt::CaseInsensitive ) == true)

Now getting this:

Code:

In file included from datalog_packet.h:4:0,
                 from datalog_element.h:5,
                 from datalog_element.cpp:2:
config.h:53:0: warning: ignoring #pragma warning  [-Wunknown-pragmas]
 #pragma warning(disable: 4100)
 ^
In file included from datalog_packet.h:7:0,
                 from datalog_element.h:5,
                 from datalog_element.cpp:2:
datalog_definition.h:37:6: error: use of enum ‘def_special_t’ without previous declaration
 enum def_special_t;
      ^
datalog_element.cpp: In constructor ‘datalog_element::datalog_element(int, datalog_definition*)’:
datalog_element.cpp:18:19: error: ‘FLT_MIN’ was not declared in this scope
   threshold_low = FLT_MIN;
                   ^
datalog_element.cpp:19:20: error: ‘FLT_MAX’ was not declared in this scope
   threshold_high = FLT_MAX;
                    ^
datalog_element.cpp: At global scope:
datalog_element.cpp:5:69: warning: unused parameter ‘parent_in’ [-Wunused-parameter]
 datalog_element::datalog_element(int offset_in, datalog_definition *parent_in) {
                                                                     ^
datalog_element.cpp: In member function ‘bool datalog_element::is_low(datalog_packet*)’:
datalog_element.cpp:110:23: error: ‘FLT_MIN’ was not declared in this scope
   if(threshold_low == FLT_MIN) return false; // disabled
                       ^
datalog_element.cpp: In member function ‘bool datalog_element::is_high(datalog_packet*)’:
datalog_element.cpp:118:23: error: ‘FLT_MAX’ was not declared in this scope
   if(threshold_low == FLT_MAX) return false; // disabled
                       ^
Makefile:16928: recipe for target 'datalog_element.o' failed
make: *** [datalog_element.o] Error 1

**steveo** · 03-09-2016

oh weird man. that's a portability issue

FLT_MIN and FLT_MAX are defined in c++ as floating point's min and max value.

i wonder if there's a QT definition of them

try #include <limits.h> in that file or something

edit: i looked and linux has them in <float.h>. i committed changes for both those issues (and a few other minor ones)

**steveo** · 03-09-2016

one bug im still working out is what happens when you switch between various logs, or delete logs. sometimes the dashboard is de-synchronized as a result (momentarily, until you move to another record) but the actual tabs with lists of data are still alright. deleting logs can also do odd things, but so far no crashing. just thought i'd mention in case anyone noticed... i am aware of those bugs.

**fbody_Brian** · 03-09-2016

Originally Posted by steveo

oh weird man. that's a portability issue

FLT_MIN and FLT_MAX are defined in c++ as floating point's min and max value.

i wonder if there's a QT definition of them

try #include <limits.h> in that file or something

edit: i looked and linux has them in <float.h>. i committed changes for both those issues (and a few other minor ones)

I'm still getting the error

Code:

In file included from datalog_packet.h:7:0,
                 from datalog_element.h:5,
                 from datalog_element.cpp:3:
datalog_definition.h:37:6: error: use of enum ‘def_special_t’ without previous declaration
 enum def_special_t;
      ^
datalog_element.cpp:6:69: warning: unused parameter ‘parent_in’ [-Wunused-parameter]
 datalog_element::datalog_element(int offset_in, datalog_definition *parent_in) {
                                                                     ^
Makefile:16928: recipe for target 'datalog_element.o' failed
make: *** [datalog_element.o] Error 1

**steveo** · 03-09-2016

sorry, i missed that one. try now. the unused parameter thing should be gone too.

**steveo** · 03-09-2016

I noticed that on the raw interface when I enable loop with main program disconnected it always close the port when message is received and than reopens it. That way frequency drops alot.

unless you have a dead t-side, i'd just 'connect' and disable the datastream messages. it'll only keep-alive if necessary.

this is a good thing anyway since idle chatter will screw with your messages (and eehack requires a nice clean datastream with proper length bytes). remember i don't do unordered raw comms and recieve arbitrary bytes, i require a proper device, length, and checksum on each message or it wont even consider it valid.

furthermore i really don't want to hang the serial port open when not using it, especially since someone (like me) might want to connect and disconnect the usb interface when the program is still open; you know, when carrying the laptop inside from the car but you still want to work with the loaded data. this way you just disconnect and don't worry about it, otherwise, interface open = crash.

Originally Posted by kur4o

I checked the bin and it is indeed a manual bin. I have no idea how it get loaded on the PCM and still can`t identify it.
16209647 eside cal id and 16209648 tside cal id.

weird, there are a few bins like that in my archive too.

I need some y-body 95 vins to grab some factory calibrations. I have checked all the bins I have on hand and there is no obd-2 possibility in the code or some changes and I assume it must be the onboard extra chip doing the job.

i only have these two:

http://fbodytech.com/bin/EE_16209281.bin
http://fbodytech.com/bin/EE_16212471.bin

it's definitely on a different chip that does ALL the work, but it's unclear what 'all the work' is.. the bin just seems to grab the obd-ii error codes from somewhere for display in the datastream.

i find this really interesting.

think about it:

the obd-ii tests are inherently really strict and done with crazy timers and thresholds and require interaction with the actuators.

even a simple obd-ii test could be 'decrease fuel by 20% when engine has been running for (minutes) above x rpm and y temperature and if trims <z and see if left o2 sensor goes lean or whatever'. that's a bitch of a test to do WHILE the primary chip is still processing. then it has to remember the results of that test, and re-test. there is no real evidence of that in the code.

the error codes themselves specified in the datastream do indicate this level of test is done, though.

so either those additional chips have some serious processing power, pinouts, mad context switching, and some kind of more complex IPC communication kinda like a third board (unlikely), or most of their functionality is bunk.

although it could be possible that they interact with the IPC to steal a ton of engine parameters?........ i don't see how, that'd be a hell of a chip.

a reeeallly likely possibility is that the obd-ii style error codes are just stolen from the regular obd-i tests and they were testing this platform if they could fudge 'minimal obd-ii compliance' with very minimal effort, by using obd-i tests and embellishing them slightly (adding only catalyst monitoring with a secondary o2 and chip).

In message 0 there is two unidentified AD stream 0113 011b. Do you have any info on them. I suppose these are the rear 02-s even they are most likely to be at 012a and 012b

0x011B is specified as the rear o2 raw voltage @ byte 35 (or 36 if you start at offset 1 like the datastream documents do) although on f-platform early results indicate no reference voltage is applied, but i haven't checked to see if anything happens if you ground that pin (not even sure which pin to be honest)

0x0113 requires research. no idea what it's for.

the corvette has only a single rear O2 afaik....

Pin d27 [byte_103] is mentioned as egr position sensor but is not used on all the schematics I checked so I decided it is not used and I suggest to use it for primary or second wideband channel.

never seen proof it's used either. it doesn't seem to do much in the code.. but it's in the datastream..

i've defined it in eehack. the definition format allows many parameters to be specified for each byte (and restricted per-view level)

3 custom parameters on the dashboard will be great.

well, i added four, and they seem to work alright (restricted to message zero)

see new beta on my site

**steveo** · 03-09-2016

so this obd-ii stuff is bugging me.

going back from the datastream at mode5, i've found there are well over a hundred bytes of memory, some of it in sequential blocks, used for storing OBD-II input, and not much else.

many of them don't have any direct addressing outside of the datastream. can you find what actually dumps data into them?

here's a nearly-complete block list of memory used in datastream output for msg5:

004A-0055
0057-005B
005D-0061
0063-0069
006A-007A
1926-193A
193D-193E
1941-1950

check out the code at E984:

Code:

E984	B6 19 2B        LE984:	ldaA	L192B
E987	9A 4A           	oraA	l_004A_unused
E989	B7 19 2B        	staA	L192B
E98C	B6 19 2C        	ldaA	L192C
E98F	9A 4B           	oraA	l_004B_unused
E991	B7 19 2C        	staA	L192C
E994	B6 19 2D        	ldaA	L192D
E997	9A 4C           	oraA	l_004C_unused
E999	B7 19 2D        	staA	L192D
E99C	B6 19 2E        	ldaA	L192E
E99F	9A 4D           	oraA	l_004D_unused
E9A1	B7 19 2E        	staA	L192E
E9A4	B6 19 2F        	ldaA	L192F
E9A7	9A 4E           	oraA	l_004E_unused
E9A9	B7 19 2F        	staA	L192F
E9AC	B6 19 30        	ldaA	L1930
E9AF	9A 4F           	oraA	l_004F_unused
E9B1	B7 19 30        	staA	L1930
E9B4	13 79 80 07     	brclr	L0079, #%10000000, @0
E9B8	FE 19 31        	ldX	L1931
E9BB	08              	incX	
E9BC	FF 19 31        	stX	L1931
E9BF	13 73 80 07     @0	brclr	L0073, #%10000000, @1
E9C3	FE 19 33        	ldX	L1933
E9C6	08              	incX	
E9C7	FF 19 33        	stX	L1933
E9CA	13 6F 80 07     @1	brclr	L006F, #%10000000, @2
E9CE	FE 19 35        	ldX	L1935
E9D1	08              	incX	
E9D2	FF 19 35        	stX	L1935
E9D5	13 70 01 07     @2	brclr	L0070, #%00000001, @3
E9D9	FE 19 37        	ldX	L1937
E9DC	08              	incX	
E9DD	FF 19 37        	stX	L1937
E9E0	13 70 40 07     @3	brclr	L0070, #%01000000, @4
E9E4	FE 19 39        	ldX	L1939
E9E7	08              	incX	
E9E8	FF 19 39        	stX	L1939
E9EB	13 70 80 07     @4	brclr	L0070, #%10000000, @5
E9EF	FE 19 3B        	ldX	L193B
E9F2	08              	incX	
E9F3	FF 19 3B        	stX	L193B
E9F6	13 71 04 07     @5	brclr	L0071, #%00000100, @6
E9FA	FE 19 3D        	ldX	L193D
E9FD	08              	incX	
E9FE	FF 19 3D        	stX	L193D
EA01	13 71 08 07     @6	brclr	L0071, #%00001000, @7
EA05	FE 19 3F        	ldX	L193F
EA08	08              	incX	
EA09	FF 19 3F        	stX	L193F
EA0C	13 71 20 07     @7	brclr	L0071, #%00100000, @8
EA10	FE 19 41        	ldX	L1941
EA13	08              	incX	
EA14	FF 19 41        	stX	L1941
EA17	13 71 80 07     @8	brclr	L0071, #%10000000, @9
EA1B	FE 19 43        	ldX	L1943
EA1E	08              	incX	
EA1F	FF 19 43        	stX	L1943
EA22	13 72 02 07     @9	brclr	L0072, #%00000010, @10
EA26	FE 19 45        	ldX	L1945
EA29	08              	incX	
EA2A	FF 19 45        	stX	L1945
EA2D	13 72 08 07     @10	brclr	L0072, #%00001000, @11
EA31	FE 19 47        	ldX	L1947
EA34	08              	incX	
EA35	FF 19 47        	stX	L1947
EA38	13 72 20 07     @11	brclr	L0072, #%00100000, @12
EA3C	FE 19 49        	ldX	L1949
EA3F	08              	incX	
EA40	FF 19 49        	stX	L1949
EA43	13 72 80 07     @12	brclr	L0072, #%10000000, @13
EA47	FE 19 4B        	ldX	L194B
EA4A	08              	incX	
EA4B	FF 19 4B        	stX	L194B
EA4E	13 73 02 07     @13	brclr	L0073, #%00000010, @14
EA52	FE 19 4D        	ldX	L194D
EA55	08              	incX	
EA56	FF 19 4D        	stX	L194D
EA59	13 73 08 07     @14	brclr	L0073, #%00001000, @15
EA5D	FE 19 4F        	ldX	L194F
EA60	08              	incX	
EA61	FF 19 4F        	stX	L194F
EA64	39              @15	ret

if we want some 'unused' ram to use for hacking the t-side this might be a good place to get it. even corvette guys wouldn't know the code is missing.

i will look into it more but the code's interactions with these bytes might reveal quite a bit more.

**fbody_Brian** · 03-09-2016

Originally Posted by steveo

sorry, i missed that one. try now. the unused parameter thing should be gone too.

compiled and working

flashed and logged this morning, all good so far.

**steveo** · 03-09-2016

compiled and working

im glad; but im going to break it again

the whole 'speed packet' thing leads me to believe this entire api is a bit broken.

i want to go back to my memory-address driven model that i conceived earlier.

luckily it's not a complete rewrite...

**fbody_Brian** · 03-10-2016

Few little things so far, on the datalog main tab for Spark adv and KR, I'm assuming that there should bed a degree symbol, but I'm seeing � instead.

also, on the analysis cruising AFR, I'm not sure what's going on, but I'm getting no data in the MAF AFR below 31 AFGS. Not sure if it's not lining up, or the data just isn't making it there.

I've attached the log