5 ms·

Would this open possibilities for a direct machine to machine network that didn't go over the internet? (I.e. could I set up something to ssh to my home server

Would this open possibilities for a direct machine to machine network that didn't go over the internet? (I.e. could I set up something to ssh to my home server from my laptop without needing wifi/cellular coverage?

upofadown 11y ago
The data rate is really low. So maybe, if you are patient and are not much more than a mile from home.
- kevinnk 11y ago
  Data rate in the US is something like 11kbps. So you'd have to be really patient.
  - runeks 11y ago
    Isn't 11 Kbps fine for SSH? That's 11 thousand ascii characters per second. The latency is the important part, I assume this is low as well but I don't know.
    - olympus 11y ago
      Actually each ascii character takes up a byte (8 bits). You can get this down to just 7 bits if you aren't using the extended table, but a byte is very convenient and what most programs use for the size of a char. That means that with an 11Kbps line you are getting about 1,000 characters per second once you factor in other communication over head (stop bits, parity bits, etc). While this may sound fast it is painfully slow for anything other than typing in single line commands and reading single line responses. The transfer of a blank 4KB text file will take three seconds. The transfer of a plain text file the size of a book would take a few minutes. With the additional overhead of SSH you will actually see the characters appearing on the screen like a lame 80s hacker movie.
      - marssaxman 11y ago
        It pretty much looked like that in reality, too.
      - jbuzbee 11y ago
        As someone who remembers 300 baud modems used in a trans-atlantic connection, I also remember that you could get stuff done if you set your expections accordingly.
    - fsiefken 11y ago
      Perhaps use mosh? It hides the lag on low bandwidth links. I remember using Citrix remote desktop on a 14k4 link. I remember using the internet at 14k4 - worked fine.
- Tremz 11y ago
  Maybe this might work to handle flocks of quadcopters?
olympus 11y ago
Sure, you can hook up a low power serial transmitter to a Raspberry Pi's UART and have a text only console to operate over. But you are pretty much limited to text only and very slow file transer over a serial transmission like Kermit or Xmodem. You'll hate it for the type of computing you're used to. If you want a graphical remote desktop you are better off setting up a WiFi router/WLAN and connecting through a remote desktop connection. This will consume much more battery life, but I power a WiFi router with an RC LiPo battery and a voltage regulator and it lasts for several hours (but you certainly aren't getting days of battery life).
IshKebab 11y ago
No, they're extremely slow.
makomk 11y ago
Probably not. Not only are they very slow, but radio propagation at the frequencies they're using is still more or less line-of-sight, which means that your range is going to be limited by the horizon. See https://en.wikipedia.org/wiki/Line-of-sight_propagation https://en.wikipedia.org/wiki/Line-of-sight_propagation
Gibbon1 11y ago
Where you get squeezed is, output power is limited by regulation (for good reason). And sensitivity is limited by noise which is related to your signal bandwidth. The wider the band, the more noise you capture. There is a signal to noise 'wall/floor' defined by information theory, etc etc. Encoding technologies+ allow you to operate closer to the wall, but it's still here as a hard limit. Once your signal/noise drops below 3-6db game over+. These new technologies/products try to solve the problem from both ends. Increasing transmit power to the max allowed. Some early Zigbee chips for instance had transmit powers of 0db, big fail. These new radios transmit 10 to 20 db output power. On the receive side reduce bandwidth to increase the sensitivity by 10-30 db, at the expense of data rate. The cost of all this is very low bandwidth. Not just in bps, but also packets per minute due to duty cycle regulations. This poses some problems if you want encrypt your packets. Add at least 32-64 bytes overhead. Another problem is as the coverage area gets wider so does the number of interfering radio's. + Sometimes you hear comments that spread spectrum allows you operate below the noise floor, but that's only for the spread signal. Once the signal is despread at the receiver, same rules apply.

upofadown 11y ago

The data rate is really low. So maybe, if you are patient and are not much more than a mile from home.

kevinnk 11y ago
Data rate in the US is something like 11kbps. So you'd have to be really patient.
- runeks 11y ago
  Isn't 11 Kbps fine for SSH? That's 11 thousand ascii characters per second. The latency is the important part, I assume this is low as well but I don't know.
  - olympus 11y ago
    Actually each ascii character takes up a byte (8 bits). You can get this down to just 7 bits if you aren't using the extended table, but a byte is very convenient and what most programs use for the size of a char. That means that with an 11Kbps line you are getting about 1,000 characters per second once you factor in other communication over head (stop bits, parity bits, etc). While this may sound fast it is painfully slow for anything other than typing in single line commands and reading single line responses. The transfer of a blank 4KB text file will take three seconds. The transfer of a plain text file the size of a book would take a few minutes. With the additional overhead of SSH you will actually see the characters appearing on the screen like a lame 80s hacker movie.
    - marssaxman 11y ago
      It pretty much looked like that in reality, too.
    - jbuzbee 11y ago
      As someone who remembers 300 baud modems used in a trans-atlantic connection, I also remember that you could get stuff done if you set your expections accordingly.
  - fsiefken 11y ago
    Perhaps use mosh? It hides the lag on low bandwidth links. I remember using Citrix remote desktop on a 14k4 link. I remember using the internet at 14k4 - worked fine.
Tremz 11y ago
Maybe this might work to handle flocks of quadcopters?

olympus 11y ago

Sure, you can hook up a low power serial transmitter to a Raspberry Pi's UART and have a text only console to operate over. But you are pretty much limited to text only and very slow file transer over a serial transmission like Kermit or Xmodem. You'll hate it for the type of computing you're used to. If you want a graphical remote desktop you are better off setting up a WiFi router/WLAN and connecting through a remote desktop connection. This will consume much more battery life, but I power a WiFi router with an RC LiPo battery and a voltage regulator and it lasts for several hours (but you certainly aren't getting days of battery life).

IshKebab 11y ago

No, they're extremely slow.

makomk 11y ago

Probably not. Not only are they very slow, but radio propagation at the frequencies they're using is still more or less line-of-sight, which means that your range is going to be limited by the horizon. See https://en.wikipedia.org/wiki/Line-of-sight_propagation https://en.wikipedia.org/wiki/Line-of-sight_propagation

Gibbon1 11y ago

Where you get squeezed is, output power is limited by regulation (for good reason). And sensitivity is limited by noise which is related to your signal bandwidth. The wider the band, the more noise you capture. There is a signal to noise 'wall/floor' defined by information theory, etc etc. Encoding technologies+ allow you to operate closer to the wall, but it's still here as a hard limit. Once your signal/noise drops below 3-6db game over+. These new technologies/products try to solve the problem from both ends. Increasing transmit power to the max allowed. Some early Zigbee chips for instance had transmit powers of 0db, big fail. These new radios transmit 10 to 20 db output power. On the receive side reduce bandwidth to increase the sensitivity by 10-30 db, at the expense of data rate. The cost of all this is very low bandwidth. Not just in bps, but also packets per minute due to duty cycle regulations. This poses some problems if you want encrypt your packets. Add at least 32-64 bytes overhead. Another problem is as the coverage area gets wider so does the number of interfering radio's. + Sometimes you hear comments that spread spectrum allows you operate below the noise floor, but that's only for the spread signal. Once the signal is despread at the receiver, same rules apply.