Dear Sir,
I am trying to print the absolute time starting from 0s in the terminal.
The first frames.start_time I get in class Hal is like this
2022-05-25T05:44:03.173772160000Z. My idea is to take it as a base “time” 0s.
But it seems not the correct 0s!?
@lc00747 Sorry about that… start_time and end_time are currently formatted to UTC time. We unfortunately don’t have a variable that stores the relative time (i.e. 0s) from the start of the capture.
We’ve received this request from a few other users and we’re tracking this idea in the link below:
For now, I added a comment and vote for you. Apologies we don’t have an immediate solution. Can I know your specific reasoning for needing the relative time? I’d love to make sure we get your use case logged as well.
@timreyes thanks for replying, the reason I want to get this 0s is because I would like
to format my own string in terminal with “relative time” which can mapping to the waveform screen time line, so I can quick to find it in between.
BTW, may I ask other question here about to print strings into a file in HighLevelAnalyzer extensions? I tried it and got error, any examples? Thanks.
@lc00747 Thanks for describing your need for that. I added some more notes to the idea post I shared previously so we can remember your use case.
I also remembered that we are tracking a feature request to jump to a protocol bubble above the waveform by double-clicking a value in the terminal. Would this be useful for you as well?
If so, I’d love to get your vote/comment added there as well.
We unfortunately don’t have a method of doing this right now. Are you particularly interested in the feature request below? If so, I’d be curious to know your reasoning for needing this feature as well.
With my USB FS/LS analyzer version, and the HLA that does the filtering for me, I want
the HLA to output the packet times such that, I could correlate, the output report along with
what I see on the screen and
With the Save the LLA to text file output.
So, my current experiment, appears to work reasonably well for my needs. Not sure how much the times are off.
What I am now doing is:
def __init__(self):
'''
Initialize HLA.
'''
self.base = 10 # commands choose.
if self.DisplayFormat == 'Hex':
self.base = 16
elif self.DisplayFormat == 'Dec':
self.base = 10
self.addr = None
self.endpoint = None
self.frame_start_time = None
self.frame_end_time = None
self.data_packet_save = None
self.frame_data = {'pid':'', 'pid2':''}
self.first_packet_start_time = None;
I added that last line in this section.
Then at the begin of decode I have:
def decode(self, frame: AnalyzerFrame):
if self.first_packet_start_time == None:
self.first_packet_start_time = frame.start_time
Later when I have a report item I wish to print:
start_bias_time = float(self.frame_start_time - self.first_packet_start_time) if self.base == 10: print(str(start_bias_time), ',', self.frame_data['pid'], ',', str(self.endpoint[0]), ',', str(self.addr[0]), ',', data_str) else: print(str(start_bias_time), ',', self.frame_data['pid'], ',', hex(self.endpoint[0]), ',', hex(self.addr[0]), ',', data_str)
And now my output report looks like it has some reasonable times output:
23.91371954 , SETUP , 0x0 , 0x0 , 0x80 0x6 0x0 0x1 0x0 0x0 0x40 0x0
23.91378884 , IN , 0x0 , 0x0 , 0x12 0x1 0x0 0x2 0x0 0x0 0x0 0x40 0x6a 0x5 0x74 0x3 0x11 0x1 0x1 0x2 0x3 0x1
23.99383474 , SETUP , 0x0 , 0x0 , 0x0 0x5 0xb 0x0 0x0 0x0 0x0 0x0
24.01368234 , SETUP , 0x0 , 0xb , 0x80 0x6 0x0 0x1 0x0 0x0 0x12 0x0
24.01375654 , IN , 0x0 , 0xb , 0x12 0x1 0x0 0x2 0x0 0x0 0x0 0x40 0x6a 0x5 0x74 0x3 0x11 0x1 0x1 0x2 0x3 0x1
24.01389326 , SETUP , 0x0 , 0xb , 0x80 0x6 0x0 0x6 0x0 0x0 0xa 0x0
As I mentioned, I am not sure how far I am off, but I think close enough that I can find data in the other places.
Nice workaround! I really want to add a simple capture start time property somewhere for the next HLA API update, but we don’t have that on the schedule yet.
In the meantime, here is another thought - I think we might construct the HLA instance when we start the capture, IF the HLA is added before the capture start button is pressed. In this case, you might be able to simply snapshot the system time when the analyzer is created, and compare that to the first frame time. If the first frame time is later than the construction time, it could be a better stand-in for the capture start time.
Sorry we don’t have a better solution for this!
Oh @KurtE I just had another thought - you can adjust T0 in the application manually to line up with the first frame too.
Just find the first frame, add a timing marker at that location, the right-click and select set as t0.
Then your timing bar should match your HLA strings.
