I am going to start working on a new project using Linux OS, I was thinking to buy the dragonboard 410c, but I have read in this forum that WIFI is intermittent and the GPS software doesn’t work.
how true is this?
The most common problem with the WiFi occurs when you ask the radio to do two things at once, for example to stay connected to one AP whilst scanning for others. The WiFi card cannot listen to both the channels at one so, during the frequency hop, it cannot listen to the AP and packets are delayed.
This is a challenge common to many WiFi cards but the reason it impacts the DB410C so heavily is the unusually long time the card is unresponsive during the scan (~80s). This problem can be mitigated by disabling background channel scanning (although this makes roaming difficult).
@danielt What about the packet loss under load conditions?
I’ve specifically modified the network-manager scan behavior and documented it in this post:
My next post after this shows that we still get packet loss, and even worse a predictable crash (watchdog bite?) that occurs when using iperf. The crash seems to be fixed in an upcoming kernel so that shouldn’t be an issue for long.
The thing about disabling background scanning is that it’s a band-aid at best, at worst it lulls you into a false sense that everything is working fine until it doesn’t. What you should be aware of is that disabling background scanning does not help fix the issues with packet loss. Packet loss is the real killer if you need to rely on this link to send data in a reliable fashion especially for large payloads like real time audio and video.
The thing about disabling background scanning is that it’s a band-aid at best
Don’t disagree with that. It only makes any sense if you don’t need to roam.
Yep, no disagreement here. While it makes the WCN3620 a bit more usable, it just isn’t reliable enough for large sustained data transfer.
When using wifi to send video via RTP/RTSP/RTMP frames are dropped in large numbers leading to the WCN3620 to stop responding all together.
Any inkling on this?
Thanks everyone for their input, it looks like a show stopper for me, because after 2 years or so the card doesn’t have a GPS software that works properly and also has problems with WIFI…
Regarding GPS I was originally under the impression that the on-board antenna wasn’t sufficient but that things should work OK with an external antenna. GPS is mentioned in the release notes and there’s nothing in the bug tracker about GPS. Having said that I do recall something on the forum recently (however since I don’t have an antenna I let it pass).
Daniel, the bug report I had for this talked about 10-15 seconds and as I implemented hardware-based (a year ago?) scanning I saw this dropping <1s. The only case I now can reproduce an issue similar to this is when I issue a BLE scan (which currently is configured to give WLAN 0% of the radio).
Can you describe the scenario where you see 80 seconds timeouts and provide some kernel logs when this happens?
Regards,
Bjorn
Sorry. Total brain failure on my part! I got the 8 right but some how got the exponent completely muddled. The total time unresponsive for me is in the order of 800ms during a scan.
Not quite sure what to say to redeem myself… I saw your reply, I confidently went to look up my previously shared results, and only then did I realize how completely out of whack I was here (2 orders of magnitude 
).
Er… sorry folks… I’ve no idea how I got that so wrong! I’ll go and hide in a cave until my pride (and intellect) recovers!
No worries Daniel,
The fact remains that we’re seeing about 30% packet loss (according to iperf), a WLAN scan takes us off the current channel for about 800ms, BT scans does reduce the throughput and BLE scan totally blocks out WLAN.
In addition to this I recently moved to a mesh network at home, which made the DB410c WLAN totally useless; it just keeps bouncing between the various APs. I have a fix for this now, but need some more work to complete the patch.
There are a number of knobs when it comes to configuring the time sharing of the RF module, so I’m hoping we can improve the situation as we’re now seeing the RF test support materialize.
Hi Bjorn,
Quick question about your incoming patch, will it remedy the issues with non p2p networks? Also can you share your information about tuning this driver? I’d be really interested in taking a look at the various knobs to see whether or not we can tune this module to work more reliably.
Also will disabling Bluetooth support cause the driver to work more reliably? I ask because it seems that there is some sort of time-sharing between the two since the device is a multi-role device that does both 2.4 GHz WIFI and BT 4.0.
Another passing thought, it seems that the WCN36XX driver has support for 5GHz WIFI, even though the WCN3620 only has support for 2.4GHz. Could this be causing us some pain if the driver tells the device to attempt to connect to a network it cannot support? Just an idea, by the way, I really have no evidence to support this other than seeing more issues when 5GHz networks exist in close proximity to the device but this could just be a coincidence.
