Search results for:

My proposal for selecting between CREG or CEREG is pass a key named 'lte' in options{}. If this is true, use CEREG, else CREG

Hopefully I've used the correct javascript idiom for testing to see the key exists or default to false. If not, please correct me after you've stopped laughing.

In the connect function:

atcmd("ATE0").then(function() { // echo off
        if (options.lte || false)
        return atcmd("AT+CEREG?"); // Check LTE registered
        else
            return atcmd("AT+CREG?"); // Check GSM registered
    }).then

Gordon,

further to the previous thread regarding the RAK8212/BG96, here's a dump of the sequence-

|  __|___ ___ ___ _ _|_|___ ___
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 1v99.206 (c) 2018 G.Williams
Espruino is Open Source. Our work is supported
only by sales of official boards and donations:
http://espruino.com/Donate
>Turning Cell on
Waiting 30 sec for GPRS connection
Connecting GPRS
["ATE0\r\n"
] "ATE0\r\r\nOK\r\n"
["AT+CEREG?\r\n"
] "\r\n"
] "+CEREG: 0,1\r\n\r\nOK\r\n"
["AT+CGATT=1\r\n"
] "\r\nO"
] "K\r\n"
["AT+CGREG?\r\n"
] "\r\n+"
] "CGREG: 0,1\r\n\r\nOK\r\n"
["AT+COPS?\r\n"
] "\r\n+"
] "COPS: 0,0,\"Telstra Mobile Telstra\",9\r\n\r\nOK\r\n"
["AT+QICSGP=1,1,\"\",\"\",\"\"\r\n"
] "\r\nO"
] "K\r\n"
["AT+QIACT=1\r\n"
] "\r\nO"
] "K\r\n"
Connected!
>sendCloud()
{"measurements":[{"source":{"id":"4823986"},"time":"","type":"CurrentSensor","c8y_CurrentMeasurement":{"Sensor1":{"value":11.1,"unit":"A"},"Sensor2":{"value":22.2,"unit":"A"},"Sensor3":{"value":33.3,"unit":"A"},"Sensor4":{"value":44.4,"unit":"A"}}},{"source":{"id":"4823986"},"time":"","type":"c8y_SignalStrength"}]}
================================
["AT+QIOPEN=1,0,\"TCP\",\"11.22.33.44\",8080,0,1\r\n"
=undefined
] "\r\nOK\r\n"
] "\r\n"
] "+QIOPEN: 0,0\r\n"
] "\r\n> "
["POST / HTTP/1.1\r\nUser-Agent: Espruino 1v99.206\r\nConnection: close\r\nContent-Type: application/json\r\nContent-Length: 316\r\nAuthorization: Basic ==\r\nHost: \r\n\r\n{\"measurements\":[{\"source\":{\"id\":\"4823986\"},\"time\":\"\",\"type\":\"CurrentSensor\",\"c8y_CurrentMeasurement\":{\"Sensor1\":{\"value\":11.1,\"unit\":\"A\"},\"Sensor2\":{\"value\":22.2,\"unit\":\"A\"},\"Sensor3\":{\"value\":33.3,\"unit\":\"A\"},\"Sensor4\":{\"value\":44.4,\"unit\":\"A\"}}},{\"source\":{\"id\":\"4823986\"},\"time\":\"\",\"type\":\"c8y_SignalStrength\"}]}"
] "\r\nSE"
] "ND OK\r\n"
] "\r\n+QIURC: \""
] "recv\",0,125\r\nHTTP/1.1 200 OK\r\nDate: Tue, 25 Sep 2018 03:56:48 GMT\r\nConnection: cl"
] "\r\n\r\n+QIURC: \"close"
-->Hello world!
] "d\",0\r\n"
==> Closed.
>state()
=undefined
] "\r\n+"
] "QISTATE: 0,\"TCP\",\"11.22.33.44\",8080,14869,4,1,0,1,\"uart1\"\r\n\r\nO"
] "K\r\n"
>close(0)
=undefined
] "\r\nO"
] "K\r\n"
>state()
=undefined
] "\r"
] "\nOK\r\n"
> 

Note that the ip address and auth have been changed to protect the innocent.
state() and close() and my functions that issue QISTATE and QICLOSE.

The function I used to create this:

function sendCloud() {
  
      if (typeof (http) === 'undefined') {
      http = require("http");
    }
//  var packet = [ { "compId": compId, "streamId": streamId,"data": data }];
  var packet = {"measurements":[
 {
  "source":{"id":CUMULOCITY_ID},
  "time":"",
  "type":"CurrentSensor",
  "c8y_CurrentMeasurement":
    {
    "Sensor1":{"value":11.1,"unit":"A"},
    "Sensor2":{"value":22.2,"unit":"A"},
    "Sensor3":{"value":33.3,"unit":"A"},
    "Sensor4":{"value":44.4,"unit":"A"}                                       }
   },
  {
  "source":{"id":CUMULOCITY_ID},
  "time":"",
  "type":"c8y_SignalStrength",
//   "c8y_SignalStrength":
//    {
//     "rssi":{"value":"99","unit":"dBm"},
//     "BER":{"value":"99","unit":"%"}
//    }
    }
  ]};

  var body=JSON.stringify(packet);
  //var body =JSON.stringify("{'test':'test'}");
  
  //memoryTracking();
  
  options = {
    host: CLOUD_PROVIDER,
      port: '8080',
      path: "/",
      method:'POST',      
      headers: {"Content-Type":"application/json", 
                "Content-Length": body.length,
                "Authorization":  AUTH,
                "Host":""
               }
  };
  //print(options);
  print(body);
  console.log("================================");
  

   var req = http.request(options, function(res)  {
    res.on('data', function(data) {
      console.log("-->"+data);
    });
    res.on('close', function(data) {
      console.log("==> Closed.");
//      gprs.at.cmd("AT+QICLOSE=0\r",1E3,print);
    });
  });
  req.end(body);
}

We can see that close is not happening.
My workaround is adding the QICLOSE into the on "close" method works although it hard codes the socket number.

Another anomaly is what seems to be a size limitation on the packet which is less than the MTU (around 512 bytes??). The body is truncated and the truncated length is correct to the send request to the module, however the length in the header is the original length, so the server is waiting for more. You can see I've commented out part of the payload I send. When I un-comment it, the send size is 352 bytes even though the packet is larger.

Gordon, thanks for the prompt response.
There doesn't seem to be any difference with using CAT-NB1 (NB-IoT) vs CAT-M1 or the other modes in regards to tcp/http. From what I have experienced, the difference is in the configuration of the module and the inherent differences in the modes. The difference here seems to be that CAT-NB1 doesn't like to hop cells, so if you're static it isn't a problem. If you're moving, you'll need to reconnect when one cell drops out. To address this, you might want to change modes on the fly - CAT-NB1 when not moving and enjoy the lower power consumption (assuming you set the various commands on the module to do so) and when movement is detected, you might want to transition to CAT-M1 and maybe back again. The transition from CAT-NB1->CAT-M1 tends to be seamless, but back the other way requires a reconnect. So with the connect function, being able to do a reconnect and skipping the power cycle would be a good feature. To issue the various commands, I'm currently just using gprs.at.cmd() which seems to work well enough.

As for selecting between CREG and CEREG - from what I've read, CAT-NB1 and CAT-M1 are E-UTRAN, so CEREG caters for those protocols. Maybe add a boolean param to connect() to select. I have a suspicion that the RAK hardware doesn't cope well with the gsm current requirements, so if you're using the RAK8212, then you're only going to be using CAT-NB1 or CAT-M1 methinks. I have a module that randomly shuts down that suggests a power problem and it's the one that works with CREG!

Other features that the BG96 has are:
SSL. This requires certificates to be loaded, so some functions are needed for this and HTTP modified to use the ssl tcp commands.

Filesystem. It would be nice to have a wrapper around this to read/write files. The BG96 has around 14MB of storage!

MQTT. This can be SSL or open.

These are variations on the send() and recv() functions.

A little quirk I've found annoying and I'm not sure what end is to blame - I'm using a macbook pro with the Chrome webide. Being able to simply connect to the module via bluetooth is brilliant but where it falls down is I'm think when the macbook goes to sleep, the bluetooth connect gets dropped (or at least as far as the ide is concerned as it reports 'disconnected') the trouble comes when you try to reconnect. From what I can gather, the module is not longer broadcasting, so it doesn't get detected and is unable to reconnect. Cycle power/reset and everything is good again. It would be super if something timed out when the connection drops and allows a reconnect.

I tried build 204 this afternoon. The http operation seems to be more consistent, however, I need to send a AT+QICLOSE,0 to close the socket. From what I gather, this is supposed to be handled by the QIURC 'closed' callback.

I got caught by this. Drove me crazy for a while until I dug a little deeper. The code turned on gps using AT+QGPS=4. This seems reasonable, but it doesn't work. I changed it to AT+QGPS=1. Seems for mode 4 you need to regularly upload the ephemeris and other data to the module for fast TTFF (time to first fix). Mode 1 is the bog standard mode, so it is a little slow to start up.
Line 136 in RAK8212.js AT+QGPS=4 -> AT+QGPS=1

Other issues I've found are:

CREG? works for gsm but for CAT-M1 and CAT-NB1, CEREG? is the command to query if we are connected to the network. Interestingly, I have one BG96 module that works with CREG? and returns 0,1 when online, but two others that report 0,3 which translates to connection refused but CEREG returns 0,1. Somehow it seems GSM is not enabled in two of my modules - I'm not sure how I did this! Note that this was using the same or different SIMs, so not an account/SIM issue.
Line 156 of QuectelBG96.js CREG -> CEREG

There's some issues with the registered handlers being forgotten - the first http request works, but subsequent ones don't have the data and close handlers called - I see there's some changes to the AT and BG96 modules done recently, so I'll try that today.

To configure the BG96 for CAT-M1 and CAT-NB1, do the following:
AT+QCFG="band",f,8000004,8000000 -> this sets the bands in use (28 and 3). These settings are for Australia. If you don't set this, then the module scans all bands and can be very slow to connect - I had 3 minutes to connect to CAT-NB1 initially! Now it is around 30 seconds. Currently only band 28 has CAT-NB1 out here.

AT+QCFG="nwscanmode",030201 to favour CAT-NB1 first
AT+QCFG="nwscanmode",020301 to favour CAT-M1 first

then
AT+QCFG="iotopmode",1 to force CAT-NB1. 0 to force CAT-M1 or 2 for either.

The commands only need to be sent once - the module remembers these settings.