New Repeater Questions

[EA7KIR]

Some will know I intend to launch a new DATV repeater in a part of Spain where DATV is virtually unheard of - despite there being pleny of licenced amatuers. With this in mind, there are a few things I'd like to hear your views and the pros & conns for each.

1. Should I choose DVBS2 or DVBT2?
2. Vertical polarisation or horizontal?
3. In/out frequencies in same band or not?

I imagine these questions must have been discussed at length in the past, but I'd like to hear what people think today.

[g8gtz]

1. I would do DVB-S2 as equipment is more readily available and you can run narrow band widths to improve S/N.

2. In the UK horizontal was mandated for repeaters many years ago, the logic was to make it compatible with yagis used for narrow band. Going vertical does have advantages in that the repeater aerials are simpler (getting a true omni horizontal polarised antenna is not easy) and stations near by can use a white stick to access.

3. Cross band is much easier as you don't have so many problems with defense so the filters can be much simpler.

73

Noel

[G3GJA]

Michael

In addition to Noel's comments,

1. DVB-T needs better linearity in the RF power amplifiers implying lower power output than DVB-S2. USA ATV stations use DVB-T, but the reasons appear to be more to do with the availability of plug-in appliances to transmit and receive with than any performance advantage. Being an ex-broadcast engineer you will know that DVB-T was chosen for commercial terrestrial use in Europe because of its resilience to multi-path signal corruption, but in practice the low symbol rate DVB-S2 transmissions and high rates of FEC used by ATV negates any problem caused by multi-path signals.

2. There's no readily available omni-directional vertical antenna for 23cm that has more gain than an Alford Slot gives in horizontal polarization. The Slot is easy to make too. Few 23cm stations have vertical antennas in the UK as there is very little FM repeater operation on the band. That probably holds for Spain too.

3. Same band operation at 23cm needs two frequencies at least 30MHz apart; this is set by the performance of the duplex filters if using a single antenna. Single antenna systems need over 110dB isolation between the TX and RX from the filtering. You can reduced this by up to 30dB if using vertical separation between TX and RX antennas at the cost of having different coverages because of the height difference. This isn't a problem if the antennas are 25m above ground level usually.

Crossband repeaters are much easier and cheaper to get going, but users need dual-band antenna TX/RX systems.

73

Clive

[DL5BCA]

Hello Michael,

I agree with the previous commenters. We also operate all ATV inputs and outputs horizontally.

Inputs: 70cm DVBS, 23cm, 13cm, 3cm FM analog
Outputs: 13cm DVBS, 5.7GHz, and 10GHz FM analog
On the 13cm band, we operate two antennas, each with filters in front of them.

If you want to operate in-band, you have to keep in mind that all receivers also require duplex filters.

Good luck.

73 Thomas DL5BCA

[Pa3fbx]

Hi , To add some thoughts..
Use DVBS or DVBS2 and multiple bandwidth for receiving.
DVBT is better but local test showed not good results using a Knucker Receiver comparing to dvbs2 Minitiouner..

We got severe problems with power windmills with tend to grow higher every year.
They cause multipath problems witch might be a reason to reinvestigate DVBT.

Get internet on repeater site to monitor/control/and stream in/out.
This makes a more flexible repeater where RX or TX problems can be overcome by internet stream.
Also look in good backchannel as digital repeater easy takes upto 10 sec delay witch makes full duplex difficult.

Benno

[HB9IAM]

After many years of using the first Repeater HB9TV analog FM relay, we switch to DVB-S for 20 years.

With the proliferation of modes, we opted for a transponder that works similarly to the QO-100.

It accepts all digital and analog formats : Video DVB, SSB, FM, phone FM wide FM, AM, and DATA !

The implementation is simple, and the results of my measurements are breathtaking!

You can find a description on the website SwissATV.ch
https://home.swiswissATVtv.ch/2024/12/u ... -mondiale/

73's from Pierre HB9IAM = F8BXA

[Basil]

Pierre, the URL is mangled.

[ON1RC]

You can find a description on the website SwissATV.ch ......the right link ....

https://home.swissatv.ch/2024/12/une-premiere-mondiale/

73's From ON1RC
Chris

[EA7KIR]

PROGRESS (or not)
The big stumbling block right now, is running the BATC input code concurrently with the main pipeline (eventually, the solution can also be applied to the Receiver code). So, out of curiosity, I asked CoPilot to review the entire application. It failed to realise the problem, but I think the report is interesting and helpful. Here it is (in markdown format):

Code: Select all

User: using the generated bindings in my go.mod, review this application

Workspace: Collecting workspace information# Application Review: DATV Repeater

Based on the workspace structure and code excerpts, this is a **Digital Amateur Television (DATV) repeater** application written in Go using GStreamer for media pipeline processing.

## Architecture Overview

### Core Components

1. **Main Pipeline** (pipeline.go)
   - Orchestrates video/audio streams using GStreamer
   - Manages three sources: Carousel (slides), BATC stream (RTMP), and Receiver
   - Uses dynamic switching with alpha blending and volume control
   - Leverages [`github.com/go-gst/go-gst`](https://pkg.go.dev/github.com/go-gst/go-gst) generated bindings

2. **State Machine** (fsm.go)
   - Controls transitions between: Standby, Carousel, BATC Listen, Receiver
   - Responds to events: `BatcFoundEv`, `BatcLostEv`, `ReceiverFoundEv`, etc.
   - Coordinates carousel and output commands

3. **Carousel** (RunCarousel.go)
   - Displays slides with configurable intervals (`vars.SecondsPerSlide`)
   - Periodic ident slides with Morse code audio
   - Uses `avlist.AVList` for audio/video frames

4. **Web Admin** (webserver.go)
   - HTMX-based admin interface on port `vars.AdminPort`
   - Pages: System Status, Function Override, Time Schedule, Recent Events
   - Authentication via `crypt.VerifyUserPassword`

### Media Pipeline Sources

**Carousel Source** (newCarouselSrc.go)
- Generates test patterns (color bars, PLUGE, ident slides)
- User photos from `AddUserPhotosToAVList`
- Morse code ident audio (`morse.MkStereoMorse`)

**BATC Source** (newBatcSrcRTMP.go)
- Listens for RTMP streams at `vars.RptBatcListenUrl`
- Implements stream watchdog with atomic counters
- Handles `pad-added` events for dynamic linking
- **Critical**: Detects user connect/disconnect, resets pipeline on timeout

**Receiver Source** (newReceiverSrc.go)
- Mock implementation with `videotestsrc` (ball pattern)
- Configured for DVB-S/S2 reception via UDP

### Sinks

**BATC Sink** (newBetcSink.go)
- Sends RTMP stream to BATC at `vars.RptBatcSendUrl`

**Transmitter Sink** (newTransmitterSinkMOCK.go)
- Mock implementation for DVB-S2 transmission
- Uses `vars.Transmitter*` settings (frequency, symbol rate, FEC, etc.)

## Key Observations

### Strengths

1. **Clean FSM Design**: Clear state transitions with event-driven architecture
2. **GStreamer Integration**: Proper use of generated bindings with bin/ghost pad patterns
3. **Configuration Management**: INI-based config with extensive validation (config/vars/validTx*.go)
4. **Admin Interface**: Functional HTMX-based UI with live updates

### Areas of Concern

#### 1. **BATC Source Watchdog Complexity** (newBatcSrcRTMP.go)
```go
var lastVideoNano int64 = time.Now().UnixNano()
var lastAudioNano int64 = time.Now().UnixNano()
var streamActive int32 = 0
var resetting int32 = 0
var resetCount int32 = 0
```
- Uses 5 atomic variables for stream monitoring
- Complex reset logic with max attempts (10)
- Risk of race conditions during pad linking
- **Recommendation**: Consider simpler approach with single `streamState` atomic

#### 2. **Missing Transmitter Implementation**
The transmitter sink is mocked. For production:
- Need real LibreSDR/Pluto SDR integration (see LibreSDR.md)
- Consider using `libiio` bindings or external process

#### 3. **Error Handling**
Several `log.Fatalf()` calls that terminate the application:
```go
if bin == nil {
    log.Fatalf("failed to create bin")
}
```
**Recommendation**: Use error returns and graceful degradation

#### 4. **Configuration Validation**
Good validation functions (config/vars/validTx*.go), but errors during initialization cause immediate exit:
```go
if err := vars.InitVariables(version, appName, adminName); err != nil {
    fmt.Println(err)
    os.Exit(1)
}
```

#### 5. **Carousel Timing**
Uses `time.NewTicker` but no synchronization with video frame timestamps:
```go
ticker = time.NewTicker(interval)
```
**Recommendation**: Consider using GStreamer clock for frame-accurate timing

### Potential Issues

1. **Audio/Video Sync**: No explicit AV sync mechanism in carousel or BATC source
2. **Pipeline Recovery**: Limited error recovery in main pipeline message loop
3. **Memory Management**: Large `AVListT` loaded into memory (user photos + test patterns)
4. **Shutdown Handling**: 5-second sleep before exit may be insufficient for pipeline cleanup:
   ```go
   time.Sleep(time.Second * time.Duration(vars.SecondsPerSlide))
   ```

### Security Concerns

1. **Admin Interface**: Basic password check without rate limiting
2. **RTMP Stream**: No authentication on incoming BATC streams
3. **Reboot/Poweroff**: Web UI allows system reboot with single click

## Recommendations

### High Priority

1. **Implement Proper BATC Watchdog**
   - Use single state machine instead of multiple atomics
   - Add configurable timeout values
   - Better logging of state transitions

2. **Add Pipeline Error Recovery**
   ```go
   case gst.MessageError:
       // Currently calls log.Fatalf
       // Should attempt graceful recovery
   ```

3. **Improve Shutdown Sequence**
   - Use `WaitGroup` for goroutine coordination
   - Proper pipeline state transitions (Playing → Paused → Null)
   - Remove arbitrary sleep durations

### Medium Priority

4. **Add Integration Tests**
   - Test FSM state transitions
   - Mock GStreamer elements for unit testing
   - Validate configuration edge cases

5. **Enhance Admin Security**
   - Add CSRF protection
   - Implement session management
   - Rate limit authentication attempts

6. **Memory Optimization**
   - Stream user photos instead of loading all into `avlist.AVList`
   - Consider on-demand generation of test patterns

### Low Priority

7. **Documentation**
   - API documentation for pipeline components
   - Deployment guide (currently scattered in NOTES)
   - GStreamer pipeline diagrams

8. **Monitoring**
   - Expose metrics (stream uptime, reset counts, errors)
   - Structured logging (consider `slog` instead of `log`)

## Code Quality

- **Good**: Modular structure, clear separation of concerns
- **Good**: Comprehensive configuration validation
- **Needs Improvement**: Error handling, testing coverage
- **Needs Improvement**: Comments and documentation

## Overall Assessment

This is a **well-structured amateur radio project** with solid GStreamer integration. The use of generated bindings is appropriate and avoids CGO complexity. Main areas for improvement are error resilience, testing, and completing the transmitter implementation.

**Estimated Maturity**: Alpha/Beta - functional for development, needs hardening for production use.