Progress has been made. I finally got a chance to focus back on the return channel of the gateway and it works. I have had successful QSOs using the new code where: Analog Radio <----> DIAL w/ USRP <----> DMRGateway <----> DMRLink <---> TG9998 This was a full two way path with the DV3000 doing both encode and decode. ambe_audio.py has been extensively modified to support the return channel and DMRGateway is tasked with the Allstar to DMR linkage. This code is not ready for prime time yet (the configuration files need to be updated with additional values, error checking, code cleanup/refactoring) but an Alpha release will be available to all testers soon. Once the code is cleaned up all source will be released to allow others to modify/extend. I specifically want to thank Cort for his amazing code base. Without it, there is no way I could have added this functionality. Open source rocks. This is so cool, thanks!!!! Mike
Mike.... this is good stuff, and congrats on your achievement! I am still largely new to this as you aware, but in the ASCII diagram you provided you mention "DIAL w/ USRP" ... just to clarify, is that the USRP channel driver or a USRP itself, or both? Just trying to get a feel for what might be needed to support this for myself from a hardware standpoint. 73 Stephen K1LNX On Wed, Jan 27, 2016 at 4:53 PM, Mike Zingman <mike.zingman@gmail.com> wrote:
Progress has been made. I finally got a chance to focus back on the return channel of the gateway and it works. I have had successful QSOs using the new code where:
Analog Radio <----> DIAL w/ USRP <----> DMRGateway <----> DMRLink <---> TG9998
This was a full two way path with the DV3000 doing both encode and decode. ambe_audio.py has been extensively modified to support the return channel and DMRGateway is tasked with the Allstar to DMR linkage.
This code is not ready for prime time yet (the configuration files need to be updated with additional values, error checking, code cleanup/refactoring) but an Alpha release will be available to all testers soon.
Once the code is cleaned up all source will be released to allow others to modify/extend.
I specifically want to thank Cort for his amazing code base. Without it, there is no way I could have added this functionality. Open source rocks. This is so cool, thanks!!!!
Mike
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
It is the USRP Channel driver. It is included in the DIAL distribution. May be also available to lesser distributions. Steve On 01/28/2016 02:28 PM, Stephen - K1LNX wrote:
Mike.... this is good stuff, and congrats on your achievement!
I am still largely new to this as you aware, but in the ASCII diagram you provided you mention "DIAL w/ USRP" ... just to clarify, is that the USRP channel driver or a USRP itself, or both? Just trying to get a feel for what might be needed to support this for myself from a hardware standpoint.
73 Stephen K1LNX
On Wed, Jan 27, 2016 at 4:53 PM, Mike Zingman <mike.zingman@gmail.com <mailto:mike.zingman@gmail.com>> wrote:
Progress has been made. I finally got a chance to focus back on the return channel of the gateway and it works. I have had successful QSOs using the new code where:
Analog Radio <----> DIAL w/ USRP <----> DMRGateway <----> DMRLink <---> TG9998
This was a full two way path with the DV3000 doing both encode and decode. ambe_audio.py has been extensively modified to support the return channel and DMRGateway is tasked with the Allstar to DMR linkage.
This code is not ready for prime time yet (the configuration files need to be updated with additional values, error checking, code cleanup/refactoring) but an Alpha release will be available to all testers soon.
Once the code is cleaned up all source will be released to allow others to modify/extend.
I specifically want to thank Cort for his amazing code base. Without it, there is no way I could have added this functionality. Open source rocks. This is so cool, thanks!!!!
Mike
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org <mailto:Allstar-Digital@lists.keekles.org> http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
-- "Anything is possible if you don't know what you are talking about." 1st Law of Logic
Stephen, Yes, exactly. You need to enable the USRP channel driver in modules and then configure it in rpt.conf and you are good to go. On Thu, Jan 28, 2016 at 2:28 PM, Stephen - K1LNX <k1lnx@k1lnx.net> wrote:
Mike.... this is good stuff, and congrats on your achievement!
I am still largely new to this as you aware, but in the ASCII diagram you provided you mention "DIAL w/ USRP" ... just to clarify, is that the USRP channel driver or a USRP itself, or both? Just trying to get a feel for what might be needed to support this for myself from a hardware standpoint.
73 Stephen K1LNX
On Wed, Jan 27, 2016 at 4:53 PM, Mike Zingman <mike.zingman@gmail.com> wrote:
Progress has been made. I finally got a chance to focus back on the return channel of the gateway and it works. I have had successful QSOs using the new code where:
Analog Radio <----> DIAL w/ USRP <----> DMRGateway <----> DMRLink <---> TG9998
This was a full two way path with the DV3000 doing both encode and decode. ambe_audio.py has been extensively modified to support the return channel and DMRGateway is tasked with the Allstar to DMR linkage.
This code is not ready for prime time yet (the configuration files need to be updated with additional values, error checking, code cleanup/refactoring) but an Alpha release will be available to all testers soon.
Once the code is cleaned up all source will be released to allow others to modify/extend.
I specifically want to thank Cort for his amazing code base. Without it, there is no way I could have added this functionality. Open source rocks. This is so cool, thanks!!!!
Mike
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
Working on it. On 01/28/2016 02:31 PM, Mike Zingman wrote:
Stephen,
Yes, exactly. You need to enable the USRP channel driver in modules and then configure it in rpt.conf and you are good to go.
On Thu, Jan 28, 2016 at 2:28 PM, Stephen - K1LNX <k1lnx@k1lnx.net <mailto:k1lnx@k1lnx.net>> wrote:
Mike.... this is good stuff, and congrats on your achievement!
I am still largely new to this as you aware, but in the ASCII diagram you provided you mention "DIAL w/ USRP" ... just to clarify, is that the USRP channel driver or a USRP itself, or both? Just trying to get a feel for what might be needed to support this for myself from a hardware standpoint.
73 Stephen K1LNX
On Wed, Jan 27, 2016 at 4:53 PM, Mike Zingman <mike.zingman@gmail.com <mailto:mike.zingman@gmail.com>> wrote:
Progress has been made. I finally got a chance to focus back on the return channel of the gateway and it works. I have had successful QSOs using the new code where:
Analog Radio <----> DIAL w/ USRP <----> DMRGateway <----> DMRLink <---> TG9998
This was a full two way path with the DV3000 doing both encode and decode. ambe_audio.py has been extensively modified to support the return channel and DMRGateway is tasked with the Allstar to DMR linkage.
This code is not ready for prime time yet (the configuration files need to be updated with additional values, error checking, code cleanup/refactoring) but an Alpha release will be available to all testers soon.
Once the code is cleaned up all source will be released to allow others to modify/extend.
I specifically want to thank Cort for his amazing code base. Without it, there is no way I could have added this functionality. Open source rocks. This is so cool, thanks!!!!
Mike
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org <mailto:Allstar-Digital@lists.keekles.org> http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org <mailto:Allstar-Digital@lists.keekles.org> http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
-- "Anything is possible if you don't know what you are talking about." 1st Law of Logic
Stephen, DMRGateway was created with the idea of how do we get audio in and out of asterisk without any modifications to asterisk or app_rpt. chan_usrp fit the bill perfectly. It provides a simple way to send and receive audio (PCM) and the signaling (COS and PTT) needed. Steve On 01/28/2016 02:28 PM, Stephen - K1LNX wrote:
Mike.... this is good stuff, and congrats on your achievement!
I am still largely new to this as you aware, but in the ASCII diagram you provided you mention "DIAL w/ USRP" ... just to clarify, is that the USRP channel driver or a USRP itself, or both? Just trying to get a feel for what might be needed to support this for myself from a hardware standpoint.
73 Stephen K1LNX
On Wed, Jan 27, 2016 at 4:53 PM, Mike Zingman <mike.zingman@gmail.com <mailto:mike.zingman@gmail.com>> wrote:
Progress has been made. I finally got a chance to focus back on the return channel of the gateway and it works. I have had successful QSOs using the new code where:
Analog Radio <----> DIAL w/ USRP <----> DMRGateway <----> DMRLink <---> TG9998
This was a full two way path with the DV3000 doing both encode and decode. ambe_audio.py has been extensively modified to support the return channel and DMRGateway is tasked with the Allstar to DMR linkage.
This code is not ready for prime time yet (the configuration files need to be updated with additional values, error checking, code cleanup/refactoring) but an Alpha release will be available to all testers soon.
Once the code is cleaned up all source will be released to allow others to modify/extend.
I specifically want to thank Cort for his amazing code base. Without it, there is no way I could have added this functionality. Open source rocks. This is so cool, thanks!!!!
Mike
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org <mailto:Allstar-Digital@lists.keekles.org> http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
-- "Anything is possible if you don't know what you are talking about." 1st Law of Logic
Thanks Steve, I really need to get off my duff and start playing with this thing. Are thereany example configs for USRP anywhere (assuming it even needs one)? I looked through your GitHub source tree as well as my own test vm I built, but nothing glares out at me. Stephen K1LNX On Thu, Jan 28, 2016 at 2:46 PM, Steve Zingman <szingman@msgstor.com> wrote:
Stephen, DMRGateway was created with the idea of how do we get audio in and out of asterisk without any modifications to asterisk or app_rpt. chan_usrp fit the bill perfectly. It provides a simple way to send and receive audio (PCM) and the signaling (COS and PTT) needed.
Steve
On 01/28/2016 02:28 PM, Stephen - K1LNX wrote:
Mike.... this is good stuff, and congrats on your achievement!
I am still largely new to this as you aware, but in the ASCII diagram you provided you mention "DIAL w/ USRP" ... just to clarify, is that the USRP channel driver or a USRP itself, or both? Just trying to get a feel for what might be needed to support this for myself from a hardware standpoint.
73 Stephen K1LNX
On Wed, Jan 27, 2016 at 4:53 PM, Mike Zingman <mike.zingman@gmail.com> wrote:
Progress has been made. I finally got a chance to focus back on the return channel of the gateway and it works. I have had successful QSOs using the new code where:
Analog Radio <----> DIAL w/ USRP <----> DMRGateway <----> DMRLink <---> TG9998
This was a full two way path with the DV3000 doing both encode and decode. ambe_audio.py has been extensively modified to support the return channel and DMRGateway is tasked with the Allstar to DMR linkage.
This code is not ready for prime time yet (the configuration files need to be updated with additional values, error checking, code cleanup/refactoring) but an Alpha release will be available to all testers soon.
Once the code is cleaned up all source will be released to allow others to modify/extend.
I specifically want to thank Cort for his amazing code base. Without it, there is no way I could have added this functionality. Open source rocks. This is so cool, thanks!!!!
Mike
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
_______________________________________________ Allstar-Digital mailing listAllstar-Digital@lists.keekles.orghttp://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
-- "Anything is possible if you don't know what you are talking about." 1st Law of Logic
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
There is no config file for chan_usrp. It's setup in app_rpt. rxchannel = usrp/127.0.0.1:34001:32001 ; ipaddress_to_use:output_port:input_port On 01/28/2016 02:58 PM, Stephen - K1LNX wrote:
Thanks Steve, I really need to get off my duff and start playing with this thing. Are thereany example configs for USRP anywhere (assuming it even needs one)? I looked through your GitHub source tree as well as my own test vm I built, but nothing glares out at me.
Stephen K1LNX
On Thu, Jan 28, 2016 at 2:46 PM, Steve Zingman <szingman@msgstor.com <mailto:szingman@msgstor.com>> wrote:
Stephen, DMRGateway was created with the idea of how do we get audio in and out of asterisk without any modifications to asterisk or app_rpt. chan_usrp fit the bill perfectly. It provides a simple way to send and receive audio (PCM) and the signaling (COS and PTT) needed.
Steve
On 01/28/2016 02:28 PM, Stephen - K1LNX wrote:
Mike.... this is good stuff, and congrats on your achievement!
I am still largely new to this as you aware, but in the ASCII diagram you provided you mention "DIAL w/ USRP" ... just to clarify, is that the USRP channel driver or a USRP itself, or both? Just trying to get a feel for what might be needed to support this for myself from a hardware standpoint.
73 Stephen K1LNX
On Wed, Jan 27, 2016 at 4:53 PM, Mike Zingman <mike.zingman@gmail.com <mailto:mike.zingman@gmail.com>> wrote:
Progress has been made. I finally got a chance to focus back on the return channel of the gateway and it works. I have had successful QSOs using the new code where:
Analog Radio <----> DIAL w/ USRP <----> DMRGateway <----> DMRLink <---> TG9998
This was a full two way path with the DV3000 doing both encode and decode. ambe_audio.py has been extensively modified to support the return channel and DMRGateway is tasked with the Allstar to DMR linkage.
This code is not ready for prime time yet (the configuration files need to be updated with additional values, error checking, code cleanup/refactoring) but an Alpha release will be available to all testers soon.
Once the code is cleaned up all source will be released to allow others to modify/extend.
I specifically want to thank Cort for his amazing code base. Without it, there is no way I could have added this functionality. Open source rocks. This is so cool, thanks!!!!
Mike
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org <mailto:Allstar-Digital@lists.keekles.org> http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org <mailto:Allstar-Digital@lists.keekles.org> http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
-- "Anything is possible if you don't know what you are talking about." 1st Law of Logic
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org <mailto:Allstar-Digital@lists.keekles.org> http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
-- "Anything is possible if you don't know what you are talking about." 1st Law of Logic
Here is my test stanza (1999 is then linked to my public node when I want it). Note that the older configs show duplex = 2 and I now have mine set to simplex with no telemetry. This is because I would get "feedback" if it was duplex and the no-telemetry is to stop any extra crap from getting on the DMR network. 192.168.1.188 is the address of my development machine where I am debugging the DMRGateway code. Once it is solid, I will move it to the same Raspberry Pi as ASL. [1999] rxchannel = usrp/192.168.1.188:34001:32001 duplex = 0 scheduler=scheduler functions = functions-repeater hangtime=0 authlevel = 0 On Thu, Jan 28, 2016 at 3:02 PM, Steve Zingman <szingman@msgstor.com> wrote:
There is no config file for chan_usrp. It's setup in app_rpt.
rxchannel = usrp/127.0.0.1:34001:32001 ; ipaddress_to_use:output_port:input_port
On 01/28/2016 02:58 PM, Stephen - K1LNX wrote:
Thanks Steve, I really need to get off my duff and start playing with this thing. Are thereany example configs for USRP anywhere (assuming it even needs one)? I looked through your GitHub source tree as well as my own test vm I built, but nothing glares out at me.
Stephen K1LNX
On Thu, Jan 28, 2016 at 2:46 PM, Steve Zingman <szingman@msgstor.com> wrote:
Stephen, DMRGateway was created with the idea of how do we get audio in and out of asterisk without any modifications to asterisk or app_rpt. chan_usrp fit the bill perfectly. It provides a simple way to send and receive audio (PCM) and the signaling (COS and PTT) needed.
Steve
On 01/28/2016 02:28 PM, Stephen - K1LNX wrote:
Mike.... this is good stuff, and congrats on your achievement!
I am still largely new to this as you aware, but in the ASCII diagram you provided you mention "DIAL w/ USRP" ... just to clarify, is that the USRP channel driver or a USRP itself, or both? Just trying to get a feel for what might be needed to support this for myself from a hardware standpoint.
73 Stephen K1LNX
On Wed, Jan 27, 2016 at 4:53 PM, Mike Zingman < <mike.zingman@gmail.com> mike.zingman@gmail.com> wrote:
Progress has been made. I finally got a chance to focus back on the return channel of the gateway and it works. I have had successful QSOs using the new code where:
Analog Radio <----> DIAL w/ USRP <----> DMRGateway <----> DMRLink <---> TG9998
This was a full two way path with the DV3000 doing both encode and decode. ambe_audio.py has been extensively modified to support the return channel and DMRGateway is tasked with the Allstar to DMR linkage.
This code is not ready for prime time yet (the configuration files need to be updated with additional values, error checking, code cleanup/refactoring) but an Alpha release will be available to all testers soon.
Once the code is cleaned up all source will be released to allow others to modify/extend.
I specifically want to thank Cort for his amazing code base. Without it, there is no way I could have added this functionality. Open source rocks. This is so cool, thanks!!!!
Mike
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
_______________________________________________ Allstar-Digital mailing listAllstar-Digital@lists.keekles.orghttp://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
-- "Anything is possible if you don't know what you are talking about." 1st Law of Logic
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
_______________________________________________ Allstar-Digital mailing listAllstar-Digital@lists.keekles.orghttp://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
-- "Anything is possible if you don't know what you are talking about." 1st Law of Logic
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
This is excellent and timely information. I've been working in securing my network feeds on dmrlink. I think I'm ready to start working with my DV3000. Looking forward to having this all come together. Then I can start my mmdvm, I've already gotten on the waiting list for boards. N1XBM Apparare Scientor Paratus Communicare Allstar Node # 27086, 41540, 41812, 42086, 42658 On Jan 28, 2016 3:10 PM, "Mike Zingman" <mike.zingman@gmail.com> wrote:
Here is my test stanza (1999 is then linked to my public node when I want it). Note that the older configs show duplex = 2 and I now have mine set to simplex with no telemetry. This is because I would get "feedback" if it was duplex and the no-telemetry is to stop any extra crap from getting on the DMR network.
192.168.1.188 is the address of my development machine where I am debugging the DMRGateway code. Once it is solid, I will move it to the same Raspberry Pi as ASL.
[1999]
rxchannel = usrp/192.168.1.188:34001:32001
duplex = 0
scheduler=scheduler
functions = functions-repeater
hangtime=0
authlevel = 0
On Thu, Jan 28, 2016 at 3:02 PM, Steve Zingman <szingman@msgstor.com> wrote:
There is no config file for chan_usrp. It's setup in app_rpt.
rxchannel = usrp/127.0.0.1:34001:32001 ; ipaddress_to_use:output_port:input_port
On 01/28/2016 02:58 PM, Stephen - K1LNX wrote:
Thanks Steve, I really need to get off my duff and start playing with this thing. Are thereany example configs for USRP anywhere (assuming it even needs one)? I looked through your GitHub source tree as well as my own test vm I built, but nothing glares out at me.
Stephen K1LNX
On Thu, Jan 28, 2016 at 2:46 PM, Steve Zingman <szingman@msgstor.com> wrote:
Stephen, DMRGateway was created with the idea of how do we get audio in and out of asterisk without any modifications to asterisk or app_rpt. chan_usrp fit the bill perfectly. It provides a simple way to send and receive audio (PCM) and the signaling (COS and PTT) needed.
Steve
On 01/28/2016 02:28 PM, Stephen - K1LNX wrote:
Mike.... this is good stuff, and congrats on your achievement!
I am still largely new to this as you aware, but in the ASCII diagram you provided you mention "DIAL w/ USRP" ... just to clarify, is that the USRP channel driver or a USRP itself, or both? Just trying to get a feel for what might be needed to support this for myself from a hardware standpoint.
73 Stephen K1LNX
On Wed, Jan 27, 2016 at 4:53 PM, Mike Zingman < <mike.zingman@gmail.com> mike.zingman@gmail.com> wrote:
Progress has been made. I finally got a chance to focus back on the return channel of the gateway and it works. I have had successful QSOs using the new code where:
Analog Radio <----> DIAL w/ USRP <----> DMRGateway <----> DMRLink <---> TG9998
This was a full two way path with the DV3000 doing both encode and decode. ambe_audio.py has been extensively modified to support the return channel and DMRGateway is tasked with the Allstar to DMR linkage.
This code is not ready for prime time yet (the configuration files need to be updated with additional values, error checking, code cleanup/refactoring) but an Alpha release will be available to all testers soon.
Once the code is cleaned up all source will be released to allow others to modify/extend.
I specifically want to thank Cort for his amazing code base. Without it, there is no way I could have added this functionality. Open source rocks. This is so cool, thanks!!!!
Mike
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
_______________________________________________ Allstar-Digital mailing listAllstar-Digital@lists.keekles.orghttp://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
-- "Anything is possible if you don't know what you are talking about." 1st Law of Logic
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
_______________________________________________ Allstar-Digital mailing listAllstar-Digital@lists.keekles.orghttp://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
-- "Anything is possible if you don't know what you are talking about." 1st Law of Logic
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
Robert, Use the existing release (1 way) to get DMRGateway/DMR3000 set up. Everything that comes after (2 way) builds on this foundation so there is no reason to wait. On Thu, Jan 28, 2016 at 3:14 PM, Robert Newberry <N1XBM@amsat.org> wrote:
This is excellent and timely information. I've been working in securing my network feeds on dmrlink. I think I'm ready to start working with my DV3000. Looking forward to having this all come together.
Then I can start my mmdvm, I've already gotten on the waiting list for boards.
N1XBM Apparare Scientor Paratus Communicare Allstar Node # 27086, 41540, 41812, 42086, 42658
On Jan 28, 2016 3:10 PM, "Mike Zingman" <mike.zingman@gmail.com> wrote:
Here is my test stanza (1999 is then linked to my public node when I want it). Note that the older configs show duplex = 2 and I now have mine set to simplex with no telemetry. This is because I would get "feedback" if it was duplex and the no-telemetry is to stop any extra crap from getting on the DMR network.
192.168.1.188 is the address of my development machine where I am debugging the DMRGateway code. Once it is solid, I will move it to the same Raspberry Pi as ASL.
[1999]
rxchannel = usrp/192.168.1.188:34001:32001
duplex = 0
scheduler=scheduler
functions = functions-repeater
hangtime=0
authlevel = 0
On Thu, Jan 28, 2016 at 3:02 PM, Steve Zingman <szingman@msgstor.com> wrote:
There is no config file for chan_usrp. It's setup in app_rpt.
rxchannel = usrp/127.0.0.1:34001:32001 ; ipaddress_to_use:output_port:input_port
On 01/28/2016 02:58 PM, Stephen - K1LNX wrote:
Thanks Steve, I really need to get off my duff and start playing with this thing. Are thereany example configs for USRP anywhere (assuming it even needs one)? I looked through your GitHub source tree as well as my own test vm I built, but nothing glares out at me.
Stephen K1LNX
On Thu, Jan 28, 2016 at 2:46 PM, Steve Zingman <szingman@msgstor.com> wrote:
Stephen, DMRGateway was created with the idea of how do we get audio in and out of asterisk without any modifications to asterisk or app_rpt. chan_usrp fit the bill perfectly. It provides a simple way to send and receive audio (PCM) and the signaling (COS and PTT) needed.
Steve
On 01/28/2016 02:28 PM, Stephen - K1LNX wrote:
Mike.... this is good stuff, and congrats on your achievement!
I am still largely new to this as you aware, but in the ASCII diagram you provided you mention "DIAL w/ USRP" ... just to clarify, is that the USRP channel driver or a USRP itself, or both? Just trying to get a feel for what might be needed to support this for myself from a hardware standpoint.
73 Stephen K1LNX
On Wed, Jan 27, 2016 at 4:53 PM, Mike Zingman < <mike.zingman@gmail.com>mike.zingman@gmail.com> wrote:
Progress has been made. I finally got a chance to focus back on the return channel of the gateway and it works. I have had successful QSOs using the new code where:
Analog Radio <----> DIAL w/ USRP <----> DMRGateway <----> DMRLink <---> TG9998
This was a full two way path with the DV3000 doing both encode and decode. ambe_audio.py has been extensively modified to support the return channel and DMRGateway is tasked with the Allstar to DMR linkage.
This code is not ready for prime time yet (the configuration files need to be updated with additional values, error checking, code cleanup/refactoring) but an Alpha release will be available to all testers soon.
Once the code is cleaned up all source will be released to allow others to modify/extend.
I specifically want to thank Cort for his amazing code base. Without it, there is no way I could have added this functionality. Open source rocks. This is so cool, thanks!!!!
Mike
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
_______________________________________________ Allstar-Digital mailing listAllstar-Digital@lists.keekles.orghttp://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
-- "Anything is possible if you don't know what you are talking about." 1st Law of Logic
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
_______________________________________________ Allstar-Digital mailing listAllstar-Digital@lists.keekles.orghttp://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
-- "Anything is possible if you don't know what you are talking about." 1st Law of Logic
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
Ok great that was my plan. If I can get it running halfway...the rest in theory should be easy. Thanks N1XBM Apparare Scientor Paratus Communicare Allstar Node # 27086, 41540, 41812, 42086, 42658
Congratulations Mike, Cort and group! I will looking for the alpha release On Wed, Jan 27, 2016 at 3:53 PM, Mike Zingman <mike.zingman@gmail.com> wrote:
Progress has been made. I finally got a chance to focus back on the return channel of the gateway and it works. I have had successful QSOs using the new code where:
Analog Radio <----> DIAL w/ USRP <----> DMRGateway <----> DMRLink <---> TG9998
This was a full two way path with the DV3000 doing both encode and decode. ambe_audio.py has been extensively modified to support the return channel and DMRGateway is tasked with the Allstar to DMR linkage.
This code is not ready for prime time yet (the configuration files need to be updated with additional values, error checking, code cleanup/refactoring) but an Alpha release will be available to all testers soon.
Once the code is cleaned up all source will be released to allow others to modify/extend.
I specifically want to thank Cort for his amazing code base. Without it, there is no way I could have added this functionality. Open source rocks. This is so cool, thanks!!!!
Mike
_______________________________________________ Allstar-Digital mailing list Allstar-Digital@lists.keekles.org http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital
participants (5)
-
Michael Hebert -
Mike Zingman -
Robert Newberry -
Stephen - K1LNX -
Steve Zingman