I need to make a connection of events in signals captured by a Picoscope oscilloscope and the time of day when these events happend. With a .psdata file the capture date/time can be viewed in PicoScope 6 in the properties panel.
Since I have quite a number of .psdata files which need to undergo further automatic processing outside of PicoScope 6 I use the command line interface for conversion of the data files to .csv/.txt. I could also use the .mat format but for neither of these formats the resulting files contain the capture date/time which is essential for me to know for further processing steps.
I am wondering if there is any way to extract the capture date/time information from the .psdata files in way that can be automated?
@Pico Technology Staff: If this is not possible I would kindly ask you to consider including that feature in a future update of the PicoScope software.
You can do what you ask by passing the time information to the converted file in the file name itself. There are 2 ways that you can do this.
1/ In PicoScope 6, you can set an alarm to automatically save a file on capture or buffer/s full and name the file
2/ You can create the time stamp in a batch file as shown here: topic38401.html (you would want to move the setting of the Current Time immediately before the Run.Pressed=True command).
thanks for your prompt answer! As far as I understand, both of your proposed solutions work well with files that have not been recorded yet, meaning that you have to make configurations to the file naming scheme before the files are actually captured.
But is there a solution for files that have already been recorded and saved without the capture timestamp in the filename?
I guess essentially I am asking for a way to extract the capture day/time from the .psdata file unless there is a way to extract it via the command line interface or the automation commands. If this is not possible, could such a feature be included in say the export as .csv/.txt/.mat or is there a specific reason why it should not be possible?
I will certainly put this forward as an enhancement request for our Development Team. However, just be aware that if it is considered for prioritisation, it may not be a quick fix.
I would find such a feature to be useful too.
I've used alarms to save data quite a few times but my post processing makes use of the automatic numbering suffix, e.g.
to sequentially post-process the files. If the date and time were used in the filename it would make it more awkward; I'd have to increment the filename by least significant value, check if it exists, if it does then load it and if it doesn't loop back around. I think. And I can look at doing this in future but, like the OP, I've got some previously recorded data that I'd like to add a time to.
If the capture time and date and any other information could be extracted into a separate file that would be fine for my use, i.e. I'm not suggesting a change to the .CSV (or other) format. I don't know if that would resolve the OP's concern.
Or is that information accessible in another format? I see the OP mentioned it's not in the .mat file but is it accessible from any other? I guess .psdata is not an open format but if it is then I could look at reading some data from that.
Just thought I'd put a post in to show that Christian isn't the only person who would be helped by this sort of feature.
I'm working on a research project on lightning signals. I use a lightning detection network to localize the discharge and a picoscope 6404C to register electromagnetic signals from our flat plane antennas. I need the time of the capture files to compare with the data of the lightning detection network.
At this moment we have recording the capture time in the file name, but the resolution is in seconds. I need at least a milliseconds resolution, because in only a second, the network report 10 or more lightning events, therefore it's difficult to correlate our signal with the network data. It's possible to get that information?
I appreciate your help,
For example on CH1 the data you want to measure and want to know the time.
on CH2 a precession signal from GPS or something else that gives a short pulse every second and a longer pulse every minute.
Then you write your own software to capture streaming mode at say 1MS/sec and have your timing at 1uS precession. And of course save only the interesting parts so you get no useless files with nothing of interest in it.
Personally I would do it in C++ but that is my main language.
P.S. you probably can even go to 10 or 20 MS/sec so 0.1uS or 0.05uS
(UPDATE, I've removed the first comment here as it was intended to cut the dialogue short, but is redundant now.)
Yes, you could use a GPS module to synchronize 2 remote PicoScopes (I was thinking about suggesting that myself), but it's not as straightforward as you suggest. Here are just some of the things that you would need to consider:
1/ You would have to ensure that the GPS module is constantly powered to avoid the time required to locate a satellite, from sleep mode (which could be tricky if it is running on batteries, because the modules are not low current devices and you don't know how long it would have to be powered before the Scope needs to capture a lightning strike).
2/ Most importantly, you would have to ensure that there is always a direct line of site to the satellite (could be difficult in conditions of lightning, especially if it is stormy weather). Also, the cause of lightning strikes can be Geomagnetic storms, which also interfere with GPS accuracy.
You could also use a high accuracy and precision RTC module, but the problem with these is that the highest accuracy one that I could find would be highly likely to have drifted out of accuracy (in terms of less than a second) by the time it is needed to timestamp a PicoScope channel.
Probably the best method would be to use Precision Time Protocol (i.e. a Precision Time Clock generator, assuming that you could capture the Time Code with enough signal integrity), if you happen to have a local internet connection (as Network Time Protocol wouldn't be accurate enough) but this would not be trivial to implement, and it certainly wouldn't be inexpensive.
Because with temperature shift the x-tall frequency of the scope will drift somewhat les than 0.01% or so but it will drift with time and temperature.
As you would need to do this anyway to find out the Absolute time, any drift in sample clocks between scopes is not relevant, because each scope has to be, by default, calibrated against the same absolute time reference.