Date   

Re: compatible with DD-WRT?

steve <stevewa206@...>
 

Hummm.... Connecting the DD-WRT to the Ethernet port would work fine...I'm wondering if you used the Open-WRT with the mesh routing, if then you could mesh all the other UDR56K's on the network? If your just using the UDR56K's as layer 2 ( TCP/IP over AX.25 ) and meshing at the WRT level, that would be pretty cool. So you use the UDR56K's as a long range mesh layer and have the WRT at 2.4 Ghz for local mesh. Hummm...that would be nice because then other hams in the area could be seen.

Then again, you can run the MESH protocol on the UDR56K too, on the unit itself. But if the WRT has it all there, that would be cool.


Steve N0FPF

On 5/26/2012 10:04 AM, John D. Hays wrote:

David,


I'm wondering what you are looking for in "compatibility"?

The UDR56K certainly should work through a router running DD-WRT or OpenWRT.

One could port DD-WRT to the UDR56K, but to what purpose?

In development we are using a full Linux distribution, specifically Debian Squeeze and can run various routing protocols and applications that run on Linux.

------------------------------------------------------------------------
John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223
<http://k7ve.org/blog> <http://twitter.com/#%21/john_hays> <http://www.facebook.com/john.d.hays>



On Sat, May 26, 2012 at 7:03 AM, w2lnx <david.bern@... <mailto:david.bern@...>> wrote:

Do you have any plans to be compatible with DD-WRT?

Thank you,
David, W2LNX


Re: compatible with DD-WRT?

"John D. Hays" <john@...>
 

David,

I'm wondering what you are looking for in "compatibility"?

The UDR56K certainly should work through a router running DD-WRT or OpenWRT.

One could port DD-WRT to the UDR56K, but to what purpose?  

In development we are using a full Linux distribution, specifically Debian Squeeze and can run various routing protocols and applications that run on Linux.


John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223 
  



On Sat, May 26, 2012 at 7:03 AM, w2lnx <david.bern@...> wrote:
 

Do you have any plans to be compatible with DD-WRT?

Thank you,
David, W2LNX


compatible with DD-WRT?

"w2lnx" <david.bern@...>
 

Do you have any plans to be compatible with DD-WRT?

Thank you,
David, W2LNX


Re: Screen shots

"k7udr" <bhhoyer@...>
 

I'll post an app note on using the UDR56K with the Winlink system next week, including screen shots.

Bryan

--- In UniversalDigitalRadio@..., "kgregc" <kgregc@...> wrote:

Are there any screen shots of the Universal Radio software?

Greg


Screen shots

"kgregc" <kgregc@...>
 

Are there any screen shots of the Universal Radio software?

Greg


Re: Cross linking (Was: Codec2)

Jonathan Naylor <naylorjs@...>
 

The specification for the preamble is pretty simple, and I reckon could be implemented easily by an experienced software developer, you'd only need an NCO I reckon. If someone were to implement such a thing then I'd happily add it to my software, but until then....

Jonathan  G4KLX



From: John
To: UniversalDigitalRadio@...
Sent: Thursday, 24 May 2012, 20:50
Subject: [UniversalDigitalRadio] Re: Cross linking (Was: Codec2)

 
The D-STAR specification has a solution to this "non-issue" -- it involves a little MSK preamble on analog transmissions.

http://www.d-star.asia/misc/shogen_4_2_8.pdf

It seems in it's simplest form, one could use a PIC or Arduino and use UR:CQCQCQ with the MY set to the radio's callsign and put it in the TX audio and PPT lines for a radio, similar to what was done on APRS for voice (in fact add a GPS and send coordinates in a payload as well).   

For linking, this is all that is really needed.  An analog repeater with a decoder would simply tell the linking system that the station whose callsign was in the MY field is present at that analog repeater. 

It you want directed traffic (callsign addressed), then a way to capture or set the UR callsign would be required.


--- In UniversalDigitalRadio@..., "siegfried jackstien" wrote:
>
> What we would need in the echolink system ist hat you can announce yourself
> to the system with a dtmf number ...
>




Re: Cross linking (Was: Codec2)

"John" <john@...>
 

The D-STAR specification has a solution to this "non-issue" -- it involves a little MSK preamble on analog transmissions.

http://www.d-star.asia/misc/shogen_4_2_8.pdf

It seems in it's simplest form, one could use a PIC or Arduino and use UR:CQCQCQ with the MY set to the radio's callsign and put it in the TX audio and PPT lines for a radio, similar to what was done on APRS for voice (in fact add a GPS and send coordinates in a payload as well).   

For linking, this is all that is really needed.  An analog repeater with a decoder would simply tell the linking system that the station whose callsign was in the MY field is present at that analog repeater. 

It you want directed traffic (callsign addressed), then a way to capture or set the UR callsign would be required.


--- In UniversalDigitalRadio@..., "siegfried jackstien" wrote:
>
> What we would need in the echolink system ist hat you can announce yourself
> to the system with a dtmf number ...
>


AW: Cross linking (Was: Codec2)

"siegfried jackstien" <siegfried.jackstien@...>
 

What we would need in the echolink system ist hat you can announce yourself
to the system with a dtmf number ...

Example you are not at home but mobile in the range of any echolink node

Give that node your node number (with a command before) that the system
knows that you are not at home (reachable on your pc with your nodenumber)
but that you are "in the system" known to be reachable via repeater xyz

Now if any other wants to connect you then the system could answer with
"your xall will be forwarded to repeater xyz" ...

All echolink hams have a unique node number (that is your home pc) ...
But all hams also can be called with their callsign number (there is a code
for converting calls to dtmf numbers in echolink)

So ... all the routing and callsign forwarding is there already in the
echolink soft .... now what only is missing is that self-announce to the
system while mobile and not connected with your home pc

Ok ... no automatic routing like in a gsm net ... but something like
"my-bbs" in the packet net ....

Then integrating of some echolink nodes in the d-star (and maybe other) nets
would be a lot easier

Dg9bfc

Sigi

Ps we made some tests with short timings (set to min) and with all spoken
things off (and no beeps etc.) with echolink .... nobody that did not know
it would hear any difference in the audio quality!!

-----Ursprüngliche Nachricht-----
Von: UniversalDigitalRadio@...
[mailto:UniversalDigitalRadio@...] Im Auftrag von Matthew
Pitts
Gesendet: Donnerstag, 24. Mai 2012 01:24
An: universaldigitalradio@...
Betreff: Re: [UniversalDigitalRadio] Cross linking (Was: Codec2)





John,

I think as long as the proper display is there, someone using the 1.2k
gmsk modem with analog audio (or echolink with callsign pass-through)
won't really be noticed. It will probably require some special tricks
somewhere along the line to properly work with the Icom gateway software
and such, but that's already taken care of in Jomathan's software.

Matthew Pitts
N8OHU

------------------------------
On Wed, May 23, 2012 7:02 PM EDT John D. Hays wrote:

The argument that analog should never be linked to digital because of
white
noise and other artifacts forgets that Vocoders (as opposed to Codecs)
like
AMBE and Codec-2 are specifically looking for speech and work hard to
remove background noise. All audio starts and ends as analog and
transitioning from an analog FM to digital voice system using a vocoder
applies the same filtering to the audio. I think the folks the argument
haven't tested their theory. Some who have tested it, can probably show
some issues like drop out, overdrive on CTCSS, etc. that will degrade the
system, however, well conditioned audio from an analog FM source should
encode much like analog voice from a microphone.

The second argument is often that the callsign information isn't there in
an analog signal or incompatible digital voice signal. Rules may vary
around the world, but here in the US the ID is for the transmitter where
the signal originates. It doesn't need to be passed through the network
for
identification purposes (other than courtesy or vanity) when it comes to
the regulations. In D-STAR, the callsign is also used as an address for
directed transmissions. In a linked system the only address needed is the
one that identifies the repeater(s) and conference channels, so that the
traffic is properly routed.

Any linking protocol that mixes systems should contain an ability to
identify the type of traffic source (Analog, Digital) and encoding (AMBE,
Codec-2, etc.) and allow the administrator of a repeater to determine
which
traffic to accept.

Given these two "non-issues", the rest is just politics. :)

------------------------------
John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223
<http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
<http://www.facebook.com/john.d.hays>



Re: Cross linking (Was: Codec2)

"Tony Langdon, VK3JED" <vk3jed@...>
 

At 12:35 PM 5/24/2012, you wrote:
The entire “MY� call is unenforceable. It
is sent in clear text, is programmed by the user
and therefore is suspicious. By default, my code
does not check D-Star MY calls for one simple
reason ­ it could lland me in gaol. In most of
the EU, it would be illegal for me acting as a
citizen to deny another citizen access to
systems designed for the whole community based
on my perception of their licensed status. If
it turned out that the other party WAS licensed
and I had denied them access, then I would have
committed a very serious offence in both
anti-discrimination and Human Rights
terms. That is a custodial sentence. The only
people with the power to investigate illegal
transmissions are the police (or Ofcom working
with the police) and the public is advised to
stay out of police business. As any form of
closed system is also not allowed, that means
that irrespective of what someone TELLS me
either verbally or by electronic ID, I cannot
afford to block them for fear of acting illegally. If they break the

I'm not sure where Australia stands on
this. What I do know is that repeaters here are
all considered "open", in that they must be
available to all amateurs whose licence allows
them access to the repeater. The reasoning is
that because the repeater owner effectively has a
frequency "reserved" for the repeater's operation
(by licensing/coordination), then that resource
must be available to all. Limiting access to a
repeater by callsign would seem to fall foul of this principle as well.

However, access to "additional features", such as
IRLP, Echolink or other network access is not
covered by these rules. Precedence was
established by the ACMA fairly early on in the
IRLP days, so it is legal for gateway owners to
allow or block network access on a callsign or
other basis as they see fit. Personally, I've
always believed in open access and have run my
systems as open access to all user functions
(local and network). Seems as is common,
Australia is somewhere between the US and Europe on this.


73 de VK3JED / VK3IRL
http://vkradio.com


Re: Cross linking (Was: Codec2)

"Tony Langdon, VK3JED" <vk3jed@...>
 

At 11:18 AM 5/24/2012, you wrote:

All the time we have the entrenched view of
“this is my system and it won’t connect to
your system� we risk siloing and isolating
users. The net effect is less usage on amateur
bands and less amateurs – exactly the effect
that is being seen in many countries.
At the end of the day, all that the majority of
people want to be able to do is talk to their
friends around the world, and not have to jump
through political hoops to do so.


On the callsign ID, that is an interesting
point. Rules do vary from country to country,
but what I’ve found is that Amateurs naturally
ID every few minutes anyway. In the UK, rules
were relaxed on D-Star so that no voice ID is
required, but you will still typically here an
over start with “G6TBA from G4ULF� and end
with “from G4ULF.� Old habits die hard,
and I certainly ID on every over still.
Similar observations in Australia. However, for
us, this was always a non-issue, because
transmitter ID, not origin ID is the critical factor.


So, again, like you, I think these are both non-issues.

To me, the benefits in terms of increase usage
and more linking possibilities far outweigh these issues.Â

BTW, EchoIRLP does NOT allow interworking IRLP
and Echolink as the IRLP crowd insist on the
end-point being a repeater.   EchoIRLP
allows a repeater to act as an IRLP node and and
Echolink node, but it does not bridge the audio together.
This was one of the original design decisions,
though strictly speaking, there is a bridge
between the two at the protocol level, but it
takes place in the EchoIRLP node when running
Echolink. A copy of thebridge does act as a
local protocol translator between Echolink and
IRLP/Speak Freely (some control functions and
audio transport layer), so the IRLP software can
remain in control of the audio path, as well as
provide sensible status reports to both networks as needed.

73 de VK3JED / VK3IRL
http://vkradio.com


Re: Cross linking (Was: Codec2)

"Tony Langdon, VK3JED" <vk3jed@...>
 

At 09:02 AM 5/24/2012, you wrote:

Any linking protocol that mixes systems should contain an ability to identify the type of traffic source (Analog, Digital) and encoding (AMBE, Codec-2, etc.) and allow the administrator of a repeater to determine which traffic to accept.
A key issue identified many years ago is that control over what sort of traffic should be allowed to pass through a gateway should be in hands of the administrator of that particular gateway/repeater. If I want to allow transmissions of analog origin on my repeater, I should be allowed to simply enable reception of that type of traffic. And if I don't want it (there are legal reasons for not allowing _some_ analog systems to link to digital here), then I should be able to block it.

Similarly, I should not be able to "force" unwanted traffic types on another gateway.


Given these two "non-issues", the rest is just politics. :)
My sentiments exactly. :)

73 de VK3JED / VK3IRL
http://vkradio.com


Re: Cross linking (Was: Codec2)

"David Lake (dlake)" <dlake@...>
 

The entire “MY” call is unenforceable. It is sent in clear text, is programmed by the user and therefore is suspicious.



By default, my code does not check D-Star MY calls for one simple reason – it could land me in gaol.


In most of the EU, it would be illegal for me acting as a citizen to deny another citizen access to systems designed for the whole community based on my perception of their licensed status. If it turned out that the other party WAS licensed and I had denied them access, then I would have committed a very serious offence in both anti-discrimination and Human Rights terms. That is a custodial sentence.



The only people with the power to investigate illegal transmissions are the police (or Ofcom working with the police) and the public is advised to stay out of police business. As any form of closed system is also not allowed, that means that irrespective of what someone TELLS me either verbally or by electronic ID, I cannot afford to block them for fear of acting illegally. If they break the rules of their licence, it is not for me to say other than reporting my suspicions to the authorities.



So, callsign ID on D-Star is pretty meaningless !



David


Re: Cross linking (Was: Codec2)

"John D. Hays" <john@...>
 

Matthew,

The truth of the matter is, for linking, it just doesn't matter.  Having a proper callsign in the "MY" field only matters in two places:

1. If going through an Icom G2 gateway which looks to see if it has the callsign in the trust server database. (G4ULF can check or not, depending on the administrator's preference.)
2. If using callsign addressing, since the receiver needs it to set the return route. (By copying to the UR address)

On linked repeaters DPLUS mostly doesn't look at the MY or the UR except for when issuing link/unlink commands (and echo/info) and a few special cases.  

The other major D-STAR linking systems want something that looks like a legitimate callsign in the MY address, and filter's out callsign addressed (the UR is not CQCQCQ...) traffic, which is not intended for the link in the first place.

Understanding this, for the most part as long as the MY field contains a USRoot Trust registered user callsign, transmissions will be passed.

For other addressed protocols besides D-STAR, its mainly a hash between callsign and address.  Analog would simply need some understood address (for Icom G2 D-STAR routed calls it would have to have a registered callsign in the MY)  That's it.   From a technical point of view, that is...


John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223 
  



On Wed, May 23, 2012 at 6:24 PM, Matthew Pitts <daywalker_blade_2004@...> wrote:
 



John,

I think as long as the proper display is there, someone using the 1.2k gmsk modem with analog audio (or echolink with callsign pass-through) won't really be noticed. It will probably require some special tricks somewhere along the line to properly work with the Icom gateway software and such, but that's already taken care of in Jomathan's software.

Matthew Pitts
N8OHU


Re: Cross linking (Was: Codec2)

Matthew Pitts <daywalker_blade_2004@...>
 

John,

I think as long as the proper display is there, someone using the 1.2k gmsk modem with analog audio (or echolink with callsign pass-through) won't really be noticed. It will probably require some special tricks somewhere along the line to properly work with the Icom gateway software and such, but that's already taken care of in Jomathan's software.

Matthew Pitts
N8OHU


------------------------------

On Wed, May 23, 2012 7:02 PM EDT John D. Hays wrote:

The argument that analog should never be linked to digital because of white
noise and other artifacts forgets that Vocoders (as opposed to Codecs) like
AMBE and Codec-2 are specifically looking for speech and work hard to
remove background noise. All audio starts and ends as analog and
transitioning from an analog FM to digital voice system using a vocoder
applies the same filtering to the audio. I think the folks the argument
haven't tested their theory. Some who have tested it, can probably show
some issues like drop out, overdrive on CTCSS, etc. that will degrade the
system, however, well conditioned audio from an analog FM source should
encode much like analog voice from a microphone.

The second argument is often that the callsign information isn't there in
an analog signal or incompatible digital voice signal. Rules may vary
around the world, but here in the US the ID is for the transmitter where
the signal originates. It doesn't need to be passed through the network for
identification purposes (other than courtesy or vanity) when it comes to
the regulations. In D-STAR, the callsign is also used as an address for
directed transmissions. In a linked system the only address needed is the
one that identifies the repeater(s) and conference channels, so that the
traffic is properly routed.

Any linking protocol that mixes systems should contain an ability to
identify the type of traffic source (Analog, Digital) and encoding (AMBE,
Codec-2, etc.) and allow the administrator of a repeater to determine which
traffic to accept.

Given these two "non-issues", the rest is just politics. :)

------------------------------
John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223
<http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
<http://www.facebook.com/john.d.hays>


Re: Cross linking (Was: Codec2)

"David Lake (dlake)" <dlake@...>
 

John

 

Completely agree.

 

Where I’ve interworked FM to D-Star, I’ve found the results to be perfectly acceptable within the confines of Amateur Radio.

 

You wouldn’t want to listen to Bartok or One Direction over it, but it works and that’s what matters.

 

All the time we have the entrenched view of “this is my system and it won’t connect to your system” we risk siloing and isolating users.  The net effect is less usage on amateur bands and less amateurs – exactly the effect that is being seen in many countries.

 

On the callsign ID, that is an interesting point.  Rules do vary from country to country, but what I’ve found is that Amateurs naturally ID every few minutes anyway.  In the UK, rules were relaxed on D-Star so that no voice ID is required, but you will still typically here an over start with “G6TBA from G4ULF” and end with “from G4ULF.”  Old habits die hard, and I certainly ID on every over still.

 

So, again, like you, I think these are both non-issues.

 

To me, the benefits in terms of increase usage and more linking possibilities far outweigh these issues. 

 

BTW, EchoIRLP does NOT allow interworking IRLP and Echolink as the IRLP crowd insist on the end-point being a repeater.    EchoIRLP allows a repeater to act as an IRLP node and and Echolink node, but it does not bridge the audio together.

 

 

David

 

From: UniversalDigitalRadio@... [mailto:UniversalDigitalRadio@...] On Behalf Of John D. Hays
Sent: Wednesday, May 23, 2012 5:03 PM
To: UniversalDigitalRadio@...
Subject: [UniversalDigitalRadio] Cross linking (Was: Codec2)

 



The argument that analog should never be linked to digital because of white noise and other artifacts forgets that Vocoders (as opposed to Codecs) like AMBE and Codec-2 are specifically looking for speech and work hard to remove background noise.  All audio starts and ends as analog and transitioning from an analog FM to digital voice system using a vocoder applies the same filtering to the audio.  I think the folks the argument haven't tested their theory.   Some who have tested it, can probably show some issues like drop out, overdrive on CTCSS, etc. that will degrade the system, however, well conditioned audio from an analog FM source should encode much like analog voice from a microphone.

 

The second argument is often that the callsign information isn't there in an analog signal or incompatible digital voice signal.  Rules may vary around the world, but here in the US the ID is for the transmitter where the signal originates. It doesn't need to be passed through the network for identification purposes (other than courtesy or vanity) when it comes to the regulations.  In D-STAR, the callsign is also used as an address for directed transmissions.  In a linked system the only address needed is the one that identifies the repeater(s) and conference channels, so that the traffic is properly routed.

 

Any linking protocol that mixes systems should contain an ability to identify the type of traffic source (Analog, Digital) and encoding (AMBE, Codec-2, etc.) and allow the administrator of a repeater to determine which traffic to accept.

 

Given these two "non-issues", the rest is just politics. :)


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 

  







Cross linking (Was: Codec2)

"John D. Hays" <john@...>
 

The argument that analog should never be linked to digital because of white noise and other artifacts forgets that Vocoders (as opposed to Codecs) like AMBE and Codec-2 are specifically looking for speech and work hard to remove background noise.  All audio starts and ends as analog and transitioning from an analog FM to digital voice system using a vocoder applies the same filtering to the audio.  I think the folks the argument haven't tested their theory.   Some who have tested it, can probably show some issues like drop out, overdrive on CTCSS, etc. that will degrade the system, however, well conditioned audio from an analog FM source should encode much like analog voice from a microphone.

The second argument is often that the callsign information isn't there in an analog signal or incompatible digital voice signal.  Rules may vary around the world, but here in the US the ID is for the transmitter where the signal originates. It doesn't need to be passed through the network for identification purposes (other than courtesy or vanity) when it comes to the regulations.  In D-STAR, the callsign is also used as an address for directed transmissions.  In a linked system the only address needed is the one that identifies the repeater(s) and conference channels, so that the traffic is properly routed.

Any linking protocol that mixes systems should contain an ability to identify the type of traffic source (Analog, Digital) and encoding (AMBE, Codec-2, etc.) and allow the administrator of a repeater to determine which traffic to accept.

Given these two "non-issues", the rest is just politics. :)


John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223 
  




Re: Codec2

"Tony Langdon, VK3JED" <vk3jed@...>
 

At 03:14 AM 5/24/2012, Curt, WE7U wrote:
Witness, in order of decreasing quality, conversations from:

*) Analog phone -> analog phone
*) Analog phone -> cell-phone
*) cell-phone -> cell-phone, same technology
*) cell-phone -> cell-phone, different technology

I've had extremely poor conversations with the last mode, with a friend using a different kind of cell-phone technology than my phone.

It's _exactly_ what's being discussed here, conversions from once
codec to another. The more conversions in the line, the poorer the quality. Real-world examples that most of us experience on at least a weekly basis.
Which is a good reason to be clever about how we do things. :) I'm a believer in fiddling with the signal as little as possible, for this very reason.

73 de VK3JED / VK3IRL
http://vkradio.com


Re: Codec2

"Tony Langdon, VK3JED" <vk3jed@...>
 

At 02:53 AM 5/24/2012, Tyrell Berry wrote:

The same is true of these vocoders... They are all lossy formats... And at such low band widths, they don't leave much left over to be lost again. My point is this: A transcoder between any two formats that use different vocoders will significantly degrade the audio quality... Maybe it will still be legible, but I doubt it will be a pleasant experience.

In light of that, going from one digital mode to another may or may not be considered worse than going from FM to digital, depending on the real world performance of that double (or potentially triple in a poorly optimized network) lossy conversion.
Another reason to push the network translation to the edge of the network, and another reason why EchoIRLP was better than other cross network solutions at the time. If you have multi protocol capable gateways, they will could attempt to choose a path that limits the number of transcoding operations to the ideal (0 between networks which use the same vocoder - EchoIRLP achieved this, or 1 when there was no vocoder in common).

73 de VK3JED / VK3IRL
http://vkradio.com


Re: Codec2

"Tony Langdon, VK3JED" <vk3jed@...>
 

At 11:02 PM 5/23/2012, you wrote:
I'm not opposed to linking different protocols, but there is value in some of the objections to linking specific networks. If the objections or concerns can be mitigated, then fewer people would resist.

The most often heard objection to linking FM systems to D-Star seems to be that D-Star users don't want all the white noise from a weak FM station digitized and retransmitted on D-Star, and I agree with this objection. Find a way to limit the retransmission of FM signals onto the D-Star network to only good, mostly full-quieting signals and you will probably overcome these objections.
Actually, there is a way, but it requires some money thrown at the problem. I have a German built DSP that is incredibly effectively at removing FM background noise. Maybe something to experiment with at some stage.


Echolink and IRLP were a match because they both use the same mode, FM.

Linking one type of digital system to another won't have this specific problem, so I don't see why we couldn't develop this option as long as protocols in each system are satisfied. For example, D-Star sends the callsign of the transmitting station through the network. Make this happen from the non-D-Star system and the D-Star network would probably be satisfied. Otherwise, there will continue to be objections.
Being digital all round, that shouldn't be too difficult, though it might need some lookup tables for systems which don't use the callsign as a MAC address. I believe TRBO uses a numeric ID, for instance.

73 de VK3JED / VK3IRL
http://vkradio.com


Re: Codec2

"Tony Langdon, VK3JED" <vk3jed@...>
 

At 02:47 AM 5/24/2012, you wrote:
So the main benefit of TDMA is being able to double repeater capacity in one RF slot. That's one antenna, one duplexer, one site rental. Certainly in the UK where we pay commercial rates for tower access and there is no free spectrum, it's a big deal.
True, useful in densely populated areas. Out where I am, where there's fewer repeaters and bigger distances, I'm concerned about the cost of that increased capacity - namely the effect on range, caused by timing limitations (AKA physics - the speed of light!).

73 de VK3JED / VK3IRL
http://vkradio.com