Author Topic: Module 120 accelerometer communications  (Read 1569 times)

kbrooking

  • Full Member
  • ***
  • Posts: 104
    • View Profile
Re: Module 120 accelerometer communications
« Reply #15 on: November 10, 2016, 02:49:48 pm »
in my post above, I have a screen shot. The pop-up window to the right is the actual error I get when running the code. I placed the break point on the statement where the error is occurring just for illustration purposes.

kbrooking

  • Full Member
  • ***
  • Posts: 104
    • View Profile
Re: Module 120 accelerometer communications
« Reply #16 on: November 10, 2016, 08:55:37 pm »
 ::) User error. I got the libraries swapped. Thanks Nick. Looks like both are working now.

dc

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: Module 120 accelerometer communications
« Reply #17 on: December 01, 2016, 03:40:24 am »
Is it possible to suppress or disable the accelerometer trigger for a while after it has been detected?  I want to trigger a GPS read after detection of movement but the GPS can take up to 120s to get a read and in the meantime continual movement triggers a queue for the GPS. 

Nick_W

  • Full Member
  • ***
  • Posts: 215
    • View Profile
Re: Module 120 accelerometer communications
« Reply #18 on: December 01, 2016, 07:18:27 am »
Yes it is.

This is one of the things that I was working on. It's quite easy really. First, you can only get a queue of two events (that's the maximum as far as I know), and you can clear them using ClearHardwareEvent.

The way to stop the accelerometer retriggering is to not clear the interrupt register. Sounds simple. Lets take the "autosleep" register for example, every time the accelerometer wakes or goes to sleep it generates an "autosleep" interrupt. You read the "autosleep" register to see if it was a "wake" or "sleep" event.

If you don't read the "autosleep" register, it doesn't clear the interrupt, and no more interrupts will be generated. The same is true for the pulse, click etc. interrupts. You can tell from the interrupt register what interrupt was generated, but if you don't read that specific interrupt, no more will be generated until you do.

In your case, say you have the accelerometer configured to interrupt on pulse. The accelerometer interrupts when it detects a transient, you read the interrupt register and it's a pulse - start the GPS reading - but don't read the pulse register (to find out what axis the pulse was on). No more interrupts until the GPS reports in - then read the pulse register, and the accelerometer will start interrupting again.

This is for the 110 accelerometer module.

The 120 accelerometer is a little different, and the library for that is still in development, but the same principal applies. The 120 module needs a lot more work before it's as easy to control as the 110, and until the battery issue is fixed, I've shelved development.

Hope this helps...

kbrooking

  • Full Member
  • ***
  • Posts: 104
    • View Profile
Re: Module 120 accelerometer communications
« Reply #19 on: December 01, 2016, 12:32:43 pm »
I think MC-Things have said the issue causing the 120 to consume batteries has been resolved. Can anyone confirm this?

mc-John

  • Global Moderator
  • Full Member
  • *****
  • Posts: 212
    • View Profile
Re: Module 120 accelerometer communications
« Reply #20 on: December 01, 2016, 03:26:58 pm »
Yes it is fixed. It is less than 2uA in sleep

SK

  • Newbie
  • *
  • Posts: 18
    • View Profile
Re: Module 120 accelerometer communications
« Reply #21 on: December 12, 2016, 03:44:45 pm »
Hi Nick

I was wondering what this line does?
Code: [Select]
(accel.GetINT1ActiveInterrupt() & LIS2DH12.INT_ACTIVE) = LIS2DH12.INT_ACTIVE
You've said that you use accel.GetINT1ActiveInterrupt() to clear interrupt but why compare LIS2DH12.INT_ACTIVE to itself?
If I wanted to clear all interrupts in the INT SRC register, how long would I have to loop for?
Something like this?
Code: [Select]
Do
    Thread.Sleep(1000000)
    INTMSG = accel.GetINT1ActiveInterrupt()
While ((accel.GetINT1ActiveInterrupt() & LIS2DH12.INT_ACTIVE) = LIS2DH12.INT_ACTIVE)

Cheers

dc

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: Module 120 accelerometer communications
« Reply #22 on: December 13, 2016, 02:42:08 am »
Has anyone been able to read values from the accelerometer?  All the code samples here seem to relate to the interupt function.  I am looking for a way to detect when the accelerometer stops moving and thought reading the values to check that they have not changed might be the way to go. 

Nick_W

  • Full Member
  • ***
  • Posts: 215
    • View Profile
Re: Module 120 accelerometer communications
« Reply #23 on: December 13, 2016, 08:15:06 am »
Sorry for taking a while to respond, I've been busy on the road.

To answer your previous question, what this line is doing:

Code: [Select]
(accel.GetINT1ActiveInterrupt() & LIS2DH12.INT_ACTIVE) = LIS2DH12.INT_ACTIVE
This (accel.GetINT1ActiveInterrupt()) reads the INT1 register and returns the contents of the INT1 register. The INT1 register contains the bitmask that shows what caused the INT1 interrupt. I just AND it with INT1_ACTIVE (0x40 - ie bit 6 set) which will be 0x40 if the INT1 is in fact active, so comparing it with INT_ACTIVE will return TRUE if INT1 is active for any reason (and FALSE if it isn't). This reads the INT1 register, but does not tell you what caused the INT1 interrupt. In our case, I don't care what caused the interrupt, as we have configured the accelerometer to interrupt on shock, so we are assuming that is what caused the interrupt.

We then go on and reset the interrupt by resetting the trigger events with

Code: [Select]
accel.SetINT1ActiveInterrupt(LIS2DH12.INT_SRC_XH | LIS2DH12.INT_SRC_YH | LIS2DH12.INT_SRC_ZH)
Which tells the accelerometer to trigger on events in the X, Y or Z axis.

This isn't a very good way to use the accelerometer, I was just adapting the code from josh to work with my library. There are much more sensible ways of doing this.

mc-T2

  • Administrator
  • Sr. Member
  • *****
  • Posts: 252
  • mc-Things! The opportunities are endless!
  • Location: Canada
    • View Profile
Re: Module 120 accelerometer communications
« Reply #24 on: December 14, 2016, 05:00:56 pm »
Just a quick update on the battery consumption for the mcMod120 - The fix to bring the mcMod120s down to 2uA in sleep mode has not yet been released but will be within the next week or two. We are making a couple other firmware changes alongside the battery consumption fix. Expect to see the new firmware shortly!

Thanks for your patience and understanding!
Need more mc-Modules, mc-Gateways or other mc-Things? Check out our product page: www.mcthings.com/products. mc-Development kits are available too!
Check out a live Dashboard using mcThings and Losant! Click here: https://goo.gl/ST43hB