Logik LBFANX12 electric oven not heating up

Got a Logik LBFANX12 electric oven that’s not heating up? We did. One minute it was working fine, next minute we could hear the fan but the light didn’t work and non of the heat settings would create any heat.

Not much good an oven that doesn’t get hot.

In fact that last time it was working the temperature light was flickering. Oven’s probably shouldn’t do that.

The surprising thing is our Logik LBFANX12 was only 18 months old. Admittedly it was the cheapest in the store at about £120 but surely it should last longer?

As the fan was working I knew it couldn’t be a fuse so after unplugging it and making sure it was safe popped off the top to take a peek.

Straight away I saw this floating around. Surely that should be connected or inside something?

Logik LBFANX12 switch part

Looks like a switch part, so took a closer look at the main function selector switch. This is the switch that switches the various elements and fans on and off. That last connector looks a bit suspect.

IMG_3843

A closer look shows the last connector, that turned out to be the main link to the heating elements, was completed toasted.

IMG_3843

Luckily after a quick scan of the internet I found a replacement and 2 days later it was all fixed but I’m not sure how long it will last. After all this simple mechanical switch is going to be carrying a massive amount of current when switched on. Each time it switches tiny arcs will occur at the contacts, and this arcing will oxidise and fatigue the metal. Might be wiser to get an electric oven with electronic switching next time. Electronic switching means no moving parts and they can use tricks like soft starting to provide switching that will last far longer.

I guess you get what you pay for!

Smoking calculator to show cost of smoking to your health and wealth

A friend of mine recently asked me for my help on adding a spreadsheet to his webpage. I thought it might be a matter of extracting some formatted data into a HTML table but it turned out to be something far more interesting and worthwhile.

He had done research into the costs of smoking and created formula to show the costs of smoking without asking too many questions.

Here’s a preview of the smoking calculator app that allow you to set sliders to show how much smoking can damage both health and bank balance. The figures are compelling.

And the reason to develop this? Well he’s a hypnotherapist and helps people overcome difficulties they are facing purely by getting them to understand their issues and getting them to realise ways they can resolve while the mind is in a receptive meditative state.

It is not brainwashing. As the patient is helping themselves they will only act on actions that make sense. Any suggestion too drastic is unlikely to take effect.

One particular area he is finding effective is in helping people who want to quit smoking. Many people find it difficult to stop so hypnotherapy is an effective way to help people quit. However my friend wanted to present people wanting to quit with some hard facts to help them motivate themselves. From this research he developed a simple spreadsheet that accepted basic facts about the patient and presented them with the cost of smoking in the form of both financial cost and cost to health. This was handy to present to clients in sessions to encourage the urge to quit but he wanted in available online so his clients could use the app at any time.

I first put together a bit of basic JavaScript to process form input as you type to produce the figures. It worked quite nicely but lacked that kind of polish we are used to these days on the web.

He originally asked about the possibility of using sliders that are found on price comparison sites. Now the maths side was sorted I thought I should swap them in. I looked at Html5 native sliders but decided browser comparably would be too much of a headache. Plus I always aim for everything I do these days to look good on mobile so I decided to look for a library option. A few google searches later I found myself looking at jQuery mobile demos which ticked all the boxes.
The sliders worked and look good both on desktop and mobile. The formula was plugged in to respond immediately on any change.

It’s a nice little mini app but I doubt it will help on it’s own. If you want support quitting smoking in the Sheffield area with hypnotherapy give Dave a call. He’s done much research and as you will see on his site is something he is very passionate about.

Visualize or visualise?

visualizeI tried to do the right thing on some recent posts about Audiospex, which represents an audio signal on an iPhone/iPad screen.

The word I used was “visualise”, which according to a quick search was the correct (UK) english spelling. I’m not American, so wanted to keep real to my roots.

This assumption is, as it turns out, a bit wrong.

As mentioned on wikipedia the ‘ise’ suffix is French in origin. Here it states that the Oxford English Dictionary recommends ‘ize’.

The actual fact is the word visualise and visualize are both correct, but visualise is not widely recognised in the US.

Definitions in wiki’s and blogs is one thing, hard facts is another.

So what does google think? Here’s a google trends chart of the 2 words:

Fairly conclusive!

From this I’ve just updated my text descriptions for the app to use visualize. It’s fine. It’s popular, correct and valid worldwide!

Engineers need to keep in time too!

metronome

Usually when we talk about keeping time in the studio its directed at musicians, mainly drummers. Drummers keep a band in time, or the drum machine. But should it just be the drummer in the studio keeping time? Well obviously all musicians need to keep time but recording studio engineers and producers should also keep time with their instruments.

Their instruments you say? Their instrument being the studio itself.

So the studio needs to keep time too? That isn’t as crazy as it first sounds. No studio professional will doubt delay units need to be set in time with the track with if the delay is long and prominent. Otherwise it will send the track out of time. So we have BPM (beats per minute) charts or a tap tempo on the delay unit to set the correct delay times.

Setting delay times

Say the track is 120BPM. That’s 2 beats per second. That’s one beat every 500ms. So set your delay time to 500ms and that delay on the track will fit. It will literally be on the beat. Want it slower? Double it to 1s. Quicker? Halve it to 250ms. All still in keeping in time with the track. Want something more advanced? Well if the track has a swing or triplet feel to it you can use multiples of 3. In this case 166, 333, 750 and 1500ms would be schmowkin’. Nice.

Here’s an example of a drum pattern at 120BPM, showing each beat is 500ms from the next. The lower pattern is delayed by 500ms exactly which lines up perfectly.

Drum part delayed using a BPM calculator offset

Most will use a DAW delay plugin where this is set automatically to the song tempo so you might think you don’t need to know the numbers, but there is much more in the studio that isn’t set automatically.

So what else is there other than delay units that have timing properties that can be set sympathetically to a tracks tempo?

Dynamics processors

Let’s start with noise gates. Three timing settings straight away to consider. Attack, hold and decay times. Gates are often useful on drums to reduce background spill that can muddy the sound. If the gate is open too long it won’t reduce the spill and provide any benefit; too quick and it will ruin the natural sound of the kit. We can use the same rules as the delay to keep it in time. For our 120BPM track maybe set hold to 100ms and decay to 400ms so the gate is closing clean on the beat. Of course your ears will tell you if this is working or not, but it’s a nice start. Or it could be used to give the kit an artificial staccato effect keeping in time with the music. The same rules apply. For a longer time double to one second, quicker halve it to 250ms.

Now let’s look at compressors. Rarely considered against music tempo but compressors have an attack and release time. Compressors are often found on the main mix to boost overall volume and generally make the mix sound bigger. Often this effect is desired without sounding artificial. But sometimes you want that compressor to pump, and the compressor becomes a key effect. This pumping needs to be kept in time so again we can use our timing rules to set the decay time on the compressor to be in time. 250ms or 500ms to really pump with an aggressive amount of compression, 1000ms or double with more gentle amounts for a more natural sound enhancement.

Reverb

Another decay time, another effect to kick into time. To much reverb bouncing around a track can clutter the mix so again tweak the times so the reverb tails away on each beat. Or if you are feeling adventurous set a pre delay in time with the track (say a 16th or 8th) for something more unusual.

Multi-fx

These units offer a great variety of effects or hybrid combinations. Chorus, Flanger, Phaser, Tremolo don’t have delay times but do have a parameter that can be set in time with a tracks tempo. That parameter is the LFO frequency which modulates the phase shift, volume or delay time of the unit. Or ‘wobble’ of the effect. As this is a frequency which will be set in hertz we cannot use delay time charts as we did before. We need to convert to cycles per second instead. Again consider our example song that has a tempo of 120BPM. That’s 2 beats per second. That’s one beat every 500ms. So to start off we want to know what frequency completes one cycle in 500ms, which is 2 cycles per second or 2Hz.

waveform_lfo_500ms

So again if we set the LFO rates to multiples of 2Hz we keep in time with the track. Say a tremolo effect is controlling volume of a guitar part. If the LFO rate is set to either 1, 2 or 4Hz as shown in the diagram the guitar will pulse in time with the tempo of the song. Of course you don’t have to stop at 4Hz – I think I would go for 8Hz here so there are 4 pulses of guitar to every beat.

Tools to help us

So if this is starting to make sense and sound useful, what tools are there to help? After all we want to focus on the creative side and not be crunching numbers.

Well this was the thinking behind the BPM Tap Tempo iPhone app. It is a BPM delay time calculator, LFO rate calculator and tap tempo recogniser all rolled into one handy app.

To start off hit the ‘tap’ button in time with the song. After a few seconds the tempo algorithm will display the BPM. The more taps you provide the more accurate the result will be, although usually about 10 seconds worth is enough.

Alternatively you can enter a tempo manually by holding down the ‘+’ or ‘-‘ buttons until the tempo reaches the desired rate.

While this is all happening a table of delay and LFO frequencies is displayed for a range of note durations so you can instantly see delay times or LFO rates you can use. If the song does not suit a straight 4/4 timing tap the mode button to modify the rates to produce values for triplet or dotted times.

Enter these values into your effect unit and you are done. If you have an iOS device you can find a link to the app using the App Store link.

Some might say to all this you should use your ears and trust them rather than tools – and they would be absolutely right. However it’s often good to have a starting point that you can rely on to set quickly without having to distract from the matter at hand – music – and that’s where tools come in.

Using swift to calculate Pi to an arbitrary amount of digits

piOk, first up, the Audiodog blog has moved!

The really nice people that run Pi blogs invited me over with the offer of a platform to knowledge share and learn in multiple languages, amongst a growing family of blogs. So you could in the future see versions of these posts in Spanish, Polish, etc? Nice!

Hmmm, so what should the first post on the new Pi blogs site be? How better to start off than investigating how to compute Pi to a large amount of digits using Swift? I’ve often wondered how Pi can be calculated and it sounds like an interesting exercise.

I’m not interested in the fastest algorithm or breaking any records (no super computers in my house) but it will be interesting how to adapt an algorithm to compute beyond the precision limitations of the CPU. A 64 bit CPU will only give us 18 digits of precision, which won’t be that impressive. Also Swift’s new language features might offer us some neat ways to develop and write the code, hopefully in a way that will lend itself to multithreading.

I’ll also employ TDD at every step to ensure we can refactor with safety as we go.

So to start off we need an algorithm. There are many to choose from, but John Machin’s formula from 1706 seems to be popular, easy to understand and can be used with techniques to compute to large amount of digits:

π/4 = 4·arctan(1⁄5) – arctan(1⁄239)

Taking baby steps, let’s test this

It passes, so are we done? Well….no. The atan function returns a double so that will only give us a limited amount of decimal places. So we need to next work out how to create our own arctan function, which we can then adapt to use a custom number type that will cope with large precision numbers.

Time to look at the Taylor Series. This is an infinite series that returns the result for our arctan function. As it is an infinite series, that means the longer we go on the more accuracy we get, perfect for our Pi quest. If we calculate arctan to the required decimal places, we can get Pi using the original Machin formula.

arctan(x) = x – x3⁄3 + x5⁄5 – x7⁄7 + x9/9 ………….

As infinity seems like a long time, lets just test with 5 steps.

Another success. So now things get interesting. We know the algorithm works and can scale but it’s the Double number type we already know is holding us back from creating enough Pi digits to fill our screen. We have to create a new number type and use it in the Taylor and Machin algorithms.

Creating a new number type that works with all operators and functions is not going to be trivial. So let’s try and cut some corners. Firstly the algorithm is going to converge on the value of Pi, so the numbers involved will always be less than Pi. So our number type only needs to handle small. Next with a bit of tweaking to the maths we can ensure this new number type (lets call it a super number) will only have to perform the following operations:

  • be multiplied by an integer
  • be divided by an integer
  • add a super number to another super number
  • subtract a super number from another super number

We have two strategies to implement this super number – store digits as multiple base 10 digits or to store the number in binary as multiple binary words. Although it’s not at all optimal in the past I’ve implemented a multiple base 10 digit strategy to create a ‘BigInt’ class for handling very large integers. To handle 1000 digit integers it creates an array of 1000 integers, where each integer represents a single digit. To perform addition, subtraction, division and multiplication it uses the basic methods learnt at school. All good to code, but not very efficient either for storage or making use of the CPU. The main advantage is the structure requires no conversion to read in base 10, just peak at the array or joining the entire array into a string is trivial.

For our Pi calculation the value only needs to be read once, when we have read enough of the Taylor sequence to get the required accuracy. So this technique will not win much there, and performing arithmetic with single digits is going to be slowwwwww.

So we will look at the big binary approach. To simplify as we know the numbers will never exceed pi we do not have to implement floating point, where the point can move to accomodate both small numbers and large. Instead we will implement a fixed point number with a fixed amount of bits to represent the integer part and another fixed amount of bits to represent the digits to the right of the floating point.

Consider 4 bits for integer and 4 bits for the fractional part:

8 4 2 1 . 1/2 1/4 1/8 1/16

or in decimal

8 4 2 1 . 0.5 0.25 0.125 0.0625

So, to represent 12.75 would be

8 4 2 1 . 0.5 0.25 0.125 0.0625
1 1 0 0 . 1 1 0 0

Or 5.625 would be

8 4 2 1 . 0.5 0.25 0.125 0.0625
0 1 0 1 . 1 0 1 0

This takes a bit of getting used to, as the fractional part does not map directly back to decimal. It’s storing as a combination of binary fractions. For example 0.123 cannot be represented using the 8 bits shown above. Instead it requires many more bits which might be an approximation rather than the exact figure. However it is a true binary representation so when we implement the arithmetic methods they will follow standard operations that are CPU friendly. In other words fast and efficient!

To simplify the binary arithmetic operations we’ll store the bits in 32 bit unsigned integers. But how many do we need? How much resolution will 16 bits give us?

1/216 = 0.00001525878906

Nearly 5 places.

And 32?

1/232 = 0.00000000023283

Nearly 10

We can approximate each 32 bits will give us at least 9 decimal places of precision. In fact a bit more calculation shows it will give us around 9.6 places. So if we want Pi to 100 decimal places the number of 32 bit words we need is

100 / 9.6 = 11 (rounding up)

Plus one more to handle the integer part.

So that’s the strategy. To prevent this blog post from turning into war and peace the complete XCode project including the tests can be found here which has the fixed number class, a formatter to convert it’s value to decimal and a taylor sequence generator to implement the arctan function.

github link

And here’s the payoff, to 1000 digits:

Computed in 0.3 seconds. Not too shabby!

What would be interesting now would be using the tools in XCode to look at any obvious ways to improve performance, and how to split the computation onto multiple threads to make use of multiple CPU’s. But that will have to wait for another post, I’m off now to get some Pi!