Assemble Electron + Asset tracker

Hi Everyone,
I am a real newbie to electronics… I hope this friendly crowd will excuse me :smile:

I received last week the Kickstarter Electron + Asset tracker kit… and I am having troubles putting all together.

I managed successfully to register the Electron on the 3G GSM network and get it on line, but I could not find any hints or instructions on how to link the Asset tracker to it… how to put all together from Hardware point of view. Does anyone have any tutorials? There are so many information on the particle.io website but I could not find anything which helps.

Then I will work on software flashing… that will be fun also :smile:
Thank you a lot

GG

You Electron is obviously set up already (with antenna, SIM and battery).

So you just pop the Electron into the headers so that the pin names on the shield line up with the ones on the Electron.
And if you’ve got a coin cell, just push it into the holder (plus up).

That’s all you need to do to get started.

1 Like

Wow… just plug the Electron on top of the headers of the tracker… LOL… THANK YOU… sounded too easy :smile:

I did it… plug in… there are no less going on the tracker… guess I need to work on the software now.

Thank you

It looks like you have your Electron mounted backwards. You should do a 180 before you start connecting things.

1 Like

Hmm, I wonder why I wrote this :confused:
The way you mounted the Electron does exactly the opposite!

What it means:

Put the Electron so that
Vin on the shield is next to Vin on the Electron,
3V3 on the shield next to 3V3 on the Electron,
B0 on the shield next to B0 on the Electron,
C0 on the shield next to C0 on the Electron and
all the other pins should fall in the right places this way too.

But I have been surprised before :sunglasses:


@JoseJones, please more specific: 180° on which axis :wink: ? (one out of three)

1 Like

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.