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.

ESP32 Retaining timing over deep sleep

/

In the last post we saw how easy it is to make an ESP32 processor sleep for a particular time. However, we also noticed that at the end of the sleep the processor is reset and all the variables in the program are reset. This is difficult if you want to keep track of time in your application. However, it is possible to get around this limitation by storing a time value in memory that is retained during sleep.

RTC_DATA_ATTR unsigned long millisOffset=0;

The statement above declares a variable called millisOffset. The attribute RTC_DATA_ATTR tells the compiler that the variable should be stored in the real time clock data area. This is a small area of storage in the ESP32 processor that is part of the Real Time Clock. This means that the value will be set to zero when the ESP32 first powers up but will retain its value after a deep sleep.

We can use this variable to create an offsetMillis function that gives a millisecond count which is adjusted by the offset:

unsigned long offsetMillis()
{
    return millis() + millisOffset;
}

Our program is going to call this function when it wants to know how much time has elapsed since the application was started. The final part of the solution is to update the offset each time our processor is put to sleep.

void sleepSensor(unsigned long sleepMillis)
{
    esp_sleep_enable_timer_wakeup(sleepMillis * uS_TO_mS_FACTOR);

    millisOffset = offsetMillis() + sleepMillis;

    esp_deep_sleep_start();
}

Now, when our application goes to sleep it records the value that the millisecond timer should have when the device wakes from sleep. This value is retained in non-volatile memory and used to offset time values when the ESP32 restarts. 

#include <Arduino.h>

RTC_DATA_ATTR unsigned long millisOffset = 0;

unsigned long offsetMillis()
{
    return millis() + millisOffset;
}

#define uS_TO_mS_FACTOR 1000  /* Conversion factor for micro seconds to miliseconds */

void sleepSensor(unsigned long sleepMillis)
{
    esp_sleep_enable_timer_wakeup(sleepMillis * uS_TO_mS_FACTOR);

    millisOffset = offsetMillis() + sleepMillis;

    esp_deep_sleep_start();
}

void printTime()
{
    unsigned long seconds, sec, min, hrs;

    seconds = offsetMillis() / 1000;

    sec = seconds % 60;
    seconds /= 60;
    min = seconds % 60;    
    seconds /= 60;
    hrs = seconds % 24;

    Serial.printf("%02d:%02d:%02d\n", hrs, min, sec);
}


void setup() {
    Serial.begin(115200);
    printTime();
    sleepSensor(30000);
}

void loop() {
}

The complete program above shows how it all fits together. The program sleeps the device for 30 seconds but the time value is maintained after each reset. Note that the loop function is empty because the program never gets this far. The repeating behaviour of the program is caused by the reset after each sleep.

I was quite surprised just how poor the time keeping is when I ran this program. This is because the timing is not provided by a crystal but by an oscillator which is fitted onto the ESP32 chip. The timing can be out by a second or so over short intervals. Try timing the above program to see what I mean.

The millis function in the Arduino library returns an unsigned long integer value that holds the number of milliseconds since a device was turned on. The program above works by adding an offset to this millis value which reflects how long the device has been put to sleep. Of course, what with data storage in any computer being a finite size, there will come a point where the millis value will not fit in an unsigned long variable and so it will wrap round and go back to 0. This occurs after 4,294,967,295 milliseconds or around 50 days. If your program does any kind of calculation with the timing values you will need to make sure that the wrap round doesn’t cause problems.

ESP32 Deep Sleep Mode

/

I'm very proud of the picture above. It shows that I'm getting around 0.1ma current consumption on our new environmental sensor when it is in deep sleep mode.

It's very easy to put an ESP 32 into deep sleep mode. This is the code that I'm using:

#define uS_TO_mS_FACTOR 1000  /* Conversion factor for micro seconds to miliseconds */

void sleepSensor(unsigned long sleepMillis)
{
    esp_sleep_enable_timer_wakeup(sleepMillis * uS_TO_mS_FACTOR);

    esp_deep_sleep_start();
}

The sleepSensor function is called with a parameter that gives the number of milliseconds for the sleep duration. It sets up a timer wakeup for that duration and then starts the deep sleep process.

The functions esp_sleep_enable_timer_wakeup and esp_deep_sleep_start are in the ESP32 library that is added to your program when you select a device based on the ESP32 processor. If you want to use them you have to include the Arduiono libraries by putting this statement at the start of your program:

#include <Arduino.h>

When the ESP32 "wakes up" at the end of the sleep the processor is restarted. The timing of the sleep duration is not particularly accurate, certainly not as accurate as the internal clock you get when the ESP 32 is running. You can make the wakeup trigger a button press rather than a timeout if you wish.

When an ESP 32 is restarted after a sleep all the varaibles are re-initialised. However, there is a way that your application can preserve some variable values in Real Time Clock memory. More of this later.

Arduino debugging 2: Using #define to manage debugging output

/

Last time, in the post here we discovered how the __FILE__ and __LINE__ symbols make it possible for a program to print out a tracing information. This can be very useful if, as is the case with Arduino development, there is no easy way to step through your code. The problem that we now have is that we need to add calls to the trace method, and we will have to remove them later.

show_location(__FILE__, __LINE__);

However, there is another feature of the C compiler that we can use which makes it very easy to add and remove debugging statements. This feature is provided by the C compiler pre-processor. The pre-processor, as the name implies, is the part of the compiler that takes in the source code file and can do some processing on the program text. Commands to the pre-processor are pre-ceded by the # character.

One pre-processor directive (something we use to tell the pre-processor what to do) is #define, which defines a symbol. If we get bored with typing lots of digits of PI (3.141592654) we can use #define to tell the pre-processor to do the hard work for us.

#define PI 3.141592654

Now, whenever the pre-processor sees the symbol PI it will replace it with the digit sequence. So, consider if my program contained the following statement (assuming I have variables called circ and rad declared somewhere):

circ = rad * 2 * PI;

The symbol PI is replaced by the number sequence that it was defined with, so that the circumference of the circle is calculated using the value of PI as defined.

The #define pre-processor directive is really powerful, and should probably come with some warnings. Here are a few:

  • There is nothing to stop a silly programmer re-defining the value of the PI symbol at any point in your program. They could define it as 4 which would cause your program to produce the wrong results, or they could define it as “chicken” which would cause your program to produce some very interesting compilation errors as your program was now trying to use the word “chicken” in arithmetic statements.

  • The defined symbol must be an identifier that “makes sense” in C. There is a convention that #defined symbols are given names that are in all capitals, with words separated by underscore so that they stand out in your code

  • The pre-processor does not replace defined symbols inside strings. In other words the statement:

    Serial.println(“Have some PI”);

    - just prints the message “Have some PI”. However, you can use #define to create symbols that are complete strings:

    #define WELCOME_MESSAGE “Hello”

    I can now write:

    Serial.println(WELCOME_MESSAGE);

  • I regard the #define statement as strong magic. I do all my #defines in one place in each source file and I only use them sparingly.

Anyhoo, back to how to use #define to make our lives easier. We can save typing by replacing the call of the show_location with #define symbol:

#define TRACE show_location(__FILE__, __LINE__)

Now, when I want to produce trace output to show where the program has reached I can just use the TRACE statement:

TRACE ;

The pre-processor will extend this and enter the text of a call of the show_location method.

It gets better. If I want to turn off all the trace statements I can just remove the TRACE symbol from my program by defining it as an empty string:

#define TRACE

This means that the pre-processor will now replace the symbol TRACE with nothing so that the trace statements are no longer present in the source of the code. A program can re-define a symbol as it is compiled, so you can enable and disable the trace behaviour in different parts of the code if you like.