I’m trying to understand how SMS messages reach the Dash unit.
I took my Dash “out for a drive yesterday,” covering several hundred miles between the east and west coasts of Michigan. I have a phone number for my SIM card, so I was able to send SMS messages to the unit directly from my phone. By the time, I was a hundred or so miles from my starting location, the SMS messages were no longer being received by the unit. I stopped for a few hours, upon stopping I rebooted the Dash. Normal behavior resumed – SMS’s received by the Dash no problem.
The same thing happened on the return trip: after about 100 miles or so, SMS messages no longer made it to the Dash, and leaving the unit sit stationary overnight (powered on, without being rebooted) still didn’t allow the earlier or freshly sent SMS messages to catch up with it. Rebooting this morning allowed normal behavior to return.
My [highly uninformed] hypothesis is that the Dash is using an SMS-over-data method for communication, such that when it is on the move, normal SMS traffic has a hard time keeping up with it if the Dash has not been sending outgoing messages to allow the Hologram cloud to effectively know where it is, data wise, and send an outgoing message back to the device using the same data path the device used to send outgoing data to the Hologram cloud.
It was unexpected behavior, so I didn’t have an opportunity to mess with a REST API app to see if that would work better.
So what do you think? Is this normal behavior, or something else? Any thoughts or background as to how SMS messages may work inbound to the Dash unit are welcome.
Thanks for the detailed write-up. On the Dash, SMS receive uses the normal SMS path, not a simulated SMS over IP or anything like that. I’ve had another similar report under similar circumstances.
In your SMS received handler function, do you make any cloud send calls?
Are SMS messages you sent delayed until after reboot, or are they lost entirely?
How are you determining successful reception of SMS? Post to cloud, printout on Serial, etc?
Hopefully your answers can help narrow down the issue. Once I can design a suitable test, it’ll be road-trip time for me too!
Is your dash normally in sleep mode? The only way I could get mine to reliably receive SMS messages while out and about was to remove the sleep functions from my sketch. Works great now.
Not asleep. My main program loop has a delay(10000) at the end, so one loop ever 10 seconds. I understand the SMS handler triggers automatically every loop, so I’m effectively checking for SMS every 10 seconds and never sleeping.
Thanks for the feedback! I’m writing this message 200 miles from home in northern Michigan (Happy 4th, everybody!). The Dash made the trip with me. Wouldn’t you know it: It has worked flawlessly “on the move” – able to send (which it did in my original issue description, too) AND receive SMS message. I’m in a cabin with RSSI of 5 or 6 (i.e., weak but steady celllular signal), and the little guy just keeps on chugging!
So… To your questions:
My SMS handler does not make any Hologram Cloud send calls directly, but it DOES in turn call a process that analyzes the incoming SMS and acts on it. The handler also turns my normally green RGB blue, so I can see immediately when a message comes in.
I also have serial debug statements running in the loop – when the Dash stopped receiving SMS’s, I reconnected to my serial monitor to find the loop still running perfectly.
The SMS messages seem to be buffered in the great SMS Cloud in the Cellular Sky – after I’d sent it about 5 SMS’s that were not received, I rebooted the Dash 12 hours or so later, with the antenna disconnected, and loaded the passthrough sketch to manually check for SMS queued on the Dash. Nothing stored. Rebooted the Dash with antenna connected, waited, and same thing: The SMS’s from 12 hours ago had disappeared. “Fresh” SMS’s sent anew at that point were received normally.
Regarding incoming SMS confirmation, here’s how I know I’m getting / not getting them: My SMS handler turns my RGB LED blue (It’s normally green), then runs the SMS body agains a bunch of “if” tests; after which the LED is changed back to green. Flawless performance when stationary, and flawless performance on my current trip!
A fresh thought: I checked the Hologram System Status (thank you for putting this on your website!), and found that I was having issues about the same time(s) that things were getting a bit wonky on the Hologram sits. Perhaps coincidence… Literally as of today there is nothing to fix – but your thoughts are indeed welcome and appreciated!
I’m also seeing SMS messages sent to my Dash being lost. My project is loosely based on code from the hologram_dash_cloud sketch. Currently I’m awake for 3 minutes and sleeping for 12 minutes. The past two days everything works fine. I just tried to send an SMS to my device and I saw this in the log:
Never saw this before. The Hologram status page says everything is fine. I don’t mean to hijack Michael’s initial complaint. I f they’re not related let’s start a new thread.
So here’s what’s happening with my sketch based on the hologram_dash_cloud sketch. In the main loop I’ve got:
while(!Clock.alarmExpired()) { // Keep the modem awake while the Dash is sleeping to check for SMS
HologramCloud.pollEvents();
Dash.sleep(); // Dash will wakeup when an SMS message is received
tone(TESTPIN, 1000, 1000);
}
When I send an SMS message, I hear the beep, but the cloud_sms handler fails to run:
UPDATE: I have been able to reproduce my problem after driving back home from 200 miles away for the holiday.
The Dash is up and running perfectly. Now that I’m back home, I’ve connected back to my serial monitor, and I see that the loop is running normally. One of my Debugs on the loop as to see if there are any SMS messages queued. Reports zero. My hourly upload from the dash to the hologram cloud is functioning perfectly, so very solid data transmission, just in one direction.
I have also tried two other message paths: POST endpoint (which normally works perfectly), as well as direct SMS via the Hologram Dashboard (which also normally works perfectly). Neither of these shows a message received.
So, in summary, it seems that SMS messages sent to the Dash on the road, as well as here at home, are now not being received. I plan to give it 24 hours running to see if any kind of resets happen, or if the messages ever catch up to it.
Erik, let me know if there’s anything I should try before power cycling the device. Happy to keep it running through at least this time tomorrow night without rebooting to preserve the error state.
In the main loop(), the code above sits in the while loop until the alarm has expired. If an SMS message is received, the program exits the sleep() function. When I send an SMS to the Dash, I know the SMS is being received, because the tone function is executed. This while loop should trigger the cloud_sms handler when an SMS message comes in but for whatever reason it’s not going. Perhaps our problems are related and since you don’t execute the Dash.sleep() function, you can’t identify when an SMS message comes in?
UPDATE2: It’s been nearly 2 full days now since “loss of SMS to Dash” on this boot cycle. The Dash has been running now for 6 days, and loss of SMS occurred when the Dash was with me on the road for the 4th of July holiday.
Efforts to reach the Dash via Dashboard SMS and POST API also did not work.
My loop is running fine (serial monitor connected), and my hourly reports FROM the Dash to the Hologram Cloud (per my sketch) are working perfectly, so no issue with basic cellular connectivity. Current RSSI = 5, carrier is T-Mobile. I would note that 24 hours ago, I had RSSI = 8, and the carrier was AT&T. The Dash was not in motion / not moved when the carrier change occurred.
Hi Alan,
Thanks for the detailed explanation. I think you may have found a bug in the firmware. We’re going to try to reproduce here over the next couple days and patch if needed. Just checking, are you running the latest firmware and Arduino IDE version?
It’s good that they acknowledge a problem and are trying to address it.
There was an issue with SMS reception, but that has been resolved. The next firmware update will include changes to more gracefully handle SMS with non-numeric values in the sender field. If you are still having issues, please continue to report them.
I’m still looking into SMS reception during intermittent cell coverage to see if anything can be done to improve that.
Here’s a summary of my “Travels with Dash” and SMS’s to the device.
Dash is booted, running on battery power in addition to the USB, so I can easily transport it without rebooting.
I drove approximately 200 miles to northern Michigan, sending it occasional SMS messages. The messages are received without problem (I know this because the incoming messages trigger an outbound SMS verification).
Stayed for three days in a fairly remote location, with weak but steady cellular service. No problem with either outbound or inbound SMS’s.
About halfway on the drive home, the unit would no longer receive inbound SMS’s. Outbound SMS’s, which also occur in the sketch at a regular one hour interval, continue without problem or interruption.
Now home, I put the unit back home in its original location, and waited approximately 40 hours for the device and cellular network to possibly catch up with each other and return to normal operation (no reboot). No “self repair” of the inbound SMS ever occurred. Outbound messages continued without issue every hour. The Dash has now been running for six days without a reboot.
As this was the second occurrence of this behavior, I was extremely careful in verification and testing of the unit, and trying to narrow down what would finally bring it online. Here’s what I discovered: inbound SMS’s were not received, and endpoint requests and SMS messages sent from the dashboard were not received, either.
I then attempted, in order:
A). Reloading the sketch, without powering down the device. A reload of the same sketch worked fine, but the same aberrant SMS behavior continued. Again, tested the reception with endpoint and messages sent from the dashboard. No luck there, either.
B). Rebooting the Dash, via 20 second power cycle. The device came online normally, and sent its boot up SMS without issue. However, no incoming messages could be received, even after one hour.
C). Same attempt as above, a power cycle, but this time with a 5 minute power off. Same result as above.
D). Same attempt as above, a power cycle, but this time with a 20 minute power off. Same result as above.
E). Same attempt as above, a power cycle, but this time with a 45 minute power off. Same result as above.
F). Same attempt as above, power cycle, but this time with a 75 minute power off. This brought the operation of the Dash back to normal for both outgoing and incoming messages. Approximately 20 messages, sent over the previous 45 hours or so, had “disappeared" and were never seen / registered.
My view is, strictly from the behavior witnessed, is the problem is neither on the Dash unit nor the modem (reloading the sketch and powering off the unit rules that out, it seems). The issue rather seems to be a basic connectivity issue between the modem and the cellular network.
Any thoughts as to what’s happening here are welcome. This is by no means a showstopper, but I thought this would be something that you would want to be aware of as it’s likely to crop up in the future, particularly with people looking for on-demand GPS reports from a device on the move.
Wouldn’t you know it: It has worked flawlessly “on the move” – able to send (which it did in my original issue description, too) AND receive SMS message. I’m in a cabin with RSSI of 5 or 6 (i.e., weak but steady celllular signal), and the little guy just keeps on chugging!