In embedded programming, code is only half the story. The other half is the hardware.
So to make sense of the software we need to know how your hardware is wired. That involves posting a schematic. Hand drawn is fine, a collection of pictures linked with lines is not.
Having said that your code is all over the place and makes little sense.
Is just a nonsense. There is no need to use a floating point number, or to convert it into voltages, just the raw numbers will do. Also read String takes at least a second to execute, do not use this.
this is how the overall system works, the arduino is just used to calculate peaks of the input and output wave and then take the timestamps of those peaks and compare , the data is converted to voltages just to get more clarity
Whilst startTime, and endTime should be unsigned long, it is better to have delay just as long.
The value of delay can be positive or negative, depending upon the phases of the two signals.
Due to the delay between taking samples, and any noise on the signals it is not guaranteed that the two peaks detected are on adjacent peaks.
The peaks detected could be many cycles apart.
The input and output signals came from a function generator.
The signals were 1kHz sinewaves, amplitude 4V pk-pk, with a 2.5V offset, and a phase difference of 90°.
At a slower time base, the pulses on channels 2 & 4 are very narrow, but can be seen if you look carefully. The measurement shown on the screen indicates a period of 998ms.
(The frequency of the signal has been reduced to 300mHz for clarity.)
Does that help to explain why you get poor results?
makes the sample rate to go up from 1Hz to 4.16kHz.
This means that we need a different way to stop the measurements and print the results.
I used the techniques from the BlinkWithoutDelay example from the IDE, to print the results at regular intervals.
Also I didn't convert the raw ADC data to volts every reading. I just did it once, after the peak was detected, ready for printing.
The sampling period is not synchronised with the input signal.
This means that the sampling starts at some random part of the input waveform,
Depending upon which of the two signals gets it's peak detected first, you will get results of around 2500µs or -7500µs, for the particular case of 100Hz signal (period 10000µs) and phase difference of 90°.
The results could also be influenced by any noise on the signals.
Maybe an improved method would wait until it came to a negative peak on the input signal before starting to look for the positive peaks on the two signals, and then stop when it sees the next negative peak. That way you should be sure that the two peaks were from the same cycle of the waveform.
That might get rid of the is it +90° or -270° issue.
There will always be some variance in the timing depending on whether you hit the exact peak, or not.
Take as many ADC readings as you can, as fast as possible, don't do unnecessary calculations.
I don't know how the Due will perform, compared with the Uno R3 that I used.
The direct port manipulation that I put in as part of the debugging process is specific to the ATmega328P/AVR microcontroller used by the Uno, and will need removing for the Due.