mktime() always uses local time zone and converts from UTC

If you’re working with UTC times, you may be upset to find that mktime() always converts using your local time zone thus wrecking your UTC times.  Instead of mktime() use:

  • Linux/Posix: timegm()
  • Windows: _mkgmtime()

Estimate Solar Azimuth and Elevation given GPS position and time.

C++ code to estimate Solar Azimuth and Elevation given GPS position and time.

For reasons that I won’t go into here I found it necessary to estimate Solar Azimuth and Elevation given GPS position and time.

Now there is quite a bit of information on how to this on the old inter-web, none of it could be described as being ‘easy’, and most methods use the ‘equation of time’ and require you to know your current time zone in order to to calculate Local Solar Time (LST) so that you can then calculate the current hour angle.

However dynamically determining which time zone you’re in is very difficult, most approaches involve using a web API – but what can you do if you have no internet connection?

Lucky I found some Mathlab code written by Darin C. Koblick which calculates Solar Azimuth and Elevation using just latitude, longitude, UTC time and altitude. It models the Sun orbiting the Earth and does not require to know your time zone! It seems to work very well and I am very happy with the results so far (thanks Darin!)

I ported the code over to C++, trying to change as little from the original Mathlab code as possible, I have included the code here, please note the license text at the end.

For example, to estimate Azimuth and Elevation for Lat/Lon 52.975/-6.0494 at sea level for the current time:

And, here is the C++ code for SolarAzEl():

Creating time_t value from a UTC date and time in C

Programming with time is difficult and error prone, for this reason I usually try to keep things in UTC so that I don’t have to worry about time zones and daylight saving offsets etc.

When in C++ I mostly use the boost::ptime library but I was surprised recently about tricky it seemed to be to initialise a time_t value for an arbitrary UTC time just using the standard C/C++ libs. We can’t use mktime() as it will figure out which time zone you’re in and assume that the time values you have passed refer to this zone, it will also apply daylight saving offsets.

Anyway to cut a long story short there are no standard functions in the C lib for this, instead your either have to use the posix timegm() function on Unix-like systems and _mkgmtime() on windows systems.

Here is an example, lets say we want to initialise a time_t value for this UTC date/time: 01/10/2020 10:16:03 (10th. Jan 2020)

That seems to do the trick, although I am astounded that this isn’t covered by the standard lib. To achieve the same using just the standard lib it seems you have to either hack around with the timezone env. variable before calling mktime() or assume you know how the time_t val is constructed and build your own timegm() function…

Speed up Encoding of JPEG images on Embedded System

Q: How can I speed up encoding & decoding of JPEG images on my embedded system?

A: Use libjpeg-turbo!

If you are encoding JPEG images from code on your embedded system then chances are you are using libjpeg either directly or indirectly. libjpeg is the standard JPEG implementation, and as properly JPEGing images is VERY hard everybody just uses this library. For example, if you save an image from OpenCV, it will use libjpeg under the hood.

libjpeg concentrates on getting the encoding and decoding correct, it doesn’t worry too much about speed or optimisation and so can appear slow, especially on embedded systems.

libjpeg-turbo is a drop in replacement for libjpeg, it supports the exact same API and uses the Intel and ARM Neon SIMD instructions to greatly increase the speed of encoding and decoding.

So next time you are struggling with JPEG speed, don’t listen to those who may mutter insane things about ‘using the GPU’ or some such rubbish, just check out libjpeg-turbo instead, it may well just do the trick, especially if you can arrange to encode your images on more than one core simultaneously!

libjpeg example – encode JPEG to memory buffer instead of file

Q: How can I use libjpeg to encode directly to memory on my embedded system without using a file?

A: If you’re encoding images into JPEG on your ARM/Linux embedded platform then you’re most likely using libjpeg, and if you’re encoding quickly then you’re most likely using its drop-in replacement libjpeg-turbo!

Most of the examples of how to use the libjpeg API show how to encode directly to a file, but it’s also possible to use the API to encode to a memory buffer instead. This is handy if you want to transmit the JPEG via MQTT or something and don’t actually need a JPEG file – you can avoid the overhead of writing to your flash filesystem and having to read the data from it before sending.

Of course, one easy way of achieving this if your embedded system has a RAM disk (as a lot of ARM/Linux based systems will) is to just get libjpeg to encode to file on the RAM disk, in this way you can avoid writing to flash, however you will still have to open the file and read in all of the data into a buffer afterwards.

The trick to getting libjpeg to encode directly to  memory is make a call to jpeg_mem_dest() (instead of to jpeg_stdio_dest() for a file), this allows the caller to specify an output buffer for the jpeg data (as well as its size).

You can either supply a pointer to a buffer, or if you pass NULL, the library will allocate a buffer for you – either way, you must free() the output buffer once you are finished with it!

Some things to note are:

  • You can pass in a pointer to a buffer that you have already malloc()’ed
  • If you pass in NULL, the lib will allocate a buffer for you.
  • If the buffer that you specify (or that the lib automatically malloced()’ed) turns out to be too small to hold the JPEG data then the lib will free() the buffer and malloc() a new one (this will probably also involve a memory copy).
  • After encoding the size variable will contain the number of JPEG bytes in the output buffer (i.e. it no longer contains the size of the buffer used!)
  • If you want to re-use the same buffer for each encode, then just pass in the same buffer pointer each time with it’s original size and don’t free() it after encoding.

Here is an example of a c++ function that encodes to memory, it uses a buffer that’s allocated by the library:

The we can use this function to encode an 8bit image like this:

Get the Subversion (SVN) URL for a file using Tortoise SVN?

How can I get the Subversion (SVN) URL for a single file using Tortoise SVN?

If you’re still rocking a venerable Subversion (SVN) repository to keep all of your software safe, then Tortoise SVN is a great user-interface to all of the SVN delights,  but how can you easily retrieve or copy an SVN URL to a single file in the repo?  I find that the easiest way to get an SVN URL to a folder is to right-click on the local folder and choose the ‘Repo-browser’ menu option, when the browser shows, the URL can be easily copied from the URL text box at the top of the browser screen.


Now, to get the URL for an individual file, just click on the file within the Repo-browser and it’s URL will be displayed in the URL box!


Get URL for single file in SVN


From here you can copy and paste to the heart’s content!

Fire-And-Forget wrapper for sending simple UDP data using boost::asio libraries

So I had a problem, as part of an embedded software system I was working on I needed to periodically send some GPS information via UDP datagrams to other devices on the network – really simple stuff, transmit a string to an IP address on a given port, Fire And Forget, send a string from here to there – end of story!

Now my normal port of call these days for networking in C++ is to reach for the boost::asio libs, as mentioned here, this library is very powerful and flexible and can handle a huge number of different networking scenarios.

All well and good, but sometimes I wish that I could just call a simple function and not have to remember or worry about all of boost stuff as it can be a proper head-wreck and there’s a lot of typing as the namespaces are so long! Python has me really spoiled, it makes so many things simple and easy to use!

So I wrote a little C++ wrapper class that just has 1 function called send() that can send a string or the contents of a binary buffer, the class is called: boost_udp_send_faf (faf stands for Fire-and-Forget!).

It is a very basic wrapper around the boost libs and only handles very simple transmission use-cases, but these use-cases probably cover about 80% of my UDP transmission needs!

To use the class for a single Fire-and-Forget send:

This sends the message to on port 8861.

If your program needs send multiple datagrams, then we can keep the socket open and reuse the end-point like this:

The socket will remain open until the ‘sender’ object goes out of scope.

It’s probably best to add exception handling to your calls as they can fail for lots of reasons and as ever networking is very flaky & unpredictable.

This will also ensure that the socket is closed once the message is sent as the object will go out of scope when execution leaves the try block.

The code for boost_udp_send_faf can be found in this repo, but I have in-lined it below as well:

Using ‘Mod’ on (small) Embedded Systems while Avoiding Time Penalties

The Mod/Modulo (% in C) operator is incredibly useful in many situations, it calculates the remainder from an integer division, for example 10 Mod 3 = 1 (10 Div 3 = 3, 3 * 3 = 9, 10 – 9 = 1).

Although you can happily call the % operator from your embedded C program it is important to be aware that it is typically implemented using integer division and multiplication, which is fine if your embedded system support these in hardware, if not they will be implemented in software sometimes resulting in huge time penalties (for example, on many PIC chips).

Often this won’t be a problem, but if you’re programming a real-time system these delays can be devastating! A big sting-in-the-tail from an innocent looking operator %

So what can be done:

a.) Avoid using % in your time-sensitive code, perhaps use running sums and remainders instead.

b.) Use a power-of-2 in your Mod call instead.

If the value of the right-hand operator isn’t crucial and both arguments are positive, then switching to a power of 2 will make it much easier and faster to calculate, a power-of-2 Mod can be calculated with an AND instruction.

Your compiler should figure out that you are using a power-of-2 and automatically carry out the optimisation, but to be safe, check the output assembly code. If it hasn’t optimised then you can replace your code with a & (b – 1)

Python Monty Hall Problem Simulation

The Monty Hall Problem is a very (to me at least) counter-intuitive probability mind-experiment which contorts my brain and fascinates me at the same time, I have been mulling it over the last few weeks and wanted to write a little simulator to see if the numbers come out as predicted (if not expected, and indeed they do!). I can just about understand the probabilistic arguments, but I still find it very confusing, as soon as I think that I grok it – my ‘understanding’ disappears into the night! I am used to being this bamboozled when reading about quantum mechanics or something, but I find it fascinating that such an apparently simple problem can be so deceptively deep!


There are 3 doors, behind one lies a car, while behind the other two are goats. A player chooses a door at random. Monty opens one of the other doors to show that there is a goat behind it. Monty then asks the player if they would like to stick with their original choice of door or switch to the other un-opened door.

If the player sticks with their door then their chance of winning the car should be 1/3. If the player switches door then their chances of winning the car increases to 2/3!!!

If you are having problems understanding the outcome, I find it helps to imagine that there are a million doors rather than 3. After you choose your door (1/1,000,000 chance of hiding the car) Monty opens up 999,998 doors that hide goats to leave one door still closed. Now which door do you think is most likely to hide the car? The one you choose, or the one that Monty avoided opening while he opened all 999,998 other doors?! It seems obvious to me that the other door that Monty left un-opened has a massively higher chance of hiding the car than your original choice! As N reduces to 3 this ‘obviousness’ reduces greatly however! This simulator allows you to experiment with more then 3 doors for this reason.

For more info:

This program is an experimental simulator to see what numbers we get when the player decides to stick or switch. It can be found on GitHub.

boost::split – warning C4996: ‘std::copy::_Unchecked_iterators::_Deprecate’: Call to ‘std::copy’ with parameters that may be unsafe

If you’re using the very handy boost::split() on Visual Studio, then you may run into the following annoying warning:

warning C4996: ‘std::copy::_Unchecked_iterators::_Deprecate’: Call to ‘std::copy’ with parameters that may be unsafe – this call relies on the caller to check that the passed values are correct. To disable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ ‘Checked Iterators’

It’s a big warning that rightly litters the compiler’s output!!

Everything’s OK, it’s just VS whinging about std::copy() being called with pointers. As the warning mentions, you can disable the warnings by defining _SCL_SECURE_NO_WARNINGS, its probably best to define it only for the affected files and not your whole project however!

Another way is to explicitly instruct that warning 4996 be ignored in the code like this:

More Info