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 AMSAT-BB@amsat.org. 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.

On Fri, Jul 17, 2020 at 1:53 PM Peter Goodhall (2M0SQL) < peter@magicbug.co.uk> 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

On Fri, Jul 17, 2020 at 4:49 PM Peter Goodhall (2M0SQL) via AMSAT-BB < amsat-bb@amsat.org> 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

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

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 amsat-bb@amsat.org 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 < amsat-bb@amsat.org> 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 AMSAT-BB@amsat.org. 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 AMSAT-BB@amsat.org. 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