Blood Glucose Meter tear down: Contour Next One

A recent study by the Diabetes Technology on a cohort of 1000 people found that of 18 popular glucometers in the US, only 6 met the FDA standard for accuracy:

Investigation of the Accuracy of 18 Marketed Blood Glucose Monitors. David C. Klonoff, Joan Lee Parkes, Boris P. Kovatchev, David Kerr, Wendy C. Bevier, Ronald L. Brazg, Mark Christiansen, Timothy S. Bailey, James H. Nichols and Michael A. Kohn. Diabetes Care 2018 Aug; 41(8): 1681-1688.

and another good study on accuracy here: Performance Evaluation of Three Blood Glucose Monitoring Systems Using ISO 15197

I was surprised by 2 things:

  1. Of course that only 6 BGMs met the standard….
  2. The FDA standard itself which specifies accuracy of only +- 15mg/dL at or below 100mg/dl and +-15% above that number. If your fasting blood glucose was measured at say 95mg/dl, that could mean to a 95% confidence level you are anywhere from 80mg/dl (relatively close to hypoglycemia) to 110mg/dl (pre-diabetic).

I decided to take a look inside the best scoring BGM: Contour Next One. Basically it looks like this:

 PCB top side

Top side features a simple connector housing for the strip insert, a Toshiba custom analogue front end and an MCU.

A decap of the MCU reveals that it is from Renesas and is likely a R5F51135ADLJ (128KB ROM flash, 32KB RAM, 8KB data flash). This is based on Renesas’ proprietary read more

Simplest NSOutlineView Demo

Most NSOutlineView examples I have seen are not that helpful since you spend time trying to figure out how the data model behind the example works rather than seeing how to use the framework itself. Yes, the data model is critical, however if you don’t understand the framework then you won’t be able to write a controller to feed the view or the model…

 So. I have tried instead to get started by boiling this all down to the simplest possible configuration.

Before the Memory Leak Police get on to me, the below is not written for memory management beauty but rather to demonstrate the framework; so, the reader is left to figure out the releases. I know I generate lots of objects…and also that I violate MVC….

But, can you make it simpler than this..?

 

Power up Interface Builder, drop an NSOutlineView into a window, hook up the delegates and outlets like you would for NSTableView. That’s it.

Here is what’s going on in the code.

In Method#1, I hard-wire the code to return that every node has 3 children. You can see that in the output below if you look under the nodes that have been expanded. You could put here any integer or function that returns one.

In Method#2, you have to return a pointer to a unique object for each of the children that you declared in #1. Normally you would ferret around in your data model to find the right object. Here I just generate a new empty object each time and return a pointer to it.

In Method#3 I hard wire-in that every node is expandable.

Finally in Method#4, I demonstrate a point from the last blog entry. You return the data that you want displayed according to with the object you returned from Method#2.

This data can be from within the Method#2 object itself or it can be something completely different, perhaps even completely unrelated to the Method#2 object. For example, you could just return the word “Hello” and have it appear at every node on the view.

I chose to get the address of the Method#2 object (also demonstrating that each object in the tree is unique) and to concat that with some text.

In the next post, a more complicated directory browser. This time with MVC.

NSOutlineView: Part 1 Introduction

Introduction

Outline views are great for displaying hierarchical data because they allow the user to drill down into the parts of the dataset that are the most interesting.

OutlineView Tree

A common place where they show up is in file handling windows. So. My last example in this column will be a directory browser. To build an outline view, all you have to do is create the view in Interface Builder, hook it up to your code and implement 4 specific delegate methods. Simple really.

It turns out that unless you try and understand some of what NSOutlineView does behind the scenes, the chances of actually hooking up your data right are remote… If you have a bug, what tends to happen is that you either get an exception/crash or nothing happens. And since much of the inner workings take place beneath the hood inside runtime, it’s not as if you can put a breakpoint inside the NSOutlineView to see what’s going on. It can take many NSLogs in your code to get some visibility.

Delegate Methods

You can think of delegate methods like the outsourcing of a task. When the outline view needs to know more about the data that you would like to display in the view, it simply calls the relevant “delegate” method and expects an answer.

These methods are the interface between your dataset and the onscreen view. At a minimum, NSOutlineView requires you to implement 4 delegate methods in your code. There are several other delegates that are strictly optional and which add more functionality to your outline view.

It’s easier to call the 4 compulsory delegates Method 1-4 instead of their full names; besides, this is the order in which runtime tends to call them anyway, so it’s a useful frame of reference.

Let’s dig in to how it all works.

Method#1

– (int) outlineView: (NSOutlineView *) outlineView numberOfChildrenOfItem:(id)item

This is the first delegate that runtime will call to populate your outline view. It asks the question: “For the node that you just clicked on to expand, how many children objects should I allow for?”

This method is only called on one of 2 occasions. Either:

  •  When the view is first displayed at start up and runtime needs to know the contents of the Root level of your data
  • When a node is expanded and runtime needs to start building the display of that node’s children.

Since these cases both happen relatively rarely, Method#1 tends to be called the least frequently out of the 4 delegates.

The next delegate methods #2 and #3 will be called the number of  times you specify in the number you return now. So, if you return “3” here, they will get called 3 times.

2 values are passed to this delegate by runtime:

  •  (NSOutlineView *) outlineView (or whatever you choose to name the view). This pointer is passed to you in all 4  delegates so I’m only going to bother to explain it once here. When you build an outline view in Interface Builder, you have the option of making a multi-column display. You could have 2 different outlines displaying in each column. To let you know which outlineview runtime is talking about, it sends you a pointer. For a simple 1 column outlineview, you can ignore this pointer.
  •  (id) item. This is a pointer to the object associated with the node that the user clicked on. For example, in the above diagram, when the user clicked on “Applications”, the pointer to item here would point to the object associated with Applications. There

read more