March 2016 - App_rpt-users - lists.keekles.org

Reverse AutoPatch
by JJC 04 Apr '16

04 Apr '16

I have scoured the internet to find documentation about reverse autopatch but have had no luck. I have been able to get autopatch working without a problem and have had _limited_ success in getting allstar(dial) to answer. I was able to get allstar to answer and allow me to run DTMF with the following, but really all that I want is reverse autopatch or both.... If I make any real changes to the stanza in extensions.conf I get an error like: Using INVITE request as basis request - 1939985154(a)198.199.84.66 Found no matching peer or user for '198.199.84.66:5060' [Mar 30 16:15:32] NOTICE[575]: chan_sip.c:14351 handle_request_invite: Failed to authenticate user "Caller ID Strings..." <sip.conf> [general] allowguest = no match_auth_username=yes register=REDACTED:XXXXXX@gvgw.simonics.com/2230 context = default allowoverlap = no ; Disable overlap dialing support. (Default is yes) bindport = 5060 ; UDP Port to bind to (SIP standard port is 5060) bindaddr = 0.0.0.0 ; IP address to bind to (0.0.0.0 binds to all) srvlookup = yes ; Enable DNS SRV lookups on outbound calls [GV17193576518] type=friend autocreatepeer=yes insecure=port,invite username=REDACTED secret=XXXXXXX host=gvgw.simonics.com qualify=no ;permit=0.0.0.0/0.0.0.0 context=custom-gv-answer <extensions.conf> [custom-gv-answer] exten => 2230,1,Answer() exten => 2230,n,Playback(rpt/node) exten => 2230,n,Saydigits(${EXTEN:1})

3 23

Hamtronics receiver issue with AllStar RTCM
by Skyler F 02 Apr '16

02 Apr '16

For a voter project, we got the hamtronics VHF receiver pretuned to the repeaters input frequency. The idea is to use hamtronics receivers for every voted receive site for equivalent audio characteristics. http://www.hamtronics.com/r303.htm When hooked up to the discriminator on the hamtronics board, I could not get the RTCM to calibrate squelch. It usually told me the audio was too low weather the RX level was bumped up or down. I then hooked it up to a motorola SM50 and it calibrated shortly after adjusting RX levels. So... I hooked a cheap sound card up to audacity, and took a look at the spectrum of each receiver. The hamtronics obviously looks like it lacks high frequency noise on the discriminator output. Here is the SM50 discriminator out: amsatnet.info/SM50.png Here is the hamtronics discriminator out: amsatnet.info/HAMTRONICS.png Here is an audio sample comparing them (you can probably guess which radio is first): amsatnet.info/Sm50_hamtron_DISC.wav Does anybody else have experience with hamtronics receivers? Thanks, Skyler KD0WHB

7 19

Scratchy audio on some transmissions
by Skyler F 31 Mar '16

31 Mar '16

On my 900MHz node, I am having problems where the "repeat only" and various transmissions sound clipped and scratchy. I turned my audio down the the lowest setting (so I had to really crank my receivers audio) and even the small, barely deviated amount of audio that came out was scratchy when Allison announced "repeat only". Has anybody had this issue before? The clipped audio only seems to occur on transmissions with a lot of punch, and is fine for both. Both adjusting the deviation on the radio and turning my TX audio down to a bare minimum does not seem to do the trick. Audio levels is not a problem, however. We tested it on a service monitor and got the deviation fine with the test tone. Thanks Skyler

2 1

URI - Raspberry Pi 3 -Radioless
by Billy Vance 31 Mar '16

31 Mar '16

I travel (Fly) on business often and would like to take a URI-Raspberry Pi3 and a mic/headset on the road to use while I am in hotels as I have found the I can't always hit a local repeater. Any ideas? Thank you KK6KFV - Billy

2 1

Re: [App_rpt-users] Digital audio
by Steve Wright 30 Mar '16

30 Mar '16

On 31/03/16 13:26, Joe Leikhim <rhyolite(a)leikhim.com> wrote: > A lot of early simulcast systems "didn't work" because the designers > ignored problems of time differential interference in overlap areas. Or > ignored problems of transmitter stability, audio level equalization. > Small things like having the audio phase 180 degrees out of phase (doh, > signal wires transposed!), CTCSS tone out of phase. A lot can go wrong > and the product still be solid. That is what I am wondering. I understand RTCM TX Simulcast addresses all those concerns, but they were unhappy enough with the result to announce it "non working", which is a great loss to me. I've not heard or seen a demonstration of this - maybe someone has a video of it, or might offer an anecdote. > By the way if you have a high site, lots of ERP, no reason not to use > voter for multiple antenna diversity co located on the site. No back > haul needed. Those places are getting expensive here. I like the voter idea, because we can reuse inexpensive sites - and just add more of them. Receivers and Ubiq radios are cheap as chips, and you can just throw one into any gap, with a big antenna and a quality preamp on it. That'll work. ;) > I am with you on digital audio CODECs. I am not sold. But there is > something to be said for 15 sites of DMR 2-slot TDMA linked with > internet and mobiles free to roam automatically. We could do better in my opinion. The interesting thing about any Voter system, is that the receivers do not have to be sited with their transmitter. So lots of problems go out the window. No duplexing and no power limitations are the big ones... Imagine what you can do on a 6/2/70 repeater site when there is no duplexing and no power limitations! 1500 watt analog repeater, anyone? Single-site digital systems have similar advantages, again no duplexing and no power limits. Cue 100watt 1.3GHz 10mbit for Hams? Multi-site zero-handoff all done in software? Really great tech chat, Joe. :) Steve

2 1

Re: [App_rpt-users] App_rpt-users Digest, Vol 85, Issue 58
by Steve Wright 30 Mar '16

30 Mar '16

On 31/03/16 11:46, Joe Leikhim <rhyolite(a)leikhim.com>wrote: > What is the problem with the RTCM and simulcast? RTCM Transmit simulcast "doesn't work", we were told. I haven't tried it. RTCM Receive voting works famously. > Analog simulcast may never sound as good as a single site, because it > does experience/cause time differential interference and noise and > therefore requires some very specific design constraints. However, for > some applications it still is the way to go. How difficult for Hams? RTCM TX Simulcast is a very good idea, but it seems to be on the back burner. > Moving forward 5-10 years, > two slot DMR with IP connectivity will be the way to go. Before I get > flamed, TETRA never got a foothold in the US and because FCC eliminated > most 25KHz channels, getting TETRA to play in the US is reserved for > those few who have the contiguous spectrum. We're Hams though, and we can do as we choose within our own regulations, and our propensity to negotiate new rules. I don't like 4800baud audio, and if we don't want to do something, then we don't have to do that. There's no need to focus on the commercial world and their limitations and rules, but we just don't have to. > [....] commercial products are very pricey and complex. That > being said, I see the RTCM as having some potential niche in the > commercial LMR world. All the commercial stuff WILL go digital. That's my prediction anyway. There's too much cleverness in the digital RF world to be ignored now - the benefits are just too great and the products are too disruptive. There won't be any analog RF before long - it'll be too slow, too featureless, too expensive, too power-hungry, and almost anything else you can think off. Maybe Hams are stuck with that reality - that an analog RF high-site will be cool and quaint, like a transistor analog VFO. Nice and old-world to play with, but not enough toys in the toybox. For myself, I just can't get past the horrible 4800baud audio, and I don't think that we have to - not on VHF/SHF anyway. A nice 64kbit channel would be lovely thanks! :p Steve

3 3

Digital Audio was: analog voting
by Steve Wright 30 Mar '16

30 Mar '16

On 31/03/16 09:53, KM4NRJ FLORIDA <km4nrj(a)gmail.com> wrote: > Unless you are talking private links using microwave unlicensed spectrum > technology, I think it may be a hair puller. That's not too hard to do though. The gear is off-the-shelf, effective, inexpensive, and uncomplicated. 2.4, 3.3, 5.8, and 10GHz radios are available. The only issue with these radios and links, is they're not actually that solid, and if something gets wedged you need an admin who really knows which chain to flush, or your repeater is going to be down days or weeks. It's nearly mandatory that hams know how to acquire some obsolete Ubiquiti, plug it in, and shoot a 100mbit link with it, and it's fun too. Many many cool stunts can be done over a link like that. Internet trunking between 'Repeaters' doesn't get anywhere near the workout that a local voted system would - where users really want to beat it to death in near-real-time. As long as a courtesy tone tells users "we're connected somewhere - there may be delays" then that is fine. It's not irlp, kerchunk kerchunk.. ;) Interesting comments on the PTP sub-microsecond timing protocols. I just installed the daemon with a flick of my admin finger, so deploying servers is a doddle. XIPAR source can be googled trivially. Sadly, I am not a coh-derrr, so others may comment. I don't mind Digital Audio over Ham Radio, but it doesn't 'feel like radio'. Maybe I'd get used to that, if it was nice warm 64kbit audio. I wouldn't mind the occasional blip in the voted audio - that doesn't sound anywhere near as bad as mister robota d-stir. I spent some time looking at transverters for our 1.3GHz band. The concept was to use a 5MHz wide channel with the Unifi zero-handoff 5.8GHz radios as the IF. 25 watt mobiles and 100 watt base stations would be easy to deploy (no duplexing). Testing at -70dbm shows a 32MBit connect and an *actual* TCP throughput of 3.5mbit/sec full-duplex for a channel total of 7mbit/sec. I stopped work on it because I wasn't really in a position to design and build the high-side LO and mixer board for it. Just ideas. Steve

1 0

Re: [App_rpt-users] App_rpt-users Digest, Vol 85, Issue 56
by KM4NRJ FLORIDA 30 Mar '16

30 Mar '16

Maybe I am way off here and there are plans to use voting for digital down the road like Digitac Motorola does. They go further and actually reconstruct packets that fail from a site using data from all sites. Having said that, in the analog world using Moto SpectraTac comparators for many years it wasn't that noticeable because all was analog from every field receiver in a 1247 square mile County. With the ADC to DAC process, I shudder at thinking of a timed referencing synchronization of various source sites using public Internet transport. I mean even in the "fire and forget" world of UDP protocol, the network cannot cope. Unless you are talking private links using microwave unlicensed spectrum technology, I think it may be a hair puller. Interesting project though. On Mar 30, 2016 12:30, <app_rpt-users-request(a)ohnosec.org> wrote: > Send App_rpt-users mailing list submissions to > app_rpt-users(a)ohnosec.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users > or, via email, send a message with subject or body 'help' to > app_rpt-users-request(a)ohnosec.org > > You can reach the person managing the list at > app_rpt-users-owner(a)ohnosec.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of App_rpt-users digest..." > > > Today's Topics: > > 1. Re: Non-RTCM voter, where? (Jeff Ackerman) > 2. Re: Non-RTCM voter, where? (Bryan Fields) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 30 Mar 2016 09:28:32 -0700 > From: Jeff Ackerman <kg6uyz(a)gmail.com> > To: Joe Leikhim <rhyolite(a)leikhim.com> > Cc: info(a)meshnetworks.co.nz, app_rpt mailing list > <app_rpt-users(a)ohnosec.org> > Subject: Re: [App_rpt-users] Non-RTCM voter, where? > Message-ID: > < > CAKmcLtJRAnL_-rPHYQHs6cq-eyXY3FmxC-FkNU9rbWUU9+NkYQ(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > XIPAR does not do GPS timing of the audio so there will be no timing of > audio. Its called "simple voter", no frills. XIPAR simply selects the > best receiver based on DSP signal strength measurements. > > On Wed, Mar 30, 2016 at 9:01 AM, Joe Leikhim <rhyolite(a)leikhim.com> wrote: > > > Without GPS, how does XIPAR deal with jitter and network latency? > > > > > > On 3/30/2016 11:25 AM, Jeff Ackerman wrote: > > > > If you looking for the alternative IP voting of the varuious app_rpt > > flavors you can try XIPAR: <http://www.xelatec.com/xipar/simplevoter> > > http://www.xelatec.com/xipar/simplevoter > > > > It wont be as seamless of voting as a RTCM, but its much simpler, doesnt > > require anything more then PC's, the IP backhaul and usb radio interfaces > > with radios capable of giving discriminator audio. > > > > Conventional hardware voting comparators could work but require the > > backhaul, which in most commercial applications is 4 wire e&m voice > > circuits using either tone signaling or e&m signaling. (This method of > > voting is done outside of allstar/app_rpt.) > > > > On Wed, Mar 30, 2016 at 8:09 AM, Joe Leikhim <rhyolite(a)leikhim.com> > wrote: > > > >> Here are some products to start with; > >> > >> There is the Raven M4x > >> > >> http://www.ravencomm.com/documents/products_doc3_23.pdf > >> > >> Raytheon JPS SNV-12 (Though the future of this product is up in the air, > >> it was the defacto standard. Uses 600 ohm VF circuits, IP connectivity > >> needs to be overlaid) > >> http://www.simulcastsolutions.com/userfiles/file/appnotes/vSnv12App.pdf > >> > >> Motorola Spectra Tac (Obsolete Now Motorola has pretty much abandoned > >> analog FM technology. Uses 600 ohm VF circuits,) > >> > http://www.repeater-builder.com/motorola/spectra-tac/spectratac-index.html > >> > >> The above voters all use some method of signal/noise voting. The JPS > >> SNV-12 and the Raven M4X use DSP to make decision, while the Spectra Tac > >> was pretty much an analog noise measurement vs a status tone/audio AGC > >> level. The SpectraTac does not support non-Motorola receivers unless you > >> know the "secret sauce" which I am privy to. > >> > >> This site has some practical examples of projects that are simulcast, > but > >> by design incorporate the SNV-12 voters. > >> > >> www.simulcastsolutions.com > >> > >> Are you looking for some more in depth RF design aspects of receiver > >> voting? I can help perhaps. > >> > >> Joe > >> > >> www.leikhim.com > >> > >> > >> On 3/8/2016 5:20 AM, Steve Wright wrote: > >> > >>> On 05/03/16 06:00, mike(a)midnighteng.com wrote: > >>> > >>>> FYI There are RTCM /voter systems for app_rpt if you want to do it > >>>> right. > >>>> > >>>> > >>> Is there an example voting-RX project somewhere I can read about? > >>> > >>> Non-RTCM please. I know about the RTCM and I'm looking at > alternatives. > >>> > >>> > >>> Many thanks, > >>> Steve > >>> > >>> _______________________________________________ > >>> App_rpt-users mailing list > >>> App_rpt-users(a)ohnosec.org > >>> http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users > >>> > >>> To unsubscribe from this list please visit > >>> <http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users> > >>> http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll > >>> down to the bottom of the page. Enter your email address and press the > >>> "Unsubscribe or edit options button" > >>> You do not need a password to unsubscribe, you can do it via email > >>> confirmation. If you have trouble unsubscribing, please send a message > to > >>> the list detailing the problem. > >>> > >> > >> -- > >> Joe Leikhim > >> > >> > >> Leikhim and Associates > >> > >> Communications Consultants > >> > >> Oviedo, Florida > >> > >> JLeikhim(a)Leikhim.com > >> > >> 407-982-0446 > >> > >> WWW.LEIKHIM.COM > >> > >> > >> _______________________________________________ > >> App_rpt-users mailing list > >> App_rpt-users(a)ohnosec.org > >> http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users > >> > >> To unsubscribe from this list please visit > >> <http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users> > >> http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll > >> down to the bottom of the page. Enter your email address and press the > >> "Unsubscribe or edit options button" > >> You do not need a password to unsubscribe, you can do it via email > >> confirmation. If you have trouble unsubscribing, please send a message > to > >> the list detailing the problem. > >> > > > > > > > > -- > > Jeff Ackerman > > kg6uyz(a)gmail.com > > > > > > -- > > Joe Leikhim > > > > > > Leikhim and Associates > > > > Communications Consultants > > > > Oviedo, Florida > > JLeikhim(a)Leikhim.com > > 407-982-0446 > > WWW.LEIKHIM.COM > > > > > > > -- > Jeff Ackerman > kg6uyz(a)gmail.com >

2 1

Non-RTCM voter, where?
by Steve Wright 30 Mar '16

30 Mar '16

On 05/03/16 06:00, mike(a)midnighteng.com wrote: > FYI There are RTCM /voter systems for app_rpt if you want to do it right. > Is there an example voting-RX project somewhere I can read about? Non-RTCM please. I know about the RTCM and I'm looking at alternatives. Many thanks, Steve

4 7

Decode DTMF on a remote base
by Skyler F 30 Mar '16

30 Mar '16

Is it possible to decode DTMF on a remote base node? There are some cases where I want my base to perform actions based on DTMF sent from various repeaters and systems. 73 Skyler

1 0