Simulcast buffer value issue
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. gmail.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"
Do you know how to use radio mobile Jeff? It can help predict areas of overlap, and help you figure out the delay required. If not, pop me the coordinates and tx specs and I can run a plot or two. There can be cases where it'll be impossible to set a delay that makes the whole overlap area sound good. Jesse
On 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.gmail.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"
Jeff, what are using for GPSDO for transmitters and for 9.6MHz injection into RTCM clock? 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.gmail.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"
Have you looked at Joe, KC2IRV's website? He has done some extensive experimenting with simulcast. I found it helpful. Http://rtcmsimulcast.wikifoundry.com Kevin W8KHW
On Feb 13, 2018, at 11: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.gmail.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"
As others have mentioned, there is a lot of information on the internet about simulcasting. It is necessary keep the overlap area small as possible. Reason for that is the audio from each transmitter has to arrive at the receiver within about 80 micro seconds. So you looking at an overlap about 15 miles wide at best. This generally requires extensive site engineering considering, capture effect, location, terrain, antenna pattern and transmit power. The Radio Mobile software package does a fair job of plotting simulcast overlap but it has a pretty steep learning curve and a fair amount of experimentation. I've attached a doodle that may be of interest. 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"
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"
participants (5)
-
Jeff Carrier -
Jesse Lloyd -
Kevin Walsh -
Sam Skolfield -
Tim Sawyer