
Steve N4IRS
We have been talking about hUC (HTTP USRP Client) since about the time we released DVSwitch Server. So, where is it already? hUC in it's early form did not really take that long. Thought it connects to DVSwitch Server differently, It's not much different then pyUC (python USRP Client) Then we started having our usual "what if" discussions. Our wives will tell you this can go on for days. A very big issue with a web based client is security. If you expose a HTML client to the internet, people will play with it. This could be disastrous. We need security to control who can do what. I sure don't want anybody with access to a search engine to start talking on DMR TG 91 (with my call and DMR ID) So, security had to be added.
Now I have this DVSwitch Server in the cloud with a web interface and at least I can control who has access. We know DVSwitch Server is single user. It sure would be nice if I can give my friends access to my server. Let's face it, I'm not using it all the time. I can share. Some friends are more responsible then others. I would like to give Jack the ability to transmit, but not move the Server to another mode or talk group (tune). I would like to give Jill the ability to listen, but no transmit and no tune. OK, we can do that. Jack and Jill can both listen to traffic on the server. Jack can transmit. I am the only one that can tune to another TG or mode. OK, this is getting good.
We don't want to limit the fun to only web clients. What about DVSM and pyUC users? Yes, you can assign the same rights to DVSM and pyUC users. You can have users from all 3 clients with different rights. Everybody that can listen will hear not only the connected Steerable Bridge (SBridge) they will hear any client with transmit rights. Let me be CLEAR, This is one SBridge shared among multiple users. This is NOT DVAAS (Digital Voice as a service)
We did not forget AllStar. You can have one or more AllStar nodes directly connected to the Server. AllStar users (by node) can be assigned rights. RX, TX Tune. It's up to the Server owner how these connections are controlled. Some Server users use AllStar to mix audio from multiple modes. This is usually done by bridging each mode into a seperate AllStar "private node" This give the Server operator the ability to connect and disconnect modes into the main AllStar node. He can also directly connect 2 modes together without connecting those modes to anything else. AllStar is VERY versatile that way. In the case of unlike modes DMR (AMBE) to P25 (IMBE) this works quite well.If you are connecting like modes YSFn (AMBE) to NXDN (AMBE) this leave something to be desired. This is transcoding where none is required. It's up to the Server operator to decide if this is a disadvantage. No matter if it's like modes or not, using AllStar to bridge Digital Voice modes has one downside, You loose the metadata that is transmitted along with the voice. Some people don't care, the advantages of mixing in AllStar outweighs the disadvantages. I can make a case for either choice.
So, how do we give people another option. That option is called Analog_Reflector. Consider a piece of software tha t will accept multiple connections from clients (DVSM, pyUC or hUC) it will also accept connections from multiple AllStar nodes either on the same server or a remote server. (via USRP) You can have multiple bridges connected. These bridges are fixed by mode and TG (reflector). Last but not lease is a Steerable Bridge (SBridge) This is the bridge you can change modes, you can change TGs it's exactly like the bridge in DVSwitch Server now. Any client (with the proper rights) can steer the bridge. This includes The AllStar nodes. One big advantage, no more macros needed (but still supported) The command path between AllStar and the reflector is two way. We can send commands for AllStar to the reflector (and on to the SBridge) We can also receive commands from a connected client and send them to AllStar. If you want to connect your AllStar node to another AllStar node, you can do it from a connected client. AllStar becomes "just another mode" accessible from a connected client. (Think Web tranceiver)
One last point I may have glossed over. EVERYBODY get the metadata. Client, Bridges, AllStar and SBridges. Everybody gets the data. Not everybody can do anything with the metadata (AllStar) but AllStar does send what little metadata it knows about the connected and transmitting stations into the reflector.
Over the next few months we are going to build a demonstration bridge. we will show you how to connect like modes without transcoding. We will show you how to send traffic to multiple modes at the same time. An example of this is DMR to YSF AND P25. We are going to do this with one instance of MMDVM_Bridge and a transcoder. Everybody gets the audio, everybody gets the metadata. Yes, it's all done with UDP ports. It's all modular. Yes it can get complex. (we have some thoughts in that area too)
DVSwitch is about giving you control. You control the mode, you control the destination. You control the metadata. It's your server. Do what YOU want.. There is SO much more I did not cover (as Mike will tell me) There is a admin interface for Analog_Reflector (and a dashboard) Somebody "sitting on his mike"? Kick him or mute him. Somebody abusing your server, ban him. I won't promise you we have thought of everything. That will come to light as we see tAnalog_Reflector in the field.
For DVSwitch, 73, Steve N4IRS
|
|
Definitely looking forward to this, especially if you can do
something like referencing the Allstarlink node database and
matching to ID's, if they exist. Of course, there is a lot of room
for error, since the call sign field for ASL nodes is technically
arbitrary, but it would be better than what exists now for passing
metadata to digital modes. There are way too many people who look
at displays and don't listen.
toggle quoted messageShow quoted text
On 12/22/2020 4:21 PM, Steve N4IRS
wrote:
We have been talking about hUC (HTTP USRP Client) since about the
time we released DVSwitch Server. So, where is it already? hUC in
it's early form did not really take that long. Thought it connects
to DVSwitch Server differently, It's not much different then pyUC
(python USRP Client) Then we started having our usual "what if"
discussions. Our wives will tell you this can go on for days. A
very big issue with a web based client is security. If you expose
a HTML client to the internet, people will play with it. This
could be disastrous. We need security to control who can do what.
I sure don't want anybody with access to a search engine to start
talking on DMR TG 91 (with my call and DMR ID) So, security had to
be added.
Now I have this DVSwitch Server in the cloud with a web interface
and at least I can control who has access. We know DVSwitch
Server is single user. It sure would be nice if I can give my
friends access to my server. Let's face it, I'm not using it all
the time. I can share. Some friends are more responsible then
others. I would like to give Jack the ability to transmit, but not
move the Server to another mode or talk group (tune). I would like
to give Jill the ability to listen, but no transmit and no tune.
OK, we can do that. Jack and Jill can both listen to traffic on
the server. Jack can transmit. I am the only one that can tune to
another TG or mode. OK, this is getting good.
We don't want to limit the fun to only web clients. What about
DVSM and pyUC users? Yes, you can assign the same rights to DVSM
and pyUC users. You can have users from all 3 clients with
different rights. Everybody that can listen will hear not only the
connected Steerable Bridge (SBridge) they will hear any client
with transmit rights. Let me be CLEAR, This is one SBridge shared
among multiple users. This is NOT DVAAS (Digital Voice as a
service)
We did not forget AllStar. You can have one or more AllStar nodes
directly connected to the Server. AllStar users (by node) can be
assigned rights. RX, TX Tune. It's up to the Server owner how
these connections are controlled. Some Server users use AllStar to
mix audio from multiple modes. This is usually done by bridging
each mode into a seperate AllStar "private node" This give the
Server operator the ability to connect and disconnect modes into
the main AllStar node. He can also directly connect 2 modes
together without connecting those modes to anything else. AllStar
is VERY versatile that way. In the case of unlike modes DMR (AMBE)
to P25 (IMBE) this works quite well.If you are connecting like
modes YSFn (AMBE) to NXDN (AMBE) this leave something to be
desired. This is transcoding where none is required. It's up to
the Server operator to decide if this is a disadvantage. No matter
if it's like modes or not, using AllStar to bridge Digital Voice
modes has one downside, You loose the metadata that is transmitted
along with the voice. Some people don't care, the advantages of
mixing in AllStar outweighs the disadvantages. I can make a case
for either choice.
So, how do we give people another option. That option is called
Analog_Reflector. Consider a piece of software tha t will accept
multiple connections from clients (DVSM, pyUC or hUC) it will also
accept connections from multiple AllStar nodes either on the same
server or a remote server. (via USRP) You can have multiple
bridges connected. These bridges are fixed by mode and TG
(reflector). Last but not lease is a Steerable Bridge (SBridge)
This is the bridge you can change modes, you can change TGs it's
exactly like the bridge in DVSwitch Server now. Any client (with
the proper rights) can steer the bridge. This includes The AllStar
nodes. One big advantage, no more macros needed (but still
supported) The command path between AllStar and the reflector is
two way. We can send commands for AllStar to the reflector (and on
to the SBridge) We can also receive commands from a connected
client and send them to AllStar. If you want to connect your
AllStar node to another AllStar node, you can do it from a
connected client. AllStar becomes "just another mode" accessible
from a connected client. (Think Web tranceiver)
One last point I may have glossed over. EVERYBODY get the
metadata. Client, Bridges, AllStar and SBridges. Everybody gets
the data. Not everybody can do anything with the metadata
(AllStar) but AllStar does send what little metadata it knows
about the connected and transmitting stations into the reflector.
Over the next few months we are going to build a demonstration
bridge. we will show you how to connect like modes without
transcoding. We will show you how to send traffic to multiple
modes at the same time. An example of this is DMR to YSF AND P25.
We are going to do this with one instance of MMDVM_Bridge and a
transcoder. Everybody gets the audio, everybody gets the metadata.
Yes, it's all done with UDP ports. It's all modular. Yes it can
get complex. (we have some thoughts in that area too)
DVSwitch is about giving you control. You control the mode, you
control the destination. You control the metadata. It's your
server. Do what YOU want.. There is SO much more I did not cover
(as Mike will tell me) There is a admin interface for
Analog_Reflector (and a dashboard) Somebody "sitting on his mike"?
Kick him or mute him. Somebody abusing your server, ban him. I
won't promise you we have thought of everything. That will come to
light as we see tAnalog_Reflector in the field.
For DVSwitch,
73, Steve N4IRS
|
|
I’ll be honest, I havn’t looked too closely at the DVSwitch server because I don’t have an android device. However, This is incredibly intriguing and very much changing my mind about dedicating a PI to this. I love the concept of multiple clients, especially a web based one. Very much looking forward to this…
toggle quoted messageShow quoted text
On Dec 22, 2020, at 19:06, Patrick Perdue < patrick@...> wrote:
Definitely looking forward to this, especially if you can do
something like referencing the Allstarlink node database and
matching to ID's, if they exist. Of course, there is a lot of room
for error, since the call sign field for ASL nodes is technically
arbitrary, but it would be better than what exists now for passing
metadata to digital modes. There are way too many people who look
at displays and don't listen.
On 12/22/2020 4:21 PM, Steve N4IRS
wrote:
We have been talking about hUC (HTTP USRP Client) since about the
time we released DVSwitch Server. So, where is it already? hUC in
it's early form did not really take that long. Thought it connects
to DVSwitch Server differently, It's not much different then pyUC
(python USRP Client) Then we started having our usual "what if"
discussions. Our wives will tell you this can go on for days. A
very big issue with a web based client is security. If you expose
a HTML client to the internet, people will play with it. This
could be disastrous. We need security to control who can do what.
I sure don't want anybody with access to a search engine to start
talking on DMR TG 91 (with my call and DMR ID) So, security had to
be added.
Now I have this DVSwitch Server in the cloud with a web interface
and at least I can control who has access. We know DVSwitch
Server is single user. It sure would be nice if I can give my
friends access to my server. Let's face it, I'm not using it all
the time. I can share. Some friends are more responsible then
others. I would like to give Jack the ability to transmit, but not
move the Server to another mode or talk group (tune). I would like
to give Jill the ability to listen, but no transmit and no tune.
OK, we can do that. Jack and Jill can both listen to traffic on
the server. Jack can transmit. I am the only one that can tune to
another TG or mode. OK, this is getting good.
We don't want to limit the fun to only web clients. What about
DVSM and pyUC users? Yes, you can assign the same rights to DVSM
and pyUC users. You can have users from all 3 clients with
different rights. Everybody that can listen will hear not only the
connected Steerable Bridge (SBridge) they will hear any client
with transmit rights. Let me be CLEAR, This is one SBridge shared
among multiple users. This is NOT DVAAS (Digital Voice as a
service)
We did not forget AllStar. You can have one or more AllStar nodes
directly connected to the Server. AllStar users (by node) can be
assigned rights. RX, TX Tune. It's up to the Server owner how
these connections are controlled. Some Server users use AllStar to
mix audio from multiple modes. This is usually done by bridging
each mode into a seperate AllStar "private node" This give the
Server operator the ability to connect and disconnect modes into
the main AllStar node. He can also directly connect 2 modes
together without connecting those modes to anything else. AllStar
is VERY versatile that way. In the case of unlike modes DMR (AMBE)
to P25 (IMBE) this works quite well.If you are connecting like
modes YSFn (AMBE) to NXDN (AMBE) this leave something to be
desired. This is transcoding where none is required. It's up to
the Server operator to decide if this is a disadvantage. No matter
if it's like modes or not, using AllStar to bridge Digital Voice
modes has one downside, You loose the metadata that is transmitted
along with the voice. Some people don't care, the advantages of
mixing in AllStar outweighs the disadvantages. I can make a case
for either choice.
So, how do we give people another option. That option is called
Analog_Reflector. Consider a piece of software tha t will accept
multiple connections from clients (DVSM, pyUC or hUC) it will also
accept connections from multiple AllStar nodes either on the same
server or a remote server. (via USRP) You can have multiple
bridges connected. These bridges are fixed by mode and TG
(reflector). Last but not lease is a Steerable Bridge (SBridge)
This is the bridge you can change modes, you can change TGs it's
exactly like the bridge in DVSwitch Server now. Any client (with
the proper rights) can steer the bridge. This includes The AllStar
nodes. One big advantage, no more macros needed (but still
supported) The command path between AllStar and the reflector is
two way. We can send commands for AllStar to the reflector (and on
to the SBridge) We can also receive commands from a connected
client and send them to AllStar. If you want to connect your
AllStar node to another AllStar node, you can do it from a
connected client. AllStar becomes "just another mode" accessible
from a connected client. (Think Web tranceiver)
One last point I may have glossed over. EVERYBODY get the
metadata. Client, Bridges, AllStar and SBridges. Everybody gets
the data. Not everybody can do anything with the metadata
(AllStar) but AllStar does send what little metadata it knows
about the connected and transmitting stations into the reflector.
Over the next few months we are going to build a demonstration
bridge. we will show you how to connect like modes without
transcoding. We will show you how to send traffic to multiple
modes at the same time. An example of this is DMR to YSF AND P25.
We are going to do this with one instance of MMDVM_Bridge and a
transcoder. Everybody gets the audio, everybody gets the metadata.
Yes, it's all done with UDP ports. It's all modular. Yes it can
get complex. (we have some thoughts in that area too)
DVSwitch is about giving you control. You control the mode, you
control the destination. You control the metadata. It's your
server. Do what YOU want.. There is SO much more I did not cover
(as Mike will tell me) There is a admin interface for
Analog_Reflector (and a dashboard) Somebody "sitting on his mike"?
Kick him or mute him. Somebody abusing your server, ban him. I
won't promise you we have thought of everything. That will come to
light as we see tAnalog_Reflector in the field.
For DVSwitch,
73, Steve N4IRS
|
|

Steve N4IRS
The existing clients are Android any Python. The python client
pretty much runs on any desktop system. As it happens, Mike is
spending a LOT of time making sure the HTML client runs on most
browsers and that includes Safari on IOS.
For the AllStar people among us, The clients will be able to control
the AllStar nodes.
toggle quoted messageShow quoted text
On 12/22/20 7:14 PM, Jeff Lehman, N8ACL
via groups.io wrote:
I’ll be honest, I havn’t looked too closely at the DVSwitch server
because I don’t have an android device. However, This is
incredibly intriguing and very much changing my mind about
dedicating a PI to this. I love the concept of multiple clients,
especially a web based one. Very much looking forward to this…
Jeff
On Dec 22, 2020, at 19:06, Patrick Perdue < patrick@...>
wrote:
Definitely looking forward to this,
especially if you can do something like referencing
the Allstarlink node database and matching to ID's, if
they exist. Of course, there is a lot of room for
error, since the call sign field for ASL nodes is
technically arbitrary, but it would be better than
what exists now for passing metadata to digital modes.
There are way too many people who look at displays and
don't listen.
On 12/22/2020 4:21 PM,
Steve N4IRS wrote:
We have been talking about hUC (HTTP USRP Client)
since about the time we released DVSwitch Server. So,
where is it already? hUC in it's early form did not
really take that long. Thought it connects to DVSwitch
Server differently, It's not much different then pyUC
(python USRP Client) Then we started having our usual
"what if" discussions. Our wives will tell you this
can go on for days. A very big issue with a web based
client is security. If you expose a HTML client to the
internet, people will play with it. This could be
disastrous. We need security to control who can do
what. I sure don't want anybody with access to a
search engine to start talking on DMR TG 91 (with my
call and DMR ID) So, security had to be added.
Now I have this DVSwitch Server in the cloud with a
web interface and at least I can control who has
access. We know DVSwitch Server is single user. It
sure would be nice if I can give my friends access to
my server. Let's face it, I'm not using it all the
time. I can share. Some friends are more responsible
then others. I would like to give Jack the ability to
transmit, but not move the Server to another mode or
talk group (tune). I would like to give Jill the
ability to listen, but no transmit and no tune. OK, we
can do that. Jack and Jill can both listen to traffic
on the server. Jack can transmit. I am the only one
that can tune to another TG or mode. OK, this is
getting good.
We don't want to limit the fun to only web clients.
What about DVSM and pyUC users? Yes, you can assign
the same rights to DVSM and pyUC users. You can have
users from all 3 clients with different rights.
Everybody that can listen will hear not only the
connected Steerable Bridge (SBridge) they will hear
any client with transmit rights. Let me be CLEAR, This
is one SBridge shared among multiple users. This is
NOT DVAAS (Digital Voice as a service)
We did not forget AllStar. You can have one or more
AllStar nodes directly connected to the Server.
AllStar users (by node) can be assigned rights. RX, TX
Tune. It's up to the Server owner how these
connections are controlled. Some Server users use
AllStar to mix audio from multiple modes. This is
usually done by bridging each mode into a seperate
AllStar "private node" This give the Server operator
the ability to connect and disconnect modes into the
main AllStar node. He can also directly connect 2
modes together without connecting those modes to
anything else. AllStar is VERY versatile that way. In
the case of unlike modes DMR (AMBE) to P25 (IMBE) this
works quite well.If you are connecting like modes YSFn
(AMBE) to NXDN (AMBE) this leave something to be
desired. This is transcoding where none is required.
It's up to the Server operator to decide if this is a
disadvantage. No matter if it's like modes or not,
using AllStar to bridge Digital Voice modes has one
downside, You loose the metadata that is transmitted
along with the voice. Some people don't care, the
advantages of mixing in AllStar outweighs the
disadvantages. I can make a case for either choice.
So, how do we give people another option. That option
is called Analog_Reflector. Consider a piece of
software tha t will accept multiple connections from
clients (DVSM, pyUC or hUC) it will also accept
connections from multiple AllStar nodes either on the
same server or a remote server. (via USRP) You can
have multiple bridges connected. These bridges are
fixed by mode and TG (reflector). Last but not lease
is a Steerable Bridge (SBridge) This is the bridge you
can change modes, you can change TGs it's exactly like
the bridge in DVSwitch Server now. Any client (with
the proper rights) can steer the bridge. This includes
The AllStar nodes. One big advantage, no more macros
needed (but still supported) The command path between
AllStar and the reflector is two way. We can send
commands for AllStar to the reflector (and on to the
SBridge) We can also receive commands from a connected
client and send them to AllStar. If you want to
connect your AllStar node to another AllStar node, you
can do it from a connected client. AllStar becomes
"just another mode" accessible from a connected
client. (Think Web tranceiver)
One last point I may have glossed over. EVERYBODY get
the metadata. Client, Bridges, AllStar and SBridges.
Everybody gets the data. Not everybody can do anything
with the metadata (AllStar) but AllStar does send what
little metadata it knows about the connected and
transmitting stations into the reflector.
Over the next few months we are going to build a
demonstration bridge. we will show you how to connect
like modes without transcoding. We will show you how
to send traffic to multiple modes at the same time. An
example of this is DMR to YSF AND P25. We are going to
do this with one instance of MMDVM_Bridge and a
transcoder. Everybody gets the audio, everybody gets
the metadata. Yes, it's all done with UDP ports. It's
all modular. Yes it can get complex. (we have some
thoughts in that area too)
DVSwitch is about giving you control. You control the
mode, you control the destination. You control the
metadata. It's your server. Do what YOU want.. There
is SO much more I did not cover (as Mike will tell me)
There is a admin interface for Analog_Reflector (and a
dashboard) Somebody "sitting on his mike"? Kick him or
mute him. Somebody abusing your server, ban him. I
won't promise you we have thought of everything. That
will come to light as we see tAnalog_Reflector in the
field.
For DVSwitch,
73, Steve N4IRS
|
|
Now you have sold me…. What about other mobile browsers like Firefox? I mean I totally get that there are so many browsers out there, it would be almost impossible to check them all. But still Safari works for me for this….. Love it!
toggle quoted messageShow quoted text
On Dec 22, 2020, at 19:18, Steve N4IRS < szingman@...> wrote:
The existing clients are Android any Python. The python client
pretty much runs on any desktop system. As it happens, Mike is
spending a LOT of time making sure the HTML client runs on most
browsers and that includes Safari on IOS.
For the AllStar people among us, The clients will be able to control
the AllStar nodes.
On 12/22/20 7:14 PM, Jeff Lehman, N8ACL
via groups.io wrote:
I’ll be honest, I havn’t looked too closely at the DVSwitch server
because I don’t have an android device. However, This is
incredibly intriguing and very much changing my mind about
dedicating a PI to this. I love the concept of multiple clients,
especially a web based one. Very much looking forward to this…
Jeff
On Dec 22, 2020, at 19:06, Patrick Perdue < patrick@...>
wrote:
Definitely looking forward to this,
especially if you can do something like referencing
the Allstarlink node database and matching to ID's, if
they exist. Of course, there is a lot of room for
error, since the call sign field for ASL nodes is
technically arbitrary, but it would be better than
what exists now for passing metadata to digital modes.
There are way too many people who look at displays and
don't listen.
On 12/22/2020 4:21 PM,
Steve N4IRS wrote:
We have been talking about hUC (HTTP USRP Client)
since about the time we released DVSwitch Server. So,
where is it already? hUC in it's early form did not
really take that long. Thought it connects to DVSwitch
Server differently, It's not much different then pyUC
(python USRP Client) Then we started having our usual
"what if" discussions. Our wives will tell you this
can go on for days. A very big issue with a web based
client is security. If you expose a HTML client to the
internet, people will play with it. This could be
disastrous. We need security to control who can do
what. I sure don't want anybody with access to a
search engine to start talking on DMR TG 91 (with my
call and DMR ID) So, security had to be added.
Now I have this DVSwitch Server in the cloud with a
web interface and at least I can control who has
access. We know DVSwitch Server is single user. It
sure would be nice if I can give my friends access to
my server. Let's face it, I'm not using it all the
time. I can share. Some friends are more responsible
then others. I would like to give Jack the ability to
transmit, but not move the Server to another mode or
talk group (tune). I would like to give Jill the
ability to listen, but no transmit and no tune. OK, we
can do that. Jack and Jill can both listen to traffic
on the server. Jack can transmit. I am the only one
that can tune to another TG or mode. OK, this is
getting good.
We don't want to limit the fun to only web clients.
What about DVSM and pyUC users? Yes, you can assign
the same rights to DVSM and pyUC users. You can have
users from all 3 clients with different rights.
Everybody that can listen will hear not only the
connected Steerable Bridge (SBridge) they will hear
any client with transmit rights. Let me be CLEAR, This
is one SBridge shared among multiple users. This is
NOT DVAAS (Digital Voice as a service)
We did not forget AllStar. You can have one or more
AllStar nodes directly connected to the Server.
AllStar users (by node) can be assigned rights. RX, TX
Tune. It's up to the Server owner how these
connections are controlled. Some Server users use
AllStar to mix audio from multiple modes. This is
usually done by bridging each mode into a seperate
AllStar "private node" This give the Server operator
the ability to connect and disconnect modes into the
main AllStar node. He can also directly connect 2
modes together without connecting those modes to
anything else. AllStar is VERY versatile that way. In
the case of unlike modes DMR (AMBE) to P25 (IMBE) this
works quite well.If you are connecting like modes YSFn
(AMBE) to NXDN (AMBE) this leave something to be
desired. This is transcoding where none is required.
It's up to the Server operator to decide if this is a
disadvantage. No matter if it's like modes or not,
using AllStar to bridge Digital Voice modes has one
downside, You loose the metadata that is transmitted
along with the voice. Some people don't care, the
advantages of mixing in AllStar outweighs the
disadvantages. I can make a case for either choice.
So, how do we give people another option. That option
is called Analog_Reflector. Consider a piece of
software tha t will accept multiple connections from
clients (DVSM, pyUC or hUC) it will also accept
connections from multiple AllStar nodes either on the
same server or a remote server. (via USRP) You can
have multiple bridges connected. These bridges are
fixed by mode and TG (reflector). Last but not lease
is a Steerable Bridge (SBridge) This is the bridge you
can change modes, you can change TGs it's exactly like
the bridge in DVSwitch Server now. Any client (with
the proper rights) can steer the bridge. This includes
The AllStar nodes. One big advantage, no more macros
needed (but still supported) The command path between
AllStar and the reflector is two way. We can send
commands for AllStar to the reflector (and on to the
SBridge) We can also receive commands from a connected
client and send them to AllStar. If you want to
connect your AllStar node to another AllStar node, you
can do it from a connected client. AllStar becomes
"just another mode" accessible from a connected
client. (Think Web tranceiver)
One last point I may have glossed over. EVERYBODY get
the metadata. Client, Bridges, AllStar and SBridges.
Everybody gets the data. Not everybody can do anything
with the metadata (AllStar) but AllStar does send what
little metadata it knows about the connected and
transmitting stations into the reflector.
Over the next few months we are going to build a
demonstration bridge. we will show you how to connect
like modes without transcoding. We will show you how
to send traffic to multiple modes at the same time. An
example of this is DMR to YSF AND P25. We are going to
do this with one instance of MMDVM_Bridge and a
transcoder. Everybody gets the audio, everybody gets
the metadata. Yes, it's all done with UDP ports. It's
all modular. Yes it can get complex. (we have some
thoughts in that area too)
DVSwitch is about giving you control. You control the
mode, you control the destination. You control the
metadata. It's your server. Do what YOU want.. There
is SO much more I did not cover (as Mike will tell me)
There is a admin interface for Analog_Reflector (and a
dashboard) Somebody "sitting on his mike"? Kick him or
mute him. Somebody abusing your server, ban him. I
won't promise you we have thought of everything. That
will come to light as we see tAnalog_Reflector in the
field.
For DVSwitch,
73, Steve N4IRS
|
|

Steve N4IRS
I can try Firefox on what IOS or ???
toggle quoted messageShow quoted text
On 12/22/20 7:22 PM, Jeff Lehman, N8ACL
via groups.io wrote:
Now you have sold me…. What about other mobile browsers like
Firefox? I mean I totally get that there are so many browsers out
there, it would be almost impossible to check them all. But still
Safari works for me for this….. Love it!
Jeff
On Dec 22, 2020, at 19:18, Steve N4IRS < szingman@...>
wrote:
The existing clients are Android any
Python. The python client pretty much runs on any
desktop system. As it happens, Mike is spending a LOT of
time making sure the HTML client runs on most browsers
and that includes Safari on IOS.
For the AllStar people among us, The clients will be
able to control the AllStar nodes.
On 12/22/20 7:14 PM, Jeff
Lehman, N8ACL via groups.io wrote:
I’ll be honest, I havn’t looked too closely at the
DVSwitch server because I don’t have an android
device. However, This is incredibly intriguing and
very much changing my mind about dedicating a PI to
this. I love the concept of multiple clients,
especially a web based one. Very much looking forward
to this…
Jeff
On Dec 22, 2020, at 19:06, Patrick
Perdue < patrick@...>
wrote:
Definitely looking forward to
this, especially if you can do something
like referencing the Allstarlink node
database and matching to ID's, if they
exist. Of course, there is a lot of room
for error, since the call sign field for
ASL nodes is technically arbitrary, but it
would be better than what exists now for
passing metadata to digital modes. There
are way too many people who look at
displays and don't listen.
On 12/22/2020
4:21 PM, Steve N4IRS wrote:
We have been talking about hUC (HTTP USRP
Client) since about the time we released
DVSwitch Server. So, where is it already?
hUC in it's early form did not really take
that long. Thought it connects to DVSwitch
Server differently, It's not much
different then pyUC (python USRP Client)
Then we started having our usual "what if"
discussions. Our wives will tell you this
can go on for days. A very big issue with
a web based client is security. If you
expose a HTML client to the internet,
people will play with it. This could be
disastrous. We need security to control
who can do what. I sure don't want anybody
with access to a search engine to start
talking on DMR TG 91 (with my call and DMR
ID) So, security had to be added.
Now I have this DVSwitch Server in the
cloud with a web interface and at least I
can control who has access. We know
DVSwitch Server is single user. It sure
would be nice if I can give my friends
access to my server. Let's face it, I'm
not using it all the time. I can share.
Some friends are more responsible then
others. I would like to give Jack the
ability to transmit, but not move the
Server to another mode or talk group
(tune). I would like to give Jill the
ability to listen, but no transmit and no
tune. OK, we can do that. Jack and Jill
can both listen to traffic on the server.
Jack can transmit. I am the only one that
can tune to another TG or mode. OK, this
is getting good.
We don't want to limit the fun to only web
clients. What about DVSM and pyUC users?
Yes, you can assign the same rights to
DVSM and pyUC users. You can have users
from all 3 clients with different rights.
Everybody that can listen will hear not
only the connected Steerable Bridge
(SBridge) they will hear any client with
transmit rights. Let me be CLEAR, This is
one SBridge shared among multiple users.
This is NOT DVAAS (Digital Voice as a
service)
We did not forget AllStar. You can have
one or more AllStar nodes directly
connected to the Server. AllStar users (by
node) can be assigned rights. RX, TX Tune.
It's up to the Server owner how these
connections are controlled. Some Server
users use AllStar to mix audio from
multiple modes. This is usually done by
bridging each mode into a seperate AllStar
"private node" This give the Server
operator the ability to connect and
disconnect modes into the main AllStar
node. He can also directly connect 2 modes
together without connecting those modes to
anything else. AllStar is VERY versatile
that way. In the case of unlike modes DMR
(AMBE) to P25 (IMBE) this works quite
well.If you are connecting like modes YSFn
(AMBE) to NXDN (AMBE) this leave something
to be desired. This is transcoding where
none is required. It's up to the Server
operator to decide if this is a
disadvantage. No matter if it's like modes
or not, using AllStar to bridge Digital
Voice modes has one downside, You loose
the metadata that is transmitted along
with the voice. Some people don't care,
the advantages of mixing in AllStar
outweighs the disadvantages. I can make a
case for either choice.
So, how do we give people another option.
That option is called Analog_Reflector.
Consider a piece of software tha t will
accept multiple connections from clients
(DVSM, pyUC or hUC) it will also accept
connections from multiple AllStar nodes
either on the same server or a remote
server. (via USRP) You can have multiple
bridges connected. These bridges are fixed
by mode and TG (reflector). Last but not
lease is a Steerable Bridge (SBridge) This
is the bridge you can change modes, you
can change TGs it's exactly like the
bridge in DVSwitch Server now. Any client
(with the proper rights) can steer the
bridge. This includes The AllStar nodes.
One big advantage, no more macros needed
(but still supported) The command path
between AllStar and the reflector is two
way. We can send commands for AllStar to
the reflector (and on to the SBridge) We
can also receive commands from a connected
client and send them to AllStar. If you
want to connect your AllStar node to
another AllStar node, you can do it from a
connected client. AllStar becomes "just
another mode" accessible from a connected
client. (Think Web tranceiver)
One last point I may have glossed over.
EVERYBODY get the metadata. Client,
Bridges, AllStar and SBridges. Everybody
gets the data. Not everybody can do
anything with the metadata (AllStar) but
AllStar does send what little metadata it
knows about the connected and transmitting
stations into the reflector.
Over the next few months we are going to
build a demonstration bridge. we will show
you how to connect like modes without
transcoding. We will show you how to send
traffic to multiple modes at the same
time. An example of this is DMR to YSF AND
P25. We are going to do this with one
instance of MMDVM_Bridge and a transcoder.
Everybody gets the audio, everybody gets
the metadata. Yes, it's all done with UDP
ports. It's all modular. Yes it can get
complex. (we have some thoughts in that
area too)
DVSwitch is about giving you control. You
control the mode, you control the
destination. You control the metadata.
It's your server. Do what YOU want.. There
is SO much more I did not cover (as Mike
will tell me) There is a admin interface
for Analog_Reflector (and a dashboard)
Somebody "sitting on his mike"? Kick him
or mute him. Somebody abusing your server,
ban him. I won't promise you we have
thought of everything. That will come to
light as we see tAnalog_Reflector in the
field.
For DVSwitch,
73, Steve N4IRS
|
|
Oops… sorry….. yes iOS...
toggle quoted messageShow quoted text
On Dec 22, 2020, at 19:24, Steve N4IRS < szingman@...> wrote:
I can try Firefox on what IOS or ???
On 12/22/20 7:22 PM, Jeff Lehman, N8ACL
via groups.io wrote:
Now you have sold me…. What about other mobile browsers like
Firefox? I mean I totally get that there are so many browsers out
there, it would be almost impossible to check them all. But still
Safari works for me for this….. Love it!
Jeff
On Dec 22, 2020, at 19:18, Steve N4IRS < szingman@...>
wrote:
The existing clients are Android any
Python. The python client pretty much runs on any
desktop system. As it happens, Mike is spending a LOT of
time making sure the HTML client runs on most browsers
and that includes Safari on IOS.
For the AllStar people among us, The clients will be
able to control the AllStar nodes.
On 12/22/20 7:14 PM, Jeff
Lehman, N8ACL via groups.io wrote:
I’ll be honest, I havn’t looked too closely at the
DVSwitch server because I don’t have an android
device. However, This is incredibly intriguing and
very much changing my mind about dedicating a PI to
this. I love the concept of multiple clients,
especially a web based one. Very much looking forward
to this…
Jeff
On Dec 22, 2020, at 19:06, Patrick
Perdue < patrick@...>
wrote:
Definitely looking forward to
this, especially if you can do something
like referencing the Allstarlink node
database and matching to ID's, if they
exist. Of course, there is a lot of room
for error, since the call sign field for
ASL nodes is technically arbitrary, but it
would be better than what exists now for
passing metadata to digital modes. There
are way too many people who look at
displays and don't listen.
On 12/22/2020
4:21 PM, Steve N4IRS wrote:
We have been talking about hUC (HTTP USRP
Client) since about the time we released
DVSwitch Server. So, where is it already?
hUC in it's early form did not really take
that long. Thought it connects to DVSwitch
Server differently, It's not much
different then pyUC (python USRP Client)
Then we started having our usual "what if"
discussions. Our wives will tell you this
can go on for days. A very big issue with
a web based client is security. If you
expose a HTML client to the internet,
people will play with it. This could be
disastrous. We need security to control
who can do what. I sure don't want anybody
with access to a search engine to start
talking on DMR TG 91 (with my call and DMR
ID) So, security had to be added.
Now I have this DVSwitch Server in the
cloud with a web interface and at least I
can control who has access. We know
DVSwitch Server is single user. It sure
would be nice if I can give my friends
access to my server. Let's face it, I'm
not using it all the time. I can share.
Some friends are more responsible then
others. I would like to give Jack the
ability to transmit, but not move the
Server to another mode or talk group
(tune). I would like to give Jill the
ability to listen, but no transmit and no
tune. OK, we can do that. Jack and Jill
can both listen to traffic on the server.
Jack can transmit. I am the only one that
can tune to another TG or mode. OK, this
is getting good.
We don't want to limit the fun to only web
clients. What about DVSM and pyUC users?
Yes, you can assign the same rights to
DVSM and pyUC users. You can have users
from all 3 clients with different rights.
Everybody that can listen will hear not
only the connected Steerable Bridge
(SBridge) they will hear any client with
transmit rights. Let me be CLEAR, This is
one SBridge shared among multiple users.
This is NOT DVAAS (Digital Voice as a
service)
We did not forget AllStar. You can have
one or more AllStar nodes directly
connected to the Server. AllStar users (by
node) can be assigned rights. RX, TX Tune.
It's up to the Server owner how these
connections are controlled. Some Server
users use AllStar to mix audio from
multiple modes. This is usually done by
bridging each mode into a seperate AllStar
"private node" This give the Server
operator the ability to connect and
disconnect modes into the main AllStar
node. He can also directly connect 2 modes
together without connecting those modes to
anything else. AllStar is VERY versatile
that way. In the case of unlike modes DMR
(AMBE) to P25 (IMBE) this works quite
well.If you are connecting like modes YSFn
(AMBE) to NXDN (AMBE) this leave something
to be desired. This is transcoding where
none is required. It's up to the Server
operator to decide if this is a
disadvantage. No matter if it's like modes
or not, using AllStar to bridge Digital
Voice modes has one downside, You loose
the metadata that is transmitted along
with the voice. Some people don't care,
the advantages of mixing in AllStar
outweighs the disadvantages. I can make a
case for either choice.
So, how do we give people another option.
That option is called Analog_Reflector.
Consider a piece of software tha t will
accept multiple connections from clients
(DVSM, pyUC or hUC) it will also accept
connections from multiple AllStar nodes
either on the same server or a remote
server. (via USRP) You can have multiple
bridges connected. These bridges are fixed
by mode and TG (reflector). Last but not
lease is a Steerable Bridge (SBridge) This
is the bridge you can change modes, you
can change TGs it's exactly like the
bridge in DVSwitch Server now. Any client
(with the proper rights) can steer the
bridge. This includes The AllStar nodes.
One big advantage, no more macros needed
(but still supported) The command path
between AllStar and the reflector is two
way. We can send commands for AllStar to
the reflector (and on to the SBridge) We
can also receive commands from a connected
client and send them to AllStar. If you
want to connect your AllStar node to
another AllStar node, you can do it from a
connected client. AllStar becomes "just
another mode" accessible from a connected
client. (Think Web tranceiver)
One last point I may have glossed over.
EVERYBODY get the metadata. Client,
Bridges, AllStar and SBridges. Everybody
gets the data. Not everybody can do
anything with the metadata (AllStar) but
AllStar does send what little metadata it
knows about the connected and transmitting
stations into the reflector.
Over the next few months we are going to
build a demonstration bridge. we will show
you how to connect like modes without
transcoding. We will show you how to send
traffic to multiple modes at the same
time. An example of this is DMR to YSF AND
P25. We are going to do this with one
instance of MMDVM_Bridge and a transcoder.
Everybody gets the audio, everybody gets
the metadata. Yes, it's all done with UDP
ports. It's all modular. Yes it can get
complex. (we have some thoughts in that
area too)
DVSwitch is about giving you control. You
control the mode, you control the
destination. You control the metadata.
It's your server. Do what YOU want.. There
is SO much more I did not cover (as Mike
will tell me) There is a admin interface
for Analog_Reflector (and a dashboard)
Somebody "sitting on his mike"? Kick him
or mute him. Somebody abusing your server,
ban him. I won't promise you we have
thought of everything. That will come to
light as we see tAnalog_Reflector in the
field.
For DVSwitch,
73, Steve N4IRS
|
|

Mike Zingman - N4IRR
Jeff,
Apple (being the control freaks that they are) specifically cripple any other browser than Safari. I have tested on Chrome and have found that the web audio implementation is broken (on purpose). Safari on iOS does actually work very well for the html client, but I suspect Firefox will be the same as Chrome.
Gotta love Apple.
Mike
|
|
I figured that was the case. While the walled garden that is Apple is nice in some respects, in others it really can be a pain the butt. But still, the fact that safari works is amazing, so using that is not an issue.
Thanks for checking. I still am very much looking forward to when this is released. It’s such a cool evolution of DVS.
toggle quoted messageShow quoted text
On Dec 23, 2020, at 06:11, Mike Zingman - N4IRR <mike.zingman@...> wrote:
Jeff,
Apple (being the control freaks that they are) specifically cripple any other browser than Safari. I have tested on Chrome and have found that the web audio implementation is broken (on purpose). Safari on iOS does actually work very well for the html client, but I suspect Firefox will be the same as Chrome.
Gotta love Apple.
Mike
|
|
On 23/12/20 8:21 am, Steve N4IRS wrote: So, how do we give people another option. That option is called Analog_Reflector. Consider a piece of software tha t will accept multiple connections from clients (DVSM, pyUC or hUC) it will also accept connections from multiple AllStar nodes either on the same server or a remote server. (via USRP) You can have multiple bridges Now this sounds awesome. I'm currently using AllStar as my main bridge. Currently, only traffic from modes with dissimilar vocoders traverses AllStar (DMR - YSF has its own dedicated MMDVM_Bridge instance). I'm not keen on losing the metadata on traffic that traverses AllStar, but at least I can guarantee minimum degradation of the audio. Analog_Reflector sounds like just what I'm looking for, and its additional features sound pretty cool too. I will definitely be upgrading to this, when it's available. :) DVSwitch is about giving you control. You control the mode, you control the destination. You control the metadata. It's your server. Do what YOU want.. There is SO much more I did not cover (as Mike will tell me) There is a admin interface for Analog_Reflector (and a dashboard) Somebody "sitting on his mike"? Kick him or mute him. Somebody abusing your server, ban him. I won't promise you we have thought of everything. That will come to light as we see tAnalog_Reflector in the field. This looks like fun. I have two use scenarios here, which are very different: 1. The multimode reflector. This is a system that bridges 4 DV modes, plus AllStar. The main advantages of Analogue Reflector here would be preservation of metadata, as well as the ability to isolate modes as needed, plus access control. I would be the only one with the keys to the city, initially. I may delegate some functions down the line. 2. I have an instance of DVSwitch on my AllStar node here. This one is to allow AllStar to connect directly to any arbitrary destination. Analogue_Reflector could simplify a lot of things here. I could also use it to link to other software (that I can make speak USRP in one way or another). :) -- 73 de Tony VK3JED/VK3IRL http://vkradio.com
|
|
On 23/12/20 11:18 am, Steve N4IRS wrote: The existing clients are Android any Python. The python client pretty much runs on any desktop system. As it happens, Mike is spending a LOT of time making sure the HTML client runs on most browsers and that includes Safari on IOS. For the AllStar people among us, The clients will be able to control the AllStar nodes. Another thing to look forward to! I love DVSwitch Mobile on my Android, but sometimes I only have the iPhone with me. Sold me yet again! :D -- 73 de Tony VK3JED/VK3IRL http://vkradio.com
|
|

Steve N4IRS
Happy new year to all! Just a quick update, The HTML Client (hUC) and the Analog_Reflector have gone into beta test as of today. The beta team will now start trying to break it and comment on features etc. I do not have a time frame as to when this goes to full release. We will need to package it for installation and document how to install, manage and use.
73, Steve N4IRS
|
|
Happy new year. great news. Thanks Steve
toggle quoted messageShow quoted text
El vie, 1 ene 2021 a las 18:38, Steve N4IRS (< szingman@...>) escribió: Happy new year to all! Just a quick update, The HTML Client (hUC) and the Analog_Reflector have gone into beta test as of today. The beta team will now start trying to break it and comment on features etc. I do not have a time frame as to when this goes to full release. We will need to package it for installation and document how to install, manage and use.
73, Steve N4IRS
|
|

Bruno
Bonne année 2021. France.
toggle quoted messageShow quoted text
Le ven. 1 janv. 2021 à 19:14, EA5GVK Joaquin < ea5gvk@...> a écrit : Happy new year. great news. Thanks Steve
El vie, 1 ene 2021 a las 18:38, Steve N4IRS (< szingman@...>) escribió: Happy new year to all! Just a quick update, The HTML Client (hUC) and the Analog_Reflector have gone into beta test as of today. The beta team will now start trying to break it and comment on features etc. I do not have a time frame as to when this goes to full release. We will need to package it for installation and document how to install, manage and use.
73, Steve N4IRS
-- Hello everyone,
I want to set up a Link between HBLink and a room Wires-X from Yeasu in C4FM. Is there a possibility to set up the type of editing.
73 to all.
F1PTL Bruno
|
|
On 2/1/21 4:38 am, Steve N4IRS wrote: Happy new year to all! Just a quick update, The HTML Client (hUC) and the Analog_Reflector have gone into beta test as of today. The beta team will now start trying to break it and comment on features etc. I do not have a time frame as to when this goes to full release. We will need to package it for installation and document how to install, manage and use. Great news Steve. I can't wait for Analog_Reflector. :) -- 73 de Tony VK3JED/VK3IRL http://vkradio.com
|
|