High latency on inbound .db sync

Troubleshooting
1

I am working with two separate units that are seeing extremely long delays syncing db files sent cloud to note hub (inbound to notecard). From a previous topic it seems like it should be within minutes at most but I am at almost 2 hours and it still has not synced despite being in continuous mode with sync set to true. I have also seen that outbound db notes are not syncing either unless a hub sync is sent immediately after the call setting the db note file. There is no problem with .qi or .qo files strangely. They are sent or received almost immediately. While testing I am sending .qo updates every 5 minutes with no issues. If I hard power cycle the modem, it picks up the new db files immediately after in comes online. Am I missing something in the handling of .db notefiles?

2

Have now found that it appears that all 3 devices now are intermittently being put in a 60min timeout due to failure to connect to notehub. Notehub status says that everything is ok. Is there a suggested way to resolve this? 60min downtime is not acceptable when all systems should be operational.

{
 "status": "{modem-off}",
 "mode": "auto",
 "count": 2,
 "net": {
  "iccid": "89011703278520598957",
  "imsi": "310170852059895",
  "imei": "868050040088706",
  "modem": "EG91NAXGAR07A03M1G_01.003.01.003",
  "band": "LTE BAND 2",
  "rat": "lte",
  "internal": true,
  "rssir": -57,
  "rssi": -58,
  "rsrp": -92,
  "sinr": 10,
  "rsrq": -9,
  "bars": 2,
  "mcc": 310,
  "mnc": 410,
  "lac": 39169,
  "cid": 116781066,
  "updated": 1691086620
 }
}
> {"req":"card.wireless.penalty"}
{
 "status": "connect delayed (50 min remaining): can't open session to notehub: failed to connect using TLS: network timeout {network} {service}{extended-service-failure}"
}
> {"req":"hub.status"}
{
 "status": "idle (can't open session to notehub: failed to connect using TLS: network timeout {network}) {disconnected} {idle}"
}
> {"req":"hub.sync.status","sync":true}
{
 "status": "modem now ON {modem-on} (connect delayed (49 min remaining): can't open session to notehub: failed to connect using TLS: network timeout {network} {service}{extended-service-failure})",
 "sync": true,
 "requested": 1
}
3

Hi @szygmunt,

Sorry about the delay in a response. It does seem like the core issue is that you have a relatively week cellular connection. So let’s look at that first:

The first thing I look at here is comparing the values you provided from a card.wireless request to what we have listed in this table.

What stands out for me is the incredibly low sinr value of 10. This is the “Signal to Interference and Noise Ratio” and anything lower than 135 is considered “poor”. I would look at your antenna placement, consider adding an additional antenna to the DIV connection on your Notecard, and look over the guide linked to above re: improving your cellular connection.

Secondly, we can look at the timeout (or “penalty box”) you’re experiencing. This is put in place to prevent runaway battery drain through excessive reconnects, but there are ways around it. Check out this doc on Understanding Notecard Penalty Boxes. But to be clear, “breaking out” of a penalty box is only a short term band-aid and I would concentrate on improving your cellular connection if at all possible.

Hope that helps!
Rob

4

Thank you for the response and pointing out the poor SINR. I will run in another location and see how things respond. I do already have the stock antenna attached to DIV connection and the main antenna attached to a directional antenna pointing out the window roughly towards the tower location. The antenna is broadband though so I might be picking up interference from that if its not something local in my office.

I did discover that some of the connection losses were due to too high a periodic update rate on the GPS location. Especially since the dev unit is indoors on an active antenna, the time to lock and update location was forcing the modem to be off for an extended amount of time.

The penalty box issue is interesting as it hit all three units in 2 different states at the same time knocking them off-line. Have now put in additional error handling to catch and respond to that state. A quick call to card.wireless.penalty with stop:true brought the units back online.

Thanks again for your help.

5

I’d be curious if switching the antennas between MAIN and DIV improves the quality of your connection at all too.

And yes, the cellular radio and GPS module cannot be enabled at the same time, so it’s important to make sure you’re managing those connections so they aren’t both fighting with each other!

Rob