Posts made by Crowdsourcer

LiPo is fine (almost new 6000mAh)! I checked the schematics again and it appears that the 3.8V is produced from the LiPo by charge controller BQ24195. This 3.8V is then fed to the SARA modem and a LDO voltage regulator (AP2112) and converted to 3.3V. Seems that something is wrong with this converter, or its configuration?

Some follow up since last year: My MKR NB1500’s are all running on LiPo’s and the SARA modem is not transmitting any more at voltages below 3.8V. I looked up the schematics of this board and it appears that there is a 3V8 powerline for the SARA modem. However it is not produced anywhere on the board? The SARA modem power requirements state “typical 3.8V” so it could be that my SARA’s are a batch that does not like voltages even slightly lower than 3.8V? Seems like a bad board design? Anyone experiencing the same problems?

@Stefan-de-Lange
Yes, this is how it should work, and would save a lot of reconnection time, but so far I think >15mA is too much (reconnection time is about 20 s at around 60 mA on average).

@Crowdsourcer said in Arduino MKR NB1500: lukt niet om te verbinden.:

@Martijn-Kooijman @Stefan-de-Lange
Some news after the update (to 2.04): Lowpower.sleep (or deepSleep) has improved by a factor 2! The current reduced to 0.48 mA, still not very low power but at least an improvement.
The command AT+URAT=8 is not recognized anymore (comunication selection for NB only). It also seems that it sometimes needs a lot of time to open a channel after a deep_sleep (varies between 10 s and >30s which wastes energy).

I can confirm now that AT+URAT=8 works with the new firmware! Probably because I changed: AT+UMNOPROF=100 (European profile).

@Stefan-de-Lange
I tried AT+CPSMS=1 but the Arduino board consumed >15 mA during sleep. No idea why, but I think for the Arduino board it is easiest to just use the power_on pin (note that this is not the power supply pin!).

@Stefan-de-Lange
I just tested the SARA PSM setting:
Changed from default 0 to 4: AT+UPSV=4
After about 6 s inactivity it enters sleep mode and requires a dummy character to send to wake it up. I get reliable connection each time (using AT+USOCR=17,7000). So far so good,
however, sleep currents too high now (>10mA) and I also observe regular increases to >40 mA and accidental short drops <1 mA.
So it seems the SARA is consuming much more than your suggested 7uA during sleep time.

@Stefan-de-Lange
-The reset pin is used in the Arduino supplied SerialSARAPassthrough program so that seems fine to use for a reset.
-I did not test PSM, in default configuration it is off.
-I tested AT+UMNOPROF? and it is default 0, I then changed it to 100 (Standard Europe), but AT+URAT is still not available.
-For now after each wake up I do the following sequence (about 14 seconds in total):
AT+CFUN=0
AT+CEREG=3
AT+CFUN=1
wait for “CEREG:…” in a SARA response string
AT+COPS=1,2,“20416”
AT+USOCR=17,7000
check for USOCR: 0
then send data…

So far it seems to work fine.

@Stefan-de-Lange
Yes, still high, but there are more peripherals (such as the charger IC) so I think something like 50 uA should be expected.
Before sleep I do:
digitalWrite(SARA_PWR_ON, LOW); //to shut down the ublox

After sleep I need to switch on the modem and do a reset:
digitalWrite(SARA_PWR_ON, HIGH);
delay(100);
digitalWrite(SARA_RESETN, HIGH);
delay(100); //default 100
digitalWrite(SARA_RESETN, LOW);

I first wait about 10 s, then I open a port:
“AT+USOCR=17,7000”
I usually get an error: “+CME ERROR: Operation not allowed”
So I need to repeat this until I get:
+USOCR: 0
That usually takes between 12 and more than 40s.

Since URAT is not possible any more, it seems as if it has difficulty selecting NB?
Any recommendations to make this more reliable?

@Martijn-Kooijman @Stefan-de-Lange
Some news after the update (to 2.04): Lowpower.sleep (or deepSleep) has improved by a factor 2! The current reduced to 0.48 mA, still not very low power but at least an improvement.
The command AT+URAT=8 is not recognized anymore (comunication selection for NB only). It also seems that it sometimes needs a lot of time to open a channel after a deep_sleep (varies between 10 s and >30s which wastes energy).

@Martijn-Kooijman
This procedure was also recommended by Arduino. Exactly do as described by Zbelding: use Extra putty (his step 3). You can check if Extra putty works by entering an AT command such as ATI9, if all is fine the modem will return the current firmware. To be safe, just use Extra putty, it is a free download.
Did you wait the 21 minutes (step 18)?

@Martijn-Kooijman

https://ublox-firmware.s3.amazonaws.com/L0506A0201-to-L0508A0204.zip

https://ublox-firmware.s3.amazonaws.com/L0506A0200-to-L0508A0204.zip
(I had version 2.00 so I used the second zip)

@Martijn-Kooijman
https://forum.arduino.cc/index.php?topic=628808.15
Zbelding updated his update procedure on 25 June. You may have tried his first version? First check what version you have by using command ATI9. Then select the proper zip file download somewhere else on that forum. Works exactly as described. Meanwhile there could be a newer version, for that I will contact Ublox.

@Stefan-de-Lange @Martijn-Kooijman
No need to solder anything, I just did the serialpassthrough method of updating firmware and it works perfectly fine! First check with ATI9 what firmware you have, mine was 2.00.

@Martijn-Kooijman
I commented out the port initialisation in
…\AppData\Local\Arduino15\packages\arduino\hardware\samd\1.8.6\cores\arduino\wiring.c
looks like this now: //pinMode( ul, INPUT ) ;
I now measure a sleep current of 0.95 mA, still way too high for IoT. I did reset the board, but no change. I did read about MKRFOX1200 achieving 50 microA, so should be possible for this one also…
I measured it at the LiPo wires. My sensors consume very little power, so they are not to blame, or is the SAMD pin assignment changing the currents within the SAMD internally?

@Martijn-Kooijman @Stefan-de-Lange
Solved! After receiving @ I use following command:
SerialSARA.write((uint8_t*)&payload, payload_size);
(It was first a Char array and this worked not ok for value 0 but strange enough worked for other numbers).
Next issue I will focus on is the sleep mode power consumption, getting it below 1.2mA.

@Martijn-Kooijman double the amount of data! Suppose there is a limit of 500 bytes (hypothetical, but I don’t know exactly how much T-mobile allows), I would then only be able to send 250 bytes.
I can binary using terminal emulator so it should be possible programming it correctly…

@Stefan-de-Lange Thanks, RealTerm works great and I could easily send sixteen 0x00 and it was received as 0x00 at TMobile. So it means that something is wrong with my Arduino code implementation. Really strange that my script fails on 0x00.

@Stefan-de-Lange Good point, I use the Arduino IDE.

@Stefan-de-Lange
I just checked with the passthrough sketch. I first send:
AT+USOST=0,“172.27.131.100”,15683,16
Then after the @ I send 0000000000000000 (16 zero’s). I get the ascii code for zero (this is 30 hex) 16 times at T-Mobile. So this is not binary!
At least with my code I could send binary as long as I did not send a zero.

@Stefan-de-Lange
Yes, I started now with fixed byte values. When I change the value of any of the 16 bytes to a value zero it does not send anything anymore. As soon as I change the zero byte to 1 it sends again. Seems like a SARA modem bug?

@Stefan-de-Lange @Martijn-Kooijman
Sorry for spamming you again, but the script is not reliable. I could not repeat reliable results and only one message was sent last night (I am sending every 15 min.). Certain hex values or a combination of them still seem to be interpreted as control characters. I will try to find those “forbidden” numbers. Sending control characters such as CR or ETX are not causing issues and are just treated as binary. I may need to resort to Base syntax, but I don’t like sending the double amount of data.

@Stefan-de-Lange @Martijn-Kooijman
Thanks for the help, appreciated!

@Stefan-de-Lange
I can confirm that it is working now. I managed to send the CR code 16 times as binary code and it arrives as 0D0D0D… HEX code.
//Solution for sharing
//sending binary data in binary extended syntax for SARA module
//measure (here a t and h float are converted into scaled unsigned 16 bit temperature and humidity values)…
uint16_t temperature_coded=round((t+40)/ 100 * 65535); //scale: -40C=0, 60C=65535
uint16_t humidity_coded = round(h / 101 * 65535); //scale: 0%=0,101%=65535
char payload[payload_size]; //define array of char
//write coded measurements into the char array
payload[0] = (byte) ((temperature_coded & 0xFF00) >> 8 );
payload[1] = (byte) ((temperature_coded & 0X00FF) );
payload[2] = (byte) ((humidity_coded & 0xFF00) >> 8 );
payload[3] = (byte) ((humidity_coded & 0X00FF) );
//payload[…etc… sendcommand=“AT+USOST=0,“172.27.131.100”,15683,”+String(payload_size);
cmd(sendcommand); //cmd: see previous post
cmd(payload);