- App_rpt-users - lists.keekles.org

Pulse back adjustment parameter
by Jeff Carrier 13 Jan '18

13 Jan '18

Lu, Look for rxondelay in usbradio.conf that's what you need. It ignores COR for however long you specify. Can be used as a kerchunk filter too. de K0JSC > > > Message: 3 > Date: Fri, 12 Jan 2018 07:39:12 -0500 > From: Lu V <luvencl8(a)gmail.com> > To: app_rpt-users(a)lists.allstarlink.org > Subject: [App_rpt-users] Pulse back adjustment parameter > Message-ID: <75544B9C-3453-4829-9143-652A119B9898(a)gmail.com> > Content-Type: text/plain; charset=utf-8 > > I have never had to tweak this parameter yet but I do now as I am adding a > repeater to my node via remote RF link. I don’t recall where this is > performed. Can someone remind me which parameter and which file I need to > tweak to remove pulse back or equivalent? What I’m referring to is where a > COR is present upon push to talk release for a second. I need to compensate > for a remote link that has a repeater tail timer of one second that I don’t > want to have sent out to the network of connected repeaters. > Thanks in advance. > > Sent from my iPhone, Lu Vencl > > ------------------------------ > >

2 1

Pulse back adjustment parameter
by Lu V 12 Jan '18

12 Jan '18

I have never had to tweak this parameter yet but I do now as I am adding a repeater to my node via remote RF link. I don’t recall where this is performed. Can someone remind me which parameter and which file I need to tweak to remove pulse back or equivalent? What I’m referring to is where a COR is present upon push to talk release for a second. I need to compensate for a remote link that has a repeater tail timer of one second that I don’t want to have sent out to the network of connected repeaters. Thanks in advance. Sent from my iPhone, Lu Vencl

2 1

Re: [App_rpt-users] 24/7 Echolink Connection Dropping Audio (one-way)
by Will Bashlor 11 Jan '18

11 Jan '18

Good morning Fellas, I have posted this on the FB group, but there seems to be more technical folks (and staff) on this list. This remains to be a very aggravating issue for our group. After much troubleshooting it appears this issue is definitely an AllStar related problem. I’ve decided to pull the plug on AllStar and go back to echolink only (probably SvxLink) for our local repeater that stays connected to the Echolink Georgia Conference (4544). I’ve tried hamvoip and the official AllStar images, bypassed my firewall completely (I have a static IP address), changed geographical locations, changed to a Hubless node, I’ve connected to Echolink theBridge software on Linux, and the Echolink application on Windows, I’ve connected to Echolink conferences and -R, and -L nodes, and I’ve also tried permanent and non-permanent connections, all to no avail. There are probably more things I’ve tried that I can’t remember off the top of my head. No matter what I try I still experience the same issue described below. Does anyone have any final advise I can try? Are there any AllStar staff reading this that can offer some support? I’m guessing this would definitely be classified as a bug. Is there somewhere I can submit it for review? I would much rather use AllStar than Echolink alone and do plan on switching back if it’s ever resolved Thanks all... From: Will Bashlor [mailto:will@bashlor.com] Sent: Friday, December 22, 2017 1:43 PM To: 'Users of Asterisk app_rpt' <app_rpt-users(a)lists.allstarlink.org> Subject: RE: 24/7 Echolink Connection Dropping Audio Hi Guys, This issue is still happening often and I’m fairly convinced it’s a bug or something within AllStar. I see this issue with the Crompton image and the official ASL image on a radioless hub node directly connected to the Internet without a firewall. I see nothing helpful in any of the logs. I also have word that it’s happening on other AllStar connected repeaters connected to Echolink for periods of time (i.e. Valdosta, GA repeater(s). To describe the issue again in the simplest way, radioless hub node 46690 is connected to node 3004544. When the issue happens, audio stops flowing from 3004544 to 46690. Someone can talk on the 3004544 conference but anyone listening on 46690 and hear them, but when they reply back no audio ever makes it to 46690. To resolve the issue you can simple disconnect 46690 from 3004544 and reconnect, then it works fine, until it happens again which may be 10 minutes or 2 weeks. What would be a good way to bring this issue to the AllStar developers as a bug to be investigated and hopefully solved? Thanks and Merry Christmas. 73 Will, KE4IAJ TARG <https://www.facebook.com/profile.php?id=196073504193006&ref=br_rs> AEC From: Will Bashlor [mailto:will@bashlor.com] Sent: Thursday, November 9, 2017 10:41 AM To: 'Users of Asterisk app_rpt' <app_rpt-users(a)lists.allstarlink.org <mailto:app_rpt-users@lists.allstarlink.org> > Subject: 24/7 Echolink Connection Dropping Audio Hello all, We have an AllStar node setup using a Pi 3, DMK URI, and a Yaesu 7800. It’s AllStar Node 46648 and it’s connected to 3004544 (echolink) 24/7. It works fine most of the time, but intermittently the audio quits working in the Internet to node/radio direction. It shows up on allmon2 and echolink as connected and if you talk RF everyone on the echolink network can hear you, but when they talk back no audio comes through to 46648 or to the Yaesu that’s connected to it and it doesn’t turn green on allmon2. If I disconnect the echolink node and connect it again it fixes the no audio until it happens again. I’ve tried with a normal connect and a permanent connect and the same thing happens using both. It may be 30 minutes or 3 days before it happens again. I wouldn’t mind it disconnecting every now and then because I have a script running (also tested without the script running) that automatically connects it back, but I have no way to detect when the audio drops except listening to it on echolink and my node at the same time. I am using a Ubiquiti Edge X router and have 4569, 5198, and 5199 UDP forwarded correctly (I’m a network guy). I’ve checked the asterisk log but it’s so full of brute force attacks I can’t really find any clue of what’s going on. I am wide open for suggestions. Any ideas or anyone experienced this issue before? Thanks in advance and 73. Will, KE4IAJ TARG <https://www.facebook.com/profile.php?id=196073504193006&ref=br_rs> AEC

5 11

RTCM Mix-station RSSI Indication
by Kevin Babich 11 Jan '18

11 Jan '18

Hello, I have an RTCM operational as a Mix-station in an environment with other RTCM's in voting configuration. The Mix-station RSSI does not appear to represent the actual signal level as a very binary 0 or 255 value is displayed, irrespective of signal level. I understand a fix for this has been made. As such, can someone please direct me to the location which I might locate it? Best, KJB

5 7

Default login??
by Pierre Martel 11 Jan '18

11 Jan '18

High, Just installed dial that I downloaded last night from the allstrlink site. Installed 64 bit version. all went well it found my network card without a problem downloaded all it needed rebooted, never asked a question. then it rebooted and now it ask for a login I did try user debian password debian, did not work try root password debian, still no go Was there a change in the login? I found that information from the faq pages of dial http://docs.allstarlink.org/drupal/node/170 Q: How do I login to DIAL? A: You can login as user debian with a password of debian (normal user) or loging as root with a password of debian (super user). Anyone can help? Pierre VE2PF

2 1

Ardunio PLL Programming of GE MVS
by Benjamin Naber 10 Jan '18

10 Jan '18

For those of you who are knowledgeable in the code of Arduino: I've begun a project that I jumped into the the *very* deep end, while knowing just barely how to swim. I've managed to get the radio to tune to a frequency that I want, but very flaky at best when it comes to tuning well within the limits of thr VCO; the arduino freezes every now and then, and quite frankly I am not working with (cough, not understanding), the existing code. In a nutshell, what I am doing is breaking the MC145159 control lines from the GE MVS CPU, and soldering in a few wires, plus a ground, to the base pins of the transistors that ulitamtely lead to the CLK,ENB, and DATA pins of the PLL. The reason why I am doing this is to enable free tuning of the radio without the need to program the radio using normal computer programming methods, ie, a cable, and a special program that is hard to come by, as well as must run this program on older hardware Given that Arduinos can be programmed from just about anything, this enabled on the fly on at least, on site programming of the radio. I am working towards enabling the use of these radios, and a couple others to be controlled by repeater controllers, and allstarlink nodes using kenwood data command set. Or whatever it is. Boiled down, this will enable good, inexpensive priced commercial radios to continue life; anyone who knows how to solder and program an Arduino can now use a commercial for a repeater VHF/UHF remote base, Allstarlink, IRLP, Echostink node radio, scanner, whatever. With the significantly better RX fronts ends on these radios, cleaner TX, these will significantly outperform any chinese radio attached to any RoIP node. --------- Here is where I am stuck: The MC145159 PLL wants the tuning data sent as follows: 14 bits for R counter 10 bits for N counter 7 bits for A counter 1 high bit for control. Totaling 32 bits. The current code, posted immediately below does not seem to allow this: emit_byte (0x14); emit_byte (0x01); /* Send "(n << 8)|(a << 1)", 24 bits, MSB first, LSB always zero */ //emit_byte (n >> 2); emit_byte ((n >> 8 ) & 0xFF); /* N high byte */ emit_byte (n & 0xFF); /* N low byte */ //emit_byte (a & 0b1); // send only seven bits? emit_byte (a << 1); /* A and LSB 0 */ //emit_byte (0x01 << 7); // send only one HIGH bit? pulse_le(); /* Latch it */ the "//" are my futile attempts to work around this, and leave commented out so I know what I *think* did not work. I've also the following to form the four bytes being sent, MSB of each counter first, control bit last: emit_byte ((r) & 0xFF); /* send first eight bits of r counter*/ emit_byte (((r & 0xFF) & n) & 0xFF); /* send last 6 bits of r counter, then send first two bits of n counter */ emit_byte ((n & 0xFF) & 0xFF); /* send last eight bits of n counter */ emit_byte (((a) & 0xFF) & 0x01 << 7); /* send seven bits for a counter, and one HIGH bit for control bit */ What does work now to test to make sure this project is even feasible: in the void setup() section .... emit_byte (0b00101000); // first eight bits of R counter emit_byte (0b00000001); // last 6 bits of R counter, first two bits of N counter emit_byte (0b00110011); // last eight bits of N counter emit_byte (0b10001001); // 7 bits for A counter, last control bit pulse_le(); ....... the above test code does work to successfully set the radio to 5 KHz step, and program the N + A counters to 151.820MHz + 45MHz Sorry it was long, However the more info you have to see what is going on, the less guessing you have to do. ~Benjamin, KB9LFZ

1 1

Registration vs online question
by Bryan D. Boyle 10 Jan '18

10 Jan '18

I'm bringing up 2 nodes for a friend who i'm introducing to Allstar...I edited the iax, extensions, usbradio, and rpt config files (not the first time I've done this...:))...and the iax2 show registry command in the cli shows that they're both registered (this is a second server in my home network...thus the 4567 port, which is also changed up on allstarlink for the server entry as well as routed properly both in port assignment and inside address in my firewall): jose*CLI> iax2 show registry Host dnsmgr Username Perceived Refresh State 67.215.233.178:4569 Y 47250 my.public.ip:4567 60 Registered 67.215.233.178:4569 Y 47247 my.public.ip:4567 60 Registered but when I look in stats.allstarlink.org, it does not report that they are active, though, when looking at allstarlink.org/nodelist.php, both of the above nodes show as green. FWIW, I can connect either to node 2000...but, they show up in the bubble chart as pink, with a (not in database) indication in the graphic bubble. I'm stumped...anyone have any insight? Or is this a synchronicity issue between the registry and nodestatus and ??? TIA 73 Bryan WB0YLE/W2FUV

5 11

Total list of all Allstar commands
by larry 10 Jan '18

10 Jan '18

Can some one point me to a listing of every available command defined that can used with Allstar. I am have a heck of a time trying to configure my nodes so everything is all the same commands on all my nodes.. It seems whenever there is a different version other than the 1-5 ilink commands there is no standard numbering system between versions or platforms. Realizing that it is up to me to standardize my own system I am about to start from scratch eliminating all the jumble. It would certainly be helpful if there was a COMPLETE command list with explanations of their functions. Larry - N7FM

6 7

Courtesy Beep
by lengriff＠optimum.net 09 Jan '18

09 Jan '18

The ' Courtesy Beep ' was always used to indicate that the repeater talk timer had reset. The beep could be delayed to force users to ' wait for the beep ' before transmitting. I do not see a way to input a delay value for the courtesy beep in Allstar.

2 1

NODE 7632300000 Telephone Portal
by Skyler F 09 Jan '18

09 Jan '18

When I call the Telephone Portal at (763) 230-0000 It tells me " welcome to the AllStar Network Telephone Portal " " Node 7632300000" "That Option is invalid, please enter the number of the node followed by the pound symbol" Then, I am able to proceed and connect. Does anybody know why the telephone portal is automatically entering it's own number as a node when I call it? Skyler

3 2