Saturday, October 15, 2016

A memory corruption bug as result of 'single character'

It has been a quite a few months since I saw or have written some serious algorithmic code involving C++ (read computing surfaces or doing numerical computation). So when a weird bug was reported for a program I work with, I though it must be fun. The case was for a particular feature in the program that would plot a surface based on some input parameters. The bug was strange because it made the program crash on Windows but on Linux it plotted the surface correctly.

Good then, let us fire gdb and figure out where it was faulting. But for some reason, on the build system I was using for Windows, I couldn't get gdb to work properly. So was left with old way: read the code and put a lot of printf(). Now since this was Windows, printf() wouldn't work either! The program however had a logging API, that would log text to a window. The problem however was that there was no text in the window (or the window was not refreshed) just before the program used to crash. So the next technique was to use the logging and commenting one line at a time, with a premature return from the affected function, which is usually very tricky to do when there are nested loops. And this was exactly the case here. Finally, the real culprit was one line that read:

if (k+l < numberOfXPoints) {
 x[i][j][k+l] = ...

There you have it. The code ought to be:

if (k+l < numberOfZPoints) {
 x[i][j][k+l] = ...

Apparently this error was never observed, and looking back at the history of the source code, I found that it was this way ever since it was written, a couple of years ago! This error didn't probably produce any visible output errors and apparently went past all the test cases as well, because for none of those, the points along z-direction exceeded the points along x-direction.

Two things to learn:
1) Never name two variables such that they differ in only one character. If you indeed need to then ideally have the differing character towards the beginning of the word as in the case above a better way to name would have been using: xPts and yPts.
2) If an error is occurring on one platform but not on another, it is most likely a memory corruption issue. Hunt down all the code dealing with arrays. 

Thursday, May 12, 2016

Experiments with super capacitors and solar panel

Towards the end of 2012, I started experimenting with powering devices directly using solar panel and an pretty expensive super capacitor. For this I bought a couple of solar calculators from a nearby mall, disassembled the tiny solar panels and tried to run a small mp3 player using the same. The project kind of got shelved, towards the beginning of 2013 due to loss of my mother.

Later on in 2014, I got some pretty inexpensive but good quality super capacitors from eBay. And then repeated the experiments. I tried two things:
1) Powering the calculator fully on solar and super capacitor
2) Powering an MP3 player using a super capacitor and a slightly larger solar panel (again ripped off from a solar power bank)

While the fully solar calculator (supported by the super capacitor) works wonderfully well (even today), the MP3 did work pretty well too. The only issue with the MP3 player being that the 1F super capacitor I had only lasted for about a minute if I got it away from direct sun light. The calculator on the other hand, requiring pretty low power didn't have issue with even ambient room light.

I believe super capacitors combined with solar panels have interesting applications. Especially in wearable world. It is only a matter of time that these things become common place.

Friday, April 01, 2016

A Thousand Times

I must have talked a thousand times .. to myself
Where are you ? Where you?

I must have walked a thousand times
To see you. Where you ?

I must have heard a thousand times
About you. Where you?

I must have walked a thousand miles
Still here 
Wondering what am I doing still, again and again and again ..


Saturday, February 13, 2016

Printing on a white label BLE thermal printer from iOS - a quick story

Over at, we are building tools to help small merchants better connect with their customers. Check to see what we do, and do not forget to watch that video, we are sure you would love it :-)

While one of the core principles at OneGreenDiary is to be as paper less as possible, there are still places where a printed paper bill may be required. We avoided print support for our merchant apps, till one of our early adopters specifically asked for it. Since we are kind of cash strapped, and can not afford to spend on a damn printer that is iOS certified, we went over to and ordered this cheap Bluetooth enabled thermal printer that claimed to work with iOS :

Great. After the printer arrived, we though that it would magically connect to out iOS device and we did start printing instantly. Bummer. Ok, how about Android ? No luck. Apparently neither iOS nor Android provide native support for BLE printers. I tried to install the outdated Windows driver, and Linux cups drivers with no luck. Not even able to print on desktop. 

But then, Abhay C, a wanderer with us, found an iOS app called printer-x, that was a demo app to print on bluetooth enabled thermal printers. He printed this:  "hello, world!"

At this point we knew, it could be done. But how? All communications with the vendor didn't go anywhere. They send some sample iOS (Objective C) code, and some Android code, both of which didn't compile, and neither we could understand what was going on in the code. There were a few comments in Chinese that tried to be helpful. Chinese, not Swift. The programmers manual that came with printer reminded me of good old DOS assembly days. There was something, but didn't know where to start.

Next we tried to venture into programming our own BLE layer for printer communication. Instead of using the CoreBluetooth library we zeroed in on using BluetoothKit, which is Swift wrapper over CoreBluetooth library ( So basically it is this: BLE frameworks try to give you two interfaces: Peripherals and Central. Peripheral refers to a device which can be discovered, asked for data, or can receive data. Central on the other hand scans for Peripherals, discovers characteristics offered by Peripheral, receive / send data to the Peripheral. One of the important thing to enable discovery is the UUID of the Bluetooth device, this can be easily obtained by using a discovery code, or a number of BLE query apps available on the App store/ Play store. I used the LightBlue app from the App store for this purpose. Once this device was discovered, we needed to connect to the device. The BluetoothKit provides a elegant interface to connect. But the issue started after this: apparently BluetoothKit's connect call back returns an instance of BKRemotePeripheral class, and this class exposes API to only receive data, not send! Apparently the class was more designed for bluetooth sensors, that only transmit data, not receive anything. Digging into the BKRemotePeripheral class, I found out a way to expose the embedded CBPeripheral object along with capturing CBCharasteristic objects. These are the objects of CoreBluetooth iOS library that allow lower level controls.

Next is when the DOS assembly like programmer's manual, which came with the printer, came up for help. After this I could easily figure out the code to issue a line feed to the printer device:

let lineFeed = self.hexToNSData("0A")
let printer = self.connectedDevice!.getPeripheral()!
printer.writeValue(lineFeed, forCharacteristic: self.connectedDevice!.getCharacteristic()!, type: CBCharacteristicWriteType.WithResponse)
At this point, I knew, things were pretty much in control. The above code basically writes the hex code "0A" to the discovered characteristic. This initiates a line feed operation on the printer. Once this is done, it was a wow moment to print this:

and then this:

Since all of this code (written in Swift) was majorly based on BluetoothKit, we felt it was best to open up this part of the code, which is now hosted on GitHub:

Hope this is of some help, especially if you are trying to programatically access these kind of printers with iOS.

Note: Before you ask, I am still connected with VLife for all official (and practical) purposes. Once an officer at immigration and citizenship department in Oz told me, it is always good to be in love with two countries, you are contributing to both with your heart. Fits well here. 

Saturday, January 30, 2016

You don't need a desktop on your Smartphone

There are two companies that are trying to position their mobile offering with a standout feature. Microsoft's continuum and Canonical's convergence mean the same thing to an external user although the way they are implemented is a lot different. Both of these implementation, however fail miserably in one important department: mobility. And that is precisely the reason I use a smartphone to do lot of my tasks on the go.

Both continuum and convergence require extra hardware to get it working: A dock, keyboard, a mouse, and an external screen. All of which completely defeats the purpose of the whole thing, atleast for me. There is another bigger issue. When you try to shove in the desktop to a form factor like a smartphone, you basically stop looking at ways to use different UI paradigm and design to improve productivity on small screens, with the pre conceived notion than only a bigger screen is needed for actual productivity. One of the prime examples of this issue is how poorly the Microsoft Excel for iOS is designed as compared to how well Apple Numbers is designed. 

While the default keypad for entering numbers and dates (two most frequent entered entities for a spreadsheet) in case of Apple Numbers is very easy and fast to use adapted keypad, in case of Mocrosoft Excel it is pretty standard looking and difficult to use keypad for the context: 

Canonical's approach is no different. In that for productivity suits like LibereOffice, there is literally no thought on how to design UI for the small form factor. Rather, the argument is to simply connect an external monitor to get a full Ubuntu desktop. Cool for geekiness, zero for usability.

In the end I see both Continuum and Convergence as defensive response to ultimate failure to innovate on the small screen. The Apples approach to bridging the gap, dubbed Continuity, though useful for a limited scenarios, feels more like a proof-of-concept rather than something that I can truly use for my workflows. All this workarounds until of course we have hardware technologies like the bendable or foldable displays become a real consumer reality.