RomRaider

Hello all!

Are there any plans to incorporate userlevels into the logger? I got a bit carried away and currently have over 1100 RAM parameters defined for my ROM and even though only about 450 are actually added inside the logger, it's quite an extensive list inside the Logger haha If there aren't any plans to add userlevels to the logger, what other ways could I control what parameters show up without having to manually add and remove parameters?

I do utilize the profiles, as they save quite a bit of time from having to scroll through the extensive list, but being able to filter all the parameters would be quite beneficial for specific scenarios that wouldn't warrant a unique profile.

I'm not aware of any plan.

Once you sort out which each parameter's purpose and which are truly useful, move those to a Logger definition that can be publicly shared and keep your dev version private. There's no use putting out a def with parameters most people will never use and aren't well documented.
Another option would be to create a couple of Logger defs targeted at tuning, or troubleshooting specific types of problems. Then a user switches between them as required.

Luckily for ME, I’m not really planning on making it publicly available or anything like that haha There isn’t any reason for it. Not when deep code analysis is required for every single ROM just to locate the parameters. Even then, you still need to have even further knowledge to be able to locate them without having a pre-defined ROM to cross reference with. So it’s just for personal use. That would definitely be a good idea though!

Right now, I’m just using a set variable before the name to have it group them up by that. So all my bitwise switches are “~ Parameter” instead of just “Parameter” Speaking of which, can you have those bitwise switches setup as regular switches instead of ECU parameters? All the ones defined currently are in a really weird format.

Can you provide an example of what switch you are logging, byte, bit and ECU ID?

Sure thing! This is for CF48D (06 Nissan 350z, so not subie haha) These are two different parameters obviously, but the actual switch is just a global one or something. One that's basically like OBD2 protocol stuff, where it's just generally supported. While the RAM parameter one is ECU specific.

Global(?) Switch


ECU RAM Parameter Switch

You're close.
Just change to:

Interestingly enough, I was able to get it to register as an actual switch!



Is the ecubyte portion required?

ecubyte?

Yea the "ecubyteindex='105'" part.

See correction below.

Sweet! Thanks for the help!

Correction.
I you are using the typical SID addressing byte="0x221302" bit="0" you will need the ecubyteindex= as it maps the supported bit returned by the ECU to select this switch for the Logging switch list.
supported bits come from 221300, 221320, 221340, etc.

If you are using the <ecuparam format then no, as the supported fact comes from matching the <ecu id= element.

What if I'm using the switch format, but using 0xFF23AC as the byte instead of a SID address? I've only tested it with one ECUParam set as a switch and it seemed to work just fine. So it's an ECUParameter, but it's just classified as a switch in this case.

What is your identifier to indicate this switch is valid for your particular ECU ID?
That's the purpose of the ecubyteindex= in <switch/> or the <ecu id= in <ecuparam/>.
Without one of these qualifiers the switch will be available for any ECU you connect with and it may not be valid for every ECU.

Ohhhh I see what you mean! So for CF48D, I could just put the ecubyteindex="CF48D" then? Since it's not a universal switch. That actually makes quite a bit more sense now haha