users reported these problems since 1 1/2 years and what i can see here really helped a lot with their valuable and useful information.
please you just cannot simply sweep this problem under the carpet any longer…
can’t you just finally give us an inofficial fix for this issue, i want to use my module after all these months of waiting (for me it’s like driving my new car with a spare tire, staying in the garage since months…)
Hello tialk - We understand your frustration, our apologies for the delays in getting this release out. As we go through test, validation and certification tests with various carriers, module is subjected to various carrier compliance test cases and sometimes cases can fail and needs to get addressed, which in turn can require a firmware spin, re-submission & re-test, etc… Such cycles continues to play a part & can impact schedule for any given release. In addition, we are on various carriers globally with many products, so priority (with carriers/customers & labs) and market demand also plays a role in terms of release schedules and/or delays. For this reason, if any bug or issue is critically impacting your business, it is best to engage with your Sales/project support channels to bring that to visibility and priority.
Having said that, we are very close to the finish line with the firmware release in question & anticipate to publish a release within ~1 week. Look out for a “Generic - GCF Approved” Release 13 on our website. Thank you for your patience (long overdue, we know) & understanding.
Note: We will update this thread once release is posted.
On the other side of this discussion, please check this behavior with latest firmware (SWI9X50C_01.09.04.00).
After adding custom band with CA (B3&B7 - mask 0000000000000044) my at!gstatus command reported strange values of aggregated band names:
If I add additional 3rd band (B20) it shows as b19, but in this example B3 is as B2.
With previous firmware band names was correctly enumerated.
So anyway the modem works ok, but maybe is a little bug to fix?
I am pretty sure this issue is caused by an earlier attempt to hide the off-by-one bug I reported here:
This bug was finally fixed, according to the release notes:
CR 2170080 - QMI_NAS_GET_LTE_CPHY_CA_INFO returns incorrect band information
But, as I noted in the original bug report:, this issue did not show up in the AT command display, for unknown reasons. I believe we now see the reason: Someone reported this bug earlier and it was “fixed” by adding another bug hiding the issue in the AT command prosessor. That bug is hitting now that the root cause is gone.
This programming style is typical for projects without source code review. Many “programmers” think that fixing symptoms is easier than fixing the code, and no one will notice the difference because the code isn’t reviewed.
You’ll obviously not see many such problems in open source
So true … The whole firmware would need a rewrite from scratch. Almost every component has bugs. Tons of bugs.
Compiling in March and releasing in late June is also something I like. Other competitors release their firmwares within days or weeks after compilation. The certification process is just a cheap excuse.
I am wondering they haven’t locked this thread yet.
We have verified the reported discrepancy with AT!GSTATUS command. We have reviewed and verified a potential fix for this with the chipset vendor - resolution will be incorporated in the next Release 14. Schedule for which is TBD currently. Updates will be posted on our website.