AT+CCED bug?

[awneil]

AT+CCED=,

=1 and =11 should give an unsolicited +CSQ indication on every change in the signal level.

This works except for +CSQ: 99,99

eg, if you lose all GSM signal, you will never get a +CSQ: 99,99 to tell you that this has happened!

Is this the intended behaviour? If so, it should be documented!

R7.43.0.201003261552.FXT001 2139952 032610 15:52

[paruthiv]

Hi
I also tested this and saw the same beheviour.After giving AT+CCED=1,11 command i removed the antenna.Subsequently i got the following indications
+CSQ: 8,99
+CSQ: 7,99
+CSQ: 4,99
+CSQ: 2,99
But never did i receive +CSQ:99,99

Regards
Paruthiv

[awneil]

@paruthiv

But never did i receive +CSQ:99,99

Did you check that an explicit manual AT+CSQ query did actually respond with +CSQ:99,99

(removing the antenna is often not sufficient to kill the signal completely!)

[paruthiv]

Hi
Yes i checked,with manually providing AT+CSQ command and it responded with +CSQ:99,99

Regards
Paruthiv

[awneil]

AT+CCED=1,3 should give periodic unsolicited +CCED: responses containing the Main Cell dump, and Neighbours 1-6 dumps.

If the signal is poor - but not so poor that registration is lost (ie, still CREG 1 or 5) - the unsolicited +CCED: responses stop.
The unsolicited +CCED: responses resume when the signal improves.

Investigating further:

• a manual single-shot request AT+CCED=0,3 in this state gives +CME ERROR: 30
• a manual single-shot request AT+CCED=0,1 in this state gives a +CCED: responses containing the Main Cell dump
• a manual single-shot request AT+CCED=0,2 in this state gives +CME ERROR: 30

So it seems that the unsolicited responses from AT+CCED=1,3 stop when there is no neighbour cell info - even though the Main Cell info is still available.

+CME ERROR: 30 is “No network service”, which seems misleading/unhelpful in this case - since there clearly is Network service

Again, is this the intended behaviour
And, again, if it is - it should be clearly documented!

This was observed with Firmware version 6.63 - haven’t tried it yet with anything more modern…

[tobias]

The +CCED=0,2 ERROR issue was there in R7.42a as well.

We had reported it to Sierra Wireless in 2010, but I don’t know if it got fixed in later releases.

Issue triggered both in-the-field and in lab environment with a R&S CMU.

[awneil]

@tobias

We had reported it to Sierra Wireless in 2010, but I don’t know if it got fixed in later releases.

Maybe they don’t regard it as a “problem” and, therefore, not something that needs fixing

There is a certain logic to it - so it could actually be that Wavecom (it dates back to then) intenteded it that way. But, if that is the case, it is highly unintuitive and not something that one would realise from reading the documentation!

Therefore if this is, indeed, the intended operation then it needs to be very clearly and explicitly documented.

[Moderator1]

Hi ,

This is a known problem and a tracker already exists for the same.Will update you on this when the tracker is resolved. I know that it would be
helpful to you guys, if you could have track of the trackers. Since the
resolution of the trackers depends on various factors , Sierra would like
to keep it internal and inform the users when the tracker is used.

[awneil]

@Moderator

This is a known problem and a tracker already exists for the same.

There are actually two problems reported in this thread:

1. Missing unsolicited +CSQ:99,99 when signal is lost altogether;
2. Unavailable Neighbour info stops Main Cell info.

There is also the further issue of the unhelpful/misleading error code.

Is there also anything else on your “Tracker”

Will update you on this when the tracker is resolved.

Thanks.

I know that it would be helpful to you guys, if you could have track of the trackers

.
Yes, it certainly would!

Since the resolution of the trackers depends on various factors , Sierra would like
to keep it internal and inform the users when the tracker is used.

I can understand that you wouldn’t want to make everything completely public, but it would still be great to have at least some kind of visibility…

To be fair, it is great that you are now acknowledging these reports - thanks!

Is this issue mentioned on the Release Notes?

[esapperley]

Since the resolution of the trackers depends on various factors , Sierra would like to keep it internal and inform the users when the tracker is used.

To be perfectly frank, it would be much more “customer focussed” for Sierra Wireless to keep an open tracking list. The reason is that it would save developers much anguish and wasted time in trying to resolve issues that are known to Sierra Wireless engineers but not to developers in general.

The software quality gurus will tell you that there’s no such thing as complex functional software that’s “bug free”, so admitting that you have some defects to resolve in your products shouldn’t present an issue. Publishing the list would only become an issue if the bugs are never resolved, or are not perceived to be resolved in a timely fashion.

[awneil]

To be fair, there is a kind of “bug list” as part of the Release Notes - but I find it to be totally impenetrable!

Maybe it’s a starting point…

[esapperley]

Yes, that’s certainly true, but as you said earlier it doesn’t give one any visibility of issues until the new release happens.

Lets face it, there is a huge degree of frustration experienced when you “burn the midnight oil” on trying to resolve an issue only to find out later that its an issue in common with other developers or a known problem that’s under active consideration by the vendor.

[awneil]

@Moderator

This is a known problem and a tracker already exists for the same.

What “problem”, exactly?

• Are you just tracking a documentation issue (ie, the current operation is as you intended, but the documentation does not describe it adequately), or
• Are tracking a functional issue (ie, the current operation is incorrect)

Or, to put it another way, should we expect the behaviour to stay the same (because it is what you intended), or should we prepare for it to change to something more “intuitive”

[awneil]

@awneil

What “problem”, exactly?

In fact, there are three problems mentioned in this thread:

1. Missing +CSQ: 99,99 notification;
2. Inappropriate/misleading/unhelpful +CME ERROR: 30 result;
3. All +CCED: notifications stop when no neighbour info is available (even though the other info is available).

In each case, the question applies as to whether you consider these just documentation inadequacies, or functional deficiencies.

In addition, I think it would be useful if there were a specific +CCED: unsolited response to indicate that no information is available.

[Rex_alex]

@awneil

@awneil

What “problem”, exactly?

In fact, there are three problems mentioned in this thread:

1. Missing +CSQ: 99,99 notification;
2. Inappropriate/misleading/unhelpful +CME ERROR: 30 result;
3. All +CCED: notifications stop when no neighbour info is available (even though the other info is available).

All these problems will be addressed in the functional tracker which is already raised. As mentioned earlier, the information about the trackers disclosed in release notes is internal to Sierra.