cyanoacry

Thanks, updated! Please do CC me, as then I can vouch for where you came from :)

Esperto Medical | https://esperto.health | Los Angeles Area | Hybrid In-office | Senior FPGA/Firmware Engineer

We're building a medical device that allows us to measure BP continuously, in real time. (We're a Caltech spin-out and found some new physics that we want to get to market.)

Desires:

  - Experience with FPGAs / FPGA integration
  - Experience with Linux on an embedded system
  - Have dealt with real-time systems
  - Experienced in Rust / Python

.. but honestly, if you can tell me what a GPIO is and how it relates to the userspace I/O driver, we'll probably get along.

Here's the official job listing: https://esperto.health/careers/sr_firmware.html

If you think this is interesting, email me, I'm the CTO: [email protected]

Thank you for the write-up! It's a little depressing (but not entirely surprising) to hear that you couldn't get folks excited about safety -- I work in the aerospace field, and our day-to-day is all about risk management: how, why, when. It's frustrating that high-reliability systems aren't seen as exciting when really they're what makes the magic run.

Best of luck, and I'm looking forward to your next venture!

Nice article! I used to work in this space (was formerly in charge of GNSS hardware at my company), and it's neat to see Galileo being put through its paces.

I see now that the US gets to take GPS (and the fact that the Air Force pretty much runs it single-handedly) for granted. We are seeing _some_ problems (like the GPS III block upgrade and OCX, ahah), but the org chart seems to be considerably simpler than what Galileo's got to deal with.

There are several I'm on (canard-aviators and gns480-users), and they've been active for something close to a decade. (And there are still emails every day!)

Frustratingly, both of these groups have great content (manuals, tips, documentation) uploaded to Yahoo Groups. It's going to be a real loss.

Neat work! Question from someone who's familiar with RF atomic clocks but not optical -- how do you steer a laser in frequency? For RF, it all comes down to VCOs: if you want a different tune range or different frequency, you just pick a different VCO.

But for lasers, I thought the frequency was driven by the energy difference between electron states for a given species? How do you synthesize an arbitrary frequency for a laser without something crazy like a FEL?

Maybe! I've worked with some SiC FETs, but the issue I ran into with FETs in amplifiers is that they're typically made with switching in mind. If you run most FETs in linear mode, you get some pretty interesting failure modes[1].

But, Wolfspeed's SiCFETs /do/ have a published SOA (see fig 22[2]), so maybe I should revisit this...

[1] Figure II-3: "Visual Image of the IRF1405Z failure. This type of visual pattern is more attractive when observed on the surface of the moon, instead of on the surface of parts that are trying to land there." http://www.irf.com/technical-info/appnotes/an-1155.pdf

[2] https://www.wolfspeed.com/downloads/dl/file/id/145/product/1...

As someone who's worked on (and drafted!) several schematics in the aerospace industry, I have to say: there's no reason it has to be that way!

The places I've worked have pretty rigorous style guides, and I personally try my best to make schematics readable and understandable. I suppose this is the same thing as code quality guidelines: you can set expectations and examples, but folks don't necessarily have to follow them.

My cooler projects are all stashed away somewhere in a company drawer, but here's one that I did early on: https://bitbucket.org/cyanoacry/ee91/raw/5d934fdc18e556938dc...

> There is no evidence the heat dissipated will impact lifespan.

I have to nitpick at this a little bit as a professional EE who works in high-reliability electronics. Wearout rates absolutely do depend on temperature (and thus heat), and thus the chips used here will have a shorter lifetime than those with active cooling. Now, whether that lifetime will be long enough for the common user is another question (maybe it's 1 million hours of life that get reduced to 100,000 hours, so not normally noticable).

There are a couple of counter examples, particularly in New Space startups. At 26, I was a Mission Director (SpaceX's equivalent to a NASA Flight Director) for Dragon re-entry and landing.

As the old Apollo-generation engineers start to retire in the space industry, there _is_ fresh blood coming in, and even at larger companies, I've found young folks in top positions. It's just not widely advertised.

And for those that wonder what a more "modern" scratchbuilt plane is like, check out the Cozy Mk IV: https://en.wikipedia.org/wiki/Cozy_MK_IV. Made from fiberglass and foam cut to templates that came with a set of plans (with a handful of pre-fab parts).

A typical builder's log: http://www.cozy.simpex.com/

source: I, too, am building a plane in my garage. https://twitter.com/acozyplane

I highly recommend Nayuki's site: https://www.nayuki.io/

Lots of content (made mostly for themselves), but the writing style is pretty nice and there's a large variety of projects.

More relevant information (including the history of the project) from AOPA: https://www.aopa.org/news-and-media/all-news/2016/october/19...

Neat, it's always really cool to see folks get their feet wet in the DSP field! (Props to the author for trying to get through the dense Wikipedia pages.)

Minor correction for the author: this isn't amplitude-shift keying, and the way to tell is to look at how demodulation works. The detection code asks if a sample is negative or positive, but "how large is this sample?" is never asked. An ASK demodulator effectively thresholds the signal on amplitude and in the simplest case this boils down to "is there a signal or not?"

The implemented code has some flavor of phase-shift keying (the inversion of a sine wave flips the phase 180 degrees), but since there isn't guaranteed to be a steady carrier, it seems like it'd be hard to decode as a pure PSK. The all-sample offset (constant above or below zero) can also be treated in a way as a PSK process, with the carrier being DC (0Hz).

1. Rockets

2. Cost of launch locks out potential customers and limits R&D uses. Global launch cadence is slow; getting into orbit is a multi-year adventure.

3. Yes, we're working on reusable rockets.

However, this only goes so far. Personally, I think that more money needs to be put into non-rocket modes of space travel, so that there's some competition. The fundamental problem is that it takes so much energy (and, with rockets, so much mass fraction optimization) to get to space, so it's difficult to engineer things with physical margin.

If you could build a rocket like a car (just toss some more steel in the frame and call it a day, with no need for the obsessive mass savings), getting to space would be a bit easier. If you had a power source that doesn't shake and bake its surroundings, getting to space would be a lot easier.

John Muratore now works at SpaceX, but this is a pretty good interview with him during his NASA days.

There's a particularly enlightening paragraph about how he retooled Houston's mission control using the "pirate paradigm" and the "build a little, test a little, fix a little" philosophy. Even though this was back in the 80's, it seems like the kernel of more rapid/agile/test-based dev process that's well known today.

You can try adding a parabolic (or circular) reflector: http://www.freeantennas.com/projects/template/

As with the original link, the antenna is directional (and since it's a reflector, probably even more directional), so you lose out on flexibility. It'll be quite good if you don't plan on moving the other point, though.

When I was a little kid, I rented out Apollo 13 almost religiously. Kept watching it, admired the guys in mission control (and the astronauts too, of course).

A little later, in April, I sat in mission control and helped launch a spaceship to the ISS.

Along the way, I realized:

Engineering in the real world is maybe 30% calculations and typical "sciency" work, the other 70% is documentation and communicating to people. The day-to-day in the aerospace industry is way different than the way things are taught at school (from an EE perspective). It's impressive to me how much design happens in everyday back-and-forth conversations, versus the common image of "one guy, hard at work, cranking out equations at his desk".

Being smart isn't enough sometimes -- you need to have discipline as well, and even then, there is a considerable amount of luck in the mix. Getting the timing for a presentation, or a forcing a decision at the right time, can make a huge difference in the success of a program. You kind of have to check all three boxes to max out your success counter: smarts, determination, and luck.

I've built a fusor[1], and in its simplified form, it's just a large, negatively charged grid in a vacuum chamber with some hydrogen sitting around. Nothing to be afraid of!

You're absolutely right that these devices don't produce net energy. I built mine because I wanted to learn more about all the tech involved (high vacuum, high voltage, some nuclear physics). They're really good teaching projects for folks going into experimental physics, since there's a neat outcome without too much danger.

I assembled a coffee table book with some pretty pictures about it, PDF copy here: http://shia.wsyntax.com/stuff/fusion/fusor_book_web.pdf

[1] http://fusion.wsyntax.com/ , http://fusion.wsyntax.com/setup/

Two things:

1) Of course, anecdotes don't prove the general case.

2) There's some conflation here between knowledge of toolchains and knowledge of software. Arguably, they are not the same--they might be orthogonal domains of knowledge. Knuth (who knows a lot about CS) does not use email, and I would be surprised if he used git for his books.

DSCOVR actually is in a "halo orbit" around L1, which means it's not sitting in the plane of the Earth-Sun orbit. From the DSCOVR site[1]: "The spacecraft will be orbiting [L1] in a six-month orbit with a spacecraft-Earth-sun angle varying between 4 and 15 degrees."

As some other folks have mentioned, the Moon's orbit is tilted a total of 5.2 degrees[2] relative to the Earth-Sun plane, so DSCOVR will see quite a number of DSCOVR-Moon-Earth alignments, but never a Sun-DSCOVR-Moon-Earth alignment.

[1] http://www.nesdis.noaa.gov/DSCOVR/

[2] http://hyperphysics.phy-astr.gsu.edu/hbase/solar/solecl.html

It's mostly a function of how the transistors are made. If a transistor is on by default, they're called "depletion-mode" transistors--this means that the channel between the two sides of the transistors normally conducts, and via the control voltage, you deplete that channel of carriers. This is set up by the "doping" of the channel, which is one of the first steps in the fab process.

Transistors that are off by default are called "enhancement-mode". GaN transistors also come in enhancement-mode flavor, so I'm a little surprised by the article. You can buy them, even as a hobbyist, from EPC. [0]

[0] http://epc-co.com/epc/Products/eGaNFETs/EPC2023.aspx

[1] http://www.digikey.com/product-search/en?WT.z_cid=sp_917_011...