I think you have lost the context of that post/discussion.

So to stabilize the discussion with less emotions.

I was referring to INTERNET connection, not LAN not even a 300km long dark fiber... INTERNET... Right? So few unknown operators between the path etc.

The network delay itself is something you cannot really compensate you just need to live with it.

The only thing you can compensate is JITTER and you do that by creating a buffer (in other words increasing the delay).

So again that 300% percentage is not that really important (but looks bad and big) as for sure we are talking about BUFFERS of around 200 ms. Maybe 500ms. Which are used for safety purposes (to have continuous stream of data).

So in that scope, INTERNET (unknown and unstable by design) with jitter of 2-3 msec is LOW JITTER.

And the point is that delay in EESDR3 is on level of ~1-2 seconds.

Dont loose the context please. If I would start the topic in scope of LAN or dark fiber (or similiar) - I take your arguments.

sq6emm wrote: You must be absolutely right. I have a valid excuse, though.

sq6emm wrote: Sorry to disturb your emotions, really did not mean it.

sq6emm wrote: That is really interesting statement. I did not know about that. (I promise, I will google it before I will be asking more stupid questions)

Just before I start googling, if I may, of course?

1. When saying that 300% variation (qoute) "is not that really important", what exactly buffer you suggesting to create to compensate the difference in delay between - say, two - UDP packets? Would it be the same (as above) buffer, to compensate the same (above) difference of, say, five UDP packets, with applied out of sequence arrival of two random packets (out of five)?

2. And could you, please, describe your expectations of the output ESDR3's sound (SSB) while having the 200ms of buffer (BTW, not sure - are you suggesting 200ms of L3/4 buffer or 200ms L5->above buffer)?

3. And what is about your expectations of the CW output with the same (2. above) buffer?

4. And, one more question, if I may, please. How exactly your (proposed) 200ms buffer complies with the information, provided by Roman in his post #2 of this thread?

5. And... sorry... I have so many questions... One more, perhaps? Thank you. As per your expectation, what mode would be more jitter-sensitive: CW or SSB. This is because your post #4 (quote) "CW could be SSB alternative".

6. And the last one. What was it really mean, when you have said (quote) "2.308 ms + 0.732 ms = ~ 3 ms"?

Thank you very much in advance for you answers.

VK6NX wrote:
So maybe before anything else... just to make sure we have common understanding as it looks like the biggest issue here.

Please - if you disagree with my statement - show me how to break the basic laws of nature and compensate the DELAY.

sq6emm wrote: Certainly, my inderstanding is sugnificantly differs from yours. I prefer to bralke nothing, but use valid tools to bypass/override/hack(in good meaning) the scenarios, which other people see "the only one way - to brake".

And, yes, I disagree with your statement, that jitter can be compensated by buffer (only, by the meaning of the context of your initial statement), Actually, buffer is least effective from the options, assiming we are talking ESDR3/ERS here (not Teams). (Hopefully, if you will look at MS Teams/Cisco Teams/Webex/Zoom architecture, you will understand why the comparisson of ESDR3/ERS with "teams-like" solutions is invalid).

Sorry, will not be asking you in exchange to "please show me how"
Completely accept you have no answers

---

Add on: BTW, jitter and delay are not required caps. Just jitter. Just delay.

VK6NX wrote:
It is not I have no answers, the point is it seems pointless - and it seems its not a problem of Yours or mine lack of deep knowledge.
Just seems our communication protocols are different, hi.

But I am fine with it, wish you luck

73;)

sq6emm wrote: Obviously, completely agree. can even define the root cause. It is in your approach of "common end-user", who levels on:
sq6emm wrote: Even being more "advanced user", than "kitchen", the fact you just know words "jitter" and "delay" will not jump you over (by any kind of magic). By all means of best wishes, mate, - open "jitter" definition and read it. Better - expanded definition. Understanding the correlation between jitter and delay will let you understand what you have really seen in yur own captures from your post #6.

And next time when you will decide to compare Teams to ERS, just be ready, that someone may ask you a question like "hold on, are you talking about in-band or out of band audio/video?" And if you not ready to answer that question, the next might be something like "are you comparing Teams with ERS being "MS Teams user", or you actually can architect, design, stage and move to prod MS Teams/Cisco Teams for corporate solution >5-10-50-80K users?". You may guess then, what would be next if your answer will be "user"
sq6emm wrote: Same here and please keep us posted with you next experiments

I have ESDR3 Ver 1.0.3 Beta installed in my SunSDR2 Dx, Build 10022023.
When I attempt to operate remote, I get the remote running, but I have no RF Output in Tune or Tx.
Receive works as it should.
I remember in another previous remote version prior to the Alpha / Beta phase that remote worked quite well.
Is this current lack of RF due to the ongoing updating of software, or have I not checked off a button somewhere?

Running a DELL 7040 i5
Tom W3FRG

, but, can a network novice toss in a comment?

I run W10, SunSDR2 DX, EESDR3 1.0.3 Beta. I have internet via fiber at trx-site and op-site with 100+ Mbit/s each.
At receive only, the remote site software tell me 630 Kbps downstream, 40 bps upstream and ping varying between 70 and 90 ms.
So, data channel vise there should not be any capacity problem.

Emediately after start of the tranceiver, the audio has just about noticable delay, that means it is not annoying me, and when i scroll the mouse wheel to adjust receiver frequency, the audio folows fairly quick.

BUT, after some time of receiving the audio gets more and more lag. After some hour of receiving, the audio lag (or audio delay) is several seconds long and is getting vorse and vorse, very anoying. After scrolling the frequency, it takes several seconds for the audio to folow.

Then, if i activate PTT just for one second, the audio delay in receive is gone.

My thougt of this is:
We know that the remote system must use buffers big enough to overcome jitter in the transfer channel (Internet). But if the software has a malfunction, call it a bug, that makes the buffer size to increase all the time, and never work the buffer down again, then this constantly increase of audio delay will occure. It may also depend om different sample rates in trx-site and op site. If the trx-site generates samples faster than the op-site is playing them back, the buffer will increase, and, it the buffer has a limited size, eventually overflow.

I have experienced this delay phenomena in early attempts of remote control of my station, and i tried different audio transfer methods. I tried PicoPhone, Skype, Teamviewer and other audio transfer solutions, but they relied on pauses in the audio stream, so the receive buffer could be emptied. With constant audio in those solutions, the buffer size expanded constantly over time and the audio got more and more delay. The product i ended up buying, and since then have been using, is Remoterig. It handles the audio buffer without any problem. It just works. But Remoterig does not transfer spectrum, and i wanted to try something new, so now i will try EESDR.

I am quite sure that the development team for EESDR will break down the audio buffer issue sooner or later.

Be nice
73 de SM2SXA

sm2sxa wrote: This effect is known as "serialisation delay", The root causes will vary from network to network.

sm2sxa wrote: and that is because you have reset serialization bucket.

BTW, for those above, talking about "receiving the audio", what we are talkling about is IQ stream encapsulated into "some kind" (webrts, for example) of real-time protocol. Perhaps, that explains.

sm2sxa wrote: I wonder, from where you, guys, have got that "buffer"
Why "buffer"? Why not, say, "ponies" or "batteflies"?

Let me give you an example. Just 6 months ago EE have spent enormous effort to completely re-write CW core. There we've been talking about "reducing 20 ms delay to 3-8 ms'. Some people been sucking EE's brain out, crying that in "3-8 ms" it is "too high" and should not exceed "3-5". And now you are practically proposing to artificially bump up those "3-8 ms" into ""30-80 ms" by introducing the "buffer". And, by the way, you cannot define what exactly buffer it should be.

Just leave it to EE.
It is beta. It literally means "communication protocols, including those used for ERS are still in test/dev phase". In a few months, once some pre-requisite tasks will be completed (for example firmware renovation and some more) - the ERS protocols will be ready and maximum thresholds will be announced.

Well Pavel, i do not think that the buffering happens in the "network". I think it happens in the application, and we need a buffer to be able to playback uninterrupted audio to the listener despite that the sent packets arrive with more or less delay, i.e. jitter from the postman, i.e. internet.

The Remoterig boxes can handle audio transfer with very little delay, and no unwanted delay over time.

Be nice
73 de SM2SXA

Hallo sm2sxa Thank you for the information about Remoterig.
Hälsn. Svante sm6usu

Hello,
I am currently building my remote setup (Sunsdr2 pro, 1.0.4beta). Both sites are connected with 150/30 mbit to the internet. Last week I tried it with receive only and the lag/delay was about 2-4 seconds. After 30mins of running ExpertSDR3, a click on a signal took ~5s to bring up the audio from the newly selected frequency... very odd.

I know a lot of fellows, which are running remote setups with SmartSDR. One of them worked a 48h contest via LTE-iphone connection. There was never a delay more then 0,2-0,3 seconds.
On my site I can run webex in fullhd with high quality audio, without any issues. So I have no idea where the delay of 2-4 s is coming from.
With this lag between expertsdr-server and client, it is better to run SunSDR3 locally and access it via Teamviewer/Anydesk and route the audio through this remote access solutions.

I will finish my complete remote setup (remote ATU, remote antenna switching, remote amp control, etc.) in the next few weeks, I will update here about the results.

73 de Ernst
OE3IDE

oe3ide wrote: Ernst, if you really after finding where the delay come from in your setup, you may have a look at Wireshark is its capabilitires to troupbleshoot RTP-alike streams.

And also note, that using webex (and other similar) is bad example. Do not get yourself caught on it. You may have a look at www.cisco.com/c/en/us/td/docs/solutions/PA/overview/12x/hybpa12x.html and compare if you wish. The key elements making a difference between webex and ESDR3 remote are:
1. Webex cloud is everywhere, practically in every country. Compare with ESDR Remote implementation.
2. QoS (EF, AF43, CS3) packets marking (for webex RTP) are end-to-end, this is part of Cisco's agreement with providers (with few exceptions in some countries). And in ESDR3 (at least at the moment) UDP in use, not RTP.
3. Up/Down scale compensation in webex is present (you can clearly see it in wireshark), however it is "invisible" for end-user due to video/audio inband mechanism. But if you will sit in one room with webex system, running on corp LAN and will simultaneously connect you mobile over LTE, you can see typically 2-3 sec (and sometimes up to 4-5 sec) delay. So, that would be a delay in company of uncomparable size, an army of developers and network engineers onboard and corporate devices configured with all "best recommended" settings - and we still have 2-3 sec delay... in hybrid mode ... with servers everywhere.

Hello,

maybe true about WebEx (and others).

Just tried Sonobus (only for interest):
In parallel I started remote ExpertSDR3 (full bandwith on remote location), one TeamViewer-Session, one Anydesk-Session and made a file-copy (1gb)..
Sonobus: no drops, no big change in delay. Audio delay between the 2 locations is between 22-38ms ....

Audio-delay over TCI is beyond 2s ....

73 de Ernst

My remote-setup is now completed. Just worked some stations via remote.

The "problem" seems to be the tx-audio, it is 2-3s delayed. So if you key the radio ("TX") and transmit, you have to wait 2-3s before unkeying the radio, otherwise the last 2-3s will not be transmitted. Same with VOX.
So the TCI command for unkeying the radio is sent without big delay, but on the tx-audio there is 2-3s delay.

73 de Ernst
OE3IDE