Example: my mother had a cardic resynchronization device, and it had some kind of NFC type thing to enable the full wireless comms mode: wave a wand over her shoulder and the device's radio wakes up for a set time to send data or receive adjustments. So it wasn't always transmitting, but it did require the doctor's office or hospital to have that NFC wand to initiate any kind of data aquisition or reconfiguration. If it has an always-on BLE radio, the provider would just needs the phone/tablet/laptop with appropriate software that is already required.

Since any device like is already going to have a radio equivalent to a BLE radio, then removing the NFC parts from the device (and especially from the provider side) is some amount of cost savings. I think most patients would disagree that this privacy trade-off is NOT worth it, but you have remember that the patients aren't usually the actual customers in the US health care system. (And most manufacturers are going to have the US market as a target at least somewhat.) The most common actual customer is actually the insurance companies, and they'll take every single fraction of a penny, along with "an arm and a leg".

Let's suppose we have a pacemaker, and it has data that is beneficial to read -- maybe even in real-time on their pocket computer, or opportunistically as the patient walks by their reader-device, or however that is done.

So we want this data, and we want it over RF. It probably seems obvious that it should only transmit when it is told to do so, right?

So how do we tell the pacemaker to transmit? On its face, that problem seems solved by integrating a receiver that sits and waits for a valid instruction.

Except: That receiver takes power to run. And since changing batteries inside of a person is problematic, we want them to last as long as they can while still performing the desired task.

Now we get to the not-obvious part: In terms of power, it's often less costly to intermittently transmit a string of data than to continuously operate a radio receiver. And maybe it's a bad idea to have an implanted pacemaker that has an open receiver for anything nearby to try to fuck with, anyway.

But a transmit-only radio? Good luck hacking that.

So... we do intermittent transmission, and this works for pacemakers. It also works for the cheap Zigbee thermometer I have (wherein I don't normally request the temperature; it just delivers it periodically, and it runs for years and years on a coin cell).

(Now: Should that pacemaker data be encrypted? Yes, of course. And so should the ID. In fact, the whole transmission should be indistinguishable from background noise by unrelated devices. In this way, authorized devices can then use pre-shared keys to receive and decode these messages and others receive nothing. That kind of cuts BLE and thus also the pocket computer out of the monitoring mix, but tradeoffs are tradeoffs.)

The fair comparison would be intermittently transmitting a string of data versus intermittently operating a radio receiver, wouldn't it?

Maybe it's still less costly to transmit, that I don't know. But I am interested about it :-).

> And maybe it's a bad idea to have an implanted pacemaker that has an open receiver for anything nearby to try to fuck with, anyway.

This part resonates more with me.

Good point. I don't know that this would actually work with BLE, as implemented on our pocket supercomputers (which I presume to be a useful part of the support system of a modern pacemaker).

But if we change the requirements to "Some kind of maybe not-even-invented-yet RF thing, maybe with a rechargeable translator device that a person keeps in their pocket to convert to BLE when that's useful" then: Sure. Intermittent receive could be used instead.

Whether that's more efficient or not is an interesting problem.

Transmitters tend to use more instantaneous power (ie, Watts) than receivers do, but a transmission can be very, very short. It doesn't care whether anything is listening or not. Transmitter wakes up, blurts out what it has to say, and goes back to sleep.

If a chunk of BLE data of this size takes 1ms of transmit time (it might), and it happens every 60 seconds (it might), then that's transmitting for 1.44 seconds per day.

So total consumed power over time (ie, Joules per day, or whatever) can be very low. That's part of how we got here -- BLE is built around this concept, and it all converges to make this easy to accomplish.

Meanwhile: An intermittent receiver tends to use less instantaneous power, but it usually needs to operate for a longer period. It wakes up and actively listens for instructions for a period of time. If none are received, then it goes back to sleep. Synchronizing free-running clocks is hard (and disciplining them is expensive, power-wise, compared to a sleep state), so maybe that receive window is 50ms every minute. Worst-case: The receiver operates for 72 seconds per day.

Even if receiving uses just 1/10th the instantaneous power as transmitting does (this is probably in the right ballpark), then the intermittent receiver still uses a ton more power over time -- especially if there are no transmissions to receive. (The receive window obviously closes if/when a transmission is received, so having something to hear can improve this some.)

But the end goal isn't just to wake the pacemaker up by pinging it. The end goal is for it to transmit data. So we still get to wake up the transmitter and have it do that.

Now, these are all made up numbers -- I think they're somewhere near reality, but maybe not. But it seems like kind of a double-whammy, to me, compared to intermittent transmit. :)