Search results for:

Watch batteries have no hope of powering the cellular module. You need to use Lithium Ion batteries. Unfortunately the RAK8212 has a poor voltage regulator that draws more current than the cellular module in sleep, so this module is a poor choice for something that has to run for a long time.

As for waterproof cases, there's many suppliers of IP rated enclosures.

RAK didn’t make a good choice of voltage regulator. This needs to be changed to one with a lower quiescent current.

When enabled, the gps module will send data regularly. The messages it sends will tell you its status.

The nrf52832 has only one uart, so you can only talk to one device at a time - either the gps or the gsm. The gps module can take some time to get a fix - 15 minutes or so.

The rx and tx pins are swapped for the bc95 vs the m35 module.

I'd suggest you update the firmware on the bc95 as well. This presents a challenge in that you need to solder some wires to the bc95 to a usb->serial converter. I use the usb base board for this. There's a windows program from quectel that does the firmware upload. You can also do this 'over the air', but I've not tried this.

I didn't solve it! Gordon did.

Mine does too - as i wired it that way. The average jlink doesn’t.

Note that the debugger doesn't supply power! The board needs to be powered externally.

I use a nRF52dk and it works fine from my mac as Gordon describes. I build Espruino and do everything on a macbook pro.

Note: the 8211 uses a BC95 cell module and a L70 GPS.
The 8212 uses the BG96. The BG96 GNSS has GPS and Glonass, so it has better performance.

You probably want to update the BC95 firmware at some stage. I just did mine today. It requires a bit of jiggery-pokery to do. You need to solder some jumper wires from two resistors on the board to the uart pins. You can then use the usb->serial board to download new firmware - you need Windows for this as the Quectel app is windows only. It works well running a Win7 VM using Virtualbox.

I concur with Gordon - it takes some time to do a cold start. The GPS needs to download the ephemeris and at 50 bits per second, it takes some time.

hah! I just had a quick read of the datasheet and I think you're right - I didn't see any means of varying the cpu clock. I had expected the nrf52 would've had a pll like most other ARM devices.

You might be able to use poke32() to manipulate the nrf52 registers directly.

I'm struggling getting it to work reliably at the moment. There's just been new firmware released for the BC95 but I've yet to check to see if the problems I've encountered have been fixed. Then there's the challenge of updating the firmware - I've soldered some wires to bridge the BC95 serial to the usb->serial board so I can do this.

The first trick to getting the BC95 working is to swap the gprs tx and rx pins (12 & 20) in rak8211.js. It's easy enough just to hand edit the min.js file as it is the first line.

That code is like decoding a puzzle! I saw the 256 + bit and I'm thinking What!! Then I twigged that it is to ensure there's at least two hex chars. Thanks for the tips.

Unfortunately the Quectel BC95 uses hex ascii. Why? Who knows. I can't think of any other AT module that does it that way.

We were having some memory problems especially when receiving, so I had thought my code was not too efficient. I had it in my mind that there might be a simple way to use a byte array and cast it to a string. That way there's no copy and allocate.

It's part of the build

The Quectel BC95 module expects the data payload as hex strings. Are the following methods, the most memory efficient way of doing this?

//convert to a hex string
    for (var i = 0; i < data.length; i++) {
      var s = data.charCodeAt(i).toString(16);
      while (s.length < 2) {
        s = '0' + s;
      }
      msg += s;
    }

and conversely:

for (let ndx = 0; ndx < (recvData[1] * 2); ndx += 2) {
    let i = parseInt("0x" + recvData[2].substring(ndx, ndx + 2)); //ascii hex to integer
    sockData[connection] += String.fromCharCode(i);          //build a string
  }

From my limited understanding, this code would create a string, append and create a new string, rinse and repeat. This seems like a bit of overhead. I did consider typed arrays, but how do I convert these back to a string in one go?

The reason i stumbled on this issue is I followed the build instructions - it seems the link gets the latest gcc release for osx. After the problems I found the earlier version that I was also using under Linux.

This was for nrf52.

I have the RAK8212 working fine whilst having the bluetooth disconnected.
Bluetooth.setConsole(true) was the secret for me.

gcc-arm-none-eabi-7-2017-q4-major seems to compile Espruino ok, but the execution seems to end up in the default handler.

Note I'm using the OSX build. Go back to gcc-arm-none-eabi-6-q1-update and all is fine.

I haven't the motivation nor the skills to dig any deeper.

I’ll try that tomorrow. Should the busy flag be reset in the send fail condition?

I'm thinking your code expects an "OK" from the AT+QISEND. This doesn't happen. The sequence should be:
AT+QISEND 0,365\r\n
response is \r\n>[space]
send data
response is \r\n SEND OK\r\n

Thus the current send function in QuectelBG96.js is borken. My current thought is there was a timing issue with the way the original code handled send but it worked most of the time. Adding extra time probably 'fixed' this. On top of this, sometimes there seems to be a discrepancy between the length of data we think we send and what the BG96 thinks it got - I've yet to narrow down on this. Setting flow control seems to help.

The forum gobbled my space - it must've thought it was a html tag, so yes, there is a space after the >

My guess is the listener for the > is not firing.

I've just tried rev 251 to see what happens. The code sends the AT+QISEND, the module responds with the \r\n> and then 1 second later, the code sends AT+QICLOSE

I've issued the command AT+IFC=2,2 to enable flow control. This seems to have made a difference. No hard evidence yet, as the defect only happens occasionally.

A new day and a fresh perspective! I've hooked up the logic analyser and what seems to be happening is that the BG96 isn't receiving enough bytes only sometimes when doing the QISEND. It's expecting 536 bytes and we send around that amount. When it fails, it doesn't give the SEND OK until the next command comes along, which in my case is around 1 second later. That command fails as it gets gobbled up as data. What I am not sure of is which end is at fault. I'll hook up the CTS line to the analyser to see if the module wants us to stop or if the espruino code is not always sending what it should.