Card.status is never "connected"?

card.Transaction rsp {‘status’: ‘{normal}’, ‘storage’: 3, ‘time’: 1620151005}

In my other units, I always get:
{‘connected’: True, ‘status’: ‘{normal}’, ‘storage’: 4, ‘time’: 1619734050}

The hub.set is in mode:continuous as usual.

So why would this Notecard not say “connected”:True?
It is doing its sync, moving data, nothing otherwise unusual.

Is it “not connected” or the API not responding with the “connected”?
Am I missing something?

Either way, it would be logical for the response to say “connected”:False rather than omitting it :wink:

Looks like it disconnects all by itself:

running generic command: hub.status
card.Transaction rsp {‘connected’: True, ‘status’: ‘connected (session open) {connected}’}

a minute or so later:

running generic command: hub.status
card.Transaction rsp {‘status’: ‘idle (since 2021-05-06T20:32:16Z) {disconnected} {idle}’}

Is the Notecard configured to use GPS (card.location.mode, card.location.track ) ?
Could you also let me know the firmware version & build number ?

To really debug this further could you capture a trace spanning several minutes, which will hopefully show the Notecard connecting and disconnecting.


card.Transaction rsp {‘mode’: ‘periodic’}
card.Transaction rsp {‘stop’: True}
firmware: (it was doing the same under

Are you using GPS ? I’m a little confused as to why card.location.mode is set to periodic, but no “seconds”/ period is defined.

There is GPS connected, but no need for GPS (for now). No location is sent to Notehub.
My understanding was that if hub.set is in “continuous” mode the modem would stay connected.
I also know that both hub.set and card.location.mode cannot be in “continuous”.
Is card.location.mode:periodic preventing the modem to stay connected?

The card.location.mode,periodic may be causing the session to disconnect - the only way to be certain is to capture “trace” for 5-10 minutes (or for long enough to show the disconnection of the session).

Could you send me the response to
so I can see if there are any environment variables related to GPS period. thanks.

{‘body’: {‘project_1’: ‘oxi’, ‘_log’: ‘1’, ‘_req’: ‘1’, ‘fleet_action’: ‘stay hydrated in hot days’, ‘fleet_rec2’: ‘bingo’, ‘fleet_rec3’: ‘chess’, ‘fleet_rec5’: ‘black cat’, ‘_fwc’: ‘notecard-$20210308204538.bin’, ‘_fwc_retry’: ‘1610591170’, ‘_tags’: ‘anems’}}

I set card.location.mode = off, rebooted, confirmed it was set to off, hub.sync
→ fixed

This implies that web.x commands won’t work if the GPS is set in any other mode besides “off”?

“This implies that web.x commands won’t work if the GPS is set in any other mode besides “off”?”

I’m not sure I’d go that far. The card.location.mode configuration of mode:periodic without specifying an interval for the GPS period (second:N) is unusual, and may be the root cause (though I will have to try this on my device tomorrow).

You could try setting:


and see how the continuous connection to Notehub works out. It should disconnect to make the GPS fix at most once per hour, and only if the accelerometer has detected movement.

I did have:
rsp {‘stop’: True}
so that’s why I did not set the “seconds” to anything – and why I did not have any GPS activity.

I’m going to try to reproduce this so that I can troubleshoot.

I was able to reproduce the problem - it is due to the card.location.mode being set to periodic (even though seconds=0). I will research a fix for the next developer release.
Please note that the setting of card.motion.mode,strop:true and card.location.track,stop:true will not help - the Notecard thinks it needs to make an initial GPS fix, but because of card.location.mode,seconds being zero it never powers on the GPS to make that first fix.

I think you have two options:

  1. Set card.location.mode to “off”, since GPS is not currently required.
  2. If for some reason you must leave card.location.mode as periodic set a really long period:
    {“req”:“card.location.mode”,“seconds”:31536000} (Fix once per year). The Notecard will attempt to make a single GPS fix at each restart but will then remain in hub.set continuous mode.

This is timely. I am using GPS. I checked the fix (perfect) unplugged the unit, plugged it back in again, then nothing worked. After some fiddling I noted the led flashed red quickly then went off so I used the reset switch and got a green flashing led.

I can’t get much to work any more. No GPS, no card.time (with lat, long, no card.status connected, nothing.

There seems to be relationships between GPS and modem but I don’t understand what they are. I do not understand why modem continuous and GPS continuous are mutually exclusive. I don’t understand why I set the GPS mode to continuous and get the message GPS inactive.

Please advise.

{“status”:"{network-up}",“count”:1,“net”:{“iccid”:“89011703278520611271”,“imsi”:“310170852061127”,“imei”:“864475044280062”,“modem”:“BG95M3LAR02A03_01.006.01.006”,“band”:“LTE BAND 12”,“rat”:“emtc”,“rssir”:-73,“rssi”:-73,“rsrp”:-101,“sinr”:121,“rsrq”:-15,“bars”:1,“mcc”:302,“mnc”:610,“lac”:55510,“cid”:141197070,“updated”:1620394181}}


{“status”:"{modem-off}",“count”:1,“net”:{“iccid”:“89011703278520611271”,“imsi”:“310170852061127”,“imei”:“864475044280062”,“modem”:“BG95M3LAR02A03_01.006.01.006”,“band”:“LTE BAND 12”,“rat”:“emtc”,“rssir”:-83,“rssi”:-84,“rsrp”:-107,“sinr”:155,“rsrq”:-10,“bars”:1,“mcc”:302,“mnc”:610,“lac”:55510,“cid”:141197070,“updated”:1620394196}}

{“err”:“cannot simultaneously use ‘continuous’ card.location.mode and hub.set modes”}
{“status”:“GPS inactive {gps-inactive}”,“mode”:“continuous”}
{“status”:“GPS inactive {gps-inactive}”,“mode”:“continuous”}
{“status”:“GPS inactive {gps-inactive}”,“mode”:“continuous”}
{“status”:“GPS inactive {gps-inactive}”,“mode”:“continuous”}
{“status”:"{modem-on}",“count”:1,“net”:{“iccid”:“89011703278520611271”,“imsi”:“310170852061127”,“imei”:“864475044280062”,“modem”:“BG95M3LAR02A03_01.006.01.006”,“band”:“LTE BAND 12”,“rat”:“emtc”,“rssir”:-81,“rssi”:-82,“rsrp”:-106,“sinr”:151,“rsrq”:-10,“bars”:1,“mcc”:302,“mnc”:610,“lac”:29044,“cid”:8812296,“updated”:1620394804}}


  • In my location, it does take quite some time to get a fix, sometimes never with the Notecarrier A. With the hat, it took an external (“hockey pock”) antenna (active) to get a reliable fix, and that takes in my case 50+ seconds.
  • any change of the modes (continuous,periodic,off) for the hub and location requires a power cycle, otherwise the notecard seems confused

My 2 cents: it would be great if the documentation offered a table with all the combinations and their outcome as I am equally confused on the interaction between the modem and the GPS – even without throwing motion detection in the mix.

In my case, once I get fix on power up I’m OK. There is some weirdness when I move the device but I’ll deal with that later.

In this case, the Notecard seems to have stopped connecting to the network or providing a fix. It says it is connected to the network but acts as though it is not.

As I noted elsewhere

After going back to basics I realized that I was passing bad data in the


My notehub address is com, not org


As such, hub syncs were not happening. It appears than unless a sync is done, things like card.time is not populated. I would have expected card.time to reflect the network information (i.e. tower coordinates, local time, etc), and independent of a valid sync. Because there was no error I didn’t realize this until I stated from scratch and noticed a

{“alert”:true,“status”:“connect delayed (57 min remaining): opening notehub: no project was found with product UID product:org.documenteddesigns.brian:test_project_1 {product-noexist} {service}{extended-service-failure}”,“time”:1620398664,“completed”:9}

I think this is a transient message: if you don’t ask for hub status at the right moment you miss the message and just realize the sync reply isn’t right.

I believe this is pretty opaque, especially to people learning the system. I might be wrong about these various things but either improved documentation or better yet, improved error messages might be useful.

The Quectel BG95 modem also provides the GPS function, but it cannot perform simultaneous GPS and cellular because of a shared RF front end within the modem chipset.

This is why the Notecard responded with {“err”:“cannot simultaneously use ‘continuous’ card.location.mode and hub.set modes”} when you attempted to set the data connection and GPS to continuous mode.

You mentioned “With the hat, it took an external (“hockey pock”) antenna (active) to get a reliable fix, and that takes in my case 50+ seconds". I estimate 10-15 seconds of this time is taken switching the BG95 from cellular to GPS mode – there is a very noticeable latency, compared to a standalone GPS, which will offer an instant startup.

We are developing an external, standalone GPS, in a stackable hat form factor, for the Notecarrier A series for customers who require simultaneous continuous data connection and continuous GPS, or who require the highest performance GPS (the GPS antenna of the Notecarrier A family is constrained by the proximity of so many other components, and you may experience significant fix times in challenging GPS environments such as an indoor location).

Regarding GPS, if the Notecard is in card.location.mode:periodic it will only enable the GPS if movement is detected via the accelerometer. If it is in card.location.mode:continuous motion is not required.

If you set the hub.set mode to continuous, and the card.location.mode to periodic, with a period in seconds, then the Notecard will maintain a constant connection to Notehub, except for when movement has been detected and the “seconds” period has elapsed, at which point it will disconnect from Notehub, attempt to make a GPS fix, and then re-connect to Notehub.

“any change of the modes (continuous,periodic,off) for the hub and location requires a power cycle, otherwise the notecard seems confused”. I don’t believe this is the case, but if you have a repeatable test that causes this please let me know and I will try to recreate it.

I will look into your comment about the mismatch of ProductUID not causing a lasting, clear error message.

Thank you for the explanation.
So, for my situation:

  • There is a bug where card.location.mode:periodic without “seconds” specified prohibits hub.set:continuous to stay connected. The workaround is to set seconds to some huge number. An upcoming firmware will fix it (or make seconds required if periodic is set)
    The above assuming there is no motion tracking.
  • The required restart is most likely related to the problem above – trying to switch back and fort between GPS and continuous hub while the GPS is in periodic.

Francois, you are correct, but I think the better workaround is to set card.location.mode to off. Since the seconds is 0 and card.motion.mode is stopped there is no benefit to have card.location.mode set to periodic.


I think you might be conflating some of my comments with those of Francois. Thanks for explaining the issue with Quectel and GPS. I was not aware of the exclusive nature of the two functions. This also explains why I lose GPS when I sync (I was going to ask …)

I will probably add an external GPS to my platform and use the Notecard as a modem. Most GPS applications I can think of require fairly constant monitoring of location, even if they don’t update that location remotely. I am working on a timing test but it looks like a sync causes lost of GPS for 10 minutes or more. You can travel a lot of ground in 10 minutes …

edit: I did my test

** Started at 19:55:11
Waiting to attach to a tower . Attached

** Demo (sync)
Fix 0.000000, 0.000000 19:55:13
Fix 0.000000, 0.000000 20:7:44
Fix 43.532877, -80.031371 20:7:59