Live data from Hacker News

Nokia selected by NASA to build cellular network on the moon

reuters.com

221–224 of 224 posts

Re: Nokia selected by NASA to build cellular network on the moon

#221

Am I the only one wondering what the point of this is?

Imagine you need robots and machines to work remotely on the moon without a human inside a cabin controlling things, without a line of sight and in a low power, low footprint form factor Now you have 2 options: 1. Use off the shelf Quectel and Qualcomm devices and off the shelf existing embedded hardware. Then test and develop using common terrestrial networks and harden it for radiation. Pack and deploy. 2. Use some…

Thanks for the ideas, they seem reasonable.

In passing, I'd note that I don't think cell technology would work without LoS; also, there's no atmosphere to reflect off of.

I guess if they're just thinking of some comm system for the moon, it might as well be 4G. (I guess? I'm not qualified to answer this.)

Re: Nokia selected by NASA to build cellular network on the moon

#222

Earlier quoted context omitted.

Yes, from experience. It's not that we don't know what's important, it's that it's all important and I have to find time to actually write code every now and then too. The real problem is just that we're all very busy and it's not really possible for everyone in the agency to have even a cursory awareness of everything that's going on. Even now with everything being virtual, I get invites to brown-bag type events pro…

Interesting. Do you think there's a chance for more balance or does it seem just a natural result of the demands of the job?

There are a couple of issues at play. One is that there's so much interesting stuff going on that I (and most of my colleagues) tend to volunteer ourselves for lots of projects, which results in us going "deep" on a couple of projects at the expense of not having enough time to go "wide" by attending lots of talks that aren't directly related to our own work. That part's on me and I really could make more time in my schedule if I just said "no" more often (but again, I don't say "yes" because I'm pressured to do so, I say "yes" because the work is really fun and interesting!).

The other question is why we have so many meetings per project. That one's tougher to tackle and I don't really have an answer. The one thing that I have identified is that we're very in to making sure that everyone has their say on things before taking action. That's a good thing overall, but it also leads to tremendous meeting bloat. A meeting that would only take 5 minutes if everyone restricted themselves to discussing critical issues before making a decision regularly takes a full hour in which we examine every pitfall, no matter how minor.

Re: Nokia selected by NASA to build cellular network on the moon

#223

Earlier quoted context omitted.

Interesting. Do you think there's a chance for more balance or does it seem just a natural result of the demands of the job?

There are a couple of issues at play. One is that there's so much interesting stuff going on that I (and most of my colleagues) tend to volunteer ourselves for lots of projects, which results in us going "deep" on a couple of projects at the expense of not having enough time to go "wide" by attending lots of talks that aren't directly related to our own work. That part's on me and I really could make more time in my…

Interesting, it sounds like in this case it's mostly a good problem to have - even ensuring all voices are heard is good, from a sound engineering perspective, which I'd imagine is important for NASA's missions!

I wonder if there would be a benefit in your case if folks had to follow a similar process to the one Amazon requires for its meetings (this may be something NASA already does, but I will admit I'm projecting a bit here and am wishing my organization required some writing before calling for a meeting):

> We don’t do PowerPoint (or any other slide-oriented) presentations at Amazon. Instead, we write narratively structured six-page memos. We silently read one at the beginning of each meeting in a kind of “study hall.” Not surprisingly, the quality of these memos varies widely. Some have the clarity of angels singing. They are brilliant and thoughtful and set up the meeting for high-quality discussion. Sometimes they come in at the other end of the spectrum.

> ...

> Here’s what we’ve figured out. Often, when a memo isn’t great, it’s not the writer’s inability to recognize the high standard, but instead a wrong expectation on scope: they mistakenly believe a high-standards, six-page memo can be written in one or two days or even a few hours, when really it might take a week or more! They’re trying to perfect a handstand in just two weeks, and we’re not coaching them right. The great memos are written and re-written, shared with colleagues who are asked to improve the work, set aside for a couple of days, and then edited again with a fresh mind. They simply can’t be done in a day or two. The key point here is that you can improve results through the simple act of teaching scope – that a great memo probably should take a week or more.

https://www.sec.gov/Archives/edgar/data/1018724/000119312518...

Post reply on HN