Добро пожаловать, Гость
Логин: Пароль: Запомнить меня
In this category, you can discuss questions related to the new Expert Remote System (ERS) based on ExpertSDR3.

ТЕМА: My Experience Remote Testing SunSDR2 DX

My Experience Remote Testing SunSDR2 DX 11 Дек 2022 13:15 #1

  • G8NOF
  • G8NOF аватар
  • Вне сайта
  • Сообщений: 9
  • Спасибо получено: 6
SunSDR2 DX Firmware: Latest Firmware
Server Software: Server (Starter) for Expert Remote System, build 20221028
Client Software: ExpertSDR3 1.0.1 Beta (latest build)
Server PC: i7 16G Ram 250G HD latest version W10
Client PC: i7 16G Ram 250G HD latest version W10
Server Network: SunSDR2 DX radio sits on a Cat6 Gigabit Network
Server Internet Connection: 70MB down link 20MB uplink
Client Network: Client PC sits on Cat6 Gigabit Network
Client Internet Connection: 220MB downlink 200MB uplink
Server Location: Central England
Client Location: Eastern Spain
N.B. I have remote access from the Client PC to my Server PC by the following options:-
1. Team Viewer
2. Any Desk
3. Windows Remote Desktop (the best)
I mention later the importance of having this remote access to the Server PC.
Establishing the connection to the remote Transceiver
N.B. you must follow al the instruction given here first eesdr.com/images/software/ESDR3/ERS_ENG.pdf
Using Windows Remote Desktop I ran the Starter application on the server PC (UK), ensuring in the DOS window I could see a connection and the serial number of my radio was shown.
I then ran the client software (Spain), ensuring that in the EESDR control panel (second button) all the server login information was entered and I had a successful connection to the server. My remote radio was then shown listed in the Control Panel left window as being on the EESDR cloud. I hit the start button in the left window next to the radio and the software started. The view is the same as if you were next to the radio itself. I hit the power button and the radio came to life. I had full received capabilities on the antennas connected to the remote radio, using the client PC audio output. The look and feel is as thought you were local with what appeared to be no latency.
In order to transmit I needed to use the Client PC, line or Mic input and select this in the Expert3 software status bar. I needed to restart the software once I had connected the line or Mic to the PC, this enable the software to pick up the PC audio connection. I also used the TX button on the client software in order to ‘key up’. I needed to adjust the audio level in the Client PC and or the PC Mic level in the Expert3 Software (top right) to achieve correct Mic level as shown on the new ‘S meter’ .
The first thing I noticed was the level of Latency on the TX audio as seen on the client software (by looking at the spectrum of transmit modulation). You can still see your modulation for about 2-3 seconds after you stop talking, if you 'un key' too soon the distant end loose the last 2-3 seconds of your QSO. I noted this and did not 'un key' until I could see the end of modulation on the spectrum.
Once I perfected the above the distant end did not know I was remote. I had many flawless QSO, s.
However there were one or two with some packet loss which was strange as the data rate as shown on the client software was way below my internet capabilities at the server and client end.
I also noticed that during receive if I was to use the Client PC to also lookup a call from QRZ there was some packet loss, this could be down my PC.
All in all I was impressed - for Beta software.
However if I did not have the capabilities to remotely access the Sever PC from the client PC this would be a problem. The connection from the Server PC to the EESDRcloud is not stable. It seems fine when you first connect and use for say 1 hour but if you come back the next day the connection is lost! Imagine if you had no remote access to restart the server software. You go away from the server location having connected to the EESDR cloud, and then arrive at the client end (in my case 1000miles away) not confident that server software is still running! I think this is a problem with the stability of the EESDR cloud service. When it works its fine but it must be stable in order to be confident that it will work for you, PARTICULARY if you have no remote access to your client PC running the server software, such that it can be reset if necessary.
I hope someone will find my experiences useful.
I sincerely hope that Expert Electronics can perfect this method of working remotely as being a cloud service it negates many problems and complexities of the past i.e. Port Forwarding and or VPN’s.
But the cloud service must be impeccable.

Glenn Holt
G8NOF
Администратор запретил публиковать записи гостям.
Спасибо сказали: Rome, VK6NX, NTZANIS

My Experience Remote Testing SunSDR2 DX 11 Дек 2022 20:38 #2

  • VK6NX
  • VK6NX аватар
  • Вне сайта
  • Сообщений: 249
  • Спасибо получено: 197
Given the described setup (remote desktop), the experienced latency is perfectly within expected timing boundaries.
Администратор запретил публиковать записи гостям.

My Experience Remote Testing SunSDR2 DX 12 Дек 2022 10:47 #3

  • G8NOF
  • G8NOF аватар
  • Вне сайта
  • Сообщений: 9
  • Спасибо получено: 6
I am not using the 'remote desktop' to drive the radio it is only so that i can re-start the server software at the server end should it crash (see other post on server crashes).
Администратор запретил публиковать записи гостям.

My Experience Remote Testing SunSDR2 DX 12 Дек 2022 12:30 #4

  • Rome
  • Rome аватар
  • Вне сайта
  • Quod Licet Jovi Non Licet Bovi
  • Сообщений: 291
  • Спасибо получено: 140
Hello Glen.
Thank you for sharing your setup and overall experience of using the ERS.
A bit of info (which I published on our Forum before) about ERS for better understanding:
Server software connects to the Cloud as a client, the same applies for ESDR3 client instance, it also connects to the Cloud as a client. Server and Client handshake in the Cloud and establish a peer-to-peer connection for best performance. In cases if peer-to-peer connection cannot be established connection goes through the Cloud, it has a certain lag, obviously.
You don't have to open certain ports for Server and Client, they operate as outgoing connections, not incoming. Server-Cloud-Client exchange all required info with each other, such as IP, UUID, etc. automatically, there is no need to manually enter anything.


At this point 2-3 seconds delay is normal, we even have a ticket about it on GitHub, so this information is definitely noted, and we plan to work on it - github.com/ExpertSDR3/ExpertSDR3-REMOTE-SYSTEM/issues/8
Роман, Roman
Expert Electronics
Администратор запретил публиковать записи гостям.

My Experience Remote Testing SunSDR2 DX 12 Дек 2022 21:16 #5

  • w7rhremote
  • w7rhremote аватар
  • Вне сайта
  • Сообщений: 19
  • Спасибо получено: 5
Ditto
Администратор запретил публиковать записи гостям.

My Experience Remote Testing SunSDR2 DX 13 Дек 2022 00:50 #6

  • w7rhremote
  • w7rhremote аватар
  • Вне сайта
  • Сообщений: 19
  • Спасибо получено: 5
My setup is almost the same hardware and software wise. The exception is my network is using Starlink as there are no other options for my very remote setup.
I primarily operate CW and have not been able to try it via the remote cloud server. I do however through magic networking have a dedicated IP on the client side that resides on the remote server network. Using SSTP and EOIP and a pair of Milrotik RB2011 routers have full access to all clients from either end of the network which comprises 4 different Subnets. The catch 22 is I've run out of Router CPU seed and will need to upgrade to much faster multi core routers.

My Observations as follow:
LAN audio is superior over the remote cloud audio via line out. Using the cloud the audio has notable distortion and the AGC control is a contributing factor. It sounds like the stream is way over driven.

Remote Cloud operation has a buffer adjustment. LAN operation does not. It should be incorporated to be operable on both remote Cloud and LAN.

At this point I believe if operating via Cloud local interfaces do not work. I assume the server application thinks everything should be on the client side. In many cases it can not. CW for instance is difficult across the Internet. I use WinkeyRemote and of course N1MM for contesting which are at the remote site for perfect CW.

The same would apply to JTDX due to timing requirements.

From my home ping time to Cloud is 200ms. From the client side using Starlink it is ~225ms. However if there is a break in communications it can take 500ms or more to establish flow again.

Bob W7RH
Администратор запретил публиковать записи гостям.
Спасибо сказали: Rome

My Experience Remote Testing SunSDR2 DX 13 Дек 2022 03:56 #7

  • VK6NX
  • VK6NX аватар
  • Вне сайта
  • Сообщений: 249
  • Спасибо получено: 197
IMHO you, guys, have to adjust you estimations in regards to Remote.

The fact is: WAN (SunSDR Remote in this instance) will never ever work on same "quality", as LAN. Just FYI: the LAN latency for SunSDR traffic should be not exceeding 30ms. Remote latency - not sure, we have to check the current threshold with EE (certainly bigger, however, theoretically, should not exceed 200ms).

Dependent on a WAN topology you can get better or worse results. For example "better" has bigger chance to occure, if WAN between Client and Remote runs over single provider. On opposite: multi-provider WAN between Client and Remote should be expected to produce worse results. However, whatever WAN setup ("worse" or "better") - there is still the fact (above).

There are simple and well described reasons "why", and most of them belong to QoS area. To understand the reasons, the "partial equality" of SunSDR stream to common voice stream can be used. The obvious contributing factors are:

- WAN packets classification and marking (*);
- QoS queuing mechanism (*);
- Fragmentation and Interleaving (**);
- traffic shaping (*);
- DiffServ (*) (***);


(* can be, and most likely is, sufficiently different within eash separate provider network)
(** in absolute majority of cases settings are same or close within eash separate provider network, but the contributing factors are serialization delays and link speeds)
(*** DiffServ might be set to prioritise IP RTP streams, which means non-marked UDP/WebRTC streams of SunSDR will be subject to queuing).


What are the possible ways around?
Option 1: try to "mask" SunSDR traffic such way, so it looks as legitimate subject to set QoS and DiffServ -> this will make routers on provider's boundaries to mark and prioritize SunSDR traffic accordingly (however there is no absolute guarrantee). And this is that EE in already working on, implemeting protocols like WebRTC and creating specific applications with adjusted latency settings (well above 30ms)
Option 2: implement compression mechanisms. This is common way in "voice over" world, but very questionable in the case of SunSDR raffic flow.

Anyway, given the above and accepting the fact that ESDR Remote is still in development, IMHO, adjusting your estimations might be reasonable :)
Последнее редактирование: 13 Дек 2022 03:57 от VK6NX.
Администратор запретил публиковать записи гостям.
Спасибо сказали: Rome

My Experience Remote Testing SunSDR2 DX 13 Дек 2022 09:22 #8

  • G8NOF
  • G8NOF аватар
  • Вне сайта
  • Сообщений: 9
  • Спасибо получено: 6
Hi all and thanks to Roman and others for the feedback.
In respect of adjusting expectations in regards of remote working, expectations have already been set, EE have launched a service.
I understand it is in its infancy. I and others wanted to use this forum to feedback our findings such that the service hopefully will end up meeting all our expectations.
Regards
Glenn
Администратор запретил публиковать записи гостям.
Спасибо сказали: Rome, VK6NX

My Experience Remote Testing SunSDR2 DX 13 Дек 2022 15:36 #9

  • w7rhremote
  • w7rhremote аватар
  • Вне сайта
  • Сообщений: 19
  • Спасибо получено: 5
Gentlemen,
Don't get me wrong. The SDR2DX is a fabulous radio when operated on the LAN.

As in Glenn's case I have a very established redundant network to my remote site which has been in operation for 17 years. Starlink is not perfect but at 99% level these days. It meets all the requirements that I need, all modes, correct timing and solid reliability. It was painful to set up. My remote is 250 miles away and seasonal weather makes it difficult to get to on a day by day basis. This is all done for a low noise environment.

There are far more questions to be asked than answered especially with remote operation and it's limitations using a SDR2DX as primary rig. From my point of view my crystal ball does not give any clear direction the remote server application will take and whether or not it will ultimately work properly in my opinion. There are things I like and many which leave a lot to be desired and as stated in a few comments in the forum it is what it is take it or leave it. It should not be a marketing point of this fine radio.

With that stated I have the ultimate solution. My existing transceiver has a RX only antenna port. By the addition of a ColibriNANO using E.Sync nearly all the issues discussed here are solved. Similar in specifications all that would be required is a audio mixer with with adjustable delay. I call it the Best of Both Worlds solution. Now if I could only find one!
Вложения:
Администратор запретил публиковать записи гостям.
Спасибо сказали: Rome

My Experience Remote Testing SunSDR2 DX 14 Дек 2022 01:52 #10

  • VK6NX
  • VK6NX аватар
  • Вне сайта
  • Сообщений: 249
  • Спасибо получено: 197
G8NOF пишет:
I and others wanted to use this forum to feedback our findings such that the service hopefully will end up meeting all our expectations.

Glenn - and this (above) is absolutely correct and nothing wrong with it. The feedback is needed and it will certainly help, hence - it is really appreciated.

The only meaning of "setting expectations" was to deliver the message: there are purely technical limitations for "over WAN comminication" (in comparison with "LAN communication"). The adjustments to protocols, the enhancements for latency compensations - all that EE will do over time. However EE will not be able to fix provider's WAN routing or equal path traffic flow between your remote and local sites - and it is only better if everyone understands it from the beginning and while setting up for further the tests.

To squeeze the maximum from Remote feature is still the target. Will be this "maximum" enough for all modes and activities - that is another question.
Последнее редактирование: 14 Дек 2022 01:52 от VK6NX.
Администратор запретил публиковать записи гостям.
Спасибо сказали: Rome, w7rhremote

My Experience Remote Testing SunSDR2 DX 14 Дек 2022 03:36 #11

  • w7rhremote
  • w7rhremote аватар
  • Вне сайта
  • Сообщений: 19
  • Спасибо получено: 5
Pavel,
I can not disagree with you at all on the Internet. We've had a conversation in the past about Starlink. Well I have it working very well now and it just works. There all multitudes of issues across the Internet that we as users do not have any control. Things like protocol blocking become huge issues when you are looking to send reliable data streams in TCP and UDP. Starlink actually blocks several popular tunnels. I have yet to determine where. It could be the Google back haul. Bumps in the Highway.

Now IPV6 is being introduced. Makes one ask what next? LOL
thanks
Bob W7RH
Администратор запретил публиковать записи гостям.

My Experience Remote Testing SunSDR2 DX 14 Дек 2022 07:33 #12

  • VK6NX
  • VK6NX аватар
  • Вне сайта
  • Сообщений: 249
  • Спасибо получено: 197
Yeah, Starlink did upgrade since we had a chat.

At least in our region they now offer IPv4 static, IPv6, coverage outside fix area (this last one makes it interesting for local IOTA DXpeditions and working /MM).

But AU Starlink still not good in terms of our Remote ... My roundtrip to EE's Remote Server is about 400ms, which makes Starlink's WAN not suitable in proxi mode. Also at this time Starlink has only one landing point in Sydney - this automatically means that guys, say, in Western Australia will either have to use two Starlink units (local-remote) or it will be crap (if one site is connected to common wire/optical WAN).

In terms of tunnels... yes, Starlink loves to take control over your traffic. Nothing wrong with it, TBH ... if I would admin it, I would probably do the same. Anyway, I am not a big fan of VPN when it comes to real-time communications, as VPN automatically means overhead on multiple things.
Последнее редактирование: 14 Дек 2022 07:38 от VK6NX.
Администратор запретил публиковать записи гостям.
Время создания страницы: 0.173 секунд