Writing up code as you write it

/

I’ve found a good use for all that time I seem to be spending waiting for my programs to compile and deploy to my hardware. I’m writing up what I’m trying to do. This is what I wrote today:

  • fixed a bug whereby only the latest reading and not the average environmental values are sent in an MQTT reading.

  • changed the handling of timeout so that an incomplete reading is sent rather than just skipping a reading

  • bug in modification so that the air quality reading was not sent when only the environmental sensor was disabled. This is because the reading age was less than the reading timeout. So a reading taken at the start of the reading period would be "out of date" by the time that the reading had timed out. Fix this by increasing the reading age to 60 seconds. Also modified the reading timeout setting so this cannot be set more than 60, so that a user couldn't cause this by silly settings.

  • added a 1 second delay before powering down after a message has been sent so that we can send MQTT messages to the device when we know it is awake. Managed this delay to ensure that it is none blocking.

  • found a nasty bug in MQTT message decoding that broke the decoding of incoming messages. Put the MQTT message decode into the main thread rather than calling the JSON decoder on the callback which is running on a network interrupt because it broke the Serial.print output. Added better decoding of the message types (better as in working).

Fun with KiCad

/

After spending a chunk of today with KiCad I have managed to make a schematic. I managed to go from this error…

..to this error…

… to no errors. Now I just have to figure out how to make this design into a PCB.

Note that if you are into hardware development you should probably think about getting into KiCad. It really is a wonderful program. It’s free and it lets you design your own circuit boards.

Close all but this file in Visual Studio

/

This is awesome. It might have been in earlier versions of Visual Studio, but I’ve only just noticed it. One snag of using the lovely code navigation features is that you can end up with lots of windows open that you don’t need any more. So, now you can right click on the tab for an open file and this very useful menu pops up. Close all but this does just what you want. It gets rid of all the other windows and just leaves you back where you want to be. If you’ve got several panes open (a great idea if you have a wide monitor) it only closes the tabs in that pane.

Very useful.

Fuses from history

/

Ian gave me these ages ago. I did a blog post about how I’d put a 3 amp fuse in the microwave with predictably hilarious results. Next time he saw me he gave me a couple of packs of fuses with great big labels on them (as if their different colours weren’t enough).

Anyhoo, today I actually used one of them. The bulb in my lovely magnifying lamp failed and as a parting shot it took out the fuse in the mains plug. So I finally had a use for a 3 amp fuse.

Thanks again Ian.

18th Hull Raspberry Pi Jam

/

I went to the 18th Hull Raspberry Pi Jam today. It was great. They had loads of Raspberry Pi machines set up and a lovely exercise wiring up neopixels. Everyone who did the lab was knocked out by how easy it is to create and control coloured light displays from software. I was showing off the work in progress for my LED Cube, which is presently two of my older panels connected to a Raspberry Pi and displaying demo images. I’m using this software to drive the panels and it works a treat.

I was telling anyone who would listen (there were a few) that the panels I really wanted to use were stuck in UK customs. I’m really hoping that soon they will be released, I can pay whatever hefty duty they figure out that I owe and I can get on with building the device.

Then I got to talking to Jon about his recent project which involved making an awesome piece of artwork. For his next one he’s going to be using a coin mechanism. These are the devices that you find on fruit machines and the like. Apparently you can buy them from Ali-Express for not much money. So I’ve bought one.

You configure the mechanism by setting it in “learn” mode and then inserting loads of a particular kind of coin. It can remember three different types of coin and the output is a simple sequence of pulses that should be easy to pick up with an Arduino or Raspberry Pi.

I’ve absolutely no idea what I will use it for. I was thinking of taking it to a hardware meetup and offering people the chance to see if it recognises their coins:

“Lets see if it can recognise your two pound coin. Oh, bad luck. Sorry, no I can’t get your money back again.”

If nothing else, this could be a nice little earner. The device has cost me considerably less than a computer game and I think I’ll have at least as much fun with it.

The next Raspberry Pi Jam (which I think will be the 19th), is on the 14th of March. This upsets me, because I would really like to go but I won’t be able to make it. Kudos to Jon and Matt who organised the event, provided the coloured pixels and then helped everyone to make them light up.

Using Arrays in OpenSCAD

/

I was doing some work today on a new chassis for our environmental sensor and I discovered how to use arrays in OpenSCAD. So I thought I’d write it down for me for later.

OpenSCAD is a language designed specifically to express 3D designs. I’ve been using Python inside the FreeCAD tool, but I’m trying to learn OpenSCAD too. Let’s just say I like a challenge.

Anyhoo, today I was placing the holes for the particle sensor mounting. I know where the four holes need to go, but I don’t want to have to create four separate cylinders that describe the holes to be cut. I’m lazy. And besides, next time I do this I might want to place 100 fixing holes. So I looked into how I could put the hole coordinates in an array and just write some code that works through them and makes the holes. That way, if I need to place 100 holes I just have to add to the array.

sensorMountingHoles = [[19,0],[41,0],[0,55],[60,55]];

for (a = [ 0 : len(sensorMountingHoles) - 1 ]) 
{
      point=sensorMountingHoles[a];
      translate([point[0],point[1],0])
      {
          cylinder(r=1.4,h=10);
      }
}

This little snippet of code creates an array called SensorMountingHoles which has offsets from 0,0 of the holes that we want to make. The array is actually an array of arrays (that’s why the square brackets are nested) and each “inner” array has just two elements, the x and y coordinates of the point. The for loop works through the “outer” array and pulls out each point in turn, translates to that position and puts a cylinder there. In other words I’m going to get holes at (19,0), (41,0) and so on. If I want more holes, I just add more elements. If I use the resulting collection of cylinders in a “difference” element I can use it to cut holes.

Rather nice.

Raspberry Pi Jam in Hull on Saturday 1st Feb

/

The next Raspberry Pi Jam is in Hull on Saturday 1st Feb. It looks like all of the coding slots have been booked up, but if you want to go along as a spectator, or to show off something you’ve made it looks like there are spots available. You can sign up here. I’m going to take along some LED panels and talk about building a LED cube. I’ve just discovered that my LED panels are actually in UK customs at the moment, which is rather exciting.

Amazing Radio: Conversations from a Long Marriage

/

Yesterday I asked the question “Does anyone listen to radio drama any more?”. And I made the point that if you don’t you should. I’ve been listening to Conversations from a Long Marriage on BBC Radio 4. It’s what you get if you have a couple of actors and a write at the top of their game and you turn them loose.

It’s exactly what it says in the title. The bickering of a married couple (probably a tiny bit older than me) about life, the universe and how they get on with each other. There’s a story of sorts, with stuff happening along the way, but for me the really great bit is the way that the actors inhabit their roles, and the delightful detail that brings it all to life.

I guess it works best for someone like me who happens to have been married for rather a long time, and can relate to a lot of the content. But I reckon it would work for anyone. It’s very funny, and you build up a real affection for the characters. It’s hugely impressive that the production can build up a whole universe out of just two people talking.

At last, I’ve found a reason to run the BBC Sounds app that they keep going on about on every TV and Radio program. Seek it out.

Root Letter: Last Answer for Switch

/

What did I do today? Well, I went to a small town in Japan, checked into a hotel, met a strange old bloke in the communal baths, had a meal in a nice restaurant and discovered my fortune in love at a local shrine. Not in real life of course (I wish), but in the game Root Letter: Last Answer which I found in town today at a very nice price. It came in a box with some nice artwork too.

It’s an interactive graphical novel. I expected that the graphics would all be hand drawn, but that is not the case. Instead there is a lot of photography, plus a smattering of video. The locations look like lightly processed images of real places and all the characters are all pictures of different people. I’m not sure if the production process actually involved going to a town, taking pictures of the library, museum etc etc along with local postmen, chefs, bartenders and creepy old men, but it looks like it could have been.

The plot is rather slow moving, but for me it is all about the journey anyway. You do get a quite nice glimpse of Japanese life along with the gameplay. What you do affects the outcome, so I’ve already decided that a few dodgy decisions that I made at the start of the game may have doomed me a bit, but I’ll be happy to come back again and have another go. You can save your game progress at any point, so you can always save before a momentous conversation and then re-do things. You can’t really compare the gameplay to that of a fast moving video game, it is more like reading a book or listening to a play on the radio (does anyone do that any more - you should).

For the price of entry I reckon I got a good deal, and I’m looking forward to finding out just what happens.

"Secret Hitler" is an amazing game

/

We spent a very happy few hours last night playing the game “Secret Hitler”. Its a role playing game where fascists (plus Hitler) take on liberals. The job of the liberals is to find out who they are and then band together and use their superior numbers to pass liberal policies. The job of the fascists is to disrupt all this and get their policies passed. If fascists get Hitler elected as chancellor they win. If the liberals get to shoot Hitler they win. The gameplay seems rather complicated when you start, but after a while the process of holding elections and passing policies gets to be second nature. Then you can get on with the lying and chicanery.

It’s not really a comment on politics. It could just as easily be Sharks vs Jets or ketchup vs mayo. However, it does set up some very interesting gameplay which kept us very engaged. If you fancy having a go you can even download and print your own copy. Well worth a look.

Bring back good stuff: Humax PVR

/

By rights the personal video recorder should be a dead device. It was in our house for a few months. I had thought that the rise of streaming services would remove the need for you to own a device that records programmes off air. I was wrong though. The FreeView user interface on our TV is not just bad, I think it is actively hostile. Finding programmes on the different platforms is uniformly horrible. The iplayer site deserves a special mention here, in that it seems able to work out exactly what I want to watch and then hide it.

In contrast the YouView programme guide is a masterpiece of simple design. You just scroll back into the past and get the programmes that you have told it to record for you. And you can skip past the adverts.

So today I went up into the loft, found the required shiny box and plumbed it back into our system downstairs. It’s a very old device, but I don’t think it has been bettered.

Bring back good stuff: The Wii U

/

I’ve just got my Wii U down from the loft. I’m a bit cross with myself for putting it up there. Being Nintendo hardware it of course just worked. Even though it is eight years or so old. And the games are still awesome. Its interesting that the devices have held their value quite well, and there are also plenty of Wii U games for sale in the second hand shops around town too. I think there are quite a few people out there who see it as a bit of an unrecognised gem. It certainly gives you a gaming experience unlike any other, with some very interesting asymmetric game options, particularly for party games.

The other wonderful thing about the Wii U is that it runs all the original Wii games, so that I was able to fire up Wii Sports again and have a few games of tennis. Wonderful fun.

Disabling the ESP32 Brownout detector

/

I hate it when things fail when they are not supposed to. I’ve now got some code that uses deep sleep on an ESP 32 to drop power consumption to a tiny amount between the readings made by the environmental sensor hardware that Brian has built.

Today I was doing some battery testing and I hit a snag. When the device is running from battery power the deep sleep mode breaks. The device does a power on reset rather than waking from its deep sleep as it is supposed to. Of course, this only happens when it is not connected to a computer, so I can’t use any of my debugging tools to find out what is going on. In the end I had to resort to flashing the LED on the device to indicate the reason for the reboot. 

void flashLed(int flashes)
{
    pinMode(LED_BUILTIN, OUTPUT);
    for (int i = 0; i < flashes; i++)
    {
        digitalWrite(LED_BUILTIN, true);
        delay(500);
        digitalWrite(LED_BUILTIN, false);
        delay(500);
    }
}

void flashBootReasonOnBuiltInLed()
{
    esp_reset_reason_t reset_reason = esp_reset_reason();
    flashLed(reset_reason);

    delay(2000);

    esp_sleep_wakeup_cause_t wakeup_reason;
    wakeup_reason = esp_sleep_get_wakeup_cause();

    flashLed(wakeup_reason);
}

This is the code that I ended up writing. On usb power I get a reset reason of 8 flashes (deepsleep) and a wakeup reason of 4 flashes (timer). All good. On battery power I get a reset reason of 9 (brownout).

OK, so what is a brownout? A brownout is when the supply voltage drops a bit low. It’s something you need to worry about because low voltage can cause your processor to do some very strange things. It might get its sums wrong or forget stuff. The ESP32 has hardware that checks the supply voltage and resets the processor if it detects that the power supply is failing. Software in the device can then detect this and go about shutting down safely.

In the case of our sensor the brownout is caused by one specific event. It occurs when the program turns on the power supply that drives the particle sensor. The particle sensor has a fan in it, which takes quite a chunk of current just as it spins up. This sudden load causes the battery voltage to drop for a fraction of a second. The sequence that we have is as follows:

  1. Sensor wakes up from a deep sleep.

  2. Sensor runs the code that turns on the power to the particle sensor.

  3. Supply voltage drops and triggers the brownout sensor which resets the ESP32.

  4. The ESP32 wakes up as from a brownout reset, not a deep sleep.

  5. Sensor runs the code that turns on the power again, but this time it doesn’t trigger the brownout sensor because the power supply has a little bit of residual power in it from the recent (failed) startup.

I’ve fixed the problem by turning off the brownout detector when I turn the power on. 

WRITE_PERI_REG(RTC_CNTL_BROWN_OUT_REG, 0); //disable brownout detector   

// turn on the power
digitalWrite(powerControlSettings.powerControlOutputPin, HIGH);

// let things power up
delay(500);

WRITE_PERI_REG(RTC_CNTL_BROWN_OUT_REG, 1); //enable brownout detector

This is the code that does the deed. The power is controlled by a pin that is lifted high to turn it on. So the program turns of the brownout detector, turns the power on, waits half a second for things to settle and then turns the brownout detector back on again.

I’m not sure whether to be proud of this code or not. But in the end I think I am. If you accuse me of masking a hardware problem with a bit of software then I’m going to plead guilty as charged. I could probably fix the hardware cause by adding a wacking great capacitor over the supply to stop the voltage dropping. But this might lead to other problems. And anyway, if you look at the programs in any of the devices that you use on a daily basis you will find bits of code like this. Little bits of behaviour that are only there because the hardware doesn’t work without them.

Oh, and as a bonus (and so I can find it again if I ever need it) here’s a chunk of C that prints out the reset reason for an ESP32.

void printBootReason()
{
    esp_reset_reason_t reset_reason = esp_reset_reason();

    switch (reset_reason)
    {
    case ESP_RST_UNKNOWN:    Serial.println("Reset reason can not be determined"); break;
    case ESP_RST_POWERON:    Serial.println("Reset due to power-on event"); break;
    case ESP_RST_EXT:        Serial.println("Reset by external pin (not applicable for ESP32)"); break;
    case ESP_RST_SW:         Serial.println("Software reset via esp_restart"); break;
    case ESP_RST_PANIC:      Serial.println("Software reset due to exception/panic"); break;
    case ESP_RST_INT_WDT:    Serial.println("Reset (software or hardware) due to interrupt watchdog"); break;
    case ESP_RST_TASK_WDT:   Serial.println("Reset due to task watchdog"); break;
    case ESP_RST_WDT:        Serial.println("Reset due to other watchdogs"); break;
    case ESP_RST_DEEPSLEEP:  Serial.println("Reset after exiting deep sleep mode"); break;
    case ESP_RST_BROWNOUT:   Serial.println("Brownout reset (software or hardware)"); break;
    case ESP_RST_SDIO:       Serial.println("Reset over SDIO"); break;
    }

    if (reset_reason == ESP_RST_DEEPSLEEP)
    {
        esp_sleep_wakeup_cause_t wakeup_reason = esp_sleep_get_wakeup_cause();

        switch(wakeup_reason)
        { 
            case ESP_SLEEP_WAKEUP_UNDEFINED:    Serial.println("In case of deep sleep: reset was not caused by exit from deep sleep"); break;
            case ESP_SLEEP_WAKEUP_ALL:          Serial.println("Not a wakeup cause: used to disable all wakeup sources with esp_sleep_disable_wakeup_source"); break;
            case ESP_SLEEP_WAKEUP_EXT0:         Serial.println("Wakeup caused by external signal using RTC_IO"); break;
            case ESP_SLEEP_WAKEUP_EXT1:         Serial.println("Wakeup caused by external signal using RTC_CNTL"); break;
            case ESP_SLEEP_WAKEUP_TIMER:        Serial.println("Wakeup caused by timer"); break;
            case ESP_SLEEP_WAKEUP_TOUCHPAD:     Serial.println("Wakeup caused by touchpad"); break;
            case ESP_SLEEP_WAKEUP_ULP:          Serial.println("Wakeup caused by ULP program"); break;
            case ESP_SLEEP_WAKEUP_GPIO:         Serial.println("Wakeup caused by GPIO (light sleep only)"); break;
            case ESP_SLEEP_WAKEUP_UART:         Serial.println("Wakeup caused by UART (light sleep only)"); break;
        }
    }
}

You’re welcome.

Recursive purchasing

/

I was in HMV today and they had a couple of books that I really fancied. It turns out that reduced “with any purchase” works with another book that is also reduced “with any purchase”.

Oh, and the “Damn Fine Cherry Pie” book is excellent. It is a cookbook based on “Twin Peaks”. It has a whole bunch of very unhealthy but totally awesome looking recipes, along with dressing tips for the perfect Twin Peaks gathering and even some origami. Amazing value at less than three quid.

LMIC Frame Counter Problem

/

This is a fairly exotic post, in that I doubt that many readers will be concerned how they can maintain the frame count of LoRa packets sent using the LMIC library when a device goes into deep sleep. However, I’m putting it here so that in six months time, when I probably need to do this again, I can just search the internets and find this article.

A LoRa application maintains a frame count for each connected device. This is a security measure. Any frames that that the application receives with a frame count that is lower than the highest frame count seen so far will be rejected by the application. You can turn off this frame count checking for a device, but it is not advised because it makes things a bit less secure. I’ve turned it off for my devices for now, which meant that the frame count just increases when the device is running and goes back to 0 if the device is reset.

This is kind of OK by me. I’m not overly concerned with security issues at this level. However, when I started using deep sleep mode I found that every frame that was sent had a frame counter of 0, and I really didn’t like that. The problem is caused by the way that the device is completely restarted between each transmission. This restarts the LMIC library each time, setting the frame count to 0 for every frame.

It turns out that a program can reset the LMIC frame count value by accessing a member of the LMIC object. All my program needs to do is create a variable in the RTC memory to hold the current frame count:

RTC_DATA_ATTR u4_t lmicSeqNumber = 0;

The program can then store the frame count in this variable after each LoRa message has been transmitted:

lmicSeqNumber = LMIC.seqnoUp;

Now, during the reset process after a deep sleep I can put the frame count back:

LMIC.seqnoUp = lmicSeqNumber;

I’ve tested this and it seems to work fine. The frame counter is retained when the device goes to sleep. Of course if I turn the device off the frame counter resets back to 0. I could fix this by storing the frame count in EEPROM storage but I’m not too keen on doing this because I’d have to update the value after each LoRa message and might lead to lots of writes which might “wear out” the EEPROM storage.