[non] changes to Highway Code rule 170

There is a lot of talk of changes to the Highway Code that are happening, notable rule 170.

Some motorists are really cross at the "new rule". There is always some bad feeling between cyclists and motorists, but this is especially odd, as the "change" is not really a change at all. So the only people cross over it are those that clearly have no clue the rule already exists.

How is it not a change?

The existing rule says "watch out for cyclists, motorcyclists, powered wheelchairs/mobility scooters and pedestrians as they are not always easy to see" so motorists already have to be on the look out for pedestrians when at side roads.

It also says "watch out for pedestrians crossing a road into which you are turning. If they have started to cross they have priority, so give way". It makes it very clear a pedestrian crossing a side road has priority.

The "new rule" only makes a very tiny change to this, as it requires motorists to give way to pedestrians "about to cross the road".

But it is hard to see how that is not, in effect, already the rule. Motorists already have to watch out for pedestrians, and a pedestrian can change from "about to cross the road" to "crossing the road" in a tiny fraction of a second by putting their foot out. I mean, this can happen far quicker than a car getting to the pedestrian, so the motorist (watching out for pedestrians) has to allow for that happening and be prepared to give way to the pedestrian crossing the road at a moments notice. It is hard to see how this is different to the new rule. So in that respect the rule has not really changed. The only other aspect of this change is from the pedestrian point of view where they may feel empowered to cross a side road rather than wait for a car - but, as always, pedestrians have to be on the look out for motorists unaware of, or ignoring, the rules.

All of the back-lash I have seen on this ignores the fact that pedestrians crossing a side road ALREADY HAVE PRIORITY over vehicles turning in to the side road.

The Highway code even has an image showing a pedestrian that would not see the car is planning to turn (even if they looked a moment before), which is, I am sure, why the rule exists.

Publicity

It is obvious from the posts on social media that a lot of motorists have no clue about rule 170. I also see this every day as I cross a side road on my walk. The typical scenario is a car, STATIONARY on the main road, waiting for traffic the other way, and I start to cross the side road. The car then expects me to stop in the middle of the road to let them turn in to the side road because of a gap in the motor traffic. I don't try to get run over, but I do make it clear that, obviously (as per the Highway Code), I am not expecting to stop. This has led to enough drivers getting cross (apparently they never read the Highway Code) that I even have cards with rule 170 printed on them to hand out. I have even had one car stop (after not hitting me), and driver and passenger get out to chase me down the road - all because they don't know the rules of the road!

So this non-change to the rules makes no difference on its own. What will make a difference is all the publicity it generates. Hopefully it will make drivers aware of the rule that has always existed, and the somewhat cosmetic change to that rule, and they can start giving way to pedestrians at side roads as they always should have.

Anomalies...

I do hope they clear up the anomalies I have noticed in the rules though...

• Pedestrians crossing the side road have clear priority over vehicles turning in to the side road, but I don't see anything saying they have priority over vehicles leaving the side road. So in effect they have priority over half the road. This seems like a mistake, and maybe there is some other bit of the highway code that even I have missed that says this. It would be nice to make the priority apply for the whole width of the road. My concern here is that cars may wait for a pedestrian about to cross, but the pedestrian is waiting for cards leaving the side road to stop - causing confusion, or if they cross - leaving a pedestrian stuck in the middle of the road waiting for cars to stop leaving the side road.
• The priority is over vehicles "turning" in to the side road - but what of a cross roads or a side road on a bend where no "turning" is needed. As written, the rule does not apply in that case. I hope the new rule makes that clearer, maybe using "entering" the side road, or "entering or exiting" (as I say above).
• It is not entirely clear if the rule covers things that may not really be a "side road", such as an entrance to a private car park, etc. I assume they are a "side road", but are they? I am not sure, so maybe the new rules could make that clear too.

Fun with DHCP

We have had a slight issue at the house here, we have some Apple HomePod things. My son decided to put several in the house when staying here and now my wife is using one.

The snag is that they keep falling off the internet! A power cycle fixes, but it is very frustrating.

I have found the solution though, and I think it points a finger at the cause.

And it is all down to DHCP. Yep, not DNS this time. Not IPv6 even. DHCP!

So what's the problem?

First off, what's the kit?

• FireBrick doing DHCP and Internet gateway
• Aruba APs
• Apple HomePods

The failure did not seem to be all the time, but could be. Sandra has almost given up using them as they never work. But it seems it can usually renew its DHCP without problems, but sometimes it gets stuck. The logs on the FireBrick showed we kept sending a DHCP "Offer" to the HomePo, but it keeps asking.

I added lots of debug, and confirmed that the request being sent, the DHCP "Discover", does not request a broadcast reply, which is fine, so we send the reply to the MAC of the HomePod and its "new" IP address. This is normal.

On a whim, I decided to try fudging the code to treat the discovery as if it has asked for a broadcast reply. This then meant a Discover, Offer, Request, and Ack - but the HomePod did not see the Ack and so kept asking. I then forced the broadcast on the Ack as well, and bingo, it worked. So the issue is the broadcast used for Offer and Ack.

This is a massive clue.

So more investigating.

The RFC says the broadcast request is in the left most bit of a 16 bit flag field.

PLEASE DO NOT DO SPECIFICATIONS LIKE THIS!

I fully understand that bits in a byte may be sent "on the wire" low or high bit first, or high to low bit first. I fully understand that bytes in a word may be ordered big endian or little endian. The above diagram is for a 16 bit "network byte order" value (i.e. big endian).

They number the bits from 0 to 15. Actually they number the gaps between the bits 0 to 15.

In my view there is only one way you should number bits - by their binary power of two value. I would always write that in the way we write numbers, most significant first, so would write that as bits 15 to 0, and it is bit 15 that is the B flag. I don't mind if showing as bits 15 to 8, and 7 to 0 (big endian) or even as 7 to 0, 15 to 8 (little endian), but number each bit by its power of two value, please!

Some people number as order on the wire, starting from 1. So 1 to 8 may be 0 to 7 or 7 to 0, who knows! Please do not do that. But at least if numbering bits 1 to 8, you have some clue that something is wrong.

So, to be quite frank, I actually do not know if this is bit 0 or 15 in a network byte order (big endian) 2 byte (16 bit) value. We assumed it is bit 15, i.e. bit 7 in the first byte. But seriously, from bits numbered 0 to 15 and a reference to "left most bit" I don't actually know for sure. I started to doubt we had read the RFC correctly!

Thankfully empirical testing shows the flags as 0x8000 from other devices, so either it is bit 7 of first byte, or other devices have the same fun reading the RFC. 

So who is at fault here?

Well, my son has the same FireBrick and the same HomePods, but different APs. That all works. That is another clue.

My Aruba APs are set up to inject data in the DHCP, which is good. I get details of the AP and SSID, and can even tell the FireBrick to allocate based on SSID even if different SSIDs on the same physical network. All good.

It may be that it is stripping the broadcast bit, bit that does not explain why it works after a power cycle. Interestingly the working DHCP renewals did not have the injected AP details, it seems. This points further to the AP being "special"

My son does have different network switches as well, so it is just remotely possible that it is a switch level issue, but that seems unlikely - the DHCP discovers are from the right MAC so all switch learning should be fine.

P.S. Yes, I had changed the filtering to disabled already.

The work around...

FireBricks now have an option to force broadcast reply. And it works. Alpha out soon.

Freestyle Libre vs Dexcom

I have used freestyle libre CGMs for a long time.

Yes, obviously, I’m diabetic, but I have always felt like a sort of amateur diabetic! I take one injection of slow acting insulin a day, not like real diabetics that have match a dose to what they eat every meal. I did not know imposter syndrome was a thing with diseases :-) However, having seen the CGM readings for a couple of non diabetics now I can see that my blood glucose is very different to “normal” and feel a tad more “legit”…

But not having to match insulin to every meal (I take tablets with meals to help) I’m not the normal target for a CGM. However, if you can afford them, I would recommend them for anyone who is diabetic even if like me it is more “mild”. Indeed, perhaps even more so where I cannot easily compensate for eating the wrong thing, the CGM has helped me get my diet right (on most days). My reaction to carbohydrates is far from obvious as some simple things can send my sugar spiking but others are no problem. The CGM helps me learn the problem foods and drinks, and what is not a problem. Even so, that is not always consistent, and can have surprises...

For example:-

• The small hump on the left last night was an evening meal with loads of rice and vegetables.
• The big spike in the middle was breakfast, which was a single sandwich (i.e. one slice of bread cut in two) and bacon, with a tablet even. No idea why so high!
• The small hump on the right was a large roast beef dinner, vegetables, and even a nice cherry cheese cake with syrup - which I expected to be a "problem"...

Not an ideal day for sensible diet, but the effect is not anything like obvious from the meals!

However, one issue with the freestyle is they occasionally screw up and don't work. Yes, in theory, I could send them back, but it got so annoying I decided to try a Dexcom instead.

Freestyle libre

• Each sensor lasts 14 days - means changing on same say of week.
• Takes one hour to warm up at start.
• Has to be scanned regularly, and only holds last 8 hours. Any older data lost if not scanned.
• Works out around £25 a week.
• The newest model has alerts for low/high but still needs scanning for readings.
• Occasionally screws up and you waste a £50 sensor. Yes, could send it back.

Dexcom

• Sensors lasts only 10 days.
• Works out around £37 a week (on yearly plan).
• Takes two hours to warm up at start.
• Updates phone via Bluetooth so no scanning. Seems to catch up if not near phone for a bit, but no idea how much memory.
• Has alerts for low/high, or soon to be low/high.

The actual sensors are different, the Dexcom has sensor and transmitter. It is bigger, has a bigger sticky patch, and thicker. The transmitter is silly - 3 month life limit and buy a new one (I included in above price), but seriously, in one off, it is £200! Why not 50p for a new button cell? And it is not like it is more complex that the whole freestyle sensor which is £50. Definitely some level of price gouging there, in my opinion.

Having said that, their web site makes no sense - you can buy packages, or individual sensors as it says "You can always choose to pay as you go, purchasing Dexcom products whenever you need them". However, the individual sensors say "Limit: 1 per user". So do they mean you can only buy "one at a time", or "one, ever". I assume "one at a time", but if that is the case the Starter pack (3 sensors and transmitter for £159) which says "Limit: 1 per user" would be the best deal of all, if it means "one at a time", so I have no idea!

The other thing that is interesting is the difference in the actual readings... Here is the last 24 hours on Dexcom and Freestyle.

The breakfast peak shows as 15.3mmol/l on the Dexcom, and under 13 on the Freestyle. The dips over night (that caused an alarm) shows as 3.1mmol/l on the Dexcom, and nearer 4 on the freestyle.

Scaling and overlaying you can see they are close, but not quite the same.

Problems!

The sensor lasts 10 days, well should do. I managed 5 days before it was too painful, and I removed it. The start pack has three, so I'll try one on my arm, but if that does the same I'm going to ask for a refund. Never had this with the FreeStyle Libre.

FYI, a week later this is still not healed properly - it is getting there but pretty serious reaction. I tried on my arm, and whilst the reaction was a lot less severe, I had to remove it as it was too irritating after a few days.

Dexcom are being slow to do anything. I've filed an MHRA report anyway.

Is this getting boring?

I have been working for two weeks on this cloud based management for my access control system and it is going well.

There have been a couple of days of total head-bang-against-wall stupidity, but mostly going well. I ended up making a new MQTT client module for my ESP32 as part of it even. The practice in MQTT server and client code bodes well for my putting MQTT in FireBricks, by the way.

One of the things I did was send a controller to someone from a hackspace and I have to say that was a great decision. He is making helpful suggestions and finding bugs and asking sensible questions. If you want the perfect tame customer, they are the ones!

I have some shiny new boards, yay!

So yes, that is progress.

Next week I have other work to do, but I'll come back to this with feedback from the first couple of real users, including a hackspace.