Welcome to the new FlexRadio Community! Please review the new Community Rules and other important new Community information on the Message Board.
If you are having a problem, please check the Help Center for known solutions.
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.
Need the latest SmartSDR and Power Genius Software?
SmartSDR v3.1.12 and the SmartSDR v3.1.12 Release Notes. | SmartSDR v2.6.2 and the SmartSDR v2.6.2 Release Notes.
SmartSDR v1.12.1 and the SmartSDR v1.12.1 Release Notes. | Power Genius XL Firmware v3.4.16. | Power Genius XL Utility v2.2.10.
SmartSDR v3.1.12 and the SmartSDR v3.1.12 Release Notes. | SmartSDR v2.6.2 and the SmartSDR v2.6.2 Release Notes.
SmartSDR v1.12.1 and the SmartSDR v1.12.1 Release Notes. | Power Genius XL Firmware v3.4.16. | Power Genius XL Utility v2.2.10.
SmartSDR 3.0.19 - No-Go over VPN
I have been running SmartSDR 3.0.19 locally at both home and my remote station site for weeks without incident. Today, I decided to do some remote SSB from home to the remote station...
The 3.0.19 SmartSDR client with Multi-flex absolutely craters my VPN connection (similar to how DAX does). My VPN connection has just 540Kb of (DSL) upload bandwidth available. Something in 3.0.19 is abusing upload bandwidth, making this version unusable over the VPN.
As a result, I have dropped back to 2.4.9, which works perfectly across the VPN and has for years.
I suspect it may have something to do with Multi-flex, but unable to determine for sure what's chewing up so much bandwidth.
The 3.0.19 SmartSDR client with Multi-flex absolutely craters my VPN connection (similar to how DAX does). My VPN connection has just 540Kb of (DSL) upload bandwidth available. Something in 3.0.19 is abusing upload bandwidth, making this version unusable over the VPN.
As a result, I have dropped back to 2.4.9, which works perfectly across the VPN and has for years.
I suspect it may have something to do with Multi-flex, but unable to determine for sure what's chewing up so much bandwidth.
0
Leave a Comment
Categories
- 70 Community Topics
- 1.9K New Ideas
- 120 The Flea Market
- 5.4K Software
- 4.9K SmartSDR for Windows
- 35 SmartSDR for Maestro and M models
- 89 SmartSDR for Mac
- 144 SmartSDR for iOS
- 150 SmartSDR CAT
- 70 DAX
- 279 SmartSDR API
- 7.1K Radios and Accessories
- 5.8K FLEX-6000 Signature Series
- 557 Maestro
- 14 FlexControl
- 723 FLEX Series (Legacy) Radios
- 155 Power Genius Products
- 120 Power Genius XL Amplifier
- 12 Power Genius Utility
- 23 Tuner Genius
- 41 Shack Infrastructure
- 22 Networking
- 90 Remote Operation (SmartLink)
- 50 Contesting
- 131 Peripherals & Station Integration
- 63 Amateur Radio Interests
- 407 Third-Party Software
Comments
It appears the uplink from remote station is saturated, as link latency goes from 30 ms (no load) to more than 3,000 then SmartSDR disconnects. Normal operation with v2 bounces between 30 and 120 ms.
Using iperf, I see 540 Kbps from remote site and 1.5 Mbps to radio at remote site. It’s DSL, which isn’t great, but it’s always worked well for SSB on v2 and v1.
You got me thinking, so I went to measure mine, and this is what I see with 1 slice, FPS about 25% and Rate about the same on my Maestro.
Is there anyway you can dig deeper and see if it is all going to the same client?
This is on V3.
The audio is set to compressed only when using SmartLink. It is uncompressed when operating on a LAN (which VPN simulates). This is a change between v2 and v3.
Mike
Why did Flex make this change? I also use a VPN from time to time. There are situations where it is preferable to SmartLink. I have not upgraded to 3.0, and I am concerned that doing so would hamper my ability to operate from some of the places I currently do.
73,
Doug K4DSP
They removed the compression for a standard LAN connections since there was no requirement to have it compressed. For none LAN and remote connections we have SmartLink, so that remains compressed.
Mike
Please provide a way to configure compress/decompress.
That being said, having run remote for about 15 years, I did find that leaving all the controls on a local PC less painful.
About 6 years ago, I went back to a local PC with all the antenna, amp and everything else control on a Local PC and then I RDP'd to that computer for normal computer work and then I use my Maestro to do all the audio work on SmartLink. In fact, my SoftEther PI that was on the Maestro died about November last year and I never rebuilt it as I went to SmartLink for 100% of my usage.
The benefit was that I only had 1 computer to keep updated and it was very very easy to use my remote from anywhere in the world from a PC, MAC or even an iPad. Just RDP to the local PC using what ever RDP solution you like.
A side benefit was that it was also easy to lend my station to a few friends and they didn't have to worry about configuring anything. This is how I contest as well. N1MM runs on the local PC and this keeps more streaming data off the internet.
I also run WSJTx for 6M work on the local PC and no chance of any audio stream corruption or latency due to the internet part, something I can't control (bad internet).
What drove me down this path was my 1mb/sec upload and everything that got streamed out got measured. Internet upstream had to go on a diet.
It was by far the best remote setup ever and I physically don't see my remote station for months at a time.
Is it 100% perfect? No. But, given the tools we have available, I am very happy with it.
Mike
I don't think SmarkLink will route properly because my home and remote station network are on the same /16 network (mask 255.255.0.0). I may be able to change that and use NAT at the remote site instead of bridging as I am now with the VPN.
Sure would be easier/better if V3 was compatible with V2 in this regard.
I have web interfaces for my rotator, my antenna switch, and my amplifier. I do not wish to expose these devices to the Internet. Using a VPN they simply appear as web interfaces on my LAN, and only on my LAN. So does the Flex. There is only one port to forward (to the RasPi running the VPN) and no PC to worry about.
I think it was a poor decision on the part of Flex to quietly make a change that could allow existing connections on 2.4.9 to fail (or perform poorly) on 3.x. I don't need MultiFlex capability, but it's generally nice to be on the latest code base, and my plan was to upgrade to 3.x after it had been out for a while. That is no longer my plan.
73,
Doug K4DSP
If the Official Response and final answer is tough luck, I'm supposed to be using SmartLink instead of my own VPN and engineering knows best by permanently disabling compression on LAN users, and what used to work in 2.x will not be properly resolved in 3.x, that's fine. Consider this my refund request for the $400 worth of upgrade fees on my two 6000-series radios.
Having said all of that, we do recognize that there are a number of situations where it would be preferable to have control of whether the audio is compressed or not. Even some Wifi setups will perform better with the lower bandwidth of our compressed audio. As such, we will likely go back to defaulting to compressed audio even when on LAN with perhaps an option to make it uncompressed for those that prefer the full bandwidth. For tracking purposes, this is #7472.
I feel compelled to mention that the recommended way to connect to a FLEX-6x00 remotely for most customers is via SmartLink. If you have the technical chops for running a VPN or the ability to manage a more complex network, more power to you.
73, Cédric HB9HFN
Cal/N3CAL
The VPN and compression is still on engineering's radar as Eric mentioned above.
Cal/N3CAL
Is there a supported SmartLink approach to control a Green Heron rotator, an AntennaGenius switch or an Alpha amp? Asking for a friend... A serial pass-through CAT mode would be a big help along with a local agent for the AG.
Short story, no.
The story that I presented at Dayton Forum on Sunday was to have a small Windows PC local to the radio that you do an RDP session to to run all those applications.
Personally I think this is about the easiest idea today as you are not then dependent on a vendor at all and you then have full control of your station. Once I get caught up on sleep, I'll record my presentation on why I think this works so well and allows the operator to easily scale their remote operation.
Mike