WEBVTT 00:00:00.320 --> 00:00:08.000 It's not fair. I told you my Wi-Fi was 00:00:04.960 --> 00:00:11.200 fixed. It worked perfectly for a week. 00:00:08.000 --> 00:00:15.200 Then right after we uploaded this video, 00:00:11.200 --> 00:00:17.920 it made a big liar out of me. I hate it 00:00:15.200 --> 00:00:24.640 when that happens. Intermittent problems are the worst. 00:00:20.400 --> 00:00:28.160 Thankfully, now I have this. That's 00:00:24.640 --> 00:00:32.399 right, three cheap Wi-Fi adapters and a 00:00:28.160 --> 00:00:34.800 USB hub. Okay, admittedly it's not that 00:00:32.399 --> 00:00:39.360 impressive, but the software behind it is. Through the power of spectrum 00:00:36.960 --> 00:00:44.719 analysis and packet capture, we're going to be digging deeper than ever into what 00:00:42.079 --> 00:00:49.920 causes Wi-Fi to randomly lose performance or drop out. And even though 00:00:48.160 --> 00:00:54.960 it wasn't our intention, we're going to be exposing some of the BS marketing 00:00:52.320 --> 00:01:00.719 that Sony uses to sell their wireless home audio systems. BS marketing that I 00:00:58.640 --> 00:01:05.760 unknowingly spread when I did a sponsored video on the very product that 00:01:02.879 --> 00:01:11.200 has been causing me all this trouble. Just like I'm about to spread this segue 00:01:08.159 --> 00:01:12.799 to our sponsor, Build Redux. Build Redux 00:01:11.200 --> 00:01:16.400 takes the challenge and the hassle out of building your own PC with 00:01:14.560 --> 00:01:20.640 configuration options, support guides to aid you, and competitive pricing versus 00:01:18.400 --> 00:01:24.000 building a PC yourself. Why not kick your feet up and let BuildRredux handle 00:01:22.720 --> 00:01:29.880 it for you? Head to buildred redux.com/lininus 00:01:25.759 --> 00:01:29.880 and start your new build today. 00:01:36.960 --> 00:01:44.640 First up, I need to show you guys how I got bamboozled into thinking that I had 00:01:40.960 --> 00:01:46.640 the solution last time. Every Wi-Fi card 00:01:44.640 --> 00:01:51.439 is constantly looking for wireless networks. It can do this passively, just 00:01:49.759 --> 00:01:56.320 listening for different networks to announce their presence, or it can do it 00:01:54.079 --> 00:02:00.399 actively by sending out a probe request and then looking at the replies that 00:01:57.759 --> 00:02:04.880 come back. Surprisingly, the active method is actually a lot more power 00:02:02.799 --> 00:02:10.160 efficient. So, that's what most devices do by default. That means that when I 00:02:07.520 --> 00:02:15.520 was going around pointing my wispy antenna at anything and everything in 00:02:11.920 --> 00:02:17.760 the house, the Wi-Fi card in my laptop 00:02:15.520 --> 00:02:22.959 was happily probing away in the background, blasting out enough power 00:02:20.160 --> 00:02:27.760 that even my very high tech directional antenna was able to pick up the signal. 00:02:26.160 --> 00:02:32.959 The only thing that is hard to explain at this point is why sometimes it didn't 00:02:30.640 --> 00:02:36.480 seem to pick anything up, cuz that's what led us to believe that the source 00:02:34.720 --> 00:02:41.599 of the interference could be malfunctioning light switches. I mean, I 00:02:39.760 --> 00:02:47.040 should have dismissed this theory as quickly as I dismissed the 2.4 GHz 00:02:43.760 --> 00:02:49.440 microwave. Only a grossly malfunctioning 00:02:47.040 --> 00:02:54.400 900 MHz device should be capable of emitting any kind of 5 GHz interference. 00:02:52.080 --> 00:02:58.720 like so defective that it wouldn't even pass compliance testing. But in fairness 00:02:57.280 --> 00:03:02.400 to me with everything I've been through with these switches, nothing would 00:03:00.959 --> 00:03:07.360 surprise me at this point. That is correct. It's still my bad, though. I should have 00:03:05.519 --> 00:03:12.959 dug deeper. And a good place to start digging would be the hidden wireless 00:03:10.159 --> 00:03:20.159 SSID that we determined is associated with the base unit here of Sony's HTA9 00:03:16.800 --> 00:03:22.080 wireless audio system. Last time around, 00:03:20.159 --> 00:03:27.280 we took Sony at their word when they claimed that they were using wireless 00:03:24.319 --> 00:03:31.840 sound specification 4.0 to deliver wireless audio to the speakers 00:03:28.959 --> 00:03:38.000 distributed around my family room. But looking back on it, if both the freebie 00:03:34.560 --> 00:03:40.879 Wi-Fi analyzer on my phone and the paid 00:03:38.000 --> 00:03:47.760 channeler software on my laptop saw a hidden Wi-Fi network, then maybe 00:03:44.560 --> 00:03:51.360 wireless audio specification 4.0 0 is 00:03:47.760 --> 00:03:53.840 just Wi-Fi. To check our theory, we'll 00:03:51.360 --> 00:03:57.920 be using MetaGeek's channelizer again with the Wisey adapter, and we'll be 00:03:55.920 --> 00:04:03.519 looking for that familiar shape that we know is the Sony base unit. It looks 00:04:00.640 --> 00:04:07.840 like it's around channels 44 and 48 today, although that does tend to vary 00:04:05.680 --> 00:04:11.439 from day to day, which is part of the reason for my problems. We can see 00:04:10.000 --> 00:04:16.400 though there's a hardware address associated with this. So, let's remember 00:04:13.920 --> 00:04:22.320 that as we peel back the next layer of this problematic onion with a new piece 00:04:18.479 --> 00:04:25.360 of software from MetGeek called Tonic. 00:04:22.320 --> 00:04:27.840 Wait, that's Wire Shark. Tonic. Tonic 00:04:25.360 --> 00:04:33.840 works by capturing spectrum information also from the Wise Spy, but at the same 00:04:30.800 --> 00:04:35.919 time by capturing all of the wireless 00:04:33.840 --> 00:04:41.040 network traffic that is bouncing around in the house using off-the-shelf USB 00:04:38.560 --> 00:04:46.160 Wi-Fi adapters. Following Metaggeek's recommendation, we went with three of 00:04:43.199 --> 00:04:52.320 these Eddax EW7833 UAC units that retail for about $50 00:04:49.199 --> 00:04:54.960 each. Each of these has three antennas 00:04:52.320 --> 00:04:58.560 and supports 3x3 spatial streams, which means that they're able to take 00:04:56.400 --> 00:05:02.639 advantage of multipath transmission to significantly improve throughput. And 00:05:01.040 --> 00:05:06.560 more importantly, it means that it's extremely unlikely that they're going to 00:05:04.479 --> 00:05:10.639 miss anything when we start capturing traffic. Just for transparency, we're 00:05:09.280 --> 00:05:16.160 probably going to do a little bit of movie magic here and show you guys a 00:05:12.400 --> 00:05:18.560 mixture of live and pre-captured data. 00:05:16.160 --> 00:05:22.560 We got a ton of audio dropouts and other artifacts when we were testing this out 00:05:20.000 --> 00:05:26.160 a few days ago. But I think it's a law of the universe that the second the 00:05:24.320 --> 00:05:30.320 camera starts rolling, your product demonstration will fail. All right, the 00:05:29.039 --> 00:05:35.440 first thing that we're going to do then is limit our view to the 5 GHz spectrum, 00:05:33.600 --> 00:05:39.840 then we're going to click on show hidden. And sure enough, there's a 00:05:38.160 --> 00:05:45.360 hidden network with the Mac Address that we noticed in Channeler. That is our 00:05:42.479 --> 00:05:50.880 base unit that I hid on top of the other base unit. Get it? Haha, that's a 00:05:47.919 --> 00:05:55.919 subwoofer. Sorry. Anywh who, when we click on that network, we get a list of 00:05:52.639 --> 00:05:57.520 access points, which is just one because 00:05:55.919 --> 00:06:04.000 even though I did gesture to one of my Ruckus APs, they are not the problem. It 00:06:00.320 --> 00:06:06.319 is entirely this. It's on channel 44 and 00:06:04.000 --> 00:06:11.520 it has five clients, which makes sense because we've got four wireless speakers 00:06:09.280 --> 00:06:15.440 around the room and then also the subwoofer. When we click on the access 00:06:13.600 --> 00:06:19.440 point, we get some more detail about it and we get some graphs and charts that 00:06:17.759 --> 00:06:23.840 summarize the traffic that's being transmitted by it. If it can show us all 00:06:21.440 --> 00:06:28.000 this information about the AP's radio, that means according to our contact at 00:06:25.520 --> 00:06:32.800 Metgeek, there is pretty much no doubt that Sony's wireless sound 00:06:30.240 --> 00:06:37.120 specification, it's just a typical Wi-Fi 4 network rather than some special 00:06:34.720 --> 00:06:41.360 technology they've invented. Though, I mean, that does kind of make sense since 00:06:39.120 --> 00:06:47.600 getting some new wireless technology certified for 5 GHz globally would be a 00:06:44.800 --> 00:06:51.520 monumental task. But then from my point of view, they should just say it's 00:06:49.919 --> 00:06:55.440 Wi-Fi. That would have made troubleshooting this a lot easier from 00:06:53.600 --> 00:06:59.840 the start. Looking at the airtime distribution now, it's interesting that 00:06:57.440 --> 00:07:05.919 basically all the traffic sent out by this base unit is broadcast rather than 00:07:03.360 --> 00:07:11.120 being sent to a particular client. What that means then is that this base unit 00:07:08.240 --> 00:07:15.599 is just blasting Wi-Fi signals out into the air for any device that's listening 00:07:13.360 --> 00:07:20.240 without any regard for whether the signal actually gets to all of the 00:07:17.680 --> 00:07:24.479 speakers or some of the speakers or the speakers and something else. And then 00:07:22.319 --> 00:07:29.360 it's just up to each speaker to take that data and sort it out into which 00:07:27.120 --> 00:07:34.400 channel it's supposed to play. I suppose every speaker just gets all the data for 00:07:31.520 --> 00:07:40.479 every channel, which might explain some of why they are not able to make 00:07:37.120 --> 00:07:41.759 efficient use of the spectrum. I mean, I 00:07:40.479 --> 00:07:45.280 can kind of see why they took this approach since they need to keep latency 00:07:43.599 --> 00:07:54.520 low enough to keep audio sync to the picture, but clearly it's not working. A 00:07:48.960 --> 00:07:54.520 little weird, but not super weird yet. 00:07:54.560 --> 00:08:02.000 When we switch over to the client list here, we're going to see a pretty high 00:07:59.199 --> 00:08:06.560 percentage of retransmitted packets. Remember, these are going from these 00:08:03.840 --> 00:08:11.440 guys back to the base station. This retry column here means that when the 00:08:08.960 --> 00:08:15.280 speakers are sending some kind of data back to the bass unit, maybe it's timing 00:08:13.520 --> 00:08:20.879 information or related to the room correction, I don't know, whatever it 00:08:17.280 --> 00:08:22.800 is, it has to resend that data quite 00:08:20.879 --> 00:08:27.039 often because the base unit isn't receiving it on the first attempt. 00:08:25.280 --> 00:08:32.080 Normally, you would want to see less than about 10% retransmission on your 00:08:29.520 --> 00:08:35.760 wireless network and less than 2% if you're dealing with something like voice 00:08:33.440 --> 00:08:40.479 over IP. anything higher and you're going to start to notice an impact on 00:08:37.200 --> 00:08:42.240 performance. In this case though, I 00:08:40.479 --> 00:08:46.800 don't think that's the source of our problems because if we click through and 00:08:44.800 --> 00:08:53.040 look at the number of packets being sent by the speakers, it is such a tiny 00:08:50.000 --> 00:08:55.839 amount of traffic that even if all four 00:08:53.040 --> 00:09:00.959 of them had to reattempt 100% of the packets they sent, we'd only be looking 00:08:58.000 --> 00:09:05.920 at a few hundred packets spread out over 10 minutes. Uh, I don't think that's the 00:09:03.680 --> 00:09:12.320 issue. So then we've determined that this Sony surround sound soundbar is 00:09:09.120 --> 00:09:15.120 using plain boring old Wi-Fi and that it 00:09:12.320 --> 00:09:18.720 is basically just spewing audio data out for the speakers to pick up and turn 00:09:16.800 --> 00:09:22.399 into sound with very little communication going back from the 00:09:20.560 --> 00:09:26.480 speakers to the base unit. Just the occasional acknowledgement and little 00:09:24.160 --> 00:09:31.040 bits of what Tonic classifies as quality of service data. That still doesn't tell 00:09:29.279 --> 00:09:37.360 us what's wrong. We're going to have to go even deeper. Let's take this data and 00:09:34.240 --> 00:09:39.120 put it into Wireshark, which is a free 00:09:37.360 --> 00:09:43.120 network capture and analysis tool that will let us go through each individual 00:09:41.360 --> 00:09:48.560 frame to try to determine what's happening. Wire uses the exact same data 00:09:46.080 --> 00:09:53.279 as Tonic, but it's not quite so userfriendly. where Tonic organizes 00:09:50.800 --> 00:09:58.160 things into networks and graphs and charts that we can easily explore. 00:09:55.920 --> 00:10:03.200 Wireshark is more like standing in front of a fire hose of raw data. In the 00:10:01.040 --> 00:10:07.680 default view, we get every bit of traffic from every device on every 00:10:05.760 --> 00:10:11.680 network that our wireless interfaces can see over the same 10 minutes that we 00:10:09.839 --> 00:10:15.839 were looking at in tonic. I think it might take 10 minutes just to scroll to 00:10:13.279 --> 00:10:20.480 the bottom of this thing. Um, nobody wants to watch me do that, right? 00:10:17.920 --> 00:10:25.360 Luckily, Wire Shark has a powerful filter system that we can use to turn 00:10:22.079 --> 00:10:27.200 the fire hose into, well, a smaller fire 00:10:25.360 --> 00:10:31.120 hose. We know we're interested in what's happening on channels 44 and 48. So, 00:10:29.519 --> 00:10:36.240 we'll start by narrowing our view down to those. Okay, we're on the right track 00:10:33.839 --> 00:10:40.959 here. It looks like almost all of the transmissions we see here are multiccast 00:10:38.640 --> 00:10:44.959 data coming from the base unit. It looks like it's sending out a couple of frames 00:10:42.480 --> 00:10:50.160 of data every 2 or 3 milliseconds. Let me just scroll down a little bit. See if 00:10:46.560 --> 00:10:52.399 there's anything interesting. Ah, right 00:10:50.160 --> 00:10:57.760 here it switches the channel of the multiccast to channel 48. And if we look 00:10:55.279 --> 00:11:02.880 in the delta column, we see that it was 74 milliseconds since the previous 00:11:00.399 --> 00:11:07.360 transmission. That is pretty significant. We mere mortals don't 00:11:05.200 --> 00:11:12.399 typically perceive lags shorter than 8 to 12 milliseconds. So when we see the 00:11:09.760 --> 00:11:17.839 deltas of 0 to 3 milliseconds leading up to this switch, those would pass us by 00:11:14.800 --> 00:11:20.560 totally unnoticed. 74 milliseconds 00:11:17.839 --> 00:11:24.079 though, that's a lot. What's weird though is that there is nothing else 00:11:22.560 --> 00:11:28.800 happening on these channels at this time. So while it's normal for a 00:11:26.560 --> 00:11:33.040 wireless network to jump around from channel to channel in order to reduce 00:11:30.800 --> 00:11:37.839 interference, if there's nothing else going on, why does it switch? Maybe 00:11:35.839 --> 00:11:46.240 we'll see something if or when it switches back. Ah, at 3996, 00:11:42.160 --> 00:11:48.880 it goes back to 44 with another 76 00:11:46.240 --> 00:11:52.320 millisecond lag. There's also a huge jump in the frame number here. So, that 00:11:50.959 --> 00:11:56.000 means that there's a bunch of other traffic that we're not seeing because of 00:11:54.079 --> 00:12:00.560 our filter. Let's turn our filter off for a minute. There's a bunch of traffic 00:11:58.240 --> 00:12:05.600 on other channels at this time, but it looks like it's mostly access points 00:12:02.480 --> 00:12:07.120 talking to other devices and mostly on 00:12:05.600 --> 00:12:11.279 channels that are at the other end of the spectrum from the Sony base unit. 00:12:09.519 --> 00:12:15.680 Let's change up our filter again and see if there are any other long delays on 00:12:13.120 --> 00:12:20.320 our channels. Let's say anything more than 50 milliseconds. 00:12:18.560 --> 00:12:25.680 Wow, some of these are more than 100 00:12:22.480 --> 00:12:28.160 milliseconds. A tenth of a second. That 00:12:25.680 --> 00:12:32.079 is a massive delay, which could totally explain the audio dropouts that we got 00:12:30.000 --> 00:12:35.600 when we were testing. So now, okay, we're going to take this and we're going 00:12:33.519 --> 00:12:42.720 to jump down to a period where we know that the audio had serious problems. 00:12:39.040 --> 00:12:45.120 And what in the world is going on here? 00:12:42.720 --> 00:12:51.680 This thing is changing channels more than once a millisecond. And it looks 00:12:48.000 --> 00:12:54.720 like, yeah, it's sending out more data 00:12:51.680 --> 00:12:57.279 more often. So, it goes from sending two 00:12:54.720 --> 00:13:03.120 frames on one channel every two to three milliseconds to four or more packets on 00:13:00.959 --> 00:13:06.480 two channels as often as every millisecond. 00:13:04.639 --> 00:13:13.040 Let's check the whole lower end of the 5 GHz spectrum just in case something else 00:13:09.760 --> 00:13:15.760 is making it behave. No, there's 00:13:13.040 --> 00:13:21.519 nothing. Like, there's bits and pieces of other traffic, but it's not much. And 00:13:18.560 --> 00:13:25.600 I'm not seeing anything on 44 or 48 other than the Sony gear, which means 00:13:23.519 --> 00:13:29.839 that our Ghost Hunter episode looking around for the source of the 00:13:26.720 --> 00:13:31.440 interference was pretty close to a real 00:13:29.839 --> 00:13:34.959 episode of Ghost Hunter, meaning we were looking for something that didn't exist 00:13:33.279 --> 00:13:42.160 and misinterpreting the data we collected. The true culprit then is just 00:13:38.880 --> 00:13:44.399 Sony, who has no reason to be shifting 00:13:42.160 --> 00:13:48.959 channels or sending out more frames like this. At least not one that's obvious to 00:13:46.639 --> 00:13:53.839 me or to our friends at Metaggeek. Unless it's ghosts. No, I'm just 00:13:51.279 --> 00:13:58.800 kidding. Which means that unless Sony re-engineers how this thing works, I'm 00:13:56.399 --> 00:14:04.399 going to keep having this problem and so will many other owners of this wireless 00:14:01.760 --> 00:14:08.560 setup. I'm going to have to append both the last video that we did searching for 00:14:06.320 --> 00:14:12.399 the source as well as the sponsored video that we did on these because 00:14:10.639 --> 00:14:15.279 obviously I don't want anyone buying them. Now, I want to give a massive 00:14:14.000 --> 00:14:20.240 shout out to MetGeek, though for providing the tools we needed to diagnose this today, as well as their 00:14:18.480 --> 00:14:23.519 software. Uh, we're hoping that our Labs team is going to make excellent use of 00:14:21.760 --> 00:14:29.040 that relationship in the coming months and years. The path forward for me then 00:14:26.320 --> 00:14:33.440 is what I guess just to do what so many of you suggested last time around and 00:14:30.959 --> 00:14:38.800 put an AV receiver in here and then find a wife approved way of running wires, I 00:14:36.480 --> 00:14:42.320 guess, over to the surrounds. I'm going to miss the room correction 00:14:40.320 --> 00:14:46.800 from these Sony's, that's for sure. Like that was the cool thing that sold me on 00:14:43.839 --> 00:14:50.160 them was a they sound really great and b you could kind of put them anywhere and 00:14:48.480 --> 00:14:55.760 you get a really convincing surround experience. But I mean, who knows? Maybe 00:14:53.760 --> 00:14:59.680 in the grand scheme of things that sucks too and I'd be better off with some 00:14:57.519 --> 00:15:03.360 basic distance correction and EQ from an AVR. With some help from the Labs team, 00:15:01.839 --> 00:15:07.199 we're going to find the answer to that. And while we're at it, hopefully we can 00:15:05.120 --> 00:15:12.399 shed some light on who has the best mainstream room correction. Because darn 00:15:10.000 --> 00:15:17.279 it, I want to stop fighting with this. I want to do it right this time. Like I do 00:15:14.800 --> 00:15:20.880 my segways right like this segue to our sponsor. Thanks to Grammarly for 00:15:19.040 --> 00:15:25.279 sponsoring this video. When it comes to work, communication is key, even if you 00:15:23.760 --> 00:15:29.040 don't have a writing job. Miscommunication can cause confusion 00:15:27.199 --> 00:15:32.880 with your team, leading to delayed projects. And that's why we recommend 00:15:30.959 --> 00:15:36.800 checking out Grammarly Premium's tone rewrite suggestions feature. It will 00:15:35.040 --> 00:15:41.120 help you by providing suggestions to ensure that your writing comes across 00:15:38.399 --> 00:15:44.480 clearly and confidently. A few people on our business team use Grammarly to help 00:15:42.880 --> 00:15:48.240 keep their writing professional and mistake free. To get started, all you 00:15:46.399 --> 00:15:52.639 have to do is install the desktop app, log in, and start typing. I mean, the 00:15:50.480 --> 00:15:56.800 right tone can move any project forward with the help of Grammarly. So, go to 00:15:54.720 --> 00:16:00.320 grammarly.com/LTT to sign up for an account. And if you'd 00:15:58.480 --> 00:16:04.800 like to enhance your writing and tone, upgrade to Grammarly Premium for 20% 00:16:02.639 --> 00:16:08.399 off. If you guys enjoyed this video, why don't you check out the first time we 00:16:06.160 --> 00:16:12.000 worked with MetGeek? It was a long time ago, but it was a really good look at 00:16:10.079 --> 00:16:16.639 their channelizer software and how it can be used to find non Wi-Fi sources of 00:16:14.399 --> 00:16:20.399 interference, which if you'll recall was what I thought I was looking for.