Hacking an IKEA MOLGAN light

Posted by Alastair Bor | 2/17/2017 11:24:00 pm | | 0 comments »

The IKEA MOLGAN is a great little product to provide motion-detected path lighting in the house at night.

TL;DR version: To save battery life, you can make the MOLGAN more sensitive to light by adding 140KOhms of resistance in parallel to the light sensor. This will cause the MOLGAN to only trigger when it's much darker than the stock setting.

I have a bunch of these mounted on the ceiling outside the bedrooms and in the bathrooms so that at night they just come on automatically with a dim enough light not to get your brain out of sleep mode but bright enough that you can see. Because they are battery-powered you can mount them anywhere and they are cheap enough that you can buy a few of them.

My biggest complaint with them is that they take 3 AAA batteries which don't provide much longevity. I use rechargeable batteries and they need to be recharged about every 3-4 weeks. They are light and motion activated which means that they only run when there is motion detected AND it's dark (see below re: IKEA's definition of "dark").

Increasing the longevity (time between recharges) could be accomplished either by
  1. Increasing the capacity of the batteries
  2. Reducing the time the light is running (draws about 80mA when running)
  3. Reducing the brightness of the light (so that it draws less than 80mA when lit)
  4. Decreasing the minimum ambient light trigger (currently triggers when not totally dark)
Increasing battery capacity is difficult to do without basically creating a new case for it. Using 3 AA batteries or even a single 16850 Li+ battery would require heavy physical modification of the case.

Reducing the run time with each trigger wouldn't gain much since the light runs for about 30 seconds per trigger and making it much shorter than that would be annoying.

Reducing the brightness could be an option, and it would be quite simple to remove one or more of the 5 LEDs on the circuit board. 

I opted to try to solve the "darkness" problem. IKEA's design means that it does not need to be absolutely pitch dark for the light to come on. This means that it often comes on unnecessarily when it's actually quite light inside (i.e. early morning, late afternoon). 
Opening up the MOLGAN is quite simple. You just pry the face (the part where the light comes out) off. It's lightly glued in and it's easy to put it back. You can pry it off with a flat-head screwdriver without even leaving a mark. When you do so, it looks something like this on the left.

What you are looking at are the 5 SMT LEDs around the edge of the board, the motion sensor in the middle and on the right edge there is a clear component that looks like a LED which is the light sensor.

If you remove two screws and unsolder the battery contacts you can remove the board and it looks like this on the other side.

Here you can see the BISS001 which is the chip in the middle of the board. It's a very common controller for battery-powered PIR controlled devices.

Importantly, the two pins next to the R2 label are the pins of the light sensor. The light sensor works like a variable resistor that varies by light. The more light, the less the resistance, the less light, the more the resistance. 

The trick is to change the range of the resistance of the light sensor so that "darkness" is triggered at a lower ambient light level.

If you remember from high school physics/electronics (or just find out by Googling around), it's very easy to reduce the resistance of a resistor by adding another resistor in parallel. 

The correct resistor size can be figured out in several ways - one is to mathematically solve it by using the BISS001 data sheet. Another one is to measure the light sensor resistance at the critical level of darkness and back-solve the correct resistor.

For me, the simplest was to just use trial-and-error with some resistors I had lying around.

To make it as simple as possible to find the correct resistance by trial-and-error I soldered some DuPont wire with female ends to the light sensor pins so that any resistor I add is in parallel.

With a very slight bit of case modding (just cutting back some plastic) you can fully re-mount the board and solder back the battery connectors. The next photo shows the MOLGAN back to fully functioning condition but with the addition of a "breakout" area to add additional resistors in parallel to the light sensor.

Playing around with some resistors I had lying around I quickly found that 130KOhm was about the lowest I could go where it would still trigger in total darkness. I went up to 140KOhm and that was quite reliable even in a room that wasn't pitch dark. Because I was just using parts that were lying around, to do 140KOhm I had 3 resistors (100K+20K+20K) Going up to 168KOhm was also quite acceptable and allowed me to use 2 resistors that I had lying around (100K+68K)

I then re-mounted the MOLGAN with the additional resistors on the ceiling to do a bit of testing and see that it was behaving as expected.

After a couple of days of testing, I was really happy with the new calibration for the darkness trigger and modified the rest of my MOLGANs with a more permanent mod.

And there you have it, with a 100KOhm and 68KOhm resistor in series added in parallel to the light sensor. By not triggering when still pretty light in the room, I'm hoping that the batteries will last longer before requiring a recharge.

For a particular room where I wanted the MOLGAN to come on only when it was very dark (since it got tons of false triggers from people walking past the open door) I went with the 140KOhm option which really cut down on the false triggers. With 140KOhm, the MOLGAN only comes on if you've entered the room and almost completely shut the door.

Bookmark and Share

Repairing a Boogie Board WT13087 (a.k.a. Jot 4.5 eWriter)

Posted by Alastair Bor | 1/29/2017 11:19:00 pm | | 0 comments »

During a recent trip to Costco I bought my daughter a Boogie Board WT13087 (Jot 4.5) by a company called Kent Displays as a bit of an impulse buy. The way they are packaged, you can test them out in the store and the one my daughter picked was working fine.
Within about a half hour of arriving home; however, the "erase" function stopped working. This is a fatal problem because it's the only way to erase the screen. The whole point of this device is that it can be re-erased many time.

I did a bit of hunting around the internet and clearly this is a problem that others have experienced. I figured that since you could use it in the store, the battery might have died from overuse by other customers playing with it and testing it out.

It's also very clear from Googling around that the battery is definitely not replaceable. The closest I could get to a successful YouTube video on this was here: https://www.youtube.com/watch?v=_k1lcq8LA5E - but alas this guy managed to ruin his Boogie Board in the process. The good news was that from the video, at least I could find out where the battery was. Instead of doing a full disassembly, I thought I would just target the battery.

I used a box cutter and snipper to expose the battery and I figured this would be an easy fix to replace. 

Lo and behold, the battery was fine, showing a full 3V... argh! Incidentally, it's a CR1620H. They definitely don't make it easily replaceable, but if it were just a battery issue, it's doable.
As it wasn't the battery, I continued opening it up to expose the circuit board. Maybe something was wrong there.

It actually wasn't too hard to expose the rest of the circuit board. The trick is not to let the plastic peel off the screen.
As you can see, the board is pretty simple with the power going in from the battery to an unidentified controller and a button to activate it all. The output of this board goes via two wires to another board at the bottom of the screen. I stuck my scope on the output wires to see what was going on when the button was pressed. 

As you can see, all the button does is to cause the circuit to produce 3 pulses. First a 36V pulse for ~150ms and then two ~150ms ~19V pulses with 250ms gaps in between each pulse. 

So that didn't get me any closer to solving the problem, but at least I knew the top board was doing something in response to a button press.
Using the box cutter, I went to expose the bottom board. This is where I made a stupid mistake. In the process of cutting open the plastic on the bottom, I cut the connection between the bottom circuit board and the screen. The bottom circuit board is completely passive, all it does is it connects the two layers of the screen to the positive and negative of the pulses from the top circuit board.

If that's all that it does, I figured that I could erase the board by sending 35V to the screen in a short burst followed by two more pulses.

Unfortunately, my power supply only goes up to 30V so I gave it a shot. I connected the power supply output to the two sections of the screen (there is a clear section that takes the negative and a black section that takes the positive).

Sure enough, it worked! Sending 30V to the screen erased it. See the video below for the full show. It turns out, you just need to send it 30V and it's not very sensitive to how long you do it for. Also, it doesn't really care about the 2 additional 19V pulses either.

So, in the end it had nothing to do with replacing the battery (although if that's what your problem is, then it's pretty easy to do). It's likely that due to some manufacturing defect, the connection between the screen and the bottom circuit board was flakey. I checked that the whole rest of the device (from the battery to the bottom circuit board) was fine. The screen itself is fine.

Now that I've "fixed" it, I have a slightly less portable version. The big lesson here is that if you are one of the many people who find that their display no longer erases, it might not be the battery. You might need to check for a good connection to the screen. This is located at the bottom (the side without the button). You could try pressing on various sections of the case to see if you can correct the bad connection.

Epilogue: I contacted Kent Displays and after a proving that I have a defective product (receipt and some photos) they sent me a new one free of charge. The new one they sent is a model WT13087B (note the B at the end). It's otherwise looks identical and after a few days it still works! See photo below of the old (right) and replacement one (left).

Bookmark and Share

A bit of "found music" from the 1960s

Posted by Alastair Bor | 8/27/2016 10:23:00 pm | | 0 comments »

I recently found this box of my Dad's old reel-to-reel audio tapes from the late 1950s to mid 1960s. They hadn't been stored particularly well and I doubted that I could yield anything interesting from them... I was wrong! The quality is actually amazing considering the circumstances. Some of it is incredibly precious commentary by relatives who are long gone, but there is also some music which I am posting here in case there is some interest in such recordings. These tapes are from Hungary so unsurprisingly the music is Hungarian. The tapes are predominantly popular music of the era. Click on on each clipping below to get the full audio of the tape associated with it. Enjoy!

Bookmark and Share

The QR Fortune Clock Concept

Posted by Alastair Bor | 6/25/2016 10:36:00 pm | | 0 comments »

QR clocks are funny in their banal use of technology - but ever since I built my first one I was wondering if there could be a better use for them. This video shows my QR Fortune Clock concept which is like a fortune cookie (you need to "unwrap" the QR code with a QR reader to find the fortune inside).
You basically fill an SD card with a text file that contains the quotes you are interested in and then every second it will randomly display the quote as a QR code. Using a cheap 128x64 OLED screen, the version 10 QR code is easily readable while providing space for a 395 character message as well as a human-readable time/date. The underlying code is running on an Arduino Mega (simply because I couldn't squeeze the code to fit onto something smaller and also because I had a spare one lying around).

If there is interest, I can provide more details about the hardware and software but essentially the clock is made from:

  • Arduino Mega 2560 - I needed the extra on-board SRAM to fit the code. Writing software is not my day job so I'm sure some smart people out there could shrink it down to fit on an Uno.
  • 1.3 inch 128x64 pixel white OLED module (this one uses an SH1106 / SSD1306 driver)
  • MicroSD module using the SPI bus.
  • MicroSD card (I had a 16gb one lying around, but this is way overkill)
  • KY-040 rotary encoder (to control the functions like time setting, file selection)
  • 10K pull-up resistor (for the pushbutton feature on the KY-040)
  • DS3231 high accuracy TCXO RTC module for timing
Apart from the standard built-in libraries, the sketch uses the following additional libraries:
  • U8glib to run the OLED display
  • DS3231 to drive the RTC module
I also use a heavily modified version of the code I found here to actually convert the text to a bitmap of a QR code.

This concept can be expanded to use a larger screen and the nice thing about it is that compared to having actual text scrolling past every second, this clock just sits on the desk quite inconspicuously until you want a bit of inspiration. I have created versions that use all sorts of different texts as the base. Some particularly interesting ones are a Unix Fortune File,  books from Project Gutenberg such as The Art of War, Walden, the Shakespearean Sonnets, the Analects of Confucius and Dante's Inferno. Of course your favourite translation of the bible or other religious text also works particularly well. Basically anything that neatly breaks down into < 400 character segments. 

Bookmark and Share

When I bought my 2010 Audi A3 (8P body style, also known as "2010 face lift") it came with the standard Audi Concert II head unit (Audi part # 8P0 035 186 S) and a dealer-installed Kufatec FISCON 36429 "Basic" Bluetooth adapter. From the outset I wasn't happy with this setup because the Bluetooth never worked properly throughout multiple phone changes (iPhone 3GS, 4, 4S, 5, etc.) and firmware updates. The volume was too loud and there seemed to be no way to lower it. Moreover, playing music over the Bluetooth sounded lousy - as if through an old crystal radio. (This is despite going back to the dealer numerous times, playing with the internal settings of the Kufatec and even using VCDS to try some internal Audi settings). When we recently moved house, our new driveway was extremely narrow, full of blind spots and required reversing in so I thought it would be time to replace the head unit with one that had a display for a reversing camera.

After doing some research on options, I decided to get a Pumpkin head unit to meet the following requirements:
  • Have a stock "look and feel" that would not ruin the aesthetics of the dashboard
  • Integrate with the steering wheel volume/channel/telephone controls
  • Provide improved Bluetooth compared to the Kufatec unit
  • Provide a screen for a reversing camera
  • Be installable without lots of cutting / soldering / drilling - basically "plug and play"
The TL;DR version of this post is that I am happy with the end result and the Pumpkin head unit meets all my requirements. It was a bit of a journey to get there, so for all the gory detail, read the full post.

1. Buying the initial parts
I bought this Pumpkin item on eBay which came with a free camera and free Australian maps for the GPS. While it came with a free camera, the camera wouldn't look "stock" so I bought this camera instead which was billed as a plug-in replacement for the number plate light. According to some back and forth e-mails with the vendor, the specific camera I needed was the Model 603 which would be an exact replacement for my number plate light. I based my decision partially on an installation video on YouTube that showed how easy it was to install this camera. I also bought some CT22AU01 radio removal keys to help remove the old head unit.

Now on to the installation and some of the issues I had to resolve...

2. Installation - Head Unit
The physical installation of the head unit was a relative breeze. With the radio removal key, you just remove the old head unit, unplug the Quadlock connector and basically plug it into the harness of the Pumpkin unit. 

Now you can turn it on and try it out... but not the radio yet.

2.1 Head Unit - Radio Antenna Fix
The first problem you will encounter is that the radio won't work because the Pumpkin antenna connector is DIN but the Audi uses a "Twin Fakra" connector. You will need to buy one of these adapters to interface the Audi antenna to the Pumpkin. This is pretty easy, but I wish that Pumpkin included one in the box. The Pumpkin has an unterminated wire called "ANT" (see below) which you need to connect to the +12V wire on the Fakra connector. It's puzzling that Pumpkin didn't pre-make the harness with this wire connected since they clearly have provision for it.

Now the radio will work through the front speakers, but there will be no audio at the rear speakers...

2.2 Head Unit - Rear Speaker Fix
My car came from the factory with an amplified set of rear speakers. The wiring needs to send +12V down to the amp that is located in the rear of the vehicle. The stock Pumpkin harness does not wire up this connection. It will need to be wired up yourself. Like the antenna power wire (mentioned above) there is a remote amp power wire that is unterminated on the Pumpkin. This wire is labeled "AMP-CON" per the photo above. Essentially, you need to connect it to Pin 13 of the Quadlock connector per this diagram. Once this is done, you will have audio coming out of the rear speakers. I don't understand why Pumpkin did not wire this into the harness in the first place.

2.3 Head Unit - Battery Consumption Fix
Everything was working fine with the head unit at this point but I noticed that it would not fully power off when I pulled the ignition key out. I put the Pumpkin to "sleep" (but not OFF) by pressing the power button and by the end of the week my car battery was flat. I sent a complaint e-mail to Pumpkin and they immediately responded with a note telling me to cut this red wire. Cutting that red wire makes the Pumpkin power down when the ignition key is switched off. This fixed the battery problem. 

At this point, the Pumpkin was installed and everything I needed was working reasonably well, although there are a few bugs to note:
  1. The 3G dongle that I bought from Pumpkin doesn't work very well. It connects to 3G but then after a few minutes of driving disconnects. Googling around, I discovered that the radio is manufactured by HuiFei and there is a forum that discusses issues with it. This is a known problem. Lots of interesting stuff to read about it here. 3G connectivity is not a key requirement for me, I mostly use the radio tethered to the WiFi personal hotspot of my phone.
  2. The software can be a bit "crashy" ... The core functions work fine (radio, DVD, reversing camera, etc.) but if you play around with some Android Apps you will find that they sometimes don't work as expected. Also, sometimes various apps crash for no reason. Again, this is a mild annoyance since these apps are not a key requirement but more for fun. 
  3. Since applying the "Battery Consumption Fix" (mentioned in point 2.3 above) the Pumpkin powers down every time I remove the key. This means that each new car trip requires the Pumpkin to boot up from scratch (unlike a car radio which is always instant-on). This can be annoying if you are making frequent small trips. I have wired up a switch to undo the "Battery Consumption Fix" (essentially a switch that can reconnect that cut wire) and when I am doing short trips I just leave that connected. It means that the radio only goes to sleep, but doesn't switch off. Hopefully I won't forget to leave this switch off at the end of the day or I'll have another dead battery.
  4. The radio doesn't quite fit in as flush as the factory radio does. The bottom bezel sticks out a bit despite my repeated attempts to "force it in" for the last mm or so. It's flush at the top and sides so I'll just live with it.
Now on to the reversing camera which was a bit more of an adventure than I bargained for. This is not Pumpkin's fault since I could have just used the free camera they supplied and not faced these problems.

3. Installation - Reversing Camera
I basically followed the instructions provided in this YouTube video. I made a small change to the installation by drilling a much smaller hole in the back of the light holder. This meant that I had to cut the cable (since the RCA jack wouldn't fit through the smaller hole) and then I reattached it after I fed the cable through. I ran the cable to the front of the car and plugged it into the Pumpkin and it worked straight away by just switching the ignition ON and putting the car in reverse. But I did have some problems.

3.1 Reversing Camera - Engine Running Fix 
The first problem I ran into is that the camera would work fine with the ignition switch in the ON position, but once I started the car it wouldn't work anymore. This reminded me of some old car stereo buzzing problems I used to have years ago which was fixed by a noise isolator. So I bought one of these and wired it in. This worked perfectly and now the camera worked exactly as intended. As a side note, this Response brand of noise isolator has lousy instructions. Their web instructions don't match with the paper instructions that they provided. Follow the wiring diagram above with the green wire going to the +12V of the car and the red wire going to the power input on the camera.

3.2 Reversing Camera - LED Light Polarity Fix
At this point the camera was working great, but the license plate light that it was integrated with did not light up! The LED light, unlike the incandescent light that it was replacing, cannot be put in any-which-way. There is a + and a - side and they need to be hooked up correctly. This picture shows the light working fine when providing +12V to the left contact. But it wouldn't work in the car which provided +12V on the right contact. I could prove this by crossing the wires like in this picture. I contacted the vendor on eBay and after showing them these pictures they went back into their inventory and found a camera module where the LED was wired the other way and sent it to me for free. This was good customer service, but I wonder if Audi wires their cars differently in Australia? Because Audi uses incandescent lights the polarity of this wiring doesn't matter, but it does with LEDs.

3.3 Reversing Camera - Light Bulb Warning / CANBUS Error Fix
Now that the LED was working with the replacement camera module the car would give a Light Bulb Failure Warning (a.k.a. CANBUS Error). Because the LED draws so much less power than the incandescent bulb, the engine computer thinks the bulb is burned out. This meant a very annoying beep every time the lights came on. The next goal was to fix the light bulb warning. After some Googling around, I found this product which basically puts a load on the line to fool the engine computer into thinking that the bulb is there. You can easily do this yourself by wiring a resistor in parallel with the LED, but this solution was nice in that it was plug-and-play with the correct connections at either end. I also replaced the bulb on the other side of the license plate with one of these so that the lighting would be even and to avoid drawing too much load with the resistor packs.

And here is how the final installation looks of the camera with fully working LED lights as well!

Overall I am happy with the result, but it was a bit more involved than I had hoped. It took several months of elapsed time to sort out all these problems so I hope this little blog post can fast-track a solution to these problems for others in the same situation.

Here is the final installation with the camera working and my daughter helping me to test it.

Bookmark and Share

An unexpected risk of using ReCaptcha

Posted by Alastair Bor | 7/09/2013 10:24:00 pm | , , | 1 comments »

We are all familiar with CAPTCHAs which are used by web sites to make sure that a user is human (and to hopefully hinder spammers).

Sometimes these images are computer generated, but often the images are from a service offered by Google called ReCAPTCHA which sources images from old books. This service can supply websites with images of words that optical character recognition software has been unable to read. These websites then present the images for humans to decipher as CAPTCHA words as part of their normal validation process. They then return the results to the reCAPTCHA service, which sends the results to the digitization projects. This sounds like a noble cause.

The old books that Google uses are unlikely to contain any offensive language - however the above graphic shows an interesting potential for confusion. This is an actual reCAPTCHA that I found in a Twitter post where someone berated a web site for having an offensive CAPTCHA. To most modern English speakers the first word looks like "goatfucker" which certainly wouldn't be a word I'd use in polite company.

As I noted above, however, the source of these words are old books... why would an old book have such an offensive word in it? 

In fact, the fifth letter of the word is a Long S (ſ) not a lower-case F (f). This means that the word is "goatſucker" which today would be written as "goatsucker" - which is a medium-sized nocturnal bird with long wings, short legs and very short bills. A photo of this innocuous bird appears to the right.

The Long S, according to Wikipedia, stopped being used in printed English by about the 1820s. Those of us who have seen old documents in History class at school or in Museums might recognise it from such famous documents as the U.S. Declaration of Independence and the Magna Carta.

There are probably other potentially confusing words like suckerfish.

The big question in my mind, though, is what is ReCaptcha expecting us to type? An 'f' or an 's' since I assume they don't want us to have to figure out how to put an 'ſ' in there.


Epilogue: A few days after writing this blog entry, I got the following ReCAPTCHA on another site (See image on left). I tried typing in "some" for the first word and it worked. I wasn't able to test out what would happen if I had put in "fome" instead. 

Bookmark and Share

Create QR Codes in Excel (or any Spreadsheet)

Posted by Alastair Bor | 3/09/2013 12:39:00 pm | | 13 comments »

For a little project I'm working on, I needed to understand how to generate QR codes. Being the Excel junkie that I am, I thought it would be easy to create a proof-of-concept entirely in Excel. As a challenge, I set a goal of doing this without using any Visual Basic or other scripting.

I will describe here the steps used to generate the code in Excel. Click here to download the Excel spreadsheet to follow along. You can also link to the Google Spreadsheet if you don't have Excel: http://bor.to/QRSheet

If you just want to generate the QR codes and not worry about the details of how it's done, just download the spreadsheet by clicking here and you can just use it standalone. Everything you need is in the tab "QR Code." Just enter text (up to 15 characters long) in the yellow box (Cell Y36) and the codes will be generated.

If you want to know how this all works, below is some explanation. To follow along, go to the "Generate QR" tab.

There are many sizes of QR codes, the smallest being a 21x21 pixel matrix known as Version 1 and the version that I have created in this spreadsheet.

To follow along, I will assume that you have not modified the original spreadsheet and "This is a test" is the string that we will encode into QR.

Step 1: There are several "Modes" you can use, but for the purposes of this spreadsheet we will use the "AlphaNumeric" mode. You can see that this is encoded with a 0010. For reasons I will explain in step 2, the spreadsheet will need to be modified if you want to use a different mode.

Step 2: We need to encode the overall length of the message. In a Version 1 AlphaNumeric QR code (21x21 pixels) there is only enough room for a maximum of 15 characters. Cell D4 has the text we want to encode and cell C7 is simply the length of the string displayed in 9-bit binary. "This is a test" contains 14 characters (including spaces). The number 14 in binary is 1110 and because we need to represent this as a 9-bit character, we put 0s to the left so that there are 9 characters. This is very easy to do in Excel with the DEC2BIN function. As I mentioned in Step 1, if you want to use another mode (Numeric, Binary or Japanese) you will need to modify Step 2 since they use a different number of bits. Numeric uses 10 bits, while Binary and Japanese use 8.

Step 3: We now need to encode the message itself. To do this, we break the message into sets of 2 characters (i.e. TH, IS,I, S, A, TE, ST). We also assign each letter a numeric value (as defined in the table I have placed in the Character Map sheet). For each pair of characters, we take the numeric value of the first character and multiply it by 45. Then we add that number to the numeric value of the second character. We then convert the result into an 11-bit binary string. If you are encoding an odd number of characters, then take the ASCII value of the final character and convert it into a 6-bit binary string. For the other modes (numeric, binary, and Japanese,) we would use a different method to encode the data. In Excel, I've done this by breaking out each character of the message in column G using the various text functions. Column H helps to tell us if it's an even or odd character (so we know if we need to multiply by 45) and column I has the numeric code that corresponds to each character using a lookup in the character map table. Column M helps us find which is the last row while Column N adds up the pair (or if there isn't a pair due to an odd number of characters, then just takes the last value). We need to convert the decimal number in column N to either an 11-bit or 6-bit binary number which I would ordinarily do with the DEC2BIN function. Unfortunately, Excel cannot do DEC2BIN on decimal numbers larger than 511. So, in Column O you can see the workaround that I had to use by breaking it down into small chunks and then putting it back together.

Step 4: Here we simply combine the strings from steps 1, 2 and 3. There is an IF/THEN function in there to handle the cases where the message we want to encode (e.g. "This is a test") has an even or odd number of characters.

Step 5: We now need to make sure that we have the correct length of string. QR codes have in-built error correction and there are different levels you can use. We will use Level Q. For this we need to make sure that we create a string with a total length of 104 bits. In Step 5 we add up to four 0s to lengthen the string. In our case, the length of the string in Step 4 was 90 characters, so we add four 0s to the end. If the length of the string in Step 4 was 102 characters, then we would only add two 0s to the end. This is done in Excel with a series of IF/THEN functions.

Step 6: If by the end of step 5 we still don't have the correct length (104 bits) then we need to continue padding it out. The way to do this is to break the string from Step 5 into 8-bit words. We will need 13 of these 8-bit words (8x13=104) by the time we're done. Column AB has the string from Step 5 broken into 8-bit words. The first thing to do is to add 0s to the end of the last word to make sure all words from Step 5 have 8 bits. You can see this in column AC. Then we keep adding new words (11101100 and 00010001) repeating in that order until we have 13. In column AD I identify which words need to be filled and then alternatively put Wordfill1 and Wordfill2. Column AE finishes it off by actually inserting the fill words.

Steps 7-10 involve some complex math to produce the error correction bits. The details of this are beyond the scope of this article, but there is plenty of stuff you can find on Google if you look around. I will describe in a very high-level way what I've done to implement this in the spreadsheet. We will be switching back and forth between decimal notation and Alpha (α) notation. This is done using log and anti-log tables which I have generated and have included in the sheet called "Galois Field 256". If you want to learn more about this, click here to search on Google.

Step 7: We need to convert the words into a "Message Polynomial" which is done by converting the binary words from Step 6 back into decimal. You can see this in column AG. Column AH has the exponent part which is shown here just for completeness, but is not used. In column AJ we convert the binary coefficient into what's known as Alpha notation

Step 8: Here we create a generator which is fixed for each version/type of QR code. The table in columns AM and AN are fixed values for the type of code we are creating (Version 1, AlphaNumeric mode with error correction level Q). For more info on how to create a generator for a different type of code, click here to search on Google.

Step 9: Here we perform the polynomial division using the message from Step 7 and the Generator from Step 8. Of interest here for the Excel implementation is that I had to create a method to repeatedly perform an XOR step. As I wrote at the beginning, I wanted to do all of this without writing any VBA code and there is no XOR function in Excel. You can see how I've implemented this in the XOR sheet.
NOTE: Step 9 has a known issue in it. The result of the XOR will always correctly give 0 as the first character. In some cases, the second (and subsequent) characters can also be a 0. If this is the case, then the MULT step must take the first non-zero digit. I have not implemented this and therefore the QR generator will fail under these circumstances. These are rare and hard to find occurrences, but if you want to try it out, trying to encode this string will fail: "2747585511"

Step 10: Phew, we've made it through all the tough math and it's pretty smooth sailing from here. The last column from Step 9 are the error correction words.

Step 11: We combine the first 13 words that we generated in step 6 and add the next 13 words from step 10. This is what we will be encoding into the QR code.

Step 12: Combining all the words together, we have our full binary string ready to populate into the QR matrix.

You can now switch to the QR Code sheet to see how we finish it off. I have copied the finished string from Step 12 to cell AW21 in the QR Code sheet for simplicity.

The QR code is drawn by turning pixels on or off. I have implemented this by using 1s and 0s in a matrix'ed set of cells (columns Y to AS). Using conditional formatting, I have set a 1 to be a black-filled cell and a 0 to be a white-filled cell. The trick is now to just create the matrix.

Step 13: There are some cells in the 21x21 matrix that always must be set in a particular way. These are the "position detection" cells and I have marked them off with a 1 and they are marked in green. There are also cells called "timing cells" which are always in a particular pattern. I have marked them in blue. We also need to load the data we created in Step 12 into the matrix. You can see in the matrix that stretches from cell B2 to V22, I have marked off where each bit goes. Starting at the lower left we put the first bit (that we created in Step 12), and move around the pattern as indicated. You can see how they all fit together in the matrix from B26 to V46.

Step 14: We're not quite done yet. Because the code we create could be difficult to read (e.g. if there are too many black pixels clustered together, etc.) we need to create 8 different versions of the code and select the best one based on a formula. To do this, we create a "mask" and filter the raw data (B26..V46) through it. Each mask is based on a formula which I will show you below. To tell the reader which mask is being used, we fill what I've labeled as the orange cells with a code to tell the reader which mask we're using. The table of codes can be seen in AV3..AW10. These are also repeated for the sake of ease down column AW at each code. You can see that in each block, the orange cells contain the bits we need to identify each mask.

Step 15: The matrices starting with B50..V70 (B74..V94, etc.) have been filled in with the mask formula. The mask is simply calculated as a function of the row/column of each cell.

  1. If (row + column) mod 2 is 0
  2. If (row) mod 2 is 0
  3. If (column) mod 3 is 0
  4. If (row + column) mod 3 is 0
  5. If (floor (row / 2) + floor (column / 3) ) mod 2 is 0
  6. If ((row * column) mod 2) + ((row * column) mod 3) is 0
  7. If (((row * column) mod 2) + ((row * column) mod 3)) mod 2 is 0
  8. If (((row + column) mod 2) + ((row * column) mod 3)) mod 2 is 0

If you look at the forumlas inside the mask matrices, you'll see how I've implemented them as Excel functions. Boolean functions in Excel normally return True/False, but if you multiply them by 1 you get 1/0 which is what we need.

Step 16: We now combine the raw data (Step 13) with the mask such that whenever the mask has a 1 we change the raw data to the opposite of what it is (from 1 to 0 or 0 to 1). Whenever the mask has a 0, we leave the raw data alone. The math to do this is quite easy and is done in the formulae hidden under the actual QR codes we've generated (Cells Y50..AS70, etc.). Using conditional formatting, we just set Excel to make the cells all white or all black based on the number underneath. As you can see, we create 8 QR codes (one for each mask). Officially, the next step is to pick the "best" one, but in practice, my iPhone QR reading app can read all of them... so find one that you like, test it and use it! If you really want to be compliant with the standard, you can Google how to pick the "best" pattern by clicking here. 

Bookmark and Share