Re: [App_rpt-users] Simulcast buffer value issue
Here's a down and dirty display of overlap with transmitter power, feed line loss, antenna gain, pattern and azimuth figured in. [image: Inline image 1]
Message: 8 Date: Wed, 14 Feb 2018 17:33:50 -0800 From: Tim Sawyer <tisawyer@gmail.com> To: Users of Asterisk app_rpt <app_rpt-users@lists.allstarlink.org> Subject: Re: [App_rpt-users] Simulcast buffer value issue Message-ID: <CAG3ht9t7Unky+Tc0MFTOLg2Z3+pcnoWFM2AyNFKeFcrOeE4cdw@mail. gmail.com> Content-Type: text/plain; charset="utf-8"
11,000 feet! No way that will simulcast well, not at 70 miles.
On Tue, Feb 13, 2018 at 8:10 PM, Jeff Carrier <k0jsc.jeff@gmail.com> wrote:
I really hope to be able to confirm this soon. I've been lazy and our 3 sites are 86 miles, 79 miles and 70 miles (in a triangle). One of the 3 is over 11,000 feet elevation. No matter what we've tried so far you still hear distortion in the overlap area(s) even when 1 site is 20 miles out LoS and the other is around 60 miles out non LoS. Everything is linked on a private uW network with very low latency and basically zero packet loss. The transmitters (GE MIII) run about 1hz freq error with the gpsdo attached.
Sometimes I just wonder if this is just multi-path from the various granite reflectors we have on the front range of Colorado (one of them is Pikes Peak)
de K0JSC
------------------------------
Message: 6 Date: Tue, 13 Feb 2018 20:43:42 +1100 From: Hayden Honeywood <haydenph91@gmail.com> To: app_rpt-users@lists.allstarlink.org Subject: [App_rpt-users] Simulcast buffer value issue Message-ID: <CAC0VLD0-9mc=T8BkvMwx6PqWXqtUXCYY2odbjc2ajjDiVLKSBg@mail.gm ail.com> Content-Type: text/plain; charset="utf-8"
Interesting thoughts Tim... perhaps worth documenting on the wiki? Even though it was just "in theory", what kind of sync error was it? Were we talking microseconds or even more?
I have a receiver on a yagi pointed at a distant simulcasted site. I have noticed on occasion, I can hear the distant simulcasted site start to send audio underneath the carrier of the site that is closest (and strongest to me). The distant site is also the master site, and has the lowest latency, but I'm talking two words worth of audio is send before my other site starts sending audio. Once they are both transmitting, I have not noticed any timing issues (i.e. distortion etc). I'm not sure if this issue was related to what I posted previously about the variable audio delay on unkey.
I'm running app_rpt on a Raspberry Pi using a cut down image we use here in VK.
"When simulcasting the audio from all (non captured) transmitters needs
to
arrive at the receiver with in an acceptable time frame (80 us). The DAC theory was that it didn't start sending audio at correct clock cycle every time. That would cause the audio to be out of sync between RTCMs causing simulcast distortion.
As I said, that was the theory. The new theory is that the external clock source was causing the DAC to trigger inappropriately. I spoke with someone I met here on the list (Kevin I think its was) who is using a different external clock and reports perfect simulcast operations"
...I'm not sure that mailman passed the image. If you're interested I can send it off list. On Thu, Feb 15, 2018 at 11:50 AM, Jeff Carrier <k0jsc.jeff@gmail.com> wrote:
Here's a down and dirty display of overlap with transmitter power, feed line loss, antenna gain, pattern and azimuth figured in.
[image: Inline image 1]
Message: 8 Date: Wed, 14 Feb 2018 17:33:50 -0800 From: Tim Sawyer <tisawyer@gmail.com> To: Users of Asterisk app_rpt <app_rpt-users@lists.allstarlink.org> Subject: Re: [App_rpt-users] Simulcast buffer value issue Message-ID: <CAG3ht9t7Unky+Tc0MFTOLg2Z3+pcnoWFM2AyNFKeFcrOeE4cdw@mail.gm ail.com> Content-Type: text/plain; charset="utf-8"
11,000 feet! No way that will simulcast well, not at 70 miles.
On Tue, Feb 13, 2018 at 8:10 PM, Jeff Carrier <k0jsc.jeff@gmail.com> wrote:
I really hope to be able to confirm this soon. I've been lazy and our 3 sites are 86 miles, 79 miles and 70 miles (in a triangle). One of the 3 is over 11,000 feet elevation. No matter what we've tried so far you still hear distortion in the overlap area(s) even when 1 site is 20 miles out LoS and the other is around 60 miles out non LoS. Everything is linked on a private uW network with very low latency and basically zero packet loss. The transmitters (GE MIII) run about 1hz freq error with the gpsdo attached.
Sometimes I just wonder if this is just multi-path from the various granite reflectors we have on the front range of Colorado (one of them is Pikes Peak)
de K0JSC
------------------------------
Message: 6 Date: Tue, 13 Feb 2018 20:43:42 +1100 From: Hayden Honeywood <haydenph91@gmail.com> To: app_rpt-users@lists.allstarlink.org Subject: [App_rpt-users] Simulcast buffer value issue Message-ID: <CAC0VLD0-9mc=T8BkvMwx6PqWXqtUXCYY2odbjc2ajjDiVLKSBg@mail.gm ail.com> Content-Type: text/plain; charset="utf-8"
Interesting thoughts Tim... perhaps worth documenting on the wiki? Even though it was just "in theory", what kind of sync error was it? Were we talking microseconds or even more?
I have a receiver on a yagi pointed at a distant simulcasted site. I have noticed on occasion, I can hear the distant simulcasted site start to send audio underneath the carrier of the site that is closest (and strongest to me). The distant site is also the master site, and has the lowest latency, but I'm talking two words worth of audio is send before my other site starts sending audio. Once they are both transmitting, I have not noticed any timing issues (i.e. distortion etc). I'm not sure if this issue was related to what I posted previously about the variable audio delay on unkey.
I'm running app_rpt on a Raspberry Pi using a cut down image we use
here
in VK.
"When simulcasting the audio from all (non captured) transmitters needs to arrive at the receiver with in an acceptable time frame (80 us). The DAC theory was that it didn't start sending audio at correct clock cycle every time. That would cause the audio to be out of sync between RTCMs causing simulcast distortion.
As I said, that was the theory. The new theory is that the external clock source was causing the DAC to trigger inappropriately. I spoke with someone I met here on the list (Kevin I think its was) who is using a different external clock and reports perfect simulcast operations"
Posting this again... Jeff, what are using for GPSDO for transmitters and for 9.6MHz injection into RTCM clock? On Thu, Feb 15, 2018 at 10:50 AM Jeff Carrier <k0jsc.jeff@gmail.com> wrote:
Here's a down and dirty display of overlap with transmitter power, feed line loss, antenna gain, pattern and azimuth figured in.
[image: Inline image 1]
Message: 8 Date: Wed, 14 Feb 2018 17:33:50 -0800 From: Tim Sawyer <tisawyer@gmail.com> To: Users of Asterisk app_rpt <app_rpt-users@lists.allstarlink.org> Subject: Re: [App_rpt-users] Simulcast buffer value issue Message-ID: < CAG3ht9t7Unky+Tc0MFTOLg2Z3+pcnoWFM2AyNFKeFcrOeE4cdw@mail.gmail.com> Content-Type: text/plain; charset="utf-8"
11,000 feet! No way that will simulcast well, not at 70 miles.
On Tue, Feb 13, 2018 at 8:10 PM, Jeff Carrier <k0jsc.jeff@gmail.com> wrote:
I really hope to be able to confirm this soon. I've been lazy and our 3 sites are 86 miles, 79 miles and 70 miles (in a triangle). One of the 3 is over 11,000 feet elevation. No matter what we've tried so far you still hear distortion in the overlap area(s) even when 1 site is 20 miles out LoS and the other is around 60 miles out non LoS. Everything is linked on a private uW network with very low latency and basically zero packet loss. The transmitters (GE MIII) run about 1hz freq error with the gpsdo attached.
Sometimes I just wonder if this is just multi-path from the various granite reflectors we have on the front range of Colorado (one of them is Pikes Peak)
de K0JSC
------------------------------
Message: 6 Date: Tue, 13 Feb 2018 20:43:42 +1100 From: Hayden Honeywood <haydenph91@gmail.com> To: app_rpt-users@lists.allstarlink.org Subject: [App_rpt-users] Simulcast buffer value issue Message-ID: <CAC0VLD0-9mc=T8BkvMwx6PqWXqtUXCYY2odbjc2ajjDiVLKSBg@mail.gm ail.com> Content-Type: text/plain; charset="utf-8"
Interesting thoughts Tim... perhaps worth documenting on the wiki? Even though it was just "in theory", what kind of sync error was it? Were we talking microseconds or even more?
I have a receiver on a yagi pointed at a distant simulcasted site. I have noticed on occasion, I can hear the distant simulcasted site start to send audio underneath the carrier of the site that is closest (and strongest to me). The distant site is also the master site, and has the lowest latency, but I'm talking two words worth of audio is send before my other site starts sending audio. Once they are both transmitting, I have not noticed any timing issues (i.e. distortion etc). I'm not sure if this issue was related to what I posted previously about the variable audio delay on unkey.
I'm running app_rpt on a Raspberry Pi using a cut down image we use
here
in VK.
"When simulcasting the audio from all (non captured) transmitters needs to arrive at the receiver with in an acceptable time frame (80 us). The DAC theory was that it didn't start sending audio at correct clock cycle every time. That would cause the audio to be out of sync between RTCMs causing simulcast distortion.
As I said, that was the theory. The new theory is that the external clock source was causing the DAC to trigger inappropriately. I spoke with someone I met here on the list (Kevin I think its was) who is using a different external clock and reports perfect simulcast operations"
A couple thoughts… Launch delay is used to “move” the effect of overlapping transmitters around. Typically we put the overlap region over un-populated areas, or areas which optimized audio isn’t critical. I agree simulcast audio quality will never be good where sites are very high or a lot of multipath exists. Transmitter deviation levels MUST be within 0.2dB for wideband systems, otherwise many issues will arise. You will need to use a monitor receiver and TIMS or O’scope to determine this… Deviation measurements ARE NOT acceptable! Kindest Regards, Kevin Babich | N9IAA Valparaiso, IN 46383 Mobile: 219.406.9707 Cessna 421 Cesssna Conquest I/II Beechcraft King Air 90/200 “…It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat...” -Theodore Roosevelt From: App_rpt-users [mailto:app_rpt-users-bounces@lists.allstarlink.org] On Behalf Of Sam Skolfield Sent: Thursday, February 15, 2018 2:13 PM To: Users of Asterisk app_rpt <app_rpt-users@lists.allstarlink.org> Subject: Re: [App_rpt-users] Simulcast buffer value issue Posting this again... Jeff, what are using for GPSDO for transmitters and for 9.6MHz injection into RTCM clock? On Thu, Feb 15, 2018 at 10:50 AM Jeff Carrier <k0jsc.jeff@gmail.com <mailto:k0jsc.jeff@gmail.com> > wrote: Here's a down and dirty display of overlap with transmitter power, feed line loss, antenna gain, pattern and azimuth figured in. Message: 8 Date: Wed, 14 Feb 2018 17:33:50 -0800 From: Tim Sawyer <tisawyer@gmail.com <mailto:tisawyer@gmail.com> > To: Users of Asterisk app_rpt <app_rpt-users@lists.allstarlink.org <mailto:app_rpt-users@lists.allstarlink.org> > Subject: Re: [App_rpt-users] Simulcast buffer value issue Message-ID: <CAG3ht9t7Unky+Tc0MFTOLg2Z3+pcnoWFM2AyNFKeFcrOeE4cdw@mail.gmail.com <mailto:CAG3ht9t7Unky%2BTc0MFTOLg2Z3%2BpcnoWFM2AyNFKeFcrOeE4cdw@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" 11,000 feet! No way that will simulcast well, not at 70 miles. On Tue, Feb 13, 2018 at 8:10 PM, Jeff Carrier <k0jsc.jeff@gmail.com <mailto:k0jsc.jeff@gmail.com> > wrote:
I really hope to be able to confirm this soon. I've been lazy and our 3 sites are 86 miles, 79 miles and 70 miles (in a triangle). One of the 3 is over 11,000 feet elevation. No matter what we've tried so far you still hear distortion in the overlap area(s) even when 1 site is 20 miles out LoS and the other is around 60 miles out non LoS. Everything is linked on a private uW network with very low latency and basically zero packet loss. The transmitters (GE MIII) run about 1hz freq error with the gpsdo attached.
Sometimes I just wonder if this is just multi-path from the various granite reflectors we have on the front range of Colorado (one of them is Pikes Peak)
de K0JSC
------------------------------
Message: 6 Date: Tue, 13 Feb 2018 20:43:42 +1100 From: Hayden Honeywood <haydenph91@gmail.com <mailto:haydenph91@gmail.com> > To: app_rpt-users@lists.allstarlink.org <mailto:app_rpt-users@lists.allstarlink.org> Subject: [App_rpt-users] Simulcast buffer value issue Message-ID: <CAC0VLD0-9mc=T8BkvMwx6PqWXqtUXCYY2odbjc2ajjDiVLKSBg@mail.gm <mailto:T8BkvMwx6PqWXqtUXCYY2odbjc2ajjDiVLKSBg@mail.gm> ail.com <http://ail.com> > Content-Type: text/plain; charset="utf-8"
Interesting thoughts Tim... perhaps worth documenting on the wiki? Even though it was just "in theory", what kind of sync error was it? Were we talking microseconds or even more?
I have a receiver on a yagi pointed at a distant simulcasted site. I have noticed on occasion, I can hear the distant simulcasted site start to send audio underneath the carrier of the site that is closest (and strongest to me). The distant site is also the master site, and has the lowest latency, but I'm talking two words worth of audio is send before my other site starts sending audio. Once they are both transmitting, I have not noticed any timing issues (i.e. distortion etc). I'm not sure if this issue was related to what I posted previously about the variable audio delay on unkey.
I'm running app_rpt on a Raspberry Pi using a cut down image we use here in VK.
"When simulcasting the audio from all (non captured) transmitters needs to arrive at the receiver with in an acceptable time frame (80 us). The DAC theory was that it didn't start sending audio at correct clock cycle every time. That would cause the audio to be out of sync between RTCMs causing simulcast distortion.
As I said, that was the theory. The new theory is that the external clock source was causing the DAC to trigger inappropriately. I spoke with someone I met here on the list (Kevin I think its was) who is using a different external clock and reports perfect simulcast operations"
There's a better plot that can be done for simulcast with Radio Mobile that even has a input parameter for acceptable delay. Use about 80 microseconds. The default resulting plot is mostly solid black which hides the map. You have to tweak the colors and/or transparency. I'll see if I can find one of my old plots... that was a couple of computers ago. On Thu, Feb 15, 2018 at 10:50 AM, Jeff Carrier <k0jsc.jeff@gmail.com> wrote:
Here's a down and dirty display of overlap with transmitter power, feed line loss, antenna gain, pattern and azimuth figured in.
[image: Inline image 1]
Message: 8 Date: Wed, 14 Feb 2018 17:33:50 -0800 From: Tim Sawyer <tisawyer@gmail.com> To: Users of Asterisk app_rpt <app_rpt-users@lists.allstarlink.org> Subject: Re: [App_rpt-users] Simulcast buffer value issue Message-ID: <CAG3ht9t7Unky+Tc0MFTOLg2Z3+pcnoWFM2AyNFKeFcrOeE4cdw@mail.gm ail.com> Content-Type: text/plain; charset="utf-8"
11,000 feet! No way that will simulcast well, not at 70 miles.
On Tue, Feb 13, 2018 at 8:10 PM, Jeff Carrier <k0jsc.jeff@gmail.com> wrote:
I really hope to be able to confirm this soon. I've been lazy and our 3 sites are 86 miles, 79 miles and 70 miles (in a triangle). One of the 3 is over 11,000 feet elevation. No matter what we've tried so far you still hear distortion in the overlap area(s) even when 1 site is 20 miles out LoS and the other is around 60 miles out non LoS. Everything is linked on a private uW network with very low latency and basically zero packet loss. The transmitters (GE MIII) run about 1hz freq error with the gpsdo attached.
Sometimes I just wonder if this is just multi-path from the various granite reflectors we have on the front range of Colorado (one of them is Pikes Peak)
de K0JSC
------------------------------
Message: 6 Date: Tue, 13 Feb 2018 20:43:42 +1100 From: Hayden Honeywood <haydenph91@gmail.com> To: app_rpt-users@lists.allstarlink.org Subject: [App_rpt-users] Simulcast buffer value issue Message-ID: <CAC0VLD0-9mc=T8BkvMwx6PqWXqtUXCYY2odbjc2ajjDiVLKSBg@mail.gm ail.com> Content-Type: text/plain; charset="utf-8"
Interesting thoughts Tim... perhaps worth documenting on the wiki? Even though it was just "in theory", what kind of sync error was it? Were we talking microseconds or even more?
I have a receiver on a yagi pointed at a distant simulcasted site. I have noticed on occasion, I can hear the distant simulcasted site start to send audio underneath the carrier of the site that is closest (and strongest to me). The distant site is also the master site, and has the lowest latency, but I'm talking two words worth of audio is send before my other site starts sending audio. Once they are both transmitting, I have not noticed any timing issues (i.e. distortion etc). I'm not sure if this issue was related to what I posted previously about the variable audio delay on unkey.
I'm running app_rpt on a Raspberry Pi using a cut down image we use
here
in VK.
"When simulcasting the audio from all (non captured) transmitters needs to arrive at the receiver with in an acceptable time frame (80 us). The DAC theory was that it didn't start sending audio at correct clock cycle every time. That would cause the audio to be out of sync between RTCMs causing simulcast distortion.
As I said, that was the theory. The new theory is that the external clock source was causing the DAC to trigger inappropriately. I spoke with someone I met here on the list (Kevin I think its was) who is using a different external clock and reports perfect simulcast operations"
Wow; that is going to be rough. In the commercial worl, we would not attempt that. Better to move the Southeast site close in between the North and Southwest sites and do a ribbon system. Even then,,, On 2/15/2018 6:46 PM, Tim Sawyer wrote:
There's a better plot that can be done for simulcast with Radio Mobile that even has a input parameter for acceptable delay. Use about 80 microseconds. The default resulting plot is mostly solid black which hides the map. You have to tweak the colors and/or transparency. I'll see if I can find one of my old plots... that was a couple of computers ago.
On Thu, Feb 15, 2018 at 10:50 AM, Jeff Carrier <k0jsc.jeff@gmail.com <mailto:k0jsc.jeff@gmail.com>> wrote:
Here's a down and dirty display of overlap with transmitter power, feed line loss, antenna gain, pattern and azimuth figured in.
Inline image 1
Message: 8 Date: Wed, 14 Feb 2018 17:33:50 -0800 From: Tim Sawyer <tisawyer@gmail.com <mailto:tisawyer@gmail.com>> To: Users of Asterisk app_rpt <app_rpt-users@lists.allstarlink.org <mailto:app_rpt-users@lists.allstarlink.org>> Subject: Re: [App_rpt-users] Simulcast buffer value issue Message-ID: <CAG3ht9t7Unky+Tc0MFTOLg2Z3+pcnoWFM2AyNFKeFcrOeE4cdw@mail.gmail.com <mailto:CAG3ht9t7Unky%2BTc0MFTOLg2Z3%2BpcnoWFM2AyNFKeFcrOeE4cdw@mail.gmail.com>> Content-Type: text/plain; charset="utf-8"
11,000 feet! No way that will simulcast well, not at 70 miles.
On Tue, Feb 13, 2018 at 8:10 PM, Jeff Carrier <k0jsc.jeff@gmail.com <mailto:k0jsc.jeff@gmail.com>> wrote:
> I really hope to be able to confirm this soon. I've been lazy and our 3 > sites are 86 miles, 79 miles and 70 miles (in a triangle). One of the 3 is > over 11,000 feet elevation. No matter what we've tried so far you still > hear distortion in the overlap area(s) even when 1 site is 20 miles out LoS > and the other is around 60 miles out non LoS. Everything is linked on a > private uW network with very low latency and basically zero packet loss. > The transmitters (GE MIII) run about 1hz freq error with the gpsdo attached. > > Sometimes I just wonder if this is just multi-path from the various > granite reflectors we have on the front range of Colorado (one of them is > Pikes Peak) > > de K0JSC > > ------------------------------ >> >> Message: 6 >> Date: Tue, 13 Feb 2018 20:43:42 +1100 >> From: Hayden Honeywood <haydenph91@gmail.com <mailto:haydenph91@gmail.com>> >> To: app_rpt-users@lists.allstarlink.org <mailto:app_rpt-users@lists.allstarlink.org> >> Subject: [App_rpt-users] Simulcast buffer value issue >> Message-ID: >> <CAC0VLD0-9mc=T8BkvMwx6PqWXqtUXCYY2odbjc2ajjDiVLKSBg@mail.gm <mailto:T8BkvMwx6PqWXqtUXCYY2odbjc2ajjDiVLKSBg@mail.gm> >> ail.com <http://ail.com>> >> Content-Type: text/plain; charset="utf-8" >> >> Interesting thoughts Tim... perhaps worth documenting on the wiki? >> Even though it was just "in theory", what kind of sync error was it? >> Were we talking microseconds or even more? >> >> I have a receiver on a yagi pointed at a distant simulcasted site. I >> have noticed on occasion, I can hear the distant simulcasted site >> start to send audio underneath the carrier of the site that is closest >> (and strongest to me). The distant site is also the master site, and >> has the lowest latency, but I'm talking two words worth of audio is >> send before my other site starts sending audio. Once they are both >> transmitting, I have not noticed any timing issues (i.e. distortion >> etc). I'm not sure if this issue was related to what I posted >> previously about the variable audio delay on unkey. >> >> I'm running app_rpt on a Raspberry Pi using a cut down image we use here >> in VK. >> >> http://vklink.com.au >> >> >> "When simulcasting the audio from all (non captured) transmitters needs to >> arrive at the receiver with in an acceptable time frame (80 us). The DAC >> theory was that it didn't start sending audio at correct clock cycle every >> time. That would cause the audio to be out of sync between RTCMs causing >> simulcast distortion. >> >> As I said, that was the theory. The new theory is that the external clock >> source was causing the DAC to trigger inappropriately. I spoke with >> someone >> I met here on the list (Kevin I think its was) who is using a different >> external clock and reports perfect simulcast operations" >>
participants (5)
-
Jeff Carrier -
Joe Leikhim -
Kevin Babich -
Sam Skolfield -
Tim Sawyer