- App_rpt-users - lists.keekles.org

Rebuilding a private node
by kk6ecm 13 Jul '14

13 Jul '14

I found that building a replacement Allstar server while the original is still in service, it works to copy all conf files over, but use unique node numbers (surrogate) during test, then switch over to the original node numbers when placing into service. Now I'm building a replacement private node that is "hosted" by an Allstar hub, and contains all the direct addresses of the connectable nodes. It seems straight forward to use a unique private node number (surrogate), but the ramifications of testing, when all the other nodes references reside in the .conf files. Would it be best to just rebuild, then test inplace without using a surrogate private node number? What is the nature of issues I could run into? Thanks, Bob kk6ecm Sent from iPad

1 0

Re: [App_rpt-users] VOTER transmit phase management
by Jim Duuuude 13 Jul '14

13 Jul '14

Well, yes, in a simulcast system, the transmitting equipment must be effectively IDENTICAL (same equipment carefully adjusted accordingly). However, I'm not sure why you are attempting this, as the Voter Board/RTCM as it currently is released/shipped does not properly support phase-coherent simulcast. Its software does (well, is capable of, if enabled). Its hardware does not. Date: Mon, 14 Jul 2014 11:08:13 +1200 Subject: Re: [App_rpt-users] VOTER transmit phase management From: stevewrightnz(a)gmail.com To: telesistant(a)hotmail.com Yes. I suppose RX is little different, but I wondered to what extent transmit phase was critical, and how it might be worked around by inserting some phase pre-correction phasing line might be inserted in the feedline, or at the simplest - varying feedline length. On Mon, Jul 14, 2014 at 11:05 AM, Jim Duuuude <telesistant(a)hotmail.com> wrote: Are you talking about simulcast transmit? Jim, WB6NIL Date: Mon, 14 Jul 2014 10:34:12 +1200 From: stevewrightnz(a)gmail.com To: app_rpt-users(a)ohnosec.org Subject: [App_rpt-users] VOTER transmit phase management On RTCM/VOTER systems, does the transmit audio and/or RF phase have to be "fiddled" to manage varying types of hardware? I read somewhere that the RF gear should be similar or identical to minimise timing issues. Can someone shed some light on this? regards,Steve ZL1BHD _______________________________________________ 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 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. -- Meshnetworks - Rangitaiki Plains Rural Broadband Internet Providers+64 21 040 5067

1 0

VOTER transmit phase management
by Steve Wright 13 Jul '14

13 Jul '14

On RTCM/VOTER systems, does the transmit audio and/or RF phase have to be "fiddled" to manage varying types of hardware? I read somewhere that the RF gear should be similar or identical to minimise timing issues. Can someone shed some light on this? regards, Steve ZL1BHD

2 1

Re: [App_rpt-users] Nodes in Indianapolis
by mike＠midnighteng.com 12 Jul '14

12 Jul '14

1 0

Nodes in Indianapolis
by Matt Beasant 12 Jul '14

12 Jul '14

Hi all, Sorry for the slightly off topic post - I'm going to the motor racing circuit at Indianapolis in August and was wondering if there were any: Allstar nodes in the area I could access to talk back home? Radio related places of interest / clubs to visit? Anyone going to the MotoGP race at the circuit? Many thanks for any and all info received! My first proper trip to the USA ;-) Kind regards, Matt G4RKY

1 0

Re: [App_rpt-users] echolink with app_rpt
by mike＠midnighteng.com 11 Jul '14

11 Jul '14

1 0

echolink with app_rpt
by Kenneth Grimard 11 Jul '14

11 Jul '14

I have a question. are the going to be any fixes or patches added to accommodate the new longer echolink node numbers. as of right now allstar can only dial node number that are a maximum of 6 digits long. the new node numbers are 7 digits long. My other question is can allstar accept connection from the stations with the new longer node numbers? Or will the require a patch in the code also? is this something we can expect in the near future? hopefully the will be a resolution to this soon? i see a problem coming down the road soon if this not addressed. ken n1dot

1 0

Allstar and External controllers
by Robert 11 Jul '14

11 Jul '14

A question. If Allstar is not being used in a voted configuration why can't I connect external controllers to my repeaters' and then Allstar to port 1 of the external controller? This would then let me run my parallel backup links in case the internet goes down. Thank you in advance.

2 1

Allstar on Ubuntu 12.04
by ronald simpson 10 Jul '14

10 Jul '14

I remember reading a post about someone getting Allstar to run on Ubuntu 12.04. I am having issues compiling zaptel. Linux kernel v3 does not have <linux/autoconf.h> looks like something changed in the headers between v2 and v3 kernel... Any clues or ideas? Sent from Yahoo Mail on Android

3 3

"Official" "fixed" DAHDI patches
by Jim Duuuude 10 Jul '14

10 Jul '14

After much lamenting this morning, I have come up with what I feel comfortable as a "working" DAHDI patch set. This is useful if you are wanting to "roll your own" app_rpt system (perhaps on some non-(Centos 5.X 32 bit) platform). If you take any of the distros of DAHDI 2.5.1 or newer, and apply these patches, it should "work". This patch set may be obtained from: https://allstarlink.org/fixed-dahdi-patches.tar.gz or from SVN at: http://svn.ohnosec.org/viewvc/projects/allstar/astsrc-1.4.23-pre/trunk/fixe…

7 11