You are using an out of date browser. It may not display this or other websites correctly.

You should upgrade or use an alternative browser.

You should upgrade or use an alternative browser.

- Thread starter jimmyslippin
- Start date

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.

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:

I just put in the "hold L to drag the camera about in the main view" controllerProbably 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 puts the camera back near the helipad

https://www.metabunk.org/sitrec/?sitch=swrcss

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 99037D21295.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 99037D21296.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 99037D21296.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.

@Mick West I'll get the TLE for the

Last edited:

@Mick West I'll get the TLE for the day before , ie 21294 = 21 Oct 2021 and attach it here in a moment.

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:

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.

This star: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.

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.

But then I remembered this...

Silly me for not deferring to the expert with two PhDs and three Masters degrees.

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.

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".

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.

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.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.

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

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 notSo 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.

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.

physicallyaccurate. 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.

It appears we have more spooky satellites and space lasers on the menu in next week's episode.

wouldn't it have been easier to move the observer, aka adjust the radius of the sphere to the geoid at the current location?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.

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 notwouldn't it have been easier to move the observer, aka adjust the radius of the sphere to the geoid at the current location?

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.

How did they determine the “UAP” was directly over the triangle?

Thread discussing gaps in lasers is CLICK HERE.It appears we have more spooky satellites and space lasers on the menu in next week's episode.

somehow that post did not get moved when the others didThread discussing gaps in lasers is CLICK HERE.

- Replies
- 7

- Views
- 2K

- Replies
- 65

- Views
- 11K

- Replies
- 11

- Views
- 3K

- Replies
- 136

- Views
- 18K