There's still way too much noise and interference here. I'm baffled. Grasping at straws here, try adding a small capacitor (20 or 30 pf) across the output of the oscillator. Maybe that will help cut down any high frequency noise that's coming either out of or into the circuit. Can you post a sketch or photo showing how you've got everything connected?
I powered up an LPRO to see if there was something odd about that model, but it's running fine. I'm comparing it to my FRT. The data run was going so well that I just let it run - it's still going on. I'm powering the LPRO from an ordinary variable lab supply with clipleads. The 10 MHz output is connected by a crappy cable. I've attached a quick drawing showing what I'm doing. My data has some wiggles, but they die out quickly. I think I'm getting a bit of interference between the channels in the squarer/divider board. Squaring up the circuit reduces trigger noise and gives better results. Dividing the frequency down reduces the number of phase wraps. I made my measurements with a Fluke/Philips PM6681 counter in Time Interval mode using the 'Single' mode. Dead time may have an effect on these measurements.
I'm going to walk through the data for this run to give you an idea of how to do the analysis. I hope it will help you to troubleshoot your situation. Obviously, the values will vary with the counters and oscillators used, but the analysis will be the same.
Start with the black line on the AlDev graph which is the raw data. Notice that the graph follows a straight line down. This is the counter noise floor. The performance of the oscillators is completely masked by the counter.
There may or may not be a flat bottom section between the falling and rising portions of the graph. This is the combined noise floor of the counter and oscillators.
The rising part of the graph means that drift is coming into play. The drift is actually the sum of the drifts of the two oscillators. This can be tricky because if they're drifting in the same direction the drift might look much lower than it really is. If they're drifting in opposite directions, the result will look much higher than it really is. If you're comparing a quartz oscillator to either a Rb standard or a GPSDO, the rising portion is almost totally due to the quartz oscillator. One thing to note is that if your data run is long enough to get to 86400 seconds (i.e. one day), you've just measured the daily drift on your oscillator. This is the most common way of specifying a quartz oscillator. Rb oscillators are usually specified in terms of drift per month.
When I looked at the Phase Difference (Linear Residual) graph, I saw that there was an anomaly at about 29000 seconds. There was a significant change in the slope of the graph. On a hunch I looked at the Original Phase Difference graph and saw that the anomaly happened at the same instant as a phase wrap. The effect that the phase wrap had on the slope of the graph is very odd. I can't explain it. I hope that I see another phase wrap before the data run ends. I decided to delete the data that came before the phase wrap.
That's a weird one, all right. I haven't followed the whole thread but I loaded your file and it does look a bit unusual. Try this:
fg 300 to set a 300-second averaging window
r to look at the residual (make sure
z mode is off)
You can see that the frequency drift settled down about 6 hours into the run, then, at 8 hours, the frequency of one of the sources jumped a bit. That's what caused the phase wrap, or at least was associated with it. It then started drifting back up.
Overall, your ADEV looks reasonable for a pair of rubidium standards that haven't been powered on for very long, and/or are in an unstable environment. One or the other of your test sources needs some more time to settle down, it looks like. Hit
e and change the Trace History to 3, and you can see the effect I'm talking about:
Your later (darker) traces look more like my measurement of an LPro with an HP 5370B.
Moral of the story (or at least my post): look to the frequency-difference view to find out what's going wrong with your ADEV view. It's very hard to use ADEV as an initial diagnostic.