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
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
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!)
Hi
Yes i checked,with manually providing AT+CSQ command and it responded with +CSQ:99,99
Regards
Paruthiv
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:
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…
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.
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.
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.
There are actually two problems reported in this thread:
There is also the further issue of the unhelpful/misleading error code.
Is there also anything else on your “Tracker”
Thanks.
.
Yes, it certainly would!
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?
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.
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…
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.
What “problem”, exactly?
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”
In fact, there are three problems mentioned in this thread:
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.
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.