The Secret of Skinwalker Ranch S03E09 - UAP Disappearing "into Thin Air" [satellite going behind cloud/entering Earth's shadow]

The laser thing is interesting. Something I've discussed before is how lasers seem to stop at a point, giving the illusion that there's three lasers converging at a certain height. In reality that's impossible, what's happening is they are converging at the vanishing point - i.e. a point infinitely far away

This means that, regardless of viewpoint, vertical lasers will alway appear to converge at the same point in the night sky, like a point on the celestial sky.

So we can use that to match up the stars
2024-05-21_09-04-22.jpg

Probably close enough? However the narrow lower spread suggests the viewpoint is further east. I need to implement a WASD controller so you can walk around to adjust this.
 
Did they explain the need for rockets and lasers?

Ok, get ready for a whole load of nonsense.

They believe that the spooky wormhole aliens or whatever use the 1.6Ghz radio frequency band to communicate which each other/open a portal/perform some spooky alien functions or whatever, and when they have previously used rockets or lasers at the "triangle" (the area of Skinwalker Ranch underneath the wormhole) it has prompted some kind of response from said aliens. This is usually in the form of a "UAP" suddenly appearing in the sky, the rocket deviating from its course to avoid going through said wormhole or the laser beam supposedly "bending" and "splitting into separate beams" for some reason.

In a previous episode they recorded one of the signals they were receiving on the 1.6Ghz frequency and had some local radio station play it (I can't remember how the aliens responded to that one.)

So in this episode they decided to combine all three by firing the space lasers while modulating the beams with the 1.6Ghz signal recording and then firing a rocket up the middle of it all to see what the spooky aliens would do. The result was a rocket blowing up, a second rocket diverting from its course and the "UAP" this thread is all about supposedly entering a portal.

EDIT: Also, while the rocket was supposed to be on its way back to the surface it was going to release three stages of environmentally friendly chalk dust. This was apparently supposed to reveal the structure of the wormhole it, or as Travis put, "throw flour on the invisible man."
 
Last edited:
Probably close enough? However the narrow lower spread suggests the viewpoint is further east.

So the TLEs that I gave you were as follows, highlighted is the 21295/21296, which ate the YY/DDD for that the Data is Valid for...

0 GLOBALSTAR M030
1 25854U 99037D 21295.64934785 -.00000110 00000-0 -74704-3 0 9996
2 25854 51.9869 268.6740 0003355 148.9434 211.1581 11.55074063995932
0 GLOBALSTAR M030
1 25854U 99037D 21296.16857067 -.00000113 00000-0 -81562-3 0 9994
2 25854 51.9869 267.3885 0003344 149.5884 210.5127 11.55073930995999
0 GLOBALSTAR M030
1 25854U 99037D 21296.34164489 -.00000114 00000-0 -83436-3 0 9996
2 25854 51.9869 266.9600 0003339 149.8343 210.2667 11.55073902996127

For October 2021 day 296 is 23 Oct, so maybe a day out.

1716309496594.png
@Mick West I'll get the TLE for the before [edit] day after , ie 21297 = 24 Oct 2021 and attach it here in a moment.
 

Attachments

  • GLOBALSTAR M030.txt
    1.8 KB · Views: 5
Last edited:
Right now the TLE code just handles one data point per object, and if there's more than one in the TLE file it will just use the last one (which will be the latest. I had ChatGPT decode the dates.

Sure, here's the information in a simple table format:

TLE Set NumberDate and Time (UTC)
1October 22, 2021 21:48:25 UTC
2October 22, 2021 23:11:43 UTC
3October 23, 2021 03:26:08 UTC
4October 23, 2021 07:15:25 UTC
5October 23, 2021 11:58:24 UTC
6October 23, 2021 17:46:22 UTC
7October 23, 2021 19:21:52 UTC
8October 23, 2021 20:46:18 UTC
Content from External Source
so for the CSS it's currently using October 23, 2021 20:46:18 UTC

I edited the TLE to make all eight different, and got:

2024-05-21_10-36-21.jpg

I was surprised they were all in a line, The top one is the latest one. The oldest (about 23 hours earlier) is about 10 second off in time.

Which is quite significant when it comes to timing things. Eventually I'll add code for better selecting the closest TLE.
 
If you download them and flick back and forth between the two images using the built-in Microsoft Photos app the cloud movement becomes apparent.
This star:
Capture.JPG
convinces me you're right. It is a clear star close to the cloud edge, that get's fainter as the cloud moves over it.
 
I tried uses all the TLEs for the CSS from 10/23 to 10/27



Note these are all the same object, just different TLE data, 30x speed or so.

All pretty much on the exact same trajectory except the last one.
 
Just eyeballing the video and sitrec recreation side by side it looks to me like the object in the video pretty much matches the movement speed in sitrec.

But then I remembered this...

Travis Taylor: It's moving waaaayyyyyy too fast to be a satellite.

Silly me for not deferring to the expert with two PhDs and three Masters degrees.
 
After reviewing the replay of the data in sitrec and the videos I now agree that the reason the object disappears is because it goes behind the cloud, however I'd say that the reason it isnt seen to reappear out of the other side of the cloud is because the CSS enters the Earth's shadow whilst behind the cloud. It is another coincidence that would be hard to identify at the time, but is only apparent after detailed post-hoc analysis.
 
After reviewing the replay of the data in sitrec and the videos I now agree that the reason the object disappears is because it goes behind the cloud, however I'd say that the reason it isnt seen to reappear out of the other side of the cloud is because the CSS enters the Earth's shadow whilst behind the cloud. It is another coincidence that would be hard to identify at the time, but is only apparent after detailed post-hoc analysis.

Yep, absolutely. My gut feeling is they 100% knew the CSS would be passing over and entering the Earth's shadow at that location and were prepared for it, but then the pesky clouds got in the way and almost ruined their night.

It's funny, it reminds me of this time I was doing a mosiac of the Carina Nebula. I was on my last night of imaging, trying to finish off the final panel (40xHa. 40xSII, 40xOIII in 2-3 minute exposures) when the clouds rolled in. The clouds covered pretty much the entire sky except for the small area I was working on. When my final image completed the clouds fully engulfed that area within a minute.
 
Just eyeballing the video and sitrec recreation side by side it looks to me like the object in the video pretty much matches the movement speed in sitrec.

But then I remembered this...

Travis Taylor: It's moving waaaayyyyyy too fast to be a satellite.

Silly me for not deferring to the expert with two PhDs and three Masters degrees.
That's why I jumped on that sentence right at the start. So often, the thing that is so bluntly denied is what is eventually seen to be the reality. I detect and react to those unfounded denials. It's a trivial corollary to Hitchin's Razor, as the thing that is dismissed without evidence can remain under discussion without the need for further evidence. As a flipside to Hitchin's Razor, perhaps I should dub that "FatPhil's Fake Beard".
 
It's certainly going in the right direction, but the position seems a bit off, as it's right next to Deneb, but in the videos is few more degrees to the right.
I think I've tracked down why this is. The library I use for satellite positions uses the ECEF coordinate system (Earth Centered, Earth Fixed, where the origin is the center of the Earth), which is fine. However it's calculating an accurate trajectory of the satellite around an oblate spheroid, which is also fine.

But I'm rendering the world, and doing motion calculations using a sphere. This means the further north you go, the less accurate your position in real-world ECEF actually is.

More simply, a satellite moving on a circular trajectory around the center of the Earth should be higher above the ground at the poles than at the equator (as the ground is "lower" at the poles)

So the fix for this was to take the satellite coordinates in ECEF and convert them to LLA (latitude, longitude, altitude) assuming an ellipsoid and then convert them back assuming a sphere.

This moves the line to the right, and it's now almost exact.
2024-05-22_09-11-38.jpg

Here the red line is original calculation, and the yellow line is corrected.
https://www.metabunk.org/sitrec/?sitch=swrcss

JavaScript:
let ecef = V3(ecefK.x * 1000, ecefK.y * 1000, ecefK.z * 1000);

// adjust ecef to account for wgs84 ellipsoid
// rendering uses a sphere, so we need to adjust the position to account for the ellipsoid
// so the viewpoint is correct

// simple approximation
//    ecef.z = ecef.z / (1-wgs84.FLATTENING)

// const a = 6378137.0; // semi-major axis (equatorial radius)
// const b = 6356752.314245; // semi-minor axis (polar radius)
//
// const scale_factor = b / a;
// ecef.z = ecef.z / scale_factor;

// // more complex
// // convert ellipsoidal to spherical ECEF
// function ecefToLLA(x, y, z) {
//     const a = 6378137.0; // semi-major axis
//     const e = 0.081819190842622; // first eccentricity
//
//     const b = Math.sqrt(a * a * (1 - e * e));
//     const ep = Math.sqrt((a * a - b * b) / (b * b));
//     const p = Math.sqrt(x * x + y * y);
//     const th = Math.atan2(a * z, b * p);
//     const lon = Math.atan2(y, x);
//     const lat = Math.atan2((z + ep * ep * b * Math.sin(th) * Math.sin(th) * Math.sin(th)), (p - e * e * a * Math.cos(th) * Math.cos(th) * Math.cos(th)));
//     const N = a / Math.sqrt(1 - e * e * Math.sin(lat) * Math.sin(lat));
//     const alt = p / Math.cos(lat) - N;
//
//     return { lat: lat, lon: lon, alt: alt };
// }


// optimized version with precalculated values
const a = 6378137.0; // semi-major axis (equatorial radius)
const e = 0.081819190842622; // first eccentricity
const e2 = 0.00669437999014; // e squared
const b = 6356752.314245; // semi-minor axis
const ep2 = 0.00673949674227; // ep squared

function ecefToLLA(x, y, z) {
const p = Math.sqrt(x * x + y * y);
const th = Math.atan2(a * z, b * p);
const lon = Math.atan2(y, x);
const sinTh = Math.sin(th);
const cosTh = Math.cos(th);
const lat = Math.atan2(z + ep2 * b * sinTh * sinTh * sinTh, p - e2 * a * cosTh * cosTh * cosTh);
const sinLat = Math.sin(lat);
const N = a / Math.sqrt(1 - e2 * sinLat * sinLat);
const alt = p / Math.cos(lat) - N;

return { lat: lat, lon: lon, alt: alt };
}


function llaToSphericalECEF(lat, lon, alt) {
const R = 6378137.0; // Mean radius of the Earth (WGS84 Sphere)

    const X = (R + alt) * Math.cos(lat) * Math.cos(lon);
const Y = (R + alt) * Math.cos(lat) * Math.sin(lon);
const Z = (R + alt) * Math.sin(lat);

return { x: X, y: Y, z: Z };
}

const llaPos = ecefToLLA(ecef.x, ecef.y, ecef.z);
const sphericalECEF = llaToSphericalECEF(llaPos.lat, llaPos.lon, llaPos.alt);
 
So the fix for this was to take the satellite coordinates in ECEF and convert them to LLA (latitude, longitude, altitude) assuming an ellipsoid and then convert them back assuming a sphere.
While this fixes the issue, it does it by pushing the satellites higher at the poles, so it's not physically accurate. However neither is any of the code that assumes a sphere. It's only a minor issue for things >100km away, like satellites, and maybe very distant mountains.

Ideally everything would use an ellipsoid model. but that's a lot of work (and bugs) for no real reward.

It should not be an issue with the stars and planets, as they are just rendered on a celestial sphere, viewed from its center.
 
While this fixes the issue, it does it by pushing the satellites higher at the poles, so it's not physically accurate. However neither is any of the code that assumes a sphere. It's only a minor issue for things >100km away, like satellites, and maybe very distant mountains.


1000114660.jpg
 
So the fix for this was to take the satellite coordinates in ECEF and convert them to LLA (latitude, longitude, altitude) assuming an ellipsoid and then convert them back assuming a sphere.
wouldn't it have been easier to move the observer, aka adjust the radius of the sphere to the geoid at the current location?
 
wouldn't it have been easier to move the observer, aka adjust the radius of the sphere to the geoid at the current location?
If I did something like that then everything else (except stars) would be wrong, so I'd have to separate rendering and then combine them. And it's not exactly the same thing, as moving the observer does not changed the positions of satellites relative to each other - or other things like planes.

This way essentially puts everything Earth-relative in the same coordinate system (geodetic LLA) and they all get the same transform to the engine's rendering coordinate system (EUS) and then camera space - and they are just part of the same 3D scene. So it's easier (code-wise) to do it like this.
 
Back
Top