Repeater controller

From CECS wiki
Jump to navigation Jump to search

This page is to brainstorm a new repeater controller (from scratch), either embeded or pc based, or a hybrid of the two.

This is a high level description, an actual implementation can be found at Repeater controller progress

Design Goals[edit]

The goal is to create a fully functioning repeater controller that is simple enough to build but complex enough to exceed the functionality most current commercial repeater controllers. This would be accomplished via a multi-tier design, where the first tier is a very simple failsafe embedded system, and additional tiers are implemented using commodity PC hardware and custom software.

Requirements of the design are to:

  • meet all FCC requirements for ID, etc.
  • support enough audio channels to meet future needs, with possibilities to expand
  • have a fixed hardware core with enough functionality that expansion via software in higher tiers is easy and seamless
  • have an event driven design so that concurrent actions (especially between tiers) are not mutually exclusive

Basic outline[edit]

Required features:

  • remote control via audio touchtone or hard wired line (serial? ethernet? phone?)
  • ID timer to satisfy FCC regulations
  • morse code or voice ID
  • recognize and use PTT and COS and CTCSS logic signals
  • audio mixer to mix incoming signal with ID signal
  • nvram and reprogrammable access codes
  • programamble timers

Optional features:

  • scheduler for timed and regular events
  • voice recording and/or generation (festival)
  • morse code generation
  • audio mixer to merge multiple external audio sources (including other repeaters)
  • programmable macros
  • APRS support (on data sideband)
  • automatic direction finding (phased array?)
  • voice fingerprinting
  • speach recognition and interpretation
  • weather station support

Approaches:

embedded system (PIC chip)
The QST article approaches this as an embedded system. Their design is functional, but limited, and missing some of the optional features listed above. Programming an embedded system would probably involve assembly language.
BTX motherboard
The goal would be to either rack mount in a metal box or inside the existing repeater chassis a motherboard and (flash?) drive containing linux, festival, asterisk, echoirlp, etc. Pieces would need to be assembled and glue software written.

Ideal functionality[edit]

I/O summary[edit]

  • control serial port (usb or rs232)
  • accessory serial port (link radio and/or weather station)
  • ethernet (through computer?)
  • digital inputs for accessories
  • digital outputs for accessories
  • audio inputs
  • audio dectectors (tone, vox, DTMF, COR)
  • sensors (input signal: strength, S/N ratio?, deviation)

functions[edit]

  • digital output on/off/toggle(delay)
  • digital voice record
  • digital voice playback (interruptable via cor or other)
  • tone sequence
  • route/mix audio
  • set memory flags
  • morse code generator (for ID)

programmable functions[edit]

  • scheduling
  • event triggered timers
    • start timer on event
    • run action on timer expiration
    • cancel timer on event
  • macros (sequence of events and delays)
  • preset mixing modes
  • preset programmable function groups (enable/disable all together)

events[edit]

  • COR on chanel activated
  • COR with tone activated
  • VOX (without COR) activated
  • DTMF squence received
  • control function triggered
  • timeout timer expired
  • serial pattern recognized (weather station? external radio?)
  • digital input (on / off / transition on / transition off)
  • watchdog timer reset
  • power on reset

control[edit]

  • via ethernet
  • via serial port
  • via DTMF on DTMF enabled audio inputs (including DTMF muting)
  • (optional) voice command and / or voice finger printing
  • via macro
  • enable/disable/trigger (macro, timer, schedule, audio channel)

audio[edit]

  • each audio channel has (audio in + COR) or (audio out + PTT) and audio level matching pot
  • tone generator
  • tone detector(s)
  • tone filter(s)?
  • DTMF generator
  • DTMF detector(s)
  • voice recorder
  • recorded voice player (abortable -> generates event)
  • misc bidirectional channels:
    • radio 1-3
    • computer
    • phone
    • local speaker / mic
    • Ability to control if CTCSS is mixed with any particular other signal

audio mixing possiblities[edit]

  • central audio bus
    • mix selected audio channels into a single final signal
    • level adjust result separately for each output channel
    • mute or allow audio to each output depending on (use/block) masks
  • multimixing
    • separate audio mixer for each output channel
    • allow each output channel to select its audio inputs

multicontrol[edit]

  • should be able to record a message while playing another and mixing other channels
  • should be able to accept new control program data while operating

CAT1000 description[edit]

PIC based controller description[edit]

Trivial controller description[edit]

(This should be the description of the controller in the 70 cm repeater.)

Three Tier design[edit]

It is unclear where the division between first and second teir goes.

  1. First tier is implemented in a real time embedded controller. Some functions can be replaced by teir 2 functions, but tier 1 timers can't be disabled by tier 2, only periodically reset
  2. Second teir is implemented in a software control loop in a computer; this should be as seamless with first teir as possible
  3. Third tier functions mostly are out of the control loop; they can transparently monitor audio and events, and inject commands into the second teir

first tier[edit]

This would be an embedded system with multiple failsafes. In an emergency, it could act as a crippled but stand alone repeater controller.

  • Critical functions
    • ID timer
    • morse code playback and/or trivial voice playback or synthesis
    • time out timer (stuck key cutoff)
  • audio routing, mixing, and level adjust (at least 4 channel)
    • RF 1 in / out
    • RF 2 in / out
    • computer in / out
    • morse code or voice ID in / out
    • control radio or link radio in / out
  • control and command recognition
    • DTMF muting and decoding for RF 1, RF 2, control/link
    • primitive reprogrammable DTMF control commands
    • serial control from computer
  • auxillary ports: the embedded controller must be able to make up for the computer's lack of I/O ports
    • extra single bit digital I/O lines for controlling accessories
    • extra serial ports for controlling TNC, weather station, link radio, etc., if necessary
    • USB port as primary link to computer if necessary
    • note that an IRLP board would do some of this already
  • memory (saved settings)
    • ID and/or voice messages
    • STATE
      • repeater ON / OFF (mixer setting?)
      • command mode
      • CTCSS detect
      • repeat access reqd
    • access codes
    • timer settings?
    • macros?
    • mixer settings?

second tier[edit]

advanced control by computer -- preferably linux, via serial control and audio channel to first tier controller

  • ntp synchronized clock
  • complex scheduling
    • meeting, tailgate announcements, other actions
  • DTMF command macros and advanced control
  • voice synthesis and advanced voice recording and playback
    • voice ID
    • voice clock (quiktime)
  • IRLP and Echolink
  • remote control via ethernet (or phone line??)

third tier[edit]

Additional modules for advanced research and other optional features:

  • voice fingerprinting and recognition (with optional blocking and/or recording)
  • advanced logging and recording including voice (vs. white noise) descrimination
  • CW recognition
  • voice command recognition
  • personal message boxes, delayed voice recordings
  • weather reports (from local and remote sensors)
  • APRS bridge including recognition (and squelching) of mic encoders
  • modulation level double separation (with delayed playback?) (or double detection with courtsey tone alert)
  • signal strength report (via courtsey tone?)
  • deviation report
  • S/N ratio report (is this possible?)

Command structure[edit]

first tier memories and commands[edit]

All commands supported via audio line (RF) and serial port. Voice messages should have a data representation maybe?

  • timers ( set / reset / check value)
    • id timer1 (10 min)
    • id timer2 (30 min)
    • time out timer (per xmitter or per input?)
    • delay between COR drop and courtesy
    • delay between courtesy and tone drop
    • delay between tone drop and PTT drop
    • DTMF start / end timers
  • macros (what are they)
    • event that triggers macro (incl DTMF decode)
    • commands: set / clear / describe / execute
    • macro executes a series of commands, incl set / clear / macro
  • message banks (play(chans) / record / erase / xfer)
    • morse code (2)
    • courtesy tone (series of tones, delays) (5+)
    • voice recording?
    • voice synth?
    • DTMF string
  • Events (macro slots executed on event, event reported via serial to second tier when not triggered by a command)
    • id message (2)
    • time out message
    • time in message
    • control error message
    • DTMF decode match events
    • unassigned events (additional macro slots) ?
    • digital input events (trigger on one of on/off/pulse)
    • power up event
    • watchdog timer event (more than one level?)
  • mixer settings
    • channels (RF1 RF2 computer ctrl) only
    • enable/disable route from A->B
  • control switches and states (on / off / toggle / momentary / read)
    • PTT (can force state)
    • digital outputs
    • tone decode required for repeat (digital input, per channel)
    • tone decode required for command (digital input, per channel)
    • tone encode on output (per channel?)
    • DTMF decode to serial
    • DTMF auto mute (per mixer channel (I/O matrix))
    • DTMF regen / repeat (per mixer channel (I/O matrix))
  • access codes (clear/set/read)
    • run command
    • play message
    • enter / exit command mode? (needs a timeout)
    • change control switch

minimal first tier[edit]

All commands supported via audio line (RF) and serial port. Voice messages should have a data representation maybe?

  • timers ( set / reset / check value)
    • id timer1 (10 min)
    • id timer2 (30 min)
    • time out timer (per xmitter or per input?)
    • delay between COR drop and courtesy
    • delay between courtesy and tone drop
    • delay between tone drop and PTT drop
    • DTMF start / end timers
    • time of day (set / play)
  • tone sequences
    • set / play
    • courtesy / time out / time in / error / power up / watch dog reset / misc?
  • play
    • morse code ID
    • courtesy tone (series of tones, delays) (5+)
    • tone signal memory?
    • DTMF string
  • mixer settings
    • channels (RF1 RF2 computer ctrl) only
    • enable/disable route from A->B
  • control switches and states (on / off / toggle / momentary / read)
    • PTT (can force state)
    • digital outputs
    • tone decode required for repeat (digital input, per channel)
    • tone decode required for command (digital input, per channel)
    • tone encode on output (per channel?)
    • DTMF decode to serial
    • DTMF auto mute (per mixer channel (I/O matrix))
    • DTMF regen / repeat (per mixer channel (I/O matrix))
  • access codes (clear/set/read)
    • play time in morse code
    • force ID
    • enable repeat
    • disable repeat
    • disconnect computer audio? / force mixer mode change

minimal first tier command structure[edit]

  • (s) set
    • (i) idtimer inteval int(secs)
    • (I) idtimer time left (resets when zero or trigger at?)
    • (c) chimetime int(min?)
    • (C) chime offset int(min)
    • (t) time out timer int(secs)
    • (1-2) courtesey tone signal strength thresholds
  • (i) ID callsign (for morse code)
    • 0 params -- return current
    • 2 params -- set (send same call twice sep by space followed by return)
  • (c) chime 1-8 (delay freq duration){0,5}
    • 0 params lists all chimes
    • 1 param plays specified chime
    • 1+3n sets chime
    • all else errors
    • 0=powerup 1=time out 2=time in 3=watchdog 4=courtesy 5=courtesy2 6=courtesey3
  • (d) dtmf string(digits) (plays digits)
  • (p) ptt (0|1) force state (??)
  • (o) out int(port) int(state)
  • (r) repeat (0|1)
  • (m) ??mixer int(state)
  • ??? dtmf access code int(slot) (digits) (command)
  • ??? tone settings
  • ??? dtmf settings
  • ??? dtmf regen settings
  • request signal strength
    • report min/max/avg at ptt drop
    • sample now (??)

minimal first tier async output to computer[edit]

  • dtmf (digits) decode...
  • powerup
  • timer # (triggered)
  • watchdog reset
  • code int(slot)

I/O lines

  • cor / tone detect / sql level?

Implementation details[edit]

  • Audio impedance
    • 8 ohms (very common)
    • 100 ohms
    • 600 ohms
Device input output
speaker - 8
standard mic ? -
condenser mic ? -
repeater (TX) ? (RX) ?
computer ? ?

Existing designs[edit]


arduino based designs[edit]

(nothing substantial found)

Retrieved from "http://newton.i2lab.ucf.edu/w/index.php?title=Repeater_controller&oldid=7083"