Any people with iTracker RAK8212 here?

Today I wrote "getting started" instructions at my personal blog at https://bit.ly/2x6OdY8 . I tried to make it very easy even for a beginner to get the Espruino firmware on the RAK8212.

However, now that I go deeper, I would like to know if there are other people playing around with this device? If yes, please contact me.

I am connecting using the "native" Web IDE, using Bluetooth to connect to the device.

Issue #1:
I can't get the GPS example running at http://www.espruino.com/RAK8212#gps. I get ERROR: 516 again and again.

Issue #2:
I would like to share experience when it comes to sending/receiving messages via LTE NB-IoT.

Hi,

There definitely are some people using RAK8212 - I'm not sure how many are looking/posting on the forum though.

ERROR: 516

This is just Not fixed now - do you have the RAK8212 by a window? Chances are you'll have to wait for a minute or two after enabling the GPS before you get valid data.

I would like to share experience when it comes to sending/receiving messages via LTE NB-IoT.

It'd be great if you could let us know how you get on. There is no NB-IoT coverage here in the UK so I'm unable to test/develop anything :(

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.

Thanks for the update! I've just tweaked the QGPS command as you suggest so new builds should have that fixed.

Hopefully the AT library recent changes will help your issues with multiple requests - let me know how it goes!

In terms of BG96 setup, how would you suggest we integrate that with the existing module? We could add extra options to connect that'd cause it to send those commands and then not do CREG/etc? It probably makes sense to send the commands each time as I guess they're quite quick, and it'd avoid issues if you tried to move your code to a new module.

@wklenk I'd be really interested to hear your experience with this - did you have code for NB-IoT that you used as well?

But once connected to NB-IoT, does the HTTP functionality still work fine?

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.

Thanks - so connect would work as-is if it just did a CEREG when not going for GSM/LTE?

Good point about the cell changing - it'd def make sense as a method that could be called then. It'd be great if you were able to suggest what might be required.

Odd about power - I've only had any luck running the boards directly off a LiPo, but when that's done it has been file.

• SSL - realistically that'd require some changes in Espruino itself I think as at the moment it expects that it'll implement SSL itself if it's going to do it (but I'm not sure there's enough RAM on the nRF52).
  
• MQTT - should be available as a module for Espruino, so probably not a big deal.
  
• Very interesting about the filesystem though - that's huge! It could always be another module that you can load in if you need it. It may even be something that works on other Quectel modules.
  
  

Bluetooth

Not sure what to suggest there - if it's not advertising it's because it thinks it is connected. It sounds like somewhere along the line Mac OS is probably still maintaining a connection but Web Bluetooth thinks it's lost - and I'm afraid all that code in the middle is very much out of my control.

I know it's not a great solution but I'd say when you're developing and you want an active connection, maybe just don't let your Mac go to sleep?

AT+QICLOSE

Could you post a new issue here with the results of running something when gprs.at.debug() has been run right after connect?

AT+QICLOSE=sktnum should be called by Espruino, which I think is what's required: https://github.com/espruino/EspruinoDocs/blob/master/devices/QuectelBG96.js#L37

Or is it the case that Espruino gets a QIURC 'closed' message, but it actually still has to issue a QICLOSE` before the socket can be used again?

I should add that I have an agreement with RAK Wireless where I maintain the build of Espruino for the RAK8211/8212 - but I'm paid quite a small amount per month for that and it doesn't cover supporting RAK's customers. I'll try to help out and take in any changes you might suggest but I can't afford to offer the same level of support that I would to folks that were buying my own boards.

Even so the QICLOSE thing is something I'd really like to get sorted properly as that sounds like something that definitely should have been working from the beginning.

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

Great - thanks! I'll get that in.

Gordon, the close issue seems to be sorted now. I see you used a ternary op to select the required string - I'm still a bit slow with the finer points of Javascript.

I'm wanting to loop on the CREG/CEREG phase to detect when the module connects but I'm not sure how I would incorporate that into the promise chain - or whether to use a promise chain. My first thought is a finite state machine, but how would I have the callback call the state machine? My initial solution is to have an interval timer call the state machine that issues the command and the callback sets a flag then tells the code to clock the machine .

Basically, issue CREG?/CEREG? at a regular interval until the module reports online or we try too many times and error out. The reason being the connect phase is power hungry and is variable so detecting it early is an advantage. The current 30 seconds seems to be either too long or not quite long enough.

Ahh - yes, Promises can be a bit crazy... You can do something like this (this one just checks BTN1 and resolves if it was pressed when it checked, or times out after a while):

// Promise.resolve() is just to get it started - in reality you'd stick this on the
// end of the promise chain
Promise.resolve().then(function() { 
  return new Promise(function(resolve, reject) {
    var n = 20;
    var i = setInterval(function() {
      console.log("Checking BTN1 "+n+"/20...");
      if (BTN1.read()) {
        clearInterval(i);
        resolve();
      }
      if (n-- <= 0) {
        clearInterval(i);
        reject("Timeout!");
      }
    }, 1000);
  });  
}).then(function() {
  console.log("Done!");
});

Basically when you do stuff like this you want to return a promise immediately (which you do with new Promise) then you execute your code in the function inside new Promise(function(..) where you have two arguments you can call - one to resolve it if everything went ok, and one to reject if it's all gone wrong and you want to bail out :)

Hi Gordon, after updating AT+QGPS=4 -> AT+QGPS=1, the start up time is really slow. And it still throws the error 516 for this time.

It is about 3-4 minutes direct at the window. Another question: Do you cut off the GPS data (latitude and longitude) to 5 decimal numbers? And are there reasons for it? More accurency would be nice.

That's the BG96 and many GPS receivers - it's called 'time to first fix'. You can download ephemeris and other data and load it into the BG96 for faster first fix. Again, error 516 is from the BG96 - it says it hasn't got a fix yet. I'm not sure what the BG96 does once its got a fix then you turn the GPS off then back on again - does it have to wait for a first fix or is it near immediate? Something I'll try in the next few days.
Did you ever get it working with AT+GPS=4? It never worked for me.

AT+GPS=4 did not work for me as well. But I "only" waited 10 minutes. So you are right, your fix shows at least some data.

Reading the documentation I found this: "The command is used to turn on GNSS function. Currently it only supports turning on GNSS in Stand-alone mode (that is, =1)"

As @Kartman says I think that is to be expected. I don't limit the decimal places of GPS data, so I guess that's just what you're getting from the BG96

AT+QGPSLOC=1 gives more precision methinks. Depends how you want the data.

Just changed it before I read your Post. Should work nice. But I am currently wondering about the Format. It is Not the same like in the documentation.

Might this solve the problem? Updating the BG96 firmware? There is a new post on RAK8212 website:
http://supportcn.rakwireless.com/topic/526/firmware-update-of-bg96-rak8212-moudle-via-dfota
@Gordon This would be a great improvement for the future adding this AT-Command to Espruino. This could fix the problems mentioned in this thread.

@MobiTech you can just run that command yourself via Espruino. It's all open source so you're welcome to contribute it if you want to :)

the code I used was:

gprs.at.cmd('AT+QFOTADL="https://quectel.com:100/update.zip',1000,print);

unfortunately, you need to host the file yourself - quectel don't do it - which is a pain.

@Kartman
I tried this:

require('QuectelBG96').connect(usart, {
      apn : "web.vodafone.de",
      username : "vodafone",
      password : "vodafone"
    }, function(err) {
      console.log("Connected!");
      if (err) throw err;
      gprs.at.cmd('AT+QFOTADL="http://mydomain.de/update.zip"',1000,print);

But how do I know that it worked? There is no console output. Or how much time does it need? Kind regards

Add gprs.at.debug() before so you get debug output.

How long does it take? I've not done an update using this method before, but via USB to the module(I'm also using another BG96 based device that has a USB connector) it takes a couple of minutes to update.
I think RAK should put some pads at least or better still a usb connector for updating the module in Rev 2.

@Kartman
I tried many things but now I only get the HTTPEND 701 error (which means unknown HTTP(s) error). After HTTPSTART it returns OK.
My code:

gprs.at.cmd("AT+QFOTADL=\"https://www.mydomain.de:443/update.zip\"\r\n",1000,print);

I tried many things like setting the port, changing the domain to http, removing the ", but nothing did work. I downloaded the zip provided on RAK's website. Any idea how to deal with this error?

It got the same error - but the site I pointed it to didn't have the file! You might want to double check you can access the file via the browser just to make sure it is actually accessible - you may have done this already.

I had a website like this (http://partone-domain.de). I figured out that the dash (-) caused the problem. When I hosted the zip on a domain without a dash in the URL it worked well.

Great success! Did you get it up to the latest version? 7xxx was the last one I had used. The RAK's were 5xxx .