[Ground-station] P4G System Testbed Prototyping Scheme proposal

[Wally Ritchie]

Would certainly be for use cases other than GEO. Es'Hail 2 is pretty close
to negligible and most other GEO's are well under 100Hz in C-Band.

Wally WU1Y

On Sun, Mar 10, 2019 at 1:56 PM KENT BRITAIN <wa5vjb at flash.net> wrote:

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