ISR's in photoswitch sensorgate's [RESTARTED]

[cattledog]

does this 1st image make sense?

I am confused I thought that the on course time for a dog would be from breaking A on the way out to breaking B on the way back in. It looks like it is A out to A back. Is that correct?

I was thinking that a near perfect pass would be when the incoming dog breaks B just before the outgoing dog breaks A. If the outgoing dog is in front of the A sensor when the incoming dog gets to A , you wont know the incoming dogs race time.

What you are calling split time is the inefficiency of the pass or start--i.e. the gap between the green light and the first dog out or the gap between the two dogs crossing A. Is my understanding correct?

[YvesD]

@ Cattledog,

I am confused I thought that the on course time for a dog would be from breaking A on the way out to breaking B on the way back in. It looks like it is A out to A back. Is that correct?

picture "A" as the sensor on the side the handlers take place, and the "B" sensor towards the flyball box where the ball is....
the dogs run away from the handler, through "A" & "B" towards the ball they have to fetch, once they have is, they run back towards their handler, at a specific moment the next handler releases his dog towards a new ball put in the same flyball box, on a certain moment those 2 dogs will pass eachother, our goal is to release them so they exactly "pass" on the sensor lines...

here's a video of what our sport looks like, the "A" is towards the handlers, the "B" towards that flyballbox.
flyball, complete run video

mention 1 dog running, (this is only an example, because we always have to race 4 dogs on after the other to have a complete "Race")

dog goes through "A" and then breaks "B", on the way back to the handler breaks "B" and then "A"
can you visualise that?

multiple dogs running,
1st dog breaks "A" and then breaks "B", on the way back breaks "B",and only from that moment on the next dog is permitted to break "A" (=> n2n passing) and immediatly break "B" (if not still broken by 1st dog), on the way back breaks "B", ...... for the other dogs

and exactly at this point is where the difficulty for me is, i don't know how to put the dog++, and there are no means to calculate a split time, so that's why they call it an "OK" passing

I've made another drawing (with eagle )
this drawing represents a race with only 1 split time from the first dog, the 3 others make a n2n passing, can you picture it in your mind?

a "splittime" is indeed the inefficienty of the handlers inreleasing the dogs to exactly "pass" on the sensorlines

@Dlloyd,

your drawings "rock"
but a n2n doesn't always mean that the "B" changes (althoug it can, due to different sizes of dogs)

i've got a new drawing for you below, (indeed there is a fault, the second row is indeed "photosensor"B", sorry for that)

Grtz,

[YvesD]

Hi guys,

here is what we call a "fault" passing :

Grtz,
Yves

[cattledog]

I think this third image is a fault, where A is broke by the outgoing dog before B is crossed by the incoming dog. Is that correct?

In the fourth image I can't determine the timing between the A and B signals. Is that a valid pass?

[YvesD]

@Cattledog,

cattledog:
I think this third image is a fault, where A is broke by the outgoing dog before B is crossed by the incoming dog. Is that correct?

In the fourth image I can't determine the timing between the A and B signals. Is that a valid pass?

@ question1 : yes, indeed that's a fault passing, but could imagine dogs running from right to left, thus breaking "A" first, before breaking "B"?

on the second lane, the sensors are horizontaly mirrored for that purpose...making "A" again the side of the handlers (the "A" side is always the side where the handlers are stationed, "B" is always the side where the flyballbox is placed)

that would make your text about the third image:

I think this third image is a fault, where A is broke by the incoming dog before B is crossed by the outgoing dog. Is that correct?

so that would be the correct text for a "fault"

@ question2 : yes, IF "B" was broken 1ms before "A", otherwise no !

Grtz,
Yves

[YvesD]

@Dlloyd,

dlloyd:
For "almost nose to nose" is both "BAB" and "ABA" possible?
For "nose to nose", I would think "BA" or "AB" is possible depending on which interrupt triggers first.

"BAB" is can indeed be a valid pass, if the first "B" comes from the outgoing dog, and that dog is small enough unbreak "B", before it is rebroken by the incoming dog...

"ABA" not and neighter is "AB", because any passing starting with "A" is a fault, due to the fact that prior to "A", "B" must be broken by the previous dog comming out of the lane...

Also, has a single dog ever tripped the furthest sensor row first, or do missing interrupt(s) / signal(s) occur?

normally every dog, first hits the "A" before hitting the "B" on his way to the box, i never had a problem (although, at the time i was drawing data without delay to the LCD's, i almost missed every event , because calculations and datawritting took so long that my system was not idle to "catch" a dog that broke a sensor)

Grtz,
Yves

[dlloyd]

Thank you for your explanations ... your faultlamp image is very helpful.

I would think that for a complete race (without nose to nose) there would be 16 transitions on each interrupt and the goal in software will be to account for a total of 32 "events". Correct?

[YvesD]

@Dlloyd,

16 transistion can be enough, because the second lane is a complete identical system, with only the RF receiver to start the race parallel contect to each other.

or less in case of n2n passings of course...

Grtz,
Yves

[dlloyd]

By transitions, I mean just counting all the "RISING" and "FALLING" events ... in the image in reply#38, there are 16 +16.

[YvesD]

dlloyd:
By transitions, I mean just counting all the "RISING" and "FALLING" events ... in the image in reply#38, there are 16 +16.

Ah OK then, that's right then
but how to capture that in software???

Grtz,
Yves

[dlloyd]

It depends on what your using as a parameter when you use "attachInterrupt"
If it's "FALLING", then there'll be 8 + 8 interrupts.
If it's "CHANGE", then there'll be 16 + 16 interrupts.

I couldn't find where you use interrupts in your code.

[YvesD]

@Dlloyd,

i was not in to interrupts up to this, i'll rework my hardware to meet you're requirements with the interrupts, by the end of this week i hope (my seasonal holidays are over as of tommorow )

I get back to this topic ASAP with more news on my hardware and maybe some more drawings

Grtz,
Yves

[dlloyd]

Something to consider...

unsigned long long Aa, Bb, Cc, Dd, Ee;
unsigned long A, a, B, b, C, c, D, d, E, e; // for printing

void setup() {
  Serial.begin(115200);

  // This example could represent a timing diagram. It shows how easy it is
  // to directly work with the signal pattern using numerics and logic.

  // The signal transitions for a complete race could be sored in just two 16-bit
  // variables.

  Aa = 0b1111111111001111111111111100111111111111110011111111111111001111; // SensorA
  Bb = 0b1111111111100111111111111001111111111111111001111111111110011111; // SensorB

  // Signal Analysis:

  Cc = Aa ^ Bb;  // Bitwise XOR: 1's represent where signals Aa and Bb differ
  Dd = Aa & Bb;  // Bitwise AND: 0's represent where either Aa or Bb are 0.
  Ee = Aa | Bb;  // Bitwise OR: 0's represent where both Aa and Bb are 0.

  // prepare for printing...
  // leading zeros were added to XOR to better visualize the data
  // this only works for the pattern shown above

  A = Aa >> 32;
  a = Aa;
  B = Bb >> 32;
  b = Bb;
  C = Cc >> 32;
  c = Cc;
  D = Dd >> 32;
  d = Dd;
  E = Ee >> 32;
  e = Ee;
  Serial.print("SensorA: ");
  Serial.print(A, BIN);
  Serial.println(a, BIN);
  Serial.print("SensorB: ");
  Serial.print(B, BIN);
  Serial.println(b, BIN);
  Serial.print("A XOR B: 0000000000");
  Serial.print(C, BIN);
  Serial.print("0000000000");
  Serial.println(c, BIN);
  Serial.print("A AND B: ");
  Serial.print(D, BIN);
  Serial.println(d, BIN);
  Serial.print("A OR B:  ");
  Serial.print(E, BIN);
  Serial.println(e, BIN);
}

void loop() {
}

[YvesD]

Hi Dlloyd,

it has happened, you lost me ;D

i have totaly no idea of how i can store time capture's in that sort of data!
i can figure out that every possibility of "0's" and "1's" can represent something of an event

i've never ever used binairy data or variables, so i'm confused about that
(although my feeling is, that you will explain a few things to me )

I think i do understand why you use unsigned long long, that's for storing the microseconds in then, as they quickly become so big, right?

but the rest of the code is not my cup of tea yet,

Grtz,
Yves

[dlloyd]

I think i do understand why you use unsigned long long, that's for storing the microseconds in then, as they quickly become so big, right?

Actually, it's just an example showing how a complete timing profile could be stored in one number. If each "bit" represents 0.1 sec in time, then a 64-bit number could store the sensor's signal pattern for a 6.4 sec race. 1's are when the signal is HIGH, 0's are when the signal is LOW. It's not a requirement for your code ... but handy for analysis of the data.

Think of it like a logic analyzer, where a few simple operations could extract and detect fault passings, nose to nose passings, etc. Really, the only information needed for analysis are the transitions themselves, just two 16-bit variables. Your existing HeatClass could be used simultaneously, as is.

i've never ever used binairy data or variables, so i'm confused about that
(although my feeling is, that you will explain a few things to me )

Well, I wasn't going to explain anything, but now that you've mentioned it...

Just to show how a perfect race with with all nose to nose passings could be stored and analyzed:

Strings:  "ABBABABABA"  <-- existing string
SensorA:   1001010101   <-- binary number showing SensorA crossings
SensorB:   0110101010   <-- binary number showing SensorB crossings
           ----------
raceStatus 1111111111   <-- variable that stores the race status

raceStatus = SensorA | SensorB;
if (raceStatus == 0b1111111111)
{
  Serial.println("perfect race!");
}

[YvesD]

Hi Dlloyd & Cattledog,

i started with rewireing my hardware on a spare Mega2560,

unsigned long long previoustime = 0;
unsigned long long time = 0;

void setup()
{
  Serial.begin(115200);
  attachInterrupt(1, Time, CHANGE);
}

void loop()
{
  if (time != 0 && time > previoustime)
  {
  Serial.println(time);
  previoustime = time;
  }
}
void Time()
{
  time = micros();
}

but i get an error in the Serial.println,
but if I use "long" instead of "long long" everything works fine
can't one use long long in the serial monitor?

Grtz,
Yves

[dlloyd]

can't one use long long in the serial monitor?

No, long (32-bit) is the max.
On the demo code, I had to break the long long down into 2 pieces.
I don't think you need to worry about storing micros() in a long ... it'll take 71 minutes to overflow.

[YvesD]

Hi Dlloyd,

works fine with "long"

made a drawing of the hardware setup, took NPN because no photocells 3-wires in fritzing !

edit:
Now is the question how to store the interrupt "changes" into some sort of variable's so that i can do some maths with them in the main loop. For the project it could be beneficial to have all events, "A" idle, "A" change1 (when dogs break the beam), "A" change2 (when the dogs unbreak the beam) and the same for "B"...
Maybe the second connection from the sensors to another digital pin will come in handy then?
To see, as mentioned by you, to determine if its HIGH (unbroken beam), or LOW (dog in front of the sensors)... do i see that correct?

Grtz,
Yves

[dlloyd]

Something to try:

volatile unsigned long time1 = 0, time2 = 0;
volatile unsigned long sensor1 = 0xFFFFFFFF, sensor2 = 0xFFFFFFFF;
boolean printFlag = LOW;

void setup()
{
  pinMode(2, INPUT_PULLUP);
  pinMode(3, INPUT_PULLUP);

  Serial.begin(115200);
  attachInterrupt(0, Time1, FALLING);
  attachInterrupt(1, Time2, FALLING);
}

void loop()
{
  if (printFlag)
  {
    Serial.print("time1: ");
    Serial.println(time1);
    Serial.print("time2: ");
    Serial.println(time2);
    Serial.print("sensor1: ");
    Serial.println(sensor1, BIN);
    Serial.print("sensor2: ");
    Serial.println(sensor2, BIN);
    Serial.print("time2 - time1: ");
    Serial.println(time2 - time1);
    Serial.println("-------------------------");
    time1 = 0;
    time2 = 0;
    printFlag = LOW;
  }
}
void Time1()
{
  time1 = micros();
  sensor1 = sensor1 << 1;
  sensor2 = (sensor2 << 1) | 1;
  printFlag = HIGH;
}
void Time2()
{
  time2 = micros();
  sensor2 = sensor2 << 1;
  sensor1 = (sensor1 << 1) | 1;
  printFlag = HIGH;
}

[YvesD]

Hi Dlloyd,

just tried your code, and printscreened it (see attach.)

the strings for "sensor1 & 2" do make a lot of sense to me now, you're just filling up that var with the "LOW"'s of the photocells (by putting a "0"), right?
that's a awesome way to make sensor events visible !!!

i did some tests with an A4 portrait piece of carton, so at least once, both sensors would be covered at the same time, just like a dog would do)

was this what you where aiming for? (although, sometimes when i do a simple ABBA, i get 6 readings ! - too sensitive?? - see 1st piece of code below this)

time1: 8978736 //"A" forward
time2: 0
sensor1: 11111111111111111111111111111110
sensor2: 11111111111111111111111111111111
time2 - time1: 4285988560
-------------------------
time1: 0
time2: 8998892 //"B" forward
sensor1: 11111111111111111111111111111101
sensor2: 11111111111111111111111111111110
time2 - time1: 8998892
-------------------------
time1: 9028160 //"A" forward ?? - distortion by hand or something else??
time2: 0
sensor1: 11111111111111111111111111111010
sensor2: 11111111111111111111111111111101
time2 - time1: 4285936036
-------------------------
time1: 13136752 //"A" back???
time2: 13136740 //"B" back
sensor1: 11111111111111111111111111010010
sensor2: 11111111111111111111111111101101
time2 - time1: 4294967284
-------------------------
time1: 13153828 //"A" back
time2: 0
sensor1: 11111111111111111111111110100100
sensor2: 11111111111111111111111111011011
time2 - time1: 4281813468
-------------------------
time1: 13198936 //"A" back
time2: 0
sensor1: 11111111111111111111111101001000
sensor2: 11111111111111111111111101101111
time2 - time1: 4281764848
-------------------------

after this i did a test with "CHANGE" instead of "FALLING"

time1: 267808 // "A"-in
time2: 0
sensor1: 11111111111111111111111111111110
sensor2: 11111111111111111111111111111111
time2 - time1: 4294699488
-------------------------
time1: 0
time2: 297788 //"B"-in
sensor1: 11111111111111111111111111111101
sensor2: 11111111111111111111111111111110
time2 - time1: 297788
-------------------------
time1: 332336 // "A"-out
time2: 0
sensor1: 11111111111111111111111111110100
sensor2: 11111111111111111111111111110111
time2 - time1: 4294630608
-------------------------
time1: 0
time2: 348684 //"B"-out
sensor1: 11111111111111111111110100000001
sensor2: 11111111111111111111111011111110
time2 - time1: 348684
-------------------------
time1: 2496580 //"A"-in back - distortion by hand or something
time2: 2496568 //"B"-in back
sensor1: 11111111111111111111010000000110
sensor2: 11111111111111111111101111111001
time2 - time1: 4294967284
-------------------------
time1: 2520272 //"A"-in back
time2: 0
sensor1: 11111111111111111110100000001100
sensor2: 11111111111111111111011111110011
time2 - time1: 4292447024
-------------------------
time1: 0
time2: 2538616 //"B"-out back
sensor1: 11111111111111111101000000011001
sensor2: 11111111111111111110111111100110
time2 - time1: 2538616
-------------------------
time1: 2575984 // "A"-out back
time2: 0
sensor1: 11111111111111110100000001100100
sensor2: 11111111111111110111111100110111
time2 - time1: 4292386980
-------------------------

the only thing that confuses me is the math of "time2 - time1" in the first section and the last section on the serial monitor. Those figures seem awefully big, as i only did : "AB" - 4sec wait outside the sensors -"BA"

btw : i did try with the external & internal pull-ups, both worked fine !

Grtz,
Yves