Ticket #25 (new enhancement)

Opened 11 years ago

Last modified 10 years ago

FIR

Reported by: stefan Owned by: somebody
Priority: major Milestone:
Component: fir Version:
Keywords: Cc:

Description

FIR filter has a time drift; FIR initializes time in startup of module, and then assumes perfect sampling rate the whole time.

It would be be better if there were a reinitialization of the time by the data header every 10 minutes, and NOT by assuming it will be perfect from the very first sample and ever after.

Change History

comment:1 follow-up: ↓ 2 Changed 11 years ago by stefan

reported by Jean-Marie Saurel saurel@… and Alexandre Nercissian aln@…

comment:2 in reply to: ↑ 1 ; follow-up: ↓ 3 Changed 11 years ago by nerces

Replying to stefan:

reported by Jean-Marie Saurel saurel@… and Alexandre Nercessian aln@…

Your analyse is correct. The fir timeserie is dated by the timestamp of its first sample and assuming a perfectly stable digitizer clock wich is unfortunately not the case in real live. The decimated time needs to be re-timestamped by the actual time whenever it drifts by more than a given fraction of sample interval

comment:3 in reply to: ↑ 2 Changed 10 years ago by paulf

For doing this FIR change, the idea of restarting the FIR from the latest timestamp is a good one. Comment to Alex on this is that it would be nice to restart after some drift, but without an absolute time source how does one know that the packet for a given channel has drifted (you cannot check it against the system clock since it is delayed in delivery).

Also, this restart feature should be an option since this could introduce discontinuities. How about if we put in an option to specify every N minutes it will reset the filter using the next packet that comes in? Does anybody have other ideas or the ability to easily test this change? It would be nice to get it into the 7.5 release but it seems like this change hasn't been a priority for anyone so it may wait for 7.6. Please get me feedback in the next day or two.

Replying to nerces:

Replying to stefan:

reported by Jean-Marie Saurel saurel@… and Alexandre Nercessian aln@…

Your analyse is correct. The fir timeserie is dated by the timestamp of its first sample and assuming a perfectly stable digitizer clock wich is unfortunately not the case in real live. The decimated time needs to be re-timestamped by the actual time whenever it drifts by more than a given fraction of sample interval

comment:4 Changed 10 years ago by paulf

Jean Marie wrote in email to ewdev list (documenting here with the ticket):

Hi Paul,

I have a couple of idea to overcome the drawbacks of the restart solution,
but they may be more complex to implement.

1- You could timestamp each outgoing packet taking into the timestamp of
each ingoing packet and the filter delay. I didn't get into the code, so I
don't know exactly how it is feasable.

2- Another way would be to continuously adjust the value of the data rate,
reading it with the incoming packets : (next packet timestamp - packet
timestamp)/number of samples.
One advantage would be to accomodate in near real-time the real data rate.
But again, I don't know how it would be easy to implement or not.


I quite agree that we could wait for the 7.6. In fact, it was a priority
for us a year ago, but now, we found a better solution : making the data
rate of the acquisition much more constant and synchronized with a GPS
clock.
We still have the hability to test any improvement of FIR module very
easily, because we have a couple of acquisition not synchronized to GPS
yet and that can provide delays of several seconds within a day after
passing through the FIR.

This make me think of another feature I would like to have with fir filter
: to have the ability to define myself the filter coefficients.
This would be nice for a couple of reasons :
  - this way, we can control the coefficients and thus populate a dataless;
  - we could imagine using this feature to produce a real-time data flow
corrected from the instrument response.
Regarding the second reason, this would allow to calculate magnitudes or
to compare directly data flows with physical units (think about an RSAM
where all the streams are from different instruments).


Finally, regarding the restart proposed feature, I agree that the user
must be able to disable it.
It's easy to implement, but more a quick solution than a final solution,
in my opinion.

Note: See TracTickets for help on using tickets.