garphunkle

I thrive in high-stress situations (for short periods of time). Examples include hardware validation before a large production run, putting out literal fires in manufacturing sites, and working in foreign countries to troubleshoot/rework bad hardware. I do fine in live coding interviews, they don't feel much different than being alone at an editor for me.

I was interested by the author's statement: "Working memory is the most reliable proxy (I know of) for fluid intelligence, your ability to reason, solve novel problems, and think abstractly." and the linked study (https://pubmed.ncbi.nlm.nih.gov/21037165/). My working memory is not so great, but it degrades less under stress.

Question worth considering for hiring managers: do you prefer stress-capable employees, or greater working-memory employees? Is my model a false dichotomy?

Shout-out to Violet Crown, PHENOM, Breakfast Club, UNITED, Night Owls, and all the other great cycling clubs in Austin! Wonderful community that I still miss.

Have you tried swapping bikes with your buddy? Are you two the same height/weight? Who has the more flexible spine? It would be fascinating to measure aerodynamic efficiency for two riders on the same bike. Is the more variation within populations, or between populations?

Try using the Silca Tire Pressure calculator set to "Gravel Roads". This will give a safe PSI recommendation with a nod to comfort. I would ride 28mm GP4000s around 75 psi on a training ride with lots of chip seal

I'm not sure if steel frames make a significant difference in comfort. If we measure comfort as deflection or vibration, then tire choice will have orders of magnitude more importance. When you have two springs in series, the combined spring constant is dominated by the weaker spring.

I race on a carbon frame with 30mm tires, and commute on a steel frame with 38mm tires for what it's worth.

Bike weight is irrelevant on flat roads. We should be obsessing over Watts/gram of drag, not Watts/kg if you're not a climber

Someday vendors will provide L2CAP support and we can all stop using GATT for bi-directional data transfer

Android allows you to initiate scanning and receive advertisements without user interaction (assuming the app has the permissions to run in the background and use Bluetooth). Advertisements are "broadcasts" or "beacons"

"Pairing" in BLE-speak is a key exchange procedure so devices can establish a secure connection without performing authentication again.

BLE communication can happen inside of a "connection", or outside of a connection.

A typical device "advertises" it's presence with beacons which are broadcast on 3 channels. These beacons are user-defined, so you can use them like UDP packets. Sensor wakes up and broadcasts the current temperature.

Your smartphone can receive advertisements while scanning. Check out the insane number of beacons present in an American apartment complex.

Note: BLE connections may be encrypted, or not. That's up to you. You do not need to "pair" (exchange keys) to communicate with a connection. There are 4 "modes" to authenticate. Without an out-of-band communication mode, all are vulnerable to MITM.

The latest BLE standard improves range with a half-data rate PHY. Range is determined by transmit power and attenuation. Most BLE radios are designed for short-range communication. I've never seen one consuming more than mW, but that does not mean you couldn't make an amplifier that transmits BLE much further

Lutron Electronics is a good counter example

I like to joke that as usage based insurance goes to infinity, we all become uninsured drivers...

Each insurance company uses the telematics differently. While the pricing model is regulated, it is not public. There is a substantial difference company-to-company

I think this is an instance of HN-confirmation bias. We all hate monitoring, so a study or article that says UBI and behavioral modification is harmful appeals to us.

Matter came around after I left, but I believe it is the same as CHIP: * IEEE 802.15.4 (2.4 GHz PHY/MAC) * 6LowPAN (IPv6 for constrained devies) * Thread (Mesh network layer) * UDP or CoAP (CoAP is like http for connectionless networks)

You need a bridge to connect CHIP to the internet (e.g. Apple Home). It was cool to route IP packets directly to lightbulbs from aws, but we don't bridge the networks in practice and all incoming/outgoing traffic goes through the bridge application.

I've been working in embedded for 5 years and am curious how rust could solve my biggest headaches:

* Managing build configurations - I use CMake to build a single application for multiple hardware platforms. This is accomplished almost exclusively through linking, e.g., a single header file "ble-ncp-driver.h" with multiple "ble-ncp-driver.cpp" files for each target platform. I call this the "fat driver" approach which has proven to be easier to work with than creating a UART abstraction or ADC abstraction. Does rust's package system address this?

* Automated device testing - fluid leaks are similar to bugs in software. They are systemic in nature and cannot be easily understood through static analysis. We spent equal time maintaining a test bench as product development.

* Preemptive operating systems - more trouble than they are worth. Often, devs get bogged down writing messages queues to pass items between task contexts and timing analysis requires detailed event tracing.

Given I don't see teams struggle with memory ownership (easy to do if you never, ever malloc), what else can rust bring to embedded dev?

My attempt at a summary:

Ripple refers to "spatial-reuse": a phenomenon where a train of packets spread from an originator uninterrupted.

With Ripple, nodes can only transmit DATA when they have received the "talking stick" (token) from the upstream originator. A downstream node can request a token with the new MAC frame: ready-to-receive. With their simulation, a node is always in either a TX, RX, or Listen state with equal proportions, so you have 1/3rd spatial-reuse.

This solves a problem in 802.11 where physical layer collision avoidance is sub-optimal for link utilization. Other protocols I am familiar with solve this with beacons to synchronize guaranteed time slots (a mode of IEEE 802.15.4), or they adopt a similar RTS/CTS scheme which can suffer from the hidden node problem.

What I cannot picture in my own head is how a packet can swim upstream: this protocol has a strong notion of upstream/downstream.

  Location: Philadelphia, PA or Austin, TX
  Remote: Yes
  Willing to relocate: Yes, to Austin or Philly
  Technologies: C++, Embedded, Python, Jenkins, ARM, Bluetooth, OpenThread
  Résumé/CV: https://tinyurl.com/y3vl7o9a
  Email: [email protected]

Two years of new product development and working with the high quality internet of things platforms. I'm relocating to a city my significant other has job offers in.

Feel free to drop me an email for a phone or technical screen.