WAN Remote v.2.0 good enough?

  • 1
  • Question
  • Updated 4 years ago
First of all I would like to thank several of you who have answered my Q:s about remoting. In particaular KY6LA who has shared his experience of iPAD remoting all over the world. Just great!
I am an avid remote DX-er now also doing remote contesting. Three towers, rotor controllers, RTTY etc performed over remoterig and legacy radios. It works 100 % well and very reliable. Now even with a Android laptop at home far from radio QTH but unforrtunately only in RX-mode (full TRX not yet available). And it works with 400 kbps uplink (from radio side) from DSL. Now 4G with about 4 Mbs uplink bandwidth in additin to that (IP-cameras, SO2R....) makes life a party I did not think of 5 years ago.
Howevere, recently I came aware of the SDR v.1.4 and LAN remoting. With a FSR 6700 at top of the Sherwood tests even more drew my attention. Adding to that FSR concept of "thin client" and no local PC made the FSR concept a strong candidate for future ham radio from wherever you may be during the day - shopping mall, TV, work etc. I am convinced that this is the right road.
I have followed the "Remote VPN" threads (e g KY6LA:s latest)and sorry to say I start to wonder whether V.2.0 with WAN Remote will be able to achieve what "legacy remoting" already today achieve.
My conclusion was though (and someone even went further and said "then with V 2.0 I will never be able to do WAN remote...since the uplink is not more than 1 Mbps) that the thin client must be made "thick" to allow DAX trafffic (digital modes etc) and PAN adapters etc unless the DAX is considerable compressed in it's data stream bandwidth requirements. Hence, I feel somewhat disappointed over the future outlook of V.2.and WAN with respect to modest data uplink bandwidths.
What are your views on this? I really hope I am wrong in these predictions since I really believe the path FSR now is taking with 6000 series is the right one. Of course in long term we will for sure be there but it would be nice if this could happen before I retire (still 10 years to go :)).
Looking forward to a discussion on the subject - with FSR officials "listening",
Best regards,
Kari SM0HRP (www.sm0hrp)
Photo of Kari Gustafsson SM0HRP

Kari Gustafsson SM0HRP, Elmer

  • 235 Posts
  • 20 Reply Likes

Posted 4 years ago

  • 1
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 643 Reply Likes
Kari, A couple of things. I think WAN remoting is problematic regardless of Flex vs what people do with their non FRS. If you have a slow link to your radio's location, no amount of software will cure a slow link. That said, look at RemoteHamRadio, not as an alternative just a web based kind of cool solution. That works fine, again, assuming reliable network speeds. But, would a slow network negate the cool effect of the panafall? Maybe, maybe not. But could it, sure. I think, generally, at this point in time the wired world is pretty well wired. One of the things that made offshoring so doable was the vast overcapacity of fiber laid between the states and EU, India, Asia etc. Last I knew Stu's iPad did not do panafall, that may well have changed. But the rhetorical question I am leading up to is this, do you need a fast panafall (bandscope + waterfall) to be happy when remoting? Or do you just need to be able to hear the remote station. Without knowing the quality of your link between you and your rig, I don't see that anyone can give you assurances. If you are pretty much certain you'll be on a predictably fast network, I suspect the difference between WAN remoting on 1.4 and WAN remoting on 2.0 is largely dependent on what sorts of other things FRS puts into 2.0. One could make an argument that the bandscope and waterfall should both be optionally selectable. In the LAN environmoent from your shack to your back yard shed, that is less of an issue.

I am sure FRS will maintain the high level of performance we all have come to expect from them. Yeah, there could be network conditions that are not well suited for the bandwidth requirements of SSDR today. Since the tcp/ip connections terminate in SSDR, not asking for the panafall will immediately reduce network traffic. However if there is no data lag or dead zones (dropped UDP packets, then all is good.

About that Android....stay tuned.
Photo of Kari Gustafsson SM0HRP

Kari Gustafsson SM0HRP, Elmer

  • 235 Posts
  • 20 Reply Likes
Walt, interesting thoughts.As I understand quite a few already today use the Panafall with their FRS even on 3G networks. I assume they adjuste the update speeds with this limited bandwidth. Then on the other hand several seem to use VPN with higher bandwidths. But if we then add DAX streams for digital modes I assume bandwidth needs would sky rocket. 
So what I am trying to say is that it is difficult to judge the potential of the system concept even as it is today and where it will be in V.2.0 without any saying from Flex. As many have witnessed already on the forum a large majority of WAN users will be in the 2-5 Mbps perhaps up tothe 7 Mbps uplink area. What implications will this have for the V2.0 would be very intersting to know more about. In the "remote rig WAN legacy domain" 5-7 Mbs is already way over what many today have as I understand. I use today 0,5 Mbs with remote rig (dual receivers) and I could easily absorb 2-3 Mbs for panafalls and compressed DAX streams. And then we are close to the "thin clien" non PC-system approach. But is Flex there with V.2.0? I really hope so. 73s Kari SM0HRP  
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1031 Posts
  • 1002 Reply Likes
Couple of brief points: first, we never felt like supporting DAX over a WAN was the "right" way to do something.  Take RTTY for example.  The important data is simply text flowing at a negligible rate.  It just doesn't make sense to send 1.5Mbps of samples to decode or encode 2kbps of actual useful data.  So over time I would like to see us add digital mode encode/decode on the radio side so that we are not transporting digital samples across the WAN.  There will be some situations where this will not be the answer.  For example, a new digital mode in rapid development by a small group is not likely to be quickly assimilated in the radio.  And the short-term answer will probably be that you have to run a mode like this locally or use another means to run it remote.  The longer-term answer is faster networks.  Network speeds will continue to increase as the years pass.

Second, today we have a lot of control over the bandwidth that you send to the client.  This will probably get even better with time and may have automatic component. See my reply in this post for more details:

Photo of Bill -VA3WTB

Bill -VA3WTB

  • 3000 Posts
  • 660 Reply Likes
Photo of Robert -- N5IKD

Robert -- N5IKD, Elmer

  • 488 Posts
  • 152 Reply Likes
For the data going across the network, it seems that the 16-bit number for the Panadapter and for the waterfall would be the same number. The only difference would be that the number is either rendered into the Panadapter or rendered and stored for the waterfall. This would cut the network load significantly.

The only drawback would be that averaging the Panadapter would affect the waterfall proportionally. Maybe connecting these could be an option for cases where bandwidth is at a premium.
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1031 Posts
  • 1002 Reply Likes
When we started, we used the same data for both.  As time moved forward, we found there are important reasons, including decoupling the controls, that made having different sources of data important.  So we moved to separate data sources in v1.4.
Photo of Kari Gustafsson SM0HRP

Kari Gustafsson SM0HRP, Elmer

  • 235 Posts
  • 20 Reply Likes
Steve OK things start to get clearer. So if I have understood all this (sorry still not a flex user) you may vary the panadpter and waterfall considerable with frame rates to lower the bandwidth usage and for modes like RTTY this would be mostly done by the client software (like MTTY today). Following your data this would lead to managable bandwidth needs (say less than 1,5 mbs) but with lower frame speeds. Which is quite acceptable on WAN. Remote.
However, another thing which is equally inportant and that is station integration. Today I understand most folks use DDutil to connect various Amps, rotors, power meters etc. to the Flex radio. And to produce the banddata. Is this functionality something you may include in the SDR software?
I understand using VPN allows us to get WAN like remoting even now. However, even if I do know networking pretty well I am reluctant to put the time in testing whether my 4G router (Cradlepoint) even would allow me to do it. Poor manuals etc makes it problematic. For sure nothing for the average ham to even consider as an alternative.
Businesswise for Flex I would highly recommend a clear tech road map for the SDR software. This would improve the return of the investment as more people (like me) would sooner start to get aquainted with the "future" way of thin client non PC way of ham radio operating from wherever you may be. My feeling is that you at Flex are close to getting it right even for us "advanced Legacy radio remoters". Make your vision a reality in v.2.0!
Photo of Al / NN4ZZ

Al / NN4ZZ

  • 1730 Posts
  • 590 Reply Likes
Hi Kari,
Regarding the station integration, here is a thread that discusses it and various options.   It sounds like it will be eventually implemented and logically once we get WAN remote with V2.0 it will become more important.    At some point it will be needed to realize the goal of "no local PC needed."


Regards, Al / NN4ZZ  
al (at) nn4zz (dot) com