USAID Tech Challenge

0 views
Skip to first unread message

Urbanus Z

unread,
Jan 22, 2013, 8:36:15 PM1/22/13
to Byza...@hacdc.org
Greetings,

It's been a while since I've checked back in with HacDc, and I'm impressed with the progress Byzantium has made.

There's a tech challenge from www.humanityunited.org. and USAID opening in Feburary that a few of you might be interested in. Here's the problem description.:

During acute crises, vulnerable populations are often cut off from critical information and have limited, if any, ability to communicate inside or outside of their communities. While there are a number of existing efforts aimed at improving information flow in these contexts, many focus on the outflow of information from communities or rely too heavily on existing communications infrastructure or basic literacy.

Which basically sounds close enough to Byzantium to be worth applying for. Let me know if anyone has interest.

Some side questions for the tech folks:
    Does Byzantium work across non WiFi IP stacks?  Would it be reasonable to attach it to Packet Radio over HAM radio?


Sincerely,
Urbanus

Andrew Donovan-Shead

unread,
Jan 22, 2013, 9:39:12 PM1/22/13
to Byza...@hacdc.org
Packet Radio via HAM radio should work. To my mind it would be another gateway in and out of the Byzantium mesh. It would be a wonderful range extender. At a quick glance, it shouldn't require more than connecting the computer wired Ethernet or USB link or whatever to the Packet Radio bridge. Byzantium should see it as an open connection to the Internet and connect the mesh automatically.

Any number of narrow-area Byzantium meshes could be interconnected over a wide area by Packet Radio. Bandwidth should increase proportional to the number of HAMs providing Packet Radio connections, limited by the number of RF channels available.

I could look into your idea and put together a system block diagram illustrating the concept, if you're interested.
--
You received this message because you are subscribed to the Google Groups "Project Byzantium (Emergency Mesh Networking)" group.
To view this discussion on the web visit https://groups.google.com/a/hacdc.org/d/msg/Byzantium/-/Gz0wUKNBphsJ.
To post to this group, send email to Byza...@hacdc.org.
To unsubscribe from this group, send email to Byzantium+...@hacdc.org.
For more options, visit this group at http://groups.google.com/a/hacdc.org/group/Byzantium/?hl=en.

Gary Belvin

unread,
Jan 24, 2013, 8:53:42 PM1/24/13
to Byza...@hacdc.org
Block diagrams would be awesome.
For full disclosure, I have not purchased a Ham Radio yet (working on it!) 
I do know that packet radio could carry low bandwidth data such as text messages, and with a repeater or so, it would be an awesome way to <actually> get data in and out of country. (Only field tests will actually tell)

Cheers,
Gary

Gary Belvin
_____________________________________________________________________

cell: 410-541-6123

"Before a man can do things there must be things he will not do."  -Mencius

haxwithaxe

unread,
Jan 25, 2013, 11:13:39 AM1/25/13
to Project Byzantium (Emergency Mesh Networking)

uhf and vhf can handle reasonable amounts of data. hf (the stuff that can reach around the planet when things go right) can handle about 1200 baud when operating within (US) regulations. which isn't going to be enough to keep a normal tcp session going from what i understand. uhf and vhf can do a lot better than wifi in terms of range but not enough to get you from major city to major city on the east coast and have any kind of reasonable speed.
that said there are people working on mesh over ham radio and the protocols byzantium uses only care about layer 3 of the osi stack so if they can get ipv4 or ipv6 then they will be happy :P
you can always roll your own layers 1 and 2 and present the computer with a layer 3 that it knows how to handle as well. things like soundmodem (soundcard as a modem) make a network device that the computer can treat like a normal ethX device. we used soundmodem to connect 2 machines over frs radios which even though we were apparently doing it wrong we still managed to start an ssh session over the link (illegal to do without a ham license apparently btw).
the ham community has an influential segment that doesn't believe that ham radio should be used for general purpose ip-like communication (the amateur part of amateur radio is the sticking point afaik) and the packet radio implementations reflect that. APRS is intended for position tracking and is thus heavily geared toward small text messages. the same bandwidth can handle a lot more data but it isn't taken advantage of due to the limited use cases of APRS.
there are projects doing more general purpose digital radio stuff but they aren't as popular as APRS.

buzz

unread,
Jan 25, 2013, 11:24:59 AM1/25/13
to Byza...@hacdc.org
> we used soundmodem to connect 2 machines over frs radios which even though we were apparently doing it wrong we still managed to start an ssh session over the link (illegal to do without a ham license apparently btw).

95.193 (FRS Rule 3) Types of communications.

(a) You may use an FRS unit to conduct two-way voice communications with another person. You may use an FRS unit to transmit one-way voice or non-voice communications only to establish communications with another person, send an emergency message, provide traveler assistance, provide location information, transmit a brief test message, make a voice page, or to conduct a brief test.

(b) Non-voice communcations.

(1) The FRS unit may transmit tones to make contact or to continue communications with a particular FRS unit. If the tone is audible (more than 300 Hertz), it must last no longer than 15 seconds at one time. If the tone is subaudible (300 Hertz or less), it may be transmitted continuously only while you are talking.

(2) The FRS unit may transmit digital data containing location information, or requesting location information from one or more other FRS units, or containing a brief text message to another specific FRS unit. Digital data transmissions must be initiated by a manual action or command of a user, except that an FRS unit receiving an interrogation request may automatically respond with its location. Digital data transmissions shall not exceed one second, and shall be limited to no more than one digital transmission within a thirty-second period, except that an FRS unit may automatically respond to more than one interrogation request received within a thirty-second period.

(c) You must not use an FRS unit in connection with any activity which is against federal, state or local law.

(d) You must, at all times and on all channels, give priority to emergency communication messages concerning the immediate safety of life or the immediate protection of property.

(e) No FRS unit may be interconnected to the public switched network.

Bill Vodall

unread,
Jan 25, 2013, 11:30:38 AM1/25/13
to Byza...@hacdc.org
On Fri, Jan 25, 2013 at 8:24 AM, buzz <bk...@ieee.org> wrote:
>> we used soundmodem to connect 2 machines over frs radios which even though
>> we were apparently doing it wrong we still managed to start an ssh session
>> over the link (illegal to do without a ham license apparently btw).
>
> 95.193 (FRS Rule 3) Types of communications.

FRS is generally outside the HAM bands so an Amateur License won't
help... If the radio's were in the HAM band (generally 420 MHz to
450 MHz) then the SSH circuit would encrypt the data flow and that is
also forbidden. Fortunately the High Performance SSH project brought
back the 'none' cipher option for SSH and that would be allowed.

73
Bill - WA7NWP

The Doctor

unread,
Jan 25, 2013, 8:57:46 PM1/25/13
to Byza...@hacdc.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/22/2013 08:36 PM, Urbanus Z wrote:

> There's a tech challenge <http://thetechchallenge.org/#!inflow>
> from www.humanityunited.org <http://www.humanityunited.org>. and
> USAID opening in Feburary that a few of you might be interested in.
> Here's the problem description.:
...
> Which basically sounds close enough to Byzantium to be worth
> applying for. Let me know if anyone has interest.

I'm definitely interested.

> Does Byzantium work across non WiFi IP stacks? Would it be
> reasonable to attach it to Packet Radio over HAM radio?

If it will run TCP/IP, Byzantium can route traffic over it.

- --
The Doctor [412/724/301/703] [ZS|Media]
Developer, Project Byzantium: http://project-byzantium.org/

PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1
WWW: https://drwho.virtadpt.net/

"I am not a metamorph!" --Shane Gooseman, _Galaxy Rangers_

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlEDOBkACgkQO9j/K4B7F8EF0gCaAjWs3p/mCQSWcv8GB0gASuHD
PwkAmgKqy/P5rDCtSoH/z++GRlcrhCqo
=d3UD
-----END PGP SIGNATURE-----

Gary Belvin

unread,
Jan 25, 2013, 10:26:19 PM1/25/13
to Byza...@hacdc.org
Does Byzantium offer any delayed tolerant networking protocols?
Live TCP connections over long distances would not be a good idea, but I could see batched twitter updates or the like working.

-U

Gary Belvin
_____________________________________________________________________

cell: 410-541-6123


Continually call others
to something great, not to being great

catskil...@gmail.com

unread,
Jan 25, 2013, 11:22:35 PM1/25/13
to Byza...@hacdc.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/25/2013 10:26 PM, Gary Belvin wrote:
> Does Byzantium offer any delayed tolerant networking protocols?
> Live TCP connections over long distances would not be a good idea,
> but I could see batched twitter updates or the like working.
>

Netnews over uucp ? ;-)

- --- Marina

> -U
>
> *Gary Belvin*
> _____________________________________________________________________
>
>
cell: 410-541-6123*
> Continually call others *to something great, not to being *great*
>>> *Gary Belvin*
>>> _____________________________________________________________________
>>>
>>>
cell: 410-541-612*3*
>>>
>>> ***"Before a man can do things there must be things he will not
>>> do." -Mencius *
>>>
>>>
>>> On Tue, Jan 22, 2013 at 9:39 PM, Andrew Donovan-Shead <
>>> aw...@cloistral.net> wrote:
>>>
>>>> Packet Radio via HAM radio should work. To my mind it would
>>>> be another gateway in and out of the Byzantium mesh. It would
>>>> be a wonderful range extender. At a quick glance, it
>>>> shouldn't require more than connecting the computer wired
>>>> Ethernet or USB link or whatever to the Packet Radio bridge.
>>>> Byzantium should see it as an open connection to the Internet
>>>> and connect the mesh automatically.
>>>>
>>>> Any number of narrow-area Byzantium meshes could be
>>>> interconnected over a wide area by Packet Radio. Bandwidth
>>>> should increase proportional to the number of HAMs providing
>>>> Packet Radio connections, limited by the number of RF
>>>> channels available.
>>>>
>>>> I could look into your idea and put together a system block
>>>> diagram illustrating the concept, if you're interested.
>>>>
>>>>
>>>> On 01/22/2013 07:36 PM, Urbanus Z wrote:
>>>>
>>>> Greetings,
>>>>
>>>> It's been a while since I've checked back in with HacDc, and
>>>> I'm impressed with the progress Byzantium has made.
>>>>
>>>> There's a tech challenge
>>>> <http://thetechchallenge.org/#%21inflow> from
>>>> www.humanityunited.org. and USAID opening in Feburary that a
>>>> few of you might be interested in. Here's the problem
>>>> description.:
>>>>
>>>> During acute crises, vulnerable populations are often *cut
>>>> off from
>>>>> critical information* and *have limited, if any, ability to
>>>>> communicate * inside or outside of their communities. While
>>>>> there are a number of existing efforts aimed at *improving
>>>>> information flow* in these contexts, many focus on the
>>>>> *outflow of information* from communities or rely too
>>>>> heavily on *existing communications infrastructure* or
>>>>> *basic literacy*.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJRA1oLAAoJEEy/Yrjnmw6c1uAQALEHbxQbewWGIq66/t5jHzKR
4hIDxy5DN6S0EZDIQLIX6Kk5XqaAktKoTn0W+TaD7IzP5baeKGxBKceeqgfRUQ7L
AzH6Z0HlFAUFQ0MPHw3HTnEPZdRupygsutJWT/YuhtnmQzU4DV7zI+vFlwPfu2CP
mUuf81HKhAVtdvzAy4qlL1XY2jKSpSAHfv2zzuE/cwk7K4TA0PCrgtsl/bD5Pstu
LYB8w7j0oxJsFVC6jT+zXYx3j5i7f1HZRzcyKNUj4h1axuEZ16PsmMjxQEd+YDmu
jzgtX9JneJSFL0EuLpZ8EiJpQVzRXXkGAoqcHmoeMKUFB+9hqVTQSDQZK2g9o/dI
49cAbthVJK900+2W0HtqOBYL8mwCIUF0V3nqdipD83VjAL3hpBj87Amv5Vkm52yF
hZsHza3L/jCWoLM2Bx4EVDL/x0K3C6r7UP6JKufIVl+PE5CAR688Zn7q/vYEf4C5
ZkGdHZzeQN5tI4tHq6HBo9c2XF2m2m7rJa3EgbYi6V/8u2ONFBg0D+A1GIZTOwZK
DloKsbDIUJE4O0zebHPWhWqiE8595EbeMlGxTEDmabPKHsUwx7agK9Eh3R9xzbwu
OMgEhm1z38+d/ADBqP6tR0QJXWpErUGUp7hiN8bmxPyGOmTjrjDOc1QDqCwqoQ/5
xAiOKWrymy0CiHPHgyCO
=ZUaB
-----END PGP SIGNATURE-----

The Doctor

unread,
Jan 26, 2013, 2:42:54 PM1/26/13
to Byza...@hacdc.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/25/2013 10:26 PM, Gary Belvin wrote:


That is something that we are researching for our next development
sprint, and the next release of Byzantium Linux (probably v0.4a, maybe
beta, we don't know yet).

There are a couple of ways that we can go about it. We are
investigating using the FIDOnet protocol
(https://en.wikipedia.org/wiki/FidoNet), which is designed to solve
this very problem (synchronizing arbitrary datastores containing
messages across unreliable links). There are several implementations
for Linux that we could use, and in fact there is a derivative of the
distro that we're building on top of which is designed specifically
for setting up a FIDOnet BBS.

There are other ways of implementing DTN, too. There is a protocol
called EJTP (Encrypted JSON Transport Protocol)
(https://github.com/campadrenalin/EJTP-lib-python) which is a Python
library for taking data from arbitrary sources, serializing it as JSON
documents, storing them to arbitrary media, and reversing the process
on the other end. It can be used for TCP and UDP traffic, HTTP
traffic, or just about anything else that you can write conversion
code for. A few of us wonder if we couldn't use it in conjunctionwith
CouchDB to synchronize nodes via removable storage.

There are other DTN protocols out there but connectivity at the 'space
is a bit spotty right now and I can't get to my notes.

The force that dictates which DTN protocol we use, and how it will be
used is the network apps that Byzantium Linux will include at that
time. We'll have to write conversion code to take dumps of data and
run them through the DTN software, and we'll have to write conversion
code that takes the DTN packets, unserializes them, and then
synchronizes the apps' datastores. This will have to be app-specific,
and it would be good to make the right design choices up front.

- --
The Doctor [412/724/301/703] [ZS|Media]
Developer, Project Byzantium: http://project-byzantium.org/

PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1
WWW: https://drwho.virtadpt.net/

How much polka is in YOUR soul?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlEEMb4ACgkQO9j/K4B7F8EbGgCgg+pJH9p9HG0EsxvelmH5zS2g
61gAn24/KaE0ANmiBvB+nrThyKN39Yk9
=8IGk
-----END PGP SIGNATURE-----

The Doctor

unread,
Jan 26, 2013, 2:44:53 PM1/26/13
to Byza...@hacdc.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/25/2013 11:22 PM, catskil...@gmail.com wrote:

> Netnews over uucp ? ;-)

That would certainly work. We should try it.

- --
The Doctor [412/724/301/703] [ZS|Media]
Developer, Project Byzantium: http://project-byzantium.org/

PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1
WWW: https://drwho.virtadpt.net/

"A distant moon of a distant star." --Captain Jack Harkness

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlEEMjUACgkQO9j/K4B7F8HXcACfWm54iS719C0qw3s+k/QFOT+Z
niIAoI9fv44Tl0mQJwi7imicCM6tjr1p
=7/V0
-----END PGP SIGNATURE-----

Andrew Donovan-Shead

unread,
Jan 26, 2013, 11:00:14 PM1/26/13
to Byza...@hacdc.org
See the file attached to this message for an overview of the system.
Byzantium-Ad-Hoc-Mesh-Overview.pdf
Reply all
Reply to author
Forward
0 new messages