(I blame Alun for the cheesy Queso joke.)
The first successful satellite QSOs made with SOAR prototype hardware happened this morning on the ~17:30 UTC pass of AO-91 over South Western US. Patrick Stoddard WD9EWK worked W7JSD in southern Arizona, N6UTC in Long Beach, California, and XE2BHL in Tijuana.
I haven’t implemented pass audio recording in SOAR yet (it will be a launch feature), so he used his own recorder to record the pass audio:
This was his setup:
Note that he uses an Elk antenna with a single feed point, so he’s using an external Diplexer; I will hopefully have a simple diplexer available as an add-on for SOAR at launch. I have the parts and boards, but haven’t assembled and tested one yet.
He’s also using an active GPS “puck” antenna; I’m working on an active “rubber duck” style GPS antenna that will come with SOAR (included, it won’t cost extra). I’m working on a blog post talking about that now.
But otherwise, he’s using SOAR as designed: External PTT, headset, and power. GPS antenna will get better, and feed line to your antenna.
Analysis Of The Pass:
Transmit Power:
This pass really showed how SOAR is only a 2W radio. When he wasn’t fighting with anyone else for the uplink, Patrick made QSO’s without any problems. But other operators with more power were able to capture the uplink from him. This is a known issue with the 2W design. I have a back-log item to design a dual-band amplifier that will integrate cleanly with SOAR; I’ve made sure to build SOAR with the signaling needed to make this easy. But this won’t be available at launch. In the mean time, if you feel the need, you can add your own mono- or dual-band amplifier to your SOAR setup.
Receiver Sensitivity:
The receiver seemed really good. (How very scientific, Smitty!) The receive signal did not noticeably desense while transmitting. When AO-91 was close to the horizon, signals were pretty weak, but the receiver was full quieting when the satellite was in clear skies.
Automation:
Patrick made sure to update the TLE data on both SOAR and AmsatDroid on his phone right before the pass, and the sky-tracks matched nearly perfectly:
In the SOAR image, you can also see the Doppler shift calculations. The Rx center frequency is 145.9600MHz, with a Doppler correction of 0.0030MHz (aka 3kHz), therefore the actual Rx frequency is 145.9570. Right now, SOAR is only updating the frequency in 1kHz steps, but that may be configurable. Unfortunately, the receiver has a very brief *blip!* of a closed-then-opened-again squelch when the frequency changes, so I don’t want it changing too often. 1kHz seems like a good compromise between staying close to the actual frequency, and not inserting too many *blips!* in your receive audio. The transmitter can’t update at all while transmitting, but it will update immediately upon un-keying. Since transmissions are so short, this isn’t at all a problem.
The phone and the voice recorder were redundant, correct (since SOAR provides both of those functionalities)? And the external GPS antenna shouldn’t be needed outdoors?
First off: Congrats on being the first commenter on my blog. 🙂
SOAR _WILL_ record the pass audio, but I haven’t implemented that yet (as of 2022-07-05). So Patrick was using his own voice recorder in the mean time. The joys of playing with prototype hardware.
I consider audio recording a launch feature of SOAR; it will be implemented before SOAR is released to the public (though it may or may not be implemented before the Early Adopter Program (EAP) users get theirs. If not, I will implement it pretty early on the EAP. Bug fixing will probably come first.)
The sky chart, azimuth and elevation calculations and display plus Doppler calculation and automatic adjustment, are already implemented in SOAR. So, yes, that was redundant with his phone. However, since he’s an early tester, he was just verifying that SOAR’s calculations agreed with AmsatDroid’s calculations. *whew!* They agreed!