[Ground-station] P4G System Testbed Prototyping Scheme proposal

[Michelle Thompson]

It goes without saying, but it's always better with:

I see the wideband/narrowband thing as both/and not either/or.

I will enable this to the best of my ability! We got a good start with
Frank Brickle outlining the low data rate "SatChat" (1kHz) protocol. It
deserves to get made and then make a difference.

-Michelle W5NYV




On Sun, Mar 10, 2019 at 11:05 AM Wally Ritchie via Ground-Station
<ground-station at lists.openresearch.institute> wrote:

> 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
>>
> _______________________________________________
> 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/f183b3e2/attachment.html>