Hi Capellio,
Could you share the exact sequence that you are doing for connecting to the network? And the SIM-card is inserted properly in the holder (no visible damages)?
Hi Capellio,
Could you share the exact sequence that you are doing for connecting to the network? And the SIM-card is inserted properly in the holder (no visible damages)?
Blind spot may not be the issue. As mentioned in my earlier post, I can get a UBlox EVB kit connected to NB ioT network in seconds, and at the same place the NB IoT Shield fails to connect. And AT+CSQ results in a constant 99,99 for me too.
Hi Jan,
Is there a way to upgrade firmware on the UBlox SARA N200?
Well somehow it suddenly started to send data. I don’t know the reason but without any changes (since setting the config values) it appears to connect en successfully send data, even in-house (no GPS but that is as expected).
So I plugged it in my car for my wife to collect me some data (she had to drive 300 km for work). That was yesterday and no data was send, at all.
So today I plugged it into my PC again to see what is going on. And immediately it sends out data, again.
The setup in-house and in the car are the same (as in the same device and cable). The only difference is the power supply, at home I use an available USB port, in the car I use the cigarette lighter output. In the car the cell reception is better than in the house and also GPS should work. The car we drive is nothing special so I don’t suspect extra isolation or something to block any signals.
Edit: So it appears the serial monitor necessity was blocking the sketch. I ripped out all println’s and got it working now.
I’m facing the same problem. I successfully setup de NB-IoT Shield while following the setup guidance (great work by the way!). I get the following response on AT+NCONFIG?:
AT+NCONFIG?
+NCONFIG:AUTOCONNECT,FALSE
+NCONFIG:CR_0354_0338_SCRAMBLING,FALSE
+NCONFIG:CR_0859_SI_AVOID,FALSE
OK
And the following response on AT+CSQ:
+CSQ:4,99
Seems to be good?!
When I upload the e.g. humidity / pressure example / GPS, I constantly get the “Failed to connect!” error message. What am I doing wrong?
Hi Roel,
When you get a CSQ you have a signal, but you are not connected yet.
Are you able to send a message with the AT commands?
Regards,
Jan
Hi Jan,
Yes, I am able to send messages. I walked through the AT commands tutorial on support.sodaq.com and all commands were successful.
KR, Roel
Hi @roel
I am happy to hear all commands were successful.
After the successful connect and transmit by AT command, did you try again with the sketch?
Do you still get the error “Failed to connect!”?
Regards,
Jan
Hi @Jan,
I followed the following steps:
Please see the result in attached image
KR, Roel
Hi Roel,
Can you modify the library to provide us with more information.
To enable more debug information about the NB-IoT connection go to the library and edit Sodaq_nbIOT.cpp
Documents\Arduino\libraries\Sodaq_nbIOT\src\Sodaq_nbIOT.cpp
Remove the // on line 24
//#define DEBUG -> #define DEBUG
Make the module more sensetive by changing the _minRSSI on line 111
_minRSSI(-113) // dBm
to
_minRSSI(-103) // dBm
if you are still not able to connect update to
_minRSSI(-93) // dBm
-93 is GSM minimum, nbiot should be 20dBm more sensetive.
Can you share the debug output with us?
Regards,
Jan
Hi @Jan,
please find below the output of the HTS221_HumidityTemperature_nbiot_att and LPS22HB_Pressure_nbiot_demo. Humidity_Temperature the connection succeeded once (-103), as well as GPS example. The second time I got an error (see below). On the Pressure example I got an error directly the first time (-103). I will give it a try on -93.
Output Pressure example:
SODAQ LPS22HB Arduino Example
AUTOCONNECT… OK
CR_0354_0338_SCRAMBLING… OK
CR_0859_SI_AVOID… OK
rdResp: OK
rdResp: OK
rdResp: OK
rdResp: OK
rdResp: OK
rdResp: OK
rdResp: +CSQ:99,99
rdResp: OK
rdResp: +CSQ:99,99
rdResp: OK
rdResp: +CSQ:99,99
rdResp: OK
rdResp: +CSQ:99,99
rdResp: OK
rdResp: +CSQ:4,99
rdResp: OK
rdResp: +CSQ:3,99
rdResp: OK
rdResp: +CSQ:2,99
rdResp: OK
rdResp: +CSQ:2,99
rdResp: OK
rdResp: +CSQ:2,99
rdResp: OK
rdResp: +CSQ:3,99
rdResp: OK
rdResp: +CSQ:3,99
rdResp: OK
rdResp: +CSQ:3,99
rdResp: OK
rdResp: +CSQ:3,99
rdResp: OK
rdResp: +CSQ:3,99
rdResp: OK
Failed to connect!
1022.58 mbar
rdResp: OK
1022.60 mbar
rdResp: OK
Output HumidityTemperature example:
rdResp: OK
rdResp: +NCONFIG:AUTOCONNECT,FALSE
rdResp: +NCONFIG:CR_0354_0338_SCRAMBLING,FALSE
rdResp: +NCONFIG:CR_0859_SI_AVOID,FALSE
rdResp: OK
AUTOCONNECT… OK
CR_0354_0338_SCRAMBLING… OK
CR_0859_SI_AVOID… OK
rdResp: REBOOTING
rdResp:
rdResp: timed out
rdResp: ⸮
rdResp: timed out
rdResp: REBOOT_CAUSE_APPLICATION_AT
rdResp: Neul
rdResp: OK
rdResp: OK
rdResp: OK
rdResp: OK
rdResp: OK
rdResp: OK
rdResp: OK
rdResp: +CSQ:99,99
rdResp: OK
rdResp: +CSQ:99,99
rdResp: OK
rdResp: +CSQ:99,99
rdResp: OK
rdResp: +CSQ:99,99
rdResp: OK
rdResp: +CSQ:4,99
rdResp: OK
rdResp: +CSQ:1,99
rdResp: OK
rdResp: +CSQ:1,99
rdResp: OK
rdResp: +CSQ:1,99
rdResp: OK
rdResp: +CSQ:1,99
rdResp: OK
rdResp: +CSQ:1,99
rdResp: OK
rdResp: +CSQ:3,99
rdResp: OK
rdResp: +CSQ:3,99
rdResp: OK
rdResp: +CSQ:2,99
rdResp: OK
rdResp: +CSQ:2,99
rdResp: OK
Failed to connect!
Hi @roel,
Thanks for sharing the debug results.
When you change the minimal required dBm, it will take longer to get a valid CSQ to start to make a connection.
When you set it on -103 ( CSQ 5 ) or even -93 ( CSQ 10) it will not try to connect if the signal is too low.
With your debug information we can see that you are in a place with poor nb-iot coverage.
Set the minimal signal back to -113 and extend the timeouts to make a connection.
on line 351, you can override the timeout.
if (!attachGprs()) {
default is 30 * 1000, see .h file.
Make it bigger to see if you wait longer you can send a message.
if (!attachGprs(120 * 1000)) {
Hope you can send a message this way.
Regards,
Jan
Thanks, my first test seems to be successfull. Thanks for your help so far, great work!
I can’t help noticing the covarage keeps being dramatic (for me that is).
I have played a little with the minimal required dBm but the effects do not vary.
I put the board in my car this morning and drove to work, I have done this multiple times to different locations and each time I drove 100km or more. Failing to connect at start I could understand but there are multiple parts where the connection keeps failing for long periods of time. I added the plotted output of the GPS registrations in the picture below, each red dot is an registration, the pin is the last one (which wasn’t my destination).
And it’s not that my server isn’t receiving the data. Makerstudio also doesn’t registrate my driving during the same periods of time.
So my next try will be to follow your instructions of changing the timeout value at the attachGprs function call. That would require me to include the source files of the library which is possible but wouldn’t it be better to create an additional call to set this value? The same as the minimum RSSI.
The way back had the same outcome. In the begin multiple registrations and just before Utrecht it disconnected and the remaining 70km never re-connected again.
@Capellio
Thanks for sharing the test results.
Can you next time in the dead area slow down a bit?
NB-IoT does not have the cell-transfer protocol like your phone has.
Example: when you do a phone call you can call without reconnecting to the network, with NB-IoT when you leave a cell you need to reconnect to the new cell this takes time, and with speed it is harder to connect.
I am wondering if you have a lower speed the results are the same.
NB-IoT may not be the best technology for asset tracking.
Let us know.
Jan
Hi @Jan, thanks for the reply.
Early in the morning with an open road
That explains it. Although I am testing it for asset tracking this won’t be a problem I think because the assets it will be used on are boats powered by an electro-motor so the maximum speed will be around 15 km/h max. With the absence of a boat I test it in my car.
[EDIT…]
I put the NS-IoT in my car again this morning and with the current setting I think the coverage is optimal for now. I just drove the allowed speed limit (130 mostly) and there are places with no connection but that is acceptable.
If I want to track faster assets, I assume to switch to the SODAQ One?
This is a lot better then the other highway. Here is gaps are minimal.
I will discuss this with our team.
@Jan : I already implemented this change myself and I put the device in a nice casing and then in a delivery truck of a friend of mine to test it some further. That was last monday (today is wednesday) and unfortunatly yesterday seems to have some kind of problem at ATT and the MQTT connections, messages wheren’t passed trhough. Today (exactly after 00:00 hour data started to come in again) so that seems to be fixed whit some sort of reset
So today is the first day of testing in the field with the current settings:
Although the board may not be the best technology for asset tracking the first results are promissing.
Unfortunately I noticed the sigarette-lighter is not disconnected when the engine is turned off (hence the incomming locations right after 00:00 hour tonight) and I was wondering if this could cause any problems, like draining the car battery. Can you say anythhing about that?
Keep you posted.