Gaps in Data Transmission

[drewcssv]

Hi. Making solid progress in getting stable data collection and transmission from Notecard (NOTE-NBNA-500) via NoteCarrier-B. But I am now seeing gaps in the data transmitted that occur every 30 minutes or so. The gaps seem to be about 5 minutes. The application code running on an ESP32 Feather is standard code taken from one of your examples, and sends the JSON-encoded payload to NoteHub about every 60 seconds. Similar code that uses WiFi works well, so not thinking it’s the logic but could be…

Not sure what documentation to share that might help diagnose, but here are some bits that might be helpful:

Here is the Event log from a recent test:

Here is the Route Log that shows data moving to a Thingspeak database:

And here is an example of the application data pulled from Thingspeak:

Finally, here’s the main code sequence that sets up the Notecard request:

void setup() {
delay(2500);
serialDebug.begin(115200);
notecard.begin();
notecard.setDebugOutputStream(serialDebug);

J *req = notecard.newRequest(“hub.set”);
JAddStringToObject(req, “product”, productUID);
// JAddStringToObject(req, “sn”, “BackpAQ Proto”);
JAddStringToObject(req, “mode”, “periodic”);
JAddStringToObject(req, “card.voltage.mode”, “lipo” ); // tell 'em we’re using a LiPO
notecard.sendRequest(req);

req = notecard.newRequest(“card.location.mode”);
JAddStringToObject(req, “mode”, “continuous”); // continuous tracking
JAddNumberToObject(req, “seconds”, 60);
notecard.sendRequest(req);
req = notecard.newRequest(“card.location.track”);
JAddBoolToObject(req, “start”, true);
JAddBoolToObject(req, “heartbeat”, true);
JAddBoolToObject(req, “sync”, true);
JAddNumberToObject(req, “hours”, 4);

notecard.sendRequest(req);

delay(1000);

Side question is why so many events at 12:25:01? I see this a lot at times…in the code there is only one time that this data is encoded and sent, yet this data transfer to file env.qo seems to happen redundantly, often. Maybe another symptom?

Thanks in advance for your help!

[RobLauer]

Hi @drewcssv,

There are a few potential issues or points of confusion here, so let me see if I can unpack this all:

Side question is why so many events at 12:25:01 ?

I can’t see the heading of the column from Notehub, but the default timestamp view is “Uploaded”. So the Notecard can add Notes over and over, but then upload groups at once. If you click on the “Uploaded” heading you can changed that to “Captured”.

JAddStringToObject(req, “mode”, “periodic”);

You specify periodic mode, but don’t specify an outbound argument for how frequently the Notecard should try to sync (IIRC the default is 30 mins).

JAddStringToObject(req, “card.voltage.mode”, “lipo” );

FYI, specifying the power type is mostly useful when using voltage variable behaviors.

JAddStringToObject(req, “mode”, “continuous”); // continuous tracking

With the GPS in continuous mode and the cellular radio in periodic mode, just be aware that the two can’t both function concurrently. This could be a reason that you’re seeing gaps in data, as the Notecard switches from GPS to cellular or vice versa. Our doc on diagnosing GPS issues may be helpful here.

Hope this helps!
Rob

[drewcssv]

Thanks for the helpful advice, Rob. I’ll play around with the Sync and GPS commands and see if I can pin down what’s happening.

[drewcssv]

Hi Rob, here is the code I am using to actually send the notes to Notehub:

// send data to cloud
J *req = notecard.newRequest(“note.add”);
if (req != NULL) {
JAddBoolToObject(req, “sync”, true);
JAddStringToObject(req, “file”, “env.qo”);
J *body = JCreateObject();
if (body != NULL) {
JAddNumberToObject(body, “temperature”, senTemp);
JAddNumberToObject(body, “humidity”, senHumid);
JAddNumberToObject(body, “pm1”, PM1_0);
JAddNumberToObject(body, “pm25”, PM2_5);
JAddNumberToObject(body, “pm10”, PM10_0);
JAddNumberToObject(body, “co2”, co2);
JAddItemToObject(req, “body”, body);
}
notecard.sendRequest(req);
}

Re SYNC, as you can see, I am using “sync” : true as mentioned by you and others (Carl Henderson) as necessary for low-latency sync. I am guessing that there might be a longish delay when the Notecard “switches” from cell to GPS and back…but can this really take as much as 5 minutes? If so, then I am probably headed to a standalone GPS, something I had hoped to avoid by going to this Notecard solution in the first place. I will also check my cell signal strength to make sure I am within spec for proper operation. Thanks again for the advice!

[drewcssv]

Hi, some additional info as I poke further into this issue. Here is a recent session log…as you can see, the rssi isn’t so bad, but the other figures are right on the edge. It could be that the gaps are caused by simply poor cell reception where my device is located, although I don’t have this issue with other cell devices using T-Mobile LTE. Is the fact that the Notecard is using “emtc” an issue? I wouldn’t think so since the payload is so small, but are there coverage issues with NB ? And why GSM? Thought no one was using that in favor of LTS/M1/etc. Finally, it’s odd that the tower “Rodeo” was selected as it much further than several closer towers…this seems to happen randomly with closer towers selected more often. Perhaps this happens when re-connecting…is there a way to force a specific tower?

“cell”: “310,410,35594,168970256”,
“rssi”: -75,
“sinr”: 92,
“rsrp”: -107,
"rsrq": -19,
“rat": "emtc”,
“bearer”: “GSM”,
“tower”: {
“time”: 1705711248,
“n": "Rodeo CA”,
“c”: “US”,
“lat”: 37.98921250000001,
“lon”: -122.21651562499997,
“zone”: “America/Los_Angeles”,
“mcc”: 310,
“mnc”: 410,
“lac”: 35594,
“cid”: 168970256,
“l”: “849VXQQM+M9Q”,
“count”: 121,
“towers”: 1

[RobLauer]

Hi @drewcssv,

I don’t think this is the root issue, but it’s curious you would see "rat":"emtc" and "bearer":"GSM". Can you please connect this Notecard to a terminal and issue trace +modem, then try and do a sync, and send the output? Very curious to see what the modem is doing at this point.

To answer your other question, no, there is no way to force a specific tower.

Rob

[drewcssv]

notecard_2024-01-22T04_30_47.log (52.2 KB)
Hi Rob, did the terminal command trace +modem and then a sync. Log is uploaded. Have no idea what any/all of this means. BTW I have noticed improved data transmission/fewer dropouts after I replaced the patch with a better duck antenna.

[RobLauer]

Hi @drewcssv,

After a quick review of the log file, it looks to me like the cellular radio and GPS are battling with each other for connectivity. I understand what you’re trying to do from a firmware standpoint, but here is what the Notecard is effectively interpreting:

1. Put the GPS in continuous mode.
2. Take a location sample every 60 seconds
3. Sync that tracked location immediately
4. (Here’s a potential problem:) If you can’t make a cell connection w/in 60 seconds, the Notecard will revert back to GPS to gather more location data (because this is what you told it to do).

So yes, a better antenna can help you make a connection more quickly. Also if you’re really wanting to gather location data that frequently AND sync it with the cloud that frequently, you’re better off using a separate GPS module. Or don’t sync location data immediately (remove that “sync:true” from your “card.location.track” call.

Rob