Until we have the Github site here figure out (and maybe even after that), all my stuff is located at:
https://github.com/NickWaterton

The structure is not great, and things that are there and have the same name as on the mcThings GitHub site are probably NOT the same. I have changed a lot of stuff (examples too) and re-written some of the libraries (the accelerator library for instance is re-written).

Feel free to use it, no guarantees that there aren't any bugs, it's all a work in progress. 

Thanks Nick. Much appreciated. Lots of good stuff here to get newbies started.

One question. The "Class to utilize MMA8652 Accelerometer" is this the accelerometer that comes on the Mod120 or is this an external sensor you added?

Hmmm... That's interesting. So you can reuse other folks Aduino code samples on these devices as well, is that correct?

Hello Nick,

I’m looking over your DoorSensor code and is very interesting. A lot here a newbie could learn from.

I know it’s a lot to ask but, would it be possible for you to do an article stepping us through your code?

 I know I, as well as others in the community could really benefit from this.

I will post in small (digestible) chunks.

First, to understand the code, you need to understand the mma8652fc - you can read the data sheet (DS in the code references) but it can be hard to understand. Here is the condensed version.

The mma8652 works in two ways:
1) X,Y,Z acceleration (including gravity) are continually measured at the  Output Data Rate (ODR), which can be configured to be between 1.56 to 800 Hz. These values are read from the OUT registers, and can be configured to have a range of 0 to (+-)2,4, or 8 g. New reading available is indicated by the STATUS register, but you can ignore this and just read the OUT registers, which will reset the STATUS register. The higher the frequency of readings, the more power is used.

2) Events can be detected, and trigger interrupts. The interrupts can be INT 1 or 2 and correspond to the MCThings accelerator interrupt 1 or 2. Events can be: Motion, Tap (pulse), Transient, Freefall, Orientation.

There are two settings, Active and Standby. You can read registers in Active or Standby mode, but you can only write (configure) registers in Standby mode. The system only takes readings in Active mode. So to configure the system, you switch to Standby, configure, then switch to Active mode.

There are two modes, Wake and Sleep. In wake mode, the system runs at the wake ODR (up to 800 Hz), in sleep mode the system runs at the sleep ODR (up to 50Hz).
The idea is that you run at a low ODR in sleep mode, to save power, then when an event triggers, the system wakes and switches to the wake ODR. After a configurable period, the system switches back to sleep mode. You can trigger the transition manually, or even disable sleep mode, but using the MCThings modules, it makes most sense to have it set up to switch from sleep to wake mode and back automatically.

The thing to realize about the ODR is that at a low ODR (1.56 Hz), there is 680ms between readings, so if you want to detect a transient or tap of duration 50ms, this won't work. You would need an ODR which has a sample rate of less than 50ms (if you care, google Nyquist sampling). 50Hz is 20ms per reading, so that would detect a 50ms duration event. An event like Landscape/Portrate switch obviously has a long duration, so 680ms detection rate would work perfectly well. Some experimentation with ODR is required if you are trying to detect short duration events (taps, thumps, rapid changes etc).

There are 5 configuration registers CTL_REG1 to 5. These are what are used for the basic set up, then each event has its own set of registers that set things specific to that event (threshold, angles, duration of event to trigger etc).

CTL_REG1 sets wake and sleep frequency, plus Active/Standby mode.
CTL_REG2 sets sleep/wake configuration (enable sleep, hi-res vs low-power etc)
CTL_REG3 sets the events to use to switch from sleep to wake mode, plus interrupt mode.
CTR_REG4 sets the events to cause an interrupt (note this is different from just switching from sleep mode)
CTL_REG5 sets which INT to activate (1 or 2) for each event.

When an interrupt is generated, you then have to read the INT_SOURCE register, to find out what the source of the interrupt was. Ie if INT1 is triggered, you don't know what triggered it (you can assign anything to either interrupt), so you read INT_SOURCE, and the bits that are set tells you what generated the interrupt.

Once you know what generated the interrupt, if you want more data (like magnitude, angle etc) you read the status register for that event. Reading the status register also clears the interrupt in the INT_SOURCE register, reading INT_SOURCE does not clear INT_SOURCE.

So for example, if you configured the orientation interrupt, to detect Portrate/Landscape change (called PL in the code/Data Sheet), then when an event triggers, you read INT_SOURCE, find that it's the PL interrupt, then read the PL_STATUS register to get details (such as portrate or landscape orientation), which resets the INT_SOURCE PL bit.

Now we know what we are trying to do, the next post will explain the code that does it.

Hello Nick,

In the below code snippet from the MMA8652 library, the whoAmI() function call is returning 0x00 and so the Accelerometer is never enabled.
Any suggestions as to why it is not returning 0x4a?

Public Sub New()
        gAccelerometer = I2c.Create(I2C_SPEED, Pin.SCL, Pin.SDA, I2C_ADDR)
        If whoAmI() = 0x4a Then
            online = True
            reset()
            // Set interrupt active low
            write(CTRL_REG3, read(CTRL_REG3) & ~IPOL_MASK) // clear bit 1 (active low)
            // Set interrupt push/pull
            write(CTRL_REG3, read(CTRL_REG3) & ~PP_OD_MASK) // clear bit 0 (push-pull)
        End If
    End Sub

In the below code snippet from the MMA8652 library, the whoAmI() function call is returning 0x00 and so the Accelerometer is never enabled.
Any suggestions as to why it is not returning 0x4a?

It works fine for me. I have just loaded the code into a new 110 module running 7.370 F/W

Here is the MQTT output

MCThings/000111B4/Status Booted: V1.02
MCThings/000111B4/Status Accel Sensor Online
MCThings/000111B4/KnockEnable True
MCThings/000111B4/Status OnLine

In order to read/write the I2C to the module, the read and write routines in the library are very specific. The MMA8562 needs a "repeated start" before you can read it. It is possible that I have a bug in here, as I'm not sure how to do a "repeated start", with the code tools we have. I do a write (without a stop) then a read - which is required for a repeated start - ie you can't have a stop before a read.

Can you post your code somewhere (I appreciate it's probably quite long) so that I can try it, or download from my github again? I did fix some small typo's in the last day or so. Not that they should effect anything, but it's working as is on my two 110 test modules.

If you put a magnet against the reedswitch, wait 5 seconds, then tap the module several times quickly (like a knock...), this is what you should see:

MCThings/000111B4/Door False
MCThings/000111B4/Doorknock True

Door False is the door detected as closed.
Doorknock True is what you get when two taps less than 0.75 seconds apart are detected (and the door remains closed for more than 1 second afterward).

Hello Nick,

I'm using the 120 modules. Could that be the reason?