-
Notifications
You must be signed in to change notification settings - Fork 1
Compatible Devices
Pi-Sat relies on Hamlib for radio and rotator control compatibility. No point in re-inventing the wheel right? That means Pi-Sat compatibility follows two layers:
- whether Hamlib supports the device
- whether the device behaves correctly in the selected control mode
Pi-Sat itself supports both network and locally managed Hamlib control paths.
Related pages:
Pi-Sat treats the station as two separate systems:
- radio control
- rotator control
Within radio control, Pi-Sat breaks operation into two logical roles:
- RX
- TX
Those RX and TX roles may be handled by:
- one physical full-duplex radio
- one physical radio used for both roles in a simpler workflow
- two separate radios
- a physical TX radio plus a separate SDR or network receive path
Rotator control is completely separate from the RX/TX radio layout.
This is the simplest arrangement.
Examples:
- receive on an SDR only
- receive on one physical radio only
Typical use:
- monitoring
- receive-only satellites (one of my favorites - SSTV)
- early station bring-up and testing
How it maps into Pi-Sat:
- configure the RX section
- leave TX disabled if not needed
- leave rotator disabled if not needed (omni antennas for example)
Pi-Sat supports a separate TX role because uplink control may live on a different device from RX.
Examples:
- TX on one physical radio while receiving on something else
- testing uplink control independently from SDR receive
How it maps into Pi-Sat:
- configure the TX section
- configure the RX section separately if receive is also used
A full-duplex radio such as an Icom IC-9700 is a common linear-satellite setup because it can handle RX and TX at the same time.
Typical use:
- linear satellites
- serious live Doppler correction workflows
- monitoring your own downlink while transmitting
How it maps into Pi-Sat:
- configure both RX and TX sections
- they may point to the same physical radio
- Pi-Sat still treats them as separate logical roles
This keeps the control logic clear even when one physical radio is doing both jobs.
This is an important supported layout.
Example:
- TX on a physical radio connected by USB serial control
- RX on a network-accessible SDR/control path
This is useful when:
- you want a larger or cleaner RX waterfall
- you want independent receive hardware
- you want to uplink from a radio but monitor from an SDR
How it maps into Pi-Sat:
- RX uses the RX section
- TX uses the TX section
- each role can use a different connectivity method
Pi-Sat supports two main connectivity styles for RX, TX, and rotator roles.
local means Pi-Sat starts and manages the Hamlib daemon locally on the Pi for a directly attached serial device.
Use this for:
- physical radios connected by USB serial / COM-style paths
- physical rotators connected by USB serial / COM-style paths
In the settings UI, directly attached USB serial devices are automatically detected and listed in the serial-port dropdown when available. This is intended to make local device selection easier and reduce manual path entry mistakes.
Typical settings fields used:
serial_portbaudmodel_id
network means Pi-Sat talks to an already running network service.
Use this for:
- network
rigctld - network
rotctld - SDR/control paths exposed over the network
Typical settings fields used:
hostport
Pi-Sat supports radios through:
- existing network
rigctld - locally managed
rigctldfor directly attached serial devices
The practical compatibility question is:
- does Hamlib support the radio model and the control path you want to use?
For the full Hamlib radio list, see:
Pi-Sat supports rotators through:
- existing network
rotctld - locally managed
rotctldfor directly attached serial devices
For the full Hamlib rotator list, see:
Pi-Sat currently treats SDR interaction as a control/readback path rather than a full decode platform. Compatibility depends on the SDR control path being exposed in a way Pi-Sat can poll and coordinate. While I would love to include a dedicated waterfall and SDR software suite in this project, that's beyond the scope and frankly my ability as this point.
Pi-Sat is designed around these categories:
- network-controlled radios
- local serial Hamlib-controlled radios
- radios used for RX only
- radios used for TX only
- one radio handling both RX and TX
- split RX/TX device layouts
- network-controlled rotators
- local serial Hamlib-controlled rotators
- SDR frequency readback/control paths used alongside the tuning workflow
- A device being listed by Hamlib does not guarantee perfect behavior in every firmware revision or cable/USB environment
- Some devices behave differently between local serial control and an existing network daemon
- Stable serial device naming matters for reliable startup
- Multi-device setups should be validated on the actual Pi before field use
- verify basic Hamlib control manually first
- then verify Pi-Sat readback
- then verify live pass behavior
- then verify any TX or rotator write path
Pi-Sat is designed to coordinate these devices, but the first layer of truth is still whether the device behaves cleanly under Hamlib on that specific system.