[00:11.540 --> 00:17.080] Welcome back to the competition formerly known as Space Security Challenge 2020, now HackASAT. [00:17.100 --> 00:21.720] Well, it's actually still known by Moth. I just wanted to change the intro because they're going [00:21.720 --> 00:26.660] to get pretty repetitive. I'm your host, Jordan Wines. The game has been a little bit slower this [00:26.660 --> 00:30.280] hour, but that makes sense because teams are starting to get into the harder challenges. [00:30.380 --> 00:34.100] As a reminder, teams are currently working on two separate challenges. [00:34.100 --> 00:41.900] First, the on-orbit challenge involves them designing a payload that will execute a moonshot, [00:41.900 --> 00:46.240] taking a picture of the moon from an actual orbiting satellite. While that challenge won't [00:46.240 --> 00:51.480] show up on the scoreboard with points, it is a pass-fail challenge. Only teams that score within [00:51.640 --> 00:56.840] a time window will be eligible for podium placement and the related $50,000, $30,000, [00:56.840 --> 01:02.840] and $20,000 prizes. Since there's a lot of data being displayed on our octagon scoreboard, [01:02.840 --> 01:07.200] otherwise known as that thing you're looking at when it's not my face on this YouTube feed, [01:07.200 --> 01:12.760] here's a quick primer on some of the elements. First, the display on the left shows a scoreboard [01:12.760 --> 01:17.680] breakdown that breaks down each team's points earned per challenge, shows the total score, [01:17.680 --> 01:22.580] and includes a log of recent solves and messages sent from each team to their Flatsat. [01:22.600 --> 01:26.500] Note that the message contents have actually been sanitized to not give away answers, [01:26.500 --> 01:28.940] but you might find some other things there instead. [01:29.900 --> 01:35.640] On the right scoreboard, you'll see the time of the teams, you see the score of the teams over time. [01:35.960 --> 01:39.520] Right now it's skewed a little bit to the left, but as the game progresses, it'll stretch out [01:39.520 --> 01:45.500] and we'll see how they do on each of these new challenges. Finally, each team has a dedicated [01:45.500 --> 01:51.120] panel with a main view and three supplementary views. Technically, we can change the supplementary [01:51.120 --> 01:57.420] views, but right now the main view shows a team logo with their color, a representation of the [01:57.420 --> 02:02.820] team's Flatsat, including their rotation, position over the earth, and messages sent. Note that the [02:02.820 --> 02:08.060] little pew-pew you see are just for visual effect and not actually representative of actual messages [02:08.060 --> 02:13.380] being sent. On the graph right now on the right, excuse me, the three graphs on the right, the top [02:13.380 --> 02:19.160] graph is yaw, the middle graph is angular velocity, and the bottom graph is total messages, all done [02:19.160 --> 02:24.200] over time, which makes for a nice overview of the different activity from each team's Flatsat. [02:24.200 --> 02:28.900] Remember, you can vote to control which of these views you're looking at in the virtual environment [02:28.900 --> 02:34.260] inside of the Stardome. That feed doesn't cut over these live updates and always shows the octagon. [02:34.840 --> 02:38.540] While we wait on our teams to continue to solve these challenges they're working on, [02:38.540 --> 02:43.540] now's a great time to introduce another segment we call Space Talk. If, like me, you're a hacker [02:43.540 --> 02:47.880] who might know about computers but is ignorant of what goes into making code run in space, [02:47.880 --> 02:52.760] there's a lot of new things to learn. Our first Space Talk episode is about how to keep track of [02:52.760 --> 03:15.460] time in space. So what time is it in space? Well, that's a complicated question. For the astronauts [03:15.460 --> 03:19.960] on the International Space Station, and for most orbiting satellites, they run on Coordinated [03:19.960 --> 03:26.760] Universal Time, or UTC. It's not actually a time zone but rather a time standard that just so [03:26.760 --> 03:33.420] happens to be the same as GMT. It's used to prevent time zone confusion and give a standard time to [03:33.420 --> 03:40.280] reference. But for astronauts especially, it's just a number. On the International Space Station, [03:40.280 --> 03:45.460] the sun rises and sets about every 90 minutes, so there isn't any relationship between the sun [03:45.460 --> 03:50.280] and what time it is that's meaningful to the astronauts. Satellites are the same way. Time is [03:50.280 --> 03:56.380] primarily used to inform them when to execute commands and perform operations. Universal time [03:56.380 --> 04:02.900] is just a reference number that's easy to relate back to your local time. But that's not the only [04:02.900 --> 04:09.720] time that's used for space applications. UTC is not an exact accounting of the passage of time, [04:09.720 --> 04:15.280] but rather strives to stay aligned with the rotation of the Earth, because it's primarily [04:15.280 --> 04:20.580] people on Earth that are using it. Earth's rotation is both irregular in the short term [04:20.580 --> 04:26.160] and slowing down permanently in the long term. Earth days are getting about 1.6 milliseconds [04:26.160 --> 04:32.280] longer every single day. This isn't in any way noticeable in daily life, but can be very [04:32.280 --> 04:37.540] significant over time. As a result, we use a different time scale when dealing with orbital [04:37.540 --> 04:43.480] motion. Orbital motion doesn't care about the Earth's rotation at all. It must be extremely [04:43.480 --> 04:49.780] precise because of the massive distances involved. The most common time standards used are Julian [04:49.780 --> 04:56.340] date and terrestrial time, which are both entirely independent of Earth's rotation. To give an idea [04:56.340 --> 05:03.480] of just how different these time scales can be, over the last century between 1900 and 2000, [05:03.480 --> 05:10.800] universal time was about 64 seconds slower than terrestrial time. It's a tiny difference to us, [05:10.800 --> 05:16.400] but when you're dealing with precise predictions over millions of miles, it gets very significant. [05:16.400 --> 05:22.620] And that's the key. What time it is in space isn't important so you can look at the clock on the wall [05:22.620 --> 05:28.580] and know if you need to go to bed. It's important so you can know where you are and know where [05:28.580 --> 05:35.080] things are. Everything in space is constantly moving, orbiting one object or another. Telling [05:35.080 --> 05:41.060] where it's located is intrinsically linked to what time it is. This gets to our next question. [05:41.120 --> 05:46.300] How do you tell where something is in space? As I said before, everything in space is constantly [05:46.300 --> 05:51.960] moving and orbiting around something else. All this motion is primarily controlled by gravity. [05:51.960 --> 05:57.280] So to know where something is right now, we use where it was at some time in the past, [05:57.280 --> 06:02.420] and we predict where it is now based on the laws of gravitational motion. Now you might ask, [06:02.420 --> 06:07.160] how do I tell you where it is or even where it was? On earth, I could tell you where to go based [06:07.160 --> 06:13.920] on your address or some landmark, and these are useful frames of reference that we can use to [06:13.920 --> 06:19.600] fully communicate where something is. In space, there are an infinite number of reference frames [06:19.600 --> 06:24.920] that we can use, but we also have an added complexity. Since again, everything is moving [06:24.920 --> 06:30.540] all the time, to have a frame of reference, we need to incorporate time. There are several [06:30.540 --> 06:35.700] different ways of describing where things are, but we typically focus on two reference frames. [06:35.940 --> 06:41.000] One, what's easiest for us to use. For example, if I want to take a photo of the moon, I would [06:41.000 --> 06:46.080] want to know where the moon is in relation to where I'm going to be when I have my camera. [06:46.080 --> 06:52.820] Two, what's easiest to calculate. Orbital math is hard and many times impossible, so [06:52.820 --> 06:58.980] picking a reference frame that makes your calculation as easy as possible is often necessary. [06:58.980 --> 07:03.700] This reference point is usually whatever has the most significant gravitational effect [07:03.700 --> 07:09.500] and ignores all other motion. For satellites, we use earth. We want to know where they are relative [07:09.500 --> 07:14.120] to our location on the earth. This frame of reference is called earth-centered earth fix, [07:14.120 --> 07:21.820] or ECEF, as it is rotating with the earth and is fixed to it. It's the same as GPS coordinates, [07:21.820 --> 07:26.780] but it's much, much easier to calculate the position of the satellite when we ignore the [07:26.780 --> 07:31.360] rotation of the earth, which is a different frame of reference called earth-centered inertial, [07:31.360 --> 07:38.740] or ECI. So if I saw where a satellite was in relation to me in the ECEF frame at time t0, [07:38.740 --> 07:45.920] and I need to know where the satellite will be in relation to me in the ECEF frame at time t1, [07:45.920 --> 07:51.820] we actually need to calculate three different steps. One, translate the coordinates I observed [07:51.820 --> 08:02.200] at t0 in ECEF to ECI at t0. Two, translate the orbital motion of the satellite in ECI from t0 [08:02.200 --> 08:09.020] to t1, where our calculations are easier. And three, translate the coordinates I calculated at [08:09.020 --> 08:17.760] t1 back to ECEF from ECI. Steps one and three both require translating between these coordinate [08:17.760 --> 08:23.940] frames ECEF and ECI. So how do we do that translation? Here is where we now introduce [08:23.940 --> 08:29.540] the idea of an epoch. An epoch is a point in time that we use as a reference to translate between [08:29.540 --> 08:36.840] these types of frames. Specifically, we use the J2000 or Julian date 2000 epoch to translate [08:36.840 --> 08:46.080] between ECEI and ECEF as we set the ECI reference frame to be the same as the ECEF at that time. [08:46.080 --> 08:51.020] That way we can calculate the translation between them by calculating how much the earth has [08:51.020 --> 08:57.000] rotated since Julian date 2000. This is a simplification of the constant translation [08:57.000 --> 09:02.580] and calculation done throughout satellites, space technology, and astronomy. But that is [09:02.580 --> 09:07.860] why time and space are both extremely important and highly dependent on really what you're looking [09:07.860 --> 09:29.630] to do with them. Thanks to Jess Coffey for putting those videos together. That one was epic. Now this [09:29.630 --> 09:35.550] was going to be where I signed off for this update, but as we were live, PFS actually jumped up on the [09:35.550 --> 09:41.290] scoreboard yet again, solving challenge two. This means that we can now move on to exposing [09:41.290 --> 09:50.010] all teams to challenge three. Challenge three. Here's what we know. With the repair complete [09:50.010 --> 09:54.790] on the GNC, the satellite has stopped spinning, but we still can't communicate with the payload [09:54.790 --> 09:59.910] module or operate the imager. We have to ask ourselves, what else did they damage on this [09:59.910 --> 10:04.910] satellite? The challenge? Teams must restore communication with the payload module so we [10:04.910 --> 10:16.590] can get it working again. This has been our last hourly update for the day. I'm looking forward to [10:16.590 --> 10:22.890] seeing everyone back here at 4 p.m. Pacific, 7 p.m. Eastern for a daily recap of all that's happened so far.