I wasn’t able to get a response earlier, so I decided to signal boost this issues with the observation generation.

I believe I have found another problem. When using the generate function, the returned observations only come from the first pass of the satellite into observable space, and none of the subsequent. I’ve tried forcing the generator to restart after the end of first pass, but no dice. In testing I propagated for a time that I calculated to contain 3 passes, but only data from the first was generated. Just in case I made a mistake, I then increased the difference between the first date and second date to ridiculous lengths, and no change. Any suggestions on getting the data from all the passes? I would like to be able to generate the all the observations between the initial and final date and not just the first pass.

I think this may be a side effect of the event detector you use.
When building EventBasedScheduler, you give it an EventDetector, which in your case is probably an ElevationDetector. This detector is wrapped by EventBasedScheduler in such a way the event generation feature can see when the event occurs. The side effect is that after having seen the occurrence, the wrapper also calls the eventOccurred method from the original EventHandler that was already registered in the original EventDetector. The default handler for ElevationDetector as documented in the javadoc is to return Action.CONTINUE at raising events, and Action.STOP at setting events. Hence propagation is stopped at the end of the first pass.

One way to avoid this is to change the default event handler using something like:

EventDetector detector = new Elevationdetector(...).withHandler(new ContinueOnEvent<>());

With this configuration, the eventOccurred method will return Action.CONTINUE for both raising and setting events and the propagation should not stop too early.

I have one more question about observation generation about noise. It seems like I have been able to get it to work accurately for range measurement, but as soon as I add noise to the angular observation generation, my orbit determination no longer works. When using the following noise generation, the converged orbit is on the order of 1000s of standard deviations away from the truth:

NormalizedRandomGenerator NRG = new GaussianRandomGenerator(new RandomDataGenerator());
RealMatrix cov2 = MatrixUtils.createRealIdentityMatrix(2);
CorrelatedRandomVectorGenerator cRVG2 = new CorrelatedRandomVectorGenerator(new double[]{0,0}, cov2 , 0.001, NRG) ;
AngularAzElBuilder aAEB = new AngularAzElBuilder(cRVG2, station, azElError, baseweight, obs);

Something is clearly wrong, but after reading the documentation it is still not clear. Any ideas on whats going on?

The covariance matrix is probably the culprit. It is set to identity, which means the standard deviation is 1 radian in azimuth, 1 radian in elevation, and no correlation. You should probably set the diagonal values to the square of the angles standard deviations, taking into account the degrees/radians factor. If for example your ground stations measure angles with a standard deviation of 0.01°, the diagonal elements should be (0.01 * π/180)^2 ≈ 3e-8.

Ah I see. I was under the assumption that the noise generation was normalized since the standard deviation is still an input. This makes sense! Thank you again!

I have another report of strange behavior. When I generate observations across a number of tracks and then separate the data by track I’ve noticed some erroneous behavior. I take the observation data and separate it into track sets by checking if the time is greater than my fixed step size of 10 seconds. I then use the batch least squares routine on each set of data individually. Then I check how many standard deviations away each track’s batch least squares orbit is from the truth.

Logically the tracks containing more observations over a longer time should have a better fit to the truth. This is my problem, however, as this does not happen. Each track’s converged orbit converges within the same standard deviations regardless of the number of observations. I’m relatively sure the track separation works, as well as the batch least squares routine otherwise. I can’t really think of a cause outside of perhaps the random data generator working incorrectly and producing a consistent bias.

Do your track have a really different number of observations? I would guess the effect would be in the square roots of number of observations, so except if tracks are really different, it would be difficult to see. It is also only a guess, inspired by the central limit theorem, however orbit determination is not the same as summing random variables, so the square roots reduction is most probably far from reality.

Another point: as track are separated in time, are they all referenced to the same initial orbit date? If OD on track 1 involves a 1 hour propagation between initial orbit and first measurement whereas OD on track 2 involves a 3 hours propagation between initial orbit and first measurement, it may have an effect too and compensate measurements number.

The Hipparchus random data generators have been validated at length and are considered of high quality. The best ones are from the WELL family. They are especially suited for simulation (like Monte Carlo analysis) because they are proven to be Maximally Equidistributed even for very high dimensions and have extremely long periods (2^512 - 1 for WELL 512, 2^19937 - 1 for WELL19937).