Hello.
I’m new here, I have a setup of a PMU that makes the readings, and a python program that makes the interface between the IEEE C37 protocol and the Json that i send to the emoncms. the code in python receives up to 120 readings of voltage current and phase, then it sends everything to emoncms via socket, i’ve noticed that in graphs and when exporting csv file emoncms shows up to 1 reading per second, even though i’ve sent more than 1 reading per second to it, so my question is, does emoncms store only 1 frame per second of information or everything it receives, if it stores all that receives how can i take this information out because in the export as csv it only goes “as down” as 1 second, if doesn’t could you tell me if is it possible to somehow tweek the program to storing and extracting the full information it receives?
It is interesting for me to have this information even though it’s a lot because, we are in the making of analysis of reactive power, harmonics distortions, power factor corrections and others studies, so it would be very good that i could store all data that the PMU generates and afterward extract all.
Emoncms is built for second precision timestamps.
unix timestamps are truncated to integers on receipt to emoncms so 1535579913.0 and 1535579913.999 are both accepted as 1535579913. Even if you were to remove this casting, the phpfina and phptimeseries feeds both use integer timestamps so you could not store data in smaller increments than 1 second. You may be able to use mySQL tables but I think most of emoncms is written to work with integer timestamps.
I too would like to see the casting of float timestamps to integers at the initial input stages removed, as I think that even if the input calcs were done to millis resolution would improve the accuracy of even standard >10s data, if a 10s update can be truncated by up to 0.999s if it’s 1mS short that’s a whopping 10% error.
Even if the data is still saved with a minimum resolution of 1 second, it would be more accurate calculated using greater resolution input. IMO since float timestamps are already presented to emoncms on many occasions, that accuracy is just thrown away by casting to an int, it’s a bit like having a ruler scaled in mm but only bothering to measure to the nearest whole cm under (not even rounding).