SCC1 RxM is dead. This is not due to idle. The EM7565 is the only modem where this issue occurs.
My guess is the modem tries to use a non-existant antenna, as the X16 is actually a 4x4 modem. B1+B3(+B7) is supported according to the specs. We are at least 5 people who are dealing with this issue.
Try to swap the main vs DIV antennas to see if the issue follows the antenna.
Also try a different location (home vs office) and switch to a different antenna.
Weird, could you try using the exact same channels? I have noticed all streams work when doing a handover from a different cell or WCDMA/UMTS until the modem enters idle mode again.
Another thing I figured out is that all streams work for the first two seconds when connecting to the cell, then one of them is dead:
Sorry for forgetting such a major detail. This issue has been present since the very first version that was pre-installed on the module (~ Dec, 2017). Currently I am on:
Do you also see the problem if you start from radio on/off mode? (instead of doing a handover)
At+cfun=0
At+cfun=1
Looks like you are having some issues with B3, maybe noise?
Is it always B3?
I’m wondering if you can replicate the issue without CA.
Try to lock the modem to B3 only and send some data, do you see signal degradation?
With RSRP being -123dBm on the main the modem will not even attach.
at!entercnd="A710"
OK
at!band?
Index, Name, GW Band Mask L Band Mask 1 TDS Band Mask L Band Mask 2 L Band Mask 3 L Band Mask 4
00, All bands 100600000EC00000 00002100BA0E19DF 0000000000000000 0000000000000002 0000000000000000 0000000000000000
OK
at!band=?
Index, Name, GW Band Mask L Band Mask 1 L Band Mask 2 TDS Band Mask L Band Mask 3 L Band Mask 4
00, All bands 100600000EC00000 00002100BA0E19DF 0000000000000002 0000000000000000 0000000000000000 0000000000000000
01, Europe 3G 0002000000400000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000
02, North America 3G 0000000004800000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000
06, Europe 0002000000400000 00000000000801C5 0000000000000000 0000000000000000 0000000000000000 0000000000000000
07, North America 0000000004800000 000001000200185A 0000000000000002 0000000000000000 0000000000000000 0000000000000000
08, WCDMA ALL 100600000EC00000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000
09, LTE ALL 0000000000000000 00002100BA0E19DF 0000000000000002 0000000000000000 0000000000000000 0000000000000000
0000000000000002 - B66
0000200000000000 - B46
0000010000000000 - B41
0000000080000000 - B32
0000000020000000 - B30
0000000010000000 - B29
0000000008000000 - B28
0000000002000000 - B26
0000000000080000 - B20
0000000000040000 - B19
0000000000020000 - B18
0000000000001000 - B13
0000000000000800 - B12
0000000000000100 - B9
0000000000000080 - B8
0000000000000040 - B7
0000000000000010 - B5
0000000000000008 - B4
0000000000000004 - B3
0000000000000002 - B2
0000000000000001 - B1
1000000000000000 - B19 (850)
0004000000000000 - B9 (1700)
0002000000000000 - B8 (900)
0000000008000000 - B6 (800)
0000000004000000 - B5 (850)
0000000002000000 - B4 (1700)
0000000000800000 - B2 (1900)
0000000000400000 - B1 (2100)
OK
//// first parameter is the index
//// 2nd - name
//// 3rd GW band mask - you should copy this from the output of at!band? because we are only changing the Lmask
//// L mask 000004 is B3
at!band=10,"LTE B3",100600000EC00000,4
OK
at!band=10
OK
BTW: There is a typo in AT!GSTATUS. SSC should be SCC.
I’m wondering if you can replicate the issue without CA.
Try to lock the modem to B3 only and send some data, do you see signal degradation?
With RSRP being -123dBm on the main the modem will not even attach.
Were you actually sending data when the modem was locked to B3?
You have mentioned that 5 of you are having the same problem in Austria , are you guys use the same platform?
Any of you have access to a Sierra EM7565 devkit?
Just want to rule out some possible platform noise issue.
Well the problem is not reproducible on the callbox.
We can’t rule out some NTWK issue.
I setup 2 Cells on the Amari eNB with the same EARFCN (1875,300) and bandwidth (15MHz)
The theoretical max with 2CA MIMO, 15Mhz, 256QAM is ~301Mbps
With iperf I was getting 285Mbps DL transfer ( IP header is not included)
Why would it be a network issue if the EM7565 is the only (known) device with such an issue? I have never seen this happening on my Huawei B618 or Galaxy S8 (Samsung SoC).
If it matters: They are using ZTE eNodeBs. I still think the modem tries to use a non-existant antenna.
I have a good news and a bad news…
The good news is that FW team fixed the bug. Your hunch was correct the issue was related to antenna switching.
This only affects CA 1+3, 2+4 and 2+66.
Unfortunately we are not planning to release a new EM7565 FW anytime soon. They next scheduled release is around June 2019.
Hey, thanks for the reply and taking the issue seriously.
June 2019 is a very late release for the new firmware. (8 Month !)
We’re struggeling with this issue since almost a year, it would be a pleasure to finally get our modules in a properly working state.
Is there a chance we can get our hands on a inofficial build maybe?
I agree. You can’t tell us you fixed the issue and not release a fixed firmware for the next 8 months. This is also security-wise a very bad decision. I mean, seriously, come on, you can’t be serious on this.
We are dealing with this problem since December, 17 and have been ignored for a very long time and now we should wait for another 8 months?
I would have to replace a lot of hardware just because you do not want to release an update.
Please think about it, and also do not forget, 1+3+8 is officially supported and affected as well.
The latest “Product technical specification” PDF also lists B1+B3 as officially supported. You really want to delay this update for another 8 months?
You updated the CA table in Oct. 2018 where you already knew B1+B3 doesn’t work properly…
Just update the firmware now, there is no reason to delay this further. People are paying customers for almost 2 years now, without a proper working device.
If it’s an easy fix, then a fast firmware release would be no problem I guess. If it’s harder to fix - so be it - but at least tell us.
Nope, they are ignoring us again. Great customer service. I thought they are finally taking our problems serious, but apparently not… Sad … That’s almost ZTE level customer service.
Time for another entry on my “Do Not Buy” list. I am done with this.
After reading this, I spit out my drink. Are you kidding me? I’m in the US and bought this modem SPECIFICALLY to be able to leverage 2+66 and yet I run into this issue constantly. What in the world would drive you to tell us that you found the fix and then tell us you’re going to sit on it for 8 months? This has to be a joke…
