interupt on pin 2 and 3 of a nano or uno

Im using a nano to look at 2 clocks to try and figure out some framing and crc errors I have a 4800hz square wave on pin 2 and a 9600hz signal on pin 3 if I disconect either of the signals It either count up or down in 9600 increments or there abouts if I connect both signals I would expect to get the difference in the signals taking into account one is twice the other however is counts up in 2300 increments
volatile long phase3;
volatile long phase2;
void clock2() {
phase2++;
}
void clock3() {
phase3++;
}
void setup() {
// put your setup code here, to run once:
pinMode(2, INPUT);
pinMode(3, INPUT);
phase2=0;
phase3=0;
attachInterrupt(0,clock2, RISING );
attachInterrupt(1,clock3, RISING );
Serial.begin(9600);

}

void loop() {
long phase=phase3-(phase2*2);
delay(1000);
Serial.println(phase);

}

The output from your signal analyser looks very clean but in reality it may not be so.
I'd probably try stronger pull up resistors and change the detection edge to falling (depending on what your clock source is). You can also ignore unexpectedly early spikes/pulses in the interrupt service routine (debouncing).

It might be something to do with this: have a look at the section about disabling interrupts in critical sections in this Nick Gammon forum post.

I would try changing your serial speed to something more modern, like 115200.

johnwasser:
I would try changing your serial speed to something more modern, like 115200.

Sure - but this isn't causing the problem he's having, since with that 1 second delay between prints, there's plenty of time for the data to be output to serial. And it's hardware serial, so the ISR is fast enough that it shouldn't be causing problems with the other interrupts.

Here you are accessing 32-bit volatile variables that are set in the ISR.

long phase=phase3-(phase2*2);

These accesses will be non-atomic on you 8-bit processor. See Reply #2.

I'd also changes phase, phase2, and phase3 from 'long' to 'unsigned long'