JohnRob
September 22, 2018, 8:55pm
1
Hi,
I'm trying to use the timestamp feature in the monitor window. Timestamps seems to be inconsistent (although I suspect it is me being inconsistent).
It doesn't appear to be a simply a Serial.print or Serial.println command.
No info it the "documentation"
Can someone enlighten me?
Thanks
John
pert
September 22, 2018, 9:13pm
2
JohnRob:
I'm trying to use the timestamp feature in the monitor window. Timestamps seems to be inconsistent (although I suspect it is me being inconsistent).
I've never used it before now and I also find it to be very inconsistent in Arduino IDE 1.8.7. Sometimes I get one timestamp on the first line after I start the Serial Monitor, but then no additional timestamps. Other times I get no timestamp at all.
I expect a timestamp added on every line, like this screenshot from one of the Arduino developers posted during testing:
arduino:master
← MichalSy:master
With the timestamp enabled, on the sample sketch I posted earlier with a Zero, t… he heap usage ramps to 900MB but then the garbage collector acts good. CPU usage increases from 2-3% to 20% but this is an hardcore test so overall it looks good from a performance POW.
I'm attaching a screenshot for @00alis so we can get some suggestions on UI elements placements

What sort of inconsistency are you encountering?
Which operating system are you using (I'm on Windows)?
JohnRob:
It doesn't appear to be a simply a Serial.print or Serial.println command.
No, it's nothing running on your Arduino's microcontroller. It's code in the Serial Monitor program.
JohnRob:
No info it the "documentation"
It's fairly typical for Arduino to do a bunch of effort to add a new feature but never bother to document it. In the case of an obvious, self-explanatory feature that's not such a problem. I would think timestamp is such a feature but since we're both having troubles with it either there is a bug or else the usage is non-obvious.
JohnRob
September 22, 2018, 9:41pm
3
Thanks for the response.
I'm using Windows 7/64 pro.
I'm happy it not me but would still like it to work as (not) advertised.
I'll try some simple configurations and see if I can find a logical solution.
John
pert
September 22, 2018, 9:43pm
4
You forgot to answer my question:
pert:
What sort of inconsistency are you encountering?
JohnRob
September 23, 2018, 6:11am
5
In the below code, "Loop Count" is in one function
all the others are in another function.
They are consistent for each loop but I can't find any logic that would suggest why some show the timestamp and others do not.
The lines that are just:
13:42:49.753 ->
are Serial.println();
Looking closer, perhaps the first Serial.print of a function (subroutine) might be missing the timestamp. I'll have to perform some testing.
John
13:42:49.753 ->
Loop Count = 1
Loop Count = 2
Loop Count = 3
Loop Count = 4
state change
------ in update_stateArray --------
state change
------ in update_stateArray --------
13:43:28.457 -> stateArray
13:43:28.457 -> start byte FE
13:43:28.457 -> 2nd byte EE
13:43:28.457 -> 1 if change 1
13:43:28.457 -> pressureOK 0
13:43:28.457 -> remote 2
13:43:28.457 -> faults 2
13:43:28.457 -> alarm 0
13:43:28.457 -> fault 4
13:43:28.457 -> override 0
13:43:28.457 -> stop byte DE
13:43:28.457 ->
13:43:28.457 ->
Loop Count = 5
Loop Count = 6
Loop Count = 7
Loop Count = 8
Loop Count = 9
Loop Count = 10
Loop Count = 11
Loop Count = 12
Loop Count = 13
Loop Count = 14
Loop Count = 15
Loop Count = 16
Loop Count = 17
Loop Count = 18
JohnRob
September 23, 2018, 8:50pm
6
I upgraded to V 1.8.7 before my testing but I suspect the version is not critical.
I found the timestamp would not display unless there was a Serial.println (); prior to any other Serial.print functions.
This seems to apply to each routine. I did not test if the same routine was called in consecutive order but I suspect the 2nd call would react like a "new" routine.
The timestamp would start after:
Serial.println ();
Serial.print ('\n');
but NOT after
Serial.print(" ");
Serial.print('\r);
Note: Any additional information on this topic would be gratefully received.
John
pert
September 23, 2018, 9:26pm
7
This is really screwy. This code:
void setup() {
Serial.begin(9600);
Serial.println("setup1");
Serial.println("setup2");
Serial.println("setup3");
Serial.println("setup4");
Serial.println("setup5");
Serial.println("setup6");
delay(1000);
Serial.println("setup7");
delay(1000);
Serial.println("setup8");
Serial.println("setup9");
Serial.println("setup10");
Serial.println("setup11");
}
void loop() {
Serial.println("hello");
delay(1000);
}
Gives this output:
setup1
14:23:44.528 -> setup2
14:23:44.528 -> setup3
14:23:44.528 -> setup4
14:23:44.575 -> setup5
14:23:44.575 -> setup6
setup7
setup8
14:23:46.524 -> setup9
14:23:46.524 -> setup10
14:23:46.571 -> setup11
14:23:46.571 -> hello
hello
hello
hello
So it's affected by delays. I have trouble believing it would intentionally work this way. If it is intentional then it absolutely needs documentation.
JohnRob
September 23, 2018, 10:55pm
8
OK, I didn't test that.
Perhaps a general rule might be:
"To obtain timestamped print statements one must precede any print statement or group of print statements by a println."
John
For me, it doesn't seem to follow "To obtain timestamped print statements one must precede any print statement or group of print statements by a println."
To me, it seems to print the timestamp (reliably twice) after a "\n\t"?
JohnRob
September 24, 2018, 8:18pm
10
Ok then....
Perhaps the general rule is there is no general rule, but results are better after
Serial.print('\n')
or
Serial.print('\n\r')
or
Serial.println ()
John
pert
October 11, 2018, 11:07am
11
There is now a bug report:
opened 09:46AM - 05 Oct 18 UTC
closed 10:11AM - 16 Nov 18 UTC
Type: Bug
Component: IDE Serial monitor
Hi all, the 1.8.7 version of the IDE doesn't show the timestamp in each line whe… n the following sketch is running on a MKRGSM board:
```c++
#include <MKRGSM.h>
const char PINNUMBER[] = "";
const char GPRS_APN[] = "Your_APN";
const char GPRS_LOGIN[] = "";
const char GPRS_PASSWORD[] = "";
GSMClient client;
GPRS gprsAccess;
GSM gsmAccess(true);
String response = "";
String okmsg = "ok";
String errormsg = "error";
void setup() {
delay(3000);
Serial.begin(115200);
int i;
//setted a timeout of 180 s for the GPRS and GSM operation
gprsAccess.setTimeout(30000);
gsmAccess.setTimeout(30000);
for (i = 0; i < 5; i++) {
Serial.print("Connecting GSM network...");
if ((gsmAccess.begin() != GSM_READY) &&
(gprsAccess.attachGPRS(GPRS_APN, GPRS_LOGIN, GPRS_PASSWORD) != GPRS_READY)) {
Serial.println("error");
Serial.println(i);
} else {
Serial.println("connected");
break;
}
delay(1000);
if (gsmAccess.status() != GSM_READY) {
Serial.println("loop");
while (true);
}
}
}
void loop() {
Serial.println("Connecting GSM network...");
if (Serial) Serial.println("Attaching to GPRS with your APN...");
if ((gsmAccess.begin() != GSM_READY) &&
(gprsAccess.attachGPRS(GPRS_APN, GPRS_LOGIN, GPRS_PASSWORD) != GPRS_READY)) {
Serial.println("error");
} else {
Serial.println("connected");
}
gsmAccess.shutdown();
Serial.println("sleeping");
delay(10000);
}
```
A portion of the serial monitor where the issue occur is reported following:
```c++
11:28:57.813 -> +CREG: 0,0
11:28:57.813 ->
11:28:57.813 -> OK
AT+CREG?
11:28:58.013 -> +CREG: 0,5
11:28:58.013 ->
11:28:58.013 -> OK
AT+UCALLSTAT=1
11:28:58.212 -> OK
11:28:58.212 -> connected
AT+CPWROFF
11:29:03.899 -> OK
11:29:03.899 -> sleeping
Connecting GSM network...
11:29:13.905 -> Attaching to GPRS with your APN...
⸮AT
11:29:17.992 -> OK
AT+IPR=921600
11:29:18.025 -> OK
```
and a proposed fix:
arduino:master
← nitram509:master
opened 10:59AM - 11 Oct 18 UTC
The root cause was a wrong initialized variable "isStartingLine".
Additionally,… I did refactor the lambda method to an inner class,
in order to make it more convenient to write a unit test (UpdateTextAreaActionTest)
This PR also introduces 3 new dependencies for testing scope only.
Testing dynamic behavior with Mockito library enables better test coverage.
As usual, any feedback is welcome.
@cmaglie I would be glad if you could have a look, since you originally developed it.
pert
November 15, 2018, 10:10pm
13
It means that someone has notified Arduino of the problem and that people are working on fixing it.