Netduino and MMA8451Q I2C

After an hour mucking around trying to figure out why my new MMA8451Q accelerometer breakout board was returning odd values I stumbled across this post which lead to this post. Then I went back to the device data sheet and found the key paragraph I had missed

A LOW to HIGH transition on the SDA line while the SCL line is high is defined as a stop condition (STOP). A data transfer is always terminated by a STOP. A Master may also issue a repeated START during a data transfer. The MMA8451Q expects repeated STARTs to be used to randomly read from specific registers.

After implementing the approach suggested in this post I can now reliably read registers on the device.

This appears to be applicable for the MMA8451Q, MMA8452Q and MMA8453Q devices.

MMA8451Q Breakout board

Finally got some time to try out the MMA8451Q breakout board that arrived last week.

I’m using my Seeedstudio Grove Base Shield, 1 x Grove Universal 5cm cable, 1 x Grove Screw Terminal and 4 x jumper wires to build a test harness for the breakout board. Once I have got the I2C connectivity & device configuration sorted I’ll connect up the two interrupt outputs on the MMA8451Q in a similar way.

Bodged up MMA8451Q connectivity

Bodged up MMA8451Q connectivity

Netduino Plus V1 Clock Accuracy vs. NTP

The Quakezure client application needs a reasonably accurate clock for time stamping the arrival of P-waves and S-waves (P waves travel at 2000-8000 m/sec so a couple of seconds can make a significant difference).  A GPS unit would provide a very accurate reference but it adds significant cost. For example the SeeedStudio GPS twig costs USD39.90 which is roughly 1/3 of the current BoM. The QuakeZure device (or separate GPS unit) would also need to be installed where it could receive information from the GPS satellite constellation. .

In New Zealand the Measurements Standards Laboratory which is part of Industrial Research Limited (a Crown Research Institute) offers public SNTP & NTP services. Using a tiered SNTP approach looked like a cost-effective alternative to GPS for internet connected devices. I started with a ping on my ADSL connection to see what the connectivity with MSL was like (will be much slower on cellular, have seen approaching 10x slower on 2G GPRS)

Ping statistics for 131.203.16.6:     Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:     Minimum = 33ms, Maximum = 33ms, Average = 33ms

I then wrote a quick ‘n dirty .NetMF console application which used a configurable (default 10mins) timer to regularly compare the current device time with the IRL time and display the difference. I wanted to see what the jitter was on the NTP request and how accurate the N+ on board clock was.

Current Time 12-12-16 06:45:00.09 Duration 43mSec Difference 0 mSec
Current Time 12-12-16 06:55:00.09 Duration 44mSec Difference 86 mSec
Current Time 12-12-16 07:05:00.09 Duration 44mSec Difference 174 mSec
Current Time 12-12-16 07:15:00.09 Duration 44mSec Difference 262 mSec
Current Time 12-12-16 07:25:00.09 Duration 44mSec Difference 349 mSec
Current Time 12-12-16 07:35:00.09 Duration 45mSec Difference 437 mSec
Current Time 12-12-16 07:45:00.09 Duration 44mSec Difference 524 mSec
Current Time 12-12-16 07:55:00.09 Duration 44mSec Difference 611 mSec

After running for an hour the N+ clock was just over half a second out, which equates to roughly 12.5 seconds a day so I then did some digging and found I was not alone.

Need to look at how often I should adjust the device time back into sync with the back office without generating to much NTP traffic.

Fez Spider and Pulse Oximeter power problems

When I initially started writing code for the Seeed Studio Pulse Oximeter I found that I was getting no pulseOximeter_Heartbeat notifications and it seemed to take an awfully long time to get pulseOximeter_ProbeAttached or pulseOximeter_ProbeDetached notifications.

I was powering the kit from the USB port on my development desktop box via a USB Client SP Module. While doing some research I read this post. I then swapped to one of the USB ports on the mother board and the problems went away. I’m going to get a USB Client DP Module so this issue is permanently resolved.

Fez Spider OOB Experience

Have just got some new kit on loan for a customer project a FEZ Spider V1.0USB Client SP Module and a Pulse Oximeter module.

FEZ Spider and Pulse Oximeter

FEZ Spider and Pulse Oximeter on my desk

Previously, I have used the Netduino & FEZ Panda II devices with SeeedStudio Grove Twigs which have quite a different development experience to the Gadgeteer model. The drag ‘n’ drop of components onto the design canvas and the automagic wiring up is neat. But, I’m not certain if this level of abstraction is a benefit or an impediment for more complex projects? I find the way the sockets are labelled and used a bit awkward compared to the Netduino etc.

I can see how those new to the platform could get something up and running quickly which is a real positive. I need to spend more time with the Gadgeteer tools to make sure I am using them in the way they were meant to be used rather than fighting them.

MMA7660FC & ADXL345 I2C Accelerometer read rates

Based on this USGS information I need to ensure a sufficiently high sampling rate to ensure the data collected is useful. Most earthquake waves appear to have a frequency of < 20Hz so taking Nyquist in account I need to be sampling at least at 40Hz.

In a tight loop doing nothing but communicating with the accelerometer I read X,Y & Z acceleration values then averaged the results over 10 lots of 10000 readings.

MMA7660FC – 6 bit acceleration value in 1 byte for each axis 650 RPS.

ADXL345 – 10 bit acceleration value in 2bytes for each axis 435 RPS

Netduino Plus using a SeeedStudio Grove Base ShieldMMA7660FC twig & ADXL345 twig.

The devices also have configurable acquisition rates & in some cases FIFOs for queuing readings which I need to look at some more

Accelerometer Evaluation Process

Two Analog devices ADXL345 Twigs from Seeedstudio arrived today. These offer much better sensitivity than the MMA7660FC Twigs that I have been using. The MMA7660 has a 6 bit 2’s complement output for X,Y & Z acceleration whereas the ADXL has 10 bit resolution in the +-2G range which I would be using.

I have also ordered a couple of MMA8451Q Accelerometer breakout boards from a vendor in China. These have a 14 bit accuracy and have a low noise mode which looks promising. The low noise mode requires a bit more power but for a non mobile application this shouldn’t be an issue.

Netduino Plus 2

WIll be ordering a Netduino Plus 2 as soon as availability confirmed

168MHz CPU (was 48MHz)

384 KB Code storage (was 64KB)

100+KB RAM (was 42KB)

Plus other improvements, I wonder what the impact of the faster CPU on power consumption will be as I have just purchased a solar panel & battery from seeedstudio.

The extra RAM should make the QuakeZure client software a lot easier as no more mucking around with shunting data off to the SD card to save space.

Quakezure device

This is the prototype QuakeZure device for detecting P-Waves and notifying Azure backoffice.

The kit cost about USD 120 and would get cheaper in quantity. Organisations like Seeedstudio can take a concept built with the Grove prototyping kit I used and organise production engineering of a real product from a concept if volumes are sufficient.

Netduino Plus USD 57.95
Grove Base shield USD 9.90
Grove Accelerometer USD 12.90
Grove GPS USD 39.90

I have been looking at other MEMS devices from Freescale,  ST MIcroelectronics, Analog devices, Memsic  plus a few others. The key issue is that as soon as you go beyond consumer grade accelerometers the price rapidly rises to several times the cost of the rest of the kit.

For a production system you would most probably use something like GHI G120 Module USD37.39 with a custom board with the necessary power supply, connectivity & sensors mounted on it.

PoC QuakeZure Client on my desk

Writing to an Azure Storage Queue from a Micro Framework device

In my TechEd presention I demoed writing messages into an Azure Storage Queue from a Netduino Plus. I have knocked up a couple of basic NetduinoPlus samples to show how this works. The code was inspired by these articles

http://azurestoragesamples.codeplex.com/
http://soumya.wordpress.com/2010/05/21/azure-simplified-part-5-using-rest-api-for-azure-queue-storage/
http://convective.wordpress.com/2010/08/18/examples-of-the-windows-azure-storage-services-rest-api/
http://brentdacodemonkey.wordpress.com/2009/04/16/azure-storage-%E2%80%93-hands-on-with-queues-part-1/
http://msdn.microsoft.com/en-us/magazine/jj190807.aspx

Both versions have a dependency on a third party SHA implementation (I really didn’t want to implement that myself) of which there are several available for the .Net MF. I have used ones from inControl & ElzeKool successfully.

There are two versions, one which has a dependency on the .Net MF Common extensions for basic string manipulation fuinctionality and a low dependency version which uses only what is available in the .Net MF framework.

Code is available from here