Go Down

Topic: MKR NB not working when powered through battery socket (Read 404 times) previous topic - next topic

JohannaB

I have posted regarding the MKR board before but it seems to never stop giving me toubles.

I am trying to run PubSubClient to connect to an MQTT broker with my Arduino MKR NB 1500. When connected to the computer via USB it works completely fine, but as soon as I power it through the battery socket it gets stuck in the "connecting to mqtt-broker" state.

Has anyone else had issues with this? I have tried different voltages on the battery(which is in fact a simulated battery) with no luck. I have also measured so that it stays above the 3.7V limit at all times.

I would be very thankful for any help.

pert

What is the current rating of your simulated battery? The radios can draw a surprising amount of current during communication and if your power supply can't provide enough current then the communication fails.

JohannaB

Hmmm.. I have been running it as a power box with a maximum output on 500mA. It goes to about 400mA when communicating with the network so Im not sure the current would be an íssue.

I actually solved it somehow. On the computer it is enough to run

Code: [Select]

NBClient client;
PubSubClient conn(client);

  boolean connected = false;
  while (!connected) {
    if ((nbAccess.begin(PINNUMBER) == NB_READY) &&
        (gprs.attachGPRS() == GPRS_READY)) {
      connected = true;
    } else {
      delay(1000);
    }
  }



in the setup and then running conn.connect to connect to the broker. But when connected through the battery socket it only works when adding

Code: [Select]



// if the NBclient is not connected, connect it
if(!client.connected()){
    Serial1.println("NBclient not connected");
    connect_modem();
}
connect_modem(){
  boolean connected = false;
  while (!connected) {
    if ((nbAccess.begin(PINNUMBER) == NB_READY) &&
        (gprs.attachGPRS() == GPRS_READY)) {
      connected = true;
    } else {
      delay(1000);
    }
  }
}


before trying to connect to the broker. It then works with no issues. I find this very strange since it seems I am doing the same thing twice but still getting different results.

Do you have any suggestions? Could it be the current or is it more likely to be something else? There is a slight voltage drop when the current goes up to 400mA, but it still stays well over the lower limit. I have also tried many different input voltages and 2 different MKR boards but the problem seems to remain. Could the drop in voltage have an impact on the functionality even though it doesnt go below the limit?

Thanks for your response!

kickouille

Johanna,

I am also a very frustrated MKR NB owner... In summary, I'm now experimenting with the third board shipped by Arduino, as two previous ones were found faulty.

I found out that power management on this board is different than the one on the first board I got.
First board was behaving more like the MKR GSM.

Second board behaves the same way as the third board.

First thing first, do you experience the same?

Interestingly enough, my setup works best when running on battery only... But in certain conditions.

Also, one point if you didn't already do that. In the code, remove
Code: [Select]
while (!Serial);
If any, as it would wait for the Serial connection to the PC to be established.
On battery only this never happens, so you would end up staying in that loop.

May I ask you to try this and tell me if you get the same:

Scenario 1:
1) Connect a charged battery only -> code working, MQTT connection established and stable, keepalives exchanged, green LED slighly ON, very dimmed, but expected
2) Connect a USB power supply to USB port -> green LED goes fully ON, board freezes, not exactly sure where in the code, but my MQTT connection goes of, and I get disconnected from operator's network, and orange LED (charging) stays off.
3) Short press reset button: orange LED comes ON. Connects to my MQTT broker is established, however no subsequent MQTT traffic (I don't publish or subscribe to anything, I only send keepalives), and connection times out on broker side.
4) Disconnect USB power -> orange LED goes off, green LED dimms a bit, but not as much as in point 1. It's on a bit dimmed as it is on the MKR GSM when running on battery only. No MQTT connection coming in.
5) Push reset button again, and we go back to point 1.

Scenario 2:
1) Connect USB power source only -> green LED goes ON, orange LED fast blink, which is expected as no battery is connected, no MQTT connection coming in to my broker.
2) Short press reset button -> green LED stays ON, this time orange LED doesn't fast blink, still no MQTT connection coming in.
3) Connect the battery -> same as point 2
4) Short press reset button -> orange LED comes ON, however no connection to my MQTT broker.
5) Double press to go in bootloader mode -> charging LED goes OFF, built in LED fades up and down.
6) Short press to go out from bootloader mode: orange LED comes ON. Connects to my MQTT broker is established, however no subsequent MQTT traffic, and connection times out on broker side.
7) Disconnect the USB power source: orange and green led are both still on! Yes, you heard me, charging LED is on even though only battery is connected, at least for some time, then it goes off, green led still on (it should not as per documentation when battery only is used). And no connection to my MQTT broker
8) Short press reset button -> back to scenario 1, point 1, stuation which is the only stable one in my case.

It took me ages to figure ths out, because of having to visibility on what is happening. With the MQTT connection, I can clearly see when that work or not.

No be noted that all of this seems to behave differently when USB connection is make to a PC instead of a bear power source...

So that make very difficult to understand where all of this stucks...

Regards

JohannaB

Hi!

Thank you for your long reply. "nice" to know someone is as frustrated as me..

I did remove the !Serial part. But thanks anyways :)

Interesting that yours only works on battery. Is it connected to the battery socket? Because I am experiencing the opposite: the connection is only stable when connected to the USB.

So to answer your questions;
Scenario 1:
1) Not working unless I add the code
Code: [Select]

// if the NBclient is not connected, connect it
if(!client.connected()){
    Serial1.println("NBclient not connected");
    connect_modem();
}
connect_modem(){
  boolean connected = false;
  while (!connected) {
    if ((nbAccess.begin(PINNUMBER) == NB_READY) &&
        (gprs.attachGPRS() == GPRS_READY)) {
      connected = true;
    } else {
      delay(1000);
    }
  }


before trying to connect to the broker. Very strange, since thats already done once in the setup. Green light is slightly on.
2) Green led goes on, connection working fine without the above code in the reconnect method or setup.
3) Works as expected, resets the program if connected to USB port
4 & 5 I am not having the same strange behavior as you do. But im not sure you should have the battery and usb connected at the same time since it should then charge the battery? That might interfere with the code, but Im not sure.


Scenario 2:
1) Same as yours but it connects to the broker.
2) As expected, green led on and no blinking. But the MQTT connection comes in.
3) 4) if we connect the battery here I suppose it will just charge the battery
5) 6) I dont have the same behavior.. hmmmm. Is there something missing in your code? Or did you get a faulty one again? Are you using the RTC library? I have found that it doesnt work properly with the MKR NB board.

I agree that troubleshooting this is a mess. There are inconsistent behaviors and no obvious mistakes. It seems to me to be a hardware issue which makes me wonder if its even worth continuing troubleshooting.

I love arduino but I dont know if releasing a "low power consuming" IoT arduino that cant handle power consumption stuff was the best idea.. ;)

pert

[quote author=JohannaB link=msg=4243502 date=1563267567There is a slight voltage drop when the current goes up to 400mA, but it still stays well over the lower limit. I have also tried many different input voltages and 2 different MKR boards but the problem seems to remain. Could the drop in voltage have an impact on the functionality even though it doesnt go below the limit?
[/quote]
How are you measuring this?

I dont know if releasing a "low power consuming" IoT arduino that cant handle power consumption stuff was the best idea.. ;)
Low power is about average power consumption. A device that sleeps at a few microamps 98% of the time, runs at a few milliamps 1.9% of the time, and draws 400 milliamps .1% of the time is pretty low power consuming, but it still needs a power supply that can provide those bursts of current when needed.


JohannaB

I am measuring it with an Otii device, made for IoT energy optimization. (https://www.qoitech.com/)

I am aware that this is about average consumption. If it would sleep at a few microamps I would be very happy, but it draws at least 10mA in regular sleep mode. When trying to put the modem to sleep with AT commands and PSM settings the power consumption actually goes up. This is an issue that I have addressed in a previous post on the forum. Thanks for the input though!


pert

If it would sleep at a few microamps I would be very happy, but it draws at least 10mA in regular sleep mode. When trying to put the modem to sleep with AT commands and PSM settings the power consumption actually goes up. This is an issue that I have addressed in a previous post on the forum.
The numbers I mentioned were just a hypothetical example, but I understand what you're saying. 10 mA sleep current is not much fun. I'm following that thread and it's quite unfortunate. Sadly, I don't have any experience in that area to help you out with the issue, but I'm interested to learn of the solution when you find it.

jmer3355

#8
Oct 08, 2019, 04:03 pm Last Edit: Oct 09, 2019, 09:37 am by jmer3355 Reason: add code
I have posted regarding the MKR board before but it seems to never stop giving me toubles.

I am trying to run PubSubClient to connect to an MQTT broker with my Arduino MKR NB 1500. When connected to the computer via USB it works completely fine, but as soon as I power it through the battery socket it gets stuck in the "connecting to mqtt-broker" state.

Has anyone else had issues with this? I have tried different voltages on the battery(which is in fact a simulated battery) with no luck. I have also measured so that it stays above the 3.7V limit at all times.

I would be very thankful for any help.

Hi,

same or similar happening here, the following sketch (UDP Ntp example) slightly modified, just added some led on/off lines for debugging, works fine when powered from USB but reboots continuously when powered from Vin (5V/2A)

Code: [Select]

/*

  Udp NTP Client

  Get the time from a Network Time Protocol (NTP) time server
  Demonstrates use of UDP sendPacket and ReceivePacket
  For more on NTP time servers and the messages needed to communicate with them,
  see http://en.wikipedia.org/wiki/Network_Time_Protocol

  created 4 Sep 2010
  by Michael Margolis
  modified 9 Apr 2012
  by Tom Igoe

  modified 6 Dec 2017 ported from WiFi101 to MKRGSM
  by Arturo Guadalupi
 
  This code is in the public domain.

*/

#include <MKRNB.h>

#include "arduino_secrets.h"
// Please enter your sensitive data in the Secret tab or arduino_secrets.h
// PIN Number
const char PINNUMBER[]     = SECRET_PINNUMBER;

unsigned int localPort = 2390;      // local port to listen for UDP packets

IPAddress timeServer(129, 6, 15, 28); // time.nist.gov NTP server

const int NTP_PACKET_SIZE = 48; // NTP time stamp is in the first 48 bytes of the message

byte packetBuffer[ NTP_PACKET_SIZE]; //buffer to hold incoming and outgoing packets

// initialize the library instance
NBClient client;
GPRS gprs;
NB nbAccess;

// A UDP instance to let us send and receive packets over UDP
NBUDP Udp;

void setup()
{
  // Open serial communications and wait for port to open:
  Serial.begin(9600);

// initialize digital pin LED_BUILTIN as an output.
  pinMode(6, OUTPUT);
  digitalWrite(6, HIGH);   // turn the LED on (HIGH is the voltage level)
  int count;
  for(count=0;count<50;count++)
  {
    if(!Serial)
    {
        delay(100);
        if(count%2)
            digitalWrite(6, LOW);    // turn the LED off by making the voltage LOW
        else
            digitalWrite(6, HIGH);    // turn the LED off by making the voltage LOW
    }
    else
      break;
  }
  digitalWrite(6, LOW);
 
  Serial.println("Starting Arduino GPRS NTP client.");
  // connection state
  boolean connected = false;

  // After starting the modem with NB.begin()
  // attach the shield to the GPRS network with the APN, login and password
  while (!connected) {
    if ((nbAccess.begin(PINNUMBER) == NB_READY) &&
        (gprs.attachGPRS() == GPRS_READY)) {
      connected = true;
    } else {
      Serial.println("Not connected");
      delay(1000);
    }
  }

  Serial.println("\nStarting connection to server...");
  Udp.begin(localPort);
}

void loop()
{
  digitalWrite(6, !digitalRead(6));
  sendNTPpacket(timeServer); // send an NTP packet to a time server
  // wait to see if a reply is available
  delay(1000);
  if ( Udp.parsePacket() ) {
    Serial.println("packet received");
    // We've received a packet, read the data from it
    Udp.read(packetBuffer, NTP_PACKET_SIZE); // read the packet into the buffer

    //the timestamp starts at byte 40 of the received packet and is four bytes,
    // or two words, long. First, esxtract the two words:

    unsigned long highWord = word(packetBuffer[40], packetBuffer[41]);
    unsigned long lowWord = word(packetBuffer[42], packetBuffer[43]);
    // combine the four bytes (two words) into a long integer
    // this is NTP time (seconds since Jan 1 1900):
    unsigned long secsSince1900 = highWord << 16 | lowWord;
    Serial.print("Seconds since Jan 1 1900 = " );
    Serial.println(secsSince1900);

    // now convert NTP time into everyday time:
    Serial.print("Unix time = ");
    // Unix time starts on Jan 1 1970. In seconds, that's 2208988800:
    const unsigned long seventyYears = 2208988800UL;
    // subtract seventy years:
    unsigned long epoch = secsSince1900 - seventyYears;
    // print Unix time:
    Serial.println(epoch);


    // print the hour, minute and second:
    Serial.print("The UTC time is ");       // UTC is the time at Greenwich Meridian (GMT)
    Serial.print((epoch  % 86400L) / 3600); // print the hour (86400 equals secs per day)
    Serial.print(':');
    if ( ((epoch % 3600) / 60) < 10 ) {
      // In the first 10 minutes of each hour, we'll want a leading '0'
      Serial.print('0');
    }
    Serial.print((epoch  % 3600) / 60); // print the minute (3600 equals secs per minute)
    Serial.print(':');
    if ( (epoch % 60) < 10 ) {
      // In the first 10 seconds of each minute, we'll want a leading '0'
      Serial.print('0');
    }
    Serial.println(epoch % 60); // print the second
  }
  // wait ten seconds before asking for the time again
  delay(10000);
}

// send an NTP request to the time server at the given address
unsigned long sendNTPpacket(IPAddress& address)
{
  //Serial.println("1");
  // set all bytes in the buffer to 0
  memset(packetBuffer, 0, NTP_PACKET_SIZE);
  // Initialize values needed to form NTP request
  // (see URL above for details on the packets)
  //Serial.println("2");
  packetBuffer[0] = 0b11100011;   // LI, Version, Mode
  packetBuffer[1] = 0;     // Stratum, or type of clock
  packetBuffer[2] = 6;     // Polling Interval
  packetBuffer[3] = 0xEC;  // Peer Clock Precision
  // 8 bytes of zero for Root Delay & Root Dispersion
  packetBuffer[12]  = 49;
  packetBuffer[13]  = 0x4E;
  packetBuffer[14]  = 49;
  packetBuffer[15]  = 52;

  //Serial.println("3");

  // all NTP fields have been given values, now
  // you can send a packet requesting a timestamp:
  Udp.beginPacket(address, 123); //NTP requests are to port 123
  //Serial.println("4");
  Udp.write(packetBuffer, NTP_PACKET_SIZE);
  //Serial.println("5");
  Udp.endPacket();
  //Serial.println("6");
}



did u have any progress with that?

Best regards

Jordi

Go Up