I tried to run a test over the weekend to profile a device. Because I don’t have much free hard drive space and have not yet tried the down sampling option, I left the GUI running and used a screen capture program to record the window - absolute values aren’t important, I just want to look over the waveform view to see if there is any unusual activity.
Unfortunately when I came back to it this morning all activity had stopped and the displays are static. The displays still respond to clicks and I can move around the waveform etc but I have no new data coming in.
PC remained on, Joulescope plugged in and test unit powered so I’m not sure why it has stopped.
It is still hooked up in its current state if I can provide any feedback to help diagnose the issue?
Hi @haly-tom, and sorry to hear you are having issues with long-term data collection. Could you look at the lower right and see if the “USB” indicator is green? Either way, it would be great if you could post the most recent Joulescope log file. See this post for details
I do not have the USB indicator, it states Buffer in the lower right hand corner.
Please find log file attached, looks like it lost connection not long after I started the test and left the office. I see the clear energy at 17:23 when I started the test and then a device stream false at 19:54 which I assume it when it lost the connection?
joulescope_20190830_035947_9804 - issue.log (146.0 KB)
Just edited the post with the correct timestamps - left the office around 17:30 not the earlier 16:49 clearing of the energy I stated earlier.
Just wanted to add, I thought this may be due to Windows locking my machine, screensaver kicking in or display going to sleep but I’ve double checked my settings and I’ve got it set to never sleep, never turn off display, screen saver disabled and there is no auto lock enabled.
@haly-tom, thank you for the log file, and I have been tracing through the software to see what would cause this. The log is not very informative:
INFO:2019-08-30 19:54:34,123:main.py:1045:joulescope_ui.main:_device_stream(False)
which simply says that collection is stopping, but does not give any information on why. Is this easy for you to duplicate? If so, could you try increasing the log level:
- Select File → Preferences → General → log_level → ALL
- Click OK
- Close and then restart the Joulescope UI
If possible, duplicate the issue and post the log file. In the meantime, I will also keep looking for the cause.
I have been trying to duplicate the issue, first without changing the log level, but have not been able to so far. I did leave it running last night and something happened on my machine but I haven’t worked out what yet - I noticed in the log a few fill missing samples messages (21:37:56, log attached) then some additional messages at 21:47 and again at 06:32. My machine was in an odd state in the morning so I looked at the event log and noticed a few Resource-Exhaustion-Detector at the same times as the Joulescope log, an example message:
Windows successfully diagnosed a low virtual memory condition. The following programs consumed the most virtual memory: X2.EXE (7036) consumed 2458513408 bytes, ccstudio.exe (10244) consumed 2178387968 bytes, and joulescope.exe (2392) consumed 1079263232 bytes.
X2 being Altium, ccstudio being Code Composer Studio and Joulescope - Altium and CCS should have been in the same state (idle) and Joulescope being active.
I do not know if this is at all related to the previous issue or not but thought I would add it in case there is something unusual on my machine that may have also caused the previous issue.joulescope_20190903_234752_2392.log (529.1 KB)
Hi @haly-tom - thanks for the update and for investigating. Dropped Joulescope samples typically happen when your host computer does not keep up with the USB traffic. Joulescope currently uses USB bulk transfers, and the host is not required to guarantee any data rate. I am considering implementing USB isochronous transfers, which guarantee a data rate but do not guarantee retransmission. Either way, we will see a small amount of dropped samples in practice. Although undesirable, the number of dropped samples should be very small.
I can say that I have never seen that error message before. If your host machine does run out of virtual memory and has to spend time reclaiming memory, that could certainly explain why it did not keep up with USB.
I have improved the logging to help capture this issue. The improved logging will be in the next release which is planned for sometime in the next two weeks. I appreciate you taking the time to investigate, and please let me know if you notice any additional unusual behavior.