1
00:00:00,320 --> 00:00:08,000
It's not fair. I told you my Wi-Fi was

2
00:00:04,960 --> 00:00:11,200
fixed. It worked perfectly for a week.

3
00:00:08,000 --> 00:00:15,200
Then right after we uploaded this video,

4
00:00:11,200 --> 00:00:17,920
it made a big liar out of me. I hate it

5
00:00:15,200 --> 00:00:24,640
when that happens. Intermittent problems are the worst.

6
00:00:20,400 --> 00:00:28,160
Thankfully, now I have this. That's

7
00:00:24,640 --> 00:00:32,399
right, three cheap Wi-Fi adapters and a

8
00:00:28,160 --> 00:00:34,800
USB hub. Okay, admittedly it's not that

9
00:00:32,399 --> 00:00:39,360
impressive, but the software behind it is. Through the power of spectrum

10
00:00:36,960 --> 00:00:44,719
analysis and packet capture, we're going to be digging deeper than ever into what

11
00:00:42,079 --> 00:00:49,920
causes Wi-Fi to randomly lose performance or drop out. And even though

12
00:00:48,160 --> 00:00:54,960
it wasn't our intention, we're going to be exposing some of the BS marketing

13
00:00:52,320 --> 00:01:00,719
that Sony uses to sell their wireless home audio systems. BS marketing that I

14
00:00:58,640 --> 00:01:05,760
unknowingly spread when I did a sponsored video on the very product that

15
00:01:02,879 --> 00:01:11,200
has been causing me all this trouble. Just like I'm about to spread this segue

16
00:01:08,159 --> 00:01:12,799
to our sponsor, Build Redux. Build Redux

17
00:01:11,200 --> 00:01:16,400
takes the challenge and the hassle out of building your own PC with

18
00:01:14,560 --> 00:01:20,640
configuration options, support guides to aid you, and competitive pricing versus

19
00:01:18,400 --> 00:01:24,000
building a PC yourself. Why not kick your feet up and let BuildRredux handle

20
00:01:22,720 --> 00:01:29,880
it for you? Head to buildred redux.com/lininus

21
00:01:25,759 --> 00:01:29,880
and start your new build today.

22
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

23
00:01:40,960 --> 00:01:46,640
the solution last time. Every Wi-Fi card

24
00:01:44,640 --> 00:01:51,439
is constantly looking for wireless networks. It can do this passively, just

25
00:01:49,759 --> 00:01:56,320
listening for different networks to announce their presence, or it can do it

26
00:01:54,079 --> 00:02:00,399
actively by sending out a probe request and then looking at the replies that

27
00:01:57,759 --> 00:02:04,880
come back. Surprisingly, the active method is actually a lot more power

28
00:02:02,799 --> 00:02:10,160
efficient. So, that's what most devices do by default. That means that when I

29
00:02:07,520 --> 00:02:15,520
was going around pointing my wispy antenna at anything and everything in

30
00:02:11,920 --> 00:02:17,760
the house, the Wi-Fi card in my laptop

31
00:02:15,520 --> 00:02:22,959
was happily probing away in the background, blasting out enough power

32
00:02:20,160 --> 00:02:27,760
that even my very high tech directional antenna was able to pick up the signal.

33
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

34
00:02:30,640 --> 00:02:36,480
seem to pick anything up, cuz that's what led us to believe that the source

35
00:02:34,720 --> 00:02:41,599
of the interference could be malfunctioning light switches. I mean, I

36
00:02:39,760 --> 00:02:47,040
should have dismissed this theory as quickly as I dismissed the 2.4 GHz

37
00:02:43,760 --> 00:02:49,440
microwave. Only a grossly malfunctioning

38
00:02:47,040 --> 00:02:54,400
900 MHz device should be capable of emitting any kind of 5 GHz interference.

39
00:02:52,080 --> 00:02:58,720
like so defective that it wouldn't even pass compliance testing. But in fairness

40
00:02:57,280 --> 00:03:02,400
to me with everything I've been through with these switches, nothing would

41
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

42
00:03:05,519 --> 00:03:12,959
dug deeper. And a good place to start digging would be the hidden wireless

43
00:03:10,159 --> 00:03:20,159
SSID that we determined is associated with the base unit here of Sony's HTA9

44
00:03:16,800 --> 00:03:22,080
wireless audio system. Last time around,

45
00:03:20,159 --> 00:03:27,280
we took Sony at their word when they claimed that they were using wireless

46
00:03:24,319 --> 00:03:31,840
sound specification 4.0 to deliver wireless audio to the speakers

47
00:03:28,959 --> 00:03:38,000
distributed around my family room. But looking back on it, if both the freebie

48
00:03:34,560 --> 00:03:40,879
Wi-Fi analyzer on my phone and the paid

49
00:03:38,000 --> 00:03:47,760
channeler software on my laptop saw a hidden Wi-Fi network, then maybe

50
00:03:44,560 --> 00:03:51,360
wireless audio specification 4.0 0 is

51
00:03:47,760 --> 00:03:53,840
just Wi-Fi. To check our theory, we'll

52
00:03:51,360 --> 00:03:57,920
be using MetaGeek's channelizer again with the Wisey adapter, and we'll be

53
00:03:55,920 --> 00:04:03,519
looking for that familiar shape that we know is the Sony base unit. It looks

54
00:04:00,640 --> 00:04:07,840
like it's around channels 44 and 48 today, although that does tend to vary

55
00:04:05,680 --> 00:04:11,439
from day to day, which is part of the reason for my problems. We can see

56
00:04:10,000 --> 00:04:16,400
though there's a hardware address associated with this. So, let's remember

57
00:04:13,920 --> 00:04:22,320
that as we peel back the next layer of this problematic onion with a new piece

58
00:04:18,479 --> 00:04:25,360
of software from MetGeek called Tonic.

59
00:04:22,320 --> 00:04:27,840
Wait, that's Wire Shark. Tonic. Tonic

60
00:04:25,360 --> 00:04:33,840
works by capturing spectrum information also from the Wise Spy, but at the same

61
00:04:30,800 --> 00:04:35,919
time by capturing all of the wireless

62
00:04:33,840 --> 00:04:41,040
network traffic that is bouncing around in the house using off-the-shelf USB

63
00:04:38,560 --> 00:04:46,160
Wi-Fi adapters. Following Metaggeek's recommendation, we went with three of

64
00:04:43,199 --> 00:04:52,320
these Eddax EW7833 UAC units that retail for about $50

65
00:04:49,199 --> 00:04:54,960
each. Each of these has three antennas

66
00:04:52,320 --> 00:04:58,560
and supports 3x3 spatial streams, which means that they're able to take

67
00:04:56,400 --> 00:05:02,639
advantage of multipath transmission to significantly improve throughput. And

68
00:05:01,040 --> 00:05:06,560
more importantly, it means that it's extremely unlikely that they're going to

69
00:05:04,479 --> 00:05:10,639
miss anything when we start capturing traffic. Just for transparency, we're

70
00:05:09,280 --> 00:05:16,160
probably going to do a little bit of movie magic here and show you guys a

71
00:05:12,400 --> 00:05:18,560
mixture of live and pre-captured data.

72
00:05:16,160 --> 00:05:22,560
We got a ton of audio dropouts and other artifacts when we were testing this out

73
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

74
00:05:24,320 --> 00:05:30,320
camera starts rolling, your product demonstration will fail. All right, the

75
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,

76
00:05:33,600 --> 00:05:39,840
then we're going to click on show hidden. And sure enough, there's a

77
00:05:38,160 --> 00:05:45,360
hidden network with the Mac Address that we noticed in Channeler. That is our

78
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

79
00:05:47,919 --> 00:05:55,919
subwoofer. Sorry. Anywh who, when we click on that network, we get a list of

80
00:05:52,639 --> 00:05:57,520
access points, which is just one because

81
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

82
00:06:00,320 --> 00:06:06,319
is entirely this. It's on channel 44 and

83
00:06:04,000 --> 00:06:11,520
it has five clients, which makes sense because we've got four wireless speakers

84
00:06:09,280 --> 00:06:15,440
around the room and then also the subwoofer. When we click on the access

85
00:06:13,600 --> 00:06:19,440
point, we get some more detail about it and we get some graphs and charts that

86
00:06:17,759 --> 00:06:23,840
summarize the traffic that's being transmitted by it. If it can show us all

87
00:06:21,440 --> 00:06:28,000
this information about the AP's radio, that means according to our contact at

88
00:06:25,520 --> 00:06:32,800
Metgeek, there is pretty much no doubt that Sony's wireless sound

89
00:06:30,240 --> 00:06:37,120
specification, it's just a typical Wi-Fi 4 network rather than some special

90
00:06:34,720 --> 00:06:41,360
technology they've invented. Though, I mean, that does kind of make sense since

91
00:06:39,120 --> 00:06:47,600
getting some new wireless technology certified for 5 GHz globally would be a

92
00:06:44,800 --> 00:06:51,520
monumental task. But then from my point of view, they should just say it's

93
00:06:49,919 --> 00:06:55,440
Wi-Fi. That would have made troubleshooting this a lot easier from

94
00:06:53,600 --> 00:06:59,840
the start. Looking at the airtime distribution now, it's interesting that

95
00:06:57,440 --> 00:07:05,919
basically all the traffic sent out by this base unit is broadcast rather than

96
00:07:03,360 --> 00:07:11,120
being sent to a particular client. What that means then is that this base unit

97
00:07:08,240 --> 00:07:15,599
is just blasting Wi-Fi signals out into the air for any device that's listening

98
00:07:13,360 --> 00:07:20,240
without any regard for whether the signal actually gets to all of the

99
00:07:17,680 --> 00:07:24,479
speakers or some of the speakers or the speakers and something else. And then

100
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

101
00:07:27,120 --> 00:07:34,400
channel it's supposed to play. I suppose every speaker just gets all the data for

102
00:07:31,520 --> 00:07:40,479
every channel, which might explain some of why they are not able to make

103
00:07:37,120 --> 00:07:41,759
efficient use of the spectrum. I mean, I

104
00:07:40,479 --> 00:07:45,280
can kind of see why they took this approach since they need to keep latency

105
00:07:43,599 --> 00:07:54,520
low enough to keep audio sync to the picture, but clearly it's not working. A

106
00:07:48,960 --> 00:07:54,520
little weird, but not super weird yet.

107
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

108
00:07:59,199 --> 00:08:06,560
percentage of retransmitted packets. Remember, these are going from these

109
00:08:03,840 --> 00:08:11,440
guys back to the base station. This retry column here means that when the

110
00:08:08,960 --> 00:08:15,280
speakers are sending some kind of data back to the bass unit, maybe it's timing

111
00:08:13,520 --> 00:08:20,879
information or related to the room correction, I don't know, whatever it

112
00:08:17,280 --> 00:08:22,800
is, it has to resend that data quite

113
00:08:20,879 --> 00:08:27,039
often because the base unit isn't receiving it on the first attempt.

114
00:08:25,280 --> 00:08:32,080
Normally, you would want to see less than about 10% retransmission on your

115
00:08:29,520 --> 00:08:35,760
wireless network and less than 2% if you're dealing with something like voice

116
00:08:33,440 --> 00:08:40,479
over IP. anything higher and you're going to start to notice an impact on

117
00:08:37,200 --> 00:08:42,240
performance. In this case though, I

118
00:08:40,479 --> 00:08:46,800
don't think that's the source of our problems because if we click through and

119
00:08:44,800 --> 00:08:53,040
look at the number of packets being sent by the speakers, it is such a tiny

120
00:08:50,000 --> 00:08:55,839
amount of traffic that even if all four

121
00:08:53,040 --> 00:09:00,959
of them had to reattempt 100% of the packets they sent, we'd only be looking

122
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

123
00:09:03,680 --> 00:09:12,320
issue. So then we've determined that this Sony surround sound soundbar is

124
00:09:09,120 --> 00:09:15,120
using plain boring old Wi-Fi and that it

125
00:09:12,320 --> 00:09:18,720
is basically just spewing audio data out for the speakers to pick up and turn

126
00:09:16,800 --> 00:09:22,399
into sound with very little communication going back from the

127
00:09:20,560 --> 00:09:26,480
speakers to the base unit. Just the occasional acknowledgement and little

128
00:09:24,160 --> 00:09:31,040
bits of what Tonic classifies as quality of service data. That still doesn't tell

129
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

130
00:09:34,240 --> 00:09:39,120
put it into Wireshark, which is a free

131
00:09:37,360 --> 00:09:43,120
network capture and analysis tool that will let us go through each individual

132
00:09:41,360 --> 00:09:48,560
frame to try to determine what's happening. Wire uses the exact same data

133
00:09:46,080 --> 00:09:53,279
as Tonic, but it's not quite so userfriendly. where Tonic organizes

134
00:09:50,800 --> 00:09:58,160
things into networks and graphs and charts that we can easily explore.

135
00:09:55,920 --> 00:10:03,200
Wireshark is more like standing in front of a fire hose of raw data. In the

136
00:10:01,040 --> 00:10:07,680
default view, we get every bit of traffic from every device on every

137
00:10:05,760 --> 00:10:11,680
network that our wireless interfaces can see over the same 10 minutes that we

138
00:10:09,839 --> 00:10:15,839
were looking at in tonic. I think it might take 10 minutes just to scroll to

139
00:10:13,279 --> 00:10:20,480
the bottom of this thing. Um, nobody wants to watch me do that, right?

140
00:10:17,920 --> 00:10:25,360
Luckily, Wire Shark has a powerful filter system that we can use to turn

141
00:10:22,079 --> 00:10:27,200
the fire hose into, well, a smaller fire

142
00:10:25,360 --> 00:10:31,120
hose. We know we're interested in what's happening on channels 44 and 48. So,

143
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

144
00:10:33,839 --> 00:10:40,959
here. It looks like almost all of the transmissions we see here are multiccast

145
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

146
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

147
00:10:46,560 --> 00:10:52,399
there's anything interesting. Ah, right

148
00:10:50,160 --> 00:10:57,760
here it switches the channel of the multiccast to channel 48. And if we look

149
00:10:55,279 --> 00:11:02,880
in the delta column, we see that it was 74 milliseconds since the previous

150
00:11:00,399 --> 00:11:07,360
transmission. That is pretty significant. We mere mortals don't

151
00:11:05,200 --> 00:11:12,399
typically perceive lags shorter than 8 to 12 milliseconds. So when we see the

152
00:11:09,760 --> 00:11:17,839
deltas of 0 to 3 milliseconds leading up to this switch, those would pass us by

153
00:11:14,800 --> 00:11:20,560
totally unnoticed. 74 milliseconds

154
00:11:17,839 --> 00:11:24,079
though, that's a lot. What's weird though is that there is nothing else

155
00:11:22,560 --> 00:11:28,800
happening on these channels at this time. So while it's normal for a

156
00:11:26,560 --> 00:11:33,040
wireless network to jump around from channel to channel in order to reduce

157
00:11:30,800 --> 00:11:37,839
interference, if there's nothing else going on, why does it switch? Maybe

158
00:11:35,839 --> 00:11:46,240
we'll see something if or when it switches back. Ah, at 3996,

159
00:11:42,160 --> 00:11:48,880
it goes back to 44 with another 76

160
00:11:46,240 --> 00:11:52,320
millisecond lag. There's also a huge jump in the frame number here. So, that

161
00:11:50,959 --> 00:11:56,000
means that there's a bunch of other traffic that we're not seeing because of

162
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

163
00:11:58,240 --> 00:12:05,600
on other channels at this time, but it looks like it's mostly access points

164
00:12:02,480 --> 00:12:07,120
talking to other devices and mostly on

165
00:12:05,600 --> 00:12:11,279
channels that are at the other end of the spectrum from the Sony base unit.

166
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

167
00:12:13,120 --> 00:12:20,320
our channels. Let's say anything more than 50 milliseconds.

168
00:12:18,560 --> 00:12:25,680
Wow, some of these are more than 100

169
00:12:22,480 --> 00:12:28,160
milliseconds. A tenth of a second. That

170
00:12:25,680 --> 00:12:32,079
is a massive delay, which could totally explain the audio dropouts that we got

171
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

172
00:12:33,519 --> 00:12:42,720
to jump down to a period where we know that the audio had serious problems.

173
00:12:39,040 --> 00:12:45,120
And what in the world is going on here?

174
00:12:42,720 --> 00:12:51,680
This thing is changing channels more than once a millisecond. And it looks

175
00:12:48,000 --> 00:12:54,720
like, yeah, it's sending out more data

176
00:12:51,680 --> 00:12:57,279
more often. So, it goes from sending two

177
00:12:54,720 --> 00:13:03,120
frames on one channel every two to three milliseconds to four or more packets on

178
00:13:00,959 --> 00:13:06,480
two channels as often as every millisecond.

179
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

180
00:13:09,760 --> 00:13:15,760
is making it behave. No, there's

181
00:13:13,040 --> 00:13:21,519
nothing. Like, there's bits and pieces of other traffic, but it's not much. And

182
00:13:18,560 --> 00:13:25,600
I'm not seeing anything on 44 or 48 other than the Sony gear, which means

183
00:13:23,519 --> 00:13:29,839
that our Ghost Hunter episode looking around for the source of the

184
00:13:26,720 --> 00:13:31,440
interference was pretty close to a real

185
00:13:29,839 --> 00:13:34,959
episode of Ghost Hunter, meaning we were looking for something that didn't exist

186
00:13:33,279 --> 00:13:42,160
and misinterpreting the data we collected. The true culprit then is just

187
00:13:38,880 --> 00:13:44,399
Sony, who has no reason to be shifting

188
00:13:42,160 --> 00:13:48,959
channels or sending out more frames like this. At least not one that's obvious to

189
00:13:46,639 --> 00:13:53,839
me or to our friends at Metaggeek. Unless it's ghosts. No, I'm just

190
00:13:51,279 --> 00:13:58,800
kidding. Which means that unless Sony re-engineers how this thing works, I'm

191
00:13:56,399 --> 00:14:04,399
going to keep having this problem and so will many other owners of this wireless

192
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

193
00:14:06,320 --> 00:14:12,399
the source as well as the sponsored video that we did on these because

194
00:14:10,639 --> 00:14:15,279
obviously I don't want anyone buying them. Now, I want to give a massive

195
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

196
00:14:18,480 --> 00:14:23,519
software. Uh, we're hoping that our Labs team is going to make excellent use of

197
00:14:21,760 --> 00:14:29,040
that relationship in the coming months and years. The path forward for me then

198
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

199
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

200
00:14:36,480 --> 00:14:42,320
guess, over to the surrounds. I'm going to miss the room correction

201
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

202
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

203
00:14:48,480 --> 00:14:55,760
you get a really convincing surround experience. But I mean, who knows? Maybe

204
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

205
00:14:57,519 --> 00:15:03,360
basic distance correction and EQ from an AVR. With some help from the Labs team,

206
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

207
00:15:05,120 --> 00:15:12,399
shed some light on who has the best mainstream room correction. Because darn

208
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

209
00:15:14,800 --> 00:15:20,880
my segways right like this segue to our sponsor. Thanks to Grammarly for

210
00:15:19,040 --> 00:15:25,279
sponsoring this video. When it comes to work, communication is key, even if you

211
00:15:23,760 --> 00:15:29,040
don't have a writing job. Miscommunication can cause confusion

212
00:15:27,199 --> 00:15:32,880
with your team, leading to delayed projects. And that's why we recommend

213
00:15:30,959 --> 00:15:36,800
checking out Grammarly Premium's tone rewrite suggestions feature. It will

214
00:15:35,040 --> 00:15:41,120
help you by providing suggestions to ensure that your writing comes across

215
00:15:38,399 --> 00:15:44,480
clearly and confidently. A few people on our business team use Grammarly to help

216
00:15:42,880 --> 00:15:48,240
keep their writing professional and mistake free. To get started, all you

217
00:15:46,399 --> 00:15:52,639
have to do is install the desktop app, log in, and start typing. I mean, the

218
00:15:50,480 --> 00:15:56,800
right tone can move any project forward with the help of Grammarly. So, go to

219
00:15:54,720 --> 00:16:00,320
grammarly.com/LTT to sign up for an account. And if you'd

220
00:15:58,480 --> 00:16:04,800
like to enhance your writing and tone, upgrade to Grammarly Premium for 20%

221
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

222
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

223
00:16:10,079 --> 00:16:16,639
their channelizer software and how it can be used to find non Wi-Fi sources of

224
00:16:14,399 --> 00:16:20,399
interference, which if you'll recall was what I thought I was looking for.