Three Thing Game. Like Old Times

Staying up late. Writing programs to impossible deadlines. Such fun. 

I'm back at Three Thing Game as part of the Spooky Elephant Collective. The organisation is great and the pizza delicious. I managed to stay sentient until around 11:00 pm, which is actually quite impressive for me. The game that we are making celebrates the great things about Hull through the medium of Venn Diagrams. 

Wish us luck. 

Begin to Code with Python goes to print today

I spent a big chunk of yesterday going through the final drafts of "Begin to Code with Python". And today the files will be going off to the printers.

I started work on the book in March, and we now have a 630 page book with over 170 example programs. Thanks to everyone at Pearson and Microsoft Press for letting me write it and being so helpful during the process..

The book will be in the shops at the start of December. The perfect Christmas present. 

Arduino vs One Drive

Some things you just have to learn the hard way. For a while I've been frustrated by the way that my Arduino projects would build fine for a while, and then fail after I had saved them. 

Eventually I worked out that if you're working on a folder which is being shared by One Drive (or DropBox and probably Google Drive) this causes the Adruino SDK to get upset when it tries to build a solution. This must be due to the file sync process causing files to be locked when they shouldn't be.  Move the files to your desktop and the program builds perfectly. 

Of course, the proper way to share a development project between a bunch of machines is to use GitHub, and that's what I'll be doing in the future....

Lora Node Live

Well, I've sent and received my first Lora packet sent from a node into a gateway. It turned out to be quite easy to set up. First you create an application, then you create a device, then you take the key data of the device web page and paste it into your node program. Then it works. 

Now I need to work out how to take the data off the server at the things network and do something with it. 

Great fun.

Super Mario Odyssey. Buy it.

I read a review of Super Mario Odyssey which ended with the phrase "If you've got a Switch, you must buy this game. If you've not got a Switch, buy one and then buy this game".

I agree. It really is that good. Not that I'm anywhere near through it, but I'm enjoying every minute. Everything is polished to perfection. The game runs well on portable and on TV. The idea of having something this good that you can play on the train is really nice. 

When I bought this game I did something I don't usually do with full price games like this. I bought the download version. It meant I could get started without a trip to the shops or waiting for a parcel, and it also means that the game is always present on my device. I've got a micro SD card in my Switch and the game takes up around 5.3G, which is not a huge amount of space by today's standards.  

I'm starting to wish that I'd bought all my other games this way, it would remove the need to carry round cartridges. Perhaps a video game shop could over a scheme where they take your game media back and swap it for a download code.  I'd go for that. 

Learning about Lora

I don't know much about Lora networks. But I know more now that I did this time last week. Which is a good trajectory I suppose. Here are some things I know now.

  1. Lora is low-power, long-range. But very low data rates (just hundreds of bytes a second, if that). 
  2. Lora works. As I write this I've got a tiny Lora node sending lumps of data across Cottingham, where they are being received.
  3. You can get Lora devices for very low prices. I'm paying around 12 pounds for a node with a rather fancy OLED display, but you can get the interface chips for a round a third of that. 
  4. Frequency is important. In the EU you should get devices that work on 868Mhz, in the US go for 915MHz. There's another frequency, 433Mhz that you can use in the EU, but it might not work as well because this frequency is also used by radio amateurs and whatnot. 
  5. If you want to just use Lora to link a few devices that are a long way apart (up to a KM or so) then you can buy devices like mine and just use them. 
  6. Lora nodes in a proper Lora network talk to a gateway device that takes their messages, assembles them into lumps of JSON and sends them over the internet to a central server which makes them available to your application. You can buy gateways, or you can make tiny ones of your own. (That's what I'm trying to do at the moment)
  7. Lora uses a range of radio channels which are grouped around the working frequency of the particular node. A proper gateway implements a bunch of channels (usually 8) and cost at least 150 pounds, but you don't need one of these to start with. A single channel gateway will work fine for up to 50 or so nodes.
  8. You can register your gateway on the things network. This acts as the server in my description and allows other people can find and use it, and also lets your cloud service capture data and send commands to nodes. Commands are sent to nodes after the node has sent a message to the gateway. This saves power (and makes the networking easier) but it does mean that you can't just tell a node something, you have to wait until it reports in and then send a message. The node will listen for a while after it has sent a message. There are versions of Lora that allow messages to be sent to the node at any time, or in designated time slots, but these aren't in common use yet.  
  9. You create applications on the things network. An application is associated with one or more Lora powered nodes which use keys to authenticate their messages. You can bake the key into the node and use activation by personalisation (ABP)  or use over the air authentication (OTAA). OTAA is more secure, but not many devices (and certainly not simple gateways) do this. 
  10. Anyone can hear your Lora transmissions. The Lora standard offers proper end to end encryption but this doesn't seem to be available in devices just yet. 
  11. Andreas Spiess (aka 'The Guy with the Swiss Accent') has made some splendid videos that describe the technology. Great to watch during the lunch hour. 
  12. Lora is a great solution but I'm not completely sure what the problem is. But I'm still going to play with it. 

CQRS and Event Sourcing at Hull Developers

Hull Devs is going from strength to strength. Hot on the heels of the talk last month we have another great talk, this time from Mathew McLoughlin who told us all about CQRS and Event Sourcing. At the start of the evening I had no idea what any of this was about. But by the end of the evening I was up to speed. 

CQRS stands for Command Query Responsibility Separation. But knowing that doesn't really help you understand it at the start. The Event side of things is a much better place to begin.

If you are implementing something complicated (Mat used hospital admissions as an example) you could do this by having a record for each item in your system. You could fill a patient object full of things like like name, age, whether the patient is in the hospital, their ward number etc etc. Your system could then update these records each time the patient changes state.

This would store the data, but if you work this way a lot of information gets lost. If you want to know which wards a patient has been treated in, then a system structured like this will not be able to tell you. Furthermore, you're not really capturing what is going on, which is that people are arriving in the system and stuff is happening to them. Instead you're forcing users to update small parts of a large data object (the patient record) each time. 

Rather than looking for the data you need to store, better to look for significant events in the trajectory of your objects, and build a system that captures these events. When a patient arrives, moves wards, gets test results and finally goes home, you record these events and your system can then then "play through" them to build a picture of the current state of your patient. It's a very nice way to work. Want to find out the state of your hospital last week? Just run the events to that point and stop. This reminded me a bit of "block chain" currencies where the movement of a lump of money is traced from person to person as it is used to pay for things.  

Mat suggested "Event Storming" meetings with the customer to identify events  and what effect they have on object state. This involves lots of paper, post-it notes and the development of a common language between customer and developer. And sounds like fun. 

OK, but what about CQRS? Well, events are a great way to get stuff into a system, but if you want to view the state of your data you have to do a bit of work. The "Command Query Responsibility Separation" part really means that "projections" of the data in response to queries should just consume events and use them to build the view of the data. The storage of the events should be the responsibility of a totally separate process. This makes the design of the system much easier. The only downside is that your view of your system may be a tiny bit behind the times, as your projection updates in response to events, but in a modern implementation this should not be a problem.

It was a great talk, very interesting. Mat has built some C# that demonstrates this which you can find here. I'm looking forward to the next one. 

Thank you, Windows 10

I'm rather liking the Windows 10 Creator's Edition Fall Update Feature Release 1709 for x64 based Systems (KB4041994).

It's full of little changes that just make everything that bit better. Like the way that the Onedrive sync status is now showed in a separate column, rather than on top of the file icon so that I couldn't tell what type of document I was looking at. 

On tip though, after the upgrade I was a bit worried that my system disk had suddenly got a lot smaller. I managed to free off 41 GBytes just by deleting previous Windows installations. 

Network your 3D Printer with Windows 10 IoT Core. If only.

I've installed Windows 10 Creator's Edition Fall Update. It's very nice. It has a lot of extra support for 3D printers. And I got all excited when I found out that there's an application for the Windows 10 IoT Core running on Raspberry Pi that lets you install your printer on the network and then print to it straight from Windows 10.

It doesn't work. At least, not for me. I've spent all afternoon creating SD card images, configuring them and then finding out that I always get assigned the same (wrong) printer device and then the driver fails to load. 

Oh well. 

Lora Networking Hardware

Had a rush of blood to the head today and ordered a complete Lora networking kit from Tindie. Only slightly more expensive than a video game and a lot more fun. I'm going to set up a test Lora network in Cottingham for folks to connect their sensors. It's only a single channel gateway (hey - I'm not made of money) but it should be good for up to fifty sensors or so. . 

Then we can work out what to use it for......

Plenty of Hardware at c4di

We had a great meeting at the Hardware meetup this week. We had digital video, DC motor control, Lora networking and transistor insights. And some new faces. If you want to come along you can sign up here

This is what I was working on. I had another Lora node receiving the messages. When it works properly I'm going to take the plastic cover off the display.....

Remote Harmony

Today I spent a little while sorting out the remote control for the telly. I bought this fancy Harmony Remote a while ago in a second hand shop and I think it has turned out to be quite a bargain. I've used Harmony remote controls for a very long time and I've round that they work very well, within the limitations of a totally open loop control system, where the remote just pumps out an infra-red message and has no way of knowing if it has been received or not.

Anyhoo, configuring the remotes is something I don't do often enough to be able to remember all the steps involved. But I do know that I'll have to download a program and then plug the remote control into the computer. I'm using a version of Windows that is several on from the one for which the program was created. I'm installing a USB driver that was written ages ago. I'm using TVs and devices that are comparatively recent. And yet it all worked. The Logitech servers even remembered the settings from last time (because I'd put my Logitech username and password into Password Padlock). Now I can turn on the TV with a single touch.Very impressive.

Broken Device Dilemma

Here;s the thing. Something I hardly use has broken. Do I:

  1. Take it as a sign that I don't really need this device in my life any more and move on.
  2. Take it as an opportunity to investigate the problem and try to get the thing working again, even though I'll hardly ever use it when it is fixed.

I think you know the answer to this question. I've ordered a replacement cable, just in case that is the cause of the problem....

The Lure of Lora

I was on AliExpress the other day, always an expensive experience, and I happened upon some boards from Heltec that offer an ESP32 (the upgrade of the ESP8266), a tiny OLED display and, most interesting, a connection to the Lora network. I've been meaning to spend some time playing with Lora for a while. It offers low power networking with a range that can go up into kilometres. At first I ordered one, and then it occurred to me that a network with only one node isn't really a network, so I got a couple more. 

They arrived on Friday the 13th last week and, much to my surprise given the date, they worked first time. I downloaded the sample programs, added them to my Arduino IDE installation and in no time at all I had two of the devices talking to each other.

Later on I discovered that I have been a little unlucky/stupid in that I've bought versions that work on the 433 MHz radio band, which is not the frequency that works the best for these devices. For the UK I should have bought the version that supports the 868 Mhz band that is used in Europe

Never mind. I can still use them, but I'll get more interference because this band is used by radio amateurs, car keys and building alarms etc. I'm looking forward to finding out more about how the network can be used.