So this isn’t a critical deficiency…? And you are still marketing this modem as B1+B3 capable…
If there are any further specific technical issues we can help with on this forum, please feel free to reach out.
Ha ha ha. Instead of telling us when we may expect the Firmware update you are telling us about certification. Like we wouldn’t know. You are of great help.
thank’s for your reply!
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.
FW Release is now available:
https://source.sierrawireless.com/resources/airprime/minicard/75xx/airprime-em_mc75xx-approved-fw-packages/
Please see : Generic SWI9X50C_01.09.04.00 002.019_000 Download Download GCF Approved—Release 13
Wow… finally. Now let’s hope everything works because I don’t want to wait another 1.5 years for the next FW release. SCNR.
thanks, going to try
Upgraded… I noticed when CA is active there isn’t a channel associated with it anymore, it states “no band”
B1+B3 works now, at least it looks like. Only time will tell.
The flash program is a mess. I always have to extract the archive and run the fdt command by hand or use qmicli.
RSSI -34 and RSRP -86 can’t be correct…
Not able to update firmware in Linux with latest Gobiserial and Gobinet drivers and SDK tools 
Anyone tried with qmi-firmware-update?
I have used a Windows VM. But I had to extract the .exe file and run the fdt command by hand. No idea why they don’t provide something that just works …
had to install the windows driver first, then the updater worked fine
Yup. Aleksander just published the required sahara+firehose support. It worked as expected for me. See [review] EM75xx firmware update using qmi-firmware-update
You still have to unzip the files 
it is the same for me:
AT!GSTATUS? displays “No Band” on the SSCx Bands.
… but i noticed it only when forcing the bands via AT!BAND=
when i set it to auto, sometimes it even displays a wrong band. (B2 when it isn’t even available)
Sierra’s quality assurance in a nutshell:
mv fw.bin /dev/null
Seriously, I have never seen such buggy firmwares before. There are bugs EVERYWHERE.
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:
!GSTATUS:
Current Time: 76898 Temperature: 40
Reset Counter: 1 Mode: ONLINE
System mode: LTE PS state: Attached
LTE band: B7 LTE bw: 15 MHz
LTE Rx chan: 3175 LTE Tx chan: 21175
LTE SSC1 state:ACTIVE LTE SSC1 band: B2
LTE SSC1 bw : 10 MHz LTE SSC1 chan: 1599
LTE SSC2 state:NOT ASSIGNED
LTE SSC3 state:NOT ASSIGNED
LTE SSC4 state:NOT ASSIGNED
EMM state: Registered Normal Service
RRC state: RRC Connected
IMS reg state: No Srv
While the bug might be easy to fix. The “certification” nonsense will lead to an update next year I guess. (if at all …)
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.