> this email is replicated because I'm getting errors that my email "contains HTML" from mailer@lists.sr.ht. Is there anyone that didn't receive my last email? This one is sent in plaintext mode.
Right. This is definitely out of my depth, but my loose knowledge of
signals/etc in my EE degree leads me to believe that
"frequency-division multiplexing" (which wikipedia says OFDM is a
subset of) could be used. At an extremely simple level from my
understanding this is composed of:
A transformer circuit that converts a data stream into multiple (say
1000) frequencies which are orthogonal to each other so they don't
interfere.
A filter circuit that filters out each frequency and converts it back
into data, merging it back into the data stream
This allows you to shove more bits down the same long distance pipe.
Thus the local "chip" side of each end can run at 1 MHz, and the 1000
"channels" can run for miles at 1KHz but be summed into a MHz.
However, my understanding was that to be "orthogonal" (aka no
interference) the frequencies needed to be halved/doubled (exponential
distance). However, the wikipedia link[0] seems to say that each
frequency just needs to be a delta T, aka linear distance. That is
very surprising to me!
> Something very simple and available is RS-485. It can do about 100 kbps over 1.2 km, but the line driver is super simple, just a digital differential driver. Something similar could probably be constructed from discrete transistors using current-steering / differential transistor pairs. Perhaps with some inductance at the ends of the connection it could be extended a bit.
This is at least a usable bandwidth for anything but medium-high
density image transmission (even a small amount of sound would be
okay).
Best,
Rett
[0]: https://en.wikipedia.org/wiki/Orthogonal_frequency-division_multiplexing#Orthogonality
On Wed, Feb 15, 2023 at 7:46 AM Rett Berg <googberg@gmail.com> wrote:
>
> Right. This is definitely out of my depth, but my loose knowledge of signals/etc in my EE degree leads me to believe that "frequency-division multiplexing" (which wikipedia says OFDM is a subset of) could be used. At an extremely simple level from my understanding this is composed of:
>
> A transformer circuit that converts a data stream into multiple (say 1000) frequencies which are orthogonal to each other so they don't interfere.
> A filter circuit that filters out each frequency and converts it back into data, merging it back into the data stream
>
> This allows you to shove more bits down the same long distance pipe. Thus the local "chip" side of each end can run at 1 MHz, and the 1000 "channels" can run for miles at 1KHz but be summed into a MHz. However, my understanding was that to be "orthogonal" (aka no interference) the frequencies needed to be halved/doubled (exponential distance). However, the wikipedia link[0] seems to say that each frequency just needs to be a delta T, aka linear distance. That is very surprising to me!
>
> > Something very simple and available is RS-485. It can do about 100 kbps over 1.2 km, but the line driver is super simple, just a digital differential driver. Something similar could probably be constructed from discrete transistors using current-steering / differential transistor pairs. Perhaps with some inductance at the ends of the connection it could be extended a bit.
>
> This is at least a usable bandwidth for anything but medium-high density image transmission (even a small amount of sound would be okay).
>
> Best,
> Rett
>
> [0]: https://en.wikipedia.org/wiki/Orthogonal_frequency-division_multiplexing#Orthogonality
>
> On Tue, Feb 14, 2023 at 5:10 PM Daniel Marks <profdc9@gmail.com> wrote:
>>
>> So typically high bandwidth over twisted pair (for example DSL) uses OFDM. So one could imagine something like a DSL modem being used point-to-point. Unfortunately DSL modems are designed to be used with DSLAMs and so can't connect directly to each other. But one could imagine perhaps reprogramming such hardware to do symmetric DSL connections. Modern PCs are also capable of quite remarkable DSP operations, some software defined radio applications being an example of this, so perhaps a ADC/DAC and an analog line driver that can be connected through USB might be used to interface to the PC.
>>
>> Another similar approach is power line networking. It produces nasty RFI generally, but this may not be such a concern :) . This may be more attractive since power lines may still be available (but not delivering power), or there may be power lines delivering power but no network capability. Of course, when you get to producing this much radiation, the difference between wired and wireless connections gets kind of fuzzy. :)
>>
>> Something very simple and available is RS-485. It can do about 100 kbps over 1.2 km, but the line driver is super simple, just a digital differential driver. Something similar could probably be constructed from discrete transistors using current-steering / differential transistor pairs. Perhaps with some inductance at the ends of the connection it could be extended a bit.
>>
>>
>> On Tue, Feb 14, 2023 at 4:27 PM Rett Berg <googberg@gmail.com> wrote:
>>>
>>> I wonder how effective v"twisted pair" would be, aka over thin wire with solar repeaters. Clearly harder to deploy than wireless, but you can shove an absolutely absurd amount of bits down wires with modern approaches. I wonder how much of that could be reduced into a few transistors, some oscillators and some embedded software. Would it be possible to get Mb/s speeds?
>>>
>>> Daniel's solution is fantastic for communication, but data storage and retrieval is a larger beast. Until the recent "laser backbone" of SpaceX, I don't think having a networking backend in wireless was even remotely conceivable (although I might be wrong).
>>>
>>> Another important point: you don't need only one solution. Slow wireless protocol for high priority communication, fast but low power (and range) wireless for <1km communication, wired communication for a community. Large amounts of data between communities could be exchanged over sneaker net, using some kind of squashed Merkel tree (git) to track updates and changes.
>>>
>>> What got shared would only be what's essential: software updates, schematic fixes, knowledge creation, etc. Bob's family blog would likely bitrot or just be burned on some CD under his bed. I think sometimes people forget how data and other things used to be lost to history, and how liberating that was. Out current mindset of "every scrap must be preserved" has plenty of downsides that are not necessary worth re-creating.
>>>
>>> Best,
>>> Rett
>>>
>>> On Tue, Feb 14, 2023, 3:25 PM Daniel Marks <profdc9@gmail.com> wrote:
>>>>
>>>> For my two cents on the subject...
>>>>
>>>> When I designed SCAMP, I was trying to design something simple enough to be decoded on a 8-bit microcontroller, but contain some features that might enable communication at extremely low signal to noise ratio using low power, like FT8. So the data rate is something like 14 to 84 bits/s, before error correction which is a 1/2 code rate. This is enough to send a short text message, but probably not sufficient to be relaying megabytes of data around constantly. It may be possible to increase the bit rate by 2 or perhaps 4 times even using an Arduino because of the way the protocol is implemented, however, the power must also increase in order to keep the bit error rate the same.
>>>>
>>>> Amateur networks such as Winlink ( https://www.winlink.org/ ) already do relaying but of course require more power, a PC, etc.
>>>>
>>>> Gossip networks might be good candidates for networks of point-to-point free space optical links. Bandwidth is less of an issue, and perhaps something simple could be made using infrared LEDs or lasers and telescopes. 850 nm Infrared LEDs and silicon photodiodes are readily available and can be scrounged from many devices, and many will work into the MHz range, making "Collapse" infrared networking hubs that could be situated on elevated poles or high locations quite doable. One could even use a pair of binoculars as a transmitter/receiver telescope, with a 20x80 possibly being able to go for several miles. Simple ARQ (automatic request retransmission) protocols are also probably sufficient for this application as well.
>>>>
>>>> 73,
>>>> Dan
>>>> KW4TI
>>>>
>>>>
>>>> On Tue, Feb 14, 2023 at 2:50 PM John Moss <jwestonmoss@gmail.com> wrote:
>>>>>
>>>>> I have given something like this quite a bit of thought, in terms of trying to build a long-term-grid-down network for regional (1-2 counties) communications and public service. Gossip networks pay for their resiliency with redundancy, which is expensive from a technical perspective. Not only storage, but also network congestion. In addition, unless nodes are placed relatively close together in high-bitrate modes, they will have to run in low bandwidth modes on low cycle rates, in order to maintain link and manage power consumption. For that reason, one of the key elements of a network like that is understanding the size limitations of data and learning to live within it. The most stable long range frequency setting on lorawan for instance has a data rate of just under 1kbps. While there are other protocols and stacks, fundamentally due to the limitations of power output and antenna size (regulation!) and typical forms of attenuation, the best way to create a long-distance stable link is by reducing your "coding rate" and tightening your bandwidth to cut through interference and effectively lower the noise floor. So throughput will ALWAYS be a problem for that kind of network. In that respect, a user of the network could pretty easily damage the network's usefulness simply by overwhelming its "gossip budget" downstream, so you'd have to build in some way to prevent that.
>>>>>
>>>>> On Sun, Jan 8, 2023 at 6:46 AM Csepp <raingloom@riseup.net> wrote:
>>>>>>
>>>>>> (disclaimer: apoligies if I've already talked about this, I tried to find
>>>>>> any previous messages about NDN, but couldn't.)
>>>>>>
>>>>>> There are a lot of mentions in the RFBitBanger thread about WiFi and
>>>>>> other current wireless networking protocols, which got me thinking about
>>>>>> content centric networking again and I'd like to ask what others who
>>>>>> know more about this topic think of its suitability for a post-collapse
>>>>>> (or at least near-collapse) scenario.
>>>>>>
>>>>>> This is the main implementation of these ideas that I know of:
>>>>>> https://named-data.net/
>>>>>>
>>>>>> The TLDR version is: instead of overlaying an end-to-end network on a
>>>>>> broadcast medium why not refer to the name of the data you want.
>>>>>> If you are familiar with secure scuttlebutt, this is a similar idea.
>>>>>>
>>>>>> The potential problems I see:
>>>>>>
>>>>>> Gossip networks require nodes to have more storage. microSD cards
>>>>>> should be around for a while, but they can't be rewritten too often.
>>>>>> If you have to build storage yourself than the situation is pretty much
>>>>>> hopeless, but if you can store at least a few hundred meg, then using it
>>>>>> to relay messages via gossip and sneaker networks might be a good use
>>>>>> for them.
>>>>>>
>>>>>> NDN uses some cryptography to validate that a piece of data came from an
>>>>>> authorized source. Performing the necessary calculations is likely too
>>>>>> expensive for something like a 6502, but depending on how hostile the
>>>>>> outside world is, having at least the option to use cryptography might
>>>>>> be worth it.
>>>>>>
>>>>>> It's definitely more complex than simple broadcast radio, so you need
>>>>>> more code to implement, which again means more storage.
>>>>>> There is a small-ish implementations in C++ for embedded applications,
>>>>>> so maybe the cost in code size is not that terrible, and again,
>>>>>> depending on other factors, it might be worth it if it frees
>>>>>> communicating parties from having to be online at the same time.
>>>>>> And again, if the environment is hostile, easily trackable radio signals
>>>>>> might be a security risk that a delay tolerant sneakernet can mitigate.
>>>>>>
>>>>>>
>>>>>> So, there are at least a few cost/benefit dimensions to analyze.
>>>>>>
>>>>>> ps.: I'm sending this to the DuskOS list because I think Dusk's
>>>>>> complexity budget might more easily allow for a protocol similar to NDN,
>>>>>> but I CC'd the CollapseOS list too since that's where the RFBitBanger
>>>>>> discussion was happening, I hope the cross posting is not too
>>>>>> disruptive.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thanks.
>>>>>
>>>>> J. Weston Moss
>>>>> W8WOW
>>>>>
>>>>> 513-504-3984