Steve also published a post at a newsgroup were he presented some more details about his ”KetoFlute”. He also included a picture of his creation.

Date: Jun 12 2012 21:12:02

Gang...

I've been silent for the past week while I've been pushing to 
get a prototype ketone breathalyzer finished

I've never worked with USB at the hardware/software level 
before. So I didn't appreciate that the USB HID (Human Interface 
Device) was inherently low-bandwidth, or at least low polling 
rate... fixed at a minimum of 16 milliseconds per packet 
exchange.

Since my whole effort has been toward determining as quickly as 
possible whether I CAN detect exhaled ketones, and differentiate 
their effect on the gas sensor from the extreme effects of 
temperature and humidity, I have wanted to race to reach that 
conclusion as fast as possible.  That meant NOT placing any 
processor out on the data collection end... just using a "dumb" 
solution that could talk to ultra-high-resolution analog to 
digital converters.  But THAT meant that the USB HID polling 
rate severely limited my possible transactions with the ADC's.

Consequently, I was forced to scrap my first iteration base upon 
the USB HID spec and switch to mainstream USB data exchange.

THAT second-generation solution is now FINISHED and WORKING:
http://www.GRC.com/health/KetoFlute_2nd_Research_Breadboard.jpg

In the photo, you can see the mouthpiece at the lower right,
the gas collection chamber, and its connection to the pair of 
22-bit ultra-high-resolution SPI-interface surface mount ADC's.

The large green button allows the "user" to signal to the 
software, though I'm unsure that it will be necessary since 
there is NO DOUBT when someone is blowing into the gas 
collection chamber.

The two large power-transistor-looking things near the top are
a P-Channel Power MOSFET which I use to switch the USB's 5 volt 
supply to the pair of gas sensors, and an adjustable voltage 
regulator which I use to drop the USB's 5 volt supply down to
3 volts for the gas sensors. (If this should ever evolve into
a limited production run build of KetoFlutes, it would run on
a pair of AA cells, so 3 volts is my operating target.)

The circuit board at the far left is an FTDI USB-to-Serial 
protocol bridge which, among other things, supports the SPI 
protocol used by the pair of Microchip MCP3553 ADC's.

The left-most trimpot adjusts the sensor voltage to 3vdc, and 
the other four trimpots adjust the gain and offset for each of 
the two data acquisition channels.

It's all working and able to collect a pair of high-precision 
22-bit samples at about 22.5 samples per second, which is more 
than adequate for my purposes.

And I have a prototype console app that reads and displays the 
data from both channels, but I don't have anyone handy who is 
NOT in ketosis.  For ME, I'm seeing a DEFINITE "common-mode" 
signal difference between the "signal" sensor that IS supposed 
to respond to volatile gasses and the "control" sensor that 
should NOT respond.  But I don't yet know that I might not
just be seeing a difference in, for example, the channel gain. 
(Though I don't really think I am, since I swapped channels and 
the response moved with the sensor.)

I have the podcast tomorrow that I need to switch over to now. 
So it will be for another day or two before I'm able to bug my 
NON Ketogenic friends and have them blow into the mouthpiece 
while I collect and log the data for subsequent analysis.

I may well remain in a fat-burning ketogenic state for the rest 
of my life. So I would LOVE to have a handy ketone breathalyzer 
that can yield both qualitative and quantitative realtime 
appraisals of my body's ketone status. I've been poking my 
fingers and drawing drops of blood for test-strips several times 
per day, but at kr31.73 () per test it's not really affordable over the 
long term, and my fingers are getting a bit chewed up.

So... If I can make this work, I will DEFINITELY build at least 
one standalone AA battery-powered "KetoFlute" for myself.  And 
if there appears to be sufficient interest among our podcast 
listeners, then I'll likely do a single production run of these 
devices to equip everyone who wants one.