The OmFLA device uses the following algorithm to compute glucose levels.

A. Computation of the current glucose level
-------------------------------------------

1. The glucose sensor contains two tables: a "trend table" which is updated
every minute, and a "history table" which is updated every 15 minutes. Both
tables are ring buffers.

2. Each table contains 3 different kinds of measurement, say A, B, and C.
Each measurement is 16 bits. The RFID reader in the OmFLA reads data in
blocks of 64 bit (the blocks are also called ISO 15693 registers in the RFID
reader documentation). For that reason in every read of the sensor one of the
measurements A, B, and C occurs twice. The trend table starts at ISO 15693
register 4, leading to the following distribution of measurements A, B, and C:

block       16-bit Measurements       Reading index
(ISO reg)    M1   M2   M3   M4      M1   M2   M3   M4
------------------------------------------------------
  4         AAAA-BBBB-CCCC-AAAA    1111-1111-1111-2222
  5         BBBB-CCCC-AAAA-BBBB    2222-2222-3333-3333
  6         CCCC-AAAA-BBBB-CCCC    3333-4444-4444-4444
  7         AAAA-BBBB-CCCC-AAAA    5555-5555-5555-6666
  8         BBBB-CCCC-AAAA-BBBB    6666-6666-7777-7777
  9         CCCC-AAAA-BBBB-CCCC    7777-8888-8888-8888
 10         AAAA-BBBB-CCCC-AAAA    9999-9999-9999- ...
 11         BBBB-CCCC-AAAA-BBBB
 12         CCCC-AAAA-BBBB-CCCC
 13         AAAA-BBBB-CCCC-AAAA
 14         BBBB-CCCC-AAAA-BBBB
------------------------------------------------------

Every minute the glucose sensor updates 3 16-bit fields in the table, causing
either one or two blocks to be overridden with new values. The reading index
(the position of the 3 fields in the table, aka. the FIFO's put pointer) are
contained in block 3 (which contains 2 indices: one for the trend table and
one for the history table.

3. We ignore the history table entirely, because its values are too old for
alarm purposes.

4. every 5 minutes (the interval can be configured by the user) we read the
entire trend table and filter out those 16 bit values that relate to raw
glucose values. Each glucose value has only 12 bits, therefore the upper 4
bits of every raw glucose value is discarded (set to 0).

The A and B measurements in the table are being ignored because we don't know
what they are and how they influence the reported glucose value. Then the raw
glucose values are sorted and the 3 upper and the 3 lower raw values (potential
outliers) are discarded, This is to smooth out sensor tolerances, After that,
9 middle glucose values remain.

5. The average of the 9 raw values is computed.

6. The average is then translated to mg/dl (aka. mg%) by:

    glucose (mg%) = SENSOR_OFFSET + SENSOR_SLOPE/1000 * raw_value

where:

SENSOR_OFFSET = -20
SENSOR_SLOPE  = 130

Both SENSOR_OFFSET and SENSOR_SLOPE can be configured by the user.
Finally, the resulting glucose value is compared against and upper and
a lower alarm threshold to decide if an alarm shall be raised.

B. Alarm thresholds
-------------------
The glucose levels at which an alarm is raised is controlled by 4 parameters:

   ALARM_HIGH   = 250,   // mg/dl, beep if glucose > ALARM_HIGH
   ALARM_LOW    =  66,   // mg/dl, beep if glucose < ALARM_LOW
   MARGIN_HIGH  =  40,   // mg/dl, minimum between initial and limit_HIGH
   MARGIN_LOW   =  20,   // mg/dl, minimum between initial and limit_LOW

All 4 parameters are in mg% and can be configured by the user.

B1. Normally the user should aim at a glucose level between
(ALARM_LOW + MARGIN_LOW) and (ALARM_HIGH - MARGIN_HIGH) when the OmFLA device
is switched ON. With the default values above (which are used unless the user
configures them differently) this is a range from 66+20=86 mg% to 250-40=210 mg%.
 if the user uses the default values above. If the user switches the device ON
and the first successful glucose measurement lies between 86 and 210 mg% then
the device raises an alarm when a subsequent glucose measurements is below
ALARM_LOW (55) or above ALARM_HIGH (250).

B2. If, however, the initial glucose level is below
(ALARM_LOW + MARGIN_LOW) = 86, when the device is switched on, then the lower
alarm threshold is reduced from ALARM_LOW = 66 to
(initial glucose - MARGIN_LOW) < 66. This is to avoid false alarms when the
device is started at a low glucose level. It is assumed that the user has
taken measures to increase the glucose, but that these measures have not yet
shown an effect. If that happens (the glucose level rises again) then the lower
alarm threshold is raised again until it reaches ALARM_LOW = 66 again. At this
point the device is back to normal mode. see B1.

B3. Likewise, if the initial glucose level is above
(ALARM_HIGH - MARGIN_HIGH) = 210, when the device is switched on, then the upper
alarm threshold is increased from ALARM_HIGH = 250 to
(initial glucose + MARGIN_HIGH) > 250. This is to avoid false alarms when the
device is started at a high glucose level. It is assumed that the user has
taken measures to decrease the glucose, but that these measures have not yet
shown an effect. If that happens (the glucose level decreases again) then the
lower alarm threshold is lowered again until it reaches
ALARM_HIGH = 250 again. At this point the device is back to normal mode. see B1.

C. Implementation detail
------------------------

In order to save program bytes, all glucose levels X are internally stored as
X/2 so that the fit into a unsigned byte (aka. uint8_t). The values 0-255 of
a byte corresponds to glucose-levels 0-510 mg%. This is important to keep in
mind when configuring the EEPROM bytes (which contain all the user-configurable
values of the OmFLA device.

For example, in order to set ALARM_HIGH to 240, the corresponding EEPROM must
be set to 120 = 0x78. If the debug image is used, then all user defined
parameters in the EEPROM are displayed like this:

osc=x4C
slope=130
offset=-20
alarm_HIGH=250
alarm_LOW=66
margin_HIGH=40
margin_LOW=20
batt_1=1200
batt_2=1096
batt_3=1000
batt_4=896
batt_5=800
read_error_retry=56 sec
read_interval=296 sec

Baudrate is 57600 8N1, active low TTL signal.