Diabetes, and CGMs (Freestyle), non-diabetic using one!

I have been diabetic for a few years. My mum was too, since she had me, and we suspect this is what did my grandfather in (undiagnosed) to be honest. It is often hereditary.

I have often felt almost like some sort of fraud. I have insulin, as just taking tablets was not working, but the process is to review my HbA1c, maybe once a year, which is a test that sort of gives an average blood glucose over some months, which is not that good a "picture". But (having lost some weight) I am on a low daily dose of insulin now. That has advantages (one jab) and disadvantages (cannot adapt to changing circumstances easily). I have tablets too. It is "mild" compared to many people.

However, when I started losing weight, I also decided to buy, with my own money, at a cost of some £100+ a month, a continuous glucose monitor (CGM). It sticks on my arm and logs interstitial glucose levels and keeps a history. It has its quirks, like only 8 hours of data (and some times I try and sleep more than that!) so has to be scanned at least that often for a full picture. It is also maybe half an hour behind blood sugar levels, so I can feel hypo when it shows higher as it has not caught up.

However, I have found it hugely useful with managing my diabetes and diet. It is really good for making me aware of the wrong things to eat (basically sugar) and what I can eat in moderation and get away with in, and how much I can eat of something without getting away with it. This is mostly feedback of history rather than "am I really hypo now" which a blood test can do.

Sadly they are not cheap, but I feel they should be used more. They are normally only prescribed for people with severe diabetes, but I can see they should be really useful, even for people just trying to control it with diet. It is a shame they are not cheaper and prescribed more.

Recently I was able to see what a "normal person" is like on one of these. That said, it was rather odd. A friend of mine (who will, no doubt, read this blog) was diagnosed with gestational diabetes. So I gave her a CGM (and another as she knocked the first one off on a car door, FFS). She did not want to do the requested 8+ finger pricks a day, so my treat.

The thing is, having used the CGM, no way is she remotely diabetic. This is one day (with her permission)... Yes, charge that battery FFS!

Subsequent days I have seen are lower than that. She does not spike over 7 even when eating stuff she knows she should not.

For me this was really interesting as I did not know what a "normal", non-diabetic person looked like on a CGM, and now I do. It puts my graph to shame, and I am well controlled (apparently).

Like I say, I almost felt like a fraud, until I saw that, and I know I am nothing like that good. My diabetes is mild, under good control, but very real. I don't feel like a fraud any more, and even wonder if I need fast acting insulin doses when I eat as I can peak at 10 mmol/l, and occasionally more.

Interesting stuff.

P.S. As requested, here is one of mine, on a really good day... Most days I am peaking higher.

New printer (Canon PRO-1000)

I have had, and used, many printers over time (for paper, not 3D).

Just off the top of my head :-

• Simple line of pins impact dot matrix through ribbon - classic. I had a few of these.
• Single "pin" with rotating roller behind paper to do dot matrix through ribbon - slow - prints one dot at a time moving up through the character, then the blade shaped head moves right to do next pixel one dot at a time.
• Band printers - I did not own one, but used one - has all the letters on a band, and it is fascinating watching the line form as each letter is printed when it is over the right space, printing many in the line at a time, so the line of text sort of forms in seemingly random order in front of your eyes.
• Daisy wheel, impact print through ribbon, but fun doing some graphics with a lot of full stops.
• A spark based printer, single wire high drags at high speed across the paper for each row burning off a silvered surface of the paper, dot matrix - creates a black on silver text.
• A spark jet printer, with a carbon rod in a glass tube making a spark to the paper and carrying carbon deposited on the page. Single glass tube moves at high speed back and forth over the paper. Like printing with pencil. I did my degree dissertation on that.
• A variety of thermal printers on thermal paper - head the width of paper. Fades rather easily.
• A variety of thermal transfer printers, transfer from film to normal paper, head the width of paper.
• A variety of thermal transfer multi-colour ribbon printers for photo printing.
• The plastic card printer we use at work, thermal transfer. Ive used two kinds of such printers.
• Normal A4 laser printers, postscript
• A3 laser printer, colour
• Ink jet printer
• Bubble jet printer
• Oh, and pen plotters

Wow, I have had a lot of printers. I suspect I have missed some out even.

Actually, I left out that I have used manual, movable lead type printing machines and done typesetting using actual fonts of lead type characters. Genuine upper and lower "cases". That was a long time ago. I must be old.

The printer I have used for a long time is a wax based printer - originally Tektronix, but now bought by Xerox. I like them as they are not as messy as using toner and do solid colours really well. You just drop in these wax blocks to load the ink, neat and tidy. They are OK (ish) for photo print, but for colour letterheads (which is why we got them originally) they are really nice. I even print red wax seals to use with an embossing seal, and well, it was actually wax.

The office moved on to other laser printers some time ago, and my printer here finally started playing up (sheet feeder issues), so I have decided it is time for a new printer, and I thought it would be nice to get an ink jet type printer, but why not get one that can do photos...

What I eventually got was a Canon PRO-1000. It can have a stack of A4 plain paper for the normal use cases, but can also take a variety of sizes up to A2, and do impressive high resolution professional quality photo prints, edge to edge, on photo paper. It does pretty good photos even on plain paper.

So, yes, it will be used for simple A4 prints most of the time. These days I print quite low volumes, and can alway use printers at work for printing something with a lot of pages. It also has separately replaceable ink cartridges, which I prefer. However, there have been occasions where we do want to print bigger than A4, mainly for circuit drawings, etc.

But yes, I can print really nice photographs now. This is printing an A2 map on plain paper.

I did consider getting the wider models, they can do roll based prints up to A0, or even bigger. You can print proper posters for adverts and the like. But no way it would fit in the man-cave sensibly. I was also not sure if it would do the simple A4 plain paper as easily. The PRO-1000 seems a good compromise. The print quality really is rather impressive and having the option of large prints is nice.

EICAR test QR

It seems there is something of a standard test string for anti virus (wikipedia has more on this).

The idea is that systems that look for viruses will have this string loaded as a signature of a valid virus, and so react as such. This allows you to test virus checking systems without an actual virus being used. Obviously some systems may flag as "test virus" or some such, and some may not have this "standard" string.

The string is :-

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

So far, so good, but what people are doing (see tweet) is putting that in a QR code, e.g. this (feel free to copy this image).

[note the white space around the image is part of the QR code spec]

And then sticking it on a car, or a hoody, etc..

The result is that some systems that happen to log the content of QR codes they see, e.g. on CCTV and the like, promptly trip their virus detection systems. Ooops.

Of course this does raise questions of whether this could count as Computer Misuse, but then should such systems be reading QR codes off a hoody anyway?

P.S. My QR code generator is on GitHub if you want... It seems to be more efficient than most (though no advantage for this particular case), and has a lot of options (png, svg, text, binary, eps, ps, hex, data URL). Have fun.

0

It is funny how we like to see numbers clock over, whether a simple anniversary or birthday, or the odometer on a car, or even years.

Until the year 2000 I do not recall anyone having any issue with the common way decades were numbered. The '20s were 1920-1929 (inclusive), and so on. No issue, no doubt, no confusion. Sadly the year 2000, being a change of millennium, caused many to say "technically the new millennium does not start until 2001 as there was no year 0". This is one rare cases where I err aware from "technically correct" for a change, and even question if it is technically correct. The years are projected back from a more recently invented calendar and indeed go from 1BC to 1AD in one calendar. So on that basis, yes, a millennium starting at the start of 1AD means a new one in 2001. But why consider the start 1AD not 1BC? All evidence suggests that was not when Jesus was born, if he existed, so you should probably consider the third millennium starting maybe spring 2004 [citation needed]. You are picking an arbitrary start point - why?

However, it depends which calendar you pick obviously. We use the Gregorian calendar, but other calendars (e.g. astronomical) do have a year 0 and otherwise align with the Gregorian calendar (for current years). So one can be "technically correct" and still have a new millennium starting at the start of 2000 without any difficulty.

My point all along was that the only reason to consider the change of millennium as "special" in any way is the base 10 numbering that we use, and that a clocking round of 1000 years happens very rarely (oddly enough, every 1000 years), and so the only logical point to consider "special" is when the year number "clocks round" 1999 to 2000. If you are not doing it then, then why even consider 1000 special, why not consider multiples of 324.6 years as "special"?

I had thought this was all old news, but, to my surprise, I see people even now on social media saying the next decade does not start until 2021 as "there wasn't a year 0", continuing this nonsense. Sorry, but (Gregorian) decades only make sense as "special" if you consider them to be the years ending 0 to 9 (inclusive), end of story. So if anyone says otherwise just say you are using the astronomical calendar which does have a year 0, and see how they cope with that. Good luck.

But this may also help (thanks to xkcd)

P.S. this was raging on twitter later in the day on the 1st, and someone even posted that "At age 21 you start your third decade", LOL. No, 1st is 0-9, 2nd is 10-19, and 3rd is 20-29. Anyway, for those insisting "it" starts in 2021, point out that what "it" is, in that case, is "the 203rd decade of the Gregorian calendar" and not "the '20s". The '20s start in 2020, end of story.

P.P.S. a reminder that it is '20s, and not 20's, unless you are using a possessive, like "The '20's greatest hits".

---

Anyway, on a more amusing note, it seems Bulb may have finally fixed my account so I can submit a meter reading (they have been messed up since I signed up for no apparent reason, and just emailed me to say fixed). Yay, so a meter reading is needed.

I was about to submit one, on 31st Dec, and noticed it was close... very close...

This has resulted in my spending many hours on the 31st Dec, turning on extra high power kit in the house for a while, and even running the tumble drier, wasting many pence worth of electricity in order to get this picture (well, maybe not wasting as it means gas heating needs less power as house is warmer)...

It is a thing of beauty, is it not?

To my surprise Bulb had no problem with my submitting the meter reading of 00000.

All the "there was not a year 0" people would say I should not consider my meter to have rolled over until 00003 (or whatever it was when first installed).

---

There is one clock I'd rather not reach 0 though :-

Slow month

I spent over two weeks with a rotten cold, which meant doing bugger all.

I hate that, and even though I have recovered from the cold now, I am still a tad stuck in the "doing fuck all" Christmas spirit.

So, yes, sorry, few blog posts.

I have got my Christmas present to myself, a new watch (Matrix Powerwatch 2) which is pretty cool. And that means once again I am watching my steps and calories, which is good news. Whilst it is new and has quirks, it does indeed seem to be a pretty good smart watch that does not need charging (uses body heat and solar). So far it is working well, even with GPS tracking my cycling! OK, 4461 is not a good step count today, I was again being lazy, but I have been managing nearer 12k most days.

Whilst I am hoping to get my head in to bluetooth and such over the next few weeks, I am also looking at some impressive TI ARM processors as well. More to post on all of that later.

Merry New Year and Happy mid-winter festival to all, whatever your reason for taking a few days rest... I'll be opening some virtual presents in WoW Classic, Mirage Raceway realm, tomorrow.

FTDI USB Serial MacOS Catalina Resource Busy error

In an effort not to be DenverCoder9, here is what I found.

New MacBook Pro, using an FTDI USB serial cable (used to program ESP32 chips).

The error was "Resource busy".

The problem is that googling this gets a lot of people saying they have this issue and a lot of answers which didn't help me - it seems many people do this to themselves by having the device open from some other app. Using lsof I confirmed it was not open by something else. Some pages even suggested update to python, but I confirmed that even a simple cat of /dev/cu.usbserial-A... said the same, so not python. Someone even suggested it was not a genuine FTDI chip, so I ordered a cable from RS, and the same issue persisted.

After a lot of googling, it seems to me that there must be some sort of bug in Catalina. It looks like FTDI USB serial should work on a Mac without needing custom drivers, but it does not work. It is recognised and the /dev/ created as you would expect, but shows the resource busy error.

Importantly there was no pop-up or prompt or error of any sort when connecting the lead, it simply appears in /dev/ as you would expect. No clue that there is a problem with drivers.

So, what did I do?

• Install the VCP drivers from FTDI (2.4.2), it is a DMG you open and install. This all went swimmingly but did not help even after a reboot, and not obvious clue as to why.
• I used the About This Mac, System Report, Software, Extensions, and saw FTDIUSBSerialDriver 2.4.2 listed, Notarised:Yes, Loaded: No, which was a clue.
• Going to System Preferences, Security and Privacy, it showed text "Some system software was blocked from loading". However, this was subtle as the adjacent "Allow" button was not active. It was not immediately obvious but I had to "unlock" the window, and then I could click Allow, and select FTDI to allow the driver.

Then it worked! It seems you do need the FTDI driver for some reason, even though MacOS knows of the FTDI USB serial. It also seems that MacOS has made the process somewhat more complex.

More fun with GPS...

The NMEA sentences from a GPS work on degrees, minutes and fractions. As a format they are horrid - the sign is a separate character N/S, E/W, and the value is fixed length so DDMM.mmmm and DDDMM.mmmm format.

The 4 places for minutes is not that precise, but more than enough for absolute GPS positioning.

But there is an alternative, and it is like the IPv6 of GPS. More precision that you could ever want - ECEF format is X/Y/Z in metres from centre of the Earth to the micrometer!!!

$ECEFPOSVEL,124015.000,3985352.629186,-54462.755461,4962832.255023,-0.008022,0.003776,0.022063

Amazing. So whilst not adding absolute accuracy, it does add some impressive relative precision.

Walking in the road to spell my name, LOL.

Shit week (or two)

Some times things go wrong, it happens, but if I did not know better I would say some deity was out to get me the last couple of weeks!

• My 3D printer started playing up, but in a subtle way. It was printing some parts slightly too narrow, which is crazy. I spent ages on this as the lid of a case did not fit on the base properly. They are a tight fit, but this was just too tight and meant it cracked the edge of the lid. I adjusted tolerances in the design, printed loads of tests, and finally the lid fitted the base just, but no idea why.

• I then put the lid on the widget I was making which has an OLED display. This is glass, and has a very thin bit at the edge. Well, the lid is carefully designed to leave a small amount of space around this, but it printed wrong didn't it! So fitting it cracked the display.
• So I had to remove the display from the base board, and it is fitted with square pins which are a bugger to desolder, so I cut them. But the cutting caused the pins to tilt enough to rip the tracks off the main board. So I had to make a new main board.
• The 3D printing got worse, now it was clearly squashing the design at a particular point, but only some of the time!

• It turns out it would print sensibly to start and then get worse, but also a small print would be fine (it broke as specific points on the X axis) all of which caused confusion as I would think I had found the cause (e.g. the X axis rails were slightly skewed) because a small test print (after tinkering) would seem to have fixed it.
• I tried all sorts, and eventually ordered a new stepper motor. The one from Amazon was wrong current, so did not work, but I found that the original stepper motor was actually slipping on the flat edge of the spindle, only at certain points and only when it warmed up. All this, wasting nearly a whole week, because of a loose grub screw. Oddly Lulzbot totally failed to answer support emails (apart from a e-ticket number) which is really bad of them.

• So, re-installed original stepper motor, tightened, applied thread lock, and bingo, working perfectly again, phew. Back in business.
• I then tried to mill a new board on my milling machine. I have done a lot of these, and I am using a simple bed-levelling program I wrote to measure the corners and adjust the cut over the board to allow fine tracks to be reliably printed. But this one new board (which was bigger than previous ones, and has some long straight cuts) was not cutting correctly - turns out I had a bug in my code that got the Z level wrong (was for previous point not current point) causing some tracks to cut at wrong depth. Just enough to not show up most of the time, but create duff boards several times.
• So I was improving the code, and making it probe several times for each point and more slowly, and so on....
• And just then the main milling motor on my milling machine stopped working. It would spin up slowly and then grind to a halt.
• I tried on a bench supply and it is fine, so clearly the power supply not the motor.
• I ordered a 48V 3A power supply, and that was not beefy enough to run it.
• I ordered a nice 10A bench supply, which I am waiting for now - will it work - I'll add a PS to this post later today :-)
• In the mean time, with 3D printing working, I had managed to make one working PCB, so made a case for the latest widget and it did not fit. For some reason I had made a silly mistake in measuring the parts, which took my about 6 attempts (at over an hour per print) to get right - this is crazy.
• However, the slightly wrong print (due to design, not printer, this time) meant the button cell battery holder moved, pulling tracks off the board, shorting it, and that took me ages to debug as the GPS refused to work with no backup battery.
• I set up the Quectel M95 mobile module, and surprise surprise all of the commands I need are different to the SIM800 module I was using. Arrrg! Thankfully they have a good manual. So new GPS tracker working well.
• Then something else stopped working on the board - I don't know what yet - I need to use my magnifying glasses to work on this board, and guess what, they just snapped.
• And in the middle of this, other issues, involving someone having unexpected hospital visits (which have turned out fine, phew).

It has been a shitty couple of weeks really.

It can only get better :-)

P.S. And not the plastic cover thing on end of my glasses has come off so I stabbed myself putting them on.

P.P.S. the cheapest, unbranded, iffy looking DC power supply I have seen, from Amazon... Actually has a CE mark, but not sure I'll ever leave it unattended. But it works - yay!

Hayes AT

A long long time ago, in galaxy far far away (no, scratch that bit), a standard evolved for talking to modems, well, specifically Hayes modems, but it was widely adopted.

It works over a serial link by sending commands starting AT for (attention). Now, I am pretty sure they were reasonably consistent, back in the day, but like many things this standard has evolved and been bastardised.

We now have things like this SIM800 module, which is basically a mobile phone in a can, with no display or keypad. It talks on a serial bus and talks Hayes AT commands, but as modified by various GSM bodies.

Now, some AT commands are consistent. You send AT and some options, and get some data followed by OK. Good.

There is a reasonably consistent format for commands and settings and queries, mostly. There are then AT+ functions which are used for a lot of the mobile stuff.

But it is far from consistent. The AT+CIPSEND, after the > sends "SEND OK" not "SENT OK" or "OK", and AT+CIPSHUT sends "SHUT OK". Why are these not just "OK" like the rest? I am also pretty sure I had one case of a response with no OK (but cannot find it now).

Then we have the asynchronous messages from the device. Most start with a +, like "+CREG: 0,1", so can be recognised if you are expecting another response. But some are just text like "SMS Ready". These smack of debug messages left in the code.

Half the interface was clearly designed for a person sat at a terminal typing stuff, and the other half was designed for talking to a machine!

But when you get to some of the higher level functions, like establishing a UDP "connection", it gets even more special. For a start, you look for "CONNECT OK" not simply "OK", and mostly at that point it seems to avoid sending asynchronous messages (though I cannot be sure). Some still can be sent, like "+PDP: DEACT" when it loses the connection. What you do get though, with no prompt, header, or indication of length is the raw binary content of any UDP packets you receive on the connection. So send a packet containing "+PDP: DEACT" and I'll think the connection has dropped!

What would have been sensible would have been a line something like "+DATA=N" and then N bytes of data, or some such, but no, it is simply the raw UDP packet.

Then we have some interesting little bugs and discrepancies. One that took a while to work but was that the length of UDP data I can send is limited. Not to 65535 which is what IP limits to, but to 1472 which is the available UDP in a 1500 byte IPv4 packet. Except it is not. It is actually 1460, any more says "ERROR". Oh, and it won't allow me to send a zero length UDP packet - no idea why, and as NAT is often used this is something I may want to send as a keep alive. I ended up having to send one byte.

But there is an even more special feature. When you receive a UDP packet, as I say, it arrives as the raw binary data via serial. I am relieved to see no mangling of any bytes, which is good. Except it truncates the last byte of the message. Yep, I have to send an extra dummy byte on my packets to the device. WTF?

I could save myself from a lot of this by coding PPP, pretending to dial on an old style modem and talking PPP which the device fakes and converts to packet data. This is a serious consideration, to be honest.

However, after a lot of messing about, my GPS trackers are sending (and receiving, when needed) tracking data over UDP over mobile - yay!

P.S. I may have maligned the SIM800 as incoming UDP looks like it may be my bug losing a byte, and there is an option for a header with length for incoming UDP. But the Quectel M95 does look a bit nicer.

GPS trackers

I am playing around with GPS trackers (I'll post more on hardware for this later). This is for commercial vehicles, not anything covert, and I am not going to even touch on GDPR in this post :-)

Reducing the number of points

One of the challenges is managing how often we sample location, and if/how we reduce the number of points. There are a number of reasons to do this:-

Local Storage

One reason to reduce the number of points stored is where the tracker is storing the points - either for download later or for transmission when mobile coverage comes back, etc. The local storage of a small embedded device is likely to be limited. The GPS module I am using has several ways to do this (I have yet to work out how to do other than simple interval). Storing every second, which it will happily do, runs out of space in a few hours.

Transmission

Transmitting the data over a mobile network has costs. Yes, there are SIM packages with unlimited data, but if you have a fleet of hundreds of vehicles you can do better than each of them on a package for tens of pounds a month and unlimited data. There are packages with much lower monthly costs but data usage costs, and there are foreign SIM packages with roaming for better coverage and higher data costs. Reducing the data transmission can get the costs down to pence a month. This means not only reducing the number of points but finding ways to reduce the overhead of transmission of the data itself.

My plan is to pack data in to an encrypted UDP packet, with a simple resend packet sent back if the data has not arrived at the expected time. I.e. an entirely NAK based protocol so that normally it is one packet in one direction, probably every 10 minutes or so. This means really low mobile data usage.

Database storage

Reducing the number of points also helps with back-end storage. Hundreds of vehicles tracked every second means a lot of data. Simply increasing the interval loses useful data so you ideally need a smarter way to reduce the data.

Display

Perhaps a small point, with computers and networks being so fast, but reducing the number of points sent to a browser to display a route can make things much more responsive.

Where to reduce points

At present I have code to reduce the points when pulling from a database and sending to a browser, with an option to also delete the removed points from the database. But ideally you want to do this in the tracker itself - that way you have all of the benefits for local storage and transmission as well.

This also creates an extra advantage - if you have a means to reduce data points effectively you can start by collecting much more data in the tracker. The GPS modules I am using can do 1/10 second fixes, so why not start with this, and reduce points from there.

How to reduce points

I pondered how to do this, and came upon with something based on removing points within a certain distance. I then found there is a standard algorithm which is basically very similar to what I came up with. The Ramer Douglas Peucker algorithm.

It recursively takes a set of points. If all intermediate points are within a specified margin of the straight line between start and end, then those intermediate points are removed. If not, the one furthest away is kept and the point from start to this, and from this to end, are recursively processed. The end result is a path of straight lines where all the removed points must have been within the specified margin of that line.

This works well, and removes points on long straight roads but keeps points driving around a roundabout!

Even setting a margin as small as 1m massively reduces the number of points, and what is even better is that you can start with say 10 times as many points (e.g. 1/10 second fixes) and still end up with similar final number - just that the points you select are more precise (i.e. the exact edge of a turn, not just nearest second).

Of course I won't have a full set of points in the tracker, I'll have to work on time periods, like 10 minutes, collect data, and then apply the algorithm. This means there will be points based purely on time as the end points for the chunks of data I process.

Distances

One issue is that the raw data is lat/lon and not ground distances. There are ways to work out exact ground distances around the curved surface of the Earth, but a simpler way is to just assume we can map lat/lon on to a flat plane. What I do is, for each stage of the algorithm, take all lat/lon relative to the middle, and convert to metres. For latitude this is simply multiple my 111111 (yes, apparently this comes from French definition of a metre). For longitude it is 111111*cos(lat), remembering to convert to radians for cos(). This means I can then work out distance from a line in metres with minimal error. Of course as the algorithm recurses and processes smaller line segments, the error because the Earth is not flat (really, it is not!) reduces.

3D

For a change, I am not talking of 3D printing, but we have altitude as well. So I am including altitude in the calculations. This means that a straight road that has a peak hill gets a point kept at the top of the hill!

4D

Yes, 4D printing would be cool, but no, I am now including time in the algorithm. That way we get points if a vehicle stops and starts or changes speed. The only issue here is deciding how time works as a unit in the distance calculation, so I need a metres/second. I have made this small, treating a 1 second deviation from the line between two points in space and time as a small fraction of a metre, hence you have to change speed or stop for many seconds to create a point you keep. It seems to work well.