I recently acquired a nicely assembled piHPSDR unit and have been enjoying it a lot. However I've noticed a quirk that I'm wondering if others have experienced.
My primary use for the unit is to run my Anan 200D remotely from other places in the house. The 200D is on a gigabit switch/wireless router with dual bands that covers the operating areas with good signal level. I am able to connect and run the Anan easily. However, when I'm listening to a signal, I get a couple of seconds of regular receive stuttering on a semi regular basis. After observing it over a period of time, it seemed it was happening on a very regular basis. Eventually I got curious enough to time it, and it seems to happen on 60 second intervals, or multiples of 60 seconds. That is, it may happen after 120 seconds, another 60 seconds, then maybe 300 seconds ,then back to 120 seconds. It rarely seems to happen at the longer intervals, I'd say 120 seconds is the most common.
It seems to happen whether I'm in the same room with the router, or if I'm a couple of walls away. The signal levels on the router seem good no matter where I am in the house, with speeds reported of 72 mbps typically.
On one occasion I did wire it to the router and as i recall there was no stuttering when wired.
As an experiment to check the quality of the wireless, last night I loaded up 3.3.15 on my I5 based laptop and ran the unit remotely for a while using the wireless and there was no stuttering. To me that indicates the anan200D and the wireless are both up to the task. In previous wireless operation with 3.3.9 using the same laptop, I was seeing about 25 mbps data transfer to run a similar test.
This seems to indicate that the issue is within the pi unit - makes me wonder what might run on a 60 second interval, and what might involve the wireless driver.
The pi is running the latest version 1.13, and the Anan firmware is 4.0. I'm running 48 khz bandwidth, single receiver.
I didn't set up the unit, so I'm not sure what else might be loaded on the unit. Teamviewer starts up, but I quit it immediately as I'm not using it at this point.
Anybody experiencing similar stuttering? Any thoughts as to what to check into?
Thanks
Kevin, WB2EMS
Receive stutter
Re: Receive stutter
Kevin,
I've done a number of Wi-Fi experiments with my homebrew piHPSDR unit. This includes using the built-in Wi-Fi as well as an 802.11ac USB Wi-Fi adapter. I should mention I have top of the line Ubiquiti UniFi AC LR 802.11ac access points.
I can get smooth receive audio on my pi over Wi-Fi, but transmit audio is plagued with drop-outs.
When one looks at the available performance, it's clear that there is plenty of bandwidth available by any LAN modality.
LAN throughput (iperf3)
100BASE-T, 12MBytes/s
Built-in WiFi, 6MBytes/s
DWA-171 in 802.11n mode, 12MBytes/s
DWA-171 in 802.11ac mode, 18MBytes/s
Radio LAN usage (iftop)
Pi to Radio, 1.4MBytes/s
Radio to Pi (48KHz), 0.5MBytes/s
Radio to Pi (192KHz), 1.25MBytes/s
Obviously the transmit direction is more demanding, however still well within the capabilities of the DWA-171. It may be pushing things a bit on the built-in Wi-Fi.
However...
Wi-Fi is prone to latency issues. Even on a lightly loaded access point, the darn thing will periodically stop and do other stuff. Since we don't want to use seconds worth of buffering, like Youtube, Netflix and other streaming services, this makes the streams between client and radio VERY susceptible to even the smallest interruptions. It would seem that for whatever reason, the Wi-Fi in your pi wants to stop and do other things on receive, as does mine on transmit.
I wish I could tell you what those other things are because I'd like this thing to work over Wi-Fi very badly. It just screams out "Carry me around the house!" At least I have shown that, for "good" Wi-Fi, it has to be a latency issue and not a gross throughput issue. Perhaps there are some linux jockey's out there who can figure out the secret sauce.
73!
Scott
I've done a number of Wi-Fi experiments with my homebrew piHPSDR unit. This includes using the built-in Wi-Fi as well as an 802.11ac USB Wi-Fi adapter. I should mention I have top of the line Ubiquiti UniFi AC LR 802.11ac access points.
I can get smooth receive audio on my pi over Wi-Fi, but transmit audio is plagued with drop-outs.
When one looks at the available performance, it's clear that there is plenty of bandwidth available by any LAN modality.
LAN throughput (iperf3)
100BASE-T, 12MBytes/s
Built-in WiFi, 6MBytes/s
DWA-171 in 802.11n mode, 12MBytes/s
DWA-171 in 802.11ac mode, 18MBytes/s
Radio LAN usage (iftop)
Pi to Radio, 1.4MBytes/s
Radio to Pi (48KHz), 0.5MBytes/s
Radio to Pi (192KHz), 1.25MBytes/s
Obviously the transmit direction is more demanding, however still well within the capabilities of the DWA-171. It may be pushing things a bit on the built-in Wi-Fi.
However...
Wi-Fi is prone to latency issues. Even on a lightly loaded access point, the darn thing will periodically stop and do other stuff. Since we don't want to use seconds worth of buffering, like Youtube, Netflix and other streaming services, this makes the streams between client and radio VERY susceptible to even the smallest interruptions. It would seem that for whatever reason, the Wi-Fi in your pi wants to stop and do other things on receive, as does mine on transmit.
I wish I could tell you what those other things are because I'd like this thing to work over Wi-Fi very badly. It just screams out "Carry me around the house!" At least I have shown that, for "good" Wi-Fi, it has to be a latency issue and not a gross throughput issue. Perhaps there are some linux jockey's out there who can figure out the secret sauce.
73!
Scott
Re: Receive stutter
Thanks for the quick reply Scott!
Yeah, mobility is the goal with these things I'd say. If it's going to sit in the shack, I might as well use the big computer and it's multiple monitors. I want to emulate your use case as so eloquently depicted in that nice picture.
My wireless access point is also 11ac capable, and dual band. I tried to get a wireless usb unit that could do 5 ghz for the pi, but wasn't able to find drivers for it. But running the laptop on 3.3.15 with more bandwidth (192) and no dropouts pretty much shows that the capability is there on 2.4 at least on the access point and radio end. The internal 2.4 on the pi doesn't have much of an antenna, but looking at the signal stats, it seems to have plenty of signal (-45 dbm) and shows a data rate of 72 mbps, which should be way more than enough.
The AP for the shack is on the other end of the spectrum from the house internet AP (14 vs channel 1) so there should be no interference there. Scanning the wifi spectrum shows my Roku box talking to the house internet on channel 1, but nothing else about - I'm out in the country so while I get slammed by part15 junk on the HF spectrum by my neighbors, (like a 5kw kiln with a controller akin to the old fish tank heaters) I don't get any other 2.4 ghz signals. And again, the laptop on the same spectrum runs fine.
I'm not a linux jockey at all, but I'll ask my buddy who is how to see what else might be running on the system. Mike had it running well at his house and his clone of it runs fine, so I'm thinking it's something in my environment.
On transmit it was somewhat functional, I did part of the net two weeks ago running it and did some tests with Mike. Had some RF issues from the transmitter potentially, which I need to sort out before digging deeper.
73 de Kevin, WB2EMS
Yeah, mobility is the goal with these things I'd say. If it's going to sit in the shack, I might as well use the big computer and it's multiple monitors. I want to emulate your use case as so eloquently depicted in that nice picture.
![Wink ;)](./images/smilies/icon_e_wink.gif)
My wireless access point is also 11ac capable, and dual band. I tried to get a wireless usb unit that could do 5 ghz for the pi, but wasn't able to find drivers for it. But running the laptop on 3.3.15 with more bandwidth (192) and no dropouts pretty much shows that the capability is there on 2.4 at least on the access point and radio end. The internal 2.4 on the pi doesn't have much of an antenna, but looking at the signal stats, it seems to have plenty of signal (-45 dbm) and shows a data rate of 72 mbps, which should be way more than enough.
The AP for the shack is on the other end of the spectrum from the house internet AP (14 vs channel 1) so there should be no interference there. Scanning the wifi spectrum shows my Roku box talking to the house internet on channel 1, but nothing else about - I'm out in the country so while I get slammed by part15 junk on the HF spectrum by my neighbors, (like a 5kw kiln with a controller akin to the old fish tank heaters) I don't get any other 2.4 ghz signals. And again, the laptop on the same spectrum runs fine.
I'm not a linux jockey at all, but I'll ask my buddy who is how to see what else might be running on the system. Mike had it running well at his house and his clone of it runs fine, so I'm thinking it's something in my environment.
On transmit it was somewhat functional, I did part of the net two weeks ago running it and did some tests with Mike. Had some RF issues from the transmitter potentially, which I need to sort out before digging deeper.
73 de Kevin, WB2EMS
Re: Receive stutter
Kevin,
If you are interested in adding dual-band, 802.11ac USB adapter to your Pi, see this thread:
https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=62371
I used Engman's drivers and the mostly work. I still have a lot of instability on my DWA-171, meaning it'll disconnect from the AP from time to time, but his drivers are getting steadily better.
73!
Scott
If you are interested in adding dual-band, 802.11ac USB adapter to your Pi, see this thread:
https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=62371
I used Engman's drivers and the mostly work. I still have a lot of instability on my DWA-171, meaning it'll disconnect from the AP from time to time, but his drivers are getting steadily better.
73!
Scott
Re: Receive stutter
That looks fairly complicated for my meager understanding of linux at this point. Perhaps in the future. I had been more interested in running 5 ghz when I didn't know the rf space conditions on 2.4 at my site. Now that I know they are pretty clean, and that 2.4 runs ok with other computers, the need to explore 5 ghz has diminished.
Talking with my linux buddy yesterday, he recommended I run top to see what was chewing up CPU. I didn't do it while connected to the anan, got home too late for that last night, but just running it showed me that teamviewer wasn't completely shut down. So I'll experiment with that command when connected up and running and see what I can discover.
73 de Kevin, WB2EMS
Talking with my linux buddy yesterday, he recommended I run top to see what was chewing up CPU. I didn't do it while connected to the anan, got home too late for that last night, but just running it showed me that teamviewer wasn't completely shut down. So I'll experiment with that command when connected up and running and see what I can discover.
73 de Kevin, WB2EMS
- Mike, K0JTA
- Posts: 16
- Joined: Sun Apr 09, 2017 11:29 pm
- Location: Hampton, Minnesota
Re: Receive stutter
Teamviewer (TV) is "always there," it seems. (No matter if the app is running or not.) So, just to be really sure that the TV app is not availing itself to the TV mother-ship, REMOVE the TV app entirely. The installer is in the unit, someplace, but is easily downloaded. (Just a suggestion, considering the TV app doing something that is taxing or interrupting the wifi data stream...)
73; Mike, K0JTA
73; Mike, K0JTA
Re: Receive stutter
Good thought on the ROKU box interrupting things, but it's many mhz away on the house wifi system, not on the dedicated shack wifi system that the pi is connected to. Still, I could power it off for a test.
I repeated the test tonight of direct cabling into the 200D. No stutter, with the WiFi turned on or off.
My thought had always been that teamviewer or some process was coming on every 60 seconds and trying to 'phone home' or whatever, but I'm not enough of a linux guy to know how to root out what the process might be, yet. But when I attempted to upgrade, I decided to do a fresh install, learn more about the process and also not install any other things. I followed the directions to build and update a fresh load of Raspbian, and then to download the current release (1.2.3).
Problem 1 was that the knobs are not working correctly, even though I've tried to copy the GPIO mapping from the working version to the new version both manually, and by copying in the .prop files which I read somewhere was where that information was stored. So far no joy there.
But imagine my surprise when my old friend the 60 second stutter was back in this clean build! Seems to behave essentially the same as the 1.1.3 version, except after a few minutes the stuttering or breakups become worse and more frequent as Paul noted.
So for now I'm doddering along with an old build that boots successfully about 1 time out of 3 and really need to build a solid stable version, hopefully new enough for some of the features but far enough back to avoid the issue Paul and I seem to be having in 1.2.3, and I need to figure out how to map the knobs correctly on the new version and any future versions. I'm hoping I can find a way to do that from the info stored in the working version instead of having to pencil out how things are soldered to the board. And I still need to find out why it stutters every 60 seconds like clockwork. I may try a stripped version of Raspbian and not download all the updates to it and see how that behaves. I'm laid up for a couple of weeks with a new knee, might as well learn a little pi and linux. But any guidance would be very appreciated. Scott, did you ever have better luck in transmit? It's such a cool toy and I'm 90% there, but that last 10%....
73 de Kevin, WB2EMS
I repeated the test tonight of direct cabling into the 200D. No stutter, with the WiFi turned on or off.
My thought had always been that teamviewer or some process was coming on every 60 seconds and trying to 'phone home' or whatever, but I'm not enough of a linux guy to know how to root out what the process might be, yet. But when I attempted to upgrade, I decided to do a fresh install, learn more about the process and also not install any other things. I followed the directions to build and update a fresh load of Raspbian, and then to download the current release (1.2.3).
Problem 1 was that the knobs are not working correctly, even though I've tried to copy the GPIO mapping from the working version to the new version both manually, and by copying in the .prop files which I read somewhere was where that information was stored. So far no joy there.
But imagine my surprise when my old friend the 60 second stutter was back in this clean build! Seems to behave essentially the same as the 1.1.3 version, except after a few minutes the stuttering or breakups become worse and more frequent as Paul noted.
So for now I'm doddering along with an old build that boots successfully about 1 time out of 3 and really need to build a solid stable version, hopefully new enough for some of the features but far enough back to avoid the issue Paul and I seem to be having in 1.2.3, and I need to figure out how to map the knobs correctly on the new version and any future versions. I'm hoping I can find a way to do that from the info stored in the working version instead of having to pencil out how things are soldered to the board. And I still need to find out why it stutters every 60 seconds like clockwork. I may try a stripped version of Raspbian and not download all the updates to it and see how that behaves. I'm laid up for a couple of weeks with a new knee, might as well learn a little pi and linux. But any guidance would be very appreciated. Scott, did you ever have better luck in transmit? It's such a cool toy and I'm 90% there, but that last 10%....
73 de Kevin, WB2EMS
Re: Receive stutter
Just an update, though there seems to be nothing new on pihpsdr.
I've been running PowerSDR 3.4.7 for most of the last month very successfully on a little windows tablet, basic quad core 3750 box. No wireless dropouts in the house unless i put something between it and the access point to physically interfere with the signal. Otherwise it's flawless. I've been listening for hours on end as I've been recovering from surgery and making qso's as well from the tablet. That's pretty well debunked the 'well your wireless environment is the problem' issues. The 60 second dropout is clearly an issue in the pi setup.
Since I've got such a nice portable solution I've sort of drifted away from trying to debug the pihpsdr setup. I'd still like to get it running correctly and bought a pi 3 B+ board to swap in to see if it's improved speed and better wireless support might help. Not clear when I might get to grafting that into the setup.
Still looking for clues.
73 de Kevin, WB2EMS
I've been running PowerSDR 3.4.7 for most of the last month very successfully on a little windows tablet, basic quad core 3750 box. No wireless dropouts in the house unless i put something between it and the access point to physically interfere with the signal. Otherwise it's flawless. I've been listening for hours on end as I've been recovering from surgery and making qso's as well from the tablet. That's pretty well debunked the 'well your wireless environment is the problem' issues. The 60 second dropout is clearly an issue in the pi setup.
Since I've got such a nice portable solution I've sort of drifted away from trying to debug the pihpsdr setup. I'd still like to get it running correctly and bought a pi 3 B+ board to swap in to see if it's improved speed and better wireless support might help. Not clear when I might get to grafting that into the setup.
Still looking for clues.
73 de Kevin, WB2EMS
Re: Receive stutter
I know its a while since the last instalment in this conversation but I stumbled across this thread while trying to solve what looks like the same problem myself. I'm new to pihpsdr having just recently bought a second-hand ANAN 100D which came with version 1 of the controller, but I am a long term linux user and programmer and I just couldn't let this problem be. Soooo, after reading the above, and a bit of head scratching and research I discovered this post:
https://www.raspberrypi.org/forums/view ... 8#p1674971
In short it seems the problem is caused by a wireless AP scan happening once every 60 seconds. The problem was fixed for me by adding the following lines to the Config section inside the dhcpcdui section of .config/lxpanel/LXDE-pi/panels/panel
BgScan=0
BgScanMenu=10000
and then rebooting.
The first line turns the background scan off while the second line sets the scan interval to 10 seconds whenever the wifi menu is displayed.
Cheers.
VK2MKE
https://www.raspberrypi.org/forums/view ... 8#p1674971
In short it seems the problem is caused by a wireless AP scan happening once every 60 seconds. The problem was fixed for me by adding the following lines to the Config section inside the dhcpcdui section of .config/lxpanel/LXDE-pi/panels/panel
BgScan=0
BgScanMenu=10000
and then rebooting.
The first line turns the background scan off while the second line sets the scan interval to 10 seconds whenever the wifi menu is displayed.
Cheers.
VK2MKE