Logs and long-running capture

Logs and long-running capture

Turn on logging when a problem is intermittent or when you need to hand evidence to another engineer.

Recommended logging habits:

• Enable timestamps for each received and sent line.
• Use a filename template that includes the port, project or date.
• Rotate logs by size or time for long tests.
• Open the current log immediately after the issue appears and keep the original file.
• Include a small sample frame in support requests so the symptom is reproducible.

For 24-hour tests or production benches, confirm the log location and rotation rule before starting the run.

Log behavior

File → Log Recording (or its toolbar button) switches logging on and off for every connection together. The Log page of the settings dialog sets the file name, timestamps and rotation; under Log Behavior it also decides how each logging session starts:

• Append to file (the default) adds to the log that is already there. Overwrite file replaces it once per logging session: the first write after logging is switched on replaces the file, every later write appends, and switching logging off and on again replaces it again.
• Prompt for filename asks for the file each time logging is switched on, suggesting the configured name. Cancel, and logging stays off for that connection.
• Start log upon connect switches logging on as the connection opens, so a capture does not miss its first bytes because nobody pressed the button. With Prompt for filename also on, the question comes as the connection opens; cancelling it leaves the connection open and logging off.

These settings belong to each connection and are saved with the .spu project.

Forgot to log? Every connection also keeps what it sent and received this session in memory, and File → Export Session… writes it to a file after the fact, even with logging off. See Exporting data and the diagnostic pack.