Arduino library for the MGC3130

2015-05-13 06:38 by Ian

This post will cover the theory-of-operation of a driver for Microchip's weird and wonderful MGC3130 e-field gesture sensor. I will be using Microchip's Hillstar dev kit for the MGC3130, a chipKIT Fubarino Mini, and MPIDE. But the library ought to work with any other Arduino-esque microcontroller provided it has Wire.h. I have a special header file case-off for the more-efficient Teensy3 i2c implementation if you are using that chip. By following that pattern, you can easily add platform support if you need to.

Edit 2015.05.20: I received perplexed emails that this post refers to the Hillstar development kit, and the post that preceded it referred to the Sabrewing kit. Both Hillstar and Sabrewing are Microchip developer kits for their MGC3130 chip. To clarify, this library will work with either kit, as they both use the same part. I developed the library using the Hillstar, but Murum Lux used to Sabrewing because of its higher area.

Here is the github repo for my fork of Hover's Arduino driver (which I used as a base, and improved beyond recognition). Soon, I will create a new repo with the MGC3130 driver converted to ManuvrOS, but for now, I will post the generalized driver that I used in the MurumLux e-field box.

Installing the library is fairly easy, but if you want my plush debug support, you will also need StringBuilder. And that means you will need to follow these instructions or have some comparable strategy for overcoming Arduino's "libraries including libraries" limitation. If you would rather not do that, you can still use the library, but you will need to excise all my usage of StringBuilder first.

Interrupt support:

If you want to use my experimental IRQ support, and are building on a platform (as I am) that has IRQ IDs that are distinct from their pin IDs, you can case it off in the header file.

#if defined(_BOARD_FUBARINO_MINI_)

...and then again in the CPP file to establish the mapping:

#if defined(_BOARD_FUBARINO_MINI_)

An engineer at did a helpful write-up for interrupt service architecture in the chipKIT environment. This is a worthwhile read if you are using a board that has interrupt capabilities that are better than the Arduino libraries that surround them.

Discussion of driver:

The first thing I do when I start writing software for a new chip is find its register documentation. In this case, the doc is hard to find because there are several datasheets for various aspects of designing with this chip. There is one for electrical layout, one for GestIC customization, a general overview doc, and the GestIC interface specification. We are only here concerned with the last. I will make your life easier by providing you a link to the only doc that we care about today.

Also, my driver is still quite simple. The only message that is handled is 0x91 SENSOR_DATA_OUTPUT (page 42 of the datasheet). Until the driver is more complete, I've been setting the chip's parameters via the host-side development tools. Since the MGC3130 has persistent storage of settings, I conf the sensor once on my PC, and then hook it up to the Fubarino. At some point as the library improves, this will no longer be required.

Depending on the data you ask the chip to send (I ask for quite a bit), you can easily saturate a 400KHz i2c bus. If the sensor updates at 100Hz, it means that output exceeding 4000 bits (probably closer to 3200, in practise) will completely saturate the bus. This is to be expected for a high data-rate part, and you should be mindful of this while you lay out your bus. Combined with the fact that there is extra an GPIO operation (TS line) that needs to be synchronized with the operation of the bus, it may be convenient to relegate the sensor its own i2c bus if possible. That, or keep your data requests specific.

Impressions of the part

After using the MGC3130 in a project, I would say that it was easier to use than most of the barometric pressure sensors I've seen. There is no awareness of calibration parameters required to do amazing things. Taps, swipes, and touches were immediately usable. Positional fixes are accurate, and reports were never false (my cursor never "teleported"). Even better, I was able to keep reading positional data in the midst of other gestures. IE, you could use it for a track-pad by looking for the touch event, and once seen, reading position until the touch event dis-asserts.

Accuracy and latency of gesture recognition for a class of gesture improves if you disable other gestures within that class. For example: tap events are easier to recognize mathematically if you are not also looking for double-taps. So the "semantic sensitivity" is dynamically adjusted based on the driver's settings. This makes sense, given that the GestIC core of the part is using a hidden Markov model to match gestures.

Microchip's claims of an intuitive user-experience are completely justified. Everyone I showed it to was comfortably using their hand to control an on-screen cursor within 30 seconds of practise.

The cost of the part is surprisingly low, considering the capability it imparts (~$5.23 from Digikey at the time of this writing). Comparable performance using an optical strategy would be many times higher and would need much more computational power to achieve the data integrity that the MGC3130 provides without any programming effort.

Some of the same functionality could be achieved with clevar usage of the capacitive touch peripheral seen in many ST parts (IE, the Teensy3), but because this is a passive sensing strategy, it is many orders of magnitude lossier than the MGC3130's strategy.

The most difficult pill to swallow is the task of laying out the PCB and calibrating a special build of the GestIC firmware to accommodate a custom application. But fortunately this only needs to be done once for a given PCB layout, and companies like HoverLabs took that burden off users at the hobbyist level. $40 is much cheaper than the $180 Hillstar kit I am using, and it should be functionally equivalent.