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

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: raymond.jimenez@esperto.health

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...

Having programmed in both, I prefer VHDL--the two take different paths, analogous to functional vs imperative programming.

The type checking that makes VHDL so annoying is also the same type checking that's saved me. Coming from Haskell, VHDL was a much easier language to learn than Verilog.

The cost (in addition to those that other replies have pointed out) is also one of support. While a <10yr old device may support IPv6, it is often that they don't always perform exactly as designed. IPv4 & IPv6 co-existence is a little bit of a crapshoot at the device level.

This translates into super-large ramifications, especially for companies like Comcast--I can only imagine that they don't want to add yet another possible moving part, especially when there's almost zero benefit to the average customer.

I host a private MoinMoin wiki on my own server, as a place to collect links as well as thoughts. It's a fairly easy setup, and allows you to make sure that you can write down even private thoughts (well, as much as you trust your own security setup that is).

There were several, but the two that stand out[1]:

1) The payload bay grew in size from 12 ft wide to 15 ft wide, in order to accommodate future unspecified military needs.

2) There were new cross-range requirements specified for reentry.[2] Basically, the military wanted to be able to launch satellites into polar orbits (useful for surveillance) and retain the capability to land after one orbit of the Earth. However, this meant that the Shuttle also needed to be able to -reach- the landing sites, which are normally not in the direct orbit path, but are divert 1000 miles away laterally (the cross part of cross-range).

[1] http://en.wikipedia.org/wiki/Space_Shuttle_design_process#Ai...

[2] http://yarchive.net/space/shuttle/shuttle_crossrange.html

Six sigma is actually alive and well, and in my experience refers to a well-defined set of methodologies for production efficiency. There are certification bodies that run programs dedicated to it[2]. It might not be necessarily intelligent (akin to the ISO 9000 quality standards), but it is a real deal.

[1] http://en.wikipedia.org/wiki/Six_Sigma

[2] http://en.wikipedia.org/wiki/List_of_Six_Sigma_certification...

Self-fluxing enameled wire is great for more than just a simple keyboard project, too---it scales to microcontroller-scale projects, if you have enough patience: http://elm-chan.org/docs/wire/wiring_e.html

It's a good solution if you have some reason (money or time restrictions) that you can't order a PCB. The biggest downside of free-wiring like this though is that you don't have a whole lot of structural rigidity, but the steel that OP uses more than makes up for this.

This approach works well in only one situation: when your code isn't doing anything substantial in terms of data processing.

For me, comments are best used at explaining _why this is happening_, not what is happening.

By far one of the best examples of code commenting I've seen is the explanation of the L2ARC (the level 2 adaptive cache) in ZFS: http://fxr.watson.org/fxr/source/cddl/contrib/opensolaris/ut... . Most of the ZFS codebase is extremely well documented due to its comments, and it helps a lot having the documentation _in the code_, to provide context (something that commit logs, by default, don't).

I'm extremely skeptical of this viewpoint, if only due to the fact that the energies involved in car crashes are an order of magnitude larger than those involved in bike accidents.

Intuition says that a car might be traveling (on average) double the speed of a bike--which puts us at 4x the amount of stored energy in your head which can dissipate. Unfortunately, bicycle helmets are almost definitely useless at this speed.[1]

It's also unclear if the same mechanisms for brain injury apply, though I don't have any statistics on this matter. My impression is that strict blunt force trauma is no longer the prevalent mechanism for injury in cars---you're more likely to get whiplash or some sort of quick rotation that puts you in a coma due to the brain sloshing around. Helmet or no helmet, it's difficult to protect against rotational modes.

So even if we went with this article's suggestion of wearing helmets in cars, there's a large possibility the numbers wouldn't look any better. I wear a helmet on a bike because it maximises my protection given the amount of inconvenience it gives me. Nothing about car statistics invalidates this trade.

[1] http://www.helmets.org/limits.htm