Web.Get location data issue

Notehub.io
1

I’m having an issue with a Web.Get Route. I am using a separate GPS module so that I may keep a continuous cellular connection and log location quickly when necessary. The location data coming from the separate GPS module is correct.

My problem is that when data is logged to _web.qo from the Web.Get Route, the location data in the JSON is incorrect. The location in the body is correct because it is coming from the GPS module. It is almost as if it is seeing the last GPS location from the notecard gps that I used before switching to the separate module (just a wild guess).

I’m probably not doing this correctly, but……here is the Web.Get Route info…..

Here is the URL (removed the HTTPS:// to keep it from making it a link:

I have the body nested inside the body is because [.body.xxxx] was returning a null string, so I threw everything at the wall to see what would stick…and this worked (different issue, possibly).

“ny3.blynk.cloud/external/api/logEvent?token=[token]&code=vehicle_motion&description=[.body.body.vehicle]%20is%20[.body.body.motion]%0D%0ATracking%20Enabled:%20[.body.body.tracking_enabled]%0D%0A%0D%0A[.body.body.local_time]%20Location:%0D%0A[.body.body.location_url]“

And the JSONata:

{“body”:

{"local_time": $fromMillis(body.time*1000, '[Y0001]-[M01]-[D01] [h#1]:[m01]:[s01][P] [z]', body.tz_offset),
"vehicle": body.vehicle_name,
"location_url": "https://www.latlong.net/c/?lat=" & $string(body.latitude) & "&long=" & $string(body.longitude),
"motion": body.motion,
"tracking_enabled": body.tracking_enabled ? "Yes" : "No"

}

}

body.latitude, body.longitude, body.time, body.tz_offset, body.tracking_enabled are pulled from the original note created.

Here is the JSON in the _web.qo file:

{
“event”: “020ad850-82e5-4b18-a80d-xxxxxxxx”,
“when”: 1754249958,
“file”: “_web.qo”,
“body”: {
“body”: {
“local_time”: “2025-08-03 2:39:12pm GMT-05:00”,
“location_url”: “https://www.latlong.net/c/?lat=xx.0062&long=-yy.127”,
“motion”: “Stopped”,
“tracking_enabled”: “No”,
“vehicle”: “[name]”
}
},
“session”: “efa14688-dc49-4861-9eb3-xxxx”,
“best_id”: “dev:xxxx”,
“device”: “dev:xxxx”,
“product”: “product:com.xxx.xxxxx”,
“app”: “app:0de33366-45c4-40b5-b375-xxxx”,
“received”: 1754249969.282741,
“req”: “web.get”,
“best_location_type”: “triangulated”,
“best_location_when”: 1754179207,
“best_lat”: xx.915152,
“best_lon”: -yy.062451,
“best_location”: “city state”,
“best_country”: “US”,
“best_timezone”: “America/Chicago”,
“tower_when”: 1754182905,
“tower_lat”: xx.915892,
“tower_lon”: -yy.06781,
“tower_country”: “US”,
“tower_location”: “city state”,
“tower_timezone”: “America/Chicago”,
“tower_id”: “310,410,14976,461xxxxxxxxx”,
“tri_when”: 1754179207,
“tri_lat”: xx915152,
“tri_lon”: -yy.062451,
“tri_location”: “city state”,
“tri_country”: “US”,
“tri_timezone”: “America/Chicago”,
“tri_points”: 7,
“status”: “success”,
“fleets”: [
“fleet:27ac1d7c-4cd9-4bc6-b890-xxxxxxxx”
]
}

Thanks,

Joe

2

Hi @scavoj,

There’s a couple of things I’m looking at here:

The best_location_type is “triangulated”, which means it used Wi-Fi triangulation to calculate the location from the Notecard. That location data is, by default, calculated only once per day (but can be overridden). It’s also about 2 hours behind the local_time that you populated in the Note body, so clearly you are getting a more recent location from somewhere else.

Did you issue the {“req”:“card.aux.serial”,“mode”:“gps”} request to tell the Notecard to use the external GPS? Or are you accessing location data from the external GPS separate from the Notecard?

I’d agree that it looks like the Notecard is just using its last known location, but your body contains more recently acquired info.

Rob

3

Yes, I used {“req”:“card.aux.serial”,“mode”:“gps”}. That correct GPS data is being used in the web.get route body.

I did notice the triangulated loc type and the behavior I’m seeing is congruent with your explanation.

I just now need to figure out why when I take the lat and long from the card.location request and place it in the body, it seem to be losing accuracy. It seems to cut it off after 4 decimal places. Does notehub trim floating point numbers? If not, I’ll just play around with it to find a solution.

Thanks,

Joe

4

Hi @scavoj,

I’m curious if the “best” values have changed since you last looked? It should be using GPS as the “best” so this may be something I have to escalate here.

In terms of your lat/lon data, Notehub doesn’t trim anything, so it must have to do with how you are casting/formatting those values. Try using a double if you are using float for instance.

Rob

5

It is still showing

“best_location_type”: “triangulated”,

“best_location_when”: 1754179207,

“best_lat”: xx.915152,

“best_lon”: -yy.062451

with the body values of

“body”: {

“local_time”: “2025-08-05 11:55:53am GMT-05:00”,

“location_url”: “www.latlong.net/c/?lat=xx.9171&long=-yy.0492“,

“motion”: “Stopped”,

“tracking_enabled”: “Yes”, “vehicle”: “vehicle” }

And a when value of:

“when”: 1754412956

which is different than the best_location_when.

Most of the time, the notecard is kept at the best_lat and best_long location, unless I take it out for a ride for testing. This data is while I was at a different location.

And local_time is using the time from {“req”: “card.location”}, which has been accurate.

Thanks,

Joe

6

It looks like the lat/lon values coming from the gps module thru the notecard is capped at 4 decimal places. Do you know if there is some setting which increases the accuracy of the gps values? All I saw was the speed (baud rate) setting which I have set at the default of 9600.

Thanks,

Joe

7

Hi @scavoj,

  1. It might be worth trying to increase the cadence at which Notecard/Notehub use triangulation to ascertain the device’s location, just to see if that changes the results of the “best” location.
  2. ”when” in an event is the timestamp for when the Note was queued on the Notecard and won’t have anything to do with location data.
  3. There is no alteration of GPS values from an external GPS. I would inspect the path of data from the GPS to the Note to see if there is any casting of the data type etc that could impact how it’s formatted.

Rob

8

Thanks, Rob.

1 - I increased the cadence to unlimited to see how the values compare. I haven’t taken it out on a field trip yet.

3 - I have verified that the JSON returned by the {“req”: “card.location”} request is only giving me 4 decimal places but I’m getting 15 decimal places when gps shows up as best location type on a note.add request.

I have another question regarding the best location type. After I issue a note.add request where I’m getting up to 15 decimal places for the gps location (in best_lat/lon), I issue a web.get request. The JSON in this request shows triangulated as the best location type almost as if it is not looking at the gps values. After looking through Notehub Walkthrough - IoT Connectivity at Blues , it would seem since the triangulated data was old, that the GPS values would be used. I’m just trying to understand what could be going on.

Edit: One thing I thought of is that I have hub.set outbound set to 0 since I do explicit syncs. Is this a problem with the above discussion?

Thanks,

Joe

9

Hi @scavoj,

Can you tell me what version of the Notecard firmware you are running (try a card.version request). I’m wondering if you’re on an older version that is causing these issues.

That should be fine. Instead of this, you can use ”mode”:”minimum” in your hub.set request, which requires explicit syncs to perform any inbound/outbound behaviors FYI.

This one is mind-boggling to me. I’m hoping it’s related to old firmware issue so let me know what version you are on and we can move forward from there!

Thanks,

Rob

10

Rob,

The version response and {“req”: “card.location”} responses are below. But I failed to mention that I am using CircuitPython (I intended to edit my post…sorry). So maybe the python libraries have something to do with it.

I have both GPS and the notecard set to continuous mode. When I get movement, I need the data in seconds.

Thanks,

Joe

{
“version”: “notecard-9.1.1.17181”,
“device”: “dev:351077454560213”,
“name”: “Blues Wireless Notecard”,
“sku”: “NOTE-WBGLWT”,
“ordering_code”: “HB0YT1N0AEAU”,
“board”: “5.13”,
“wifi”: true,
“cell”: true,
“gps”: true,
“body”: {
“org”: “Blues Wireless”,
“product”: “Notecard”,
“target”: “u5”,
“version”: “notecard-u5-9.1.1”,
“ver_major”: 9,
“ver_minor”: 1,
“ver_patch”: 1,
“ver_build”: 17181,
“built”: “Apr 15 2025 11:34:37”
}
}

{‘time’: 1755716250, ‘lon’: -90.xxxx, ‘status’: ‘GPS updated (428392 sec, 36/49 dB SNR, 8/8 sats, HDOP 1.06) {gps-active} {gps-signal} {gps-sats} {gps}’, ‘crc’: ‘0010:FEA4D55D’, ‘lat’: 29.xxxx, ‘mode’: ‘continuous’, ‘dop’: 1.06}

11

Hi @scavoj ,

I would recommend trying v9.2.3 of the Notecard firmware. There were some significant bugs fixed re: GPS in recent versions that may help here. CircuitPython shouldn’t matter as this is a lower level issue.

Also, 428392 sec is concerning, as this means the GPS location from the external module hasn’t updated in days.

As an aside, I just read back through this thread and realized you don’t need to use the Web requests to route data to Blynk. There is a dedicated Blynk route in Notehub you could use instead.

Rob

12

Thanks, Rob.

I updated the firmware:

{
“version”: “notecard-9.2.3.17324”,
“device”: “dev:351077454560213”,
“name”: “Blues Wireless Notecard”,
“sku”: “NOTE-WBGLWT”,
“ordering_code”: “HB0YT1N0AEAU”,
“board”: “5.13”,
“wifi”: true,
“cell”: true,
“gps”: true,
“body”: {
“org”: “Blues Wireless”,
“product”: “Notecard”,
“target”: “u5”,
“version”: “notecard-u5-9.2.3”,
“ver_major”: 9,
“ver_minor”: 2,
“ver_patch”: 3,
“ver_build”: 17324,
“built”: “Aug 11 2025 12:07:58”
}
}

But I’m still getting only 4 decimal places.

As far as the GPS updating, I never noticed that value. Every time I’ve tested it, It gave me the correct location.

I am using the dedicated Blynk Route to pass data to the data streams. I was using the web.get Route to send a logEvent to have Blynk send me an email and to send a push notification to my phone. I could’t figure out any other way to do it (Blynk docs are difficult to read). I also have another web.get Route to modify the url for a WebPage Button on the Blynk ios app. Just having the button associated with my url data stream didn’t work. So this is the solution I came up with. I have since broken this one and haven’t had the time to fix it.

Thanks,

Joe

13

Hey @scavoj,

I’m working on trying to figure out what’s going on with this bit.

But I’m still getting only 4 decimal places.

I just connected an external GPS to a Notecard running 9.2.3.17324 and I got plenty of decimal places back for my location.

~ DeviceUID dev:860322067941481 (NOTE-WBNAN) running firmware 9.2.3.17324
> {"req":"card.location"}
{
 "status": "GPS updated (253 sec, 28/44 dB SNR, 6/6 sats, HDOP 1.28) {gps-active} {gps-signal} {gps-sats} {gps}",
 "mode": "continuous",
 "lat": xx.76351333333334,
 "lon": -xx.64799666666669,
 "dop": 1.28,
 "time": 1755782891
}

With that in mind, a couple of questions that might help us figure out what’s going on.

  • Can you verify that the time in your card.location response is recent? Let’s make sure you’re getting a new reading since you updated to 9.2.3.
  • Can you share which external GPS module you’re using and how you have it wired?

TJ

14

Hey TJ,

I grabbed the card.location from the CircuitPython code and then from the In-Browser Terminal (a minute or less apart). I am using the latest Ultimate GPS Breakout from AdaFuit. The time in this test looks good. I was out and about today and the GPS position logged to notehub is correct (with only 4 decimal places).

CircuitPython:

{‘time’: 1755813168, ‘lon’: -xx.0624, ‘status’: ‘GPS updated (73607 sec, 43/49 dB SNR, 9/9 sats, HDOP 0.90) {gps-active} {gps-signal} {gps-sats} {gps}’, ‘crc’: ‘0005:E8226B91’, ‘lat’: xx.9153, ‘mode’: ‘continuous’, ‘dop’: 0.9}

In-Browser Terminal:

{
“status”: “GPS updated (73700 sec, 43/49 dB SNR, 10/10 sats, HDOP 0.78) {gps-active} {gps-signal} {gps-sats}”,
“mode”: “continuous”,
“lat”: xx.91527166666667,
“lon”: -xx.06244,
“dop”: 0.7800000000000001,
“time”: 1755813259
}

Thanks,

Joe

15

Can you share the bit of your firmware you’re using to create the Note? (If there’s anything in there you don’t want to share publicly feel free to DM me.)

Considering that the data looks ok for the best_location fields in Notehub, I feel like something in the firmware must be truncating the locations that end up in body.location_url.

TJ

16

TJ,

I hope I didn’t forget anything. But here are the highlights of what the code does. I didn’t expect the # symbol to create bold text. And I can’t get the indentation on the two functions correct.

I ran it again and here are the results:

External GPS Setup Response: {‘crc’: ‘0003:FC75CD9B’, ‘mode’: ‘gps’, ‘rate’: 9600}

GPS Setup Response: {‘mode’: ‘continuous’, ‘crc’: ‘0004:4A00FC75’}

build_note_body(): gps_location_response: {‘time’: 1755988995, ‘lon’: -xx.0623, ‘status’: ‘GPS updated (249438 sec, 37/49 dB SNR, 8/8 sats, HDOP 0.94) {gps-active} {gps-signal} {gps-sats}’, ‘crc’: ‘0010:6BF42631’, ‘lat’: xx.9152, ‘mode’: ‘continuous’, ‘dop’: 0.94}

Thanks,

Joe

DEBUG: bool = True
…
i2c: busio.I2C = busio.I2C(board.SCL, board.SDA)
ncard: notecard.OpenI2C = notecard.OpenI2C(i2c, 0, 0, debug=False)
…
external_gps_setup_request: dict = {“req”: “card.aux.serial”,
“mode”: “gps”}
gps_setup_request: dict = {“req”: “card.location.mode”,
“mode”: “continuous”}
gps_location_request: dict = {“req”: “card.location”}
…
def output(msg: str, debug: bool = True):
if debug:
print(msg)
…
def get_gps_location(gps_location_command: dict) → dict:
return ncard.Transaction(gps_location_command)
…

Setup GPS

response = ncard.Transaction(external_gps_setup_request)
…
response = ncard.Transaction(gps_setup_request)
…

Retrieve GPS information

gps_location_response: dict = get_gps_location(gps_location_request)

Below is what generated the JSON output in a previous post showing the 4 decimal places for lat and lon.

(i.e., gps_location_response only contains 4 decimal places for lat and lon)

output(f"build_note_body(): gps_location_response: {gps_location_response}", DEBUG)

body is the body that I’m creating for the Note to be sent

…
body[“latitude”] = gps_location_response[“lat”]
body[“longitude”] = gps_location_response[“lon”]
…

17

Thanks @scavoj,

One thing that could be going on: CircuitPython prints floating-point numbers with 6 significant digits by default. I wasn’t aware of this, but this came up in a few of the searches I’ve been doing trying to figure out what’s up.

To test, can you try running this from your host firmware to see if you get additional digits back?

output(
    f"lat={gps_location_response['lat']:.7f}, lon={gps_location_response['lon']:.7f}",
    DEBUG
)

I noticed that Adafruit’s tutorials use similar syntax when printing coordinates, for example:

       print(f"Latitude: {gps.latitude:.6f} degrees")
       print(f"Longitude: {gps.longitude:.6f} degrees")

TJ

1 Like
18

TJ,

Awesome. You are correct. When I take a str and cast it to a float, it rounds to 4 decimal places. So my solution is just to use strings in the note body (which is just going to get concatenated into the url anyway).

Thanks for your help.

Joe

2 Likes