Currently each station sends bulk data to server via winlink(email) using packet or telnet if available.
MT63 -
M17 - open source codec for voice and data
APRS - uncon only, limited payload, but may be enough
AX.25 - PACKET (either con or uncon methods)
VARA - (connected mode only though) file tx, chat, winlink
LORA/LORAWAN? - unlikely due to data throughput limitations, and low RF power
CATS - See issue #42
Maybe have a revolving query that looks for holes and sends to assigned station for updates?
At rocket recovery event, we relied on time slotting (beaconing at 5 second intervals) the APRS positions (plus time for digi-peat) to ensure clear airspace. It worked well, and was rather fun to listen to. If we implemented something like this for Bear, each station would get it's assigned slot automatically. Works well if all stations can hear the same thing for db population, but where this event is spread out, multiple gateways would have to be utilized to conduct it. Clocks have to be synchronized. Also leave a timeslot for query or dnf data coming back from the main server
Could use a control message to indicate when the database has an updated record for ?
APRS for queries to/from server, and position updates (it was very useful having a live map with some of the rovers, stations, and sweeps on it.
One of the benefits of winlink is the built in support for multiple modes (telnet, vara fm, vara hf, packet, and so on) the station is able to select which mode works best for them, but the data all goes to the same end location.
Server location?
if it were aprs, Igate routes back to server(could we direct to our private server address?)
if packet, then the gateway needs to receive and convert to IP and communicate to the server, then when responses come back to return the other direction.
What happens if the internet/server connection drops out? Should the server have the same RF link method ability to be connected back to the stations?
Ideally, I think we should try to satisfy the following, but somewhat difficult to adopt new tech also..
-utilize existing equipment for operators
-use an unconnected type so that other listening stations can automatically stuff their own db without having to send queries all the time. this way our key mtn top stations can cover large area.
-use existing infrastructure if possible
Currently we rely on permanent winlink gateways at Red Spur and in the Valley, and setup a temporary one on Temple peak. digi's, those are however a connected type
APRS is the other established digital mode, but would be better off main channel for data bandwidth. could use aprs on common channel for low traffic queries or station to station messaging
MT63 - M17 - open source codec for voice and data APRS - uncon only, limited payload, but may be enough AX.25 - PACKET (either con or uncon methods) VARA - (connected mode only though) file tx, chat, winlink LORA/LORAWAN? - unlikely due to data throughput limitations, and low RF power CATS - See issue #42
Maybe have a revolving query that looks for holes and sends to assigned station for updates?
At rocket recovery event, we relied on time slotting (beaconing at 5 second intervals) the APRS positions (plus time for digi-peat) to ensure clear airspace. It worked well, and was rather fun to listen to. If we implemented something like this for Bear, each station would get it's assigned slot automatically. Works well if all stations can hear the same thing for db population, but where this event is spread out, multiple gateways would have to be utilized to conduct it. Clocks have to be synchronized. Also leave a timeslot for query or dnf data coming back from the main server
Could use a control message to indicate when the database has an updated record for ?
APRS for queries to/from server, and position updates (it was very useful having a live map with some of the rovers, stations, and sweeps on it.
One of the benefits of winlink is the built in support for multiple modes (telnet, vara fm, vara hf, packet, and so on) the station is able to select which mode works best for them, but the data all goes to the same end location.
Server location? if it were aprs, Igate routes back to server(could we direct to our private server address?)
What happens if the internet/server connection drops out? Should the server have the same RF link method ability to be connected back to the stations?
Ideally, I think we should try to satisfy the following, but somewhat difficult to adopt new tech also.. -utilize existing equipment for operators -use an unconnected type so that other listening stations can automatically stuff their own db without having to send queries all the time. this way our key mtn top stations can cover large area. -use existing infrastructure if possible
Currently we rely on permanent winlink gateways at Red Spur and in the Valley, and setup a temporary one on Temple peak. digi's, those are however a connected type
APRS is the other established digital mode, but would be better off main channel for data bandwidth. could use aprs on common channel for low traffic queries or station to station messaging