request detailed system diagram for remoting a satellite station
Hello,
Does anyone have a detailed system diagram (or interconnect drawing) showing how they have remoted a satellite station please? Specifically which parts of the system require IP-addressable power on/off, etc.
I am in the process of constructing a new satellite station for U/V linear use at Milwaukee Area Technical College (where I teach). Our Data Communication and Networking class introduces satellite technology which I plan to demonstrate live.
Because the hours of access to the building are limited, and because we teach Data Communication and Networking from two campuses (but have Satellite station at only one), remoting this station would be desirable.
I have an APC IP-addressable power strip (117vac) and some power relays if we need 220vac switched, an IC-9700, two high-power switchable LNAs (2m and 70cm), antennas (20 element RHCP for 2m and 16 Turn G3RUH Helix for 70cm), and a Yaesu 5500 rotor with Green Heron Az/El controller (I'll bring Heliax from home to get to the rooftop). Hopefully our city campus location is not overly noisy. I plan to construct the HEO-ready station as soon as I can be back on campus to do this.
One specific area of concern: how to pass audio over internet. I've heard Skype and some other vehicles have problematic latency but I have yet to remote any station to use 'near real-time audio' for CW or SSB QSOs so I lack experience with this. The satellite computer (controlling antennas and managing Doppler) is a Mac mini running MacLoggerDX and MacDoppler software.
If helpful, I have two surplus new Raspberry Pi 3s (new and unused) that could be repurposed for part of this if helpful.
You'll be happy to know I've been reading the mail and I know to first listen and test so we Tx with minimum power. But as a satellite newby, I'm sure I'll need abundant guidance when we get QRV.
Any detailed system diagrams (could be off-list directly to me) showing how you built and configured such a remote station satellite system would be greatly appreciated.
Thank you
very 73,
Dave KJ9I KD9BOG (at work)
Hi! we have the same issue to want to be solved, but with an Icom IC9100. I saw an Icom Software (https://www.icomamerica.com/en/products/amateur/hf/rsba1/default.aspx) for our case, maybe can work with your 9700 too. We dont try it because for the COVID dont access to the station to try it.
BUT we are still searching an alternative with raspberry pi, to remote control all the station (Rotor, Equipment and audio exchange) so if you find an alternative, please share with us too.
73s Mati LU9CBL
El 17/7/2020 a las 16:06, David J. Schmocker via AMSAT-BB escribió:
Hello,
Does anyone have a detailed system diagram (or interconnect drawing) showing how they have remoted a satellite station please? Specifically which parts of the system require IP-addressable power on/off, etc.
I am in the process of constructing a new satellite station for U/V linear use at Milwaukee Area Technical College (where I teach). Our Data Communication and Networking class introduces satellite technology which I plan to demonstrate live.
Because the hours of access to the building are limited, and because we teach Data Communication and Networking from two campuses (but have Satellite station at only one), remoting this station would be desirable.
I have an APC IP-addressable power strip (117vac) and some power relays if we need 220vac switched, an IC-9700, two high-power switchable LNAs (2m and 70cm), antennas (20 element RHCP for 2m and 16 Turn G3RUH Helix for 70cm), and a Yaesu 5500 rotor with Green Heron Az/El controller (I'll bring Heliax from home to get to the rooftop). Hopefully our city campus location is not overly noisy. I plan to construct the HEO-ready station as soon as I can be back on campus to do this.
One specific area of concern: how to pass audio over internet. I've heard Skype and some other vehicles have problematic latency but I have yet to remote any station to use 'near real-time audio' for CW or SSB QSOs so I lack experience with this. The satellite computer (controlling antennas and managing Doppler) is a Mac mini running MacLoggerDX and MacDoppler software.
If helpful, I have two surplus new Raspberry Pi 3s (new and unused) that could be repurposed for part of this if helpful.
You'll be happy to know I've been reading the mail and I know to first listen and test so we Tx with minimum power. But as a satellite newby, I'm sure I'll need abundant guidance when we get QRV.
Any detailed system diagrams (could be off-list directly to me) showing how you built and configured such a remote station satellite system would be greatly appreciated.
Thank you
very 73,
Dave KJ9I KD9BOG (at work)
Sent via [email protected]. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: https://www.amsat.org/mailman/listinfo/amsat-bb
Does anyone have a detailed system diagram (or interconnect drawing) showing how they have remoted a satellite station please? Specifically which parts of the system require IP-addressable power
on/off, etc.
K8YSE wrote an article of his remote station configuration in the January/February 2014 AMSAT Journal. An archived copy can be found at https://launch.amsat.org/
Then follow the links to the AMSAT Journal archive.
AMSAT members can view the article entitled "An Internet Remote Station" by John Papay, K8YSE, in the January/February 2014 issue of The AMSAT Journal: https://launch.amsat.org/The-AMSAT-Journal-2014
Obviously technology has evolved somewhat in the past six years, but that should get you a good start on what needs to be considered.
73,
Paul Stoetzer, N8HM Executive Vice President AMSAT
On Fri, Jul 17, 2020 at 3:07 PM David J. Schmocker via AMSAT-BB [email protected] wrote:
Hello,
Does anyone have a detailed system diagram (or interconnect drawing) showing how they have remoted a satellite station please? Specifically which parts of the system require IP-addressable power on/off, etc.
I am in the process of constructing a new satellite station for U/V linear use at Milwaukee Area Technical College (where I teach). Our Data Communication and Networking class introduces satellite technology which I plan to demonstrate live.
Because the hours of access to the building are limited, and because we teach Data Communication and Networking from two campuses (but have Satellite station at only one), remoting this station would be desirable.
I have an APC IP-addressable power strip (117vac) and some power relays if we need 220vac switched, an IC-9700, two high-power switchable LNAs (2m and 70cm), antennas (20 element RHCP for 2m and 16 Turn G3RUH Helix for 70cm), and a Yaesu 5500 rotor with Green Heron Az/El controller (I'll bring Heliax from home to get to the rooftop). Hopefully our city campus location is not overly noisy. I plan to construct the HEO-ready station as soon as I can be back on campus to do this.
One specific area of concern: how to pass audio over internet. I've heard Skype and some other vehicles have problematic latency but I have yet to remote any station to use 'near real-time audio' for CW or SSB QSOs so I lack experience with this. The satellite computer (controlling antennas and managing Doppler) is a Mac mini running MacLoggerDX and MacDoppler software.
If helpful, I have two surplus new Raspberry Pi 3s (new and unused) that could be repurposed for part of this if helpful.
You'll be happy to know I've been reading the mail and I know to first listen and test so we Tx with minimum power. But as a satellite newby, I'm sure I'll need abundant guidance when we get QRV.
Any detailed system diagrams (could be off-list directly to me) showing how you built and configured such a remote station satellite system would be greatly appreciated.
Thank you
very 73,
Dave KJ9I KD9BOG (at work)
Sent via [email protected]. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: https://www.amsat.org/mailman/listinfo/amsat-bb
dear Mati: Thank you.. I will share any details discovered! If nothing is out there already in existence, certainly I can design my own solution (this may just take a lot longer).
very 73 and I look forward to contacting LU station Mati via satellites!
very 73,
Dave KJ9I
KD9BOG at work
On 7/17/20 2:23 PM, lu9cbl--- via AMSAT-BB wrote:
Hi! we have the same issue to want to be solved, but with an Icom IC9100. I saw an Icom Software (https://www.icomamerica.com/en/products/amateur/hf/rsba1/default.aspx) for our case, maybe can work with your 9700 too. We dont try it because for the COVID dont access to the station to try it.
BUT we are still searching an alternative with raspberry pi, to remote control all the station (Rotor, Equipment and audio exchange) so if you find an alternative, please share with us too.
73s Mati LU9CBL
El 17/7/2020 a las 16:06, David J. Schmocker via AMSAT-BB escribió:
Hello,
Does anyone have a detailed system diagram (or interconnect drawing) showing how they have remoted a satellite station please? Specifically which parts of the system require IP-addressable power on/off, etc.
I am in the process of constructing a new satellite station for U/V linear use at Milwaukee Area Technical College (where I teach). Our Data Communication and Networking class introduces satellite technology which I plan to demonstrate live.
Because the hours of access to the building are limited, and because we teach Data Communication and Networking from two campuses (but have Satellite station at only one), remoting this station would be desirable.
I have an APC IP-addressable power strip (117vac) and some power relays if we need 220vac switched, an IC-9700, two high-power switchable LNAs (2m and 70cm), antennas (20 element RHCP for 2m and 16 Turn G3RUH Helix for 70cm), and a Yaesu 5500 rotor with Green Heron Az/El controller (I'll bring Heliax from home to get to the rooftop). Hopefully our city campus location is not overly noisy. I plan to construct the HEO-ready station as soon as I can be back on campus to do this.
One specific area of concern: how to pass audio over internet. I've heard Skype and some other vehicles have problematic latency but I have yet to remote any station to use 'near real-time audio' for CW or SSB QSOs so I lack experience with this. The satellite computer (controlling antennas and managing Doppler) is a Mac mini running MacLoggerDX and MacDoppler software.
If helpful, I have two surplus new Raspberry Pi 3s (new and unused) that could be repurposed for part of this if helpful.
You'll be happy to know I've been reading the mail and I know to first listen and test so we Tx with minimum power. But as a satellite newby, I'm sure I'll need abundant guidance when we get QRV.
Any detailed system diagrams (could be off-list directly to me) showing how you built and configured such a remote station satellite system would be greatly appreciated.
Thank you
very 73,
Dave KJ9I KD9BOG (at work)
Sent via [email protected]. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: https://www.amsat.org/mailman/listinfo/amsat-bb
Study SatNOGS. I haven't looked for a while and it was mostly receive-only when I did, but they have hardware and software to make a good start. Plus, any remote station should participate in the SatNOGS network when otherwise not in use.
On Fri, Jul 17, 2020 at 12:09 PM David J. Schmocker via AMSAT-BB < [email protected]> wrote:
Hello,
Does anyone have a detailed system diagram (or interconnect drawing) showing how they have remoted a satellite station please? Specifically which parts of the system require IP-addressable power on/off, etc.
I am in the process of constructing a new satellite station for U/V linear use at Milwaukee Area Technical College (where I teach). Our Data Communication and Networking class introduces satellite technology which I plan to demonstrate live.
Because the hours of access to the building are limited, and because we teach Data Communication and Networking from two campuses (but have Satellite station at only one), remoting this station would be desirable.
I have an APC IP-addressable power strip (117vac) and some power relays if we need 220vac switched, an IC-9700, two high-power switchable LNAs (2m and 70cm), antennas (20 element RHCP for 2m and 16 Turn G3RUH Helix for 70cm), and a Yaesu 5500 rotor with Green Heron Az/El controller (I'll bring Heliax from home to get to the rooftop). Hopefully our city campus location is not overly noisy. I plan to construct the HEO-ready station as soon as I can be back on campus to do this.
One specific area of concern: how to pass audio over internet. I've heard Skype and some other vehicles have problematic latency but I have yet to remote any station to use 'near real-time audio' for CW or SSB QSOs so I lack experience with this. The satellite computer (controlling antennas and managing Doppler) is a Mac mini running MacLoggerDX and MacDoppler software.
If helpful, I have two surplus new Raspberry Pi 3s (new and unused) that could be repurposed for part of this if helpful.
You'll be happy to know I've been reading the mail and I know to first listen and test so we Tx with minimum power. But as a satellite newby, I'm sure I'll need abundant guidance when we get QRV.
Any detailed system diagrams (could be off-list directly to me) showing how you built and configured such a remote station satellite system would be greatly appreciated.
Thank you
very 73,
Dave KJ9I KD9BOG (at work)
Sent via [email protected]. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: https://www.amsat.org/mailman/listinfo/amsat-bb
My 'Quick' answers (TL;DR version below): 1. Think about VPNs for secure access and 'freedom' to connect to various devices in various ways all through an encrypted tunnel. By freedom I mean avoiding weird port forwarding rules and such in the firewalls. We use OpenVPN heavily in the VTGS, with our firewalls running the server side (look into pfSense for an awesome firewall solution with native OpenVPN support). 2. Numato Relays for low voltage control ((https://numato.com/product/8-channel-ethernet-relay-module). Both a webserver interface and a low level telnet interface for control through external programs. We use it to control things like LNA power, Polarization switch control, radio power (SDRs for us), tracking control box power, etc. (We also use a IP controllable AC strip, but mainly for the 'nuke it from orbit' solution if we need to power cycle something). For anything high current the numato relays also offer extra digital I/O ports on the same relay boards via standard 0.1 inch headers that can be used to control things like high current FET switches (W6PQL has a good example: https://www.w6pql.com/high_current_solid-state_dc_switch.htm). This might be handy for things like controlling rig power if it sucks more current during TX than the numato relays can handle. 3. 'rigctl' and 'rotctl' for controlling radios and rotators (respectively). Lots of support out there. As mentioned, SatNOGS is a good resource for this. Both can run on an RPi with USB style interfaces to the Rig / Rotator control box. We use IP controllable systems at VT (mostly Spid MD-01s) which can be controlled by rotctl or via custom software. 4. We used to use 'ffmpeg' as an audio streaming server (winner of the 'lowest latency' contest when we were searching for this kind of solution, compared to things like 'icecast'). On the 'receive side' we just used VLC media player. A low cost USB audio card + an RPi (I think the RPi jack was only audio out, no mic in, but I could be wrong about that) could work for the audio connection to a HW rig. PulseAudio has a great interface for setting up the audio routing and loopbacks and such if you need them (it's a bit like a swiss army knife for this sort of thing). There are also a few other low level command line utilities, and some cripting might make it easier to set up a two way connection. There are also some remote desktop utilities that include audio features. I think the one we used for a while was 'NoMachine' but we switched to 'X2Go' so that we could play games with GPU accelerated FFTs and OpenGL rendering (for gr-fosphor spectrum displays for those curious) that didn't work over other remote desktop solutions. There are probably a lot newer solutions for this now (its been a few years since we've messed with audio streaming). 5. Almost all of the VTGS code is on Github: https://github.com/vt-gs. There might be some nuggets buried in there useful for you (maybe the relay control code and/or the Spid control code if you want to do it with python, Eagle/Kicad boards for PA control and the companion network control software, etc.). Fair warning, its constantly changing and is pretty specific to our system, but still you might find something useful there.
TL;DR version: Most of our setup at the VT ground station is remote over IP connections (even our VHF/UHF PA system). We use SDRs + GNU Radio, so its also a little different compared to folks using HW radios. Its pretty non-standard and constantly changing, and I don't have an 'easy' diagram to share (more like a few hundred slides of the evolution over the years). At a super high level, we run everything on a LAN at the tracking station and then remotely connect to it over VPN connections. From there the remote system can then access individual servers/devices over SSH, through low level message passing protocols (RMQ and/or ZeroMQ),and even lower level TCP/UDP sockets, etc. etc. Using the VPN is 1) secure and 2) avoids crazy weird firewall rules for port forwarding.
For the remote power control, we also use a remote (IP) controllable AC strip. I use this for the 'high level' remote power control and typically a human is accessing it and controlling things through the built in webserver. For 'lower level' power control (typically DC) I use IP controllable relays from Numato Relay (https://numato.com/product/8-channel-ethernet-relay-module). They have a nifty built in webserver as well as an interface over telnet (a little archaic, but easily interfaced with using Python modules) for control from external programs. We mostly only run low voltage/low current devices through these relays, like LNAs, Polarization control, USRP power (the SDRs we use, 6VDC), the 15VDC supply to the MD01 so we can turn the tracker off (NOT the 24V motor supply!), etc. etc. We don't do things like TX/RX sequencing with this, mainly due to latency concerns over a network, and that is handled by the transmitter 'deck' that has interfaces into things like the LNA PTT lines.
For tracking control, we also use IP addressable systems. In our case its mostly Spid MD-01s with the Ethernet module add on. We also use serial to IP converters and a 'faux-yaesu' interface (basically an Arduino and some circuitry that emulates the yaesu interface box) for controlling some yaesu rotators. If I could start over, I would have thought more about using things like 'rotctl' and 'rigctl'. Problem with that for us at VT is we work with something like 10 different manufacturers' versions of 'tracking pedestals' that are never likely to be supported by rotctl because most aren't for Amateur Radio (like FLIR and MOOG systems), but we are working towards a unified 'tracking daemon' that has to account for all flavors of PTU. As mentioned, SatNOGS has good stuff on this front.
For the specific issue of audio streaming, I have only come up with two 'workable' solutions over the years, though it has been a while. The main issue was latency. A lot of the solutions at the time were fine for like podcast streaming where some delay was no big deal (like 'icecast'), but SUPER frustrating if trying to tune by ear for a linear bird on sideband (you'd tune....then like 30 seconds later you'd hear the audio change). We finally settled on 'ffmpeg' for the audio streaming 'server'. For the receive side I just used VLC media player. I think ffmpeg has been absorbed into other open source audio projects, but I can't remember which one off the top of my head. The other solution was actually a remote desktop solution called 'NoMachine'. It was a little cludgy at the time, but it was remote desktop combined with audio support and the audio latency was imperceptible. All of this was 5+ years ago, and as already mentioned, there are probably a lot better solutions out there. In all cases I'd recommend '
Finally, almost all our code is on Github (and eventually our documentation will be as well). Feel free to take a look, but fair warning, its constantly changing and pretty specific to our system. There might be nuggets in there that are useful to you though (like the Numato Relay control stuff if you go that route and you want to control them through Python, or python code for controlling MD-01s/Spid rotators): https://github.com/vt-gs
Good Luck! Feel free to reach out (on or off list) if you have more questions about any of the above!
-Zach, KJ4QLP
P.S. I just realized the TL;DR version is about as long as the 'quick' version.....sorry.
Sadly Satnogs isn't suitable for the job being it's for telemetry only, also I don't believe it forwards telemetry to AMSAT-NA or AMSAT-UK so radio amateurs would be better off with a different solution.
Sadly ICOMs remote software isn't that great for satellite work, I'd also love to see a better remote solution even if it's just for working passes in a different room in the house.
Peter, 2M0SQL
On Fri, 17 Jul 2020, 20:56 Bruce Perens via AMSAT-BB, [email protected] wrote:
Study SatNOGS. I haven't looked for a while and it was mostly receive-only when I did, but they have hardware and software to make a good start. Plus, any remote station should participate in the SatNOGS network when otherwise not in use.
On Fri, Jul 17, 2020 at 12:09 PM David J. Schmocker via AMSAT-BB < [email protected]> wrote:
Hello,
Does anyone have a detailed system diagram (or interconnect drawing) showing how they have remoted a satellite station please? Specifically which parts of the system require IP-addressable power on/off, etc.
I am in the process of constructing a new satellite station for U/V linear use at Milwaukee Area Technical College (where I teach). Our Data Communication and Networking class introduces satellite technology which I plan to demonstrate live.
Because the hours of access to the building are limited, and because we teach Data Communication and Networking from two campuses (but have Satellite station at only one), remoting this station would be desirable.
I have an APC IP-addressable power strip (117vac) and some power relays if we need 220vac switched, an IC-9700, two high-power switchable LNAs (2m and 70cm), antennas (20 element RHCP for 2m and 16 Turn G3RUH Helix for 70cm), and a Yaesu 5500 rotor with Green Heron Az/El controller (I'll bring Heliax from home to get to the rooftop). Hopefully our city campus location is not overly noisy. I plan to construct the HEO-ready station as soon as I can be back on campus to do this.
One specific area of concern: how to pass audio over internet. I've heard Skype and some other vehicles have problematic latency but I have yet to remote any station to use 'near real-time audio' for CW or SSB QSOs so I lack experience with this. The satellite computer (controlling antennas and managing Doppler) is a Mac mini running MacLoggerDX and MacDoppler software.
If helpful, I have two surplus new Raspberry Pi 3s (new and unused) that could be repurposed for part of this if helpful.
You'll be happy to know I've been reading the mail and I know to first listen and test so we Tx with minimum power. But as a satellite newby, I'm sure I'll need abundant guidance when we get QRV.
Any detailed system diagrams (could be off-list directly to me) showing how you built and configured such a remote station satellite system would be greatly appreciated.
Thank you
very 73,
Dave KJ9I KD9BOG (at work)
Sent via [email protected]. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership.
Opinions
expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Not an AMSAT-NA member? Join now to support the amateur satellite
program!
Subscription settings: https://www.amsat.org/mailman/listinfo/amsat-bb
-- Bruce Perens - CEO at stealth startup. I'll tell you what it is eventually :-) _______________________________________________ Sent via [email protected]. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: https://www.amsat.org/mailman/listinfo/amsat-bb
On Fri, Jul 17, 2020 at 1:53 PM Peter Goodhall (2M0SQL) < [email protected]> wrote:
Sadly Satnogs isn't suitable for the job being it's for telemetry only, amateurs would be better off with a different solution.
You can download every bit of telemetry AND the un-demodulated audio. If AMSAT isn't getting it, they aren't trying. Most of the ground stations are identified in the SatNOGS system by their Amateur callsigns. Look at https://network.satnogs.org/stations/ This is definitely the largest Amateur ground-station network. And since it is Open Source, if it does not do something you wish to do, you can extend it.
Thanks
Bruce
While I get your pro-open source, and I've plenty code-shared that is, my point was really that its not suited for what dave wants todo out the box, unless he wanted to build in bidirectional audio streaming and other functions that would be needed for using it on linear and FM transponders.
I totally get its open source and a large network, I do have some personal concerns regarding the system, but that really isn't the topic of this email thread.
Peter.
On Fri, 17 Jul 2020 at 22:39, Bruce Perens [email protected] wrote:
On Fri, Jul 17, 2020 at 1:53 PM Peter Goodhall (2M0SQL) [email protected] wrote:
Sadly Satnogs isn't suitable for the job being it's for telemetry only, amateurs would be better off with a different solution.
You can download every bit of telemetry AND the un-demodulated audio. If AMSAT isn't getting it, they aren't trying. Most of the ground stations are identified in the SatNOGS system by their Amateur callsigns. Look at https://network.satnogs.org/stations/ This is definitely the largest Amateur ground-station network. And since it is Open Source, if it does not do something you wish to do, you can extend it.
Thanks Bruce
Hi Dave,
We have a similar situation at the University of Arizona: we are also moving towards remote control. Even before the campus virus shutdown elevated the priority of remote operation, I concluded that a directional satellite system is not optimal for K7UAZ -- given the consistent scarcity of volunteer labor available to maintain a directional antenna system. This fall K7UAZ will be migrating to a set of omni, circularly polarized antennas with preamplifiers. Not that controlling az/el rotors is overly complicated, but this change does help make remote operation even easier.
Regards,
Curt / K7ZOO K7UAZ Station Manager
On Fri, Jul 17, 2020 at 12:09 PM David J. Schmocker via AMSAT-BB < [email protected]> wrote:
Hello,
Does anyone have a detailed system diagram (or interconnect drawing) showing how they have remoted a satellite station please? Specifically which parts of the system require IP-addressable power on/off, etc.
I am in the process of constructing a new satellite station for U/V linear use at Milwaukee Area Technical College (where I teach). Our Data Communication and Networking class introduces satellite technology which I plan to demonstrate live.
Because the hours of access to the building are limited, and because we teach Data Communication and Networking from two campuses (but have Satellite station at only one), remoting this station would be desirable.
I have an APC IP-addressable power strip (117vac) and some power relays if we need 220vac switched, an IC-9700, two high-power switchable LNAs (2m and 70cm), antennas (20 element RHCP for 2m and 16 Turn G3RUH Helix for 70cm), and a Yaesu 5500 rotor with Green Heron Az/El controller (I'll bring Heliax from home to get to the rooftop). Hopefully our city campus location is not overly noisy. I plan to construct the HEO-ready station as soon as I can be back on campus to do this.
One specific area of concern: how to pass audio over internet. I've heard Skype and some other vehicles have problematic latency but I have yet to remote any station to use 'near real-time audio' for CW or SSB QSOs so I lack experience with this. The satellite computer (controlling antennas and managing Doppler) is a Mac mini running MacLoggerDX and MacDoppler software.
If helpful, I have two surplus new Raspberry Pi 3s (new and unused) that could be repurposed for part of this if helpful.
You'll be happy to know I've been reading the mail and I know to first listen and test so we Tx with minimum power. But as a satellite newby, I'm sure I'll need abundant guidance when we get QRV.
Any detailed system diagrams (could be off-list directly to me) showing how you built and configured such a remote station satellite system would be greatly appreciated.
Thank you
very 73,
Dave KJ9I KD9BOG (at work)
Sent via [email protected]. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: https://www.amsat.org/mailman/listinfo/amsat-bb
I echo your approach, Curt.
I'm primarily a terrestrial narrowband operator. No beams. 8x halos on 2 meters. 4x halos on 6 meters. No rotators, no complexity. However...I live in a rural area with very little band noise.
My suburban brothers need beams to null out broadband noise sources, birdies, etc.
Ev, W2EV
On Friday, July 17, 2020, 6:57:58 PM EDT, Curt Laumann via AMSAT-BB [email protected] wrote:
Hi Dave,
We have a similar situation at the University of Arizona: we are also moving towards remote control. Even before the campus virus shutdown elevated the priority of remote operation, I concluded that a directional satellite system is not optimal for K7UAZ -- given the consistent scarcity of volunteer labor available to maintain a directional antenna system. This fall K7UAZ will be migrating to a set of omni, circularly polarized antennas with preamplifiers. Not that controlling az/el rotors is overly complicated, but this change does help make remote operation even easier.
Regards,
Curt / K7ZOO K7UAZ Station Manager
On Fri, Jul 17, 2020 at 12:09 PM David J. Schmocker via AMSAT-BB < [email protected]> wrote:
Hello,
Does anyone have a detailed system diagram (or interconnect drawing) showing how they have remoted a satellite station please? Specifically which parts of the system require IP-addressable power on/off, etc.
I am in the process of constructing a new satellite station for U/V linear use at Milwaukee Area Technical College (where I teach). Our Data Communication and Networking class introduces satellite technology which I plan to demonstrate live.
Because the hours of access to the building are limited, and because we teach Data Communication and Networking from two campuses (but have Satellite station at only one), remoting this station would be desirable.
I have an APC IP-addressable power strip (117vac) and some power relays if we need 220vac switched, an IC-9700, two high-power switchable LNAs (2m and 70cm), antennas (20 element RHCP for 2m and 16 Turn G3RUH Helix for 70cm), and a Yaesu 5500 rotor with Green Heron Az/El controller (I'll bring Heliax from home to get to the rooftop). Hopefully our city campus location is not overly noisy. I plan to construct the HEO-ready station as soon as I can be back on campus to do this.
One specific area of concern: how to pass audio over internet. I've heard Skype and some other vehicles have problematic latency but I have yet to remote any station to use 'near real-time audio' for CW or SSB QSOs so I lack experience with this. The satellite computer (controlling antennas and managing Doppler) is a Mac mini running MacLoggerDX and MacDoppler software.
If helpful, I have two surplus new Raspberry Pi 3s (new and unused) that could be repurposed for part of this if helpful.
You'll be happy to know I've been reading the mail and I know to first listen and test so we Tx with minimum power. But as a satellite newby, I'm sure I'll need abundant guidance when we get QRV.
Any detailed system diagrams (could be off-list directly to me) showing how you built and configured such a remote station satellite system would be greatly appreciated.
Thank you
very 73,
Dave KJ9I KD9BOG (at work)
Sent via [email protected]. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: https://www.amsat.org/mailman/listinfo/amsat-bb
_______________________________________________ Sent via [email protected]. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: https://www.amsat.org/mailman/listinfo/amsat-bb
On Fri, Jul 17, 2020 at 4:49 PM Peter Goodhall (2M0SQL) via AMSAT-BB < [email protected]> wrote:
Sadly Satnogs isn't suitable for the job being it's for telemetry only, also I don't believe it forwards telemetry to AMSAT-NA or AMSAT-UK so radio amateurs would be better off with a different solution.
Friends,
Satnogs is an incredible and incredibly underutilized resource for AMSAT. It doesn't automatically forward telemetry, but you can go to the appropriate Satnogs site, filter on the satellite you want and download the audio recording of the pass (or passes) that you want. Then lather-rinse-repeat for as many passes as you want. I would never have been able to create as many recordings myself at my home QTH as I can get by downloading them from Satnogs. You can get recordings from anywhere on the planet where there was a ground station that made a recording. (If you're fully onboard you could even schedule somebody else to make a recording for you on a particular date/time in the future. Think about that.)
A while back I downloaded several months worth of old Falconsat-3 audio recordings so that I could run the recordings through my own 9600 DSP demodulator and see if I could recover any data from the recordings, and improve the demodulator as much as possible. I wrote some scripts to convert and filter each ogg recording and then run them all through my demodulator. This whole scheme actually worked too well, as I now have more than enough recordings to keep me busy for a long long time because it takes my old computer DAYS to process through ALL of those recordings [footnote 1] and to decide if the latest tweak was an improvement or not. (Think about your last visit to the eye doctor where you watch the eye chart through the phoropter [footnote 2] while the eye doctor makes adjustments to the lenses and asks you if this one is now "Better? Or worse?" -- well, this is almost the same thing but it takes three days to find out the answer for each change. But, I digress...)
So far, of the recordings that I downloaded, the most extreme pass is
https://network.satnogs.org/observations/180707/
the audio recording is eighteen megabytes and is online at
https://ia902808.us.archive.org/7/items/satnogs-observation-180707/satnogs_1...
The satnogs webpage for this pass shows 644 valid 9600 baud AX.25 packets this recording so you know it is a good pass with plenty of frames in it. By throwing everything I can think of at this recording, I can now get over 1000 good frames out of it. Oh, and, hey, if anybody else tries this recording against their own demodulator, then whatever results you get please send them to me so I can look for any valid frames I am missing. And the advantage of the satnogs recordings is that you can keep tweaking your software iteratively by running the recordings against the "new" demodulator again, and again, and again, and compare the results. You could never achieve this or iterate this many times with live satellite passes.
73, Douglas KA2UPW/5 [1] If the whole process doesn't get interrupted... Actually, this says more about my old slow computer than it says about the speed of the demodulator. [2] If you get your eyes checked then you know this device. You just might not know the name for it. Consider "phoropter" to be today's new word-of-the-day. See https://en.wikipedia.org/wiki/Phoropter
Sorry, another TL;DR...but hey its Friday night, what else have I got to do.....The one sentence version of the below is 'it would be cool if the SatNOGS network could record raw IQ, and then that could all be brought together at a central processing location to do some really cool stuff.'.....here comes the longer version........
I'm also generally 'pro-SatNOGS' (they started right about when I published my Master's thesis about GS networks! I wish they had been there sooner or I had known about them earlier....would have been a great addition to the work). I was furiously writing to finish my thesis while they were out winning the Hack-a-day prize. I'll admit I was jealous at first......but I quickly got over my "hate 'em cause I ain't 'em" problem because what they are up to is just too cool (and every time I talk with someone from their team face to face, they have all been super nice enthusiastic folks!). I'll freely admit I haven't had time to participate in the network myself or with VTGS systems, though that is mainly due to us not being 'ready' in terms of things like system automation (just not enough hours in a given day....this whole sleep thing is a real downer). That said, the VT Amateur Radio club, K4KDJ, a separate entity from our ground station (though with overlapping people, I used to be an officer in K4KDJ when I was a student) is considering setting a node up.
Here's one thought (laid out in a list) for the SatNOGS folks (This is a total 'feature request' of which I'm sure they get a lot......this is not a poke against them, more 'hey here's a fun idea' type thing. If I had more time I'd actually try to get more involved on this front). What follows is a total 'thinking out loud', not fully thought through, brain dump of some ideas I've been kicking around for a couple years now (I guess since at least 2013/2014.....but the existence of the SatNOGS network makes it seem more feasible now), so feel free to skip. I know others have had similar thoughts, so I also no way claim this as solely my own idea.....(AMSAT in general and Douglas, KA2UPW and Joe, KM1P specifically were in the acknowledgments section of the thesis specifically because of some conversations in this arena and for their super positive encouragement to a newby, Bob McGwier, N4HY was my committee chair....). I'm sure there are others I've talked about this with (maybe also Chris Thompson), these ideas have been 'marinating' over the last few years and I can't remember every conversation I've had........
1. One thing I think would be REALLY fun to explore is raw IQ captures shared over their network. The recorded audio is great, and I'm 100% behind what Douglas mentioned. However, if the recording point could be moved 'upstream' a bit to the raw IQ samples, some really interesting applications could be explored. Cross correlating the IQ streams to determine things like time difference of arrival and frequency difference of arrival can lead to things like orbit determination...something that might be of interest for folks burning Ion thrusters (or solar sails) and don't want to wait for TLE updates.....I'm thinking for future HEO efforts on this front, but the general theory/application could be applied across the various orbital regimes from LEO out to GEO and beyond. The familiar 'Fox Tail' on the Fox bird might make for a good 'target' for this type of thing.
2. One requirement for this to work properly is good timing references at the ground stations though (RTL SDR and FCDPP oscillators are prob not good enough), GPSDOs and other oscillators would be desirable (and are not hard to come by these days...QEX has some great articles, ebay has surplus, etc.). If reference signals can be sent over a transponder (PN sequences to make the correlations that much simpler to identify is what I'm thinking here) with a known group delay, with precise freq/time control, then there is potential to explore applications and resolving timing ambiguities between station pairs, even if they don't have 'great' oscillators (room to experiment!). Even with good timing references, you then have to make sure that's properly integrated with the SDR software actually executing the recordings (see #5 below for potential solution to part of that problem). I'm sure Tom Clark, K3IO with his long history of VLBI work might have some advice on this front (along with others). For those involved with ADSB collection over the Flightaware network (similar to SatNOGS....but different and for collecting transmissions from general and commercial aviation aircraft), they do something similar as part of their multilateration processing (using the 'known location' message bursts to resolve timing residuals between station pairs, and then using the residuals to correct the timing offsets when geolocating the messages/emitters that don't have position info in them....they call it 'MLAT'). Big difference is they don't send IQ, just 'precise' timestamps of the received messages......but I bring it up because all their Python code is open source and on github for the multilateration process....and might be a useful starting point.
3. Raw IQ recordings come with an obvious tough requirement....storage capacity and network bandwidth. IQ sample captures will be MUCH larger than the audio recording of the same pass. Perhaps some type of prototype system could be set up though to 'get started' that doesn't break the bank where certain systems (maybe volunteer stations that have the oscillator/timing features mentioned) are tasked for specific experiments on this front (not normal ops that might generate way too much data).
4. Then there is the central storage/computing resources needed to run the correlations. With modern compute resources (including cloud services), the cost of that effort doesn't necessarily have to break the bank (especially if a willing university....with big honkin GPUs in server stacks that are currently underutilized, with a research faculty member interested in GS networks and novel applications, who is also a ham, and a lifetime member of AMSAT......... are willing to free up some system time ;-) hi hi, at least maybe for some prototyping on this front).
5. then there is the appropriate tagging of metadata necessary to take full advantage of the timing information. For this I would recommend the Signal Metadata Format (aka SigMF) (https://github.com/gnuradio/SigMF). While it grew out of GNU Radio (and there are OOTMs for GNU Radio support) it is not specifically tied to the GNU Radio project and can be used for anything (literally any time series of data, even for stuff that is 'not radio' if desired). I use it extensively for signal collection work and keeping track of the myriad bits of info that needs to be tracked along with the raw IQ (the metadata is in JSON format, super easy to use). Their 'extensions' framework is ingenious, and allows folks to 'extend' the specification for custom metadata formats not already covered in the spec.
6. Finally, if all of the above can be accomplished, then there is another application that could be explored beyond the satellite tracking, signal combining. Imagine if there were packets transmitted that no single ground station could decode due to lack of sufficient SNR.....but then all the IQ streams are brought together, the correlations are performed and the streams are time aligned, and summed (perhaps with weighting)........the random nature of the noise drives its average lower, while the not so random nature of the signal drives its average higher (massive oversimplification of the idea).....leading to higher SNR....leading to potentially high enough SNR to demodulate the otherwise 'lost' packets. There are lots of techniques out there for this sort of thing in the DSP world, right now I'm thinking 'maximal ratio signal combining' that applies weights to the summing process based on the measured SNR at each station.
7. Finally, Finally. Imagine the ground stations involved were using omni antennas. Also imagine multiple birds were overhead and in the recording bandwidth. Theres nothing stopping you from going back in time, doing a bit of preprocessing (maybe coarse tuning for the target bird using TLEs, filtering for the specific signal of interest, etc.) and then re-executing the above process.
All of the above is pretty complicated to do, and I didn't cover every little technical detail or 'gotcha' type problem......but I think it could be a lot of fun to explore as a team.....if there is enough interest, perhaps some collaboration on this front and ideas for proposals could be put together to explore more.....I'm also betting the 'super-Elmers' out there (like the Bobs, Toms, and Phils) could figure out the math for this sort of thing in their sleep.
If you're reading this line....then THANKS! For sticking with the thinking out loud brain dump on this topic......as always, feedback is welcome (on or off list).
-Zach, KJ4QLP
Also, as a quick afterthought / alternate idea....(and again, I'm not 100% 'up' on the specifics of interfacing with SatNOGS, other than the SiDS protocol details).....
I wonder if an autmated 'scraper' of some sort could be set up for the Fox / HuskySat-1 / GOLF spacecraft specifically for AMSAT-NA (or other AMSATs of the world).
Simple idea is pull the recordings from SatNOGS....run them through the decoders (maybe FoxTLM, maybe something more custom like what Douglas mentioned he was working on, maybe a variant of that like a GNU Radio version, maybe all three) and then inject the decoded data into the AMSAT TLM network. I feel like some kind of batch process that executes this say every 24 hours, or once a week, or whatever makes sense could be set up to automate the process........
As always there is a lot of 'devil in the detail' there that I didn't mention, and like many things it might be simple to propose, but non-trivial to actually execute (especially on volunteer time).......
Has anyone thought along these lines, or gotten into anything like this? Again simple summary being 'pull from SatNOGS, decode, inject to AMSAT' and do that automatically. If such a system existed....what would the appropriate station ID be (the original station ID? Maybe one station ID that identifies the source of the data as a 'scraper' and then a website keeping track of the stats for the scraper independently that maps back to the original station?....something like 'SatNOGS-Scraper-1' with the station details field populated with a link to the scraper stats page?.....I guess that might get weird if the lat/lon of the scraper is constantly changing to match the original station's position.....also how to keep accurate track of timestamps?). Would prototyping something like this cause heartburn for the TLM database managers (I have visions of half built 'things' flooding the AMSAT TLM server and causing all kinds of problems). Then again, I believe the fox server side is also on github.....so maybe a separate prototyping instance could be set up?
Just another Friday night thought......
-Zach, KJ4QLP
participants (10)
-
Bruce Perens -
Curt Laumann -
David J. Schmocker -
Douglas Quagliana -
Ev Tupis -
JoAnne K9JKM -
Leffke, Zachary -
lu9cbl＠gmail.com -
Paul Stoetzer -
Peter Goodhall (2M0SQL)