mc-Things
mc-Products => mc-Module => Topic started by: Nick_W on October 01, 2016, 07:50:39 pm
-
So, back from the road, and my 120 modules have arrived!
I set them up, with the hope of making some progress on a library for the new accelerometer.
First, a lot of trouble connecting and downloading code (even with the latest firmware, mcStudio etc.). The module has to be really close to the Gateway for it to download reliably. I mean inches away.
But, figured that out.
Now, can't talk to the accelerometer. Some odd behavior, if I set the I2C speed to 400kHz, the whole module hangs (have to "delete code" to recover). Set to 250kHz, it seems OK. I2C address set to 0x19.
So trying at 250kHz, first step is to read the WHO_AM_I register (either 0x0f or 0xaf - depending on register auto increment or not), this should yield 0x33. No matter what I try, I read 0. And it actually reads 0, not just "nothing". Trying to read other registers also yields 0.
I have checked the I2C data sequence, and it seems to be the same as the 110 module accelerometer (which works).
Does anyone have some example code using the new accelerometer (just who_am_i would be fine)?
I'm not sure if this is a bug (the hang at 400kHz is worrying), or something I'm missing.
Any help with the 120 module accelerometer would be appreciated.
-
Nick,
Just to be sure, are you using the latest versions of the mcMod120 firmware and mcStudio? Also, there is currently a bug on the mcMod120s with using the I2C at 400kHz so the bus can only be used at 250kHz or 100kHz.
Also, I have attached a very preliminary LIS2DH12 driver and test script. Please give it a try and let me know how it goes.
Thanks,
mc-Josh
-
Thank you Josh!
Just what I was looking for. That explains the hang at 400kHz, so I'll just go with 250kHz right now.
I am using the latest FW and mcStudio (as far as I know).
The example should get me going, it looks to be the same as what I am doing, but we'll see when I get into it...
Thanks again!
-
Nick,
Were you able to get the LIS2DH12 up and running?
Thanks,
Josh
-
Haven't had a chance to get to it just yet (doing the work thing). Maybe tomorrow? I'll let you know.
-
Hello Nick, would you be able to provide an example using the accelerometer on the 120 once you have it figured out?
-
Looks like the drive and test script Josh provided loaded and executed (no errors) on my 120 but, not sure what the test script is doing. How can I test it?
-
I haven't had much time to work on it lately, but I do have it working in my door knock sensor code.
I added LedRed on and off, so that I could see the interrupts.
One thing I noticed is that it is very sensitive, triggers at the slightest touch. If you trigger it too much (not very much), the module stops publishing (beacons still work).
I changed the response time from 2ms to 20ms, and it's better.
Not sure why it would stop publishing if you generate too many interrupts though.
I think I was confused about my previous code because the WHO_AM_I register returns a 0 when you query it (I expected 0x33) - so I thought I had a bug in my I2C code, but no, it does return 0. Weird.
-
Ok, had some time to work on this.
There is a new beta library published on my github site.
It's in projects.
The test code is a version of my door knock program.
It's a beta release, but it covers most functionality. Not fully tested yet.
-
When I run the example code for the LIS2DH12 that Josh provided I get the attached error.
-
Yes,
You have to use my code, not his I use different names for some things, and the library works differently. I use "read" and "write" not "readsinglebyte" and so on.
I have implemented lots of methods, so you don't need to use "read" and 'write" directly. Look at the library, or my example, you'll see the difference.
his code won't work with my library. Use mine.
-
Hope this helps,
Here is the equivelent of Josh's example code, but using my library:
Class LISDH12_Test
Shared accel As LIS2DH12
Shared Event Boot()
accel = New LIS2DH12
'set accelerometer to cause interrupt if accelation is > 1.15Gs for longer than 2ms (any axis)
accel.ConfigureShockInterrupt(1.15, 2.0)
End Event
Shared Event AccelerometerInt1()
'debounce interrupt
Thread.Sleep(100000)
Thread.ClearHardwareEvent()
'Read Int source register to clear interrupt
If ((accel.GetINT1ActiveInterrupt() & LIS2DH12.INT_ACTIVE) = LIS2DH12.INT_ACTIVE) Then
'interrupt generated
LedRed = Not LedRed
End If
'restart interrupt
accel.SetINT1ActiveInterrupt(LIS2DH12.INT_SRC_XH | LIS2DH12.INT_SRC_YH | LIS2DH12.INT_SRC_ZH)
End Event
End Class
You can see that I don't use read (or readsinglebyte) or write directly.
I do plan to re-write this using Millenials method of passing strings - so much easier!
make sure you have the latest firmware! much more reliable.
-
Hmm, just re-read your message. Do you mean you are using Josh's code as-is? ie his beta library?
That did work on my modules (120). This does only work on 120's not 110's.
I just compiled my example (with my library), uploaded it to a 120 module, and it works just fine...
-
Hello Nick,
Apologies, I should have been more specific.
Yes, the error I attached below is while using Josh's code as is and with his library along with the new mod120's that just arrived the other day and latest firmware from mcThings download page.
I wanted to make sure I could execute Josh's example before trying yours.
Any suggestions?
-
I didn't have any problems other than the device only working at 250KHz (not 400), and the whoami returning 0 confused me for a while.
Have you just tried uploading and running it? seems an odd place for a breakpoint. I also haven't seen that error message before, when I tested, and got problems the error message was "I2C Bus is locked".
Do you have a screenshot of what you actually get?
-
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.
-
::) User error. I got the libraries swapped. Thanks Nick. Looks like both are working now.
-
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.
-
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...
-
I think MC-Things have said the issue causing the 120 to consume batteries has been resolved. Can anyone confirm this?
-
Yes it is fixed. It is less than 2uA in sleep
-
Hi Nick
I was wondering what this line does?
(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?
Do
Thread.Sleep(1000000)
INTMSG = accel.GetINT1ActiveInterrupt()
While ((accel.GetINT1ActiveInterrupt() & LIS2DH12.INT_ACTIVE) = LIS2DH12.INT_ACTIVE)
Cheers
-
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.
-
Sorry for taking a while to respond, I've been busy on the road.
To answer your previous question, what this line is doing:
(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
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.
-
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!