It looks like you're using an Ad Blocker.

Please white-list or disable AboveTopSecret.com in your ad-blocking tool.

Thank you.

 

Some features of ATS will be disabled while you continue to use an ad-blocker.

 

mystery ufo near ISS

page: 11
39
<< 8  9  10    12 >>

log in

join
share:

posted on Jan, 20 2015 @ 02:42 PM
link   

originally posted by: RoScoLaz4
"A UFO has been spotted near the International Space Station in footage broadcast after astronauts evacuated part of the orbiting craft.

Alien spotters noticed a strange object disappear behind the ISS, reigniting bizarre claims that the space station is actually a place for aliens to come out hang out with humans.

Footage of the UFO was shown on the news channel CBS, sparking furious debate among online conspiracy nuts. It is not clear whether the film was stock footage, or taken from NASA's live feed."

video at link. looks big. note use of the term 'conspiracy nuts'


www.mirror.co.uk...
i dont know what to think(im just posting crsp to get to 20 comments so i can start a thread




posted on Jan, 20 2015 @ 03:21 PM
link   

originally posted by: tanka418
Oh...now that's truly disappointing. Perhaps better to have left that date uncorrected.

I went back an plugged in the error correction...ISS was no where near Russia at that time, nor did it pass near Arizona. In fact with the exception of south west Australia, and later northern Calif, Nevada, southern Idaho...ISS is over the Pacific. So...no...sorry; not any lakes or craters. Just water and probably a cloud, or an ocean anomaly.
So let's see if I've got this right.

You don't see the correlation between this image from the video I posted on page 8, and the following snapshot of the same region from Google earth showing the same river and same lake in the same relative positions?

From video I posted on page 8:



originally posted by: elevenaugust

originally posted by: laurentius
It is the sun reflecting on lake Elton between city Zhanibek and city Zaikhin.

In the distance you see the river Volga.

49.142447, 46.671110

Well done, I was actually searching for it


Lake Elton from GE:





Appears to be a salt deposites lake, so this probably account for the sunglint colored hue.

Case solved!


Even the photo from the wikipedia article on Lake Elton (second image in elevenaugust's post) shows that it has a non-uniform appearance, darker on one side and lighter on the other, consistent with the mystery object.

I suspect you failed to consider some things in your analysis. The camera isn't pointing straight down, for one thing, so you may actually capture some areas not directly under the ISS. I'd say so far, score one for elevenaugust for providing evidence to back up his comment, and zero evidence from you to back up yours.



posted on Jan, 20 2015 @ 05:01 PM
link   
a reply to: Arbitrageur

Perhaps you don't quite understand.

At the time of separation of STS-134 ISS was over the south Indian Ocean, by the time of the fly around it had just left south east Australia and was heading north east over the southern pacific. It's next landfall was the Northern California coast.

At no time during its mission ending flight did it pass over Russia. You can confirm this by entering the appropriate values in the history "engine" on the "ISS Tracker.com" website.

Or perhaps that isn't STS-134...and that would push this video into a third mission and time frame...how many are y'all going to use?



posted on Jan, 20 2015 @ 06:48 PM
link   

originally posted by: tanka418
At no time during its mission ending flight did it pass over Russia. You can confirm this by entering the appropriate values in the history "engine" on the "ISS Tracker.com" website.

Or perhaps that isn't STS-134...and that would push this video into a third mission and time frame...how many are y'all going to use?
All I can confirm is what I said before, your analysis is flawed and still you failed to provide any data. Even if this wasn't STS-134, there is still no mystery about what the object is, which makes your following post completely incorrect:


originally posted by: tanka418
I went back an plugged in the error correction...ISS was no where near Russia at that time, nor did it pass near Arizona. In fact with the exception of south west Australia, and later northern Calif, Nevada, southern Idaho...ISS is over the Pacific. So...no...sorry; not any lakes or craters. Just water and probably a cloud, or an ocean anomaly.
So assume for a moment it's not STS-134. We still can clearly identify lake Elton and the river above it in the video. It's definitely lake Elton no matter who photographed it and when, of that there can be no doubt, so it makes no sense for you to refer to an ocean anomaly when we can clearly see a river. The ocean doesn't have rivers flowing through it; well they do have currents, but they don't look like rivers from space.

According to the STS-134 execute package the undock was scheduled for around 03:55 GMT (13/14:59 MET) on May 30 2011 and the flyaround was scheduled to end about 80 minutes later. The object doesn't appear at the very beginning, so it would have to be after 4am GMT, so let's put 04:26:30 into ISS tracker website you suggested; it's not far from Lake Elton at all:

Lake Elton location, point "A" from Google maps satellite view:


ISS location about 31 minutes after the shuttle was supposed to undock, where it should be well into the into scheduled 80 minutes flyaround:
www.isstracker.com...


STS-134 Execute package showing scheduled separation and flyaround:
www.nasa.gov...



edit on 20-1-2015 by Arbitrageur because: clarification



posted on Jan, 20 2015 @ 07:36 PM
link   
a reply to: Arbitrageur

You're gonna love this.

That software has a serious big. When you enter an offset for a converted value, it seems to be adding some unknown value. Probably a variable that isn't properly defined. In any case it seems to shift the orbital report a significant amount.

When using a time value of 3:25 and entering an offset of 00000 you are causing an error in the report. This was detected by the fact that IF we add "0000" (zero) to the GMT value the report is different than that produced when not specifying a zero offset.

In any case it will be impossible for us to determine the precise location of ISS sue to the "broken" tool. I could write something to do the same, but, I have little motivation, and you wouldn't accept the results anyway.

In any case; the location produced by manually converting the time to GMT and NOT adding/specifying an offset is more likely to be correct (its a software thing).

BTW: in the fly around video...they specify undock time as 10:55PM CST



posted on Jan, 20 2015 @ 08:11 PM
link   
a reply to: tanka418
I changed the time by 1 hour and the offset by one hour, and it comes out the same.



I think the "bug" is you not following the instructions. If it tells you to enter an offset, and zero is a valid offset, then you should enter one, which I did. If I had to guess I'd say NOT following the instructions might cause an error, by omitting the offset. The instructions say: "Use the date format 'YYYY-MM-DD HH:MM:SS+0000' "

It doesn't say anything about any of that information being optional, I think that's a faulty assumption on your part. Maybe a programmer could have changed it so failing to enter some of the data in the expected format might still result in a correct plot, but I didn't make that assumption, and I specifically thought about whether I should enter the offset (even though it was zero), and I decided the instructions indicated it was expected.


BTW: in the fly around video...they specify undock time as 10:55PM CST


Daylight savings time begins in March, so I doubt they were using CST in May, probably CDT. So they were right on schedule.


edit on 20-1-2015 by Arbitrageur because: clarification



posted on Jan, 20 2015 @ 09:45 PM
link   
a reply to: Arbitrageur

So...you didn't see the last paragraph of those "instructions"?

It says; "You can also use the format 'mm/dd/yy hh:mm:ss' Example '12/31/2012 01:34:35'. This format requires you to convert the time you're looking for into GMT."

It very explicitly states the offset is NOT required, yet we find that it makes a significant difference.



Maybe a programmer could have changed it so failing to enter some of the data in the expected format might still result in a correct plot, but I didn't make that assumption...


Actually the default behavior would be to produce the same "plot" (output) whether the value was there or not, presuming the offset is 0000 (zero). But, this was likely done in Java, so the variables are probably variants and not initialized (Java allows that)...uninitialized variables sometimes hold random data.

By the way; I've been a Software Architect/Engineer for better than 40 years.



posted on Jan, 20 2015 @ 10:22 PM
link   
a reply to: tanka418
That's a completely different alternate format which uses slashes instead of hyphens for entering the date, and the date isn't in the same format.

That's not the same as entering the date using hyphens in a different sequence, and then omitting the offset. Two different things.

If you think the example you cited of the slash date format is telling you that it's ok to omit the offset from the hyphen date format, that's where you went wrong, because that's not what it's saying.

I don't see how you can confuse them, the dates aren't even entered in the same order, one puts the year first and the other the year last. In addition, saying that you MUST use GMT time in the slash format isn't saying the offset is optional...there is no concept of offset if all dates entered in that format are GMT, so of course there's no offset entered in that format.


edit on 20-1-2015 by Arbitrageur because: clarification



posted on Jan, 20 2015 @ 11:03 PM
link   

originally posted by: Arbitrageur
a reply to: tanka418
That's a completely different alternate format which uses slashes instead of hyphens for entering the date, and the date isn't in the same format.

That's not the same as entering the date using hyphens in a different sequence, and then omitting the offset. Two different things.

If you think the example you cited of the slash date format is telling you that it's ok to omit the offset from the hyphen date format, that's where you went wrong, because that's not what it's saying.

I don't see how you can confuse them, the dates aren't even entered in the same order, one puts the year first and the other the year last. In addition, saying that you MUST use GMT time in the slash format isn't saying the offset is optional...there is no concept of offset if all dates entered in that format are GMT, so of course there's no offset entered in that format.



No! Vitually all programming languages use an animal known as a "DateTime". This is true of PHP, Java, C, C++, C#, and of course VB. It is kind of a standard. This data object provides the conversion so that any "known" format may be used. This may be somewhat dependant on the individual computer's operating system, but as a general rule; anything that can resolve to a DateTime is acceptable. Thus, slashes, dashes, year month, day out of traditional order, etc. all resolves the same; as a DateTime.

If, on the remote chance this is not the case, then I submit the programmer is probably a kid, and wrote this thing originally in JavaScript. If that is the case then we will have no option but to discard any results obtained from it.

And, you still haven't told us "HOW" you arrived with your initial "observation".

By the way; the difference of an hour or even a day makes little difference in the results. The use of an offset (any offset shifts the entire "track" significantly East.

Quite frankly, I'm rather surprised this bit of code was released...I certainly wouldn't have. If the writer cannot get the time offset correct, what else does he have wrong



posted on Jan, 20 2015 @ 11:24 PM
link   

originally posted by: tanka418
a reply to: Arbitrageur

Perhaps you don't quite understand.

At the time of separation of STS-134 ISS was over the south Indian Ocean


You are wrong tanka418, this is the correct information:
The shuttle undocked on schedule at 10:55 p.m. CDT Sunday, after 11 days, 17 hours and 41 minutes attached to the station.
Endeavour and the station were flying 215 miles above and over La Paz, Bolivia when they parted ways.

I think you were reading a different mission. Check the whole STS-134 final day activities here:
www.collectspace.com...



posted on Jan, 21 2015 @ 12:16 AM
link   

originally posted by: tanka418
a reply to: Arbitrageur

Perhaps you don't quite understand.

At the time of separation of STS-134 ISS was over the south Indian Ocean,


To confirm you are wrong here is the original undocking transmission,
at minute 2:15 NASA spokesman gives the location wich is Bolivia.



posted on Jan, 21 2015 @ 12:33 AM
link   

originally posted by: free_spirit

originally posted by: tanka418
a reply to: Arbitrageur

Perhaps you don't quite understand.

At the time of separation of STS-134 ISS was over the south Indian Ocean


You are wrong tanka418, this is the correct information:
The shuttle undocked on schedule at 10:55 p.m. CDT Sunday, after 11 days, 17 hours and 41 minutes attached to the station.
Endeavour and the station were flying 215 miles above and over La Paz, Bolivia when they parted ways.

I think you were reading a different mission. Check the whole STS-134 final day activities here:
www.collectspace.com...


Indeed!

I've been checking this "ISSTracker" a bit more and am finding that it is rather sensitive to date format. This actually tells me quite a lot. The most important is that the only date format that does work is probably "mm/dd/yyyy hh:mm" with a converted time (no offset). That actually places ISS over South America during that time frame. And that is the only independently verified location. So that what we have to use.

So...no...not a different mission...broken software (ISSTracker.com/historical).

edit on 21-1-2015 by tanka418 because: (no reason given)



posted on Jan, 21 2015 @ 01:41 AM
link   

originally posted by: tanka418
By the way; I've been a Software Architect/Engineer for better than 40 years.
I think that's working against you here. You think you know how the code is written and you expect it to perform to your programming experience or something, and you either don't comprehend or otherwise don't feel you need to follow the instructions on the site.

In my case, I don't make any assumptions about how the code is written. I understand the difference in the two formats and if I follow them exactly as instructed, the site works fine for me.

If I don't follow the instructions, then yes I can get wrong results, and maybe a better coder would do some things better but it's a free site so what do you expect? If top notch programming, again you're making assumptions I'm not making.


originally posted by: tanka418
So...no...not a different mission...broken software (ISSTracker.com/historical).
Translation:

"When I don't follow the instructions, it doesn't work right"

In my case when I follow the instructions it works fine.

I won't disagree that it could be coded better, but my expectations for a free service like that to be coded so well are apparently not as high as yours. I wouldn't go so far as to say it's broken...but there's room for improvement. For example he could return an error message if you leave a required field blank, instead of plotting a location that would be wrong.
edit on 21-1-2015 by Arbitrageur because: clarification



posted on Jan, 21 2015 @ 02:54 AM
link   
Amazing that again you guys figured it out that it was a lake.. How tricky light sources and shadows and reflections can be .
Great job .. also you've to have a pretty good eyesight for landmarks and geological mapping. .

I really thought that CGI again killed the thread ..

Although I still wonder how they put that camera out there..?



posted on Jan, 21 2015 @ 07:16 AM
link   

originally posted by: SecretKnowledge
a reply to: sean

We know what it is, from page 7 of this thread we are on now,
member laurentius found it


I didn't know if that was it or not. I was just taking a shot in dark guess of what it could be. I knew right away that it was part of the landscape as it moved with the river. There is quite a resemblance though take a look at this pic and you'll see what I mean. Meteor Crater, AZ
edit on 21-1-2015 by sean because: (no reason given)



posted on Jan, 21 2015 @ 07:59 AM
link   
a reply to: sean

I see what you mean alright, if there was a river near there then it couldve been i suppose



posted on Jan, 21 2015 @ 08:04 AM
link   

originally posted by: Cobaltic1978

originally posted by: IAMTAT

originally posted by: Cobaltic1978

originally posted by: IAMTAT
Is there any possibility that it is a large high altitude cloud passing the space station is passing over?


No.

If that's true...Then we have a genuine mystery.


Indeed we do, although swamp Gas cannot be ruled out as yet 😉


To rule out swamp gas would be sheer arrogance.



posted on Jan, 21 2015 @ 09:21 AM
link   

originally posted by: Arbitrageur

I think that's working against you here. You think you know how the code is written and you expect it to perform to your programming experience or something, and you either don't comprehend or otherwise don't feel you need to follow the instructions on the site.

In my case, I don't make any assumptions about how the code is written. I understand the difference in the two formats and if I follow them exactly as instructed, the site works fine for me.



Okay, my bad...I was expecting some level of professionalism. I guess that's expecting way too much!

By the way...not sure I said this...that code would NEVER have been released in that state IF I had been involved.

The assumptions I made here are valid, in so far as a professional software engineer typically does thing rather different. For instance...I/we would allow the machine t make the conversions. But...dude didn't. He also appears to not know his language too well. This was written using PHP. A "C" like language, that has a library not unlike what I use. Date conversions are rather simple...as far as delimiters go (those characters between the numbers of the date). Typically, if the system is properly used, virtually any non-alphanumeric character can be used. But, that is not the case here because dude made a rookie mistake and didn't have it together enough to fix it. This is a lesion I learned more than 20 years ago.

Finally; No the site doesn't work fine for you, and it appears that you are still going with the error .

As I said; there is a single format that works: "mm/dd/yyyy hh:mm:ss" with NO offset value. Which also means that we have to convert the time manually.

Thanks to Free_Spirit we know the real location of ISS when this event occurred. We were both wrong. We were both bitten by dudes inaccurate software.

My apologies to y'all for that.

By the way; I don't feel it is unreasonable to expect a certain level of professionalism in any software appearing on a website. This includes design, coding, testing, validation.



posted on Jan, 21 2015 @ 10:48 AM
link   

edit on 21-1-2015 by InhaleExhale because: delete,



posted on Jan, 21 2015 @ 02:25 PM
link   
a reply to: Arbitrageur

Well this is rare, and welcomed...

I have to thank you for a most productive argument.

This lead to me finding, and developing an understanding of www.space-track.org.... This site has available satellite tracking data for just abut everything in orbit. They have historical data as well, and it is collected and maintained by the government, or a very close association. Some f the data available is from the Air Force, NORAD, and others. All in all a very good source of satellite tracking data. IF that sort of thing interests you.

I've already downloaded data for ISS on 05-30-2011...there are only about 4 data records for that day and will have to be studied a bit to properly understand and progress.

Anyway; THANKS MAN






new topics

top topics



 
39
<< 8  9  10    12 >>

log in

join