Output

Aaron Barnes' wxPython based FreeEMS tuning tool. No longer maintained and out of date with the protocol requirements.
User avatar
sry_not4sale
LQFP144 - On Top Of The Game
Posts: 568
Joined: Mon Mar 31, 2008 12:47 am
Location: New Zealand, land of the long white burnout
Contact:

Output

Post by sry_not4sale »

What are people ideas on debugging/logging output for the tuner. Currently it just spews out everything, everywhere lol But i would like to change that, especially since changes are required to our logging methods due to the application being multi-threaded now.

There is a very low level debug information need for the developers (especially for debugging threading issues), this would be best appended to a log file and rotated I believe. Instead of dumping to console, someone could just tail the log file.

Next would be a way of turning on/off serial data capture for Fred. What is your *one* preferred format Fred?

What else do we need?

Obviously error logging for users to send when things are going awry on someones install.
Some form of logging for tuning sessions... what would be needed to be recorded here?

Thanks in advance,
Aaron
Owner / Builder: 1983 Mazda Cosmo 12at (1200cc 2-rotor turbo) coupe [SPASTK]
165hp @ 6psi standard - fastest production car in japan Oct 82
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Output

Post by Fred »

sry_not4sale wrote:There is a very low level debug information need for the developers (especially for debugging threading issues), this would be best appended to a log file and rotated I believe. Instead of dumping to console, someone could just tail the log file.
Agree 100%
Next would be a way of turning on/off serial data capture for Fred. What is your *one* preferred format Fred?
unknown/bad packets (checksum, header, format, length, payload id, etc) to a special file in hex of some sort. preferably in the style that ben wrote for us.
Obviously error logging for users to send when things are going awry on someones install.
Yes, this is true. We need multiple types don't we.

User level stuff should be with flashing lights and dialogs etc. - in the face if/when they need to know
Application stuff should be to a file - errors, issues, debugging etc.
Bad/unknown packets to a file - helps me develop and allows use of tool with new code
EMS data to a set of files one fo reach format - record everything sent by EMS
Some form of logging for tuning sessions... what would be needed to be recorded here?
This I can answer : everything you are receiving from the device. Now, this is trickier than it could be as we have many types of log. The only good approach is a new file per type of log. This is complicated by the future configurable log, but you could set it up such that when the config changes the file is closed and a new matching one opened.

Make any sense?

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: Output

Post by jharvey »

Hmmm, some thoughts. I see a need for graphical logs, and viewing of log data. However, I think right now the item in question isn't so much how to interpret it, but what should be included and how.

I see two categories relative to logging. Users and Developers.

Users would basically want the sensors and perhaps a couple specific CPU parameters. They will want it via on-board storage to analyse after the fact and in event of a problem, and users will want a serial stream to analyse with a lap top on the fly. So the tuning software should capture both of these.

Users would also likely want too limit what is being looked at, allowing for more detailed data on a specific sensor with the allotted bandwidth or memory space. For example, you probably only need temperature on change, or once every 30 seconds, however, users would likely want RPM every rotation, or perhaps even sub rotation. So they would want this data either based on a series of events, or based on a specific time limit, kind of like the key frame in a MPEG.

I'll call logging because of change or specific events "logic logging" and I'll call the logging based on just because it's been a while "priority logging".

I think we want a combination of priority logging and logic logging much like we see with video key framing. And I think we want some control over this via gui control. I'm sure some vehicles want the temp more than every 30 seconds, and others it's find for the temp to happen every minute. The min limit should be set via gui.

I also see a separation between the rules people would want for on-board storage, and transmission. Basically the same rules, but the output is either to the memory or serial stream, perhaps a third output for gauges ect.

I see the debug data as very specific, and not used by most... Well eventually not used by most. Perhaps debug data for developers could be activated with a -v switch(s), such that -vv is more verbose, ect. Then you can add what ever you want to spit out.

Hope the above make some sense, I'm running a bit of a fever right now, not exactly on my game.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Output

Post by Fred »

Aaron can only provide what he is provided, thus I think your post was almost entirely aimed at me and belongs in that special purpose logs thread I put up. I may move it if I get a chance.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: Output

Post by jharvey »

I have to admit, I thought the same. What gets sent or stored seems to be mostly a firmware thing, however the tuner software would have some control by sending a couple requests or config commands.
User avatar
sry_not4sale
LQFP144 - On Top Of The Game
Posts: 568
Joined: Mon Mar 31, 2008 12:47 am
Location: New Zealand, land of the long white burnout
Contact:

Re: Output

Post by sry_not4sale »

This thread was more to gauge what sort of program debug info, and serial data needs to be logged.

Current idea is:
- program debug log to file, off by default
- serial data logged to file, enabled via menu and given a name e.g. "bnr32 - high boost run 12/07/08"
- last 25 (configurable?) serial packets shown in diagnostic grid. Logging packets not shown.
Owner / Builder: 1983 Mazda Cosmo 12at (1200cc 2-rotor turbo) coupe [SPASTK]
165hp @ 6psi standard - fastest production car in japan Oct 82
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Output

Post by Fred »

sry_not4sale wrote:- last 25 (configurable?) serial packets shown in diagnostic grid. Logging packets not shown.
If you are handling them correctly, I don't wanna know what was sent/received :-) And if I don't, who does? Only stuff that isn't handled should be stored and recorded, and I reckon putting it in the gui is a bad idea, just write to a log file so it can be tailed efficiently.

Thoughts?

As for the datalog, are you going to use my json format suggestion? Or what? CSV SUCKS, but a CSV export from json tool would be SO easy to write.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
sry_not4sale
LQFP144 - On Top Of The Game
Posts: 568
Joined: Mon Mar 31, 2008 12:47 am
Location: New Zealand, land of the long white burnout
Contact:

Re: Output

Post by sry_not4sale »

So Fred, do you want to be able to see the formatted packet output like in the diagnostics grid for all packets?

If so, where. Give me your exact run down on output/logging so I know what ya want :)

Cheers,
Aaron
Owner / Builder: 1983 Mazda Cosmo 12at (1200cc 2-rotor turbo) coupe [SPASTK]
165hp @ 6psi standard - fastest production car in japan Oct 82
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Output

Post by Fred »

No, I only want to see the hex of packets you aren't properly parsing! If you parse and display it in a good way, that is enough :-)

eg for datalogs, the real time view will be sweet
for debug packets a println will be good
for errors a println with num + message
for tables load them into a memory object in an array of 16 so that it can be viewed in a table and/or 3d by selecting which table to view from the 16.
not sure what else there is.

the echo should be repeated there and anything you don't recognise :-)

Is that enough detail?

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
sry_not4sale
LQFP144 - On Top Of The Game
Posts: 568
Joined: Mon Mar 31, 2008 12:47 am
Location: New Zealand, land of the long white burnout
Contact:

Re: Output

Post by sry_not4sale »

Nope :P Please be more specific/detailed :)

Thankyoucomeagain.
Owner / Builder: 1983 Mazda Cosmo 12at (1200cc 2-rotor turbo) coupe [SPASTK]
165hp @ 6psi standard - fastest production car in japan Oct 82
Post Reply