Finding the G2 Protocol

We had the Trav’ler protocol mostly figured out. RS-485, 57600 baud, bare > prompt, a <motor_id> <degrees> to move, AZ = / EL = to read position. Clean, predictable, a little primitive. Then the Carryout G2 showed up.

A different cable, a different bus

The first sign this wasn’t going to be a drop-in was the connector. The Trav’ler uses an RJ-25 (6P6C) for RS-485 half-duplex — two wires carry both directions, one device talks at a time. The G2 has the same physical jack (RJ-12 6P6C), but it’s RS-422 full-duplex: separate TX and RX differential pairs, four wires, simultaneous bidirectional communication.

Chris Davidson’s winegard-sky-scan repo had the wiring guide. Without it, we’d have been guessing at a 6-pin connector with no silkscreen and no documentation.

Pin	Wire Color (confirmed)	RS-422 Function
1	Orange/White	GND (PE)
2	Orange	TX+ (TA) — computer to dish
3	Green/White	TX- (TB) — computer to dish
4	Blue	RX+ (RA) — dish to computer
5	Blue/White	RX- (RB) — dish to computer
6	Green	Not connected

We used a DSD TECH SH-U11 USB-to-RS422 adapter with an FTDI FT232R chip. Plugged it in, opened a terminal at 57600 (the Trav’ler baud rate), and got nothing.

The baud rate wasn’t what we expected

57600 — silence. No prompt, no garbage, nothing. The adapter’s RX LED wasn’t even flickering during boot. Tried 9600, 19200, 38400 — nothing. Then 115200, and the terminal filled with text.

Bootloader v1.01
SPI1 init @ 4 MHz
Motor init: System=12Inch, master=40000 steps, slave=24960 steps
SPI2 init @ 6.857 MHz
EXTENDED_DVB_DEBUG ENABLED
BCM4515 ID 0x4515 Rev B0, FW v113.37
Enabled LNB STB
Ant ID - 12-IN G2

115200. Double the Trav’ler’s baud rate. And a boot log that was actually telling us what it was doing — SPI bus initialization, motor configuration, DVB tuner identification. The Trav’ler just silently boots and eventually spits out NoGPS or No LNB Voltage.

The polarity puzzle

Except those first few sessions weren’t clean. Sometimes we’d get perfect ASCII output. Other times: garbled characters at the correct baud rate. Not random noise — structured garbage, with consistent timing but wrong byte values.

This is the signature of an inverted differential pair. RS-422/485 uses differential signaling: the logic level is determined by which wire is more positive. Swap the + and - wires on either the TX or RX pair, and every bit inverts. The UART framing still looks valid (start bit, data bits, stop bit), so you get characters — just the wrong ones.

Caution

Polarity is critical on the G2. Swapping +/- on the RX pair (dish-to-computer) produces garbled data at the correct baud rate — systematic bit inversion, not random noise. Swapping +/- on the TX pair (computer-to-dish) causes silent failure — the dish never responds because it can’t decode the inverted framing.

If you’re getting structured garbage at 115200 baud, swap the two wires on your RX pair before trying anything else.

Once we got the polarity sorted, the connection was rock solid. Full-duplex RS-422 at 115200 is noticeably snappier than half-duplex RS-485 at 57600 — no bus turnaround penalty.

The first ?

We sent a ? and got back something we didn’t expect:

TRK>?
Enter <a3981> - A3981 Stepper Driver IC
Enter <adc> - Analog to Digital Converter
Enter <dipswitch> - DIP Switch
Enter <dvb> - DVB Tuner
Enter <eeprom> - EEPROM
Enter <gpio> - GPIO
Enter <latlon> - Lat/Lon Calculator
Enter <mot> - Motor Control
Enter <nvs> - Non-Volatile Storage
Enter <os> - Operating System
Enter <peak> - Peak/DiSEqC Switch
Enter <step> - Stepper Motor
TRK>

Twelve submenus. The Trav’ler’s HAL 2.05 firmware has maybe four or five commands at the root level. This thing had dedicated submenus for the motor driver ICs, the DVB tuner, GPIO pins, non-volatile storage, ADC readings — it was a full embedded debug shell.

And the prompt: TRK>. Not a bare >, but a labeled prompt that changes with context: MOT> in the motor submenu, NVS> in storage, DVB> in the tuner, EE> in EEPROM. The firmware is telling you where you are. The Trav’ler variants just give you > everywhere and you have to track context yourself.

Position format — Angle[0], not AZ =

The motor submenu confirmed the first real protocol difference. On the Trav’ler:

> a
AZ = 180.00  EL = 45.00  SK = 0.00

On the G2:

MOT> a
Angle[0] = 180.00
Angle[1] = 45.00

Same a command, different response format. No skew motor (the G2 doesn’t have one). And Angle[0]/Angle[1] instead of named AZ/EL fields — the firmware treats motors as an indexed array rather than named axes. Move commands still use a <id> <deg>, which was a relief. But every regex we’d written for position parsing was wrong for this variant.

The move confirmation format is also different: Angle = 46.00 (no array index) instead of AZ = 46.00. Just enough variation to break naive parsing.

Killing the satellite search

On first boot, the G2 does the same annoying thing the Trav’ler does: it starts hunting for TV satellites. On the Trav’ler, you enter the search submenu and kill it. On the G2, the approach is different — you go nuclear.

NVS index 20: Disable Tracker Proc. Set it to TRUE and the firmware skips the satellite search entirely on every boot. Permanent, survives power cycles, stored in flash.

TRK> nvs
NVS> e 20 1
NVS> s
NVS>

e 20 1 sets the value, s saves to flash. After this, the G2 boots to TRK> and waits. No search, no homing sequence (with NVS 20 = TRUE, the motors stay uncalibrated — the homing sequence is part of the tracker process).

Note

With the tracker disabled, the azimuth position register reads as 2147483647 (INT_MAX) — a sentinel value meaning “uncalibrated.” You need to explicitly home the motors with h 0 and h 1 in the MOT submenu before position readings are meaningful.

Firmware identification

The OS submenu gave us the full picture:

TRK> os
OS> id
NVS Version: 02.02.48
System ID: 12-IN G2
Copyright 2013 - Winegard Company

Firmware 02.02.48, built in 2013. A 12-inch Carryout G2. The MCU is an NXP MK60DN512VLQ10 — a Kinetis K60, ARM Cortex-M4 at 96 MHz with 512 KB flash and 128 KB RAM. That’s a serious microcontroller for a satellite dish from 2013. The original Trav’ler’s MCU is unknown, and based on the simpler firmware shell, it’s likely something much more modest.

What we were looking at

By the end of that first session, the picture was clear: the Carryout G2 is a fundamentally more capable platform than the original Trav’ler. Two A3981 stepper motor driver ICs controlled via SPI. A BCM4515 DVB-S2 tuner with DiSEqC 2.x support. A full GPIO debug interface. Non-volatile storage with 130+ named parameters. An ADC subsystem for raw signal measurements.

And unlike the Trav’ler — where the IDU (indoor unit) is a dumb RS-485 passthrough to the ODU (outdoor unit) — the G2 is a single self-contained unit. Everything is on one board, accessible through one serial port. The debug shell is talking directly to the MCU that drives the motors, reads the tuner, and manages the entire system.

The motor control protocol (a <id> <deg>) was compatible enough with the Trav’ler family that writing a CarryoutG2Protocol subclass was straightforward. The hard part was everything else — the twelve submenus full of commands we’d never seen before, the different position format, the named prompts, the NVS configuration system. Mapping all of that would take the console-probe tool, the GPIO mapping session, and a lot of hours at the serial terminal.

But we knew it was worth it. This wasn’t just a dish that could point at things. It had a built-in DVB-S2 receiver with RSSI readings, a signal analysis chain, and a firmware command called azscanwxp that we’d later discover was a radio telescope mode.