I believe that Daniel's use case is to have an SDR receiving the entirety of a band of interest, and sending those samples, pre any processing, to multiple remote users. The concern with just instantiating N udp streams is that it doesn't scale for wide bands and large numbers of users.
Merging multiple remote user's transmit streams into a single tx stream is of course another problem. On Thu, Feb 4, 2016 at 11:27 AM, Marcus Müller <marcus.muel...@ettus.com> wrote: > Wait, is this discussion still about forwarding spectrum from band A over > band B, or is it already also incorporating IP-based access over > "classical" internet access technology? In the latter case, I'd really say > that that not having multicast is not really a problem, here - the way to > go would be to extract the channels of interest at the receiver, decode > them, and forward them only occupying the actual data rate - which for the > typical 2m channel is ridiculously low compared to what your average ISP > can offer you as uplink. > > Bonus realization is that decode and forward (i.e. decoding, and then > encoding the decoded signal in the same manner as the original transmitter > for relaying it, be it digital or analog voice FM or whatever), under the > assumption that your relay has a decoder that isn't worse than what you had > done locally with the same digital samples, always leads to a better > overall SNR then what forwarding the raw input signal would have had. > (Think in terms of noise figures - in decode and forward, your overall > noise figure is basically is close to that of the worse receiver, be it > that of your relay or final receiver, whereas in a "bent digital pipe and > upmix" system, it would be the product of all noise figures.) > > Now, if we talk about forwarding the raw spectrum from band A over band B, > maybe because the relay itself can't know how/what to decode, and need to > add additional data (e.g. call signs of the relay), it's mandatory that we > occupy more bandwidth*power in B than we receive in A, lest we lose > information. Luckily, with increasing carrier frequency, bandwidth usually > gets easier to acquire; sadly, the same relation exists for carrier > frequency and attenuation... > > Now, sampling signal with bit depth B, of which only E<B bits are actually > effective, putting these bits into symbols, and transmitting those > including pulse shaping, channel coding/forward error correction and > framing as packets is bound to increase the bandwidth a lot, unless you can > use a modulation that has a very high spectral efficiency, i.e. bit/s/Hz, > which in turn means that the receiver of these packets needs to have a much > more impressive SNR than what can get reconstructed as signal contained in > the packets. That doesn't sound too tempting! > > Best regards, > Marcus > > Am 4. Februar 2016 19:02:56 MEZ, schrieb Daniel Pocock <dan...@pocock.pro > >: >> >> >> >> On 04/02/16 18:56, Martijn Moeling wrote: >> >>> that is why websdr is the way to go, the software is free and receivers >>> can be cheap (like one or more rtl dongles) >>> >>> >> >> Not quite... while WebSDR could be accessed over amateur bands using >> packet modes, I didn't see any evidence that it supports IP multicasting >> the whole spectrum from the radio. Therefore, if several people try to >> access it simultaneously, it will send a separate IP flow to each of >> them, which is not scalable. >> >> Regards, >> >> Daniel >> >> ------------------------------ >> >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
