Electron Cellular Locate Test App

General
1

Hey All!

The Electron has a cool feature called CellLocate where it can provide triangulated GPS coordinates based on signal strength of Cell Towers nearby.

Screen Shot 2016-03-11 at 4.03.32 PM.png921×330 92.2 KB

Here’s a white paper from u-blox describing the feature:
Hybrid positioning and CellLocateTM

Below is a little test application I came up with last night to play with the feature, see how it works and what we might want in the official API. In practice the LAT/LONG is always kind of near one of three locations by me, but it’s close enough for not being a fully fledged GPS device. I’ve yet to take it on the go and see how it improves as I pass near other towers, or more urban areas with higher cell tower density.

This code is not super ideal because it has to poll the Cellular.command() with an empty string to grab the UULOC URC, and we have to wait in a hard loop to prevent the system thread from polling sockets and accidentally reading in the URC. In the real implementation this will all be handled for you, with a CellularLocate class object that will manage everything you’ll need and won’t require a blocking loop. It’s also currently done in straight C to keep it simple for a test.

The initial response usually takes quite a while to return, up to the full 60 second timeout (supposedly this timeout can be 1-999 seconds so try to play with it and see what happens). But thereafter the response usually comes right away, and you can see it is updating… so my guess is some work is done during that first call, but successive calls are returned quickly if we remain stationary.

Give it a test and see how it works for you, and please report any issues you find with it. Note it may not work at all for you if you are in a fairly rural area.

Open a serial terminal and press L or l to kick off the process. You should get a nice URL to put into your browser.

If you don’t get a valid location the first time, try again. There are a lot of factors that go into this working or not, and a lot of it depends on how much data u-blox has in their AssistNow server for your device and coverage area.

You shouldn’t need this, but I’ve also added a command that will set the AssistNow server back to factory defaults which is required for this to work. It should be set already though, but just in case you are having problems, press A or a for this. It should end with OK! if all went well.

This will compile in the Build IDE or locally with v0.4.8-rc.6 or develop#213e18b668 firmware.

17 Likes
2

@BDub I just had a new Electron arrive today and just got it setup and I came across your new code here so I figured I would give this a try real quick :smiley:

I have been following others who have been attempting to do this for a few weeks now with no luck even with asking Ublox support for help. So it’s really nice to see that you have this all figured out. @jvanier @dchatenay @Eric24

I am right outside of a major city with plenty of cell towers near by.

I ran the test and it put me less than 2 miles from where I’m sitting which I think is pretty dam good considering it’s not GPS but a addon feature. I’ll keep testing as I move this around in the vehicle to different locations and cities with less towers.

Good work :smiley:

Side note: What’s the status on getting that System.sleep() fixed up?

1 Like
3

@BDub I took the laptop and electron with me on a little trip around the city today to see how the location tracking worked at various different spots of the city.

I’m impressed with how close it gets without it actually being GPS. So far I would say it pins my location to be within a 1/10th of a mile up to 1 mile away from where I actually am.

See the pictures below. The RED pin is where it says I am. The Green Triangle is where I actually was.

This was the closest it got my location. I was right across the street. Tons of cell towers around here.

You can see the Uncertainty = 286 which is low. So the lower the number the closer it will be to your true location.

Pasted image852×113 4.09 KB

This one is further away and the Uncertianity on this one was higher in the 2000 range:

Pasted image844×231 3.98 KB

Pasted image951×706 1.09 MB

Another close one.

Pasted image769×135 4.13 KB

Pasted image951×666 199 KB

2 Likes
4

Hi, I tested with develop branch, worked without a problem out of the box. I am in a somewhat rural area, so not too many cell towers around. The first reported location was about a kilometer off, later it got closer. All it all a very nice tool to have. So +1 for me to include that in the firmware! Thanks a lot.

2 Likes
5

Works great for me Thanks! What is UNCERTAINTY? In feet 5141? MATCHED_COUNT?

6

Meters... this is how uncertain the coordinates are about where you really are. If you imagine drawing a circle around the coordinates reported, with a radius equal to the Uncertainty... you should be inside that circle.

This is just a little debugging statement for how many of the callback parameters were matched. You need at least 8 to include the coordinates. 17 is all of them. Typically they should all come back, but the way sscanf works, it's possible to get some noise in the serial line and just the right time that may keep the data from completely parsing. So we do error checking and look to see that at least 8 matched before trying to use the coordinates. There's more you could do as well... like checking for non zero coords and such.

3 Likes
7

Worked well for me. Off by 622 feet, which seems pretty reasonable for triangulation in a sparsely populated area. Uncertainty value was 1000 meters.

8

Anybody calculate how much data it uses? How long it takes at the most? What if you run it 10x while moving slowly. Is the average of those 10 better than 1?

9

Ran this a few times over the day and each time got the same answer - about 3500m away from my actual location. The uncertainty ranged from 850m to 139,000m on the calls.

1 Like
10

I would expect the same answer if you don’t move at all. But if you do move slowly around trees and buildings, it might improve because of multipath. The accuracy is much worse when you’re indoors (with my mobile phone app), because you signal may be going out only one particular window. How much data do your queries use when you divide by the number of times?

11

Weird bug tonight. I was consistently getting the correct Lat and -3.7957644 long. Put me in the middle of Madrid, I’m in Philly. Printed buf variable. Used original code. I reset a few times same exact result. Disconnected the Lipo, now I get the correct answer -75.603630. The odd thing is I get the exact same answer every time. Only the uncertainty changes. Will try walking tomorrow.

12

I tested the code on my 2G electron. I get weird results as well.

The first request of the day locates me with an accuracy of couple of miles. However the subsequent requests keeps the coordinates same and increases the uncertainty over time. Within 5 to 10 min it goes from a 500 uncertainty to 10000 although my physical location (midwest) did not change.

I started driving driving around, same results, coordinates did not change and the uncertainty kept increasing, seemed independent of my physical location.

I tried reset, reflash, no change.

13

Ditto @srvn13 . Anyone else? This would have been really cool!

Sensor_used is always 0, after the first time. Please help anyone?

14

I have found a temporary solution to get Sensor_used = 2. I use Cellular.off() then SLEEP_MODE_DEEP. This makes it 2 every time it wakes. But the data overhead is 6k for handshake. My goal is to avoid this 6k data handshake so I can do it more often. How can we make it use the sensor without turning off the cell modem? @BDub ?

I have tried the original code above, it only works once with Sensor_used=2. I’d have to disconnect and reconnect the LiPo to get another location with Sensor_used=2.

“If the previous position degraded by the elapsed time satisfies the desired accuracy then the sensor 0 is reported in the information text response.”

How do I increase (lower) the desired accuracy? I changed the 500 to 50 in his original code, no difference.

This is what I’m running now:

void setup(){
vdoit();  //original code from Bdub
sprintf(s,"%1d %0.6f,%0.6f err=%d",loc.sensor_used,shlat,shlng,shunc);
Particle.publish("hi",s,60);
delay(500);
Cellular.off();
delay(500);
System.sleep(SLEEP_MODE_DEEP, 10*60);
}

@Stevie Does the original code work for you when you press L more than once? For me the location never changes, but the Uncertainty increases with elapsed time as mentioned in the PDF link above.

Is it possible I’m not moving far enough in my tests? I’ve been walking over to the other side of the hill without any change Sensor=0. Perhaps if I drive further it will realize it moved and capture another Sensor=2? It is transmitting and receiving data every time.

Update: Drove really far. Always Sensor=0 except the first time. Many missing values in the Publish log. The location never changes.

@RWB Do you only press L in each of the examples above? Or do you reset? Or do you power off between locations? I notice each time your sensor is 2. Which hardware version of the Electron?

15

@sbright33 For my testing I powered down each time after pressing L and getting the location.

I just pulled the laptop out at the different locations and plugged in the electron via USB and pasted the link into the browser.

16

That’s the problem. There’s no way to automate the original code without a keypress. Without powering down. Without the 6k handshake data every time. Great code! It would be so much better if it worked more than once! Anyone overcome this limitation? Any suggested changes?

17

@sbright33, I powered it down for my measurements in between the different locations. What you can maybe do is to disable the cloud usage. Then I think (and it seems to be proved by the dashboard) that it does not use the 6kb for each measurement.

18

@Stevie Please tell me more? Example code would be appreciated.
Remember there is a huge delay between handshake and data usage display on the dashboard.

19

The best way is to use

SYSTEM_MODE(MANUAL);

outside of your setup call. Then in setup you call

Cellular.connect();
while(!Cellular.ready());

After that the cellular is ready and to my knowledge the 6kB handshake - or at least a part of it - is not happening. That’s my understanding and also seems to be backed by the dashboard a couple of days later.

20

@BDub Can you verify this? What portion of the 6k will be avoided?