Search results for:

It doesn’t work even with small packets! It looks like it gets out of sync by one line.
I’m currently using the previous code with an extra timeout. This works around 80% of the time. I’ve soldered some wires onto the rxd and txd to the bg96 and will get some logic analyser samples. This should give us some hard evidence. I should be able to post some pix tomorrow ( my time).

The horizontal members are most likely groundplane and not radiators. I gather the antenna was to be ultimately installed outdoors, so with any significant distance the loss of the coax becomes a consideration. Thankfully, with the advent of WiFi, the demand for cheap low loss coax was created and we got the likes of LDF400 that have significantly better performance than RG213 and also means we don't need to work with Heliax. (if you don't know what heliax is - Google it and compare the loss between RG213/LDF400 and Heliax at 800-900MHz)

I think I'm going to have to use the logic analyser to get some hard evidence as to what happens with the send function.

Here it is:

  atcmd("ATE0").then(function() {// echo off
        return atcmd("AT+CEREG=2"); //turn on extended cereg response for cell tower info
    }).then(function() {
        return new Promise(function(resolve, reject) {
            var n = 60;
            var done = false;
            var i = setInterval(function() {
                at.cmd(options.lte?"AT+CEREG?\r":"AT+CRE­G?\r",500,function(d)
                    {
                        var n = d.split(",")[1]; //1 =connected,5=connected,roaming
                        if (n==1 || n==5)
                        {
                            clearInterval(i);
                            resolve();
                        }
                    });
                if (n-- <= 0) {
                    clearInterval(i);
                    reject("Timeout!");
                }
            }, 1000);
        });
    }).then(function(d) {
        return atcmd("AT+CGATT=1",10000); // attach to GPRS service

Initial tests indicate....... failure. Seems to be highly unreliable. I must preface this by saying I merged your changes into my code, so I may have missed something. So I've reverted the changes and are working from 225. I'm trying to get something working so I can test over the weekend, so I'll revisit this next week.

Why was it hard for me to make the changes? I'm not the most experienced javascript programmer, so some of the idioms leave me perplexed. Like returning the closure. I wrote a little program to see what happens with return cb; vs return cb(d);
I got the idea of registering/unregistering the > prompt, but I was unsure of the context since the two functions were slightly different. I'll get there eventually.....

As for the changes I've made to the BG96 code, I added the retry on the CREG?/CEREG? I can send you the code to see if you want to incorporate it?

Gordon, i couldn’t figure out how to graft the esp8266 code in. I did some more investigation and it seems the code doesn’t allow enough time for the send to complete and respond. Cat-nb1 is only 20kbit/s methinks, so it takes a bit longer than gsm/lte. I changed the timeout from 2000 to 10000. I’ve yet to do extensive testing to verify this.

Thanx. I’ll give it a go.

This is probably the same on other nRF52832 based devices. Currently I'm using the bluetooth web ide to talk to the RAK8212 module. That works fine. Where things go wrong is when I have code running that is talking to the BG96 and I disconnect from bluetooth. The code talking to the BG96 no longer seems to work. Similarly, when I save() the code and have it startup, things don't seem to work as they should. 'work' meaning the code seems to execute, but comms with the BG96 have been interrupted.
Also what might be compounding the problem is that I have an analog input in use which is on port D28 (serial rxd) and there is a comment in the code that mentions a logic 1 on the rxd (D28) will cause the serial port to be re-routed to pins D28/29.

I'm not fully understanding the logic as to where the console and Serial1 streams end up in the various use cases and if there's a simple solution to force the logic.

The board i was using has a bg96 and the designers were kind enough to provide a usb connector. Yes, i was using qflash. As for the RAK modules, they’re still stuck with the version 5 firmware.

Gordon, thanks for the code snippet. I was able to incorporate the CEREG poll into the bg96 connect function. Now it powers the module, waits 5 seconds then polls the module for the cell to connect. This makes it startup a bit faster.

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

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.

Nice to see you added a capacitor. If you wanted to do an equivalent of the opto, but in mosfets, then you'd need a p-chan and an n-chan. The devil is in the details, so you'd have to analyse the circuit to see if there is any specific advantage in switching the resistor divider. There has probably been discussion on the likes of stack exchange as this is not a new problem. Low power circuitry is tricky as you need to analyse just about every component for the likes of leakage and temperature sensitivity.

That's not going to work! If the gate is at 3.3V and the source is at 3.3V, then no current will flow.
I'm not in a position to work through this issue at the moment. Obviously, the 'simple' solution is to use higher value resistors. The values I used were simply an example not taking into account of current draw. With higher value resistors you need to take into account leakage currents. Your solution of using an opto, whilst 'it works' it's not really a clean solution. The opto itself gives you no protection from spikes in the method you're using it. Note that I pulled the part bss138 off the top of my head before I saw your ascii art diagram.

Since I've made tweaks to the BG96 module, I copied the changes to my module and tried it.
The first time failed:

{\"rssi\":{"
[BG96] AT+QISEND response undefined  <<<<< here it stopped
>state()
=undefined
] "\r\nSEND OK\r\n"
>state()
=undefined
] "\r\n+QISTATE: 0,\"TCP\",\"11"
] ".123.33.456\",80,6804,2,1,0,1,\"uart1\"­\r\n\r\nOK\r\n"
>state()
=undefined
] "\r\n+QISTATE: 0,\"TCP\",\"1”
] "1.123.33.456\",80,6804,2,1,0,1,\"uart1\­"\r\n\r\nOK\r\n"
] "\r\n+QIURC: \"recv\",0,195\r\nHTTP/1.0 504 Gateway Time-out\r\nCache-Control: no-cache\r\nConnection: close\r\nContent-Type: text"
[BG96] [
  "+QIURC: \"recv\"",
  "0",
  "195"
 ]
] "\r\n\r\n+QIURC: \"closed\",0\r\n"
["AT+QICLOSE=0\r\n"
--><html><body><h1>504 Gateway Time-out</h1>
The server didn't respond in time.
</body></html>
] "\r\nO"
] "K\r\n"
>gprs.debug()
={
  socks: [ undefined ],
  sockData: [
    "",
    "",
    "",
    "",
    "",
    ""
   ],
  busy: false }

The second time looked like it worked as the webserver responded, so it was happy with the amount of data it got.

{\"rssi\":{"
] "\r\nSEND OK\r\n"
[BG96] AT+QISEND response "> "
[BG96] AT+QISEND response "SEND OK"
] "\r\n> "
["\"value\":\"99\",\"unit\":\"dBm\"},\"B­ER\":{\"value\":\"99\",\"unit\":\"%\"}}}­]}"
] "\r\nSEND"
[BG96] AT+QISEND response "> "
] " OK\r\n"
[BG96] AT+QISEND response "SEND OK"
]

My guess it might be a timing sensitivity with the prompt??

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.

If you're worried about power consumption then look at the specs for the mic5219 regulator on the RAK8212 board. Torex have some cmos regs where the quiescent current is much less.

I think you're off by a factor of 10! My calculator says 244uA. I'm measuring a battery whose self discharge is well in excess of 244uA. Opto? Why not just a mosfet like a BSS138? Optos are always the last resort as they age, have wide parameter spread and so on.

You'll need to provide a resistor divider on port bit D28 (which is the only analog input) to scale the voltage between 0-3.3V. Then:

pinMode(D28,'analog');
value = analogRead(D28) * scale_factor;

You'll have to figure out the scale factor yourself - 3.3V is full scale which is a value of 1. For example, I'm using a voltage divider to read a 12V battery with a 39k and 10k resistor. The scale factor is 16.21.

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.

Gordon,
the close() issue is fixed, but the sending of the remaining data seems to be lingering.

>sendCloud()
Length:406 {"measurements":[{"source":{"id":"123456­7"},"time":"","type":"CurrentSensor","c8­y_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":"1234567"},"tim­e":"","type":"c8y_SignalStrength","c8y_S­ignalStrength":{"rssi":{"value":"99","un­it":"dBm"},"BER":{"value":"99","unit":"%­"}}}]}
================================
["AT+QIOPEN=1,0,\"TCP\",\"11.222.33.123\­",80,0,1\r\n"
=undefined
] "\r\nOK\r\n"
] "\r\n+QIOPEN: 0,0\r\n"
] "\r\n>"
] " "
["POST /peppap/xxx HTTP/1.1\r\nUser-Agent: Espruino 1v99.225\r\nConnection: close\r\nContent-Type: application/json\r\nContent-Length: 406\r\nAuthorization: Basic NannyPlumRulesYWRp==\r\nHost: \r\n\r\n{\"measurements\":[{\"source\":{­\"id\":\"1234567\"},\"time\":\"\",\"type­\":\"CurrentSensor\",\"c8y_CurrentMeasur­ement\":{\"Sensor1\":{\"value\":11.1,\"u­nit\":\"A\"},\"Sensor2\":{\"value\":22.2­,\"unit\":\"A\"},\"Sensor3\":{\"value\":­33.3,\"unit\":\"A\"},\"Sensor4\":{\"valu­e\":44.4,\"unit\":\"A\"}}},{\"source\":{­\"id\":\"1234567\"},\"time\":\"\",\"type­\":\"c8y_SignalStrength\",\"c8y_SignalSt­rength\":{\"rssi\":{\"value\":\""
] "\r\nSEND OK\r\n"
>state()
=undefined
] "\r\n+QISTATE: 0,\""
] "TCP\",\"11.123.33.123\",80,14516,2,1,0,­1,\"uart1\"\r\n\r\nOK\r\n"
>close(0)
=undefined
] "\r\nOK\r\n"
>state()
=undefined
] "\r\nOK\r\n"
>sendCloud()
Length:406 {"measurements":[{"source":{"id":"123456­7"},"time":"","type":"CurrentSensor","c8­y_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":"1234567"},"tim­e":"","type":"c8y_SignalStrength","c8y_S­ignalStrength":{"rssi":{"value":"99","un­it":"dBm"},"BER":{"value":"99","unit":"%­"}}}]}
================================
["AT+QIOPEN=1,1,\"TCP\",\"11.123.44.123\­",80,0,1\r\n"
=undefined
] "\r\nOK\r\n"
] "\r\n+QIOPEN: 1,0\r\n"
] "\r\nERROR\r\n"
["99\",\"unit\":\"dBm\"},\"BER\":{\"valu­e\":\"99\",\"unit\":\"%\"}}}]}"
>close(0)
=undefined
] "\r\nOK\r\n"
> 

We can see on the second invocation of sendCloud() that it 'knows' about the left over data, but the send fails.

  options = {
    host: CLOUD_PROVIDER,
      port: '80',
      path: "/peppap/xxx",
      method:'POST',      
      headers: {"Content-Type":"application/json", 
                "Content-Length": body.length,
                "Authorization":  CUMULOCITY_AUTH,
                "Host":""
               }
  };
  //print(options);
  print(`Length:${body.length} ${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.");
    });
  });
  req.end(body);

Gordon, I had hoped you'd pick up on the problem! It now builds for me.

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

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.

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.