Web.post chunks get forwarded immediately in contradiction to documentation

I left the notecard powered off for a few hours and now it’s back to behaving normal again. (Power-cycles of about minute did not fix things). Leaving it powered on but in “off” mode overnight, also didn’t address the issue. Just to be clear, this is still with the default 250ms SEGMENT_DELAY.

The documentation talks about a continuous mode session duration. Perhaps the continuous mode session is getting corrupted somehow and I need to wait until the session has hit this timeout before things work correctly again. The documents don’t list what the default duration is.

It works when hub.status returns:

{'connected': True, 'status': 'connected (session open) {connected}'}

But it appears to not work when hub.status returns:

{"status":"connected {connected-closed}"}

Is it possible that aweb.post with a payload of 8kB is what’s causing the issue? The documentation doesn’t state a maximum payload size (for either a normal post or a fragment post). I started playing around and running with fragment sizes of 1kB and 2kB appeared to work reliably.

@bsatrom @scjerry at least with 1kB payloads, reducing the SEGMENT_DELAY doesn’t have a measurable effect because each call to send a web.post fragment is measuring to have a minimum time of about 0.6 - 1.0 seconds due to overhead in the hub communication. With 8kB payloads and a 50ms SEGMENT_DELAY I could send 64kB in ~30 seconds (i.e. about 4 seconds per 8KB chunk).

Here is the code I’m currently using:

class temporary_mode():
    def __init__(self, card, mode, wait_for_connection=True):
        self.card = card
        self.mode = mode
        self.current_mode = None
        self.wait_for_connection = wait_for_connection

    def __enter__(self):
        # get the current mode
        req = {
            "req": "hub.get",
        }
        rsp = self.card.Transaction(req)
        self.current_mode = rsp.get("mode")

        if self.current_mode != self.mode:
            # set the new mode
            req = {
                "req": "hub.set",
                "mode": self.mode
            }
            rsp = self.card.Transaction(req)
            logging.info("Setting to %s mode %s", self.mode, rsp)


        else:
            logging.info("Card is already in mode %s with response %s", self.mode, rsp)

        
        # wait for the notecard to become connected
        rsp = {}
        while self.wait_for_connection:
            req = {"req": "hub.status"}
            rsp = self.card.Transaction(req)
            logging.info("Checking connection %s", rsp)
            # 'connected {connected-closed}' might not be valid, but I haven't
            # figured out how to get the notecard out of that state
            if rsp.get("connected") == True or rsp.get("status") == 'connected {connected-closed}':
                break
            time.sleep(5)

    def __exit__(self, *args, **kwargs):
        if self.current_mode != self.mode:
            # restore the old mode
            req = {
                "req": "hub.set",
                "mode": self.current_mode
            }
            rsp = self.card.Transaction(req)
            logging.info("Restoring original mode %s response %s", self.current_mode, rsp)

from notecard import notecard as _notecard
class temporary_segment_delay():
    """
    Temporarily change CARD_REQUEST_SEGMENT_DELAY_MS.
    """
    def __init__(self, delay_ms):
        if delay_ms < 25:
            raise ValueError("segment delay less than 25ms could result in unstable operation")
        self.initial_delay_ms = _notecard.CARD_REQUEST_SEGMENT_DELAY_MS
        self.new_delay_ms = delay_ms
        
    def __enter__(self):

        logging.info("setting CARD_REQUEST_SEGMENT_DELAY_MS from %s to %s", self.initial_delay_ms, self.new_delay_ms)
        _notecard.CARD_REQUEST_SEGMENT_DELAY_MS = self.new_delay_ms
        
    def __exit__(self, *args, **kwargs):
        logging.info("restoring CARD_REQUEST_SEGMENT_DELAY_MS to %s", self.initial_delay_ms)
        _notecard.CARD_REQUEST_SEGMENT_DELAY_MS = self.initial_delay_ms


def web_post(card, route, payload, name=None, chunk_size=1024, content=None):
    offset = 0
    fragmented = ( len(payload) > chunk_size )

    s = time.time()
    # nested with to be Py 2 compatible without using contextlib
    # web.post requires continuous mode
    with temporary_mode(card, "continuous"):
        # Use a faster segment delay on web.post
        with temporary_segment_delay(50):
            while offset < len(payload):
                req = {"req": "web.post"} 
                req["route"] = route
                if name:
                    req["name"] = name
                if content:
                    req['content'] = content

                if fragmented:
                    fragment = payload[offset:offset+chunk_size]

                    req["total"] = len(payload)
                    req["payload"] = b2a_base64( fragment, newline=False).decode("ascii")
                    req["status"] = hashlib.md5( fragment ).hexdigest()
                    req["offset"] = offset
                    req["verify"] = True

                    logging.debug("sending web.post fragment of length %s at offset %s", len(fragment), offset)
                else:
                    req["payload"] = b2a_base64( payload, newline=False ).decode("ascii")
                    logging.debug("sending web.post of length %s", len(payload))

                offset += chunk_size
                rsp = card.Transaction(req)
                logging.debug("web.post response %s", rsp)
                # if data remains to be transmitted we expect a 100 request
                if offset < len(payload) and rsp.get("result") != 100:
                    raise RuntimeError("error in fragmented web.post")

    response_payload = None
    if rsp.get("payload"):
        response_payload = a2b_base64(rsp['payload']).decode("ascii")
    e = time.time()
    logging.debug("web.post took %s seconds for %s bytes", e-s, len(payload))

    return rsp, response_payload

@dirtdevil I want to attempt to reproduce your errors today locally, so thanks for sending this code sample along. Note that any text in {} are considered constants and won’t change between firmware revisions. So, looking for {connected} is a good idea. The connected boolean is critical to watch as well (if it’s false, it won’t show up at all in the response).

The default is something we established through early Notecard testing and is meant to provide a safe, conservative delay for host-to-Notecard comms. We use this same value across our C, Arduino and Python libraries. In terms of downsides, the biggest is that if you set this too low, the Notecard may not have processed your last message and responded before you send the next one. As I mentioned, I would tread 25 ms as the absolute floor, but you can experiment with lower delays for your app. I would only ask/suggest that you implement a method for inspecting the response of each message to ensure that you are getting what you want and not an error, as well as a retry function, just to be safe and defensive.

@dirtdevil I was only able to replicate your error if I disconnected the antenna from the Notecard on my Pi. I’m starting to wonder if you are running into connectivity issues? Can you try a card.wireless request to see what the results are? We will figure this out one way or another :slight_smile:

Here is what I get from doing hub.status and card.wireless (i.e. no web.post)

... prior to this I called hub.set mode=continuous, verified with hub.get and waited for the connected to go to true ...
2022-03-02 01:48:02,133
{"req": "hub.status"}
{"connected":true,"status":"connected (session open) {connected}"}
{"req": "card.wireless"}
{"status":"{network-up}","mode":"auto","count":1,"net":{"iccid":"890...","imsi":"310...","imei":"867...","modem":"BG95M3LAR02A03_01.006.01.006","band":"LTE BAND 12","rat":"emtc","rssir":-77,"rssi":-78,"rsrp":-107,"sinr":92,"rsrq":-16,"bars":1,"mcc":310,"mnc":410,"lac":4615,"cid":167136272}}

2022-03-02 01:48:08,725
{"req": "hub.status"}
{"connected":true,"status":"connected (session open) {connected}"}
{"req": "card.wireless"}
{"status":"{network-up}","mode":"auto","count":1,"net":{"iccid":"890...","imsi":"310...","imei":"867...","modem":"BG95M3LAR02A03_01.006.01.006","band":"LTE BAND 12","rat":"emtc","rssir":-77,"rssi":-78,"rsrp":-107,"sinr":92,"rsrq":-16,"bars":1,"mcc":310,"mnc":410,"lac":4615,"cid":167136272}}

2022-03-02 01:48:15,317
{"req": "hub.status"}
{"status":"connected (session open) {connected}"}
{"req": "card.wireless"}
{"status":"{network-up}","mode":"auto","count":1,"net":{"iccid":"890...","imsi":"310...","imei":"867...","modem":"BG95M3LAR02A03_01.006.01.006","band":"LTE BAND 12","rat":"emtc","rssir":-77,"rssi":-78,"rsrp":-107,"sinr":92,"rsrq":-16,"bars":1,"mcc":310,"mnc":410,"lac":4615,"cid":167136272}}

2022-03-02 01:48:21,907
{"req": "hub.status"}
{"status":"idle (since 2022-03-02T01:47:55Z) {disconnected} {idle}"}
{"req": "card.wireless"}   
{"status":"{modem-off}","mode":"auto","count":1,"net":{"iccid":"890...","imsi":"310...","imei":"867...","modem":"BG95M3LAR02A03_01.006.01.006","band":"LTE BAND 12","rat":"emtc","rssir":-77,"rssi":-78,"rsrp":-110,"sinr":78,"rsrq":-18,"bars":1,"mcc":310,"mnc":410,"lac":4615,"cid":167136272,"updated":1646185695}}

2022-03-02 01:48:28,502
{"req": "hub.status"}
{"status":"3s starting communications {wait-module} {connecting}"}
{"req": "card.wireless"}   
{"status":"{modem-on}","mode":"auto","count":1,"net":{"iccid":"890...","imsi":"310...","imei":"867...","modem":"BG95M3LAR02A03_01.006.01.006","band":"LTE BAND 12","rat":"emtc","rssir":-77,"rssi":-78,"rsrp":-110,"sinr":78,"rsrq":-18,"bars":1,"mcc":310,"mnc":410,"lac":4615,"cid":167136272,"updated":1646185695}}

2022-03-02 01:48:35,098
{"req": "hub.status"}
{"status":"10s starting communications {wait-module} {connecting}"}
{"req": "card.wireless"}   
{"status":"{modem-on}","mode":"auto","count":1,"net":{"iccid":"890...","imsi":"310...","imei":"867...","modem":"BG95M3LAR02A03_01.006.01.006","band":"LTE BAND 12","rat":"emtc","rssir":-77,"rssi":-78,"rsrp":-110,"sinr":78,"rsrq":-18,"bars":1,"mcc":310,"mnc":410,"lac":4615,"cid":167136272,"updated":1646185695}}

2022-03-02 01:48:41,693
{"req": "hub.status"}
{"status":"connected {connected-closed}"}
{"req": "card.wireless"}   
{"status":"{modem-on}","mode":"auto","count":1,"net":{"iccid":"890...","imsi":"310...","imei":"867...","modem":"BG95M3LAR02A03_01.006.01.006","band":"LTE BAND 12","rat":"emtc","rssir":-77,"rssi":-78,"rsrp":-110,"sinr":78,"rsrq":-18,"bars":1,"mcc":310,"mnc":410,"lac":4615,"cid":167136272,"updated":1646185695}}

... at this point the card can get stuck in this state for awhile, sometimes it will alternate trying to connect to wireless service ...

Your assessment that it might be poor signal strength appears reasonable. The bars is 1 or 2 and rssi is on the lower end of good to fair.

I can confirm that I have the Molex antenna installed securely and the device is not in any particularly disadvantaged situation. In fact it’s probably better than normal since it is sitting in the window.

It seems like the firmware might not be safe to call web.post unless connected: True. I’m going to change my code to never execute web.post unless connected: True.

I’m also going to try out a WBNA Notecard to see if that improves things. I’ll also try out one of my notecards that’s on the older firmware just to see if that has any better behavior in terms of connectivity. I will report here when I have results.

Thanks again!

@dirtdevil - this is very helpful, thanks. Would you mind replicating the above steps, but also include a hub.get call at the beginning and also a hub.sync.status call after each hub.status?

@RobLauer

2022-03-03 02:09:55,165
{"req": "hub.get"}
{"mode":"continuous","host":"a.notefile.net","product":"com.gmail.mike.ihde:opensync","device":"dev:867730051643769","duration":5}

At this point there was a long period of time with attempts to connect multiple times.

2022-03-03 02:11:44,662:INFO
{"req": "hub.status"}
{"status":"17s waiting for wireless service {wait-service} {connecting}"}
{"req": "hub.sync.status"}
{"status":"waiting for wireless service 9 sec [----] {cell-registration-wait}","requested":32}
{"req": "card.wireless"}
{"status":"{cell-registration-wait}","mode":"auto","count":1,"net":{"iccid":"890...","imsi":"310...","imei":"867...","modem":"BG95M3LAR02A03_01.006.01.006","band":"LTE BAND 12","rat":"emtc","rssir":-75,"rssi":-75,"rsrp":-105,"sinr":78,"rsrq":-17,"bars":1,"mcc":310,"mnc":410,"lac":4615,"cid":167134479,"updated":1646273456}}

After waiting a couple minutes without success connecting, I did a card restore followed by a restart and then…

2022-03-03 02:13:41,040:INFO:root:Action get
{"req": "hub.get"}
{"mode":"continuous","host":"a.notefile.net","product":"com....","device":"dev:867...","duration":5}

2022-03-03 02:13:41,583:INFO:root:Action monitor
{"req": "hub.status"}
{"status":"9s starting communications {wait-module} {connecting}"}
{"req": "hub.sync.status"}
{"sync":true,"requested":1}
{"req": "card.wireless"}
{"status":"{modem-on}","mode":"auto","net":{}}

2022-03-03 02:14:07,077:INFO:root:Action monitor
{"req": "hub.status"}
{"status":"connected (session open) {connected}"}
{"req": "hub.sync.status"}
{"status":"connect using TLS {socket-tls-connecting}","requested":26}
{"req": "card.wireless"}
{"status":"{network-up}","mode":"auto","count":1,"net":{"iccid":"890...","imsi":"310...","imei":"86...","modem":"BG95M3LAR02A03_01.006.01.006","band":"LTE BAND 12","rat":"emtc","rssir":-73,"rssi":-74,"rsrp":-105,"sinr":77,"rsrq":-17,"bars":1,"mcc":310,"mnc":410,"lac":4615,"cid":167134479}}

2022-03-03 02:14:20,671:INFO:root:Action monitor
{"req": "hub.status"}
{"connected":true,"status":"connected (session open) {connected}"}
{"req": "hub.sync.status"}
{"status":"merge multiple notefiles","requested":39}
{"req": "card.wireless"}
{"status":"{network-up}","mode":"auto","count":1,"net":{"iccid":"890...","imsi":"310...","imei":"867...","modem":"BG95M3LAR02A03_01.006.01.006","band":"LTE BAND 12","rat":"emtc","rssir":-73,"rssi":-74,"rsrp":-105,"sinr":77,"rsrq":-17,"bars":1,"mcc":310,"mnc":410,"lac":4615,"cid":167134479}}

2022-03-03 02:14:27,073:INFO:root:Action monitor
{"req": "hub.status"}
{"connected":true,"status":"connected (session open) {connected}"}
{"req": "hub.sync.status"}
{"status":"resetting all trackers because of session ID mismatch","requested":46}
{"req": "card.wireless"}
{"status":"{network-up}","mode":"auto","count":1,"net":{"iccid":"890...","imsi":"310...","imei":"867...","modem":"BG95M3LAR02A03_01.006.01.006","band":"LTE BAND 12","rat":"emtc","rssir":-73,"rssi":-74,"rsrp":-105,"sinr":77,"rsrq":-17,"bars":1,"mcc":310,"mnc":410,"lac":4615,"cid":167134479}}

2022-03-03 02:14:33,481:INFO:root:Action monitor
{"req": "hub.status"}
{"connected":true,"status":"connected (session open) {connected}"}
{"req": "hub.sync.status"}
{"status":"update change tracker: _env.dbs","requested":52}
{"req": "card.wireless"}
{"status":"{network-up}","mode":"auto","count":1,"net":{"iccid":"890...","imsi":"310...","imei":"867...","modem":"BG95M3LAR02A03_01.006.01.006","band":"LTE BAND 12","rat":"emtc","rssir":-73,"rssi":-74,"rsrp":-105,"sinr":77,"rsrq":-17,"bars":1,"mcc":310,"mnc":410,"lac":4615,"cid":167134479}}

2022-03-03 02:14:39,887:INFO:root:Action monitor
{"req": "hub.status"}
{"status":"idle (since 2022-03-03T02:14:15Z) {disconnected} {idle}"}
{"req": "hub.sync.status"}
{"status":"modem now OFF {modem-off}","requested":5}
{"req": "card.wireless"}
{"status":"{modem-off}","mode":"auto","count":1,"net":{"iccid":"890...","imsi":"310...","imei":"867...","modem":"BG95M3LAR02A03_01.006.01.006","band":"LTE BAND 12","rat":"emtc","rssir":-73,"rssi":-74,"rsrp":-105,"sinr":85,"rsrq":-17,"bars":1,"mcc":310,"mnc":410,"lac":4615,"cid":167134479,"updated":1646273677}}

At this point the Notecard never reconnected successfully, but kept going back and forth trying to start communications.

@dirtdevil - thanks for sending this over. Based on the responses this does confirm our suspicion that cellular coverage in this location is not ideal. It’s also in LTE band 12 (700MHz) which if you look at your Molex antenna you’ll see the lowest frequency range is 698MHz. With a WBNA Notecard (maybe even try adding an additional diversity antenna) the situation should improve quite a bit. Not a “fix” per se, but this will help to diagnose the issue.

@RobLauer sorry for the delay in responding. I have been trying to find a consistent method that causes this state. Short story is that the issue still occurs, but I haven’t found a guaranteed reliable way to produce it.

As you probably already know, attempting to do a web.post when not connected in continuous mode will correctly return an error {'err': 'web operations in continuous mode require being online (hub.set)'}. The connected {connected-closed} state seems to be an exception to that rule.

One thing that seems correlated is after a power-cycle it seems to be more likely to happen. Especially if the card was in continuous mode when it was power-cycle. For example, my NB card was running great all weekend and I issued various commands and logged status/responses continually without issue.

After power cycling the NB card and running commands that had just been working 5 minutes prior, I was able to get into the connected {connected-closed} state (see below).

$ notecard -port /dev/i2c-1 -interface i2c -verbose -req '{"req": "hub.get"}' 
{"req":"hub.get"}
{"mode":"continuous","host":"a.notefile.net","product":"...","device":"dev:867...69","duration":2}
$ notecard -port /dev/i2c-1 -interface i2c -verbose -req '{"req": "hub.status"}' 
{"req":"hub.status"}
{"status":"connected {connected-closed}"}
$ notecard -port /dev/i2c-1 -interface i2c -verbose -req '{"req": "hub.sync.status"}' 
{"req":"hub.sync.status"}
{"status":"connected {connected-closed}","time":1646615613,"sync":true,"completed":632}

$ notecard -port /dev/i2c-1 -interface i2c -verbose -req '{"req": "hub.sync"}'
{"req":"hub.sync"}
{}
$ notecard -port /dev/i2c-1 -interface i2c -verbose -req '{"req": "hub.sync.status"}'
{"req":"hub.sync.status"}
{"status":"idle {disconnected}","sync":true,"requested":1}
$ notecard -port /dev/i2c-1 -interface i2c -verbose -req '{"req": "hub.sync.status"}'
{"req":"hub.sync.status"}
{"status":"starting communications {wait-module} {connecting}","sync":true,"requested":10}
$ notecard -port /dev/i2c-1 -interface i2c -verbose -req '{"req": "hub.sync.status"}'
{"req":"hub.sync.status"}  
{"status":"get notebox change summary","sync":true,"requested":22}
$ notecard -port /dev/i2c-1 -interface i2c -verbose -req '{"req": "hub.sync.status"}'
{"req":"hub.sync.status"}  
{"status":"modem now OFF {modem-off}","sync":true,"requested":26}
$ notecard -port /dev/i2c-1 -interface i2c -verbose -req '{"req": "hub.sync.status"}'
{"req":"hub.sync.status"}  
{"status":"modem disconnected {cell-disconnected}","time":1646616409,"sync":true,"completed":1}
$ notecard -port /dev/i2c-1 -interface i2c -verbose -req '{"req": "hub.sync.status"}'
{"req":"hub.sync.status"}  
{"status":"modem now ON {modem-on}","time":1646616409,"sync":true,"completed":12}
$ notecard -port /dev/i2c-1 -interface i2c -verbose -req '{"req": "hub.sync.status"}'
{"req":"hub.sync.status"}  
{"status":"connected {connected-closed}","time":1646616409,"sync":true,"completed":14}

$ notecard -port /dev/i2c-1 -interface i2c -verbose -req '{"req": "card.wireless"}' 
{"req":"card.wireless"}
{"status":"{modem-on}","mode":"auto","count":1,"net":{"iccid":"890...25","imsi":"310...82","imei":"867...69","modem":"BG95M3LAR02A03_01.006.01.006","band":"LTE BAND 12","rat":"emtc","rssir":-79,"rssi":-79,"rsrp":-110,"sinr":76,"rsrq":-18,"bars":1,"mcc":310,"mnc":410,"lac":4615,"cid":167136272,"updated":1646616402}}

The card is now stuck. Even after restore, restart, power cycle I’m unable to get out of this state.

{"req": "hub.status"}
{"status":"connected {connected-closed}"}
{"req": "hub.sync.status"}
{"status":"connected {connected-closed}","time":1646618425,"completed":134}
{"req": "card.wireless"}
{"status":"{modem-on}","mode":"auto","count":1,"net":{"iccid":"890...25","imsi":"310...82","imei":"867...69","modem":"BG95M3LAR02A03_01.006.01.006","band":"LTE BAND 12","rat":"emtc","rssir":-79,"rssi":-79,"rsrp":-108,"sinr":77,"rsrq":-16,"bars":1,"mcc":310,"mnc":410,"lac":4615,"cid":167136272,"updated":1646618419}}

I’m going to leave it like this an log overnight to see if it ever connects on it’s own correctly. If it does, I’ll update the forum post with

So with the WBNA card, I’m not seeing a significant difference in the results reported by card.wireless (this is with the Molex antenna without a diversity antenna). Some of the other cellular antennas I’ve got actually made the reported rssi worse on both the NB and WB card.

$ notecard -port /dev/i2c-1 -interface i2c -verbose -req '{"req": "card.wireless"}'
{"req":"card.wireless"}
{"status":"{network-up}","mode":"auto","count":1,"net":{"iccid":"890...25","imsi":"310...82","imei":"868...14","modem":"EG91NAXGAR07A03M1G_01.003.01.003","band":"LTE BAND 12","rat":"lte","rssir":-75,"rssi":-75,"rsrp":-107,"sinr":81,"rsrq":-15,"bars":1,"mcc":310,"mnc":410,"lac":4615,"cid":167136272,"updated":1646615177}}

Anyways, I think the web.post returning incorrectly is just a symptom of doing a web.post in the connected {connected-closed} state. The only reason I ever considered doing that is that my NB card would get stuck in connected {connected-closed} indefinitely so I assumed it was considered equivalent to the connected state.

I appreciate all the time you have spent looking into this with me; we certainly have learned a lot on along the way (documentation improvements for web.post, improving transfer rates by reducing segment delays, etc.)

I’m happy to continue investigating this with you. Just let me know what experiments or diagnostics that you would like me to do. Otherwise, I’ll probably move on and just use the WBNA card since, so far, I haven’t been able to get it into the stuck state yet.

The NB card stayed in the connected {connected-closed} state for about an hour. During that time the only calls being made were hub.get, hub.status, hub.sync.status.

The card went to modem now OFF {modem-off} , waiting for wireless service {wait-service} {connecting} , then connected (session open) {connected}.

As of this morning it is still connected fine.

Couple thoughts this morning:

  1. You mentioned having additional antennas? Can you use one of those as a diversity antenna on the WBNA? My concern is you are still connecting to LTE BAND 12 which is at the low end of the frequency range.

  2. I am a bit concerned as to how your NBGL Notecard is getting into connected {connected-closed} state. Are you enabling the GPS module before any of these calls (with a card.location.mode request for instance)? Or performing any DFU actions?

You can also ensure the GPS module is off with this command as you are testing:

{
  "req": "card.location.mode",
  "mode": "off"
}

Thanks,
Rob

  1. Yes, here is what I get with both the Main and Diversity antennas installed (using the Molex on each):

Main: Molex, Div: Molex

{"status":"{network-up}","mode":"auto","count":1,"net":{"iccid":"890...25","imsi":"310...82","imei":"868...14","modem":"EG91NAXGAR07A03M1G_01.003.01.003","band":"LTE BAND 12","rat":"lte","rssir":-75,"rssi":-75,"rsrp":-109,"sinr":79,"rsrq":-17,"bars":1,"mcc":310,"mnc":410,"lac":4615,"cid":167136272,"updated":1646708261}}

I also have:

Adafruit 1991
Sparkfun WRL-17841

I don’t think those would provide any better characteristics based upon their specifications.

According to https://www.cellmapper.net/, cell 167136272 is on band 12 (709 MHz Uplink 739 MHz Downlink) and is less than 1 mile away. I can use an external SIM and try a different provider if that is something you are interested in.

2a. I think this is the root of the issue; about the time that I started experiencing these issues I was also starting to test out the location tracking. The documentation explicitly states that continuous cellular and continuous location are note allowed, but I had turned on periodic mode and it’s been on since (because the setting persists). I’ll turn location mode off and see if the problem goes away entirely. Is the documentation missing this restriction or is the intention that you can combine continuous cellular with periodic location and it simply needs a fix in the firmware?

My project doesn’t strictly require location tracking, so I can turn it off. I’m also able to turn location mode off prior to setting continuous cellular mode, then the swap them back if that will work around the issue.

2b. I have never used any DFU actions.

You can definitely combine continuous cellular with periodic GPS. The only issue is whenever the Notecard needs to update its location, the cellular connection will be interrupted (but will reestablish automatically).

@dirtdevil - Another thing we just noticed. You had earlier mentioned performing a card.restore to reset the Notecard. There is an additional parameter on that call that you may have been missing:

{"req":"card.restore"} erases the user files, but not the configuration.
{"req":"card.restore","delete":true} erases the user files and the configuration.

I would recommend using the delete:true param as well.

Rob,

I wanted to see how much you wanted me to continue to investigate this and if there were any specific test remaining you wanted me to pursue.

Thanks,
Michael

Did you notice any changes in behavior after resetting the Notecard with the {"req":"card.restore","delete":true} command?