1. main@DVSwitch.groups.io
  2. Messages
   Date   
Re: YSFn and YSFw

Michael KD5DFB
 

So if I build a YSF reflector, will both modes work with it? My end goal it to connect it to my P25 reflector 
Re: YSFn and YSFw

Steve N4IRS
 

Yes,
YSFn is narrow. I do not remember what Yaesu calls it. It uses a AMBE Vocoder (DMR, NXDN). YSFw is wide. It ises a IMBE Vocoder (P25)

Steve N4IRS 

On 07/15/2018 09:52 PM, KD5DFB wrote:
Okay, I have surfed the internet high and low. I cannot find what the n and w stand for. Is it just as simple as narrowband and wideband? 

Michael KD5DFB

YSFn and YSFw

Michael KD5DFB
 

Okay, I have surfed the internet high and low. I cannot find what the n and w stand for. Is it just as simple as narrowband and wideband? 

Michael KD5DFB
Re: Question....

David KG5RDF
 

We have been using the md380-emu. The system been up for a month. It has not missed a beat. Done zero maintenance and  is connected to a large linked repeater system with 900+ ppt's per day. You all know the tribulations of and large analog system:)

Thanks for all the great work!

David KG5RDF

-------- Original message --------
From: Steven Blackford <kb7sqi@...>
Date: 7/14/18 5:03 PM (GMT-06:00)
To: main@dvswitch.groups.io
Subject: Re: [DVSwitch] Question....

Hey Steve,
     The md380-emu has been rock solid in all the bridges I have running. 73 de K4SQI!

Steve, K4SQI 

On Sat, Jul 14, 2018 at 17:34 Steve Siesel [K4KSA] <steve@...> wrote:

I am rebuilding my ASL <> Brandmeister bridge…..

 

Should I continue to use the DV3000 or have you found that emu380 is doing a better job?

 

Steve

K4KSA

--
-----
Steve, kb7sqi@...
Re: Question....

Steven Blackford
 

Hey Steve,
     The md380-emu has been rock solid in all the bridges I have running. 73 de K4SQI!

Steve, K4SQI 

On Sat, Jul 14, 2018 at 17:34 Steve Siesel [K4KSA] <steve@...> wrote:

I am rebuilding my ASL <> Brandmeister bridge…..

 

Should I continue to use the DV3000 or have you found that emu380 is doing a better job?

 

Steve

K4KSA

--
-----
Steve, kb7sqi@...
Question....

Steve Siesel [K4KSA]
 

I am rebuilding my ASL <> Brandmeister bridge…..

 

Should I continue to use the DV3000 or have you found that emu380 is doing a better job?

 

Steve

K4KSA
Re: HB_link

Bob kc2cwt
 

thanks i may have to add a master ,

As i did add the HB-Bridge.cfg file

On 07/12/2018 09:16 PM, Jon K1IMD wrote:
Hi Bob,
No or Maybe...

If you did nothing to change the TS/TG routing and let the c-Bridge
handle the TG "distribution" then no you don't.  If you monkeyed with
the TG/TS routing then yes and maybe another instance all together.

The hotspot or DMO device can act a little wonky handling both TSs.

73
Jon
K1IMD

On 7/12/2018 21:01, Bob kc2cwt wrote:
I have HB_link set up for my open spot to the C bridge

Now i what to and a mmdvm repeater

do i have to make a new Master .

thanks


--
Bob KC2CWT
kc2cwt@kc2cwt.net
(914)497-5502
Re: HB_link

Jon K1IMD
 

Hi Bob,
No or Maybe...

If you did nothing to change the TS/TG routing and let the c-Bridge
handle the TG "distribution" then no you don't.  If you monkeyed with
the TG/TS routing then yes and maybe another instance all together.

The hotspot or DMO device can act a little wonky handling both TSs.

73
Jon
K1IMD

On 7/12/2018 21:01, Bob kc2cwt wrote:
I have HB_link set up for my open spot to the C bridge

Now i what to and a mmdvm repeater

do i have to make a new Master .

thanks
HB_link

Bob kc2cwt
 

I have HB_link set up for my open spot to the C bridge

Now i what to and a mmdvm repeater

do i have to make a new Master .

thanks

--
Bob KC2CWT
kc2cwt@kc2cwt.net
(914)497-5502
Re: DMR <-> P25

Steve N4IRS
 

Change to AUDIO_USE_GAIN and set the value to less then 1. I would start with .5 if it's hot and adjust up or down as needed.

Steve

On 07/12/2018 06:49 PM, va3czk@... wrote:
Hi Steve,

is there any recommended value for the audio level between DMR and P25 that works best?
Getting a little bit of distortion on both sides ?

Thanks,

J

[USRP]
server = 127.0.0.1                      ; IP address of Allstar/Asterisk
toASLPort = 34001                       ; Analog_Bridge <-- ASL
fromASLPort = 32001                     ; Analog_Bridge --> ASL
aslAudio = AUDIO_UNITY                  ; Audio to ASL (AUDIO_UNITY, AUDIO_USE_AGC, AUDIO_USE_GAIN)
agcGain = -20                           ; Gain (in db) of the AGC filter
dmrAudio = AUDIO_UNITY                  ; Audio from ASL (AUDIO_UNITY, AUDIO_USE_GAIN, AUDIO_BPF)
dmrGain = 0.35                          ; Gain factor of audio from ASL (0.0-1.0)
 
Re: DMR <-> P25

va3czk@...
 

Hi Steve,

is there any recommended value for the audio level between DMR and P25 that works best?
Getting a little bit of distortion on both sides ?

Thanks,

J

[USRP]
server = 127.0.0.1                      ; IP address of Allstar/Asterisk
toASLPort = 34001                       ; Analog_Bridge <-- ASL
fromASLPort = 32001                     ; Analog_Bridge --> ASL
aslAudio = AUDIO_UNITY                  ; Audio to ASL (AUDIO_UNITY, AUDIO_USE_AGC, AUDIO_USE_GAIN)
agcGain = -20                           ; Gain (in db) of the AGC filter
dmrAudio = AUDIO_UNITY                  ; Audio from ASL (AUDIO_UNITY, AUDIO_USE_GAIN, AUDIO_BPF)
dmrGain = 0.35                          ; Gain factor of audio from ASL (0.0-1.0)
 
Re: Allstarling.org Contact

Kevin Custer
 

Chris,

My explanation is not in defense of your comment, and I'm not offended.  While I don't remember seeing your post or the response to it, that isn't the answer you should have received.  As I indicated, there are plenty of things we need to address and make better, and everyone should expect that we'll do just that - over time.  Certainly there were instances in the past that our servers had some issues, but a while ago we purchased some new ones, and they've been running for some time - a few months now.  I have over 50 nodes publicly registered at ASL, so I know immediately when there are registration issues.  Since the upgrade, I've helped troubleshoot and resolve registration problems on several nodes, and none of them were because the ASL server networks were unstable or unreachable.  I haven't personally had any registration issues since the upgrade.

In closing, currently it's my recommendation that folks post their problems to the app_rpt email list.  It's the best place to get answers and resolve to issues pertaining to ASL.

Thanks,
Kevin W3KKC

On 7/11/2018 6:11 PM, Chris WB4ULK via Groups.Io wrote:
Kevin,

I'm sorry if I offended you with that light hearted comment. I can only imagine what work goes into keeping this thing up.

I was not looking for someone to hold my hand when I wrote an email asking what was going on with the registration server several months ago. I was writing asking about it because the registration server is completely out of my control. The answer I got back did not answer to my question, instead I was told to get a mentor.

I took this with a grain of salt and waited the issue out with nothing else said. What else could I do? The comment above was nothing more than a making light of the situation, as I figure with such a tremendous load on whomever is maintaining the system, you are not going to get great explanations sometimes.

Again, I am sorry that that offended you.

Chris
WB4ULK
Re: MMDVM User Authentication

Cort N0MJS <n0mjs@...>
 

Alright boys… give that a shot.

On Jul 11, 2018, at 8:42 AM, Rod - KC7AAD <kc7aad@...> wrote:

I think white listing would be better. Deny all unless they match in a list.

--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206
Re: Allstarling.org Contact

Chris WB4ULK
 

Kevin,

I'm sorry if I offended you with that light hearted comment. I can only imagine what work goes into keeping this thing up.

I was not looking for someone to hold my hand when I wrote an email asking what was going on with the registration server several months ago. I was writing asking about it because the registration server is completely out of my control. The answer I got back did not answer to my question, instead I was told to get a mentor.

I took this with a grain of salt and waited the issue out with nothing else said. What else could I do? The comment above was nothing more than a making light of the situation, as I figure with such a tremendous load on whomever is maintaining the system, you are not going to get great explanations sometimes.

Again, I am sorry that that offended you.

Chris
WB4ULK
Re: DMRLink - bridge streams over writing.

Peter M0NWI
 


Ah OK, I didn't get that from the config text I was hoping to link pairs or Masters as trunk group, will have to look again.

Sent from Outlook
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 20:51:17
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMRLink - bridge streams over writing.
 
Any system you designate as “TRUNK” will become one. There was never a limitation to one. All “TRUNK” does is remove the contention handler completely. I don’t use it a lot, but N3FE who hangs out on here is kinda the TRUNK guru. If I screw up something with the TRUNK code, Corey is the one who usually finds it first :)


On Jul 11, 2018, at 2:46 PM, Peter M0NWI <peter-martin@...> wrote:


Hehe, yes got that after looking at it for a bit, all rebuilt now just under 1000 lines in my config!   Swapped over into operation, and seems OK from my limited testing.

Best not to tell the users or they'll point out every error, and see if anyone shouts about the crashing TG being fixed?

What would have been nice, would have been to have more than one TRUNKS section, is that possible?

Thanks Cort.
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 20:25:54
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMRLink - bridge streams over writing.
 
You just have to switch thinking that the configuration is centered on a group of arbitrarily named “conference bridges”. Each conference bridge is just like a telephone conference bridge – anyone may “dial into” it. Just think about, for each system (master peer or peer), which TS/TGID combination do you want to be part of a bridge?

I always thought bridge.py was ok, too – but an overwhelming majority had asked for an easier to configure version, and two was a bit too much to keep maintaining :)

On Jul 11, 2018, at 11:05 AM, Peter M0NWI <peter-martin@...> wrote:

Bridge.py is GREAT!  Not hard to do at all, in fact very logical and really flexible!

Just my tuppence :)

Having a go with confBridge, but its quite difficult to get it to do what because of the multiple masters I run!  

But, like the British Rail adverts from the '70s, "we're getting there!" 

73,
Peter

From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 16:29
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMRLink - bridge streams over writing.
 
You probably can. The reason for the creation of confbridge was that bridge was HARD to write rules for, and nobody actually used anything “asymmetric” that it could do and confbridge couldn’t.

On Jul 11, 2018, at 9:20 AM, Peter M0NWI <peter-martin@...> wrote:

Hi Cort,

Thanks for you're answer, even if it's not what I wanted 😊

Do you believe I can replicate what I have now under Confbridge, if so I'll start to do that work, it's just been, ain't broke, don't fix it territory!!

73,
Peter


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 13:14
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMRLink - bridge streams over writing.
 
Peter (and group),


* None of my code EVER plays favorites with a TGID based on some designator assigned by one of the “networks”. That would go completely against what I stand for with these projects.

* Bridge.py is a retired application. It hasn’t been developed for some time and is not supported.


The goal of the contention handler routines was to keep something like this from happening. I suspect one of two scenarios – the contention handler is outright failing and sending the wrong traffic, or it’s failing not quite outright and sending BOTH streams to the repeater, which is picking the “other” stream.

I’d really like to figure out which of those things is happening. In IPSC, Motorola has some kind of convoluted (to me) method of determining who gets access to the channel. I’m sure it makes sense to them, but when you’re reverse engineering…. I really am not entirely sure how they make the choice, but it appears significantly more complicated than “who got here first”.

Can anyone duplicate this behavior with confbridge.py? If so, then I’ll dig into it for sure. If it’s just bridge.py…. then I think the best answer I have is to move to confbridge, then we’ll deal with it if it comes back. I know that’s not the answer Peter wants to hear… but it’s the one I have.

0x49 DE N0MJS


On Jul 11, 2018, at 5:11 AM, Peter M0NWI <peter-martin@...> wrote:

Cort,

As you know I've got a fairly stable DMRLink bridge, this hosts 8 repeaters.  I was asked by one keeper to link the local S2TG9 from repeater A, to  repeater B S1TG9, I added both way rules to the bridge.py files, and it seemed to be OK, when user on A keys, output is send to the repeater B no problem.

Then I got reports that while listening on repeater B (connected to bridge Master B), to the stream from repeater A (bridge Master A), if another stream arrived into repeater B, same slot, different TG, say a National or International group from Master C in the same bridge, repeater B would drop the TG9 stream and play out the new Master C stream.

I thought that as the repeater B (Master B) was already outputting network traffic, it would ignore further traffic until the first stream finished, and a hang time had expired.  

Wonder if because they are streaming from different Masters in the same bridge, that that scenario hasn't been considered, and so hold off is not invoked?

Is there a priority that can/has been set within the streams, which is allow the national groups to take precedence over the local traffic?

73,
Peter



--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206






--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206






--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206






--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206
Re: DMRLink - bridge streams over writing.

Cort N0MJS <n0mjs@...>
 

Any system you designate as “TRUNK” will become one. There was never a limitation to one. All “TRUNK” does is remove the contention handler completely. I don’t use it a lot, but N3FE who hangs out on here is kinda the TRUNK guru. If I screw up something with the TRUNK code, Corey is the one who usually finds it first :)


On Jul 11, 2018, at 2:46 PM, Peter M0NWI <peter-martin@...> wrote:


Hehe, yes got that after looking at it for a bit, all rebuilt now just under 1000 lines in my config!   Swapped over into operation, and seems OK from my limited testing.

Best not to tell the users or they'll point out every error, and see if anyone shouts about the crashing TG being fixed?

What would have been nice, would have been to have more than one TRUNKS section, is that possible?

Thanks Cort.
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 20:25:54
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMRLink - bridge streams over writing.
 
You just have to switch thinking that the configuration is centered on a group of arbitrarily named “conference bridges”. Each conference bridge is just like a telephone conference bridge – anyone may “dial into” it. Just think about, for each system (master peer or peer), which TS/TGID combination do you want to be part of a bridge?

I always thought bridge.py was ok, too – but an overwhelming majority had asked for an easier to configure version, and two was a bit too much to keep maintaining :)

On Jul 11, 2018, at 11:05 AM, Peter M0NWI <peter-martin@...> wrote:

Bridge.py is GREAT!  Not hard to do at all, in fact very logical and really flexible!

Just my tuppence :)

Having a go with confBridge, but its quite difficult to get it to do what because of the multiple masters I run!  

But, like the British Rail adverts from the '70s, "we're getting there!" 

73,
Peter

From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 16:29
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMRLink - bridge streams over writing.
 
You probably can. The reason for the creation of confbridge was that bridge was HARD to write rules for, and nobody actually used anything “asymmetric” that it could do and confbridge couldn’t.

On Jul 11, 2018, at 9:20 AM, Peter M0NWI <peter-martin@...> wrote:

Hi Cort,

Thanks for you're answer, even if it's not what I wanted 😊

Do you believe I can replicate what I have now under Confbridge, if so I'll start to do that work, it's just been, ain't broke, don't fix it territory!!

73,
Peter


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 13:14
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMRLink - bridge streams over writing.
 
Peter (and group),


* None of my code EVER plays favorites with a TGID based on some designator assigned by one of the “networks”. That would go completely against what I stand for with these projects.

* Bridge.py is a retired application. It hasn’t been developed for some time and is not supported.


The goal of the contention handler routines was to keep something like this from happening. I suspect one of two scenarios – the contention handler is outright failing and sending the wrong traffic, or it’s failing not quite outright and sending BOTH streams to the repeater, which is picking the “other” stream.

I’d really like to figure out which of those things is happening. In IPSC, Motorola has some kind of convoluted (to me) method of determining who gets access to the channel. I’m sure it makes sense to them, but when you’re reverse engineering…. I really am not entirely sure how they make the choice, but it appears significantly more complicated than “who got here first”.

Can anyone duplicate this behavior with confbridge.py? If so, then I’ll dig into it for sure. If it’s just bridge.py…. then I think the best answer I have is to move to confbridge, then we’ll deal with it if it comes back. I know that’s not the answer Peter wants to hear… but it’s the one I have.

0x49 DE N0MJS


On Jul 11, 2018, at 5:11 AM, Peter M0NWI <peter-martin@...> wrote:

Cort,

As you know I've got a fairly stable DMRLink bridge, this hosts 8 repeaters.  I was asked by one keeper to link the local S2TG9 from repeater A, to  repeater B S1TG9, I added both way rules to the bridge.py files, and it seemed to be OK, when user on A keys, output is send to the repeater B no problem.

Then I got reports that while listening on repeater B (connected to bridge Master B), to the stream from repeater A (bridge Master A), if another stream arrived into repeater B, same slot, different TG, say a National or International group from Master C in the same bridge, repeater B would drop the TG9 stream and play out the new Master C stream.

I thought that as the repeater B (Master B) was already outputting network traffic, it would ignore further traffic until the first stream finished, and a hang time had expired.  

Wonder if because they are streaming from different Masters in the same bridge, that that scenario hasn't been considered, and so hold off is not invoked?

Is there a priority that can/has been set within the streams, which is allow the national groups to take precedence over the local traffic?

73,
Peter



--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206






--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206






--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206






--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206
Re: DMRLink - bridge streams over writing.

Peter M0NWI
 


Hehe, yes got that after looking at it for a bit, all rebuilt now just under 1000 lines in my config!   Swapped over into operation, and seems OK from my limited testing.

Best not to tell the users or they'll point out every error, and see if anyone shouts about the crashing TG being fixed?

What would have been nice, would have been to have more than one TRUNKS section, is that possible?

Thanks Cort.

From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 20:25:54
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMRLink - bridge streams over writing.
 
You just have to switch thinking that the configuration is centered on a group of arbitrarily named “conference bridges”. Each conference bridge is just like a telephone conference bridge – anyone may “dial into” it. Just think about, for each system (master peer or peer), which TS/TGID combination do you want to be part of a bridge?

I always thought bridge.py was ok, too – but an overwhelming majority had asked for an easier to configure version, and two was a bit too much to keep maintaining :)

On Jul 11, 2018, at 11:05 AM, Peter M0NWI <peter-martin@...> wrote:

Bridge.py is GREAT!  Not hard to do at all, in fact very logical and really flexible!

Just my tuppence :)

Having a go with confBridge, but its quite difficult to get it to do what because of the multiple masters I run!  

But, like the British Rail adverts from the '70s, "we're getting there!" 

73,
Peter

From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 16:29
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMRLink - bridge streams over writing.
 
You probably can. The reason for the creation of confbridge was that bridge was HARD to write rules for, and nobody actually used anything “asymmetric” that it could do and confbridge couldn’t.

On Jul 11, 2018, at 9:20 AM, Peter M0NWI <peter-martin@...> wrote:

Hi Cort,

Thanks for you're answer, even if it's not what I wanted 😊

Do you believe I can replicate what I have now under Confbridge, if so I'll start to do that work, it's just been, ain't broke, don't fix it territory!!

73,
Peter


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 13:14
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMRLink - bridge streams over writing.
 
Peter (and group),


* None of my code EVER plays favorites with a TGID based on some designator assigned by one of the “networks”. That would go completely against what I stand for with these projects.

* Bridge.py is a retired application. It hasn’t been developed for some time and is not supported.


The goal of the contention handler routines was to keep something like this from happening. I suspect one of two scenarios – the contention handler is outright failing and sending the wrong traffic, or it’s failing not quite outright and sending BOTH streams to the repeater, which is picking the “other” stream.

I’d really like to figure out which of those things is happening. In IPSC, Motorola has some kind of convoluted (to me) method of determining who gets access to the channel. I’m sure it makes sense to them, but when you’re reverse engineering…. I really am not entirely sure how they make the choice, but it appears significantly more complicated than “who got here first”.

Can anyone duplicate this behavior with confbridge.py? If so, then I’ll dig into it for sure. If it’s just bridge.py…. then I think the best answer I have is to move to confbridge, then we’ll deal with it if it comes back. I know that’s not the answer Peter wants to hear… but it’s the one I have.

0x49 DE N0MJS


On Jul 11, 2018, at 5:11 AM, Peter M0NWI <peter-martin@...> wrote:

Cort,

As you know I've got a fairly stable DMRLink bridge, this hosts 8 repeaters.  I was asked by one keeper to link the local S2TG9 from repeater A, to  repeater B S1TG9, I added both way rules to the bridge.py files, and it seemed to be OK, when user on A keys, output is send to the repeater B no problem.

Then I got reports that while listening on repeater B (connected to bridge Master B), to the stream from repeater A (bridge Master A), if another stream arrived into repeater B, same slot, different TG, say a National or International group from Master C in the same bridge, repeater B would drop the TG9 stream and play out the new Master C stream.

I thought that as the repeater B (Master B) was already outputting network traffic, it would ignore further traffic until the first stream finished, and a hang time had expired.  

Wonder if because they are streaming from different Masters in the same bridge, that that scenario hasn't been considered, and so hold off is not invoked?

Is there a priority that can/has been set within the streams, which is allow the national groups to take precedence over the local traffic?

73,
Peter



--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206






--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206






--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206
Re: Shameless Request

Steve N4IRS
 

DO NOT junk the HSOs I'll take them.

Steve

On 7/11/2018 3:27 PM, Cort N0MJS via Groups.Io wrote:
I’ll take the PAs and you can junk the rest :)

On Jul 11, 2018, at 11:38 AM, Jon K1IMD <lists@...> wrote:

Cort,
I don't have any GE/Johnson/Moto PA's BUT I do have a couple complete 100w MSF5000 UHF repeaters tuned up on the ham band... the price is right but the shipping would be insane!  You or Gavin coming east soon?  I'll hook you up...
73
Jon
K1iMD

--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206
Re: Shameless Request

Cort N0MJS <n0mjs@...>
 

I’ll take the PAs and you can junk the rest :)

On Jul 11, 2018, at 11:38 AM, Jon K1IMD <lists@...> wrote:

Cort,
I don't have any GE/Johnson/Moto PA's BUT I do have a couple complete 100w MSF5000 UHF repeaters tuned up on the ham band... the price is right but the shipping would be insane!  You or Gavin coming east soon?  I'll hook you up...
73
Jon
K1iMD

--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206
Re: Shameless Request

Cort N0MJS <n0mjs@...>
 

Oh hell – yes, it would be less expensive to just buy one than to ship one of those monsters – Peter, you’re off the hook for now, but someday I’ll need some trinket you have that weighs less!

On Jul 11, 2018, at 11:01 AM, Peter M0NWI <peter-martin@...> wrote:

Hi Cort,

Don't have any of the kit sorry, and it might be difficult to get it across the pond!

BUT!  If you've got a PayPal, I'm happy to chip in a few bucks if that's of use, for all the help you've given me personally, my repeater group, and the hobby over the years!!

73,
Peter

From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 16:52
To: DVSwitch@groups.io
Subject: [DVSwitch] Shameless Request
 
Guys,

Here’s the deal. In addition to writing this software, I also try to run a fistful of repeaters in Northeast and Northcentral Kansas. That stuff competes with hblink/dmrlink development – and usually wins. It’s production repeaters people rely on. Seems to always get in front of adding features, etc.

Some of you may have RF hardware resources that I don’t have, and I’m thinking, maybe there’s a way to free up more time. I’m looking for (good working order) UHF PAs from EF Johnson CR series repeaters, or similar. Stuff that takes a few watts in (5-10, typically) and makes 75-100w out. If anyone would like to donate or sell cheap as a “thank you”, I’d be both grateful and have more time to work on code. Likewise if there’s anyone who has experience re-building these amps and the tools/documentation, etc. to do it, you might also volunteer to rebuild an amp. I don’t really have the tools (enough heat, stockpile of the chip capacitors, etc.) to do this right, and it takes me forever to get anywhere.

Ok, yes, I just pretty much begged for UHF PAs.. but I though, what the hell? Maybe someone’s sitting on a lifetime supply out there :)

0x49 DE N0MJS

--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206









--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206
8741 - 8760 of 10557