openvehicles/Open-Vehicle-Monitoring-System

SMS Response

gluca opened this issue · 8 comments

gluca commented

Some OVMS users are experiencing strange responses to SMS configuration.
Last row of every SMS like MODULE, SERVER and GPRS is missing the last character and some AT command is appended instead.
For Instance. a MODULE SMS command would return

Module:
...
...
Notifications:SMAT+###### (with ##### replaced by some AT command string).
instead of
Notifications:SMS

It Sounds to me like a not properly null terminated string but I've been not able to recreate the problem. Users state it disappear after reflashing or moving GPRS/GSM switch (but I'm not sure about it).

dexterbg commented

I sometimes also had this, I felt it happens especially when GPRS
connectivity is bad or when sending SMS to the module while it's not
fully initialized. I also remember CIPSHUT in some SMS.

My guess was that somehow net_state_enter() could be called between
net_send_sms_start() and net_send_sms_finish() -- there's no system flag
for an ongoing SMS transfer (like net_msg_sendpending for ongoing MSG
transfer). Haven't checked this though, just an idea.

Regards,
Michael

Am 09.10.2014 um 19:51 schrieb Gianluca:

Some OVMS users are experiencing strange responses to SMS configuration.
Last row of every SMS like MODULE, SERVER and GPRS is missing the last
character and some AT command is appended instead.
For Instance. a MODULE SMS command would return

Module:
...
...
Notifications:SMAT+###### (with ##### replaced by some AT command string).
instead of
Notifications:SMS

It Sounds to me like a not properly null terminated string but I've
been not able to recreate the problem. Users state it disappear after
reflashing or moving GPRS/GSM switch (but I'm not sure about it).

—
Reply to this email directly or view it on GitHub
#135.

Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

markwj commented

I also remember CIPSHUT in some SMS.

I’ve seen this on the GPRS sms message, as the current code switches to state NET_STATE_DONETINIT immediately after sending the SMS, but before net_send_sms_finish() is called by the framework. I’ve been looking for a more elegant solution to this. It seems to be that setting up net_state_vint=(NET_GPRS_RETRIES-1) and transitioning to NET_STATE_NETINITP would delay the GPRS initialisation for 15 seconds, but would work around this particular issue.

there's no system flag for an ongoing SMS transfer (like net_msg_sendpending for ongoing MSG

For the more general case of the system flag for ongoing SMS transfer, I think it should be ok so long as the SMS messages are never sent partially. We should only be sending commands to her modem in the main poll loop, so as long as the SMS command is completely sent before doing that, it should be ok?

The above comments on GPRS SMS also apply to MODULE, VEHICLE, GSMLOCK, and SERVER - they all have the same logic in that they net_state_enter(NET_STATE_DONETINIT) before the net_send_sms_finish() is called.

Regards, Mark.

On 11 Oct, 2014, at 4:07 pm, Michael Balzer notifications@github.com wrote:

I sometimes also had this, I felt it happens especially when GPRS
connectivity is bad or when sending SMS to the module while it's not
fully initialized. I also remember CIPSHUT in some SMS.

My guess was that somehow net_state_enter() could be called between
net_send_sms_start() and net_send_sms_finish() -- there's no system flag
for an ongoing SMS transfer (like net_msg_sendpending for ongoing MSG
transfer). Haven't checked this though, just an idea.

Regards,
Michael

Am 09.10.2014 um 19:51 schrieb Gianluca:

Some OVMS users are experiencing strange responses to SMS configuration.
Last row of every SMS like MODULE, SERVER and GPRS is missing the last
character and some AT command is appended instead.
For Instance. a MODULE SMS command would return

Module:
...
...
Notifications:SMAT+###### (with ##### replaced by some AT command string).
instead of
Notifications:SMS

It Sounds to me like a not properly null terminated string but I've
been not able to recreate the problem. Users state it disappear after
reflashing or moving GPRS/GSM switch (but I'm not sure about it)

—
Reply to this email directly or view it on GitHub
#135.

Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
—
Reply to this email directly or view it on GitHub.

gluca commented

And how about delay or refuse sms while initializing?
Il 12/ott/2014 16:35 "Mark Webb-Johnson" notifications@github.com ha
scritto:

I also remember CIPSHUT in some SMS.

I’ve seen this on the GPRS sms message, as the current code switches to
state NET_STATE_DONETINIT immediately after sending the SMS, but before
net_send_sms_finish() is called by the framework. I’ve been looking for a
more elegant solution to this. It seems to be that setting up
net_state_vint=(NET_GPRS_RETRIES-1) and transitioning to NET_STATE_NETINITP
would delay the GPRS initialisation for 15 seconds, but would work around
this particular issue.

there's no system flag for an ongoing SMS transfer (like
net_msg_sendpending for ongoing MSG

For the more general case of the system flag for ongoing SMS transfer, I
think it should be ok so long as the SMS messages are never sent partially.
We should only be sending commands to her modem in the main poll loop, so
as long as the SMS command is completely sent before doing that, it should
be ok?

The above comments on GPRS SMS also apply to MODULE, VEHICLE, GSMLOCK, and
SERVER - they all have the same logic in that they
net_state_enter(NET_STATE_DONETINIT) before the net_send_sms_finish() is
called.

Regards, Mark.

On 11 Oct, 2014, at 4:07 pm, Michael Balzer notifications@github.com
wrote:

I sometimes also had this, I felt it happens especially when GPRS
connectivity is bad or when sending SMS to the module while it's not
fully initialized. I also remember CIPSHUT in some SMS.

My guess was that somehow net_state_enter() could be called between
net_send_sms_start() and net_send_sms_finish() -- there's no system flag
for an ongoing SMS transfer (like net_msg_sendpending for ongoing MSG
transfer). Haven't checked this though, just an idea.

Regards,
Michael

Am 09.10.2014 um 19:51 schrieb Gianluca:

Some OVMS users are experiencing strange responses to SMS
configuration.
Last row of every SMS like MODULE, SERVER and GPRS is missing the last
character and some AT command is appended instead.
For Instance. a MODULE SMS command would return

Module:
...
...
Notifications:SMAT+###### (with ##### replaced by some AT command
string).
instead of
Notifications:SMS

It Sounds to me like a not properly null terminated string but I've
been not able to recreate the problem. Users state it disappear after
reflashing or moving GPRS/GSM switch (but I'm not sure about it)

—
Reply to this email directly or view it on GitHub
<
https://github.com/openvehicles/Open-Vehicle-Monitoring-System/issues/135>.

Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#135 (comment)
.

gluca commented

My ovms box seems stuck on initializing.
It resets (both green and red light on)
It shows 6 green blinks once
then 4 blinks three times
Then resets again
This happens infinitely.
Sometimes it finish the init sequence but more often it doesn't (last time
it took 45 hours to properly init)
Do you think is a sim problem or what?
Il 12/ott/2014 16:35 "Mark Webb-Johnson" notifications@github.com ha
scritto:

I also remember CIPSHUT in some SMS.

I’ve seen this on the GPRS sms message, as the current code switches to
state NET_STATE_DONETINIT immediately after sending the SMS, but before
net_send_sms_finish() is called by the framework. I’ve been looking for a
more elegant solution to this. It seems to be that setting up
net_state_vint=(NET_GPRS_RETRIES-1) and transitioning to NET_STATE_NETINITP
would delay the GPRS initialisation for 15 seconds, but would work around
this particular issue.

there's no system flag for an ongoing SMS transfer (like
net_msg_sendpending for ongoing MSG

For the more general case of the system flag for ongoing SMS transfer, I
think it should be ok so long as the SMS messages are never sent partially.
We should only be sending commands to her modem in the main poll loop, so
as long as the SMS command is completely sent before doing that, it should
be ok?

The above comments on GPRS SMS also apply to MODULE, VEHICLE, GSMLOCK, and
SERVER - they all have the same logic in that they
net_state_enter(NET_STATE_DONETINIT) before the net_send_sms_finish() is
called.

Regards, Mark.

On 11 Oct, 2014, at 4:07 pm, Michael Balzer notifications@github.com
wrote:

I sometimes also had this, I felt it happens especially when GPRS
connectivity is bad or when sending SMS to the module while it's not
fully initialized. I also remember CIPSHUT in some SMS.

My guess was that somehow net_state_enter() could be called between
net_send_sms_start() and net_send_sms_finish() -- there's no system flag
for an ongoing SMS transfer (like net_msg_sendpending for ongoing MSG
transfer). Haven't checked this though, just an idea.

Regards,
Michael

Am 09.10.2014 um 19:51 schrieb Gianluca:

Some OVMS users are experiencing strange responses to SMS
configuration.
Last row of every SMS like MODULE, SERVER and GPRS is missing the last
character and some AT command is appended instead.
For Instance. a MODULE SMS command would return

Module:
...
...
Notifications:SMAT+###### (with ##### replaced by some AT command
string).
instead of
Notifications:SMS

It Sounds to me like a not properly null terminated string but I've
been not able to recreate the problem. Users state it disappear after
reflashing or moving GPRS/GSM switch (but I'm not sure about it)

—
Reply to this email directly or view it on GitHub
<
https://github.com/openvehicles/Open-Vehicle-Monitoring-System/issues/135>.

Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#135 (comment)
.

markwj commented

Try the steps here:

http://www.openvehicles.com/helpme

3 green blinks would be trying to make a GPRS call, but you should really check all the other steps first.

Regards, Mark.

On 13 Oct, 2014, at 1:21 am, Gianluca notifications@github.com wrote:

My ovms box seems stuck on initializing.
It resets (both green and red light on)
It shows 6 green blinks once
then 4 blinks three times
Then resets again
This happens infinitely.
Sometimes it finish the init sequence but more often it doesn't (last time
it took 45 hours to properly init)
Do you think is a sim problem or what?
Il 12/ott/2014 16:35 "Mark Webb-Johnson" notifications@github.com ha
scritto:

I also remember CIPSHUT in some SMS.

I’ve seen this on the GPRS sms message, as the current code switches to
state NET_STATE_DONETINIT immediately after sending the SMS, but before
net_send_sms_finish() is called by the framework. I’ve been looking for a
more elegant solution to this. It seems to be that setting up
net_state_vint=(NET_GPRS_RETRIES-1) and transitioning to NET_STATE_NETINITP
would delay the GPRS initialisation for 15 seconds, but would work around
this particular issue.

there's no system flag for an ongoing SMS transfer (like
net_msg_sendpending for ongoing MSG

For the more general case of the system flag for ongoing SMS transfer, I
think it should be ok so long as the SMS messages are never sent partially.
We should only be sending commands to her modem in the main poll loop, so
as long as the SMS command is completely sent before doing that, it should
be ok?

The above comments on GPRS SMS also apply to MODULE, VEHICLE, GSMLOCK, and
SERVER - they all have the same logic in that they
net_state_enter(NET_STATE_DONETINIT) before the net_send_sms_finish() is
called.

Regards, Mark.

On 11 Oct, 2014, at 4:07 pm, Michael Balzer notifications@githubcom
wrote:

I sometimes also had this, I felt it happens especially when GPRS
connectivity is bad or when sending SMS to the module while it's not
fully initialized. I also remember CIPSHUT in some SMS.

My guess was that somehow net_state_enter() could be called between
net_send_sms_start() and net_send_sms_finish() -- there's no system flag
for an ongoing SMS transfer (like net_msg_sendpending for ongoing MSG
transfer). Haven't checked this though, just an idea.

Regards,
Michael

Am 09.10.2014 um 19:51 schrieb Gianluca:

Some OVMS users are experiencing strange responses to SMS
configuration.
Last row of every SMS like MODULE, SERVER and GPRS is missing the last
character and some AT command is appended instead.
For Instance. a MODULE SMS command would return

Module:
...
...
Notifications:SMAT+###### (with ##### replaced by some AT command
string).
instead of
Notifications:SMS

It Sounds to me like a not properly null terminated string but I've
been not able to recreate the problem. Users state it disappear after
reflashing or moving GPRS/GSM switch (but I'm not sure about it)

—
Reply to this email directly or view it on GitHub
<
https://github.com/openvehicles/Open-Vehicle-Monitoring-System/issues/135>

Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#135 (comment)
.

—
Reply to this email directly or view it on GitHub.

gluca commented

Mark,
The box worked without problems for months. It hangs on GPRS call (green blinks 4 times, so I suppose modem passes apn check).
The problem arose after sever ip change. I suspect a connection problem with the new server but I cannot a check it. How can I monitor it?

Of course I double checked new server ip.

Another strange thing is that features and parameters panels are rarely populated (android app).
I'll try to sniff android app traffic to investigate on such issues.

Gianluca Magalotti dal mio iPad mini

Il giorno 13/ott/2014, alle ore 05:19, Mark Webb-Johnson notifications@github.com ha scritto:

Try the steps here:

http://www.openvehicles.com/helpme

3 green blinks would be trying to make a GPRS call, but you should really check all the other steps first.

Regards, Mark.

On 13 Oct, 2014, at 1:21 am, Gianluca notifications@github.com wrote:

My ovms box seems stuck on initializing.
It resets (both green and red light on)
It shows 6 green blinks once
then 4 blinks three times
Then resets again
This happens infinitely.
Sometimes it finish the init sequence but more often it doesn't (last time
it took 45 hours to properly init)
Do you think is a sim problem or what?
Il 12/ott/2014 16:35 "Mark Webb-Johnson" notifications@github.com ha
scritto:

I also remember CIPSHUT in some SMS.

I’ve seen this on the GPRS sms message, as the current code switches to
state NET_STATE_DONETINIT immediately after sending the SMS, but before
net_send_sms_finish() is called by the framework. I’ve been looking for a
more elegant solution to this. It seems to be that setting up
net_state_vint=(NET_GPRS_RETRIES-1) and transitioning to NET_STATE_NETINITP
would delay the GPRS initialisation for 15 seconds, but would work around
this particular issue.

there's no system flag for an ongoing SMS transfer (like
net_msg_sendpending for ongoing MSG

For the more general case of the system flag for ongoing SMS transfer, I
think it should be ok so long as the SMS messages are never sent partially.
We should only be sending commands to her modem in the main poll loop, so
as long as the SMS command is completely sent before doing that, it should
be ok?

The above comments on GPRS SMS also apply to MODULE, VEHICLE, GSMLOCK, and
SERVER - they all have the same logic in that they
net_state_enter(NET_STATE_DONETINIT) before the net_send_sms_finish() is
called.

Regards, Mark.

On 11 Oct, 2014, at 4:07 pm, Michael Balzer notifications@githubcom
wrote:

I sometimes also had this, I felt it happens especially when GPRS
connectivity is bad or when sending SMS to the module while it's not
fully initialized. I also remember CIPSHUT in some SMS.

My guess was that somehow net_state_enter() could be called between
net_send_sms_start() and net_send_sms_finish() -- there's no system flag
for an ongoing SMS transfer (like net_msg_sendpending for ongoing MSG
transfer). Haven't checked this though, just an idea.

Regards,
Michael

Am 09.10.2014 um 19:51 schrieb Gianluca:

Some OVMS users are experiencing strange responses to SMS
configuration.
Last row of every SMS like MODULE, SERVER and GPRS is missing the last
character and some AT command is appended instead.
For Instance. a MODULE SMS command would return

Module:
...
...
Notifications:SMAT+###### (with ##### replaced by some AT command
string).
instead of
Notifications:SMS

It Sounds to me like a not properly null terminated string but I've
been not able to recreate the problem. Users state it disappear after
reflashing or moving GPRS/GSM switch (but I'm not sure about it)

—
Reply to this email directly or view it on GitHub
<
https://github.com/openvehicles/Open-Vehicle-Monitoring-System/issues/135>

Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#135 (comment)
.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.=

markwj commented

If you can try the steps at:

http://www.openvehicles.com/helpme

that would be very helpful. They will rule out the most common of problems.

At the end of that page, there is a section with some SMS messages and a request to send their output to me. That allows me to check the server side as well, and logs we have here.

Regards, Mark.

On 13 Oct, 2014, at 1:09 pm, Gianluca notifications@github.com wrote:

Mark,
The box worked without problems for months. It hangs on GPRS call (green blinks 4 times, so I suppose modem passes apn check).
The problem arose after sever ip change. I suspect a connection problem with the new server but I cannot a check it. How can I monitor it?

Of course I double checked new server ip.

Another strange thing is that features and parameters panels are rarely populated (android app).
I'll try to sniff android app traffic to investigate on such issues.

Gianluca Magalotti dal mio iPad mini

Il giorno 13/ott/2014, alle ore 05:19, Mark Webb-Johnson notifications@github.com ha scritto:

Try the steps here:

http://www.openvehicles.com/helpme

3 green blinks would be trying to make a GPRS call, but you should really check all the other steps first.

Regards, Mark.

On 13 Oct, 2014, at 1:21 am, Gianluca notifications@github.com wrote:

My ovms box seems stuck on initializing.
It resets (both green and red light on)
It shows 6 green blinks once
then 4 blinks three times
Then resets again
This happens infinitely.
Sometimes it finish the init sequence but more often it doesn't (last time
it took 45 hours to properly init)
Do you think is a sim problem or what?
Il 12/ott/2014 16:35 "Mark Webb-Johnson" notifications@github.com ha
scritto:

I also remember CIPSHUT in some SMS.

I’ve seen this on the GPRS sms message, as the current code switches to
state NET_STATE_DONETINIT immediately after sending the SMS, but before
net_send_sms_finish() is called by the framework. I’ve been looking for a
more elegant solution to this. It seems to be that setting up
net_state_vint=(NET_GPRS_RETRIES-1) and transitioning to NET_STATE_NETINITP
would delay the GPRS initialisation for 15 seconds, but would work around
this particular issue.

there's no system flag for an ongoing SMS transfer (like
net_msg_sendpending for ongoing MSG

For the more general case of the system flag for ongoing SMS transfer, I
think it should be ok so long as the SMS messages are never sent partially.
We should only be sending commands to her modem in the main poll loop, so
as long as the SMS command is completely sent before doing that, it should
be ok?

The above comments on GPRS SMS also apply to MODULE, VEHICLE, GSMLOCK, and
SERVER - they all have the same logic in that they
net_state_enter(NET_STATE_DONETINIT) before the net_send_sms_finish() is
called.

Regards, Mark.

On 11 Oct, 2014, at 4:07 pm, Michael Balzer notifications@githubcom
wrote:

I sometimes also had this, I felt it happens especially when GPRS
connectivity is bad or when sending SMS to the module while it's not
fully initialized. I also remember CIPSHUT in some SMS.

My guess was that somehow net_state_enter() could be called between
net_send_sms_start() and net_send_sms_finish() -- there's no system flag
for an ongoing SMS transfer (like net_msg_sendpending for ongoing MSG
transfer). Haven't checked this though, just an idea.

Regards,
Michael

Am 09.10.2014 um 19:51 schrieb Gianluca:

Some OVMS users are experiencing strange responses to SMS
configuration.
Last row of every SMS like MODULE, SERVER and GPRS is missing the last
character and some AT command is appended instead.
For Instance. a MODULE SMS command would return

Module:
...
...
Notifications:SMAT+###### (with ##### replaced by some AT command
string).
instead of
Notifications:SMS

It Sounds to me like a not properly null terminated string but I've
been not able to recreate the problem. Users state it disappear after
reflashing or moving GPRS/GSM switch (but I'm not sure about it)

—
Reply to this email directly or view it on GitHub
<
https://github.com/openvehicles/Open-Vehicle-Monitoring-System/issues/135>

Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#135 (comment)
.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.=
—
Reply to this email directly or view it on GitHub.

markwj commented

Fix as discussed applied:

[master 9adb299] Issue: SMS Response #135
1 file changed, 20 insertions(+), 5 deletions(-)