<html><head></head><body><div class="ydpe83e1409yahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;"><div></div>
<div>High Gain antennas make for some pretty challenging point problems.</div><div><br></div><div>Yes, lots of servos and a computer can do it, but you just killed portable and</div><div>remote operators.</div><div><br></div><div>I just did some 11 element Yagi's for 1269 MHz and already getting</div><div>complaints that they are too narrow to use for some operators.</div><div><br></div><div>Holding a 3 degree beamwidth on a quickly moving object is NOT simple.</div><div><br></div><div>Kent WA5VJB<br></div><div><br></div>
</div><div id="ydp4f0479f4yahoo_quoted_2619773580" class="ydp4f0479f4yahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div>
On Saturday, March 9, 2019, 2:30:39 PM CST, Paul Williamson via Ground-Station <ground-station@lists.openresearch.institute> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div dir="ltr">Wally raises some interesting points about the choice of channel<br></div><div dir="ltr">bandwidths, which I treated as a given in the testbed proposal. I<br></div><div dir="ltr">mentioned them under the heading System Architecture Review because<br></div><div dir="ltr">these bandwidths have been part of the project baseline for a long<br></div><div dir="ltr">time now. I didn't really intend to bring them back up for debate, but<br></div><div dir="ltr">since we now have a little bit of real-world experience with QO-100<br></div><div dir="ltr">it's a good idea to sanity-check our baseline.<br></div><div dir="ltr"><br></div><div dir="ltr">The choice to reach for wider bandwidths is a conscious one. In a<br></div><div dir="ltr">microwave system, high gain antennas are within reach. In a system<br></div><div dir="ltr">with high gain antennas, it's perfectly OK to use the whole band of<br></div><div dir="ltr">allocated spectrum. In amateur radio we're used to sharing a band by<br></div><div dir="ltr">slicing it up in frequency, but with high gain antennas we can re-use<br></div><div dir="ltr">the same frequencies on many different links by simply pointing our<br></div><div dir="ltr">antennas in different directions. For the foreseeable future, we're<br></div><div dir="ltr">unlikely to have so many amateur payloads in geo orbits that we need<br></div><div dir="ltr">to worry about crowding. So if spectrum scarcity is not the issue,<br></div><div dir="ltr">that leaves the question of link budget: can we muster enough signal<br></div><div dir="ltr">to make these bandwidths work?<br></div><div dir="ltr"><br></div><div dir="ltr">We have link budget calculations (see the repo) that show that with a<br></div><div dir="ltr">few watts and a 30-ish inch dish antenna, the 100 kHz uplink closes<br></div><div dir="ltr">with a bit of margin. We already need a dish of about that size for<br></div><div dir="ltr">the downlink, so why not also use it for the uplink? That's why P4G<br></div><div dir="ltr">antenna work has concentrated on dual-band feeds for the dish, rather<br></div><div dir="ltr">than separate transmit antennas. I don't have these link budget<br></div><div dir="ltr">numbers at my fingertips, and I haven't tried to compare them to<br></div><div dir="ltr">QO-100 measurements, so maybe these need to be revisited.<br></div><div dir="ltr"><br></div><div dir="ltr">I think the important point here is that wider bandwidths (and data<br></div><div dir="ltr">rates) are much more interesting and are a big part of why it's<br></div><div dir="ltr">worthwhile to push up into microwaves and modern technology. Voice is<br></div><div dir="ltr">just the least-common-denominator application, but even voice can<br></div><div dir="ltr">benefit from somewhat higher data rates, by stepping up from so-called<br></div><div dir="ltr">"communications quality" codecs to ones that actually sound good and<br></div><div dir="ltr">are not fatiguing to listen to. For data applications, it's even more<br></div><div dir="ltr">clear that a higher data rate opens up whole new worlds of<br></div><div dir="ltr">possibility. Those of us who remember upgrading our telephone modems<br></div><div dir="ltr">from 300 baud incrementally to 56kbps will recall that it was both a<br></div><div dir="ltr">miraculous improvement, and also still too slow. The 100 kHz uplink<br></div><div dir="ltr">channels are already a severe compromise in capability compared to<br></div><div dir="ltr">what we're used to with terrestrial broadband internet. I'm hoping we<br></div><div dir="ltr">can do at least that well.<br></div><div dir="ltr"><br></div><div dir="ltr">There are valid use cases for narrowband data, too. Probably a few of<br></div><div dir="ltr">the uplink channels should be subdivided into much narrower channels<br></div><div dir="ltr">and a low-data-rate service defined for less capable ground stations.<br></div><div dir="ltr">I'd consider that an optional add-on to the P4G system. I treated it<br></div><div dir="ltr">as out of scope for the purposes of the initial testbed proposal.<br></div><div dir="ltr"><br></div><div dir="ltr">The opportunities for waveform and modem testing over QO-100's<br></div><div dir="ltr">wideband transponder are truly exciting. I hope we will pursue that<br></div><div dir="ltr">and learn a lot. I certainly don't want to minimize the importance of<br></div><div dir="ltr">that work. I do see it as separate from the purpose of the testbed<br></div><div dir="ltr">system, which is more about investigating (and let's not forget<br></div><div dir="ltr">demonstrating) the overall system architecture than about decibels of<br></div><div dir="ltr">modem performance and link budgets.<br></div><div dir="ltr"><br></div><div dir="ltr">73 -Paul KB5MU<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">On Sat, Mar 9, 2019 at 8:06 AM Wally Ritchie via Ground-Station<br></div><div dir="ltr"><<a href="mailto:ground-station@lists.openresearch.institute" rel="nofollow" target="_blank">ground-station@lists.openresearch.institute</a>> wrote:<br></div><div dir="ltr">><br></div><div dir="ltr">> Great Start<br></div><div dir="ltr">><br></div><div dir="ltr">> Some Observations:<br></div><div dir="ltr">><br></div><div dir="ltr">> 1. 100kHz seems more like wideband than narrowband. 100kHz x 100 channels is 10MHz or half of the entire C band uplink spectrum allocation. This seem about 10X too wide. All things being equal, 100kHz channels require 10dB higher power than 10kHz channels. So, what you can do with 1W for 10kHz channels requires 10W for 100kHz.<br></div><div dir="ltr">> 2. Based on cursory listening to narrowband transponder on QO-100, people seem to be using on the order of 2W for 2.7kHz channels producing something like 15dB C/N with modest uplink antennae.<br></div><div dir="ltr">> 3. There is 70kHz of available bandwidth on QO-100 allocated to digital or mixed modes that could be used for testing narrowband digital waveforms up to 2.7kHz (the limit of the current operating rules). This could be used to test narrowband uplink waveforms in a real earth-space environment. Perhaps temporary permission can be gained for testing wider waveforms up to about 10k wide. Testing of wider waveforms can also be done in the RB-TV portion of the Wideband transponder. These channels are about 300kHz wide.<br></div><div dir="ltr">> 4. In any deployed satellite-based digital repeater, the two figures of merit for the RF will be the EIRP of the downlink transmitter, and the G/T of the uplink receiver. These will vary depending on what the host-satellite can make available for Power and Antennae. QO-100 wideband hemispheric beam output is likely as good as it will get (at least for hemi beams) since this is based on a commercial linear transponder output. Another bird might be 10dB below that or lower. Receiver G/T should comparable to QO-100. (Note, however, that pathloss is 7.5dB greater at C band vs. S band).<br></div><div dir="ltr">> 5. The 2Mbaud DVB-S2 (QPSK 2/3) downlink beacon of QO-100 provides an excellent baseline reference as do DVB-S (and S2) carriers in the remaining 5+ MHz bandwidth. Note that lots of real-world testing can be performed on this linear transponder using one or more DVB-S2 carriers originated on the ground. This can also be used for downlink receiver testing, in particular testing the ability of low-cost DVB-S2 receivers to handle 1Mbaud DBV-S2 in the presence of adjacent channels at similar power. (The typical consumer grade DVB-S2 has a minimum channel filter of 5 – 6 MHz).<br></div><div dir="ltr">><br></div><div dir="ltr">> Wally WU1Y<br></div><div dir="ltr">><br></div><div dir="ltr">><br></div><div dir="ltr">><br></div><div dir="ltr">> On Fri, Mar 8, 2019 at 6:59 PM Paul Williamson via Ground-Station <<a href="mailto:ground-station@lists.openresearch.institute" rel="nofollow" target="_blank">ground-station@lists.openresearch.institute</a>> wrote:<br></div><div dir="ltr">>><br></div><div dir="ltr">>> This has been posted to<br></div><div dir="ltr">>> <a href="https://github.com/phase4ground/documents/blob/master/Papers_Articles_Presentations/Papers/P4G%20Testbed%20Proposal.md" rel="nofollow" target="_blank">https://github.com/phase4ground/documents/blob/master/Papers_Articles_Presentations/Papers/P4G%20Testbed%20Proposal.md</a><br></div><div dir="ltr">>><br></div><div dir="ltr">>> As always, comments are welcome.<br></div><div dir="ltr">>><br></div><div dir="ltr">>><br></div><div dir="ltr">>><br></div><div dir="ltr">>> Phase 4 Ground System Testbed Prototyping Scheme Proposal<br></div><div dir="ltr">>> =========================================================<br></div><div dir="ltr">>> 2019-03-08 Paul Williamson, KB5MU, <a href="mailto:paul@mustbeart.com" rel="nofollow" target="_blank">paul@mustbeart.com</a><br></div><div dir="ltr">>><br></div><div dir="ltr">>> The Phase 4 Ground project has had a reasonably well-defined top-level<br></div><div dir="ltr">>> system architecture for several years now. So far, work has mainly<br></div><div dir="ltr">>> concentrated on some of the known "hard parts", such as DVB-S2/X<br></div><div dir="ltr">>> reception including the LDPC decoder, dual-band feeds, and 5 GHz power<br></div><div dir="ltr">>> amplifiers. Now it's time to build a testbed that approximates the<br></div><div dir="ltr">>> planned system architecture so that we can demonstrate and experiment<br></div><div dir="ltr">>> with some of the other interesting parts of the system.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> The specific goal of this document is to plan a set of incremental<br></div><div dir="ltr">>> steps that can take us smoothly from a fresh start to a testbed system<br></div><div dir="ltr">>> that implements and/or simulates all the main parts of a complete<br></div><div dir="ltr">>> Phase 4 Ground system. Each step should be "easy" in the sense that no<br></div><div dir="ltr">>> major new development work is required and it is reasonably clear what<br></div><div dir="ltr">>> needs to be done. This will mean that some interesting parts of the<br></div><div dir="ltr">>> system have to be dummied out or grossly simplified. For example, the<br></div><div dir="ltr">>> part of the payload that multiplexes the data from all the received<br></div><div dir="ltr">>> uplinks is complicated, but it can be temporarily replaced by a simple<br></div><div dir="ltr">>> round-robin multiplexer that doesn't support features like<br></div><div dir="ltr">>> authentication and authorization. It will also mean that some<br></div><div dir="ltr">>> performance parameters of the desired system will have to be<br></div><div dir="ltr">>> compromised. For example, we want to be able to receive enough<br></div><div dir="ltr">>> channels of uplink data to effectively utilize the entire 10 MHz of<br></div><div dir="ltr">>> the 5 GHz Amateur Satellite Service uplink band, but to accomplish<br></div><div dir="ltr">>> this may require a higher-performance (presumably FPGA-based) receiver<br></div><div dir="ltr">>> solution than we have ready at this time. However, a receiver<br></div><div dir="ltr">>> subsystem that can handle just a few channels is within reach.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Once the testbed system is in place, we hope it will serve in two main ways.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> First, a testbed system that resembles the desired system architecture<br></div><div dir="ltr">>> should make a very effective demonstration. This will make it much<br></div><div dir="ltr">>> easier to communicate the design and get the community excited about<br></div><div dir="ltr">>> its possibilities. It should contribute to recruiting more volunteers<br></div><div dir="ltr">>> to work on the project, and it should make our story for fundraising<br></div><div dir="ltr">>> much more convincing.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Second, a testbed system can serve as a platform for development of<br></div><div dir="ltr">>> the more advanced subsystems that haven't yet been fully worked out.<br></div><div dir="ltr">>> It should make it easier to identify requirements for these<br></div><div dir="ltr">>> subsystems. When prototype subsystems become available, it should be<br></div><div dir="ltr">>> possible to integrate those prototypes into the testbed and perform<br></div><div dir="ltr">>> some level of testing on those subsystems.<br></div><div dir="ltr">>><br></div><div dir="ltr">>><br></div><div dir="ltr">>> System Architecture Review<br></div><div dir="ltr">>> --------------------------<br></div><div dir="ltr">>><br></div><div dir="ltr">>> The system architecture assumes a single central payload and many user<br></div><div dir="ltr">>> stations. The central payload may be aboard a geosynchronous satellite<br></div><div dir="ltr">>> or may be at a terrestrial site with good coverage. We adopt the<br></div><div dir="ltr">>> satellite nomenclature and call the user station a "ground" station.<br></div><div dir="ltr">>> The link from the ground station to the central payload is called the<br></div><div dir="ltr">>> "uplink" and the link from the central payload to the ground stations<br></div><div dir="ltr">>> is called the "downlink".<br></div><div dir="ltr">>><br></div><div dir="ltr">>> The downlink is a single broadband transmission in the well-defined<br></div><div dir="ltr">>> industry standard format DVB-S2 or S2X for satellite systems.<br></div><div dir="ltr">>> Terrestrial systems may use DVB-S2/X as well, or may use the DVB-T2<br></div><div dir="ltr">>> standard instead for better performance in the multipath environment.<br></div><div dir="ltr">>> The downlink is shared among all the active ground stations at any<br></div><div dir="ltr">>> given time. This is done by treating all user signals as generic<br></div><div dir="ltr">>> digital data and incorporating that data into the DVB signal according<br></div><div dir="ltr">>> to the industry standard for Generic Stream Encapsulation (GSE).<br></div><div dir="ltr">>><br></div><div dir="ltr">>> When DVB-S2/X is used commercially, the various user data streams<br></div><div dir="ltr">>> (video or data) are generally transmitted over the Internet or other<br></div><div dir="ltr">>> data links to a large central ground station. These links are not<br></div><div dir="ltr">>> covered by any particular DVB standard. The central ground station is<br></div><div dir="ltr">>> then responsible for multiplexing the signals according to proprietary<br></div><div dir="ltr">>> business rules, and creates one big data stream on the ground. The<br></div><div dir="ltr">>> central station then transmits this big data stream as a DVB-S2/X<br></div><div dir="ltr">>> signal and uplinks it to the satellite payload. The satellite payload<br></div><div dir="ltr">>> is typically kept as "dumb" as possible, and merely retransmits the<br></div><div dir="ltr">>> uplinked DVB-S2/X signal on the downlink.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> This common commercial architecture does not translate well to amateur<br></div><div dir="ltr">>> radio. There is (as yet) no robust amateur infrastructure for relaying<br></div><div dir="ltr">>> data to a central station. Some entity would have to operate the<br></div><div dir="ltr">>> central ground station, which would be expensive, politically fraught,<br></div><div dir="ltr">>> and probably not very fun. Worse, the central ground station would be<br></div><div dir="ltr">>> a fragile single point of failure for the system. Instead, the P4G<br></div><div dir="ltr">>> architecture places the multiplexing function in the payload, on board<br></div><div dir="ltr">>> the satellite in the case of a space-based system.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> With the multiplexing function in the payload, P4G needs a<br></div><div dir="ltr">>> standardized way to pass data on the uplink from ground stations to<br></div><div dir="ltr">>> the payload. This needs to be relatively simple, since the payload<br></div><div dir="ltr">>> (which has restrictions on size, power, and complexity) must be able<br></div><div dir="ltr">>> to receive and process many of these signals simultaneously. We have<br></div><div dir="ltr">>> not identified any industry standard that is suitable for this type of<br></div><div dir="ltr">>> service, so P4G is defining its own uplink. The basics are that each<br></div><div dir="ltr">>> ground station transmits a separate MFSK carrier in one (or more, for<br></div><div dir="ltr">>> higher data rates) of about 100 non-overlapping uplink channels of<br></div><div dir="ltr">>> about 100 kHz each. The ground stations and the payload cooperate to<br></div><div dir="ltr">>> determine which channel may be used by each ground station, and when.<br></div><div dir="ltr">>> Channel-sharing parameters will be broadcast by the payload in<br></div><div dir="ltr">>> overhead messages in the downlink. Other overhead messages will convey<br></div><div dir="ltr">>> in real time which channels are in use, and by which stations, and<br></div><div dir="ltr">>> establish a common timebase for channel assignments. A protocol will<br></div><div dir="ltr">>> be specified by which a ground station may be required to authenticate<br></div><div dir="ltr">>> its identity and be checked against authorization policies set by the<br></div><div dir="ltr">>> payload operator. Development of these details into a rigorous<br></div><div dir="ltr">>> protocol specification is one of the major development activities<br></div><div dir="ltr">>> remaining.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> A ground station receives the entire multiplexed downlink, but is<br></div><div dir="ltr">>> probably not capable of or interested in making use of all the data on<br></div><div dir="ltr">>> the downlink. It will want to select one or more of the multiplexed<br></div><div dir="ltr">>> data streams for further processing. For example, if the ground<br></div><div dir="ltr">>> station is participating in a roundtable voice conversation with<br></div><div dir="ltr">>> several other ground stations, it will want to process the data<br></div><div dir="ltr">>> streams from each of the the other participants. Perhaps it will<br></div><div dir="ltr">>> decode audio from every stream and mix the audio together for the<br></div><div dir="ltr">>> local user's headphones. If it can't decode that many audio channels<br></div><div dir="ltr">>> simultaneously, or if the local user doesn't want that, it may<br></div><div dir="ltr">>> implement a smart algorithm to decide which audio channel(s) to decode<br></div><div dir="ltr">>> and present. Similar considerations apply to other types of data<br></div><div dir="ltr">>> streams. Except for certain mandatory control messages transmitted by<br></div><div dir="ltr">>> the payload itself, the ground station is free to decode and process<br></div><div dir="ltr">>> as much or as little of the downlink as it chooses.<br></div><div dir="ltr">>><br></div><div dir="ltr">>><br></div><div dir="ltr">>> Simplifying Assumptions<br></div><div dir="ltr">>> -----------------------<br></div><div dir="ltr">>><br></div><div dir="ltr">>> In order to make the demo more visually comprehensible, and to<br></div><div dir="ltr">>> restrict the complexity of any one component for the testbed system,<br></div><div dir="ltr">>> the payload, ground station transmitter, and ground station receiver<br></div><div dir="ltr">>> will be implemented in three separate subsystems. In some cases the<br></div><div dir="ltr">>> station functions will be further divided into multiple sub-subsystems<br></div><div dir="ltr">>> for convenience. The ground station transmitter and/or ground station<br></div><div dir="ltr">>> receiver subsystems may be replicated to create a more elaborate and<br></div><div dir="ltr">>> capable demonstration testbed. When it's time to test protocols that<br></div><div dir="ltr">>> involve both the uplink and the downlink, ground station transmitters<br></div><div dir="ltr">>> may be interconnected one-to-one with ground station receivers in<br></div><div dir="ltr">>> order to create a complete ground station.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Within the scope of this plan, we won't try to implement any channel<br></div><div dir="ltr">>> allocation protocol, authentication, or authorization. That work does<br></div><div dir="ltr">>> need to be done, though.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Within the scope of this plan, we won't try to simulate the<br></div><div dir="ltr">>> earth-space-earth or terrestrial channels in any detail. We'll use<br></div><div dir="ltr">>> attenuators to match signal strengths, but won't simulate any fading<br></div><div dir="ltr">>> or noise or delay or Doppler shift. Those might be interesting things<br></div><div dir="ltr">>> to add in later phases.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> We will use some simple packets and Opus encoded voice for the tests<br></div><div dir="ltr">>> and demonstrations. That's only a tiny representative slice of the<br></div><div dir="ltr">>> possible applications.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> The plan is written for DVB-S2/X, but there's no particular reason why<br></div><div dir="ltr">>> a similar plan wouldn't apply as well to a DVB-T2 system.<br></div><div dir="ltr">>><br></div><div dir="ltr">>><br></div><div dir="ltr">>> Proposed Testbed Development Phases<br></div><div dir="ltr">>> -----------------------------------<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Each of these phases is intended to be simple and incremental, and<br></div><div dir="ltr">>> includes a demo that exercises the function(s) implemented in that<br></div><div dir="ltr">>> phase. Some of the demos are just sanity checks for the lab, while<br></div><div dir="ltr">>> others would make good public demonstrations.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> First, we will concentrate on the ground station receiver side.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Phase 1. Set up a Raspberry Pi with audio output to a speaker. This<br></div><div dir="ltr">>> will be the beginning of a ground station receiver.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Demo: play an audio file from the Raspberry Pi's local storage.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Phase 2. Configure the Raspberry Pi to listen to Ethernet for a<br></div><div dir="ltr">>> multicast IP stream containing Opus-encoded digital audio. This can be<br></div><div dir="ltr">>> implemented using the existing program VLC.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Demo: on a laptop, use existing tools like opusenc and multicat to<br></div><div dir="ltr">>> transmit a multicast IP stream via Ethernet. Play an audio file from<br></div><div dir="ltr">>> the laptop's disk (or use a live microphone) and hear it come out of<br></div><div dir="ltr">>> the Raspberry Pi's speaker.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Phase 3. Add the SR-1 (commercial DVB-S2/X receiver with GSE<br></div><div dir="ltr">>> capability) to the system. Connect its data output port to the<br></div><div dir="ltr">>> Raspberry Pi's Ethernet. On a fast laptop (NOT connected to the<br></div><div dir="ltr">>> Ethernet) run the GSE+DVB-S2 transmit flowgraph in GNURadio Companion<br></div><div dir="ltr">>> (as already demonstrated at GNURadio Conference 2018) through a USRP<br></div><div dir="ltr">>> B210 SDR. This is the beginning of the payload transmitter. Connect<br></div><div dir="ltr">>> the SDR's RF output through suitable attenuators to the SR-1's RF<br></div><div dir="ltr">>> input. Again run opusenc and multicat, either on the fast laptop or on<br></div><div dir="ltr">>> another laptop, and arrange networking interconnects (like we did at<br></div><div dir="ltr">>> GNURadio Conference) so that the multicast IP stream goes over the<br></div><div dir="ltr">>> GSE+DVB-S2 link.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Demo: again transmit Opus-encoded voice and hear it come out of the<br></div><div dir="ltr">>> Raspberry Pi's speaker, after passing over the air in DVB-S2 GSE<br></div><div dir="ltr">>> format.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Phase 4: Modify the transmit flowgraph by adding a simple frame mux at<br></div><div dir="ltr">>> the input to the GSE module. One input of the mux gets the multicast<br></div><div dir="ltr">>> IP packet stream from the Opus encoder, as before. Other inputs stream<br></div><div dir="ltr">>> from file sources or, optionally, from other multicast IP packet<br></div><div dir="ltr">>> streams from other computers.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> On the Raspberry Pi, wrap VLC in a simple UI that allows a user to<br></div><div dir="ltr">>> select which of several multicast IP addresses to monitor.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Demo: show that the Raspberry Pi can switch around among the multiple<br></div><div dir="ltr">>> audio streams at will.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Phase 5: Add additional copies of the Raspberry Pi.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Demo: show that multiple streams can be received in parallel. We are<br></div><div dir="ltr">>> of course faking the multiple reception to some extent, since all the<br></div><div dir="ltr">>> Raspberry Pis are listening to the same SR-1. The SR-1 has powerful<br></div><div dir="ltr">>> enough hardware to handle the entire downlink.<br></div><div dir="ltr">>><br></div><div dir="ltr">>><br></div><div dir="ltr">>> Partial success can be declared here. We've demonstrated a multiplexed<br></div><div dir="ltr">>> downlink over GSE and a minimal ground receiver with the ability to<br></div><div dir="ltr">>> select and receive one of the streams. Since we're using Opus at a<br></div><div dir="ltr">>> decent bit rate, the audio quality ought to be outstanding. This might<br></div><div dir="ltr">>> be a good time to set aside the downlink and work on the downlink, but<br></div><div dir="ltr">>> there's still more to do on the downlink.<br></div><div dir="ltr">>><br></div><div dir="ltr">>><br></div><div dir="ltr">>> Phase 6: Add our open-source DVB-S2/X receiver (perhaps it is a<br></div><div dir="ltr">>> flowgraph) running on suitable hardware. Split the RF signal between<br></div><div dir="ltr">>> the SR-1 and our receiver. Split the Ethernet into two segments, each<br></div><div dir="ltr">>> with one or more of the Raspberry Pis. Let the SR-1 continue to feed<br></div><div dir="ltr">>> one segment and let our receiver feed the other segment.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Demo: as before. Show that the open source receiver works like the<br></div><div dir="ltr">>> SR-1. Adjust the downlink attenuators and see how the performance<br></div><div dir="ltr">>> compares near the threshold. Now the demo is less fake, since we have<br></div><div dir="ltr">>> two completely separate receivers.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Phase 7: Replicate the DVB-S2/X receiver and connect each one<br></div><div dir="ltr">>> separately to its own Raspberry Pi.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Demo: as before, but even less fake<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Phase 8: Incorporate the functions of the Raspberry Pi into the<br></div><div dir="ltr">>> hardware that's running the DVB-S2/X receiver.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Demo: as before, but with less clutter<br></div><div dir="ltr">>><br></div><div dir="ltr">>><br></div><div dir="ltr">>> Set that aside and start on the uplink. This could also be started in<br></div><div dir="ltr">>> parallel, resources permitting.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Phase A. Set up a fast laptop with GNU Radio. This will be the<br></div><div dir="ltr">>> beginning of the payload receiver. Create a simple flowgraph that<br></div><div dir="ltr">>> implements a polyphase filter bank to receive 4 contiguous 100 kHz<br></div><div dir="ltr">>> channels. Connect each of the four output channels to spectrum<br></div><div dir="ltr">>> visualizers. Connect another SDR (perhaps the USRP X310) to the<br></div><div dir="ltr">>> flowgraph as a signal source. Connect an off-the-shelf signal<br></div><div dir="ltr">>> generator's output to the SDR's RF input.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Demo: Run the flowgraph and observe the four channels of vacant<br></div><div dir="ltr">>> spectrum. Manually sweep the signal generator across the band, and<br></div><div dir="ltr">>> watch the carrier sweep across each of the four spectrum visualizers<br></div><div dir="ltr">>> in turn.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Phase B: Set up a separate SDR with GNU Radio on a laptop. This will<br></div><div dir="ltr">>> be the beginning of the ground station transmitter. Create a flowgraph<br></div><div dir="ltr">>> that alternates a fixed synchronization preamble with a packet data<br></div><div dir="ltr">>> source, and transmits it in a MFSK burst (i.e., turning the<br></div><div dir="ltr">>> transmitter on, sending a preamble and some data, and then turning it<br></div><div dir="ltr">>> off). Feed it with random data packets for now. Make it transmit near<br></div><div dir="ltr">>> the middle of one of the four channels the polyphase filter bank is<br></div><div dir="ltr">>> receiving, and connect its RF output through suitable attenuators to<br></div><div dir="ltr">>> the RF input of the payload receiver SDR (removing the signal<br></div><div dir="ltr">>> generator).<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Demo: See the bursts of data in one of the spectrum visualizers on the<br></div><div dir="ltr">>> payload receiver.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Phase B1: Try replacing the ground station transmitter laptop with a<br></div><div dir="ltr">>> Raspberry Pi. If it works we can more cheaply and conveniently<br></div><div dir="ltr">>> replicate multiple ground stations for later testing.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Demo: same as Phase B.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Phase C: Modify the flowgraph in the payload receiver to add a MFSK<br></div><div dir="ltr">>> demodulator and a correlation detector on each of the four outputs of<br></div><div dir="ltr">>> the PFB. Add a time visualizer at the output of each correlation<br></div><div dir="ltr">>> detector.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Demo: See the transmitted preambles cause a pulse on the corresponding<br></div><div dir="ltr">>> time visualizer.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Phase D: Modify the payload receiver flowgraph to use the correlation<br></div><div dir="ltr">>> sync pulse to parse the data burst into a header of N bits and a body<br></div><div dir="ltr">>> of M bits. Add a data display widget that shows the header and another<br></div><div dir="ltr">>> data display widget that shows the first bits of the body.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Demo: See that the first N bits of the random packet data shows up the<br></div><div dir="ltr">>> header widget and the next few bits of the random packet data shows up<br></div><div dir="ltr">>> in the body widget.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Phase E: Modify the ground station transmitter flowgraph to encode a<br></div><div dir="ltr">>> header and body. Define certain bits of the header to be a length<br></div><div dir="ltr">>> field. Add a UI widget to set the length field. Modify the payload<br></div><div dir="ltr">>> receiver flowgraph to parse out the length field from the header and<br></div><div dir="ltr">>> display it.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Demo: Set various values in the length field on the ground station<br></div><div dir="ltr">>> transmitter, and see them show up in the length display on the payload<br></div><div dir="ltr">>> receiver.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Phase F: Modify the ground station transmitter flowgraph to accept a<br></div><div dir="ltr">>> packet input, determine its length, pack that value into the length<br></div><div dir="ltr">>> field of the header, and use the data from the packet to fill the body<br></div><div dir="ltr">>> part of the transmission.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Demo: send various length packets into the ground station transmitter<br></div><div dir="ltr">>> flowgraph, and see that the length display on the payload receiver<br></div><div dir="ltr">>> shows the same lengths.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Phase G: Modify the payload receiver flowgraph to use the received<br></div><div dir="ltr">>> length value to grab that much of the received body data and output it<br></div><div dir="ltr">>> as a packet. Use Wireshark to monitor the packet output.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Demo: Send packets from the ground station transmitter and see them<br></div><div dir="ltr">>> appear in the Wireshark display.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Phase H: Combine the payload receiver flowgraph with the multiplexed<br></div><div dir="ltr">>> GSE+DVB-S2 (payload transmitter) flowgraph from Phase 4. Have the<br></div><div dir="ltr">>> packets that were output in Phase G go into the multiplexer instead.<br></div><div dir="ltr">>> Move the Wireshark to monitor the ground station receiver's Ethernet.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Demo: send packets from the ground station transmitter and see them<br></div><div dir="ltr">>> appear in the Wireshark display, after going over DVB-S2.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Phase I: Move the opusenc+multicat source to the ground station<br></div><div dir="ltr">>> transmitter's Ethernet. Arrange for the multicast IP stream to go into<br></div><div dir="ltr">>> the packet transmitter.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Demo: transmit Opus-encoded voice and hear it come out of the<br></div><div dir="ltr">>> Raspberry Pi's speaker, after passing through both the uplink and the<br></div><div dir="ltr">>> downlink.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Phase J: Replicate one or more copies of the ground station transmitter.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Demo: transmit multiple streams of Opus-encoded voice and receive them<br></div><div dir="ltr">>> on the multiple ground station receivers from Phase 5.<br></div><div dir="ltr">>><br></div><div dir="ltr">>><br></div><div dir="ltr">>> That's already a pretty nice demo. Since we have physical separation<br></div><div dir="ltr">>> between the ground station transmitter, the payload, and the ground<br></div><div dir="ltr">>> station receiver, we can label them and point to them and make the<br></div><div dir="ltr">>> demo visually compelling. We have all the major components of the<br></div><div dir="ltr">>> system, albeit in simplified form.<br></div><div dir="ltr">>><br></div><div dir="ltr">>><br></div><div dir="ltr">>> Going beyond the demo scope, some next steps might be:<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Phase K: Replace the multiplexer in the payload flowgraph with a<br></div><div dir="ltr">>> custom block. Have it generate an on-the-fly status report and<br></div><div dir="ltr">>> transmit that on its own multicast IP stream, muxed in with the user<br></div><div dir="ltr">>> streams. Add a process to the ground station receiver to accept the<br></div><div dir="ltr">>> status report stream and display it.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Demo: see the system status live on the ground station receiver.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Phase L: Add a block in the payload flowgraph to generate an overhead<br></div><div dir="ltr">>> information stream and feed it to the multiplexer. Add a process to<br></div><div dir="ltr">>> the ground station receiver to accept the overhead stream and display<br></div><div dir="ltr">>> it.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Demo: see the system overhead information on the ground station receiver.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Phase M: Modify the payload flowgraph to alternate long transmissions<br></div><div dir="ltr">>> at the regular MODCOD as before with short transmissions of canned GSE<br></div><div dir="ltr">>> data at the most robust MODCOD.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Demo: increase the attenuation on the downlink RF until the regular<br></div><div dir="ltr">>> MODCOD can no longer be received. Note that the SR-1 still locks up on<br></div><div dir="ltr">>> and receives the robust MODCOD. This simulates initial ground station<br></div><div dir="ltr">>> acquisition. Note that the SR-1 is not designed for burst reception,<br></div><div dir="ltr">>> so the "short" transmissions may have to be rather long for this demo<br></div><div dir="ltr">>> to work.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Phase N: If we have reached Phase 6 on the downlink side, modify the<br></div><div dir="ltr">>> DVB-S2/X receive flowgraph to handle the MODCOD switching back and<br></div><div dir="ltr">>> forth, if necessary.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Demo: as in Phase M, only with our own DVB-S2/X receiver.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Phase O: (maybe this makes sense) Modify the DVB-S2/X receiver to take<br></div><div dir="ltr">>> advantage of information and synchronization obtained from the robust<br></div><div dir="ltr">>> MODCOD to improve acquisition performance at the regular MODCOD. Maybe<br></div><div dir="ltr">>> it would help if the information sent under the robust MODCOD included<br></div><div dir="ltr">>> the index of the regular MODCOD.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Demo: vary the attenuation on the downlink RF and see if our receiver<br></div><div dir="ltr">>> can now acquire the downlink at a lower signal strength, or more<br></div><div dir="ltr">>> quickly.<br></div><div dir="ltr">>><br></div><div dir="ltr">>><br></div><div dir="ltr">>> In Conclusion<br></div><div dir="ltr">>> -------------<br></div><div dir="ltr">>><br></div><div dir="ltr">>> This plan doesn't finish the project. It does plan substantial forward<br></div><div dir="ltr">>> progress, and creates specific and effective public demonstrations.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> _______________________________________________<br></div><div dir="ltr">>> Ground-Station mailing list<br></div><div dir="ltr">>> <a href="mailto:Ground-Station@lists.openresearch.institute" rel="nofollow" target="_blank">Ground-Station@lists.openresearch.institute</a><br></div><div dir="ltr">>> <a href="http://lists.openresearch.institute/mailman/listinfo/ground-station" rel="nofollow" target="_blank">http://lists.openresearch.institute/mailman/listinfo/ground-station</a><br></div><div dir="ltr">><br></div><div dir="ltr">> _______________________________________________<br></div><div dir="ltr">> Ground-Station mailing list<br></div><div dir="ltr">> <a href="mailto:Ground-Station@lists.openresearch.institute" rel="nofollow" target="_blank">Ground-Station@lists.openresearch.institute</a><br></div><div dir="ltr">> <a href="http://lists.openresearch.institute/mailman/listinfo/ground-station" rel="nofollow" target="_blank">http://lists.openresearch.institute/mailman/listinfo/ground-station</a><br></div><div dir="ltr"><br></div><div dir="ltr">_______________________________________________<br></div><div dir="ltr">Ground-Station mailing list<br></div><div dir="ltr"><a href="mailto:Ground-Station@lists.openresearch.institute" rel="nofollow" target="_blank">Ground-Station@lists.openresearch.institute</a><br></div><div dir="ltr"><a href="http://lists.openresearch.institute/mailman/listinfo/ground-station" rel="nofollow" target="_blank">http://lists.openresearch.institute/mailman/listinfo/ground-station</a><br></div></div>
</div>
</div></body></html>