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
