All times are UTC+01:00




Post new topic  Reply to topic  [ 8 posts ] 
Author Message
PostPosted: Wed May 08, 2024 10:05 pm 

Joined: Sun Jan 07, 2024 7:36 pm
Posts: 11
Hi,

We are testing MicroMPX at our FM transmitter site. Currently we have no other way than using a 4G modem. We built a VPN over it to the studio, and most of the time MicroMPX is running fine.
I have set the errorcorrection to 96/48 and a delay of 14 seconds to get a high level of correction. I also configured QoS on both networks (ST source and transmitter site) but we still get dropouts.
Every 1 or 2 hours MIcroMPX complains about 10-20s no packets. Is there some way to get the buffer high enough to get through this? It doesn't matter for us if the delay on the transmitter is 30-60s.

We also see shorter drops, and everytime we lose audio. Isn't it possible to let MicroMPX buffer more?

We use a 320k MP3 stream that's onair now through a DB Deva box, and that does not have the issue of dropping out.


Top
   
PostPosted: Thu May 09, 2024 6:53 pm 

Joined: Mon Dec 30, 2019 12:34 pm
Posts: 18
Let's think differently for a moment. What VPN are you using? When fiber to one of our transmitter sites was cut, we ran Wireguard over 4G and 32 recovery packets for each 32 packets (basically sending everything twice) on 5 seconds of delay, that worked like a charm.


Top
   
PostPosted: Tue May 21, 2024 10:23 pm 

Joined: Sun Jan 07, 2024 7:36 pm
Posts: 11
Great that it worked for you, but I have tried serveral VPN solutions now, and it still isn't stable. Tried VPN through the routers on both sites (IPSEC), and I recently built a Wireguard VPN directly between the Stereotool MicroMPX encoder (Windows 10) and decoder (Raspberry Pi), and we still have silences because of packets missing, or packets coming too late. Also getting errors of incoming packets are too slow / fast.

Isn't there a posibility to make this transport more reliable? It probably works great on stable links, but even with the 96/48 setting, it just isn't.
I will try 32/32, but this doubles the 320k bandwith right?


Top
   
PostPosted: Tue May 21, 2024 10:34 pm 

Joined: Mon Dec 30, 2019 12:34 pm
Posts: 18
Yeah. Sending everything twice was the only way we got it stable.


Top
   
PostPosted: Mon Jun 10, 2024 6:28 pm 
User avatar

Joined: Mon Nov 30, 2015 5:05 pm
Posts: 25
Hi Peter, had the same issue here. Worked flawlessly untill roughly the end of 2022. Something happened after that, because this issue occurred at our side too. After testing it out with two different providers, even in line of sight with the 4G tower, I got issues just like you describe. It can run without buffering for 20 minutes, sometimes 30, sometimes more than an hour, but after that random buffers of up to 20/30 seconds, but most of the times less. Tried several VPN configurations (TCP or UDP), but nothing seemed to resolve the issue. The providers cannot see the type of data, so they must be limiting on the raw amount of data your using. On the other hand I would expect some more continuity in the behavior, speedtests also show no limit in the amount of speed thats available.


Top
   
PostPosted: Mon Jun 10, 2024 6:47 pm 
Site Admin
User avatar

Joined: Mon Mar 17, 2008 1:40 am
Posts: 11389
Strange. We do send UDP packets, so providers *can* drop those. But if anything the newer versions should be more stable, not less.

A few things:
  • 96/48 will handle dropouts up to about 300 ms. It doesn't help to increase the buffer size more, that won't be fixed. For maximum correction you can use 128/127 to fix dropouts up to 700 ms or so, but given the description that won't help either.
  • What you report seems to indicate that the whole connection disappears for 20-30 seconds. We send keyframes regularly. The newer builds use 0.5 seconds by default, which means that on average a dropout would be half of that, so 0.25 seconds. If your setting is higher you can reduce it, but it will only make the dropouts a bit shorter, not fix them.
  • You're using a VPN; VPN's will wrap our UDP packets. They might send them as UDP or as TCP, and, importantly, they might not include the QoS settings in that.
  • Based on your names and email addresses I'm guessing that you're both in the Netherlands. Not sure if this matters but maybe it does, there might be similarities in the network infrastucture. You're also both using 4G, are you using the same VPN? Maybe that VPN had an update that changed something.

Do you know if the DEVA uses TCP or UDP? Was that going through the VPN as well?


Top
   
PostPosted: Mon Jul 22, 2024 3:52 pm 

Joined: Sun Mar 14, 2021 10:43 am
Posts: 46
We are running our infill site on 4G at the moment while the normal ADSL connection has an intermittent fault - I know from experience it takes Openreach months to solve these sorts of problems. Like you we run it over a VPN (Tailscale - free)

It runs really solid - maybe the odd dropout of few seconds every few days - but they tend to be in the early hours of the morning when no one is listening anyway.

Big question in my mind is how good is your 4G signal? We are using a Microtik outdoor 4G router to try and maximise signal. The way 4G (and 5G) works, the better you can make the radio conditions of the cellular link the more reliable signal you will get (ie not only peak throughput, but enhanced reliability). This is because the scheduler in the base station recognises how good your link is and thus schedules you more often because you are less "taxing" than users in poorer radio environments - you essentially get an "unfair advantage" over everyone else, even if the cell site is congested! Ideally you want to get 5 bar +++ coverage so that you can use the highest possible modulation scheme on the cellular link (that said we only have 3-4 bars!). It also helps if your 4G modem equipment is a "high category" which means it has the higher modulation schemes and tricks to improve throughputs. Cat 3 is the lowest you can get, Cat 6 is ancient, something like Cat 12 or above is where to aim. If you get a 5G device it is likely to have higher 4G category by default. I'm waiting for our ZTE MC7010 to arrive which looks like it should be about the best you can possibly buy! https://www.amazon.co.uk/Outdoor-Router ... S22GF?th=1


Top
   
PostPosted: Thu Oct 17, 2024 1:00 pm 

Joined: Mon Dec 30, 2019 12:34 pm
Posts: 18
So due to the installation of fiber being delayed we are running a new site on 4G for a few weeks now. We have real world experience now. Thought it might be worth sharing.

There was a weird disconnect happening every day. It seemed to be after a rolling window of 24 hours. The provider we use, Odido (formerly T-Mobile Netherlands), doesn't allow 4G sessions longer than 24 hours. So we just set-up the modem to reconnect every night at 3AM. That way we have control over it.

With an outdoor 'puck' antenna and a cheap TP-Link modem MicroMPX over WireGuard seems to be pretty stable. Besides the nightly connection drop we don't see much drops. Recovery packages are being used a couple of times per day but that doesn't cause dropouts. The latency of the connection sometimes goes from 40msec to 80msec but MicroMPX seems to be able to handle that. No packets too late.

This is the Smokeping graph for the site. Confirming it's stability. MicroMPX doesn't seem to be fundamentally incompatible with 4G or WireGuard.

Image

If you're experiencing problems it might be worth putting Smokeping on an intensive monitoring scheme for the link itself.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 8 posts ] 

All times are UTC+01:00


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited