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.
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
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 22.214.171.124: 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.
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.
Have just got some new kit on loan for a customer project a FEZ Spider V1.0, USB Client SP Module and a Pulse Oximeter module.
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.