Hi Michael, thanks for posting that error message. ASL did make a change involving pthreads a few weeks ago. Here is the link to my fork of the branch from prior to that:
If you replace the git clone line in the build instructions with a wget and unzip of the above it should fix that and voxhangtime cfg in usbradio.conf will be supported. LMK how it goes.
If you already did the various update commands on your node you would just need to do the following:
UPDATE: See updated instructions in post from Dec. 23. Building from a zip may not work since git files are not present
cd ~
wget https://github.com/AllStarLink/ASL-Asterisk/archive/24cdbdc0b235122a8cd8502a5bf7f749ba9c1c9b.zip
unzip 24cdbdc0b235122a8cd8502a5bf7f749ba9c1c9b.zip
mv ASL-Asterisk-24cdbdc0b235122a8cd8502a5bf7f749ba9c1c9b ASL-NR9V
cd ASL-NR9V/asterisk
./configure
make
sudo su # if not already logged in as root
make install
I just tested these steps and got no errors. Let us know how it goes.
This stupid rule with limiting the number of links in a post is completely ridiculous. I can’t post the output from my attempt to download that file but in short it is unable to resolve the host address.
It finally downloaded. During the make process I get the following errors:
menuselect/menuselect --check-deps menuselect.makeopts
Generating embedded module rules …
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
make[1]: Entering directory ‘/home/repeater/ASL-NR9V/asterisk/utils’
Hi Michael, not sure why there would be a ‘git’ error during a make, maybe the make file is trying to pull in a git version number or something like that. Anyhow it appears that no matter how or what you try to compile you’re getting errors. I think the first step is to go back to the latest beta release and try to compile that following the instructions on the ASL github readme, ie.:
git clone https://github.com/AllStarLink/ASL-Asterisk.git
cd ASL-Asterisk/asterisk
./configure
make
make install
2 other notes:
You can post all the text, logs etc. you like if you use the “</>” button on the toolbar to format it as 'code'. That will prevent urls from showing up as links or the forum software assuming you are a spammer.
I would post the results of the above here: ASL-2.0.0-beta.6 Ready for Download - #12 by k6jwn. This was posted by the devs and I suspect they might like to know if someone is unable to compile the code.
Should be a simple matter to then resolve that and at that point it’s literally just 1-line of code to change the VOXHANGTIME #define in xpmr.c.
(BTW I just got a microscope and am going to try soldering a COS wire onto an RT85 soon as it should be pretty easy to do and would simplify the cfgs a bit. I have no issue with a 500mS or even 1S voxhangtime (always good to leave a bit of space before and after your audio anyway) but if I can open an RT85 and solder a wire on in 10 minutes then the default ASL config with simpleusb would be all that’s needed. Will let you know how that goes.)
This time I began with flashing the beta 6 image on a re-formatted micro SD card. Booted up the system
and did not enter asl-menu to do any setup. Followed the Prerequisite Steps on the github page, followed by the git clone line from your last post. No errors until the make install command and saw the following:
/home/repeater/ASL-Asterisk/asterisk/main/utils.c:1390: undefined reference to `pthread_setspecific’
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:142: asterisk] Error 1
make[1]: Leaving directory ‘/home/repeater/ASL-Asterisk/asterisk/main’
make: *** [Makefile:361: main] Error 2
Something is wrong in line# 142 in “asterisk” as well as line# 361 in “main”. I have also tried the preliminary steps on the github page after going through the setup process in asl-menu. At that time I
was thinking that perhaps some files being in use, such as usbradio.conf and its associated drivers, was causing the errors.
David, is it possible to get a fresh image that already includes the changed voxhangtime setting rather than repeatedly attempting to compile the updated file?
Also, I would indeed be curious as to where you’re tapping the COS line inside the RT85. Simple enough to use pin 2 of the DB-9 connector on the DRA-30. And if there are three contacts on the audio jack of the radio it would be easy to disconnect the existing radio circuit from its “ring” contact and re-purpose it for the COS. The 2.5mm audio cable I’m using is a 3-foot cable I purchased on Amazon and cut it in half. My DB-9 plug is actually a breakout plug making the use of the terminal blocks a great alternative to soldering. As for working on SMT circuit boards I got very good at replacing 168-pin fine-pitch “chips” using a 1/64" solder tip, solder paste and a 10x jeweler’s loupe.
I was able to duplicate the compile error KE7MT saw with latest ASL 2.0 Beta on an RPi 4 and will post on the other thread I mentioned that this has occurred for 2 people and I’m sure they’ll take care of that soon.
Here are updated instructions on how to compile the known-working ASL 2.0 Beta build (date Nov. 17, '22) with my pull request that makes the voxhangtime a cfg parameter settable in usbradio.conf:
mkdir ASL-voxhangtime-20221117
cd ASL-voxhangtime-20221117
git init
git remote add origin https://github.com/davidgsd/ASL-Asterisk.git
git fetch origin 24cdbdc0b235122a8cd8502a5bf7f749ba9c1c9b
git reset --hard FETCH_HEAD
cd asterisk
./configure
make
sudo make install
I confirmed this compiles fine on my RPi4. I could also post the resulting build files but the above instructions are pretty simple and probably 10 times easier than trying to manually install all the build files.
This seems to be working, but after the squelch tail something else is keeping the node keyed for at least 2 seconds. There must be something else in the ASL files besides the two perimeters in rpt.conf, which I have turned all the way down to 5ms each.
Your node number (should have been set in asl-menu/initial setup)
rxchannel = Radio/usb_[node#] ; Comment out all other rxhannel lines
duplex = 3
hangtime = 100
althangtime = 100
linkunkeyct = none ; prevent extra courtesy tones and hang time
nounkeyct = 1
parrotmode = 1 ; 1 = Parrot On Command
Uncomment following lines:
921 = cop,21 ; Enable Parrot Mode
922 = cop,22 ; Disable Parrot Mode
Also check that you have the following RT-85 settings:
I verified the settings on the radio and the two changes I had to make didn’t have any effect. I am hearing the squelch tail ~500ms after unkeying but for some reason the DRA-30 is still in transmit mode- at least the red LED continues to be illuminated for about 1 second and an additional ~1 second after that, according to what I am monitoring on the output of my simplex node. Sure wish Oops (UPS) had delivered my replacement RT85 as was schedule today but the Montana weather…
When in full-duplex (duplex=3 in rpt.conf (not 4)) the hang time on the local RF TX is longer, but the node is not actually transmitting audio to the network during that extra time (beyond when RX CD dropped). Since you’re hearing the squelch tail after ~500mS it sounds like it’s working exactly as it should It probably just stays keyed a bit longer to prevent more squelch tails, and because it can – it’s full-duplex thus you can key up anytime without having to wait for the node Tx to unkey, so it appears ASL/App-rpt took that into consideration and is making it work a little more like a repeater in this case, giving you a little extra hang time after each TX is complete so if you key up or a remote node keys up there’s no unnecessary carrier drop and extra squelch tail.
Thus I think you’re good to go. You could log into asterisk (sudo asterisk -vvvr) and enable some of the extended debug messages and see if it says any more info about what it’s doing…
p.s. - I couldn’t get any useful timing data from the asterisk menu manually so I set up a script to get the rpt keyed vars from asterisk every 50mS, then keyed up just for a fraction of second, enough to trip CD. Results:
time 1671868925.527 [cos_keyed] => 1 [tx_keyed] => 1
time 1671868926.803 [cos_keyed] => 0 [tx_keyed] => 1 => diff: 1200 mS
time 1671868929.321 [cos_keyed] => 0 [tx_keyed] => 0 => diff: 2500 mS
That sounds like about what you’re seeing and it works great for me. The extra 1.2 secs of space is not noticeable or annoying during a normal QSO on a repeater, where there’s already several seconds of hang time and a courtesy tone. When voxhangtime was 2000mS (vs. 500mS now) it was much more noticeable though and the time to drop COS was closer to 3 seconds.
I finally received my replacement RT85 and have the duplex node up and running. The only problem I have been encountering is the audio from the transmit HT cuts out. At first I thought it was my Internet connection so I switched over to my simplex node. Whatever the problem is, it is related to the transmit side of the duplex node.
Edit: I disconnected from the “hub” of my go-to ASL network and tried a couple extended parrot transmissions and there is no audio disruption. This only happens during the voice telemetry and while receiving when connected to the “hub”. I also swapped HTs and reprogrammed them accordingly, trying to eliminate a bad audio jack. The problem persists. Not sure if there may be some clipping because the telemetry and received transmissions seem to be a little on the “hot” side.
The audio can sound distorted and like it’s cutting out if too loud. HTs are set up for mic-level signals coming in (eg. ~10mV) so you need some significant attenuation from a line-level output. Setting the audio level into the node is easy using the tune utility’s level meter, but on the node’s Tx audio you just have to set it where it sounds the best, or record in an SDR or another radio and then check the levels / clipping / deviation.
Also, make sure all your port settings match on the ASL site for both the server and the node, and that those match the port settings in iax.conf (bindport), rpt.conf ([node#] = radio@ip:port…), and in your router/cable modem.
This is 5 different places the port has to be set. If it’s your first node then you probably have the default of 4569 and didn’t need to change anything, but if it’s not your first node then you have to use a different port number (eg. 4570, 4571, …), and make sure all those places have the same setting and that your router/cable modem has a port forwarding rule to forward traffic on that port# to your node. The node can still look like it’s working if those settings don’t match but the audio will then be more likely to have stuttering/dropouts.
p.s.- There is actually a 6th place the port number has to be set - in the node’s firewall. The ASL-menu’s security options let you enable an iptables firewall and fail2ban, which should always be done. But it might go with the default port num instead of what you actually want.
The only problem I have now is an apparent ground loop in the DC supply. Both RT85s are on battery eliminators. My Alinco power supply has one mobile power port, so I am using a “Y” adapter to give me two mobile power ports. There is noise (a lot of hiss) on the output of the node when it is transmitting but when I remove the battery eliminator from the receive radio and put it on battery, the hiss goes away and the output of the node is full quieting.
That does not sound like a ground loop, but power supply ripple from drawing near the max current that can be supplied by the power supply. Switching power supply’s start getting noisy when over 80% capacity.
I would use 1 ea or a bigger one.
The Alinco power supply delivers 30A and I have used it for my 100W HF radios for years. It’s not an overload problem. Currently the only load on that supply is two RT85s, one of them which is only being used as a receiver. The other one is set to low power since I’m using it in in the house. Even then I can be at the outer perimeter of my 5 acres and still get full quieting audio.
I did a lot of testing with a few switching power supplies and although not always necessary I recommend a snap-on ferrite core filter with at least 3-4 turns of the power wires around it – as close to the power supply as possible, and then also add a min. 2200 uF Filter cap – as close to the radios as possible.
I tested 4 different power supplies, one linear and 3 switching, and saw ripple of up to 30mV AC with no extra filter cap but the added cap. dropped it to < 1mV.
The ferrite filter on the other hand prevents conducted RF from getting into the power supply and causing harmonics at 60 Hz mixed with the switching frequency.
BTW I just finished the power supply box for my latest node, I put the Dell adapter and the 7.5V switcher supply inside a 6" x 4" x 2" aluminum box in order to have better shielding and have a nice solid enclosure to anchor all the components. The metal probably makes no significant difference for RFI actually but it does keep the wiring nicely concealed and out of the way.
I have tested only FCC-certified switching power supplies (you can get 7.5V 2A switching wall adapters for $10 on ebay/amazon/mouser, this is one I have in the box). No idea how good of supplies Alinco makes, but an RT85 Tx’ing low power uses only 475mA, so a 2 Amp supply gives loads of headroom and there was no noise on the audio in my tests even with no metal box.
So the ferrite filter and extra filter cap are the first step. Second step would be try a different power supply. Ground loops are not typically an issue for RF. Most shacks have numerous ground loops because there is just no way not to when everything is powered from 12V (ground #1) then you have ground wires and coax (ground path #2), and various interconnections/USB/audio cables. At worst that will cause a 60Hz hum somewhere eg. if I go into a mic pre on a mixer I have to use an isolation transformer. But a node as we have set up with a microPC and 2 HTs is standalone with no connections to anything else. Only thing you have is a ground and audio wires going less than a foot to the DRA/RIM audio interface, and the power wires. If you keep all this as short as possible and run all wires parallel to each other there literally won’t be any loops ie. having any actual enclosed area within a plane.
Just finished testing the new node I built and it’s working very well. For this one I used a Repeater-Builder RIM-LiteV2 radio interface and the audio is crystal clear. The level trim pot required no adjustment since the Rx HT has a volume control already, and for the Tx audio I have a 10K audio-taper panel-mount potentiometer at the top of the peg board.
I noticed however that the Tx audio would pick up some noise, apparently due to the Tx HT antenna only being a few inches away from the RIM. I then put a 6dB 2-Watt SMA attenuator inline (see pic above) and that fixed it.
After further investigation I found that with a ferrite filter on the power wires going to the Rx HT that also stops any noise. So either an attenuator or ferrite filter will fix it, and with both you should be very well covered against any possible chance of RFI/noise.
I also have a spare small aluminum box that I tried putting over the RIM-Lite but it didn’t really make much difference. So that’s good news in that the RIM works fine with no case which saves a few $.
(Updated) So in summary if you have any Tx noise these are some simple solutions:
Put some attenuation in-line with the Tx antenna. The RT85’s put out 1.5 Watts on Low power which is a lot more than you need within ~1 mile of your QTH. 6dB of attenuation reduces that to ~375mW which is much more reasonable.
Add a small ferrite clip-on filter on the power supply wires to the Rx HT. I already had a ferrite filter inside the power supply box but it was for the power to both HTs. Apparently some RF could still get coupled into the power line to Rx HT however so either you’d want one ferrite right next to the power supply and one on the line to the Rx HT, or separate filters on each line going to each HT.
Use some other antenna for the Tx HT, such as a small mag-mount antenna 10 feet or so away on a file cabinet or an outdoor antenna or attic antenna. The 1+Watt of Tx RF will then no longer be right next to the node components.
Check your power supply ripple, try different power supplies, ferrite filters and filter caps as noted previously.
It probably just stays keyed a bit longer to prevent more squelch tails, and because it can – it’s full-duplex thus you can key up anytime without having to wait for the node Tx to unkey, so it appears ASL/App-rpt took that into consideration and is making it work a little more like a repeater in this case, giving you a little extra hang time after each TX is complete so if you key up or a remote node keys up there’s no unnecessary carrier drop and extra squelch tail.
