IridiumSBD code problem with Arduino Mega2560
TomEldredge opened this issue · comments
I just connected my new Rockblock to an arduino Mega, and uploaded the example code SendReceive. I have the tx and Rx on 18 and 19, respectively, using 5 volts from Arduino (measured it with VOM), and sleep line either pin 10 or 5 volts steady. The code compiles, In the serial monitor I get “Waiting for Response OK” messages, then after about 9 or 10 messages (I think) I finally receive the message: ” <<NO modem Detected. Powering off RockBlOCK…!, SignalQuality failed:error 10"
I tried two different MEGA2560 boards with same results. This is about as simple as could be. Any ideas? I had this set up with full sky view and antenna facing the sky. Is there some way I can do a simple querry of the RockBlock to see if I can get any response?
As in my post above, there seems to be problems with the Arduino MEGA2560 board and this code. I have been talking with the support staff at RockBlock and they acknowledged that another user has had difficulty also. They are trying to recall the solution, and I have forwarded them the complete configuration I am using. They passed the problem to a technical guy, and hopefully he will be able to help. I can see the MEGA2560 transmitting, but we never get a response from RockBlock. We tested the RockBlock by interfacing to it with a usb cable and sending it AT commands using a serial terminal (TeraTerm). It responded correctly to those commands in that configuration. If anyone else has any ideas or experience like this, I’d appreciate receiving them, and so would RockBlock support, I’m sure.
These two posts have been placed at the end of the IridiumSBD code description. Could you fiddle with these questions? They are my present day puzzle box. I hope to make a presentation on Monday of this technology to my brother, and five of my sons who work together in a company I founded and they have developed. Thank you for fiddling with this stuff.
Hi Tom--
I suspect your problem is a simple one. You can't use SoftwareSerial on all the pins on the Mega. See http://arduino.cc/en/Reference/SoftwareSerial for details. Happily, the solution is an easy one. Change the RX pin to one that supports pin change interrupts.
Also (and this is just as important), make sure you haven't got your tx and rx lines mixed up. This is VERY easy to do, because the RockBLOCK people recently relabeled their devices so that TX means "TX from the RockBLOCK's point of view", i.e. should be hooked up to the RX line on the Arduino. Of course if you have an older RockBLOCK, it's just the opposite.
Mikal
Hi Mikal,
Thank you for the incredibly fast response. I'll look into your reference
links. We did switch Tx and Rx, and we tried other pin pairs, Arduino
Mega2560 pins 22 (Tx, and 23 Rx) as well as the dedicated tx2, rx2 pins 16
and 17. Again, thank you for the blazing response. I watched the talk
you gave in Dallas on your gift boxes. Inspiring for me a fiddler too.
Fiddling is what started our business (making CNC controls) for every kind
of machine you can imagine.
Thanks again,
Tom
On Thu, Jun 12, 2014 at 2:26 PM, Mikal Hart notifications@github.com
wrote:
Hi Tom--
I suspect your problem is a simple one. You can't use SoftwareSerial on
all the pins on the Mega. See
http://arduino.cc/en/Reference/SoftwareSerial for details. Happily, the
solution is an easy one. Change the RX pin to one that supports pin change
interrupts.Also (and this is just as important), make sure you haven't got your tx
and rx lines mixed up. This is VERY easy to do, because the RockBLOCK
people recently relabeled their devices so that TX means "TX from the
RockBLOCK's point of view", i.e. should be hooked up to the RX line on
the Arduino. Of course if you have an older RockBLOCK, it's just the
opposite.Mikal
—
Reply to this email directly or view it on GitHub
#2 (comment).
Tom Eldredge
Edge Solutions LLC
Rutex LLC
(573) 341 1528
(573) 368 7399
harmonyt@rollanet.org
tome77@gmail.com
Hi Mikal,
Thank you again for your help. I tried pins 14 and 15, both positions for
tx and rx. Failed. Tried 13 and 12...success!
Those pins are already in use in my application, so I will try others until
I find some that are available and work.
By the way, 14 and 15 are listed as ones that support change interrupts on
the link you sent me. They did not work for me.
Thank you SO much!
On Thu, Jun 12, 2014 at 2:26 PM, Mikal Hart notifications@github.com
wrote:
Hi Tom--
I suspect your problem is a simple one. You can't use SoftwareSerial on
all the pins on the Mega. See
http://arduino.cc/en/Reference/SoftwareSerial for details. Happily, the
solution is an easy one. Change the RX pin to one that supports pin change
interrupts.Also (and this is just as important), make sure you haven't got your tx
and rx lines mixed up. This is VERY easy to do, because the RockBLOCK
people recently relabeled their devices so that TX means "TX from the
RockBLOCK's point of view", i.e. should be hooked up to the RX line on
the Arduino. Of course if you have an older RockBLOCK, it's just the
opposite.Mikal
—
Reply to this email directly or view it on GitHub
#2 (comment).
Tom Eldredge
Edge Solutions LLC
Rutex LLC
(573) 341 1528
(573) 368 7399
harmonyt@rollanet.org
tome77@gmail.com
Hi Tom. Thanks for the kind words. Great news!
If I were porting this application to one of the Mega varieties, I would take advantage of the fact that these provide more than one /Hardware/ Serial port. The sample code for IridiumSBD assumes Uno, which only has one hardware port but needs to talk to /two/ Serial devices, the GPS module and the RockBLOCK.
On Mega I /think/ you could hook up the RockBLOCK to the second HW serial port and simply change one line of code:
SoftwareSerial nss(18, 19);
->
HardwareSerial &nss(Serial1);
Make sense?
Hi Mikal,
I need to use pins 14 and 15, or pins 16 and 17. Pins 18 and 19 are
already in use also.
So, I would I put the line: "HardwareSerial &nss(Serial2); " in place of
the "SoftwareSerial nss(18, 19); " code, I think. This would work for pins
16 and 17?
Thank you again. I'm an old man who never learned C. Only Paschal,
several versions of Basic, dbase II and QPRO4. I have young men do most of
my programming these days...but I still do a lot of the hardware.
Tom
On Thu, Jun 12, 2014 at 3:41 PM, Mikal Hart notifications@github.com
wrote:
Hi Tom. Thanks for the kind words. Great news!
If I were porting this application to one of the Mega varieties, I would
take advantage of the fact that these provide more than one /Hardware/
Serial port. The sample code for IridiumSBD assumes Uno, which only has one
hardware port but needs to talk to /two/ Serial devices, the GPS module and
the RockBLOCK.On Mega I /think/ you could hook up the RockBLOCK to the second HW serial
port and simply change one line of code:SoftwareSerial nss(18, 19);
->
HardwareSerial &nss(Serial1);Make sense?
—
Reply to this email directly or view it on GitHub
#2 (comment).
Tom Eldredge
Edge Solutions LLC
Rutex LLC
(573) 341 1528
(573) 368 7399
harmonyt@rollanet.org
tome77@gmail.com
Thank you again, Mikal,
I have it working on the hardware serial2, per your instructions! I am
humbled and amazed that you would take the time to help me.
Gratefully,
Tom
On Thu, Jun 12, 2014 at 3:53 PM, Tom Eldredge harmonyt@rollanet.org wrote:
Hi Mikal,
I need to use pins 14 and 15, or pins 16 and 17. Pins 18 and 19 are
already in use also.So, I would I put the line: "HardwareSerial &nss(Serial2); " in place of
the "SoftwareSerial nss(18, 19); " code, I think. This would work for pins
16 and 17?Thank you again. I'm an old man who never learned C. Only Paschal,
several versions of Basic, dbase II and QPRO4. I have young men do most of
my programming these days...but I still do a lot of the hardware.Tom
On Thu, Jun 12, 2014 at 3:41 PM, Mikal Hart notifications@github.com
wrote:Hi Tom. Thanks for the kind words. Great news!
If I were porting this application to one of the Mega varieties, I would
take advantage of the fact that these provide more than one /Hardware/
Serial port. The sample code for IridiumSBD assumes Uno, which only has one
hardware port but needs to talk to /two/ Serial devices, the GPS module and
the RockBLOCK.On Mega I /think/ you could hook up the RockBLOCK to the second HW serial
port and simply change one line of code:SoftwareSerial nss(18, 19);
->
HardwareSerial &nss(Serial1);Make sense?
—
Reply to this email directly or view it on GitHub
#2 (comment).Tom Eldredge
Edge Solutions LLC
Rutex LLC
(573) 341 1528
(573) 368 7399
harmonyt@rollanet.org
tome77@gmail.com
Tom Eldredge
Edge Solutions LLC
Rutex LLC
(573) 341 1528
(573) 368 7399
harmonyt@rollanet.org
tome77@gmail.com
Fiddlers gotta support each other. :)
Hi Mikal,
In June you helped me, (a fellow fiddler) get my design going with the
Global Beacon, Rockblock and GPS module, using the hardware serial command
that worked with the I/O pins that we had available. I was pulled off this
project for a while, but I did have satellite communication working with my
hardware setup and your code.
Now I am back on the project, and I have communication between my Mega2560
like processor and the Rockblock working, but I do not seem to be able to
transmit messages to the satellite. Nick Farnell, with Rockblock support
in England says I am not actually transmitting but I get a good signal
quality. He said I am not actually transmitting, as he sees no AT+SBDIX
command in the serial monitor code. Here is the serial monitor code. Does
not the Arduino "isbd.sendSBText(outBuffer);" command execute this AT+SBDIX
command? I added some serial scripts for debugging, but here is what my
serial monitor reports:
InternalBegin: success!
AT+CSQ
Waiting for response OK
<< AT+CSQ
+CSQ:5
OK
Setup Signal quality is 5
Starting loop
Beginning to listen for GPS traffic...
A GPS fix was found!
Beginning to talk to the RockBLOCK...
Calling internalBegin
Powering off RockBLOCK...!
Going to sleep mode for about an hour...
Starting loop
Beginning to listen for GPS traffic...
A GPS fix was found!
Beginning to talk to the RockBLOCK...
Calling internalBegin
Powering on RockBLOCK...!
AT
Waiting for response OK
<< AT
OK
ATE1
Waiting for response OK
<< ATE1
OK
AT&D0
Waiting for response OK
<< AT&D0
OK
AT&K0
Waiting for response OK
<< AT&K0
OK
InternalBegin: success!
Made contact with the RockBlock...
loading RockBlock buffer...
Transmitting message: 37.827682,-91.835983,220.00,0.1,0
internalSendReceive
AT+SBDWT=37.827682,-91.835983,220.00,0.1,0
Waiting for response OK
<< AT+SBDWT=37.827682,-91.835983,220.00,0.1,0
OK
AT+CSQ
Waiting for response OK
<< AT+CSQ
+CSQ:5
OK
AT-MSSTM
Waiting for response OK
<< AT-MSSTM
-MSSTM: a15518c6
I am wondering why I am not transmitting this GPS data to the satellite.
Any ideas?
Thanks,
Tom Eldredge
On Thu, Jun 12, 2014 at 4:29 PM, Tom Eldredge harmonyt@rollanet.org wrote:
Thank you again, Mikal,
I have it working on the hardware serial2, per your instructions! I am
humbled and amazed that you would take the time to help me.Gratefully,
Tom
On Thu, Jun 12, 2014 at 3:53 PM, Tom Eldredge harmonyt@rollanet.org
wrote:Hi Mikal,
I need to use pins 14 and 15, or pins 16 and 17. Pins 18 and 19 are
already in use also.So, I would I put the line: "HardwareSerial &nss(Serial2); " in place of
the "SoftwareSerial nss(18, 19); " code, I think. This would work for pins
16 and 17?Thank you again. I'm an old man who never learned C. Only Paschal,
several versions of Basic, dbase II and QPRO4. I have young men do most of
my programming these days...but I still do a lot of the hardware.Tom
On Thu, Jun 12, 2014 at 3:41 PM, Mikal Hart notifications@github.com
wrote:Hi Tom. Thanks for the kind words. Great news!
If I were porting this application to one of the Mega varieties, I would
take advantage of the fact that these provide more than one /Hardware/
Serial port. The sample code for IridiumSBD assumes Uno, which only has one
hardware port but needs to talk to /two/ Serial devices, the GPS module and
the RockBLOCK.On Mega I /think/ you could hook up the RockBLOCK to the second HW
serial port and simply change one line of code:SoftwareSerial nss(18, 19);
->
HardwareSerial &nss(Serial1);Make sense?
—
Reply to this email directly or view it on GitHub
#2 (comment)
.Tom Eldredge
Edge Solutions LLC
Rutex LLC
(573) 341 1528
(573) 368 7399
harmonyt@rollanet.org
tome77@gmail.comTom Eldredge
Edge Solutions LLC
Rutex LLC
(573) 341 1528
(573) 368 7399
harmonyt@rollanet.org
tome77@gmail.com
Tom Eldredge
Edge Solutions LLC
Rutex LLC
(573) 341 1528
(573) 368 7399
harmonyt@rollanet.org
tome77@gmail.com
Hi TomEldredge,
I had faced the same problem before. But I have fixed it by add following codes:
isbd.begin();
isbd.useMSSTMWorkaround(false); // add this line after isbd.begin()
You could refer to the docs about "Erratum Workarounds and other Tweaks" at http://arduiniana.org/libraries/iridiumsbd/
Thank you for the tip. I will try it in the morning!
Tom Eldredge
On Tue, Nov 25, 2014 at 6:47 PM, mountain8848 notifications@github.com
wrote:
Hi TomEldredge,
I had faced the same problem before. But I have fixed it by add following
codes:
isbd.begin();
isbd.useMSSTMWorkaround(false); // add this line after isbd.begin()You could refer to the docs about "Erratum Workarounds and other Tweaks"
at http://arduiniana.org/libraries/iridiumsbd/—
Reply to this email directly or view it on GitHub
#2 (comment).
Tom Eldredge
Edge Solutions LLC
Rutex LLC
(573) 341 1528
(573) 368 7399
harmonyt@rollanet.org
tome77@gmail.com
Hi Mikal, and mountain8848:
Thank you for the tip. Yesterday was a stressful day for me as I struggled
to find out what was going on here, because the code worked this summer.
Your tip worked! I have forwarded this info to Rockblock support.
Hopefully it will help someone else also.
Thank you again.
Tom Eldredge
On Tue, Nov 25, 2014 at 9:44 PM, Tom Eldredge harmonyt@rollanet.org wrote:
Thank you for the tip. I will try it in the morning!
Tom Eldredge
On Tue, Nov 25, 2014 at 6:47 PM, mountain8848 notifications@github.com
wrote:Hi TomEldredge,
I had faced the same problem before. But I have fixed it by add following
codes:
isbd.begin();
isbd.useMSSTMWorkaround(false); // add this line after isbd.begin()You could refer to the docs about "Erratum Workarounds and other Tweaks"
at http://arduiniana.org/libraries/iridiumsbd/—
Reply to this email directly or view it on GitHub
#2 (comment).Tom Eldredge
Edge Solutions LLC
Rutex LLC
(573) 341 1528
(573) 368 7399
harmonyt@rollanet.org
tome77@gmail.com
Tom Eldredge
Edge Solutions LLC
Rutex LLC
(573) 341 1528
(573) 368 7399
harmonyt@rollanet.org
tome77@gmail.com
Hi Mikal,
Thank you and mountain8848 for solving my problem. I was stuck without
your help. Rockblock support was not able to locate the problem. Is this
something that can have a better fix than a "workaround?" I hope so.
Is it sufficient to have this "isbd.useMSSTMWorkaround(false); code only
executed once in void setup? Does it need to be executed again in the void
loop()? I was able to get communications established, but now we are
having heavy wet snow, and heavy cloud cover, so I do not know if that is
why I only got communication one time through the program
(GlobalBeacon.ino) and then no more. I have my setup outside a window
covered with a plastic bag for testing. The GPS works inside my home, but
not the Rockblock.
Thank you again for contributing this great software to enable fiddlers
like me to access such powerful hardware. We Arduino users are spoiled.
Sincerely,
Tom
On Wed, Nov 26, 2014 at 9:12 AM, Tom Eldredge harmonyt@rollanet.org wrote:
Hi Mikal, and mountain8848:
Thank you for the tip. Yesterday was a stressful day for me as I
struggled to find out what was going on here, because the code worked this
summer.Your tip worked! I have forwarded this info to Rockblock support.
Hopefully it will help someone else also.Thank you again.
Tom Eldredge
On Tue, Nov 25, 2014 at 9:44 PM, Tom Eldredge harmonyt@rollanet.org
wrote:Thank you for the tip. I will try it in the morning!
Tom Eldredge
On Tue, Nov 25, 2014 at 6:47 PM, mountain8848 notifications@github.com
wrote:Hi TomEldredge,
I had faced the same problem before. But I have fixed it by add
following codes:
isbd.begin();
isbd.useMSSTMWorkaround(false); // add this line after isbd.begin()You could refer to the docs about "Erratum Workarounds and other Tweaks"
at http://arduiniana.org/libraries/iridiumsbd/—
Reply to this email directly or view it on GitHub
#2 (comment)
.Tom Eldredge
Edge Solutions LLC
Rutex LLC
(573) 341 1528
(573) 368 7399
harmonyt@rollanet.org
tome77@gmail.comTom Eldredge
Edge Solutions LLC
Rutex LLC
(573) 341 1528
(573) 368 7399
harmonyt@rollanet.org
tome77@gmail.com
Tom Eldredge
Edge Solutions LLC
Rutex LLC
(573) 341 1528
(573) 368 7399
harmonyt@rollanet.org
tome77@gmail.com
Another user (gizmoberg) has suggested a fix: see release 1.04.
@TomEldredge , if isbd is a global variable you should only have to call useMSSTMWorkaround once, i.e. in setup().
If you send the console log, that may be a more useful way of determining why you aren't getting messages through. M
Hi Mikal,
Per your suggestion in the email from Nov 26, I am sending the console
log. I seem to be able to get one transmission to the satellite through,
then I get an error, "No modem detected". You can see this in the console
log below. I also encluded the complete Arduino code that I use at the end
of the Console Log. Can you help me see why it only sends one transmission
to the satellite?
Console Log:
Calling internalBegin
Powering on RockBLOCK...!
AT
Waiting for response OK
<< AT
OK
ATE1
Waiting for response OK
<< ATE1
OK
AT&D0
Waiting for response OK
<< AT&D0
OK
AT&K0
Waiting for response OK
<< AT&K0
OK
InternalBegin: success!
AT+CSQ
Waiting for response OK
<< AT+CSQ
+CSQ:5
OK
Setup Signal quality is 5
Starting loop
Beginning to listen for GPS traffic...
A GPS fix was found!
Beginning to talk to the RockBLOCK...
Calling internalBegin
Powering off RockBLOCK...!
Going to sleep mode for about an hour...
Starting loop
Beginning to listen for GPS traffic...
A GPS fix was found!
Beginning to talk to the RockBLOCK...
Calling internalBegin
Powering on RockBLOCK...!
AT
Waiting for response OK
<< AT
OK
ATE1
Waiting for response OK
<< ATE1
OK
AT&D0
Waiting for response OK
<< AT&D0
OK
AT&K0
Waiting for response OK
<< AT&K0
OK
InternalBegin: success!
Made contact with the RockBlock...
loading RockBlock buffer...
Transmitting message: 37.827892,-91.835800,260.80,0.2,0
internalSendReceive
AT+SBDWT=37.827892,-91.835800,260.80,0.2,0
Waiting for response OK
<< AT+SBDWT=37.827892,-91.835800,260.80,0.2,0
OK
AT+CSQ
Waiting for response OK
<< AT+CSQ
+CSQ:5
OK
AT+SBDIX
Waiting for response OK
<< AT+SBDIX
+SBDIX: 0, 30, 0, 0, 0, 0
OK
SBDIX MO code: 0
SBDIX success!
Going to sleep mode for about an hour...
AT*F
Waiting for response OK
<< AT*F
OK
Powering off RockBLOCK...!
Starting loop
Beginning to listen for GPS traffic...
A GPS fix was found!
Beginning to talk to the RockBLOCK...
Calling internalBegin
Powering on RockBLOCK...!
AT
Waiting for response OK
<< AT
AT
Waiting for response OK
<< AT
AT
Waiting for response OK
<< AT
AT
Waiting for response OK
<< AT
AT
Waiting for response OK
<< AT
AT
Waiting for response OK
<< AT
AT
Waiting for response OK
<< AT
AT
Waiting for response OK
<< AT
No modem detected.
Powering off RockBLOCK...!
Going to sleep mode for about an hour...
Starting loop
Beginning to listen for GPS traffic...
A GPS fix was found!
Beginning to talk to the RockBLOCK...
Calling internalBegin
Powering on RockBLOCK...!
AT
Waiting for response OK
<< AT
AT
Waiting for response OK
<< AT
AT
Waiting for response OK
<< AT
AT
Waiting for response OK
<< AT
AT
Waiting for response OK
<< AT
AT
Waiting for response OK
<< AT
AT
Waiting for response OK
<< AT
AT
Waiting for response OK
<< AT
No modem detected.
Powering off RockBLOCK...!
Going to sleep mode for about an hour...
Starting loop
Beginning to listen for GPS traffic...
A GPS fix was found!
Beginning to talk to the RockBLOCK...
Calling internalBegin
Powering on RockBLOCK...!
AT
Waiting for response OK
<< AT
End of Console Log.
The Arduino code I am using is pretty much the code you provided, except
for a few notes and the use of hardware serial instead of software serial
for the Mega pins I had to use in this application. Code used:
//DRGlobalBeacon_ino
#include <IridiumSBD.h>
#include <SoftwareSerial.h>
#include <TinyGPS++.h> // NMEA parsing: http://arduiniana.org
#include <PString.h> // String buffer formatting: http://arduiniana.org
#define BEACON_INTERVAL 60 //360 //0 // Seconds between transmissions
#define CONSOLE_BAUD 115200
HardwareSerial &nss(Serial2);
HardwareSerial ss(Serial3);
IridiumSBD isbd(nss, 2); //was 10
TinyGPSPlus tinygps;
void setup()
{
// Start the serial ports
Serial.begin(CONSOLE_BAUD);
// Setup the RockBLOCK
isbd.attachConsole(Serial);
isbd.attachDiags(Serial);
int signalQuality =-1;
nss.begin(19200); //Set up Serial port for Rockblock
ss.begin(9600); //Set up Serial port for GPS
isbd.begin();
isbd.useMSSTMWorkaround(false); //add this line
isbd.setPowerProfile(1);
int err = isbd.getSignalQuality(signalQuality);
if (err != 0)
{
Serial.print("SignalQuality failed: error ");
Serial.println(err);
return;
}
Serial.print("Setup Signal quality is ");
Serial.println(signalQuality);
}
void loop()
{
bool fixFound = false;
unsigned long loopStartTime = millis();
// Step 1: Reset TinyGPS++ and begin listening to the GPS
Serial.println(" ");
Serial.println(" ");
Serial.println("Starting loop ");
Serial.println("Beginning to listen for GPS traffic...");
tinygps = TinyGPSPlus();
// Step 2: Look for GPS signal for up to 7 minutes
for (unsigned long now = millis(); !fixFound && millis() - now < 7UL *
60UL * 1000UL;)
if (ss.available()) // if (ssGPS.available())
{
tinygps.encode(ss.read()); // tinygps.encode(ssGPS.read());
fixFound = tinygps.location.isValid() && tinygps.date.isValid() &&
tinygps.time.isValid() && tinygps.altitude.isValid();
}
Serial.println(fixFound ? F("A GPS fix was found!") : F("No GPS fix was
found."));
// Step 3: Start talking to the RockBLOCK and power it up
Serial.println("Beginning to talk to the RockBLOCK...");
if (isbd.begin() == ISBD_SUCCESS) //If not successful, it will power off
the Rockblock
{
Serial.println("Made contact with the RockBlock...");
char outBuffer[60]; // Always try to keep message short
if (fixFound)
{
Serial.println("loading RockBlock buffer...");
sprintf(outBuffer, "%d%02d%02d%02d%02d%02d,",
tinygps.date.year(), tinygps.date.month(), tinygps.date.day(),
tinygps.time.hour(), tinygps.time.minute(), tinygps.time.second());
int len = strlen(outBuffer);
PString str(outBuffer, sizeof(outBuffer) - len);
str.print(tinygps.location.lat(), 6);
str.print(",");
str.print(tinygps.location.lng(), 6);
str.print(",");
str.print(tinygps.altitude.meters());
str.print(",");
str.print(tinygps.speed.knots(), 1);
str.print(",");
str.print(tinygps.course.value() / 100);
}
else
{
sprintf(outBuffer, "No GPS fix found!");
}
Serial.print("Transmitting message: ");
Serial.println(outBuffer);
isbd.sendSBDText(outBuffer);
}
// Sleep
Serial.println("Going to sleep mode for about an hour...");
isbd.sleep();
int elapsedSeconds = (int)((millis() - loopStartTime) / 1000);
while (elapsedSeconds++ < BEACON_INTERVAL)
delay(1000);
}
On Wed, Nov 26, 2014 at 8:03 PM, Mikal Hart notifications@github.com
wrote:
@TomEldredge https://github.com/TomEldredge , if isbd is a global
variable you should only have to call useMSSTMWorkaround once, i.e. in
setup().If you send the console log, that may be a more useful way of determining
why you aren't getting messages through. M—
Reply to this email directly or view it on GitHub
#2 (comment).
Tom Eldredge
Edge Solutions LLC
Rutex LLC
(573) 341 1528
(573) 368 7399
harmonyt@rollanet.org
tome77@gmail.com
The hangup of the modem while running the above code seems to be caused by holding the sleep input to the modem to +5 volts all the time. As soon as I connected it to pin 2 it allowed multiple transmissions without any interruptions. So, if you are running this code for GlobalBeacon.ino maybe you must connect the sleep pin so that the MEGA2560 can put the modem to sleep then wake it up. I will do some final verification of this tomorrow.
I think another followup to the problems I was having yesterday and reported to this forum is appropriate, since I have taken the precious time of others to look at this issue with me. Hopefully this will be helpful to someone. With the code in the GlobalBeacon.ino, I have found that I cannot pull the sleep input to the Rockblock modem high (to +5v) and run the code as it is. In my setup, keeping the sleep input pulled high allows one transmission to be sent to the satellite, then the modem is hung up and the configuration produces an error, "No modem detected" after the program tried to address the modem for another transmission. Maybe some part of the code could be changed to prevent this, but I am not familiar with the programming well enough yet.
Also, I noted that when the sleep input to the Rockblock is connected to output pin 2 of my Mega2560, the Rockblock tends to keep the output floating near +5v, or as my digital multimeter read, +4.2 volts when the Mega2560 was not telling the rockblock to wake up. So this was a confusing output which I would interpret as a high. When my digital multimeter was connected to monitor this output, the modem would also hang up, so, I think the rockblock was not being really put to sleep, and thus it hung up just like when I intentionally kept the sleep input held at +5v all the time. When the Mega2560 was telling the Rockblock to wake up, the voltage was a solid +5v. So, I inserted a 10k resistor between this Mega2560 output signal and ground, and now I can monitor the output with my digital multimeter and the modem will not hang up. The voltage monitored switches from 0 volts to +5v distinctly whether it is being awakened or put to sleep. I do not exactly know why this happens, but it does. I verified it this morning. So now I think I have a reliable configuration.
Another followup. Even after all of these tests, it seems my Rockblock still is hanging up after one successful transmission. I do not know what the issues are. It was working last night after I hooked up the sleep line to the Mega2560 rather than pulling it high to +5v all the time. I just tested it several times and after one successful transmission, it reported "No modem detected" on the next cycle of attempted transmission. I'm very puzzled.
I will try the brand new rockblock I just received from England. It will take me a while to hook it up in my box. I need to assemble the connector etc.
@TomEldredge, if you're still watching, try the new version 2.0 of the library. It turns out that the sleep() code was doing a full device shutdown, and you can only "wake" from that by removing power for several minutes to let the supercap dissipate.