n8ur
commented
4 years ago Hi German --
This is a known situation (I hesitate to call it an issue or a bug, because it's complicated). There are two things going on, one if which can probably be mediated and the other not.
The big problem is that you can never guarantee that the two channels will always come out in "ABAB" order because there are many perfectly legitimate conditions where that sequence doesn't occur -- including only one channel in use, channels running at different rates, or time interval between them being so small that noise or drift causes them to cross. There's no way to automatically deal with those situations in the code.
The second phenomenon is in the nature of the way the TDC-7200 chip in the TICC works. Without going into gory details, if the two channels trigger within a short (probably < 100 us, but I haven't fully verified that) period, there's no guarantee which chip's output will first be processed by the Arduino, so you could get outputs that are out of order, resulting in what you show in your snippet.
There's no way to fix this behavior, but I think it's possible for the Arduino processing loop to check each result to see if its timestamp is earlier than a prior one, and if so flip the output order. I plan to implement that as soon as I have some cycles free. If it works, it will ensure that the TICC will always output timestamps in increasing order and solve some of the instances of "ABBA" output. But again it can't solve the first problem.
John
On 6/24/20 5:10 PM, germanh1982 wrote:
Hi
When using the TICC with both channels simultaneusly and the channels' relative phase is low enough, the TICC spits out the readings in an order different than the relative time of each event:
timestamp (seconds)
0.439584593247 chA 0.439582179116 chB 0.689584594560 chA <--- This row and the next are out of order, for example 0.689582177550 chB <--- 0.939582176044 chB 0.939584595875 chA 1.189584597191 chA 1.189582174452 chB 1.439582172960 chB 1.439584598507 chA 1.689582171446 chB 1.689584599821 chA 1.939582169811 chB 1.939584601135 chA 2.189584602511 chA 2.189582168244 chB 2.439584603827 chA
This doesn't seem to happen when the relative phase difference between the inputs doesn't let the event times between channels get close. During this situation, the readings come out in order, as far as I can tell.
The issue causes Timelab to confuse the input readings, because of the way the channels are configured and interpreted in the software: for each reading cycle, chA is the first reading and chB goes after chA. I understand this is also an issue with Timelab, because it shouldn't expect that the reading are always in order.
I'm not sure whether this is a Timelab bug or the TICC firmware. I understand that by having two independent inputs there's no way to ensure that the channel readings will come out in order, but I'm referring to the cases where the inputs do come out of order: Is there anything that can be done in order to avoid it from happening?
Attached is a phase difference plot from Timelab, where the issue shows. phase-difference https://user-images.githubusercontent.com/22637620/85627597-20f2c080-b645-11ea-98a4-a70991fd595c.png
Also, the phase data files used to obtained these graphs: phase-data-issue.txt https://github.com/TAPR/TICC/files/4827907/phase-data-issue.txt phase-data-ok.txt https://github.com/TAPR/TICC/files/4827908/phase-data-ok.txt
Let me hear your comments BR, German
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/TAPR/TICC/issues/30, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADNCPP5A7IQ7QI2CSTRJ4W3RYJTVNANCNFSM4OHJ7RHQ.
germanh1982
citizenrich
Hi
When using the TICC with both channels simultaneusly and the channels' relative phase is low enough, the TICC spits out the readings in an order different than the relative time of each event:
timestamp (seconds)
0.439584593247 chA 0.439582179116 chB 0.689584594560 chA <--- This row and the next are out of order, for example 0.689582177550 chB <--- 0.939582176044 chB 0.939584595875 chA 1.189584597191 chA 1.189582174452 chB 1.439582172960 chB 1.439584598507 chA 1.689582171446 chB 1.689584599821 chA 1.939582169811 chB 1.939584601135 chA 2.189584602511 chA 2.189582168244 chB 2.439584603827 chA
This doesn't seem to happen when the relative phase difference between the inputs doesn't let the event times between channels get close. During this situation, the readings come out in order, as far as I can tell.
The issue causes Timelab to confuse the input readings, because of the way the channels are configured and interpreted in the software: for each reading cycle, chA is the first reading and chB goes after chA. I understand this is also an issue with Timelab, because it shouldn't expect that the reading are always in order.
I'm not sure whether this is a Timelab bug or the TICC firmware. I understand that by having two independent inputs there's no way to ensure that the channel readings will come out in order, but I'm referring to the cases where the inputs do come out of order: Is there anything that can be done in order to avoid it from happening?
Attached is a phase difference plot from Timelab, where the issue shows.
Also, the phase data files used to obtained these graphs: phase-data-issue.txt phase-data-ok.txt
Let me hear your comments BR, German