As SYSOP of our local repeater (see on0wv.uba.be ) which is located on our BRUGES Belfry, about 85m high and reachable by 365 stairsteps to climb, I developed some accessories for our ECHOLINK facility (see www.echolink.org)
Our ECHOLINK is running on some SIEMENS industrial 'Box-PC 620', a very reliable machine, linked to a link transceiver located at the repeater site. We choose for this approach - not linking directly to the repeater - for additional reliability and possibility to exchange the repeaters when maintenance is required. This was off course possible due to the fact that Internet is available at our site ! The link transceiver is an old defective IC-2725 with burned out final stage, modified so that it is still able to give 10mW output on 2m. It is powered from the PC, so that the complete unit is modular.
This very robust BOX PC-620 has the annoying feature that it cannot be rebooted from Windows : if you give a 'shutdown and restart' command, it will shutdown and then remain in some 'sleep' stage, a cursor flickering on the screen. The only way to have it rebooted is to disconnect and re-apply the AC power supply, or depress the RESET button. Not very handy as it is in a remote location !
Therefore a hardware watchdog circuit was designed, based on a PIC circuit and firmware developed by ON7ATV (thanks Alain!). The circuit is powered by the USB port of the PC (5v), the output is connected to the RESET switch (interfaced by an opto-coupler), and the input is linked to a serial port of the PC.
By means of a scheduled task, triggering a simple DOS batch routine at regular intervals, a small stream of data is outputted on the port, thereby resetting a counter on the PIC board. If no stream is received (this means : a signal of constant level, either 0 or 1), the PIC board will eventually close momentarily the opto coupler and generate a reset. The timings are adjusted so that no subsequent reset happens in a boot-up phase.
Off course this circuit will as well monitor should the PC become 'frozen' and initiate a brute force reboot.
Our new ECHOLINK facility is being intensively used and tested. As some weird (and mostly same) DTMF codes are given which invariably produce the same error message ( code 'xxxxx' not found'), some kind of filtering was needed to discourage these 'test' !
Unfortunately, there is not such facility in the standard ECHOLINK software. However, the ECHOLINK software offers an API interface by which some interaction is possible.
Instead of designing an application in Visual Basic, I choose for the 'direct approach' using VBscript, which can be edited very easily to suit your needs. The script will run in background under following conditions:
if ECHOLINK s not yet running, it will start ECHOLINK main program
you can give 2 parameters in the startup command (see details in script header):
/A : 'Announce' mode (default = OFF or 'silent'): in this ANNOUNCE mode, ECHOLINK will key the transceiver and announce that DTMF is disabled or re-enabled.
/D : DEBUG mode : the 'penalty' timers for DTMF decode suspension are shorter, debug messages can be included,...
there are 2 'blacklists' of DTMF codes to be drawn up in the script . Whenever a blacklisted code is received:
the script first checks if any station is connected: if so, DTMF decoding cannot be suspended (necessary to end a call etc)
if running in silent mode, ECHOLINK will produce no audio output at all (even not a 'not found' message !)
the decoding of DMTF will be suspended by some time (penaly timer - short) - you can define this in the script
if the DTMF code is on the second blackist, the decoding of DMTF will be suspended by some longer time (penaly timer - long, which you can define in the script as well). This is really to 'kill' any repetitive players ...
During the DTMF muting, the access from Internet is still possible.
all DTMF received and actions taken are logged (in a volatile manner, on screen only)
another way to suspend DTMF during the 'penalty timer' is from the web remote control, put ECHOLINK in 'RECEIVE ONLY' (tick checkbox in 'Control Link Menu')
the DTMF decoding is disabled by altering the sysop settings (DTMF decode external/internal/none ---> setting them to NONE). The effect of having the change applied, is that there is a 'partial reset' in the software, and all parameters are set back to the software last startup situation. Or otherwise explained: if you amend any parameter after the startup (e.g. adjust the volume), and DTMF is disabled or re-enabled, these are lost. So it is important to set all parameters right with the script not running, shutdown the software to have the settings 'saved', and then restart ECHOLINK with the DTMF watchguard
ECHOLINK will only decode (and produce output) for codes which are in the command list (like * # etc), or DTMF addresses of 4, 5 or 6 digits long.
The VBScript will detect a shutdown from ECHOLINK main software to shut down as well. However, before ECHOLINK can be restarted, a task remains running (echolink.exe - why ?) and must be killed first.
As I am not a programmer in VBscript, it can certainly be enhanced and refined (feel free to do and report !) For example : testing if a node is in the station list, and if not and repeatedly submitted (trial counter), then suspend DTMF ...
Download a DTMF test script (it simulates DTMF codes send to ECHOLINK, you can define the code in the suffix of the command line. As this is simulated, even when DTMF decoding is disabled, it will still send & virtually decode !)
Dowload a Speechtest script (producing the 17 messages built in ECHOLINK)
Our repeater site has been running for 3 years with a triband antenna DIAMOND X6000, as three repeaters ( 2m / 70cm/ 23cm ) were QRV from this location - see specifications here.
We have experienced that during rainshowers, strong static discharges were noticed, producing QRM on the repeater signal, going from crackling (like a machine gun) to a constant whine, making any QSO impossible.... strange, as the antenna is announced 'DC grounded'.
After replacement of the X6000 with a new antenna (type X300), we have opened the X6000 to analyze status of the 'guts'. No water dripping out .... that is a good start ! But, much to our surprise, the lower end of radiator came loose.... because a small PCB, making the junction between lower and upper end of radiator and being a support for small ceramic condensator, was completely burnt ! See picture below ....
This PCB burnout was sure not caused by too much power : never, on any band, there has been more than 50w applied.... So, came to conclusion that the PCB failure was due to the fact that the top radiator section can become loaded by static rain / wind, and then regularly discharges by arcing towards the lower section (only this one is DC grounded !) - burning slowly through the PCB !