• Guests may view all public nodes. However, you must be registered to post.

Alternate Frequencies (Split from Seeking Amateur Radio Operators General Class and higher)

expat42451

Active member
Right now we are going into a more active sunspot time-- A combination of that propagation uncertainty and 40M being what it can be at night, might be a good consideration to post an alternative frequency and band at a little bit later time just in case. I know this can add confusion but it can also make a difference if for example, 7200 is occupied at 0130 on the 16th.

An example of what this might look like is this-- if 7200 is occupied then up 10 and call. if 7210 is occupied then up another 10 and call. If 7220 is occupied the up another 10 and call. If 40 meters is dead-unlikely but none never knows- then think about designating a frequency for a little later time on either 75 or 20. Say a 75m freq at 0145 and a 20 m freq at 0200. Same procedure if the designated freq is occupied at the designated time then up 10 and call. I used this years ago when sailing, operating Maritime Mobile and keeping a pre arranged sked with another operator. Just a suggestion. The first time to establish a net might be a little rough and some people wont be able to get in but dont let it discourage anyone. Its well worth doing, alternative comms path when the internet is down plus sharpens operator skills for those new to the hobby. I wish I was going to be where I could participate. I will listen on one of the SDR web available receivers. Mike, your suggestion about putting something together on echolink is a good one. Here in Ecuador I dont think there is any longer any 2 M or 6 M repeater anywhere in the country but I might be wrong...... There are almost no amateurs active here any longer......I occasionally see on dxmaps, a couple of HF ops come up on contest weekends but those are rare as hens teeth. Again I am sorry I cant participate other than listen. I miss the hobby more than I can say.
73
 
Last edited:
Good Point... I was thinking of that going forward... Just shooting up a test flare on this run, to see how things go.. as we get further in, perhaps 60 Meters or 80 meters could be a good choice...

It's my thought to crawl first, see how many people can work that, and then perhaps a week or two later, try connecting in on an All-Star reflector (each person would have to connect their local node to the reflector) and go from there...
Perhaps I could run DMR on the 16th... we could meet on a talkgroup there and have comms both on HF and DMR... just floating the idea out there.. how many have DMR capability ?
 
Good Point... I was thinking of that going forward... Just shooting up a test flare on this run, to see how things go.. as we get further in, perhaps 60 Meters or 80 meters could be a good choice...

It's my thought to crawl first, see how many people can work that, and then perhaps a week or two later, try connecting in on an All-Star reflector (each person would have to connect their local node to the reflector) and go from there...
Perhaps I could run DMR on the 16th... we could meet on a talkgroup there and have comms both on HF and DMR... just floating the idea out there.. how many have DMR capability ?
What about Echolink, would that be a possibility?
 
Good Point... I was thinking of that going forward... Just shooting up a test flare on this run, to see how things go.. as we get further in, perhaps 60 Meters or 80 meters could be a good choice...

It's my thought to crawl first, see how many people can work that, and then perhaps a week or two later, try connecting in on an All-Star reflector (each person would have to connect their local node to the reflector) and go from there...
Perhaps I could run DMR on the 16th... we could meet on a talkgroup there and have comms both on HF and DMR... just floating the idea out there.. how many have DMR capability ?
Understand completely. What you are doing is excellent preps. Again I wish I was where I could help.
A suggestion....a future consideration .you might want to think about main, alternate and tertiary "net control" stations. Among the qualifications for these might be stations that could put say a KW on frequency through a effective antenna as well as an auxiliary power source in case of a commercial power failure. Location will play a part as well because of things like terrain around the antenna and how that affects departure angle on RF &c, ground conductivity and so on. While some of this sounds like a lot to a new operator (and it can be) at first blush --its a great opportunity in establishing a network, to also provide a learning opportunity for everyone involved that will improve everyone's skills in working together and in learning more about all aspects of radio. From an old vacuum tube guy...... what Megalos is putting together is absolutely great in my opinion. Get everyone on the air and working in a net. After that the more experienced of you have the opportunity to work with the less experienced to teach them more about propagation, antenna design, how location, terrain and ground conductivity can change the way you can communicate with other people.

Any way I can help from this remote location I am at your service. I only wish I had equipment and location here to get on the air. To give you an idea, an IC 7300, Icom's entry SDR costs around $1000 there in the US. By the time shipping and customs are paid its right at $2000 at my door. Ditto for everything from power supplies to antenna matching units, coax, and it goes on and on. A $100 Samsung Evo 860 SSD is $200 delivered. If it were not for this I would have already been on the air. What you guys are doing makes me miss it even more. I turned 70 not long ago and wish I was where I could spend time with some of you in person helping out.

Delta Echo26 great idea about including Echolink as well.

73
 
Last edited:
I am just amazed. You can now run EchoLink under Android. I am still looking around for a Linux solution that doesnt involve WINE. While EchoLink on WINE might not be so bad, recent changes to the Linux audio stack namely pipewire (another layer of obfuscation on top of pulseaudio and ALSA) give me pause. One consideration is to run EchoLink in its native environment in a Virtual Box container. Anyone running EchoLink under a distro with pipewire?

RiffRaff are you running EchoLink through your GSM carrier or through a wifi net? I use Skype under Android 10 on my phone to have a US number.Through GSM here in Ecuador its garbage almost unusable but on WiFi works perfectly. I think some GSM carriers play games with packet timing to increase circuit bandwidth and that may be the cause of the problem with Skype. Maybe your EchoLink as well? Just an idea.

As a note found QTel for Manjaro. Working on getting it running.
 
Last edited:
I am just amazed. You can now run EchoLink under Android. I am still looking around for a Linux solution that doesnt involve WINE. While EchoLink on WINE might not be so bad, recent changes to the Linux audio stack namely pipewire (another layer of obfuscation on top of pulseaudio and ALSA) give me pause. One consideration is to run EchoLink in its native environment in a Virtual Box container. Anyone running EchoLink under a distro with pipewire?

RiffRaff are you running EchoLink through your GSM carrier or through a wifi net? I use Skype under Android 10 on my phone to have a US number.Through GSM here in Ecuador its garbage almost unusable but on WiFi works perfectly. I think some GSM carriers play games with packet timing to increase circuit bandwidth and that may be the cause of the problem with Skype. Maybe your EchoLink as well? Just an idea.
If I'm home my phone automatically connects to my local wireless network. If I'm not home it goes out over the carrier's 4G network.

I'm running Mint 20.1, and according to Synaptic, Pipewire is not installed on my system. Since this is a brand new install, I had not gotten around to installing EchoLink yet. I'm doing that now. Look for the software package called Qtel.
 
If I'm home my phone automatically connects to my local wireless network. If I'm not home it goes out over the carrier's 4G network.

I'm running Mint 20.1, and according to Synaptic, Pipewire is not installed on my system. Since this is a brand new install, I had not gotten around to installing EchoLink yet. I'm doing that now. Look for the software package called Qtel.
Got QTel running. Incidentally I since the last post have Qtel installed plus signed up and received my EchoLink authorization , the procedure with my FRN and electronic license. Now the fun begins, QTel doesnt appear anywhere as either a sink or source in the audio stack settings. All QTel offers is the ALSA defaults for its own sink and source. Before pipewire I had things running fine but sort of like the whole systemd debacle in other areas.... pipewire has screwed the audio stack. My other mahcine is running another Arch derivative, Endeavour. I may try it there depending on how I can or cant make Qtel work here on Manjo. I came over to Manjo from Ubuntu after the Stallman revelations on shared search results and have been here for a while. Mint looks like a sweet distro. Ubuntu was great until the privacy blowup. Hopefully the Mint devs are smarter than the Ubuntu guys were.

Looked for your call on listed stations but dont see you yet. For fun tried opening a connection to another station and received the error message from QTel "could not open speaker audio device"......
Also look for Pulse Audio in Mint. You probably have a pulse sound server running (it runs by default) on most recent distros. Pulse unlike pipewire has some really great tools for audio routing if you dont want to use JACK or one of its derivatives. If you have Pulse running and QTel only offers ALSA you can synaptic in a number of plugins for compatibility between ALSA and Pulse..or try just using an ALSA mixer. Linux sound stack sucks.
73
 
Last edited:
I had to open up the proper ports in my network firewall for it to connect to the servers. I'm online now, but watching TV with the wife. We can test it tomorrow if you like.

I have both Pulse and Alsa installed. You don't have those packages available to you in your repositories?
 
Enjoy the TV and family time. Look forward to trying it tomorrow. On my primary machine not able to connect due to audio foolishness with pipewire. Secondary machine able to connect but so far no QSO's. Also have Echolink running on Android. So far again no QSO's, able to connect to repeaters and QRZ - can hear the repeater cycle but no answers yet.

Glad you got it running. Have a great night.
73
 
There are few repeaters that have local and provincial coverage, there is also one that is out of service at the moment, which is connected to the brandmeister network
 
Enjoy the TV and family time. Look forward to trying it tomorrow. On my primary machine not able to connect due to audio foolishness with pipewire. Secondary machine able to connect but so far no QSO's. Also have Echolink running on Android. So far again no QSO's, able to connect to repeaters and QRZ - can hear the repeater cycle but no answers yet.

Glad you got it running. Have a great night.
73
I'm on Qtel for a while if you feel like testing it.
 
I had a few close buddies in Bn HQ commo in the military... and reading this thread reminds me of talks in Iraq combat. According to them, it sounds like this is verbiage you might want to take offline. Some things shouldn’t be public knowledge. Gets into the wrong hands unintentionally and gives ideas/knowledge. Just my military 2 cents.Take it or give a refund. Regardless, I totally support what you are doing. I just wish the specifics weren’t broadcasted. Much respect
 
There are few repeaters that have local and provincial coverage, there is also one that is out of service at the moment, which is connected to the brandmeister network
Hey Alberto thanks for the info on the HC group and the repeaters. Good to know.
 
Couple of us have been trying to make Echolink and its Linix equivalent, QTel work. Problem repeatedly seems to be timeouts when trying to connect to either a repeater or another station. I am in Ecuador with an Ecuador IP so dont know if this matters i.e Echolink rejects foreign IP addys. What I do know is that I cant make UDP work ...Echolink wants UDP bi directional on ports 5198 and 5199. It also wants TCP bi directional on 5200. I am running a couple of desktop boxes behind a firewall/router. Have both Linux and Windoze...both boxes are dual boot. I have put in port forwarding rules in the router, using the LAN MAC addy of the machine with the program on it to prevent having to disable LAN DHCP. Have also disabled stateful packet inspection on the router firewall and so far I can not get the UDP problem solved. Forgot to mention that I have both put in rules for the IP Table firewall on Linux--didnt work.... and then disabled it to see if I cacked the rules. No difference. Anyone won this UDP battle suggestions appreciated. On Echolink Android running with a GSM connection I get repeated timeouts (thanks CNT) when trying to connect. Running the phone connected to Wifi (same router) I have been occasionally been able to connect and have a QSO with someone on a repeater. This in itself is mystifying because the wifi connection is governed by the same rules that govern the ethernet connections to both of the boxes......only thing I can think of is that the provider (CNT) maybe has 5198 and 5199 blocked.
 
Couple of us have been trying to make Echolink and its Linix equivalent, QTel work. Problem repeatedly seems to be timeouts when trying to connect to either a repeater or another station. I am in Ecuador with an Ecuador IP so dont know if this matters i.e Echolink rejects foreign IP addys. What I do know is that I cant make UDP work ...Echolink wants UDP bi directional on ports 5198 and 5199. It also wants TCP bi directional on 5200. I am running a couple of desktop boxes behind a firewall/router. Have both Linux and Windoze...both boxes are dual boot. I have put in port forwarding rules in the router, using the LAN MAC addy of the machine with the program on it to prevent having to disable LAN DHCP. Have also disabled stateful packet inspection on the router firewall and so far I can not get the UDP problem solved. Forgot to mention that I have both put in rules for the IP Table firewall on Linux--didnt work.... and then disabled it to see if I cacked the rules. No difference. Anyone won this UDP battle suggestions appreciated. On Echolink Android running with a GSM connection I get repeated timeouts (thanks CNT) when trying to connect. Running the phone connected to Wifi (same router) I have been occasionally been able to connect and have a QSO with someone on a repeater. This in itself is mystifying because the wifi connection is governed by the same rules that govern the ethernet connections to both of the boxes......only thing I can think of is that the provider (CNT) maybe has 5198 and 5199 blocked.
Try completely turning off the firewall temporarly to eliminate it as the problem. Or put the computer in question in a DMZ so it's on the other side of the firewall. If it works, then you know for sure the firewall is the issue and you just need to research proper filter rules for the traffic. If it doesn't, then something else is going on, probably with your ISP.
 
Hey Alberto thanks for the info on the HC group and the repeaters. Good to know.
(y)
If you are interested in obtaining a HC license, tell me in which part of Ecuador you are living, to find and get in touch with the radio club of the sector or with a radio amateur in the area.
 
Top