Step-by-Step Install & Configuration Checklist

(AllStarLink v3 + Raspberry Pi 4 + Shari PiHat)

1. Hardware Preparation

  • ☐ Install Raspberry Pi 4 in a ventilated case
  • ☐ Seat AURSINC Shari PiHat firmly on the GPIO header
  • ☐ Attach antenna (dummy load recommended for initial testing)
  • ☐ Use a clean, regulated 5V power supply (≥3A recommended)
  • ☐ Insert quality microSD card (32–64 GB, name brand)

2. Base OS & AllStarLink v3 Install

  • ☐ Flash official AllStarLink v3 image
  • ☐ Boot Pi and complete first-run console wizard
  • ☐ Set:
    • Hostname
    • Timezone
    • Locale
  • ☐ Enable SSH
  • ☐ Update system:
sudo apt update && sudo apt full-upgrade -y

3. Network Configuration

  • ☐ Assign static IP (or DHCP reservation)
  • ☐ Confirm:
    • DNS resolution
    • NTP time sync
  • ☐ Test outbound connectivity:
ping google.com

4. AllStar Node Registration

  • ☐ Request node number from AllStarLink portal
  • ☐ Record:
    • Node number
    • Node password
    • SIP credentials
  • ☐ Confirm node shows “Assigned” status

5. Audio & GPIO Bring-Up (Shari PiHat)

  • ☐ Confirm ALSA device presence:
aplay -l
arecord -l

☐ Verify GPIO access (no conflicts with serial console)

☐ Disable Bluetooth audio if not needed

☐ Confirm PTT and COS logic levels match PiHat documentation

6. SA818 RF Module Setup

  • ☐ Program:
    • RX frequency
    • TX frequency
    • CTCSS (encode/decode as needed)
    • Squelch level
  • ☐ Verify TX inhibit until PTT asserted
  • ☐ Confirm deviation is reasonable (no clipping)

7. Asterisk / AllStar Core Configuration

  • ☐ Edit node definition files:
    • rpt.conf
    • extensions.conf
  • ☐ Configure channel driver (GPIO-based)
  • ☐ Validate:
    • Node number matches registration
    • Passwords correct
  • ☐ Restart services:
sudo systemctl restart asterisk

8. Initial RF & Network Tests

  • ☐ Verify node registers to network
  • ☐ Key RF PTT → confirm COS detection
  • ☐ Transmit DTMF → confirm command recognition
  • ☐ Connect to a known hub for test audio

9. Audio Level Calibration

  • ☐ Set RX audio so COS opens reliably
  • ☐ Adjust TX audio for clean deviation
  • ☐ Confirm no clipping or distortion
  • ☐ Re-test over live link

10. Reliability Hardening (Recommended)

  • ☐ Enable watchdog
  • ☐ Enable auto-reconnect logic
  • ☐ Disable Wi-Fi power save (if Wi-Fi used)
  • ☐ Label node with callsign + node number
  • ☐ Document final config values

Node Templates

Template A: Simplex AllStar Node

Use Case: Home node, portable node, RF access point

Design Characteristics

  • Single RF frequency
  • No transmitter hold-off
  • Short hang times
  • RF-initiated linking allowed

Key Parameters (Conceptual)

[rpt]
node = 12345
callsign = W5RTM
rxchannel = SimplexRX
txchannel = SimplexTX
duplex = 0
hangtime = 50
totime = 180000
idtime = 600000
tailmessagetime = 0

RF Logic

  • COS directly gates audio
  • PTT asserted immediately on inbound audio
  • Optional CTCSS decode for access control

Recommended Enhancements

  • DTMF command whitelist
  • Auto-disconnect timer
  • Nighttime RF mute option

Template B: Repeater-Linked AllStar Node

Use Case: Repeater controller, link radio, remote base

Design Characteristics

  • Separate RX/TX logic
  • Transmit delay to protect repeater
  • Longer hang times
  • Stricter DTMF access control

Key Parameters (Conceptual)

[rpt]
node = 23456
callsign = W5RTM
rxchannel = RepeaterRX
txchannel = RepeaterTX
duplex = 1
txdelay = 150
hangtime = 300
totime = 600000
idtime = 540000

RF Logic

  • COS qualified before audio pass
  • TX delay prevents kerchunking
  • Optional courtesy tone injection

Recommended Enhancements

  • Scheduler-based link control
  • Backup hub failover
  • Separate control operator DTMF group

Simplex vs. Repeater: Operational Comparison

AspectSimplex NodeRepeater Node
RF ComplexityLowModerate–High
TX DelayMinimalRequired
Hang TimeShortLonger
PortabilityExcellentLimited
Failure ImpactIsolatedSystem-wide
Ideal UseHome / EMCOMMInfrastructure

Final Notes

This checklist and template set is intentionally repeatable. You should be able to:

  • Clone SD cards
  • Swap node numbers
  • Reuse RF logic
  • Maintain consistent audio behavior across multiple deployments

Leave a Reply

Your email address will not be published. Required fields are marked *