Hi.
I know that the antenna is mounted on the top inside of the Vero, and most of the inside is covered with aluminium, which will weakening the signal.
So as a test, is it possible that you try to lay down the Vero, so that the top of the Vero points in the direction of the router.
I know it’s not a solution (if it works) but It would be very interesting to see if the reception gets better this way.
1 Like
Yeah, that seems to have helped. The signal strength still shows two bars, but I could watch without buffering. I could also watch at 2X and 4X, but it balked at 8X.
Oddly, when I went to look at the network configuration it showed:
“Status: No wireless connection”
I had to disable and enable the adapter in order to look at the configuration (IP address, etc.).
Seems like a poor design if you have to set a device on its side in order to get WiFi to work.
Yes you are right, not the best design, but even worse, it is not something that can be fixed with a software update 
1 Like
Ah, well. Thanks for the suggestion. Given the size and shape of the box, I don’t think anyone but me will ever realize it’s sitting on its side…
I decided to install iperf on the Vero and run some brief tests. I didn’t tweak any parameters. The MacMini hosting the media files is the client, the Vero the server. The first and last results are with the Vero sitting upright. The middle two results are with the Vero on its side:
Client connecting to 192.168.0.180, TCP port 5001
TCP window size: 129 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.0.75 port 62499 connected with 192.168.0.180 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.1 sec 11.9 MBytes 9.90 Mbits/sec
Bleach:~ mnewman$ iperf -c 192.168.0.180
------------------------------------------------------------
Client connecting to 192.168.0.180, TCP port 5001
TCP window size: 129 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.0.75 port 62509 connected with 192.168.0.180 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 21.8 MBytes 18.2 Mbits/sec
Bleach:~ mnewman$ iperf -c 192.168.0.180
------------------------------------------------------------
Client connecting to 192.168.0.180, TCP port 5001
TCP window size: 129 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.0.75 port 62513 connected with 192.168.0.180 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 17.4 MBytes 14.5 Mbits/sec
Bleach:~ mnewman$ iperf -c 192.168.0.180
------------------------------------------------------------
Client connecting to 192.168.0.180, TCP port 5001
TCP window size: 129 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.0.75 port 62560 connected with 192.168.0.180 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-17.4 sec 12.0 MBytes 5.79 Mbits/sec
Doesn’t that seem very, very slow?
I was going to install iperf on the Pi, but I can’t figure out how to do that:
osmc@osmc:~$ sudo apt-get install iperf
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package iperf
and
osmc@osmc:/etc/apt$ cat sources.list
deb http://mirrordirector.raspbian.org/raspbian jessie main contrib non-free
deb http://apt.osmc.tv jessie main
I’m not smart enough to know what’s wrong….
You need to run sudo apt-get update first. Iperf is definitely available.
Yeah, thanks. Stupid me….
Here’s iperf results with the Pi/Airport Express:
Bleach:~ mnewman$ iperf -c 192.168.0.151
------------------------------------------------------------
Client connecting to 192.168.0.151, TCP port 5001
TCP window size: 129 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.0.75 port 49825 connected with 192.168.0.151 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 27.1 MBytes 22.6 Mbits/sec
Just for comparison purposes:
The Vero is about three meters (ten feet) from the router and is, pretty-much, line of sight. The only barrier is the wood sidewall of the entertainment cabinet.
The Pi/Express is about 10 meters (33 feet) from the router with two intervening concrete walls.
I remembered that I have iperf on my iPad3, so I set it up as a server and placed it right over the Vero.
Here are the results:
------------------------------------------------------------
Client connecting to 192.168.0.140, TCP port 5001
TCP window size: 129 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.0.75 port 57086 connected with 192.168.0.140 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 38.9 MBytes 32.6 Mbits/sec
Bleach-2:~ mnewman$ iperf -c 192.168.0.140
------------------------------------------------------------
Client connecting to 192.168.0.140, TCP port 5001
TCP window size: 129 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.0.75 port 57117 connected with 192.168.0.140 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 43.9 MBytes 36.7 Mbits/sec
As one can see, the throughput is about double what the Vero gets when on its side, and about four times what the Vero gets when upright.
I stuck the iPad next to the Pi and still got 26.3 Mbits/sec.
Any fix in the works or are we just stuck with this?
So, no help on this at all?
Vero is a commercial product for which we paid a premium in the expectation that we would be getting a box with superior design and quality implementation. The expectation of decent support goes right along with that.
I don’t feel very good about having paid nearly two hundred bucks for a video player that only works properly when lying on its side. It especially hurts that a $35 RPi B+ and an ancient Airport Express run circles around it when it comes to WiFi performance.
I guess you can continue to ignore me, but do you really want unhappy paying customer?
No one is ignoring you, we are watching the thread. While the attenuation is not as high as it could be, I still think there are some driver issues to be worked on as well. If you wget a speed file you will notice the fluctuations – resolving this could be promising in that it will give more reliable results, but it won’t work miracles.
Sam
1 Like
Thanks for your reply. Sometimes just a few words work wonders…
This is what I have to do to get my Vero to play a 480p video without buffering.
My Pi B+ wired to an Airport Extreme can receive wireless signals through two concrete walls and still stream a 720p video without buffering.
This is not right and needs to be fixed.
It’s a hw design bug … not really much can be done about it. Buy an external wireless stick, details were shown by @thansen_dk who deconstructed it …
Btw. newer cuboxes don’t ship wireless internal anymore … cause it seems they learned from that … only the old models have wireless integrated.
It seems to me that the vendor has an obligation to make good a product that doesn’t work as advertised. One of the reasons I bought the Vero was so that I could do away with the Airport Express I was using with my Pi. I guess I can go back to using the AE.
However, I am extremely unhappy about having paid nearly two hundred bucks for a product that performs so poorly.
So disappointed to see this topic - my big issue with my Pi is streaming from my NAS and if this is performing worse then it completely rules it out for me. 
Really wanted to support the project
That’s easy, just hover your mouse over this link and press the left mouse button https://osmc.tv/contribute/donate/#donate
Already a donator to Raspbmc…
Connection stability should improve when we move to the 4.1 kernel, and I have also disabled power management for the internal WiFi which was causing some issues.
Sam
1 Like
Great stuff, will be following progress to see if there are significant improvements 
I’m still having problems with Vero and WiFi. Right after a reboot, the Vero WiFi performs fine. But, overnight it degrades to the point where a reboot is required. It gets bad enough that it loses connection with the SQL server and I’m unable to log in via ssh:
Bleach:downloads mnewman$ ssh osmc@osmclrwifi
Connection closed by 192.168.0.61
Bleach:downloads mnewman$ ping 192.168.0.61
PING 192.168.0.61 (192.168.0.61): 56 data bytes
Request timeout for icmp_seq 0
64 bytes from 192.168.0.61: icmp_seq=1 ttl=64 time=3.533 ms
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
64 bytes from 192.168.0.61: icmp_seq=9 ttl=64 time=3.724 ms
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11
64 bytes from 192.168.0.61: icmp_seq=12 ttl=64 time=4.670 ms
Request timeout for icmp_seq 13
Request timeout for icmp_seq 14
64 bytes from 192.168.0.61: icmp_seq=15 ttl=64 time=2.691 ms
Request timeout for icmp_seq 16
Request timeout for icmp_seq 17
Request timeout for icmp_seq 18
Request timeout for icmp_seq 19
Request timeout for icmp_seq 20
64 bytes from 192.168.0.61: icmp_seq=21 ttl=64 time=3.965 ms
Request timeout for icmp_seq 22
Request timeout for icmp_seq 23
64 bytes from 192.168.0.61: icmp_seq=24 ttl=64 time=2.773 ms
^C
--- 192.168.0.61 ping statistics ---
25 packets transmitted, 6 packets received, 76.0% packet loss
round-trip min/avg/max/stddev = 2.691/3.559/4.670/0.683 ms
As soon as I reboot, it’s fine:
Bleach:downloads mnewman$ ping 192.168.0.61
PING 192.168.0.61 (192.168.0.61): 56 data bytes
64 bytes from 192.168.0.61: icmp_seq=0 ttl=64 time=2.463 ms
64 bytes from 192.168.0.61: icmp_seq=1 ttl=64 time=2.147 ms
64 bytes from 192.168.0.61: icmp_seq=2 ttl=64 time=3.268 ms
64 bytes from 192.168.0.61: icmp_seq=3 ttl=64 time=2.805 ms
64 bytes from 192.168.0.61: icmp_seq=4 ttl=64 time=2.300 ms
64 bytes from 192.168.0.61: icmp_seq=5 ttl=64 time=2.322 ms
^C
--- 192.168.0.61 ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.147/2.551/3.268/0.380 ms
As I stated before, the Vero is line-of-sight with my router and about four meters away.
This is pinging a Raspberry Pi (via an Airport Express) that is about ten meters from the router with two concrete walls in between:
Bleach:downloads mnewman$ ping osmcbr
PING osmcbr (192.168.0.151): 56 data bytes
64 bytes from 192.168.0.151: icmp_seq=0 ttl=64 time=2.749 ms
64 bytes from 192.168.0.151: icmp_seq=1 ttl=64 time=23.406 ms
64 bytes from 192.168.0.151: icmp_seq=2 ttl=64 time=2.249 ms
64 bytes from 192.168.0.151: icmp_seq=3 ttl=64 time=1.727 ms
64 bytes from 192.168.0.151: icmp_seq=4 ttl=64 time=1.757 ms
64 bytes from 192.168.0.151: icmp_seq=5 ttl=64 time=2.093 ms
64 bytes from 192.168.0.151: icmp_seq=6 ttl=64 time=2.152 ms
^C
--- osmcbr ping statistics ---
7 packets transmitted, 7 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.727/5.162/23.406/7.455 ms
osmc@osmc:~$ sudo journalctl | paste-log
http://paste.osmc.io/ikaqiqefut