GB3OA IRLP and Echolink 5302 nodes unavailable
GB3OA IRLP and Echolink 5302 nodes unavailable Read More »
GB3OA IRLP and Echolink 5302 nodes unavailable Read More »
It’s been noticed in the logs and heard on air that users have been having problems with DTMF tones and OA recognising them.
Most repeaters in the UK are now narrow FM using 12.5kHz filters in the receiver and OA is no exception. So, if your rig is set to wide FM your DTMF tones will be clipped and distorted by the OA receiver. Some may get through and be recognised but others won’t, and you’ll be left wondering why OA is not responding.
All recent rigs have a menu option for wide or narrow FM and obviously for good comms this should be set to narrow.
The same goes for voice communication. Your audio could well be badly clipped and at the distant end of the IRLP contact the op may have problems. This usually shows up when the op keeps wanting you to repeat your callsign. Shouting down the mic only makes the situation worse. Either backing off from the mic or making sure your rig is set to narrow FM is the answer.
Apologies to those trying to connect to GB3OA using Echolink. The router updated itself automatically but changed a couple of the settings, allowing Echolink contacts to go out from GB3OA but not come in. This has now been corrected and all is well. IRLP contacts were not affected.
To avoid confusion, the relevant web pages (Repeater Details and Internet Linking) have been changed to specify the various timeouts on OA.
They are:
Echolink will also specify an error code if the txm is more than four minutes – a link to all OA error codes can be found on the Internet Linking page.
THE STREAM: this is now fully up to spec again and running normally. It can easily be listened to throughout the world by going to http://shoutcast.com and searching for GB3OA.
The repeater’s internet linking Node (5302) went offline last night (7th October) due to a failed Operating System upgrade.
We’re pleased to report the fault has been fixed and everything is now running normally.
In addition, it was noticed that the Node’s timeout had been accidentally set too short. This has also been corrected. The timeout is now back to the default setting of four minutes.