[Ground-station] P4G System Testbed Prototyping Scheme proposal

Wally Ritchie wally.ritchie at gmail.com
Sun Mar 10 13:50:54 EDT 2019

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openresearch.institute/pipermail/ground-station/attachments/20190310/208fa2f2/attachment-0001.html>

More information about the Ground-Station mailing list