The Secret of Skinwalker Ranch S03E09 - UAP Disappearing "into Thin Air" [satellite going behind cloud/entering Earth's shadow]
- Thread starter jimmyslippin
- Start date
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
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.
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
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.
jimmyslippin
Member
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:
I just put in the "hold L to drag the camera about in the main view" controller
This puts the camera back near the helipad
https://www.metabunk.org/sitrec/?sitch=swrcss
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...
For October 2021 day 296 is 23 Oct, so maybe a day out.
@Mick West I'll get the TLE for the
Last edited:
jimmyslippin
Member
Wouldn't we need the data for 24/25 Oct 2021?
EDIT: Your CSS TLE data is also from 22/23 Oct 2021.
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.
I edited the TLE to make all eight different, and got:
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.
so for the CSS it's currently using October 23, 2021 20:46:18 UTC
Sure, here's the information in a simple table format:
TLE Set Number Date and Time (UTC) 1 October 22, 2021 21:48:25 UTC 2 October 22, 2021 23:11:43 UTC 3 October 23, 2021 03:26:08 UTC 4 October 23, 2021 07:15:25 UTC 5 October 23, 2021 11:58:24 UTC 6 October 23, 2021 17:46:22 UTC 7 October 23, 2021 19:21:52 UTC 8 October 23, 2021 20:46:18 UTC
I edited the TLE to make all eight different, and got:
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.
JMartJr
Senior Member.
This star:
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.
jimmyslippin
Member
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.
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.
jimmyslippin
Member
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.
FatPhil
Senior Member.
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".
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.
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);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.
jimmyslippin
Member
It appears we have more spooky satellites and space lasers on the menu in next week's episode.
Mendel
Senior Member.
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.
LeastWeasel
New Member
How did they determine the “UAP” was directly over the triangle?
JMartJr
Senior Member.
Thread discussing gaps in lasers is CLICK HERE.
Mendel
Senior Member.
somehow that post did not get moved when the others did
Similar threads
