Timestamp issues the second

[poledna]

Hello, I'll start by the problems i faced the first time I got my hands on the this beautiful repository(nice work btw), I am using mainly the pdc tool and i receive data from a third party pmu using IEEE C37, after hitting a couple of bumps connecting to the pmu i found that it would receive only one package and then would raise an error, after a couple of prints in the library, i managed to find that it was originally raising the error in the crc module, then i printed what was arriving in the pdc right after a single transmission and error, and i saw that the pmu sends multiple messages with the second, and that was creating a crc error due to the program trying to check its crc of a larger message than it should, i solved this by resizing the buffer size from 2048 to 4 in this line: '<while len(received_data) < 4:>' . it did the trick for me at least. then i also wanted a udp connection, and i altered something and did it, but i don't exactly know why but my pmu isnt responsive to the udp request of config2 frame, so i pickled the config2frame from the tcp connection and then used that as config2 frame for the udp. not a long term solution but a quick one. I added to files to the zip file attached: one with the tcp(that's basically the example but with cfg2 pickled) and the udp one with it's quick "solution". both tcp and udp i can receive the data(i receive a phasor in polar form). but after a couple dataframes received i get a error in the timestamp(i plotted the cossine wave for visualization) in the file índice.png in the zip is how 15 dataframes with reception rate of 60 frames per second, and índice2.png where is plotted more frames with 30 frames per second, i added a line to the example to show when the timestamp "goes backwards" if(timestamp[i]-timestamp[i-1]<0): print(datetime.datetime.fromtimestamp((timestamp[i])).strftime('%Y-%m-%d %H:%M:%S.%f')) print(i-1) print(i) what come to the timestamp issues: when the time comes to 2018-08-08 16:46:27.824997 the fraction of second is the thing, the next is 2018-08-08 16:46:27.002803 and creating a vacuum in the plot and a overwrite int the plot as well, no matter the framerate. So this is my in the moment problem if someone has an idea to solving this timestamp i'd be appreciated.

I added another zip file in the zip file with my in this moment altered library.

synchrophasor.zip

[poledna]

So I found the problem in this line in frame.py: fr_seconds = frasec_int & (223-1) it should be: fr_seconds = frasec_int & (224-1) this avoids the frasec counter "resetting" after 8M

[poledna]

hm github has made the as bold, it is in frame.py: fr_seconds = frasec_int & (2 23-1) should be fr_seconds = frasec_int & (2 ** 24-1) it is just a pair of asterisks not three but avoids the bold

[sstevan]

Hey @poledna,

Thanks for letting us know! I will reopen this issue to keep it visible by default until we fix this issue.

[poledna]

I've been reading a bit more and according to item 4.3 of Martin, K. E., Benmouyal, G., Adamiak, M. G., Begovic, M., Burnett, R. O., Carr, K. R., Cobb, A., Kusters, J. A., Horowitz, S. H., Jensen, G. R., Michel, G. L., Murphy, R. J., Phadke, A. G., Sachdev, M. S., & Thorp, J. S. (1998). IEEE standard for synchrophasors for power systems. In IEEE Transactions on Power Delivery (Vol. 13, Issue 1). https://doi.org/10.1109/61.660853 I think the value should be 2^24 due to "Compatibility with IEC 61850:2000 [B3] requires a TIME_BASE value of 2^24." At least this was what solved a issue I had at the time with a weird overflow of time in my PDC received data. The PMU was sending at 120 fps.

[veljkoDjurkovic]

@ poledna

You are probably right about this line of code. Should be (2^24)-1 because according to the standard actual frasec is used to be 24-bit integer. Thank you for helping us to solve this issue!

Veljko