Whilst it is a fun application, a novelty, I personally do not feel it has any place being promoted by emergency services. And this post is my honestly held personal opinion, as always.
If they want to "handle" w3w addresses from the public, that may make some sense, as it is popular. If the app if given to them free of charge (as seems to be the case), and if they take any w3w address with some caution, checking the location by other means if possible, then yes, fine.
But reports on social media (including from people I personally know) suggest that w3w is not just "promoted" by emergency services but actively preferred to the extent that call handles will refuse to take simple o/s grid references and insist on a w3w address. For one recent case, the police force in question confirmed that they should have taken an o/s grid reference. But in practice this seems not to be the case.
What seems worse is stories of people being talked through downloading the app on an emergency call. This is quite incomprehensible. Even if you want a w3w address for some reason, it is far quicker to send someone to the w3w web page (what3words.com) which shows your location. The only possible reason to download the app is so the user has the app on their phone. It is a purely marketing activity, as someone is more likely to use w3w if they have the app. Do we really want emergency services actively engaged in time consuming marketing activity for third party closed commercial apps, during an emergency call?
As I say, much of this is anecdotal, but social media is full of this, as highlighted by w3w.me.ss.
What is especially odd is that w3w's own terms and conditions are not consistent with use in an emergency. They expect you to read, understand, and agree many thousands of words before use, and expect you to check the terms before every use. This is not sensible for the caller, and the emergency call handling staff, to do in an emergency situation where time is critical. Also, the terms prohibit use where it could lead to someone dying, which is often the case in an emergency. Given these clear terms, it makes no sense emergency services would even be considering w3w usage, let alone promoting it. It is almost as if they did no checks at all on how it works or even just reading the terms.
There are ways to get location from callers, not just (long standing, open standard) alternatives like o/s grid references or even simple latitude/longitude, but means that don't involve any reading out, like SARLOC or AML. These should be available to emergency services. Even if there is need for a caller to give a different location, knowing where the caller is puts that in context and helps eliminate errors, whatever format is used.
So, in order to try and address this, I have made a petition. It calls for "Review how emergency services handle location data from the public." which I think is fair.
Sign here! And do share the link to get some traction, if you agree this needs reviewing. Of course, if you feel strongly enough, it is also worth contacting your MP over this.
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.
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 two 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.
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 existing" (as 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.
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.
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.
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.
I am thinking of the next generation of my SolarSystem alarm system.
It started as RS485, a slot in replacement for a Galaxy system using the same external devices, and running on a Raspberry Pi with USB RS485 adaptors. It worked quite well.
The next generation used ESP8266, then ESP32 based WiFi connected devices. This works well.
Next generation
I am now planning to get rid of the Raspberry Pi and RS485 completely. The idea is the ESP32 modules work together over a mesh WiFi. Yes, one of them would connect to a conventional WiFi access point, but they can work without that - off 12V battery backup if needed, with no "controller" as such.
This is not that complex - devices need to know what inputs and outputs link to what areas and states in the system, and broadcast information to allow every unit to know when alarm armed, or triggered, etc. Using secure AES encrypted DESFire key fobs on door controllers the alarm can be set and unset.
There would still be a "controller" to configure the system, program fobs, record logs, and so on. But this could be a cloud based service. Some of you know my love of cloud based services (not), and as this is all open source it would allow the cloud service to be run locally. But the server is not a "live" part of the system - it allows config, and so on - via a simple web page. Obviously communications would then be secure to the server.
This makes everything simpler to set up as you just need a local WiFI internet access.
To make it work I now have designs (and several prototype boards and cases) for key components:
Door controller module and NFC reader (can be used as 6 input 1 output module)
Bell box module (also usable as a 2 input 4 output module)
General purpose I/O (5 GPIO with ADC if needed)
Keypad module (fits in galaxy keypad and talks RS485 to it locally)
The nice thing is that just one of these, eg door control, can be set up to talk to local WiFi/NAT and connect to a cloud service allowing configuration of an access system. But you can then add other modules, and set up a whole alarm system if you want. The key fobs have access controls such as which doors, and times of day and days of week that are allowed.
More serious work needed
The issue is that I need to do quite a lot to complete the design and coding for this - not just in the modules, but the controller system and database back end. This is all pure R&D work at present with no concrete customers for the system (though we have had some interest), which can make it a bit hard getting the motivation - but a real customer would also help ensure we are steering the project in the right direction.
Bootstrapping security
One of the design challenges is bootstrapping the security of key fobs and controllers. They need AES keys, and these need to be secure, and need to get in to devices and fobs.
In simple practical terms, you can just buy fobs from the likes of Amazon, and then use one one of the NFC modules - e.g. one of the doors - to program the fob. Similarly you can make ESP32 modules, or use off the shelf modules like nodemcu and flash the code.
But you have to be very sure that this is actually being done by someone authorised to program fobs. Even then, if someone wanted to, they could capture that initial config and get the AES key used. Once the AES key is know the system for a whole site can be compromised.
Once the fob is programmed, any capture of the communications does not help you, but the initial set up of a fob is inherently insecure - this is the bootstrap problem - it has to be insecure as the fob is blank and it has to get the keys - so someone can "pretend to be a blank fob" and get the keys in the same way.
You have the same issue with end devices and a cloud system - you have to be sure the device is the device you think it is. If someone can get a fake device on a system it can get keys. So the devices need a secure client identity too.
I suspect the answer is simple - design the system so that the controller will only do initial config of devices and fobs locally (e.g. USB connected). The controller then sends out the devices and fobs pre-set for the site. Of course this means for a cloud based service the service operator provides the devices and fobs - which may make it more commercially viable to operate a cloud service.
Security
Of course any system has to consider security - the AES/DESFire fobs are massively more secure than 125kHz fobs used by Galaxy Max readers. The WiFi is a bit of a trade off: It is way more secure using WIFi and TLS than RS485 (Galaxy modules can have messages inserted on the bus without it noticing!). It is possible to disrupt (just as cutting an RS485 bus is, which is exposed on outside of building if using Max readers), but like RS485 it would trigger an alarm. At the end of the day you have to be more secure than breaking a window.
The good news is I now have the "proper" PCBs for my door controller and NFC reader...
I have to say they look good - proper boards, and using solder paste and oven means a very professional result.
PCB Train do a nice job, but these were on a three week lead time. Both boards work. However, in the three weeks since I ordered I have made a few design changes.
The door controller changes are very minor - instead of 3 inputs with 3 GND on the 6 pin connector I have all 6 pins connected to GPIO, where you drive some pins to GND if you want. This allows a lot more options if needed, etc. The pins all have BAV99S and 100Ω for some ESP protection, and 33pF to help reduce noise. It is a small change, and so the existing boards are more than usable. The only snag is I mis-ordered as 1.6mm not 0.8mm boards, and I have designed cases to be as small as I can to fit in a back box. I think 1.6mm will still fit, but it is annoying.
The bigger issue is the NFC board. As I say, they work. But the tuning is perhaps not spot on. The newer design boards have a loop both sides, allowing the board to be 40mm x 40mm not 42mm x 42mm. However, the newest boards are better - the main thing is they do not get hot which is a big clue (i.e. the antenna is clearly better and easier to tune), and I have them working with more range. So I would rather use the new boards. They too are also 0.8mm which saves space.
So, all in all, I decided to order some new boards - two week lead time. However I have a few dozen of these boards. As I say, they work, and I am testing with them, and may well use some, but once I get the replacements I will end up throwing these away, I am sure, which is a shame.
So, if a hackspace, or other good cause, wants either of these bare boards, to play with. The schematics and code are all on GitHub. Note, need hot air gun at least for the PN532, and fine tipped soldering iron. Let me know. Email me at pcb1@revk.uk
Long term?
These, and some other related modules, should be able to make a WiFi mesh with (not having to be always on-line) "cloud" control and management (on or off site) to work as an alarm and access system.
My latest project is to make something battery powered, based on an ESP32 processor. The ESP32 data sheet claims it can go down to under 1uA in a deep sleep mode. It also has an Ultra Low Power processor that can do things in deep sleep at only a few uA. It is not very clear in the datasheet for the ESP32-WROOM-32 module how low it can go - after all that has extra bits including an external flash. So it was a bit of an unknown. However, I have made something, and it works... (on GitHub)
The first board was a cock up - wrong footprint completely on a key device - kicking myself. The second version was more what I would expect - some minor errors I could work around, allowing me to prove it all works and confirm power usage. The 3rd version was great except one of the chips again had wrong footprint - but this time close enough for the device to fit without problem. I have managed to keep the device tiny - not much bigger than the ESP32-WROOM-32 itself.
The first application is actually to work with a VL53L0X ranger in the top of an oil tank, running on battery and reporting over WiFi. The next trick may be LoRa for such things.
Battery / power supply?
The first real question was whether to try and run directly from a battery, or to use a power supply?
Directly from a battery means finding a battery that is within spec to produce 3.3V. The voltage from a battery is often slightly more (when new) than stated, and depends on the battery technology. The processor will cope with voltages a bit out of range as well (3.0V to 3.6V). So a 3V battery should work. But the voltage drops as the battery runs down, and we are starting on the edge of acceptable voltages, so this could cause problems. The advantage of running directly from a battery, apart from fewer components, is the really low power modes of the ESP32 should allow a really long battery life.
With a power supply you have the advantage of using a wide range of battery, e.g. 4.5V, 9V, 12V, etc, but the big disadvantage of wasting power on the regulator itself.
I ended up using the LMR16006 from TI which is designed for battery devices, and has an idle current of 28uA when not driving much load (e.g. an ESP32 in deep sleep). It also has a shutdown mode drawing less than 1uA (see more on that later).
However, testing showed that it draws 34uA when not even connected to a load. This pretty much is explained by the 460kΩ potential divide built in to the fixed 3.3V module to drive its feedback pin. I could go for external potential divide but 460kΩ is on the top range recommended in the data sheet.
However, even 34uA is good, and can allow a battery to last years.
USB as well?
Do I need USB as well? Well, no, not really, I could have a generic programming header, but I like the USB-C connectors. They are good as a power supply when not running off battery, and make programming and debug easy. So yes, I'd like to keep the USB.
The issue is power. The USB chip (FT231X) can be powered from USB, and even work its own 3.3V I/O from that. So it can be totally off when no USB. Good.
But it is used to control EN/GPIO0 to reset and put the ESP32 in boot mode. If USB is off, the ESP32 stays in reset. Thankfully the USB chip can be configured to invert RTS and DTR if you want, so I put them through a simple transistor inverter so that when the USB is off the ESP32 is not in reset or boot mode. The result then works as expected with the debug and flashing tools in the ESP IDF.
The Tx pin to the USB when powered down was a concern, but it seems to cause no problem, and the code can turn it off immediately on start up, and in deep sleep it is not connected.
The USB chip can also feed in some useful GPIO pins, reporting when it is on (a fixed "1" on a CBUS pin), and even if it is connected to a charger not a USB device. This means the software can tell if running from battery or not, and stay awake when being used for USB debug.
How low does the ESP32-WROOM-32 go?
Well, the good news is that the ESP32-WROOM-32 does indeed use bugger all (aka 1uA) in deep sleep. This is impressive, so we are looking at under 35uA idle current for the whole board from a 9V supply when idle.
Obviously we need to wake up occasionally, but we can wake up, boot, connect to WiFi, connect to MQTT, report status, and shut down in under a second with fixed IP. Indeed, the WiFi can be in use for under half a second, which is impressive. We need to do some long term tests to confirm battery life.
Measuring the voltage?
Of course, one thing we want to measure is the battery voltage. That allows us to see if we have a low battery. It is essential for any battery based device to tell you the battery is low. The answer is a simple potential divide feeding an ADC input to the ESP32. Except that draws current! Even 1MΩ divide is 9uA at 9V, 100% of the time.
The answer is a FET, well, two FETs. I am not an electrical engineer so this needed a bit of research. One FET or transistor would not work as it had to be at the "top" of the divider. If it was at the bottom of the divider it would mean 9V going in to the ADC pin when the FET was off. But when at the top of the divider you don't have GND as a reference to drive the FET.
The answer is an N-channel FET driving a P-channel FET, all in one package. Thanks to twitter for help on this. It works! I can turn on the divider, take a reading, and turn off again. I have some resistors to ensure than when GPIOs are isolated the FET stays off anyway. Sorted.
How low can you go?
Can I do better than 35uA? Well, yes, probably. The ESP32-WROOM-32 itself goes down to 1uA or so. The regulator in shutdown goes to 1uA but as that annoying potential divider still. If I was able to shutdown and disconnect the power from the ESP32-WROOM-32, it could run off a capacitor for many seconds at 1uA.
So basically I'd need a way for the processor to turn off its own power most of the time!
The trick is ensuring that if you sleep too long, the power will come back on anyway, and indeed when first powered up.
I think I can do this with another FET, pulling the shutdown pin to GND, driven from a GPIO pin. When no power the GPIO will go to ground, pulled by parasitic diodes if nothing else, and cause the FET to go off. Of course you still have the issue of making the shutdown pin then go high when the FET is off, with the only power being the battery, so you still need that one pull up resistor. I wonder how big we can make it? If we can make it 10MΩ we waste only 1uA on that.
The same signal driving the shutdown pin could also drive a FET switching the feedback potential divider, so we turn that off too. It may need some careful design, e.g. FET at bottom of that divide, to ensure we don't fool the regulator in to supplying too much power because its feedback is not get connected, but that should not be rocket science.
For now, I'll test using the current design, idling at 35uA, and see how it goes. But I may yet make a new version that tries to turn itself off most of the time :-)
P.S. I am such a fan of solder paste now, I can't see me ordering boards without getting a stencil as well. It is so quick and so reliable, it is quite amazing really...
It has been a month since I came up with this crazy idea, but the NFC reader board is working really well now. To be fair, every version I have made has worked, just some better than others. The most noticeable impact on how well it works is the inductors. Using small inductors (i.e. 0603) means it is crap - needs fob flat on then antenna to do anything. Now it works around 2cm. I have changed layout a lot, changed the antenna shape, changed component size. Lots.
I have, however, learned a lot about ESD protection, layout for RF, choosing components for RF, using KiCad, and solder paste. The solder paste has perhaps been to be the biggest change as I am no longer afraid of adding passives, which previously would have been far too annoying to hand solder and take too much space. Lots of 0603s are no issue now.
So I have a nice NFC card design, thanks a lot to John for his help. I also have a nice door control module which is tiny, and only 7mm thick. Easy to fit in a back box with other stuff.
If any hack space want to have a play with one of these NFC boards, let me know. I'd be interested in feedback. Main advantages over Elechouse are red/amber/green LEDs, tamper button, door bell input, and more ESD protection.
The boards, and 3D cases, are all on GitHub.
So what next?
Well - battery power - that's what. I have made up a new regulator for my boards rather than using the Pololu boards (they really are very good!). It has an automatic ECO mode dropping to 27uA.
Planning to work on Ultra Low Power mode on the ESP32, see how low I can get it, and run from a battery.
So now I need a board that can be low power. This means the USB chip needs to be turned off when not using USB, which is fun as it means I do not want to power its I/O pins for Tx either - and the ESP32 blurts lots of debug on Tx at start up. So a small FET is in order. Also quite fun as the FT231X USB chip works the RST and GPIO0 pins, so need them to work properly when no USB power.
P.S. Why USB?
Someone asked why do I have USB at all? I used to have boards with USB-C for power, and a header for programming, but it was actually less space and easier to just fit an FT231 to the board instead of the header, so using the USB for power and serial load/debug. The battery board is perhaps an exception as it needs a couple of extra components to let me disconnect the USB, but even so, on a board this small an extra programming header would be tricky, so I decided to stick with USB serial.
My soldering is not bad, but there are limits, and I am reaching them with the smaller and smaller components I am trying to use. Not only are the pins small, they are under the chip. A small QFN is just about doable. So I wanted to up my skills in soldering and try solder paste. I'm impressed with the result, but it was a bit of a journey.
How to do it? Get an oven, get a proper solder stencil, and get the right solder paste. You can then wipe the paste through the stencil with a plastic card, apply components and cook. It works!
So what was so hard?
Well, it was not as simple as it sounds, so here is what happened.
Laser a stencil?
I decided to try and make a stencil myself. Basically, having a proper metal stencil made adds another £50 to the cost, and someone said they had success with a vinyl cutter. I decided to try a laser. I got a cheap one off Amazon (K4 laser generic Chinese thing). Sadly the firmware simply will not laser cut, it only raster images. It looks like I could dismantle it and re-flash with something sane, but a lot of work.
Try again
So I ordered a better laser, one that actually claims to do GRBL. Again from Amazon. The GRBL firmware loader is a windows program but works from parallels, and then it just works nicely with LaserWeb on my Mac. I'm amazed at what you can get.
So what to cut to make a stencil? Well I tried mylar and it sort of melted. I tried acetate, and it sort of burned!
So I tried some actual vinyl, and that worked surprisingly well, but is just not quite accurate enough - rough edges. It would be fine for 0603 but not QFNs. Bugger.
Oh, and all of them made some nasty smells - this is why a cheap laser is not ideal - no fans. Recommend using outside!
Cut a stencil?
Next I tried an actual vinyl cutter, as someone else had managed this. How hard could it be. I decided to try and do a bit more research, and there are some nice small cutters like Cricut and Silhouette. However I see Cricut recently stopped you cutting your own designs!!! You have to pay for designs. Wow. And I could not work out what you needed for Silhouette to work. So I went for a more generic cutter/plotter that does HPGL. Using Inkcut on my Mac worked, I can cut things...
But, not quite. For a start it took a bit to work out it uses XON/XOFF. Then I found when the serial port closes at the end of the job the printer aborts and so does not finish the job (I added a delay to fix that).
It could not cope with mylar or acetate, but did cut vinyl. However, it did not make a clean stencil! The pads were not closed and the fine pads were just a diagonal line!
The answer is that I did not quite do enough research. This is a "drag blade" cutter, so the blade point drags 0.25mm behind. This would be fine(ish) for cutting large sticky back lettering, but now when the features you are cutting are not even 0.25mm wide! There are, apparently, some s/w work arounds I could try. But for now I have given up and decided to do it properly...
Try again
Update: It looks like the Silhouette printers are going to work. Seems you have to pay £50 more for being able to load an SVG, but it will load a DXF anyway. Converting SVG to DXF is easy with inkscape and free, so why would you pay £50 more. That said, I am not sure it can cope with such detail.
Use a proper stencil?
So I ordered a proper stencil - very nice. PCB Train do a good job.
I ordered some solder paste from RS, and, well, it was a disaster. It was runny and far too much solder paste, and well, useless!
Try again
I was desparing, but encouraged by people on twitter who clearly managed to do this right, I carried on. I ordered some different solder paste, just in case.
It worked first time, clean, nice, easy to use. I am impressed.
The first board made like this actually worked - well minor issue with reset, but did then work. So now to try another.
Update:
I failed to get anything to make my own stencils, but the ones from PCB Train are impressive. One trick is they charge the same for stencils up to a certain size, so I'll be adding a number of boards that I think I have finished and ready to the artwork for next stencil order anyway. If they are the same when I order the actual boards, great, I have a stencil already. If not, then it has not cost me to do this, but it is an incentive not to move any components if I do have further changes at all before ordering.
