Any people with iTracker RAK8212 here?

Posted on
  • Today I wrote "getting started" instructions at my personal blog at . 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 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

    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 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.


    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?


    Could you post a new issue here with the results of running something when has been run right after connect?

    AT+QICLOSE=sktnum should be called by Espruino, which I think is what's required:Ā­/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.

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview

Any people with iTracker RAK8212 here?

Posted by Avatar for wklenk @wklenk