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.
Hi Raymond, your first link Esperto.medical isn’t working. I also sent an email about the algorithms engineer position on your site if you want me to CC you too.
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!
Ironically, in my experience, finance is the field that probably cares most about risk management. That and maybe healthcare (though less than you would think, surprisingly).
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.
I think there's an important lesson to learn: unlike offline, many online communities only exist because people find it interesting, and there exist many things that no one will take care about. If not now, when? It not you, who?
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?
Atomic physicists use mostly semiconductor diode lasers.
You need to narrow their emission wavelength to something ~ the atomic transition (MHz) and then carefully tune it as you say.
Typically diffraction grating is used to carefully feedback some of the laser's output (<10%) back into it, and this can be used to to narrow the emission from several nm to MHz, and to coarsely tune the frequency to few 10-100 Ghz.
Fine tuning is done by changing the current flowing through the laser or the temperature of the junction. These both cause a frequency shift on the MHz scale scale.
You might fine it interesting, you can also use VCOs for fine tuning, but you take the generated RF and send it into a crystal called an Austo-optic modulator. The laser light refracts from the RF phonons propagating through the crystal and this can be used to shift the laser light by the RF frequency.
Typical optical clock transitions have ~Hz linewidths, not MHz.
The intrinsic frequency stability of almost all lasers is by far not good enough to be able to probe such transitions. Therefore, ultra-stable optical cavities are used as a frequency reference, and the laser is constantly steered to stay on the cavity resonance by a fast electronic feedback system. In this way, laser linewidths in the sub-Hz range can be achieved. Then an acousto-optic modulator is used to scan the laser frequency across the clock transition.
*acousto-optic, of course. (I swear, auto-incorrect is getting worse.)
To expound slightly on your (correct) explanation: The phonons impart (or remove) energy to (from) the laser light, the same way a moving mirror does: via doppler shift.
I made a differential heterodyne interferometer in undergrad using the method you describe.
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.
- psu drawing: no left-to-right flow, connector names are numbered, output connector (CONN2) is just floating around on the left and connected via net names. Same pretty generic net name ("out") is used as in the main amp.
- amplifier drawing: the main feedback loop is obscured because it's only connected via net names, connectors are again just stashed of somewhere to the side and only connected by name and not labelled. I would also point out that each op-amp of the quad-op-amp U1 shares the same designator, so you can't talk about U1a, U1b etc., which you actually do in the text.
The left half of the schematic is arranged pretty neatly and logically, but the discrete output stage is pretty cramped over there (clearly limited by the fixed sheet size), though standard arrangements of the building blocks make it quite clear what everything is (U1c U/I conversion, current mirror to the top rail, mirrored back to the bottom rail with an x3 CM, resistive load to the top, emitter follower output stage, CCS as load, off to the output).
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
Even FETs that have a published SOA, it often ends up being roughly "don't spend more than about 10% duty cycle in the linear region" because FETs have been so strongly optimized for switching applications.
> 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).
If the pi is designed to throttle at a temperature where its lifespan is reduced from 50 to 49 years, then it is throttling at a gratuitously low temperature that affects quite a few use cases.
On the other hand, if it is designed to throttle at a temperature that materially reduces the lifespan, then it needs a fan to preserve its lifespan.
Either way, the hardware is starkly suboptimal for a pretty large set of advertised use cases until you add a fan.
> If the pi is designed to throttle at a temperature where its lifespan is reduced from 50 to 49 years, then it is throttling at a gratuitously low temperature that affects quite a few use cases.
That's another claim that needs evidence. It seems possible to me that the thermal throttling is designed to prevent logic errors.
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).
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:
.. 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: raymond.jimenez@esperto.health