← back to the chart

Take the data

Everything the page shows, as files you can open in a spreadsheet or load into whatever you like. No sign-up, no email, no licence to agree to.

For ten days a sensor on my arm reported my blood glucose about once a minute, and I photographed what I ate. That is all this is: one person, one arm, one consumer sensor, over one stretch of ten days that has now ended. It is a public record of a stunt, not a dataset from a study — see what it is not below before drawing a conclusion from it.

Covers: working it out…
Up to: —
Readings: —
Meals: —

Three files

glucose.csv

Every sensor reading: timestamp, millimoles per litre, milligrams per decilitre, and the trend arrow the sensor reported.

meals.csv

One row per meal: when, what it was, the carbohydrate estimate and how that estimate was arrived at. Names the photo files, so this joins to the zip below.

photos.zip

The meal photographs, full size, named to match the meal rows. Assembled in your browser, so it takes a moment and costs me nothing.

What the columns mean

ts_utc — the reading's own timestamp, in UTC, ISO 8601.
ts_local — the same instant in Stockholm time, which is where I was. This is the one to use if you care what time of day I ate.
mmol_l — the reading as the sensor gives it. One decimal place is all the resolution there is.
mg_dl — the same number in the other unit, as the sensor reported it rather than converted by me.
trend — the sensor's own arrow, 0 to 5, falling fast through rising fast. Blank where it did not say.
carbs_g — grams of carbohydrate. An estimate unless carbs_source says label, which means a nutrition panel was in one of the photos and its numbers were used.
confidence — low, medium or high: how sure that estimate is. Low usually means the portion was hard to judge from a photograph.
photos — the filenames inside the zip, separated by spaces. Empty for a meal I did not photograph.

What this is not

Worth saying plainly, because the file format makes it look more official than it is:

One person. Nothing here generalises. The whole point of the research this site cites is that two people eating the same food get different answers, which makes a sample of one a description of me and nothing else.
A consumer sensor, not a blood test. It measures the fluid between cells rather than blood, so it lags real blood glucose by several minutes and reads a few percent off. Sharp changes are where it is least accurate.
The carbohydrate figures are mostly guesses from photographs, made by a language model. Check carbs_source. The ones marked estimate should be treated as roughly right at best.
Meal times are when I pressed the button, which is usually while eating but sometimes a little after.
Gaps are real. A sensor goes offline, a phone loses signal, and one sensor read a compression low overnight that was the mattress rather than my blood. Where I know a stretch is wrong I have said so on the chart.

Using it

Do what you like with it, including commercially, with no attribution required — though a link back is welcome. There is no warranty of any kind, and it is not medical information about anybody except me. If you build something with it I would genuinely like to see it: the comment box on the front page works.