Oh, so installing that rule also prevents Linux from trying to send a bunch of AT commands that would just end up in the cloud.
It’s actually one of the /dev/hid* or /dev/usb/hid* nodes that get used for programming. ttyACM0 is just used for the serial communication.
If you’re seeing debug messages from the Dash itself going to the cloud then that would be something in your sketch.
Hey Reuben,
the permissions thingy fixed the firmware upgrade problem; I successfully upgraded to 0.9.2
I will monitor the hang issue overnight and post back. thanks for the help.
Hey Guys,
I have been able to upgrade the FW to 0.9.2 but still have the same issues on two different dash devices. We are using only the device str8 out of the box with no custom sketch or code involved. I have been moving a SIM card between them for testing as I only have a single SIM activated for now; I don’t believe this could have this effect (is this a valid assumption?)). The behavior is as follows:
Bidirectional SMS worked for a short time over a few hours. Then i left the device idle for ~30 minutes and when I tried to send the device a message via REST API I get the below output from the device. It has been truncated below to save space but the messages repeated for several minutes before the “Cloud send failed! Retrying” message at which point the message came through. But… while it recovered on the receive side, I still cannot send SMS from the device to the cloud.
+EVENT:LOG,60,4,INFO,50,An error occurred while processing a modem command
+EVENT:LOG,25,5,DEBUG,14,Modem command:
+EVENT:LOG,44,5,DEBUG,33,AT+USOCO=0,“23.253.146.203”,9999
+EVENT:LOG,31,4,WARN,21,Modem command timeout
+EVENT:LOG,60,4,INFO,50,An error occurred while processing a modem command
+EVENT:LOG,25,5,DEBUG,14,Modem command:
+EVENT:LOG,44,5,DEBUG,33,AT+USOCO=0,“23.253.146.203”,9999
+EVENT:LOG,31,4,WARN,21,Modem command timeout
+EVENT:LOG,26,5,DEBUG,15,Socket failure!
+EVENT:LOG,43,4,WARN,33,Socket failure during socket open
+EVENT:LOG,25,5,DEBUG,14,Modem command:ed rm
+EVENT:LOG,22,5,DEBUG,11,AT+USOCL=0
+EVENT:LOG,31,4,WARN,21,Modem command timeout
+EVENT:LOG,60,4,INFO,50,An error occurred while processing a modem command
+EVENT:LOG,25,5,DEBUG,14,Modem command:
+EVENT:LOG,22,5,DEBUG,11,AT+USOCL=0
+EVENT:LOG,31,4,WARN,21,Modem command timeout
+EVENT:LOG,48,4,WARN,38,Failure sending data during cloud push
+EVENT:LOG,38,4,WARN,28,Cloud send failed! Retrying.
// msg finllay arrives from API
+EVENT:SMSRCVD,112,2016-08-11T16:19:14.5223963Z|command:SET_ATTENUATOR,attenuatorLevel:int,time:ISO 8601 date/time,signature:byte[]
Not sure what to do now… Are you guys still working on the FW for this issue or is 9.2 supposed to have fixed it?
Also, how can I verify what firmware is actually loaded on the device? The updater said it loaded but I see no way to verify
Rock - Sorry saw you’re using 0.9.2. The fix for this is in the current release candidate 0.9.4 of the firmware. Can you verify with that as well? Sorry you’ll have to load another set of firmware.
The firmware version can be checked by pressing the tiny M2 reset button while snooping the serial port (via USB or TTL). This will reset the system module and print the firmware version for you. On the Dash, the M2 reset is just a little bit below the antenna connector.
Hey Ryan,
I found 0.9.4 here: http://downloads.konekt.io/dash/system_firmware/dash_system_module_firmware_0.9.4.bin from this thread: Dash Modem Times Out and Won't Send Data After 1 Hour - #24 by HologramPat.
Is that the correct binary? If so, it does not work either. However the problem is now the reverse. We can send SMS to the cloud but we cannot send from the cloud (or API) to the device. Below is the output from the device. I used the M2 switch and verified the version only the device hung and would not complete booting (I waited 15 minutes). After I disconnected/reconnected and the device came up I could send to the cloud but not the reverse.
Output after using M2 switch:
$ cat < /dev/ttyACM0
+EVENT:LOG,37,5,DEBUG,26,Konekt Dash system init…
+EVENT:LOG,15,5,DEBUG,5,0.9.4
+EVENT:LOG,47,5,DEBUG,36,Beginning modem bootstrap process…
+EVENT:LOG,81,5,DEBUG,70,Bootstrapping (1/14): Init modem (can sometimes take several minutes).
+EVENT:LOG,25,5,DEBUG,14,Modem command:
+EVENT:LOG,16,5,DEBUG,6,AT&F0
+EVENT:LOG,31,4,WARN,21,Modem command timeout
+EVENT:LOG,25,5,DEBUG,14,Modem command:
+EVENT:LOG,16,5,DEBUG,6,AT&K4
+EVENT:LOG,31,4,WARN,21,Modem command timeout
+EVENT:LOG,25,5,DEBUG,14,Modem command:
+EVENT:LOG,16,5,DEBUG,6,AT&F0
+EVENT:LOG,31,4,WARN,21,Modem command timeout
+EVENT:LOG,25,5,DEBUG,14,Modem command:
+EVENT:LOG,22,5,DEBUG,11,AT+CFUN=16
+EVENT:LOG,31,4,WARN,21,Modem command timeout
+EVENT:LOG,76,4,INFO,66,Data connection deactivated by network, possibly due to inactivity�+EVENT:LOG,37,5,DEBUG,26,Konekt Dash system init…
+EVENT:LOG,15,5,DEBUG,5,0.9.4
+EVENT:LOG,47,5,DEBUG,36,Beginning modem bootstrap process…
+EVENT:LOG,81,5,DEBUG,70,Bootstrapping (1/14): Init modem (can sometimes take several minutes).
+EVENT:LOG,25,5,DEBUG,14,Modem command:
+EVENT:LOG,16,5,DEBUG,6,AT&K4
+EVENT:LOG,31,4,WARN,21,Modem command timeout
+EVENT:LOG,36,5,DEBUG,25,Modem self-tests complete
+EVENT:LOG,46,5,DEBUG,35,Bootstrapping (2/14): Config modem.
+EVENT:LOG,47,5,DEBUG,36,Bootstrapping (3/14): Init SIM card.
+EVENT:LOG,33,5,DEBUG,22,Modem event: SIM ready
+EVENT:LOG,23,5,DEBUG,12,IMSI loaded.
+EVENT:LOG,24,5,DEBUG,13,ICCID loaded:
+EVENT:LOG,30,5,DEBUG,19,8944501006151414358
+EVENT:LOG,23,5,DEBUG,12,IMEI loaded:
+EVENT:LOG,26,5,DEBUG,15,353162070596656
+EVENT:LOG,53,5,DEBUG,42,Bootstrapping (4/14): Init event handling.
+EVENT:LOG,57,5,DEBUG,46,Bootstrapping (5/14): Wait for carrier signal.
+EVENT:LOG,36,5,DEBUG,25,Modem event: signal found
+EVENT:LOG,57,5,DEBUG,46,Bootstrapping (6/14): Establish operator link.
+EVENT:LOG,40,5,DEBUG,29,Caller-listening modem event:
+EVENT:LOG,38,5,DEBUG,27,+COPS: 0,0,“AT&T”,2
OK
+EVENT:LOG,48,5,DEBUG,37,Bootstrapping (7/14): Config network.
+EVENT:LOG,40,5,DEBUG,29,Modem event: Other (ignored):
+EVENT:LOG,32,5,DEBUG,21,+UPSND: 0,8,0
OK
+EVENT:LOG,44,5,DEBUG,33,Bootstrapping (8/14): Config APN.
+EVENT:LOG,51,5,DEBUG,40,Bootstrapping (9/14): Config IP address.
+EVENT:LOG,51,5,DEBUG,40,Bootstrapping (10/14): Link up (1 of 2).
+EVENT:LOG,51,5,DEBUG,40,Bootstrapping (11/14): Link up (2 of 2).
+EVENT:LOG,102,4,CRIT,92,Modem instruction aborted mid-instruction. This most likely is a bug and should be reported.
+EVENT:LOG,60,4,INFO,50,An error occurred while processing a modem command
+EVENT:LOG,41,5,DEBUG,30,Modem event: PSD context event
+EVENT:LOG,25,5,DEBUG,14,Modem command:
+EVENT:LOG,24,5,DEBUG,13,AT+UPSDA=0,3
+EVENT:LOG,31,4,WARN,21,Modem command timeout
+EVENT:LOG,65,5,DEBUG,54,Delaying to prevent carrier frustration, please wait:
+EVENT:LOG,13,5,DEBUG,3,30s
+EVENT:LOG,65,5,DEBUG,54,Delaying to prevent carrier frustration, please wait:
+EVENT:LOG,13,5,DEBUG,3,20s
+EVENT:LOG,65,5,DEBUG,54,Delaying to prevent carrier frustration, please wait:
+EVENT:LOG,13,5,DEBUG,3,10s
+EVENT:LOG,81,5,DEBUG,70,Bootstrapping (1/14): Init modem (can sometimes take several minutes).
+EVENT:LOG,25,5,DEBUG,14,Modem command:
+EVENT:LOG,16,5,DEBUG,6,AT&K4
+EVENT:LOG,31,4,WARN,21,Modem command timeout
+EVENT:LOG,60,4,INFO,50,An error occurred while processing a modem command
+EVENT:LOG,98,4,CRIT,88,Insufficient buffer while processing modem events, oldest event(s) dropped to make space
+EVENT:LOG,25,5,DEBUG,14,Modem command:
+EVENT:LOG,16,5,DEBUG,6,AT&K4
+EVENT:LOG,31,4,WARN,21,Modem command timeout
+EVENT:LOG,60,4,INFO,50,An error occurred while processing a modem command
+EVENT:LOG,25,5,DEBUG,14,Modem command:
+EVENT:LOG,11,5,DEBUG,1,
+EVENT:LOG,31,4,WARN,21,Modem command timeout
+EVENT:LOG,46,5,DEBUG,35,Bootstrapping (2/14): Config modem.
+EVENT:LOG,47,5,DEBUG,36,Bootstrapping (3/14): Init SIM card.
+EVENT:LOG,23,5,DEBUG,12,IMSI loaded.
+EVENT:LOG,24,5,DEBUG,13,ICCID loaded:
+EVENT:LOG,30,5,DEBUG,19,8944501006151414358
+EVENT:LOG,23,5,DEBUG,12,IMEI loaded:
+EVENT:LOG,26,5,DEBUG,15,353162070596656
+EVENT:LOG,53,5,DEBUG,42,Bootstrapping (4/14): Init event handling.
+EVENT:LOG,57,5,DEBUG,46,Bootstrapping (5/14): Wait for carrier signal.
+EVENT:LOG,57,5,DEBUG,46,Bootstrapping (6/14): Establish operator link.
+EVENT:LOG,40,5,DEBUG,29,Caller-listening modem event:
+EVENT:LOG,22,5,DEBUG,11,+COPS: 0,0,
+EVENT:LOG,40,5,DEBUG,29,Caller-listening modem event:
+EVENT:LOG,38,5,DEBUG,27,+COPS: 0,0,“AT&T”,2
OK
+EVENT:LOG,48,5,DEBUG,37,Bootstrapping (7/14): Config network.
+EVENT:LOG,40,5,DEBUG,29,Modem event: Other (ignored):
+EVENT:LOG,32,5,DEBUG,21,+UPSND: 0,8,1
OK
+EVENT:LOG,44,5,DEBUG,33,Bootstrapping (8/14): Config APN.
+EVENT:LOG,60,4,INFO,50,An error occurred while processing a modem command
+EVENT:LOG,25,5,DEBUG,14,Modem command:
+EVENT:LOG,39,5,DEBUG,28,AT+UPSD=0,1,“apn.konekt.io”
+EVENT:LOG,31,4,WARN,21,Modem command timeout
+EVENT:LOG,60,4,INFO,50,An error occurred while processing a modem command
+EVENT:LOG,25,5,DEBUG,14,Modem command:
+EVENT:LOG,39,5,DEBUG,28,AT+UPSD=0,1,“apn.konekt.io”
+EVENT:LOG,31,4,WARN,21,Modem command timeout
+EVENT:LOG,60,4,INFO,50,An error occurred while processing a modem command
+EVENT:LOG,25,5,DEBUG,14,Modem command:
+EVENT:LOG,39,5,DEBUG,28,AT+UPSD=0,1,“apn.konekt.io”
+EVENT:LOG,31,4,WARN,21,Modem command timeout
+EVENT:LOG,60,4,INFO,50,An error occurred while processing a modem command
+EVENT:LOG,25,5,DEBUG,14,Modem command:
+EVENT:LOG,39,5,DEBUG,28,AT+UPSD=0,1,“apn.konekt.io”
+EVENT:LOG,31,4,WARN,21,Modem command timeout
+EVENT:LOG,60,4,INFO,50,An error occurred while processing a modem command
+EVENT:LOG,25,5,DEBUG,14,Modem command:
+EVENT:LOG,39,5,DEBUG,28,AT+UPSD=0,1,“apn.konekt.io”
+EVENT:LOG,31,4,WARN,21,Modem command timeout
+EVENT:LOG,65,5,DEBUG,54,Delaying to prevent carrier frustration, please wait:
+EVENT:LOG,13,5,DEBUG,3,60s
+EVENT:LOG,65,5,DEBUG,54,Delaying to prevent carrier frustration, please wait:
+EVENT:LOG,13,5,DEBUG,3,50s
+EVENT:LOG,65,5,DEBUG,54,Delaying to prevent carrier frustration, please wait:
+EVENT:LOG,13,5,DEBUG,3,40s
+EVENT:LOG,65,5,DEBUG,54,Delaying to prevent carrier frustration, please wait:
+EVENT:LOG,13,5,DEBUG,3,30s
+EVENT:LOG,65,5,DEBUG,54,Delaying to prevent carrier frustration, please wait:
+EVENT:LOG,13,5,DEBUG,3,20s
+EVENT:LOG,65,5,DEBUG,54,Delaying to prevent carrier frustration, please wait:
+EVENT:LOG,13,5,DEBUG,3,10s
+EVENT:LOG,81,5,DEBUG,70,Bootstrapping (1/14): Init modem (can sometimes take several minutes).
+EVENT:LOG,25,5,DEBUG,14,Modem command:
+EVENT:LOG,16,5,DEBUG,6,AT&K4
+EVENT:LOG,31,4,WARN,21,Modem command timeout
+EVENT:LOG,60,4,INFO,50,An error occurred while processing a modem command
+EVENT:LOG,98,4,CRIT,88,Insufficient buffer while processing modem events, oldest event(s) dropped to make space
+EVENT:LOG,25,5,DEBUG,14,Modem command:
+EVENT:LOG,16,5,DEBUG,6,AT&K4
+EVENT:LOG,31,4,WARN,21,Modem command timeout
+EVENT:LOG,60,4,INFO,50,An error occurred while processing a modem command
The devices are not currently usable.
What I need to know: are your developers activity working on this and what is the ETA for a fix. Are there older versions of firmware available and if so where are they? Maybe we can find one that works.
Hi @rscavetta,
Can you confirm how you are currently powering the Dash, and your jumper setting?
If you are encountering the issue you have described here, and if power cycling the device does not resolve the issue, this is most commonly caused by a power-related issue. The errors you’re seeing are indicating that the on-board baseband modem is not responding; since it is the component that consumes the most power out of all components on the Dash, insufficient power is the most common cause for the baseband modem to not respond to commands.
Version 0.9.4 of the system firmware includes additional in-field connection healing capabilities, baseband modem recovery functionality, and various bugfixes and feature improvements. One of the improvements concerning connection healing will reset or (if necessary) power-cycle the baseband modem after “Delaying to prevent carrier frustration” if the baseband modem does not respond to commands, in case of a low-power condition that has since been resolved (e.g. more power is suddenly available, battery has been recharged, etc.).
Your log printout indicates that, even after attempting to power cycle an unresponsive baseband modem, it remained unresponsive; additionally, while initially still responsive, the baseband modem began encountering errors coinciding with transmission and with bringing up the packet-switched data context (data service), just before becoming unresponsive. Usually we see this in cases of a power supply issue, as that moment in the boot-up process contains a lot of transmit activity.
Complete list of system firmware downloads is available here: https://hologram.io/docs/hardware/hologram-dash/downloads/firmware/
Best,
PFW
Hey Pat,
We have three physical devices. We use them in serial pass through mode and the power jumpers are correct and are just as shipped to us. They are powered via USB only. They are all acting the same way with FW 0.9.4.
I added a powered hub and it provides a constant 5.1 volts on the device and it seems to draw no more than 150ma when the activity light is flashing and idles at between 10 and 50ma.
The symptom does not change, it’s the same as the log I last posted. When it does works it works only in the device->cloud direction. i still cannot get a SMS to the device from the dashboard or the API. the old FW worked fine and only occasionally would hang when left idle for a while. Now it just doesn’t work at all in the API->device direction.
I’m willing to try any other suggestions you may have.
Rock - Our carrier network partner experienced an outage yesterday (Aug-11) that affected inbound device terminated SMS messages. This was resolved as of this morning, have you been able to successfully send an SMS from API->device today?
As for the timeout issue, we still have an engineer investigating this but suspect it may be related to hardware issues on some earlier Dash hardware units. If interested, we could ship you a replacement unit when we get our 1.1 versions in the next week or two to check.
Thanks Ryan,
I’m running some tests now an the device appears to be working bidirectionally just fine so far.
I won’t know about the timeout until overnight but will post back results.
Thanks!
Hey Ryan,
New Status on my issue:
Not working again. the day after the cellular outage (Aug-12), the devices were working perfectly and did so for 2 days or so. However, as of yesterday it’s back to the same behavior: i can send to the device from the API but SMS messages sent from the device to the cloud never get there nor are they passed on to my webhook.
Is the cellular company having an issue again?
I am running:
BTW: Do you guys have a page where we can see the real time status of the cell networks? That would be handy and might save us some time during problem times…
Regards,
Hi Rock - We’re not currently seeing any cellular network outages and do have a status page here: http://status.hologram.io/ that you can check if there are network issues going forward
Were you able to see whether the modem is indicating a successful send for the SMS messages from the device? Trying to understand where the dropoff is happening.
-Ryan
Hey Ryan,
Thanks for the status page… that will come in handy.
Well… the messages seem to say success but the msgs never show up.
All of the debug messages are being sent to my cloud AND passed on to my webhook. This cannot be correct behavior, no? Reuben mentioned earlier that that is a function of the sketch but we are using this right out-of-the box with NO sketch customization. Are we being billed for that DEBUG data?
Also, the devices get into a state that I cannot get out of… Below is the output of the device, it does look very different from what I was with earlier FW.
$ cat < /dev/ttyACM0
+EVENT:LOG,40,5,DEBUG,29,Caller-listening modem event:
+EVENT:LOG,18,5,DEBUG,8,+USOWR:
+EVENT:LOG,40,5,DEBUG,29,Caller-listening modem event:
+EVENT:LOG,31,5,DEBUG,20,+USOWR: 0,63
OK
+EVENT:LOG,42,5,DEBUG,31,Data successfully sent to cloud
+EVENT:LOG,38,5,DEBUG,27,Closing connection to cloud
+EVENT:LOG,42,5,DEBUG,31,Data sent to cloud successfully
+EVENT:LOG,52,5,DEBUG,41,Pushing cloud message attachment to cloud
+EVENT:LOG,48,5,DEBUG,37,Cloud socket buffered write succeeded
+EVENT:LOG,48,5,DEBUG,37,Cloud socket buffered write succeeded
+EVENT:LOG,48,5,DEBUG,37,Cloud socket buffered write succeeded
+EVENT:LOG,42,5,DEBU3 c+EVENT:LOG,52,5,DEBUG,41,Pushing cloud message attachment to cloud
+EVENT:LOG,42,5,DEBUG,31,Commit cloud message attachment
+EVENT:LOG,38,5,DEBUG,27,Opening connection to cloud
+EVENT:LOG,40,5,DEBUG,29,Caller-listening modem event:
+EVENT:LOG,18,5,DEBUG,8,+USOCR:
+EVENT:LOG,40,5,DEBUG,29,Caller-listening modem event:
+EVENT:LOG,28,5,DEBUG,17,+USOCR: 0
OK
+EVENT:LOG,31,5,DEBUG,20,Writing to socket…
+EVENT:LOG,40,5,DEBUG,29,Caller-listening modem event:
+EVENT:LOG,18,5,DEBUG,8,+USOWR:
+EVENT:LOG,40,5,DEBUG,29,Caller-listening modem event:
+EVENT:LOG,31,5,DEBUG,20,+USOWR: 0,98
OK
+EVENT:LOG,42,5,DEBUG,31,Data successfully sent to cloud
+EVENT:LOG,38,5,DEBUG,27,Closing connection to cloud
+EVENT:LOG,42,5,DEBUG,31,Data sent to cloud successfully
+EVENT:LOG,52,5,DEBUG,41,Pushing cloud message attachment to cloud
+EVENT:LOG,48,5,DEBUG,37,Cloud socket buffered write succeeded
+EVENT:LOG,48,5,DEBUG,37,Cloud socket buffered write succeeded
+EVENT:LOG,48,5,DEBUG,37,Cloud socket buffered write succeeded
+EVENT:LOG,42,5,DEBUGalf+EVENT:LOG,52,5,DEBUG,41,Pushing cloud message attachment to cloud
+EVENT:LOG,42,5,DEBUG,31,Commit cloud message attachment
+EVENT:LOG,38,5,DEBUG,27,Opening connection to cloud
+EVENT:LOG,40,5,DEBUG,29,Caller-listening modem event:
+EVENT:LOG,18,5,DEBUG,8,+USOCR:
+EVENT:LOG,40,5,DEBUG,29,Caller-listening modem event:
+EVENT:LOG,28,5,DEBUG,17,+USOCR: 0
OK
+EVENT:LOG,31,5,DEBUG,20,Writing to socket…
+EVENT:LOG,40,5,DEBUG,29,Caller-listening modem event:
+EVENT:LOG,32,5,DEBUG,21,+USOWR: 0,282
OK
+EVENT:LOG,42,5,DEBUG,31,Data successfully sent to cloud
+EVENT:LOG,38,5,DEBUG,27,Closing connection to cloud
+EVENT:LOG,42,5,DEBUG,31,Data sent to cloud successfully
+EVENT:LOG,52,5,DEBUG,41,Pushing cloud message attachment to cloud
+EVENT:LOG,48,5,DEBUG,37,Cloud socket buffered write succeeded
+EVENT:LOG,48,5,DEBUG,37,Cloud socket buffered write succeeded
+EVENT:LOG,48,5,DEBUG,37,Cloud socket buffered write succeeded
+EVENT:LOG,42,5,DEBUG1te+EVENT:LOG,52,5,DEBUG,41,Pushing cloud message attachment to cloud
+EVENT:LOG,42,5,DEBUG,31,Commit cloud message attachment
+EVENT:LOG,38,5,DEBUG,27,Opening connection to cloud
+EVENT:LOG,40,5,DEBUG,29,Caller-listening modem event:
+EVENT:LOG,19,5,DEBUG,9,+USOCR: 0
+EVENT:LOG,40,5,DEBUG,29,Caller-listening modem event:
+EVENT:LOG,28,5,DEBUG,17,+USOCR: 0
OK
+EVENT:LOG,31,5,DEBUG,20,Writing to socket…
+EVENT:LOG,40,5,DEBUG,29,Caller-listening modem event:
+EVENT:LOG,17,5,DEBUG,7,+USOWR:
+EVENT:LOG,40,5,DEBUG,29,Caller-listening modem event:
+EVENT:LOG,31,5,DEBUG,20,+USOWR: 0,98
OK
+EVENT:LOG,42,5,DEBUG,31,Data successfully sent to cloud
+EVENT:LOG,38,5,DEBUG,27,Closing connection to cloud
+EVENT:LOG,42,5,DEBUG,31,Data sent to cloud successfully
+EVENT:LOG,52,5,DEBUG,41,Pushing cloud message attachment to cloud
+EVENT:LOG,48,5,DEBUG,37,Cloud socket buffered write succeeded
+EVENT:LOG,48,5,DEBUG,37,Cloud socket buffered write succeeded
+EVENT:LOG,48,5,DEBUG,37,Cloud socket buffered write succeeded
+EVENT:LOG,42,5,DEBUGalf+EVENT:LOG,52,5,DEBUG,41,Pushing cloud message attachment to cloud
+EVENT:LOG,42,5,DEBUG,31,Commit cloud message attachment
+EVENT:LOG,38,5,DEBUG,27,Opening connection to cloud
+EVENT:LOG,40,5,DEBUG,29,Caller-listening modem event:
+EVENT:LOG,18,5,DEBUG,8,+USOCR:
+EVENT:LOG,40,5,DEBUG,29,Caller-listening modem event:
+EVENT:LOG,28,5,DEBUG,17,+USOCR: 0
OK
+EVENT:LOG,31,5,DEBUG,20,Writing to socket…
+EVENT:LOG,40,5,DEBUG,29,Caller-listening modem event:
+EVENT:LOG,31,5,DEBUG,20,+USOWR: 0,95
OK
+EVENT:LOG,42,5,DEBUG,31,Data successfully sent to cloud
+EVENT:LOG,38,5,DEBUG,27,Closing connection to cloud
+EVENT:LOG,42,5,DEBUG,31,Data sent to cloud successfully
+EVENT:LOG,52,5,DEBUG,41,Pushing cloud message attachment to cloud
+EVENT:LOG,48,5,DEBUG,37,Cloud socket buffered write succeeded
+EVENT:LOG,48,5,DEBUG,37,Cloud socket buffered write succeeded
+EVENT:LOG,48,5,DEBUG,37,Cloud socket buffered write succeeded
^C
This will continue seemingly forever…
[UPDATE]
I have now burned all 3 devices back to 0.9.2 but I am still getting a non-stop loop of the device sending nothing but debug messages to the cloud:
$ cat < /dev/ttyACM0
+EVENT:LOG,23,5,DEBUG,12,IMSI loaded.
+EVENT:LOG,37,5,DEBUG,26,Konekt Dash system init…
+EVENT:LOG,25,5,DEBUG,14,Version: 0.9.2
+EVENT:LOG,47,5,DEBUG,36,Beginning modem bootstrap process…=
+EVENT:LOG,81,5,DEBUG,70,Bootstrapping (1/14): Init modem (can sometimes take several minutes).
+EVENT:LOG,50,5,DEBUG,39,Retry delay before modem bootstrapping:
+EVENT:LOG,15,5,DEBUG,5,60000
+EVENT:LOG,50,5,DEBUG,39,Retry delay before modem bootstrapping:
+EVENT:LOG,15,5,DEBUG,5,50000
+EVENT:LOG,50,5,DEBUG,39,Retry delay before modem bootstrapping:
+EVENT:LOG,15,5,DEBUG,5,40000
+EVENT:LOG,50,5,DEBUG,39,Retry delay before modem bootstrapping:
+EVENT:LOG,15,5,DEBUG,5,30000
+EVENT:LOG,50,5,DEBUG,39,Retry delay before modem bootstrapping:
+EVENT:LOG,15,5,DEBUG,5,20000
+EVENT:LOG,50,5,DEBUG,39,Retry delay before modem bootstrapping:
+EVENT:LOG,15,5,DEBUG,5,10000
+EVENT:LOG,81,5,DEBUG,70,Bootstrapping (1/14): Init modem (can sometimes take several minutes).
+EVENT:LOG,36,5,DEBUG,25,Modem self-tests complete
+EVENT:LOG,46,5,DEBUG,35,Bootstrapping (2/14): Config modem.
+EVENT:LOG,47,5,DEBUG,36,Bootstrapping (3/14): Init SIM card.
+EVENT:LOG,23,5,DEBUG,12,IMSI loaded.
+EVENT:LOG,24,5,DEBUG,13,ICCID loaded:
+EVENT:LOG,30,5,DEBUG,19,8944501006151414358
+EVENT:LOG,23,5,DEBUG,12,IMEI loaded:
+EVENT:LOG,26,5,DEBUG,15,353162070597803
+EVENT:LOG,53,5,DEBUG,42,Bootstrapping (4/14): Init event handling.
+EVENT:LOG,57,5,DEBUG,46,Bootstrapping (5/14): Wait for carrier signal.
+EVENT:LOG,36,5,DEBUG,25,Modem event: signal found
+EVENT:LOG,57,5,DEBUG,46,Bootstrapping (6/14): Establish operator link.
+EVENT:LOG,48,5,DEBUG,37,Bootstrapping (7/14): Config network.
+EVENT:LOG,44,5,DEBUG,33,Bootstrapping (8/14): Config APN.
+EVENT:LOG,51,5,DEBUG,40,Bootstrapping (9/14): Config IP address.
+EVENT:LOG,51,5,DEBUG,40,Bootstrapping (10/14): Link up (1 of 2).
+EVENT:LOG,51,5,DEBUG,40,Bootstrapping (11/14): Link up (2 of 2).
+EVENT:LOG,61,5,DEBUG,50,Bootstrapping (12/14): Link verification (1 of 2).
+EVENT:LOG,61,5,DEBUG,50,Bootstrapping (13/14): Link verification (2 of 2).
+EVENT:LOG,67,5,DEBUG,56,Bootstrapping (14/14): Enter serial passthrough mode. OK
+++
+EVENT:LOG,38,5,DEBUG,27,Opening connection to cloud
+EVENT:LOG,42,5,DEBUG,31,Data successfully sent to cloud
+EVENT:LOG,38,5,DEBUG,27,Opening connection to cloud
+EVENT:LOG,42,5,DEBUG,31,Data successfully sent to cloud
+EVENT:LOG,38,5,DEBUG,27,Opening connection to cloud
+EVENT:LOG,42,5,DEBUG,31,Data successfully sent to cloud
+EVENT:LOG,38,5,DEBUG,27,Opening connection to cloud
+EVENT:LOG,42,5,DEBUG,31,Data successfully sent to cloud
+EVENT:LOG,38,5,DEBUG,27,Opening connection to cloud
+EVENT:LOG,42,5,DEBUG,31,Data successfully sent to cloud
+EVENT:LOG,38,5,DEBUG,27,Opening connection to cloud
+EVENT:LOG,42,5,DEBUG,31,Data successfully sent to cloud
+EVENT:LOG,38,5,DEBUG,27,Opening connection to cloud
^C
the udev rules file:
ATTRS{idVendor}==“7722”, ATTRS{idProduct}==“1200”, ENV{ID_MM_DEVICE_MANUAL_SCAN_ONLY}=“1”, ENV{ID_MM_CANDIDATE}=“0”, MODE=“0666”, ENV{ID_MM_DEVICE_IGNORE}="1"
SUBSYSTEM==“usb”, ATTRS{idVendor}==“7722”, ATTRS{idProduct}==“1200”, MODE="0666"
SUBSYSTEM==“usb”, ATTRS{idVendor}==“2cf3”, ATTRS{idProduct}==“1100”, MODE="0666"
ATTRS{idVendor}==“2cf3”, ATTRS{idProduct}==“4400”, ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}==“2cf3”, ATTRS{idProduct}==“4400”, ENV{MTP_NO_PROBE}="1"
SUBSYSTEMS==“usb”, ATTRS{idVendor}==“2cf3”, ATTRS{idProduct}==“4400”, MODE:="0666"
KERNEL==“ttyACM*”, ATTRS{idVendor}==“2cf3”, ATTRS{idProduct}==“4400”, MODE:=“0666”
Hey Ryan,
It looks like it’s the rules file that is causing the problem. I down-rev’d the FW to 0.9.2 and deleted the rules file that was recommended above as a permissions fix in this thread and the messages are flowing again in both directions.
I will now retest the hang scenario with 0.9.2 and if that fails I will try 0.9.4 WITHOUT the rules file.
Will post results…
Hey rock, are you just using the default user program sketch or is this something you wrote?
One thing that rules file does is prevents linux from invoking the modem manager which actually sends a bunch of stuff to the serial port and would cause the problem you’re seeing. The rules file should actually prevent that, but if you have a cloud write in a loop or something then it might lead to this problem as well.
Hey Reuben,
They are right out of the box with the exception of updating FW. serial pass thru mode, stock sketch… I think, we’ve never written one, is there a way form me to verify the stock sketch is loaded?
You can try reloading the sketch from here if you want: hologram-dash-arduino-examples/konekt_user_module_serial_gateway at master · HologramEducation/hologram-dash-arduino-examples · GitHub
Also, we did have a cloud interruption this morning that might have caused some weird behavior for you. It wasn’t recorded on the status page unfortunately as we fixed it as soon as it was discovered. We’ll do a better job of reporting that stuff in the future.
Hey Reuben,
I don’t understand the comment. what do you mean by “cloud write loop”?
From my perspective it seems that the rules file is actually causing the problem. I would think that the device should not send any info to the cloud unless I tell it to no?
Some Linux distributions try to send AT commands or something when a serial port pops up because they think it’s a modem. If you do that with the Dash, then all those messages get sent to the cloud.
The rules file is supposed to stop that from happening so it’s odd that getting rid of it fixes the problem. I’m just looking to see if something else could be going on there.
The cloud write loop thing is just if you’re running your own user sketch which it sounds like isn’t case here so nothing to worry about.