08-02-2005 07:48 AM
08-03-2005 04:38 PM
Hello J-F,
It seems that you know what rate you need to acquire your serial message at, so I do not understand why you need a trigger at all. It seems you are getting a bit for each external clock pulse, so why can't you acquire all data and just dispose of any you do not need by parsing your data after it is acquired? Using this method, you should easily be able to acquire at the rate you want.
Maybe I do not understand what you are trying to do, so please post back with more information.
Thanks,
Laura
08-04-2005 07:30 AM
Hi Laura,
Thanks for the reply.
Well, the trigger ensures me that I will not desynchronize. This test will be run for a couple of months continuously, so the probability of a glitch on the clock is quite high.
Yes I could probably redesign without a trigger, but I do not have a lot of experience with buffer manipulation. I have a CRC on my data, but if I discover an error how do I recover coherently? Clear the buffer until I accidentally recover in-between messages? Maybe I could use the trigger then to resynchronize (well, I think this could work, I tough of it while writing you this reply, you already helped me!!!! thanks!!!)
Another way would be to acquire my 112 bits, then pause the acquisition for the duration of another couple of bits (so that if I had extra clocks they will be ignored and I will recover at the next message). But how do I do that since timeout/timer resolution is 1mS??
08-05-2005 03:54 PM
Hello JF,
I see now why you want to have the trigger. I think a retriggerable operation would work best for you. A retriggerable operation requires counters (since they are retriggerable), which the 6534 does not have. If you have a second device with counters, there is an example that shows how you could set this up.