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.
© Espruino, powered by microcosm.
Report a problem