I’m using a FC130 and I’m trying to understand how I can determine the record send rate, because in one scenario I would like to record a specific transient event on a digital input. Ideally I want to have access to the 40ms samples without any filtering, as this would help me to record my event.
I disabled everything in the eventual record but the digital input 2. I disabled the sleep modes too.
I tried the filter value of 0 or 1.
I’ve tried the priority of low or high.
I’ve tried using the analog input with a 5V threshold instead of the digital input, also with a filter value of 0 or 1.
To test it, I’ve put a 0V to +10V square with a generator, and tried frequencies of 1Hz, 3Hz, 12.5Hz and 25Hz during exactly 10s.
The only result that I’m getting is that I receive one record per second. I never received multiples records per second.
I assume that ideally if there were no filtering on the analog input, and that each sampling instant the value would trigger “on change”, I should be receiving 25 records per seconds (1/40ms)…
I see that the internal timestamp of the record is said to be in ms, but the last digit are always 000, so only the seconds are changing.
Is there a software limit that enforce maximum one packet per second?
In fact in my application I need to have several records per seconds with a better accuracy than one second in the timestamp. For example on the following picture, I would like to be able to tell that the signal D2 went low 200ms before the signal D1, and that they were both low during 200ms, that 200ms later D2 went high, followed by D1 200ms later.
(the symmetry is an example. In reality the toggling instants to record will not be so well spaced in time, and that is precisely that io toggle spacing in time that need to be recorded)
Actually I’m getting only (1+) 2 records (see red), with each timestamp ending with 000. I’m missing events, and I’m not able to locate the events in time with a better accuracy than one second.
In that example situation, I would like to get (1+) 8records (see green) with a timestamp that actually contain ms instead of 000, that would allow me to locate the “on change event” precisely in time. The sending of the record could be delayed of course (for example to the next second multiple in my example), but the timestamp should refer to the event instant.
Unfortunately, using a counter does only allow to count the events, but I still would not be able to locate them in time precisely.
