Closed kjhazelwood closed 2 years ago
It was to be the 15 Hz Booster cycle number.
In v1.x
, we removed this field because ItemData
now always has an array of (stamp, value)
pairs. For slow rates, the array will have one element. Faster than 15 Hz will switch to the FTP protocol and ItemData
's array will have more than one element.
The cycle number doesn't easily fit in this model (since you could ask for 100Hz data which can span cycles.)
Maybe each ItemData
can have a single cycle
value. ~For <= 15hz, it'll be the cycle associated with the single piece of data. For faster rates, It's the cycle for the last point and you can work back through the data if you care about the cycle values for each point (but for FTP data, I doubt anyone wants to correlate the cycle number.)~ The cycle value is always associated with the last item in the array.
I built a test version in which ItemData
gets the .cycle
value.
For slow rates, it appears to be a millisecond timestamp from the Epoch. For fast rates, it's just a packet counter. I don't mind committing this code, but maybe we can convince @charlieking65 to make DPM return the actual cycle number of the data.
Thanks for the explanation. For my purposes, even at FTP rates, a 15Hz cycle_id would be very beneficial. Data synchronization even at high data rates usually only has to be attributed to the same Booster injection. I think FTP itself does a pretty good job for synchronizing data on the mS level.
We need to get the DPM project onto GitHub so we can transfer this issue to it. 😄
I think it's fine to leave this here, but I created a DPM repo here if you want to transfer this issue https://github.com/fermi-controls/data-pool-manager.
aeca61c496739d14a585f5c1626d93d4b0e8abf3 makes the cycle value available in ItemData
's .cycle
property. The rest of this issue will be handled in the issue mentioned above.
I see in the
README.md
foracsys.dpm
a attribute ofItemData
calledcycle
. I dont see it available in 0.11.4, I presume its not available until v1.0? What doescycle
represent? Iteration count of thedpm.replies()
genenerator? Or an actual beam cycle id (that would be even better, but not sure what that would be from)?