This week in the Lobby, we're talking about rapid prototyping with a SpaceX engineer with experience optimizing Falcon rocket circuitry and putting rovers on Mars.

 

A Big Thank You to This Episode's Sponsors

 

 

 

Meet Sandip Dasgupta

This week, host Dave Finch speaks with Sandip Dasgupta, a EE at SpaceX who spent over 15 years with NASA's Jet Propulsion Laboratory.

 

Sandip Dasgupta

Senior Electrical Engineer at SpaceX

 

Hear discussion about the new generation of smart rockets, the complexities of FPGA prototyping, and a story of how a single line of Verilog haunts him to this day.

You won't want to miss this lively conversation that explores the technical side of one of the most exciting times in aerospace history with a focus on the flaws and advantages of rapid prototyping.

 

"SpaceX and Rapid Prototyping" Annotated Transcript

Sandip Dasgupta:

If it's off course... it could have been devastating and just... blown up.

 

Dave Finch:

Oh, my gosh. How do you fix that?

 

Sandip Dasgupta:

It's kind of a complicated answer.

 

Dave Finch: 

From EETech Media, this is Moore's Lobby, where engineers gather to talk all about circuits. I'm Dave Finch.

Joining me in the Lobby today is Sandip Dasgupta, Senior Electrical Engineer at SpaceX, to talk all about rapid prototyping.

It could be argued that no other company is prototyping ultra-high-performance electronics faster or more effectively than SpaceX. In their mission to land humans on Mars, the company has already produced a viable, reusable rocket and has claimed their place as the first US company to send humans into space. Preceding each of these impressive milestones are the prototypes. Countless prototypes. Very expensive prototypes.

Sandip Dasgupta has been designing embedded controls, FPGAs, and even ASICs since his days at NASA’s Jet Propulsion Laboratory. Now, he works for SpaceX, where he says the culture of rapid prototyping is like rocket fuel for their success.

Sandip, welcome to Moore's Lobby and congratulations on an exciting and historic launch—the first commercial spacecraft carrying humans into space. I mean, what an accomplishment and what a moment to witness for all of us.

 

Sandip Dasgupta:

Thank you. Yeah, it was a great moment for everybody. I mean, before working for SpaceX, I'd been keeping tabs on their progress and what they're doing, and how they're disrupting the industry. It's been a great pleasure to work for them.

 

Dave Finch:

I can only imagine. I mean, it's got to be so fun working for a company that takes on these types of challenges. I read an article about the last shuttle mission in 2011 where the crew hung an American flag inside the ISS, and they said, "All right, race is on. Who's going to be the first to come back up here in a commercial capsule and claim this flag?"

Obviously, this was an informal and emblematic gesture, right? But still, it occurs to me that I wouldn't want to be playing Capture the Flag against Elon Musk.

 

Sandip Dasgupta:

Right. Exactly, exactly. The thing is the goal of SpaceX is to land humans on Mars. What's been amazing about SpaceX is that they have been able to monetize getting there. They didn't just try to do that first. The first thing they did was to design a Falcon rocket, and then make it recoverable. When you do that, you put yourself in a great position to achieve your ultimate goal.

Right now, SpaceX's bread and butter is their Falcon 9 rocket because it makes launches cheaper for everybody—even if that's not your mission in life. If you're just a foreign government or a private company or the US government or NASA, SpaceX provides great value to you because now launches are cheaper. That has helped increase SpaceX's income to do other things and further its mission.

 

Dave Finch:

You're proving an exciting model, right? Like, not only are you leveraging recoverable rockets to minimize Capex with every launch, but you're also saving the additional, what, tens of millions of dollars? Or whatever it costs to essentially bum a ride off of some other country's space program every time you want to leave the planet.

 

Sandip Dasgupta:

That's exactly right. That's exactly right. There's two things at play there. Actually, three things. One is what you mentioned, which is expense in outright cost.

Secondly, it's a question of national pride. We, for a long time, did not have the ability to send human beings into orbit around the Earth. That's just a sad thing.

The third thing is control. If you are in control of the rockets, you have control over the technologies and where you go next. You can't control what Russia is going to do to their next rockets if you're just paying them to be a passenger on board.

 

A Word on Elon Musk...

Dave Finch:

You work for a pretty interesting guy. Are you consciously aware, in the day-to-day work at SpaceX, that you're working for somebody who has become this living legend? Or are there enough management layers that buffer what we see in the media versus your day-to-day?

 

Sandip Dasgupta:

That's an interesting question. There is nothing internal to SpaceX that expresses his importance in the industry any more than what people see in the press.

But you're right, from one standpoint, that you are reminded that you work for him because he sends us all emails every day.

He will say things outright like X, Y, and Z are the most important thing we should be working on, so get your butt in gear.

 

Dave Finch:

Wow. That's pretty amazing that you've got somebody at the executive level who's spelling it out that clearly for everybody in the company. That's actually pretty rare.

 

Sandip Dasgupta:

Yeah, it's actually very rare because SpaceX's employee count is above 7,000. My prior job was at the Jet Propulsion Laboratory in Pasadena, which is a federally-funded research and development corporation, but really, it should be considered functionally as one of the NASA houses.

At JPL, I never had any clue what JPL's managers were doing at the highest level. I had no idea. Not making a judgment. I'm just expressing what the reality is.

 

The Advent of the Smart Rocket

Dave Finch:

As a design engineer, what types of systems are you working on now or have you worked on in the past?

 

Sandip Dasgupta:

It's been quite a wide variety and I don't want to age myself, but I've had the opportunity to work on several things that are all different. I have worked on a rover that is now on the surface of Mars. I've worked on a moon orbiter. I've worked on an Earth orbiter and one little, tiny, cute experimental circuit board that's now actually on the ISS.

 

Dave Finch:

Oh, man.

 

Sandip Dasgupta:

Then for SpaceX, the rocket electronics that actually are components of the Falcon 9 rocket that launched Dragon.

 

Dave Finch:

Are (bleep) you kidding? You developed engine controls for the Falcon 9? Holy ... Pardon my language, but that is awesome.

 

Sandip Dasgupta:

That's okay. It's your show.

 

Dave Finch:

Yeah. I guess I should have read the show notes before I called you, but I had no idea. You were working on the engine circuitry for Falcon 9. God, that's amazing.

 

Sandip Dasgupta:

For the engine. And just to be totally honest here, that obviously existed before I started. I was involved in upgrading it and making it better. I was involved in that. I did not actually work on the actual Dragon capsule that housed the astronauts. I was involved in the engine that launched them.

 

Dave Finch:

Well, I mean, personally, I'm almost more excited about the rocket and its engines. It's like this explosive ignition blast off, but it's all controlled, and there's so much science behind it.

Then watching it maneuver to this gentle landing on a tiny platform somewhere that's literally floating around on waves and it can land, does no damage to itself. That's incredible.

I once cost about $1,200 of damage trying to back my Volvo into the garage. I was going maybe 10 miles an hour. I could see where I was going. Plowed into the workbench, took out my daughter's bike, the whole thing. What you're doing with these very powerful, very expensive rockets maneuvering them is unbelievable.

 

Sandip Dasgupta:

The level of precision necessary is kind of stunning, even for those of us who work in the industry.

It's kind of like... Let's say you were in Los Angeles and you could, through a network of mirrors and telescopes, look at somebody in Paris and throw something with your hand and hit them in the head. The precision necessary is unbelievable.

Just at a higher level, this is actually why a lot of the electronics are being put on rockets, in the same way that our phones used to just make phone calls and now they're smartphones, or our TVs just used to receive broadcasts but they're now smart TVs. Rockets are becoming smart rockets, which means that they have their own notion of where they are, their navigation, their guidance. They actually report data back to Earth. They're communicating nowadays. It's not just a cylinder on rocket fuel anymore. They're becoming more intelligent themselves.

 

Dave Finch:

Right. It's not just math and physics anymore, it's active autonomous guidance, we'll say.

 

Sandip Dasgupta:

Exactly. I do want to make a slight correction, though. I mean, it's all math and physics, it's all math and physics. But it's not math and physics that was calculated a week ago and cross your fingers and pray anymore. They're in real-time communicating.

It's actually similar to the way an airplane works. Like, whenever we take a flight on a plane, you're actually off course most of the time. What happens is that there's a beacon that corrects you just slightly, just barely tweaks your flight path. Then, 10 minutes later, you're off course again and you slightly tweak it. You play this game where you're constantly a little bit off course and you just keep changing it and fixing it so that you're on the right path, and eventually, you get to the destination correctly.

That's how these rockets are operating. They're constantly measuring, "Hey, where are we? Where am I? Okay, we're going to miss the platform by five feet, so move over a little." Now, you're like, "Okay, you overcorrected by two feet. Move back."

There's this constant iterative communication between the ground and the rockets to make sure they stay on course.

 

"The Hardware Is Always New"—Innovation in Rocket Circuitry

Dave Finch:

These are leading-edge circuit designs clearly, and that's exciting. But do you have to start from scratch every time or is there some amount of design reused?

 

Sandip Dasgupta:

The answer changes depending on whether you're talking about JPL or SpaceX.

 

Dave Finch:

Ah, okay. Let's go with SpaceX.

 

Sandip Dasgupta:

Okay. With SpaceX, hardware is consistently new. It's almost always new. That being said, obviously, the Falcon 9 rocket has been around long enough at least that we understand a lot of this stuff about the hardware.

But, for me, there has absolutely been stress about learning new hardware and learning new stuff. It's stuff I've never done before. That doesn't mean you're not responsible for it, and that's just the culture of the place. You get thrown into the fire and it makes it challenging and a little bit nerve-wracking—but fun, too, and stimulating.

One thing that defines this is cost and design generations. What I mean by that is it obviously saves you a lot of money to reuse hardware that's been tested so that, A) you don't have to go out and inspect the components, but also B) you don't necessarily have to re-prototype as intensely as you did the first time, as if you're starting from scratch. You do get that benefit, but that's not really where SpaceX is at. Most of the stuff at SpaceX is very new, it's very state of the art.

That being said, there will be a time where what we're doing now is boring.

I know that sounds surprising, but it's like, "What do you mean you didn't recover the rocket it launched?" Our kids will be very used to that. And the engineers of that era will probably be reusing a lot of the stuff that we're doing now, and they should.

 

Dave Finch:

I think one of the mistakes a lot of people make about engineers is they assume that every engineer is really an expert on every aspect of what's happening on the circuit. Whereas the reality is there are people who have been designing switched-mode power supplies for 35 years and there's no way I'm going to go think as an audio engineer, "I'll bet I could design my own switcher."

 

Sandip Dasgupta:

No. You're absolutely right. There's things that people sitting in the cubes right next to me do that I have no clue about, and it's humbling but it's also stimulating. It's like, "Hey, can we go grab lunch and you just tell me for 20 minutes what it is that you do?"

 

Safety and Speed in Rapid Prototyping Methodologies

Dave Finch:

That's a great thing about working with such a diverse organization of engineers.

Speaking of working with these engineers, you're at SpaceX. Your boss is on a quest to land humans on Mars. His first stop was the International Space Station, the ISS. To get that far, he wants to invent recoverable rockets.

I don't know him, but he does not strike me as a wait and see kind of guy, so I imagine the pressure to produce flight-ready prototypes is fairly intense.

Now, there's good rapid prototyping. And then there's, in my experience, pretty bad rapid prototyping. I'm thinking of, I should not be laughing about this, but I'm thinking of that flat earth guy, Mad Mike Hughes-

 

Sandip Dasgupta:

Yes.

 

Dave Finch:

...who we saw the story a few months ago, he strapped himself to a homemade steam rocket.

This guy gets knocked off course as he's blasting off from... in the video, it looked like he was blasting off from a truck bed or something. But anyway, knocks him off course. He flies out of control and plows into the ground without a parachute.

Now, some might say it was tragic. Others might say, "Well, duh." But, either way, safe to say that Mad Mike Hughes could have been a little more careful in his prototyping methodology.

 

Sandip Dasgupta:

Probably.

 

Dave Finch:

Tell me about the culture of rapid prototyping at SpaceX where you've obviously got legitimate engineers, you've got legitimate funding—that sort of thing.

 

Sandip Dasgupta:

Sure. There's a changing story depending on where you work and what projects you're looking at. SpaceX cares more about speed and rapid prototyping than a checklist of careful lessons learned in the past. That's not the way they operate. They're like, "Get it done yesterday." Anything that helps you prototype faster is going to be supported by management.

At JPL, it's the exact opposite. It's safety matters more than anything else. They're in favor of doing things on time and quickly, but not at the expense of checking off those boxes.

To dig a little deeper, one of the things that you can do is, as long as it doesn't hold you back, you can reuse designs that you've done before. Let's say you're laying out a circuit board. If you have something that you know helps with speed or reducing interference, then you just copy and paste that same layout. There's no need to redesign it unless you really, really have to.

So lot of it is recycling in terms of rapid prototyping.

 

Dave Finch:

Tell me about your approach for prototyping the improvements to the Falcon 9 rocket engine circuitry. For example, were you designing with a microcontroller or FPGA? Did you start with the simulation and virtualization and then build the hardware after that phase, or did you start by focusing on the hardware first? How did that look?

 

Sandip Dasgupta:

In terms of hardware and software, the answer there is all of the above—or both.

But, in terms of the general process, one of the things is that you do know one of the things you're going to have to be able to do, some of the things that you're going to have to be able to do, And then there areother things that we don't know what we're facing.

In other words, there are no-knowns and unknown unknowns and every combination thereof. You first have to take those into consideration.

For example, we know that we have to be able to communicate at a certain rate. Like, I need to get information about a rocket's position and its velocity in X amount of time. You can't take a minute to tell me where you are. I need to know in two seconds maximum.

So that gives you one prototyping guideline right there. How quickly are we getting data back?

There are certain things like that you know ahead of time based on past results or lessons learned from prior missions—but there are going to be things that you have no idea. As you are aware, the first couple of attempts at this, the rockets blew up, they missed, and they fell over. Those were unknown unknowns and you go, "Well, why did that happen?" Then when you try to figure it out and troubleshoot, then that establishes guidelines for your next prototyping effort.

Or if you haven't gone full-on... I mean, those missions were tests begin with. It's not like we had people on board, thank goodness. But they were tests themselves. That was a prototype test that failed because we didn't have all the right stuff inside, either the electronics or we weren't testing the right thing.

So there is an iterative process here.

 

Where to Get Chips that Can Survive Jupiter (AKA Does NASA Do IC Design?)

Dave Finch:

Meanwhile, you're also having to work with the components that are available. Most chip manufacturers, passive component OEMs, board houses—they're not looking at their product roadmaps and thinking, "Well, sure, our stuff works here, but can it function on Jupiter? Let's go check it out." Or even, "Can it work on Jupiter for, say, 15 years?"

So, when it comes to things like component selection during the prototyping phase, surely you must have approved vendors, chipmakers that will commit to keeping critical components from going end of life. I imagine that's the case, or are you constantly battling with the normal production cycles and new product roadmaps and that sort of thing?

 

Sandip Dasgupta:

That's a great question. It's actually an iterative process. For example, we have libraries of components that are online and that are available to every designer, and these are in-house. What SpaceX will use and considers okay is not going to be available to the general public. But internally, we all have components. It's like, "Hey, I need a memory device that's ..." whatever it is—four megabytes or four gigabytes of data, whatever you need. These are the chips that are okay for that within up to this radiation environment. All that data is stored and put down.

The trouble you get into or where it can make you nervous is if you're dealing with something completely new. If we're sending something to Jupiter, let's say, Jupiter is one of the most heinous radiation environments in the entire solar system.

There is a large battery of parts that can withstand orbiting Jupiter. What if we say we need that? We absolutely have to have something that can orbit Jupiter for X number of years and collect data and not be fried to bits.

Our design requires, let's say, 20 components just as an example. Of those 20 components, we know of 7 that'll work, the other 13 we have no idea.

So then there's pressure on the industry, "Hey, you need to make one of these for us, or do we make it ourselves?" Sometimes companies will come back and they say, "If you pay us X million dollars, we'll do it."

Sometimes, and this is where it gets really hairy, is you don't know. Like for a certain component, the company that manufactures it says, "We think this will work in Jupiter, but we're not sure." Then you go, "Well, do I use it or not?" Then you go back up and look at your budget and say, "Do I have to pay to have this thing tested?"

Just as a simple example, a radiation test for an integrated circuit component can cost upwards of a million to two million bucks.

 

Dave Finch:

Really?

 

Sandip Dasgupta:

Yeah. Just to put it through radiation testing and saying, "It withstood this amount of radiation for this amount of time and it fried at this point." You provide that data. If it's good enough for your mission, then that was $2 million well spent, depending on your budget.

But it might fail, and you might say, "Well, this part doesn't work." Great. We just blew two million bucks for no reason.

Unless you consider eliminating a part for consideration of success, which is possible.

 

Dave Finch:

But then you think like, "Well, would it have been cheaper just to start with our own IC designer and to start designing for these known factors going into it?" But maybe that's not realistic.

 

Sandip Dasgupta:

Well, I'm not going to say it's not realistic, but it's higher than my paygrade. It's a political discussion that upper management discusses.

If you actually look at the history of NASA, there has been a push-pull between NASA being a management organization or actually being an engineering house where things were done within NASA. And that back and forth changes depending on who's the president. Who are your congressman, who's the director of NASA, who's the director of JPL? It really becomes a political issue.

A lot of chips that are purchased for the aerospace industry are absolutely beyond the scope of the consumer electronics market, right? Like I've seen integrated circuits in FPGAs upwards of $25, $30,000 apiece.

Those are clearly made for the aerospace industry because the manufacturers that make them, they may also make a device that cost $50 that goes in your cell phone, but they also want market share within aerospace.

They'll make this device, they'll spend the money themselves to have the expertise to test these things against various radiation and temperature environments and then they put that on their advertisement. "This thing can withstand orbiting marks, and here you go. Pay us $50,000 for this part."

 

Prototyping for FPGAs

Dave Finch:

If you'll indulge me, can you tell me a little bit about prototyping for FPGAs? The reason I ask is I've never had to do it, and the reason I never had to do it was I was too scared of FPGAs.

I would always go to the safe microcontroller world or microprocessor world where it was all architected for me and it was like, "Here's what you have to work with," where it seems like an FPGA is almost like such a blank canvas that I didn't even...

What is the process like for prototyping with an FPGA on your board?

 

Sandip Dasgupta:

That's a great question. Before I answer it, I'm chuckling over here because as an FPGA guy, my comfort zone is much more with a blank slate than being given a microprocessor and having to figure out how to write to it and compile software for it.

That scares me.

 

Dave Finch:

You don't have an all-new culture to learn, you're saying?

 

Sandip Dasgupta:

Exactly, exactly.

But FPGAs are not all the same thing. They're not homogenous. They don't have the same technology. What that means is some FPGAs, once you program it, that's what you get. If there's a mistake or a bug in there, you're screwed. You need to get a new FPGA, and that's the old one off your circuit board.

There are some FPGAs where the technology is RAM-based, which means that you can reprogram it. Most of them have a limit on how much you can reprogram them. Some of them are like, you can reprogram this device 1,000 times before you start seeing problems. That gives you the opportunity to go ahead and put in a design that won't work, maybe. It could have bugs in it, that's fine. We're just getting up and running here. Just want to try a few things.

Then after 10, 20, 30 reprograms, you're maturing your design. It's gotten mature to the point where you're starting to trust it. A lot of times what's done, and I have seen this in one project that comes to mind that's specific—which was the Mars rover, Curiosity—where a lot of the electronics were prototyped using a RAM-based cheaper FPGA just to show that the functionality worked.

Then when we went from a prototype to an engineering model, we would use a less expensive, less tested version of the final FPGA, and then test there. Then finally, when we are about to launch something and deal with flight electronics hardware, we would put in the super-duper one time programmable, expensive FPGA down the board and send it up in space.

It really changes the game based on what the application is, where this FPGA is going to sit, and what its function is in life.

 

The Value of a Functional Prototype

Dave Finch:

Have you found that it's better to start with a functional prototype before moving on to performance testing? Or, do you try to execute both of them simultaneously?

 

Sandip Dasgupta:

The relationship between functional testing and performance testing—that's kind of an ongoing, maturing field.

For example, the first thing you care about is if I give one set of inputs, it gives me the right set of outputs. Okay, so, cool. That's functional, that works. But what if when you heat it up to 85 degrees Celsius? It works 90% of the time, but I'm getting wrong outputs 10% of the time.

Then it becomes a question of, well, we need to change our testing, or we need to get a new device, or we need to change the design internally so that it doesn't matter if it gets hot.

There are a lot of games you can play and a lot of methods to approaching prototype based on what I will call mission parameters.

How long does this mission have to last? If we have a device that fries after one year because you're subjecting it to a certain environment—that might be okay if the lifetime of the mission is 90 days. But if it's something on the other extreme where it has to be solid under really extreme conditions for five years, then that completely changes the game with how you prototype and how you test.

 

Mistakes and Prototyping ("That one line of Verilog code...")

Dave Finch:

In a rapid prototyping environment, where do you see engineers making mistakes? Young, old, it doesn't matter. Are we generally prone to making mistakes when we're trying to move quickly and iteratively?

 

Sandip Dasgupta:

I find that what most people are really careful about, and what they're really adamant about, and what they really specifically like to look at hard is the stuff that has bitten them in the past.

I got bitten by one line of Verilog code. That has informed my designs going forward after that since then.

Once you suffer a trauma in the lab, you will never make that mistake again.

A lot of what you see younger engineers doing is doing stuff that seems to make sense theoretically or on paper, but they've just never gotten bitten by something they didn't look at before. That could be anything. That could be not caring about crossing clock domains, for example. Let's talk about digital design in the FPGA world. Sometimes one part of your design might be running at 50 megahertz and another part running at 100 megahertz.

Sure, these young engineers might know about it, might understand the vagaries of clock domain crossing, but they haven't actually been beaten by that, by a bug that resulted from not doing it right.

If you want to get real specific, FPGAs tend to be divided up into different power banks. Each portion, each geographical portion of the FPGA like the northwest upper left quadrant of it has a completely different and isolated power rail from the lower right quadrant, the southeast quadrant.

What you never want to do, for example, is assign 32 bits that are talking to a memory device on the same power bank because then you get into this realm where all 32 bits are all of a sudden going from a zero to a one and you're really stressing out that one unique power bank. What you learn is that when I assign pins to talk to a memory device, I need to spread them out amongst different power banks.

 

Dave Finch:

Oh, yeah.

 

Sandip Dasgupta:

That's a notion called simultaneously switching outputs. I never would have imagined anything like that coming out of school or coming out of grad school. I had to learn it and suffer it.

 

Dave Finch:

Yeah. That's not going to be in the datasheet.

 

Sandip Dasgupta:

No, absolutely not, and it's certainly not going to ever be in a college textbook.

 

Dave Finch:

Have you ever dropped the ball on the design where you thought, "Oh, man, this is bad," and you feel that pit in your stomach?

 

Sandip Dasgupta:

Yes, yes. I can relate one of the more embarrassing examples in my personal life, in my professional life.

 

Dave Finch:

We've all had them, by the way.

 

Sandip Dasgupta:

Yeah. I can talk about it now because it's been over 10 years and the rover is successfully walking around the surface of Mars.

But there was one time, one line of code in the FPGA design, one line of Verilog code that made the design run off into the weeds after running for one minute. We were like sitting there for a minute. Oh, everything looks great, everything looks cool, and all of a sudden, we're getting data back that makes zero sense.

 

Dave Finch:

Oh, no.

 

Sandip Dasgupta:

Not to bore you too much, but it was a question of a certain address of certain program counted that went off into an invalid area of memory.

That was based on one line of Verilog code that had an error in it. We probably blew, I would say, two weeks of tests on it trying to figure this out.

 

Dave Finch:

It always is. It's that one line of code, yeah.

 

Sandip Dasgupta:

It was one line of code. I was like, "Oh, crap, we didn't do this right."

 

Dave Finch:

When it gets to the point where you're working on it for a couple weeks, and even maybe the chip manufacturer is like, "Listen, dude, this thing should be working." That's a terrible feeling.

 

Sandip Dasgupta:

Yeah, exactly. I mean, those kind of things where you're not sure if it's something wrong with the device like, "Hey, do I contact the manufacturer of this FPGA because I don't understand what's going on?" Or, do I just batten down even harder and say, "No, this problem's got to be mine. There's something I'm doing wrong here and I just can't figure it out right now"? That's always a tough call.

 

Dave Finch:

It strikes me as interesting. I've never done anything as high stakes as what you're working on. Like, the stuff I was doing, a lot of it was audio circuitry. 

 

Sandip Dasgupta:

A nice, subtle way to imply that, what you do has more sex appeal than what I do.

 

Dave Finch:

Hardly. Nobody ever sat and watched a televised event where there was a Bose sound system just sitting there.

 

Sandip Dasgupta:

Yeah. Well, I was listening to my Bose headphones last night, so it's as important to my life.

 

Dave Finch:

A frustrating thing I do remember from any prototype that I was personally accountable for in an embedded system was rationalizing is this truly a firmware software issue or is there something going on on the PCB around this that I haven't accounted for yet—a pull-up resistor of the wrong value that's letting noise in or whatever the case may be?

When you're prototyping, are you doing all of it, like full-stack?

 

Sandip Dasgupta:

I personally have done less prototyping that is software-intensive. However, that being said, sometimes there have been cases where software found a hardware bug because it'll put it into a mode. And exactly like you said, maybe a resistor wasn't populated, or maybe an FPGA input was assigned to the wrong pin, and that thing isn't connected.

It'll find out certain things that you didn't test on your own because you needed the whole system up and running.

 

The Engineering Spirit: Solving Problems, Architecting Solutions

Dave Finch:

Man, what you've already achieved in your career, and you seem pretty young, but what you've already accomplished reads like a greatest hits record. What are you excited about doing next? I don't mean with SpaceX or wherever, but just as an engineer, where do you see yourself going from here?

 

Sandip Dasgupta:

That's a great question. First off, thank you for your comments. I'm humbled by people like you who recognize stocks, and I'm also humbled by the opportunities that have been given. It's been an absolutely lucky opportunistic journey that I've had. There are people just as amazing and even more amazing, and I see kids who are younger than me that are way brighter than I am. Sometimes it's a question of where you were at the right time to get a job offer. I've mainly been lucky. I'll put that out there first.

To answer your question, what I'd really would like to do in my life is to architect designs. That's something that I've never really done. I've been more of a, "Here's your problem, go solve it, and test it and make sure it works and bring it back to me." That's been my job.

Whereas one day, I would like to be... Well, we have these needs, either societally or even just within the realm of engineering. How do we go about this and stand in front of a blackboard and architect with flow charts and diagrams in just a much higher scale of, this is how I would solve this problem, and hire somebody like myself in the future.

I want to think about the problems that I've solved at a much larger, more abstract level. That's what I'm trying to do.

 

Dave Finch:

It seems like you're at the right company to do something like that, too, because SpaceX, obviously, it's still a young company, but it's also a very bright, very optimistic company and solving problems that other people haven't solved before.

 

Sandip Dasgupta:

Yeah, exactly right. I mean, I marvel at the architects of our designs because I don't know what they do from day-to-day. I get the opportunity to meet them every once in a while in a meeting or a webinar, but I don't really see how they work on a day-to-day basis, and I want more of that, once this era is done.

 

Dave Finch:

Gotcha. There's knowing when it's time, knowing when the era has run its length and its course, and you say, "All right, now it's time for me to start being in the room when they're making these architectural decisions or asking those architectural questions."

But I think it's also a matter of inserting yourself, and I don't think it's ever too early to insert oneself into where you want to be. Just from one person to another, I would always encourage, reach out to those people who are sitting in the rooms that you want to be sitting in and introducing yourself and saying, "We all have our jobs to do, right? But if the timing ever works out, I would love to sit in on one of these meetings and just be a fly on the wall."

 

Sandip Dasgupta:

That's exactly right, and I appreciate that. It's something that I've slowly come to realize over the years that nobody's going to push you up. You have to insert yourself, like you said. 

 

Dave Finch:

You know what, it's funny, people respond positively to that usually because so few people do it.

I remember I reached out to a chief strategy officer once when I was working for a huge corporation. I had been there like a week. Their onboarding process frankly sucked, and so we were all like onboarding ourselves.

And I said, "You know what, instead of reaching out to the people I can see all the time in my cubicle, I'll see them eventually." I started at the top at the C-suite, and she was awesome. She was like, "Well, welcome to the company. Sure. Put time on my calendar." And I sat with her for 30 minutes. It's surprising what people will let you do if you just ask.

 

Sandip Dasgupta:

That's amazing. That's great.

You mentioned young engineers. I would just make sure that people understand that. The very first thing you have to do is get other people involved, and you have to get people involved who are at your level, at the level above you, at the level below you, and have a team effort where everybody throws up something that could go wrong.

You need to reach into the part of your brain that lies awake at night wondering what could go wrong today. That's the very first step to any of this is brainstorming and trying to understand how you can break what you have designed.

This is your baby, and unfortunately, you want to make it fail in your head.

I think you get used to it over time, but in the very beginning, it's weird to think like that.

I would just say that it's really important to have all your colleagues who are available involved and just test and challenge and question yourself.

Over the years, I've developed a higher comfort level in doing that.

 

Dave Finch:

I want to give a big thank you to Sandip Dasgupta who joined us from his home in California via Zoom to talk about prototyping today. 

And we want to hear from you, as well. What are some best practices that you've developed in your own prototyping? What are your go-to tools? What equipment can't you live without? 

Drop your thoughts into the comments section on this episode's page on allaboutcircuits.com. 

And if you enjoy listening to Moore's Lobby, please take a moment to leave us a review on Apple, Google, Spotify, or wherever you listen to this podcast. It's a small gesture that goes a long way to helping us build a thriving and meaningful community of listeners and contributors.

Thanks for listening.