[Sara Damiano]

All of the network selection/registration is done by the u-blox firmware.  The Mayfly’s mcu tells the Digi mcu to tell the u-blox mcu to automatically select the network.  ModularSensors doesn’t even both to ask which network gets selected.  It could ask, but I never cared enough to implement it.

ModularSensors is also requesting automatic selection between LTE-M and NB IoT and the same telephone chain makes it happen.  But, in reality, if you’re using a Hologram SIM, you will never use NB IoT.  Hologram doesn’t currently support it in the USA.  (https://community.hologram.io/t/nb-iot-usa/3434/7).  All of their advertising makes it look like they do, but if it’s actually true for anywhere in the world, it’s not true for the USA.

I have the Tagolas Maximus that Beth linked, the same Pulse that you have, a PCB trace style antenna from a GPRS bee, and a unknown brand (came with a kit) stick antenna with an SMA/uFL adapter currently on my desk.  Right this instant (literally right now) I’m seeing CSQ [scale of 0-30) of 12-16 with the Tagolas, 17-18 with the Pulse, 17 with the PCB antenna, and 18-19 with the stick antenna.  (Yup, I just yanked the uFL off that many times just for you guys.)  I personally prefer the little PCB trace antenna.  I pretty sure the reason my big Tagolas antenna is so much more variable and lower than the others is that it’s big and thin and has gotten crumpled up sitting on my desk (hence my preference for the stiff PCB antenna).  When using the flat patch style antennas, the orientation of the antenna and the cable can make a big difference – the data sheets for them have pictures of the exact amount of curve they’re supposed to have.  Running any power cables the wrong way across the antenna can also kill you signal.  (Remeber how one of the iPhones once had a warning about “don’t hold them this way” or you’ll get bad service?)

 

 

Attachments:

1. 

   20200221_120208-scaled.jpg
   

[Sara Damiano]

I’m sorry!  It looks like it somehow missed the dependencies in the install.  Try running the command pio lib install EnviroDIY_ModularSensors

[Sara Damiano]

Hm.  Did you restart VSCode after changing the path?  Can you open up a new terminal and successfully run git?

I’m sorry; I know dealing with these setup things can be really frustrating.  I really appreciate you working through it on the forum where it might be able to help someone else, too.  It’s been such a long time since I first started out that I forget the beginning steps.

[Sara Damiano]

The git problem is probably another “path” issue.  Did you add git to your “path” when you installed it?  I don’t remember if the installer gives you the option.

Try checking your path and adding the directory where git installed to it.  The git executable (git.exe) is probable installed in “C:\Program Files\Git\bin”  Here are some instructions for adding a directory to the path:  https://helpdeskgeek.com/windows-10/add-windows-path-environment-variable/

 

[Sara Damiano]

The DRWI_CitSci.ino, once corrected, is what will go in the src/main.cpp location correct?

Correct.  🙂

The platformio.ini you need is here:  https://github.com/EnviroDIY/ModularSensors/tree/master/examples/DRWI_CitSci

I’ve had problems with the python path before, not just with platformio, but with other programs as well.  I’ve had to uninstall and re-installed all of python and anaconda several times over the years.  It’s not been a huge number of times, but I haven’t ever tracked down the reason it got screwy.  I’ve kind-of accepted that as an annoyance of python.

[Sara Damiano]

If you are still getting library compiler errors after fixing your sketch, I would strongly prefer to guide you through using PlatformIO. It really is easier, even though it feels much more “programmer” then the more “hobbiest” Arduino IDE.

Very , very briefly:

1. Open the “PlatformIO home”, and create a new project
2. After your project is created, delete the contents of the new platformio.ini file and replace them with the contents of the same file from the folder where you copied your code from on GitHub
3. Delete the contents of src/main.cpp and replace it with your corrected sketch
4. Open the PlatformIO menu (looks like a bug) and select “build.” it should download the proper versions of all the libraries and their dependencies (which might lake a few minutes ) and then compile.

If you really, really want to use the Arduino IDE and you can’t get it to compile there, please post a screen shot of your libraries folder for the Arduino IDE (probably in documents/Arduino/libraries or something similar). Make sure the screen shot shows everything. Also go to the Arduino IDE’s library tool and list out all the libraries and versions it shows are installed. Post the screen shot , your corrected code , and the full error log your getting so I can try to figure out where to help next.

[Sara Damiano]

It looks like when you created your sketch, instead of starting with a completely empty file you pasted your code into the middle of the Arduino IDE’s placeholder code.  So there are chunks of that at the beginning and end which you need to remove.

 

From the beginning, delete this :

void setup() { // put your setup code here, to run once: } void loop() { // put your main code here, to run repeatedly:

From the end, delete this :

 

} // ========================================================================== // Main loop function // ==========================================================================

 

The last line in your code should be a closing curly brace.

[Sara Damiano]

That’s a lot of compiler errors!

Could you post your program (“sketch_jan07a.ino”)?  I’m guessing based on the errors that there might be a stray quotation mark or a missing semicolon somewhere that’s throwing the whole thing off.

It looks like you have also some of the libraries installed multiple times and I’m guessing some might not be installed.  Did I mention that library management with the Arduino IDE isn’t easy?  That’s it’s biggest downside.  ModularSensors has so many dependencies that managing them gets pretty painful pretty fast with the Arduino IDE.  (Sorry!)  But it is definitely doable!

Can you check your library folder like I described back in November?  Again, if you’ve written programs before that you want to work again exactly as they did in the past, you’ll have to crawl through each library checking for versions, but if not you might as well delete them all and start over.

[Sara Damiano]

You shouldn’t really need the development board.  If you’re going to use a bunch of the XBee’s I’d say it’s a $70 well spent, but you shouldn’t *need* it.

Nothing looks wrong in your program.  I’m guessing you’re just not connecting to the internet.  What build flags are you running with?  Can you set all of these and post the log from the serial port monitor:

INI

build_flags = -DSDI12_EXTERNAL_PCINT -D TINY_GSM_RX_BUFFER=64 -D TINY_GSM_YIELD_MS=2 -D TINY_GSM_DEBUG=Serial -D MS_LOGGERMODEM_DEBUG -D MS_LOGGERMODEM_DEBUG_DEEP -D MS_DIGIXBEE_DEBUG -D MS_DIGIXBEECELLULARTRANSPARENT_DEBUG -D MS_DIGIXBEECELLULARTRANSPARENT_DEBUG_DEEP -D MS_DIGIXBEE_DEBUG -D MS_DIGIXBEELTEBYPASS_DEBUG -D MS_DIGIXBEELTEBYPASS_DEBUG_DEEP

1 2 3 4 5 6 7 8 9 10 11 12 13

build_flags =     -DSDI12_EXTERNAL_PCINT     -D TINY_GSM_RX_BUFFER=64     -D TINY_GSM_YIELD_MS=2     -D TINY_GSM_DEBUG=Serial     -D MS_LOGGERMODEM_DEBUG     -D MS_LOGGERMODEM_DEBUG_DEEP     -D MS_DIGIXBEE_DEBUG     -D MS_DIGIXBEECELLULARTRANSPARENT_DEBUG     -D MS_DIGIXBEECELLULARTRANSPARENT_DEBUG_DEEP     -D MS_DIGIXBEE_DEBUG     -D MS_DIGIXBEELTEBYPASS_DEBUG     -D MS_DIGIXBEELTEBYPASS_DEBUG_DEEP

The output might be very long; you’ll probably see a _lot_ of lines that are AT+CEREG? and responses to that.  That’s the Mayfly asking the cellular chip on the XBee3 if it’s registered on the network yet.  If you eventually get a +CEREG=5 (or 1), you’re registered.  If the response is still a 2 or 4 you’re not registered with the network.  If you get as far as being registered and then you’re still not able to post data, that’s a problem with your code or my library.  If you’re never registered, it’s the bee or the sim.

Some things to try if you’re not getting registered:

• Increase the time modem.connectInternet(120000L) up to 10 or 15 minutes (it’s in ms, 120000L = 2 minutes; 600000L = 10 minutes, the “L” tells the compiler it’s a “long” number).  Making the initial connection with a new sim/board/tower may take a really long time.
• Flip back and forth between using “bypass” and “transparent” mode.  See if one works.
• Run a basic program on your Mayfly that just wakes up the bee and leaves it awake.  Let it sit a long while and see if you ever connect.  Something like this should work:
• C++

  #include <Arduino.h> void setup() { Serial.begin(115200); Serial1.begin(9600); pinMode(23, OUTPUT); // make sure the XBee is awake digitalWrite(23, LOW); } void loop() { delay(1000); Serial1.print("+++"); // Enter command mode delay(1000); Serial1.print("ATAI\r"); // Ask if we're connected to the network while (Serial1.available()) { Serial.write(Serial1.read()); } delay(300000L); // wait 5 minutes before asking again }

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

  #include <Arduino.h>   void setup() {     Serial.begin(115200);     Serial1.begin(9600);     pinMode(23, OUTPUT);  // make sure the XBee is awake     digitalWrite(23, LOW); }   void loop() {     delay(1000);     Serial1.print("+++");  // Enter command mode     delay(1000);     Serial1.print("ATAI\r");  // Ask if we're connected to the network     while (Serial1.available())     {         Serial.write(Serial1.read());     }     delay(300000L);  // wait 5 minutes before asking again }

  If you eventually get a “0” (zero) response, you’re finally connected.  A “22” or “FF” means it’s searching or the status is unknown.  A “25” means registration has been denied – if you get that, your APN that you set in your other code must have been wrong – I doubt you’ll get this.

[Sara Damiano]

We haven’t figured out why we’ve had such a high failure rate with the LTE-M XBee3’s.  It’s pretty discouraging.

I know there was an upload issue with the outputs you tried to post.  (I think our wonderful webmaster is working to allow ino files to be posted.)  But from what you did post, if TinyGSM was able to tell you that the modem was a “u-blox SARA-R410M-02B” it can only have done that if it succeeded in asking the modem for its name.  That means your modem is definitely *not* completely broken and it must have an active bootloader even if XCTU can’t find it.

And what I said above about the assoc/rssi lights only applies if you’re running the XBee3 in “transparent” mode.  You’re running in “bypass.”  The assoc and RSSI lights do not work in bypass mode.  The assoc light will probably never start to blink even after you’re connected and the RSSI light will stay off.

[Author]

Posts