Re: Timestamps
Posted: Thu Oct 22, 2020 4:39 pm
Thanks. I should be able to give this a try over the weekend.
I can tell from the sketch that this will send back readings as often as it possibly can. So, while the baud rate is only 9600 baud, the data rate is probably pretty high because the serial port is getting hammered continuously.
CoolTerm shouldn't have problem with that, and I assume when you try this sketch with a Mac or a Windows PC and turn on HH:MM:SS.sss timestamps it works just fine , but I may have an idea what may be happening on the Raspberry Pi. With no timestamps or timestamps with second resolution, CoolTerm doesn't refresh the display at every DataAvailableEvent. Instead, it polls the port and refreshes the display at the rate specified in the "Miscellaneous" settings. The default is 100ms. However, when using millisecond timestamps, CoolTerm forces a refresh of the display at every DataAvailableEvent. So, in this particular case, the display is being refreshed as fast as it possibly can. This can become very CPU intensive, especially when there is a lot of data to display. I have found that text display GUI controls on Linux systems, including the Pi, behave very different than on macOS or Windows. You may have noticed on the Pi that automatic scrolling is kind of weird and the display tends to flicker.
I will definitely dig into this further, but I believe that what you're seeing may be a limitation of the text display. There is one thing you can't try within CoolTerm to see if it makes a difference. Under "Receive Option" you can reduce the size of the receive buffer. The default it 10,000, but just for testing, you could reduce that to 1,000. That way, CoolTerm will only ever display the last 1,000 bytes, and refreshing the display will be computationally less power hungry.
What I would recommend on the Arduino side is to insert a delay(100) statement below the Serial.println(voltage) statement. This adds a 100ms wait state between readings, thus throttling the data rate. If you don't need readings to come in at the highest rate possible, it's always a good idea to reduce that to what's acceptable.
I can tell from the sketch that this will send back readings as often as it possibly can. So, while the baud rate is only 9600 baud, the data rate is probably pretty high because the serial port is getting hammered continuously.
CoolTerm shouldn't have problem with that, and I assume when you try this sketch with a Mac or a Windows PC and turn on HH:MM:SS.sss timestamps it works just fine , but I may have an idea what may be happening on the Raspberry Pi. With no timestamps or timestamps with second resolution, CoolTerm doesn't refresh the display at every DataAvailableEvent. Instead, it polls the port and refreshes the display at the rate specified in the "Miscellaneous" settings. The default is 100ms. However, when using millisecond timestamps, CoolTerm forces a refresh of the display at every DataAvailableEvent. So, in this particular case, the display is being refreshed as fast as it possibly can. This can become very CPU intensive, especially when there is a lot of data to display. I have found that text display GUI controls on Linux systems, including the Pi, behave very different than on macOS or Windows. You may have noticed on the Pi that automatic scrolling is kind of weird and the display tends to flicker.
I will definitely dig into this further, but I believe that what you're seeing may be a limitation of the text display. There is one thing you can't try within CoolTerm to see if it makes a difference. Under "Receive Option" you can reduce the size of the receive buffer. The default it 10,000, but just for testing, you could reduce that to 1,000. That way, CoolTerm will only ever display the last 1,000 bytes, and refreshing the display will be computationally less power hungry.
What I would recommend on the Arduino side is to insert a delay(100) statement below the Serial.println(voltage) statement. This adds a 100ms wait state between readings, thus throttling the data rate. If you don't need readings to come in at the highest rate possible, it's always a good idea to reduce that to what's acceptable.