1034418 - [Flame][NFC] NFC should not detect when phones are side by side

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Vendcom, defect)

Description

[Alison Shiue]

Gaia      a3a5322692578e0a577fb7fa08e32144b2b05ba3
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/0293597de41f
BuildID   20140612160201
Version   32.0a2

STR:
1. Enable NFC on both phones
2. Open browser(or image, contact... that can share) on both phones
3. Tap two phones multiple times (maybe 10~20 times)
4. Put two phones side by side

Expected result:
1. In step 3, NFC detect and shrinking UI show correctly
2. In step 4, two phones do not NFC detect 

Actual result:
1. In step 3, sometimes NFC detect(phone vibrate) but could not show shrinking UI due to NFC connect lost
2. In step 4, two phones would vibrate continuously

Comment 1

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

nominate to 2.1+ as this greatly influence the NFC usbility on Flame.

Comment 2

[Alison Shiue]

Attachment: Flame_NFC_detect_issue.mp4

Add a video about NFC connect lost problem

Comment 4

[Dimi Lee [:dimi]]

This issue is almost 100% reproducible after both devices reboot and use NFC p2p connection for first time. This issue also happened in old build (central-2014-0601) or old version of nfcd.

Following is the reproduce step:
1. Enable NFC on both device
2. Reboot both devices and make sure both devices should not enter screen off state (This is issue can't be reproduced if screen is off then on)
3. Open image in gallery on both devices.
4. Tap two devices together.

Expect result:
Both device show shrinking UI.

Actual Result:
One device may not shrink and the other device will keep shrinking for a while.
After this step if you tap two devices together nothing will happen. If manually enter screen off state and then resume to screen on, p2p sharing will work correctly.

Comment 5

[Dimi Lee [:dimi]]

Sorry I didn't notice that original bug description includes "Put two phones side by side and device will keep vibrating".
So this bug doesn't exactly describe the same thing as i commented in Comment 4.

I will remove duplicate and track it bug 1041470.

Comment 6

[Dietrich Ayala (:dietrich)]

This was requested to block long ago, can you please re-test and if the problem still is repdroducible?

Comment 7

[Alison Shiue]

Try on following KK builds on tinderbox

[master]
Gaia-Rev        3c898380b47f298cd3b7a0dacb3a6529e94322d4
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/4cdc4b9e5832
Build-ID        20140922184244
Version         35.0a1

[2.1]
Gaia-Rev        3742913e11f69e789dcb0aa0dedf2e5572da0129
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-aurora/rev/df42b05782aa
Build-ID        20140922185144
Version         34.0a2

the detect issue still occur, please refer: https://www.youtube.com/watch?v=S0EG6Rd6m1Y&feature=youtu.be

Comment 8

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

[Blocking Requested - why for this release]:
See comment 1

Comment 9

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

Wesly,

Mind to raise this to vendor?

Comment 10

[Wesly Huang (EPM)]

Yes Wesley, I've added this into my tracking list with T2M.

@Alison: since we have QCT CS release and some NFC fixes (though not totally work) in v184 SW internally, would you help check if this issue is still there? (I saw the last test was on Sep./22 and assume this is still based on v180 or older BSP) Thank you.

Comment 11

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

v184 still has this problem

Comment 12

[Wesly Huang (EPM)]

Thanks Yoshi, I will follow this with T2M. Also ni youlong here

@Youlong, need you team to have fix this in the coming KK build, thanks.

Comment 13

[youlong.jiang]

(In reply to Wesly Huang from comment #12)
> Thanks Yoshi, I will follow this with T2M. Also ni youlong here
> 
> @Youlong, need you team to have fix this in the coming KK build, thanks.

hi wesly -

we checked with NXP about this issue. and find the power of antenna is high. But on SW side, we have no idea to config register to modify antenna Q value, mainly consider the certification and protocol standard. then need to consider fixing this issue from HW side.

tks.

Comment 14

[Wesly Huang (EPM)]

If that's the case I would propose to waive this issue due to HW limitation.

Comment 15

[Ken Chang[:kenkai]]

I would say this isn't a blocker.
ni?Wesley.
Should we talk with T2M to know how to fix this problem in HW side(returning devices to them, rework,
or something else)?

Comment 16

[Wesly Huang (EPM)]

Hi Ken:

I've talked with T2M SW team and just confirmed again this is HW design issue, and no good SW mitigation/workaround per T2M + NXP's evaluation. So as suggested I will discuss with Alison and EPM Wesley about our next move. Keep ni on me.

Comment 17

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

I played with two Flames and the use case actually is not a usual one.
User can move two phones away a little bit then it comes back to normal state. 
As above, this one doesn't block.

Comment 18

[Wesly Huang (EPM)]

Thanks Wesley, per our discussion with Alison let's close this one considering it's Flame's HW design limitation, and less frequent use case.