examples cause arduino mega r3 to loop unless #define DIAGNOSTICS true

[JimKruk]

this is very puzzling. I bought a Rockblock, arduino mega r3 and a level shifting board from Sparkfun. I am try to use the example code in the IridiumSBD libraries, BasicSend, SendReceive and all I get in the serial monitor window (set at 115200, CR/LF) is random garbage. If a change the #define DIAGNOSTICS from false to true everything runs ok and I see output in the serial window.

arduino library was downloaded from here: https://github.com/mikalhart/IridiumSBD
this is V2 that was released around November 2017

I added a delay line in SETUP and a few lines like this:
Serial.println(F("RockBlock Test")); in the start of setup and then this line just before the modem.begin
Serial.println("Starting modem...");
err = modem.begin();

it appears it is starting up but somehow just gets stuck inmodem.begin and cause the program to reset over and over and never reaches the LOOP function, but I have no idea why

in the console window I see the "rockblock test" is coming from setup then I see "Sta" and it repeats that sequence over and over.

I think "Sta" is part of this string in setup: Serial.println("Starting modem...");
It does not appear to ever get the the loop function and never reaches the last couple of lines in setup which prints out my menu in setup()

very strange....

I am using IDE 1.8.1 the Serial3 with no changes in the sample code. For power I am using the USB cable from the PC for the arduino mega and for the rockblock power pins a 5v wall adapter 2000 ma. Since everything works ok when I set #define DIAGNOSTICS to true I feel the wiring/level shifting is ok.

any thoughts/comments greatly appreciated !

[justinj0001]

I can confirm the same issue. Running IDE 1.8.5 with modem on Serial2.
With diagnostics set to false it seems to be resetting after a short amount of time or clock cycles as the higher the baud I set on for Serial0 the more text that gets output before the (WDT?) board is reset. I believe this is what is causing the 'garbage' in the console at lower baud rates (The board resetting before the byte is transmitted). I changed the sleep example very slightly and the lower that the serial baud is set, the less of the initial abcd.... text I get. At 1M baud I am getting millis() returning 0 or 1ms and it does not increase above this.

Copied from console output

ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
Starting modem...
ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
Starting modem...
ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
Starting modem...
ABCDEFGHIJKLMNOPQRSTUVWXYZ
0
Starting modem...
ABCDEFGHIJKLMNOPQRSTUVWXYZ
0
Starting modem...
ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
Starting modem...
ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
Starting modem...

Code:

#include <IridiumSBD.h>

/*
 * Sleep
 * 
 * This sketch demonstrates how to use the RockBLOCK Sleep pin.  The
 * general strategy is to call modem.begin() to start, then modem.sleep()
 * to stop.
 * 
 * Assumptions
 * 
 * The sketch assumes an Arduino Mega or other Arduino-like device with
 * multiple HardwareSerial ports.  It assumes the satellite modem is
 * connected to Serial3.  Change this as needed.  SoftwareSerial on an Uno
 * works fine as well.
 * 
 * This sketch also assumes that pin 4 is connected to Sleep
 */

#define IridiumSerial Serial2
#define SLEEP_PIN 7
#define DIAGNOSTICS false // Change this to see diagnostics

// Declare the IridiumSBD object (note SLEEP pin)
IridiumSBD modem(IridiumSerial, SLEEP_PIN);

void setup()
{ 
  // Start the console serial port
  Serial.begin(1000000);
  Serial.println("ABCDEFGHIJKLMNOPQRSTUVWXYZ");
  Serial.println(millis());
  while (!Serial);

  // Start the serial port connected to the satellite modem
  IridiumSerial.begin(19200);
}

void loop()
{
  // Begin satellite modem operation
  Serial.println("Starting modem...");
  int err = modem.begin();
  if (err != ISBD_SUCCESS)
  {
    Serial.print("Begin failed: error ");
    Serial.println(err);
    if (err == ISBD_NO_MODEM_DETECTED)
      Serial.println("No modem detected: check wiring.");
    return;
  }

  // Send the message
  Serial.print("Trying to send a message.  This might take several minutes.\r\n");
  err = modem.sendSBDText("Hello, world! (Sleep test)");
  if (err != ISBD_SUCCESS)
  {
    Serial.print("sendSBDText failed: error ");
    Serial.println(err);
    if (err == ISBD_SENDRECEIVE_TIMEOUT)
      Serial.println("Try again with a better view of the sky.");
  }

  else
  {
    Serial.println("Hey, it worked!");
  }

  // Put modem to sleep
  Serial.println("Putting modem to sleep.");
  err = modem.sleep();
  if (err != ISBD_SUCCESS)
  {
    Serial.print("sleep failed: error ");
    Serial.println(err);
  }

  // Demonstrate that device is asleep
  Serial.println("Trying to send while asleep.");
  err = modem.sendSBDText("This shouldn't work.");
  if (err == ISBD_IS_ASLEEP)
  {
    Serial.println("Couldn't send: device asleep.");
  }
  else
  {
    Serial.print("Send failed for some other reason: error ");
    Serial.println(err);
  }

  Serial.println("Sleeping for a minute.");
  delay(60 * 1000UL);
}

#if DIAGNOSTICS
void ISBDConsoleCallback(IridiumSBD *device, char c)
{
  Serial.write(c);
}

void ISBDDiagsCallback(IridiumSBD *device, char c)
{
  Serial.write(c);
}
#endif

[JimKruk]

Hi Justin
Thank you for the comments an interesting observations. What confuses me is in the examples folder all the programs are using serial3. From what I read when using the arduino mega 2560 R3 , only certain pins on that board support interrupts on RX, 10, 11, 12, 13, 14, 15 so I assume that is why the author choose Serial3

According to the doc
Serial3 uses 15 rx and 14 tx
Serial2 uses 17 rx and 16 tx

I will try some different baud rates and delay statements and see if that helps
Thanks

[justinj0001]

Hey msy380,
I don't believe serial2 instead of serial3 has anything to do with it. That could be an author preference seeing as how in the comments in the example it says to change or use software serial.

Assumptions
 * 
 * The sketch assumes an Arduino Mega or other Arduino-like device with
 * multiple HardwareSerial ports.  It assumes the satellite modem is
 * connected to Serial3.  Change this as needed.  SoftwareSerial on an Uno
 * works fine as well.

[AngeloACR]

Hi! I'm having exactly the same problem, but I'm using AltSoftSerial instead of SoftwareSerial, and using an Arduino Nano. Any idea on how to solve this?

[JimKruk]

I bought my rockblock from sparkfun and i’ve been working with them on this also. They were also to reproduce the problem using an Arduino mega 2560 where none of the examples run properly unless diagnostics are set to true. I also contacted rockblock and was told this is third-party software they are not responsible for it. Was really hoping the author Mikal would see the open issues and offer some advice.

…

On Wed, Mar 28, 2018 at 3:15 PM AngeloACR ***@***.***> wrote: Hi! I'm having exactly the same problem, but I'm using AltSoftSerial instead of SoftwareSerial. Any idea on how to solve this? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#12 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AjcN_XJ8I_m94GWJXdGeQHDoJLmxvqT6ks5ti-E4gaJpZM4Sh6sT> .

[justinj0001]

That's a shame @msy380. My understanding was RockSeven helped make this library in the first place so it's a shame they can't contribute to diagnostics and resolution. I haven't had the chance to look through the library to see what might be causing this. It's on my todo list, but so are a heap of other things right now.
Feel free to try and find the problem in the meantime 😄

[mikalhart]

Hi all--

I'll be looking at this in the next two weeks. Is the common thread here that everyone affected is using the Mega? @AngeloACR, are you using the Mega? If so, I was certainly suggest using one of the "hardware" serial ports in favor of the less reliable software serial implementations.

[justinj0001]

Using Mega and hardware serial here

[AngeloACR]

I'm using a Nano and and AltSoftSerial. Also tried with SoftwareSerial and didn't work neither @mikalhart

[mikalhart]

Hi friends--

I'm starting to maybe understand this. Most of the testing we do with IridiumSBD occurs on ARM processors, and I think there may be a difference between the way the ARM compilers handle undefined functions with the "weak" attribute and the Atmel core ones. Could I convince one or more of you to do the following experiment:

1. Keep DIAGNOSTICS defined as false.
2. Change the bit at the bottom of the sketches that involves diagnostics from:

#if DIAGNOSTICS
void ISBDConsoleCallback(IridiumSBD *device, char c)
{
  Serial.write(c);
}

void ISBDDiagsCallback(IridiumSBD *device, char c)
{
  Serial.write(c);
}
#endif

to

void ISBDConsoleCallback(IridiumSBD *device, char c)
{
#if DIAGNOSTICS
  Serial.write(c);
#endif
}

void ISBDDiagsCallback(IridiumSBD *device, char c)
{
#if DIAGNOSTICS
  Serial.write(c);
#endif
}

If my guess is right, this should fix the problem.

Full explanation:

These functions are defined as "weak" in the library to indicate that they should be called if and only if the user (or example writer) provides them in the sketch. On ARM systems, their absence simply causes nothing to happen, but I'm starting to guess that on Atmel core devices, the compiler actually generates a call to address 0, which would create the behavior you are reporting.

[justinj0001]

I don't have a modem around at the moment but will have a new batch coming soon. I'll test it then unless someone else can test before then.

[AngeloACR]

I have tested the proposed solution on an Uno without a Modem, and looks like it works well. I get the "No modem detected" message, and when in the loop, it throws "unexpected error 3". I'll test it in a few days with a Nano and an Iridium Edge to see if it works well with a Modem. Lets see what happen

[mikalhart]

Thank you @AngeloACR and @justinj0305. I am increasingly certain that this is the problem. The real solution will be a tiny bit of new code in the library to check whether those diagnostic functions have been provided by the user. That'll come soon once we get a bit more confirmation.

[JimKruk]

Hello, I had originally posted an issue here: https://github.com/ mikalhart/IridiumSBD/issues having the same problem. I am using an arduino mega 2560 R3 with the rockblock mk2, level shifter board, arduino IDE 1.8.1. I am trying to use the examples: https://github.com/mikalhart/IridiumSBD/tree/master/examples but see the same behavior where it just loops if diagnostics = false. All the examples use SERIAL3 so I assumed the code was using an arduino mega R3 since it is mentioned in the comments ? I also saw a post, I think by Mikal here: #2 that not all the rx/tx pins support interrupts so I was using the examples "as is" with serial3. Oddly if i change diagnostics = TRUE the code runs fine. Mikal, there are also a few open issues where the send routine is not clearing the buffer after sending a message so if you later try and receive a message it resends the old message. Rocklock advised to use AT+SBDD. Perhaps that fix could also be included an the revision to prevent the looping problem when DIAGNOSTICS = FALSE ? I am not a programmer so I am at the mercy of someone to try and fix the library/samples. Desperately trying to get this to work in the next few weeks. This project was to go aboard a sailboat headed off shore in early May. Any help would be greatly appreciated ! If there is a revision someone wants me to test I would be happy to do so. thank you

…

On Sun, Apr 1, 2018 at 10:57 AM, Mikal Hart ***@***.***> wrote: Thank you @AngeloACR <https://github.com/AngeloACR> and @justinj0305 <https://github.com/justinj0305>. I am increasingly certain that this is the problem. The real solution will be a tiny bit of new code in the library to check whether those diagnostic functions have been provided by the user. That'll come soon once we get a bit more confirmation. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#12 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AjcN_Z7gcNVwxhVTidf6b8JbEbsnfTaEks5tkOrOgaJpZM4Sh6sT> .

[JimKruk]

Hi Mikal
Thank you so much for commenting on this thread. I just re-read it and saw where you suggested a work around at the bottom of the sketch. I have a rockblock mk2, mega 2560 r3 and will test that fix and report back later today
Jim