Assemble Electron + Asset tracker

Thank you both,
I think I got it right now :slight_smile:

GG

1 Like

Looks better :+1:

Hi. Not sure if replying is the correct etiquette to continue on this same topic, but with my own questions(?) I have got to the same point as giangui in his photo above. I am also a newcomer to the electron.

My question is whether the shield is powered up via the power supply of the electron?

Is there documentation of the shield schematic anywhere (havent been able to find so far on guides).
There doesnt seem to be much (any?) guidance on “how to get started” with the asset tracker…

I can see two screw down terminals with “+” and “-” adjacent them, so wondering whether this is external shield power (or not).

With electron inserted in shield and powered up (as per the last photo from giangui) above I have no indication from shield of power up or GPS lock, so left wondering whether I need to do more to get to next step.

Thanks for help.

You can find schematics here
https://github.com/spark/shields/tree/master/electron-shields

And since the intended use of that shield is off-grid the Electron LiPo should suffice to power the device and the shield (unless you put very power hungry things on the proto area :wink: )
And yes, you could use the screw terminals to power the whole lot and charge the LiPo too.

If you need more than this and the comments in the library samples, there are several threads about the Asset Tracker in this forum too.
Or this piece of art
https://github.com/dmiddlecamp/fancy-asset-tracker

1 Like

I tried installing the motion-tracker example but my device crashes and goes into safe mode within about 3 seconds of flashing the build over.

Any suggestions on where to start debugging?

You are mostly likely getting safe mode (blinking magenta) because you built for a system firmware version later than what you have on your Electron. If you’re using Particle Dev (Atom IDE), you need system firmware 0.5.3 on your Electron. If you’re using Particle Build (Web IDE) you may need to adjust the version popup menu. It’s explained here:

1 Like

Thanks for the reply, I think I got it working. In the mean time I started looking into this related project but was unable to install it. Perhaps either of these projects will help someone else in the future who is getting started.

I was able to get the asset tracker up and running. It was reporting out its location every 20 minutes. I wasn’t doing anything to save battery life. So I’m assuming GPS and cell hardware were just on all the time. I’m still learning what kind of life span to expect out of this thing. It died after about a day and a half. So now I’m going to go through some of the demos linked to in this thread. I’m going to have this thing in a car and wired so that it will be charging any time the car car is moving.

In the meantime, does anyone already know what is the max amount of time that the device can stay alive for if it were only using the accelerometer and essentially in a standby mode? I get that I can just keep adding battery to get the life I want too :slight_smile: Just wondering if anyone already has some info/experience to share. My goal is 2 weeks standby time.

You probably want to do some research on sleep modes:

Your battery run-time will vary based on how often you sleep, how long you are awake and the capacity of the battery. You may also want to ping @RWB and @Rftop who I have seen do a lot of solar and battery trials. You can also search the forum for sleep modes and battery capacity threads as I know this question is asked often… maybe not in the context of the asset tracker but the concept is all the same.

1 Like

If you put the Electron in SLEEP_MODE_DEEP with cellular off and only have the LIS3DH accelerometer in wake-on-move mode I think you should be able to go 4 weeks or so with the 1800 mAh LiPo battery.

3 Likes

+1 to @ninjatill’s comments. As he said, The Code that you use will be the major determining factor.

Take for instance the WakeOnMove example here
I’ve never measured the “Sleep” current required by my Asset Tracker, but I’d expect a minimum of 6.5 mA (for SLEEP_NETWORK_STANDBY) + the current for the accelerometer. @rickkas7 might have some data for the Asset Tracker and his code.

Also, if you plan to use the Li-Po in an Automobile, please take thermal precautions.
At a minimum, add a temperature sensor and disable charging when the cabin temps are too high for safely recharging the Li-Po. Something as simple/easy as a TMP36 is a starting point for less than $1.

[Edit] I see that he beat me :grin:

2 Likes

That is a really good tutorial. Thanks a lot for such good detail.

I worked through the first 2 examples, 1_GPS_Features.ino and 2_Accelerometer.ino. Now I’m on 3_WakeOnMove.ino. I wish it had more comments as I’m struggling a little more than the first 2 to understand some of the individual lines and what they are trying to do. I’ll probably get through it, but if anyone wants to toss me a bone these lines are the ones I’m not entirely clear on yet:

awake = ((t.clearAccelInterrupt() & LIS3DH_INT1_SRC_IA) != 0);

Does this one actually change something or just check something?
if (!t.setupLowPowerWakeMode(movementThreshold))

And finally, I’ve brought in the line below and tried verifying it and it works as it’s written, but if I change SLEEP_NETWORK_STANDBY to SLEEP_MODE_DEEP it fails to verify the code.

System.sleep(WKP, RISING, TIME_PUBLISH_BATTERY_SEC, SLEEP_NETWORK_STANDBY);

The deep sleep parameter is not a replacement for the SLEEP_NETWORK_STANDBY flag but as the docs state would go as first parameter
https://docs.particle.io/reference/device-os/firmware/electron/#sleep-sleep-

System.sleep(SLEEP_MODE_DEEP, RISING, TIME_PUBLISH_BATTERY_SEC);

Yes it does set the threshold first and then checks whether that change was successfully applied or not.

First the interrupt flag is cleared and the returned value (representing the previous state) is binary ANDed with the LIS3DH_INT1_SRC_IA flag to reset all other bits but this one and then the result of that operation is compared for inequality to zero and stored as boolean in the awake flag.

1 Like

Here is the code from the example:

case RESET_STATE:
	if (!t.setupLowPowerWakeMode(movementThreshold)){
		Serial.println("accelerometer not found");
		state = SLEEP_STATE;
		break;
	}

	state = BOOT_WAIT_STATE;
	break;

My interpretation: When setting the accelerometer into low power wake mode, if it was successful it will return a zero. This means the accelerometer isn’t found, as expected since it’s in sleep/standby, hence the print command. In that case, it’s ready to do a wake command if needed, so it is ok to go to sleep. Otherwise, the accelerometer WakeMode didn’t work, so go through other routines instead.

Something still isn’t clicking for me. Do I need to set the LowPowerWakeMode after every time it sends a wake command (so it is kicked out of that mode after it is triggered my movement)? In that example I only see it going to RESET_STATE one time as the code is first initialized. Is that correct? I’m not understanding the use of this case in that example. If the command was successful or not, I don’t see it ever getting called again as it goes to either BOOT_WAIT_STATE or SLEEP_STATE which never get back to calling the statement again.

Sorry for what I’m sure sounds like novice questions. Also thanks for pointing me at the reference material. I should have already gone through that but missed it. My bad :slight_smile:

I haven’t looked at the actual implementation but I’d rather expect the function to return true (= 1) when the call succeeded and false (= 0) when it failed, but due to the preceding negation operator (!) returning false will be inverted to true and hence the “not-found” branch initiated.

Yeah, there’s some counter intuitive logic to me in that example (still guessing I don’t understand the code correctly). I think that I should change my question…

When would the command t.setupLowPowerWakeMode(movementThreshold) fail to work? If I understand that, then I can write my own logic for dealing with it.

This provides one answer :wink:

I know :slight_smile: I meant more like, why would it respond with a zero? I’ve probably been thinking about the interaction of the devices incorrectly. It’s on the SPI bus, the command goes through the Electron, and if the SPI bus response is non-existent, then the command gives a zero, telling you the shield isn’t plugged in or significantly damaged. I’ve been framing the question in the context of the example, which still doesn’t make sense to me yet since it can fail and the command never gets checked again. I’m going to move on and just assume that zero means there’s a hardware problem that you need to physically inspect to correct.

I’m working on getting a threshold that is more sensitive for the wake. Seems like the lowest value I can use is 4. I looked through this https://www.st.com/resource/en/datasheet/cd00274221.pdf and can see that ACT_THS uses 7 bits of that register. I also saw a comment in an example somewhere else that a lower value is a lower threshold, makes sense. Values of 0, 1 or 2 seemed to disable the wake feature though. Thanks again for the help, and Happy New Year :wink: going to see The Mule now.

To answer that, you may need to look into the implementation of that function
https://build.particle.io/libs/Adafruit_LIS3DH/1.0.3/tab/Adafruit_LIS3DH.cpp Line 351ff

But as it turns out, that particular library would only ever return success - don’t ask my why Adafruit has originally implemented it this way :wink:

However, since the actual setup is a multi step procedure it is (would be) good practice to check for each individual step whether it actually renders the expected result and if it didn’t bail out of the function and report failure.
And hence checking the return value of the function (even if the current implementation never will fail) is good practice too - after all, the implementation might be extended and then your application can already handle it.

BUT, I’d actually not use the AssetTracker library but rather the more sophisticated AssetTrackerRK library.

1 Like

In other words, if moving the device is what lead to it waking up from sleep (versus a timer), then awake would equal 1. Did I understand that correctly? It is always 1 for me from the tests I’ve been running.

I’ve been having problems with it never waking up. I think part of the problem was going to sleep with it the device still moving, but not enough to trigger my “bump” logic that keeps it awake. I’m rewriting that and doing more testing. That issue stems from what I’ve seen with it in the glove box of my car.

The other issue with it never waking up seems to be related to it being powered by the USB plug. I’m only ever using USB to charge it. I’ve left it on my kitchen table, powered by battery only, completely still and it would always wake up. However, if I was charging it via USB, there were times it would become non-responsive. No wake up from a bump or a timer. Had to press reset.

Are there any known issues with sleep and charging it?

Edit: And I have been using the AssetTrackerRK library since it was suggested.