Hacker News new | past | comments | ask | show | jobs | submit login

Wouldn't this lead to a spectrum monopoly and the death of family radios, home wifi, etc.?

The market may be "efficient", but I don't want my radio regulator to optimize for cost alone, rather for balancing a variety of different needs, ranges, and durations like they are now.




First, I would argue we haven't efficiently used the bandwidth at all. In many places you'll find large swaths of bandwidth not being used at the moment. This gets particularly more pronounced at night.

E.g. Why can't I use FM frequencies that aren't being used in the area for my personal use of a few hundred feet? Why can't I use the frequencies the local car dealership is using after 6pm when they've closed for the night?


I'd agree with that, and wish we could phase out many of the old analog frequencies and relicense them for use with more efficient digital encodings.


Digital encodings are analog down deep under everything, and often they are far, FAR less reliable when you don't have 20 dB+ s/(s+n). Analog at least degrades in a fairly transparent and predictable manner. Many public service departments across the country are giving up their old "vhf" channels... and then regretting it when the new UHF digital stuff just doesn't work half the time.


Almost any channel adaptive digital encoding (ie. where the sender gets feedback from the receiver about how much data is successfully arriving) will end up sending more useful data than any analogue scheme in any conditions.

Super weak voice channel where you can barely make out any words? That same channel, with the same transmit power, will get a decent telephone quality digital voice down, as long as you use modern low bitrate audio encoding. And it would send pages of text per second if you can handle typing not speaking.


FT8 I think is a great example of low power digital working well.

It's not huge amounts of data or traffic, but it seems to be fairly reliable.


I see. Thanks for the input!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: