[Commotion-dev] SPAN Apps Published to Google Play

Tue Jan 22 21:04:35 UTC 2013

Hello Teco,

On Wed, Jan 23, 2013 at 12:16 AM, Teco Boot <teco at inf-net.nl> wrote:
> Hi Paul,
>
> Op 22 jan. 2013, om 11:53 heeft Paul Gardner-Stephen het volgende geschreven:
>
>> Hello Teco,
>>
>> On Tue, Jan 22, 2013 at 5:06 PM, Teco Boot <teco at inf-net.nl> wrote:
>>> Hi Paul,
>>>
>>> Using an external radio for longer range ad hoc connections makes
>>> sense. Question is how to connect the smartphone to such device. I'm
>>> not so sure WiFi AP is the right solution. The helper acting as AP
>>> would be power hungry, where the smartphone as station can use the
>>> power saving modes. Maybe bluetooth tethering can help.
>>
>> But remember that the helper device can actually have a larger battery.
> Yes. So can the smartphone. I planned OTG with power Y-cable. With stock
> CM10 on Galaxy Nexus, phone doesn't charge, because lousy implementation
> of OTG. I need USB host for attaching satphone and/or AUX radio.

Yes, it is possible to come up with solutions that work with
particular handsets, but one of the attractions for us is that the
helper device solves the problem for practically all smart-phones in
one go.

>> Also, AP mode is still less power hungry than ad-hoc mode on most hardware.
>> We would need to investigate all this more thoroughly.
>>
>>> I still like the wlan ad hoc mode, for short range / high data rate.
>>
>> As do we.
>>
>>> Energy consumption shouldn't be a problem when the MANET protocol and
>>> beaconing is quit. Maybe take the reactive approach.
>>
>> Actually, ad-hoc consumes almost as much power listening as it does
>> transmitting, due to the waveforms used in WiFi.
> Could be device dependent or method used (wpa_supplicant or iwconfig).
> I'll test and let you know my findings.

Do check it out, but my understanding is that the 0.3W that an idle
ad-hoc connection consumes is more or less unavoidable.  What is
optimisable is the next 0.3W used by keeping the CPU awake to do mesh
routing etc.

>>
>>> Do you use the RF22 mesh protocol?
>>
>> No. We are creating a new protocol that we call "multi-threaded radio"
>> and is designed with the frequency hopping requirements of the ISM915
>> band in mind.
>>
>> Once synchronised (which has some interesting but solvable
>> challenges), then the radios will follow the same sequence of channels
>> to listen on, with a channel dwell time of 1ms - 2ms, and a bit rate
>> of 128kbit.
>>
>> Each radio will only listen on 1/4 of the slots, reducing RX duty
>> cycle to 25%, reducing energy consumption.  Even when listening,
>> energy consumption will be much lower than WiFi due to the simpler
>> waveform decoding.
>>
>> When a radio hears a packet for itself, it keeps listening on the same
>> channel to receive the whole packet.  This will likely be ~10s of ms.
>> Meanwhile, the other nodes will have hopped along to other channels to
>> listen if there is any traffic for them.  Thus we can get 128kbit on
>> each channel, with many channels carrying traffic at the same time.
>> Or at least that is the theory, we will find out when we get to
>> implement it :)
> Interesting!

We think so, too :)

> I wonder if you have planned to integrate the L3 routing functions, e.g.
> running olsr or batman on this somewhat narrow-band radio. As we have
> concerns on battery live, while having little multicast/broadast and few
> flows, a reactive protocol like AODV would be candidate. On the other
> hand, with multiple gateways to the Internet, reactive protocols have
> their challenges. That is why I still focus on olsrd. We will finish
> the extended smartgateway in a few weeks (to be released in olsrd 0.6.7,
> in couple of months).

In principle it should be possible to run OLSRd or similar over the
long range mesh, although the limited bandwidth would not be very nice
for IP-based applications.  The concept has really been designed with
MDP, VoMP and Rhizome in mind, that can tolerate low-bandwidth
situations.

But back to OLSRd, that should not be a big problem, provided that you
can reduce the heart rate from the typical 1Hz - 2Hz to, say, 0.01Hz -
0.05Hz, which should be possible because of the 16x - 30x range
increase, which means that nodes should move in and out of range 16x -
30x more slowly.  In fact, node transit times may in fact average more
than 16x - 30x for a variety of reasons.

Really the biggest challenge to carrying IP traffic over our
long-range-mesh concept is that it will not appear to the OS as a
network interface -- the network functions will be provided solely as
part of the Serval Overlay Mesh functions of the Serval Daemon.  Thus
you would need a TCP to MDP tunnel/socks-proxy type thing to
encapsulate the IP packets.

Paul.

> Teco
>
>
>> Paul.
>>
>>> Teco
>>>
>>>
>>> Op 21 jan. 2013, om 21:41 heeft Paul Gardner-Stephen het volgende geschreven:
>>>
>>>> Hi,
>>>>
>>>> As CyanogenMod seems to be using github these days, it would make it
>>>> much easier to implement something like this.  It would require some
>>>> committed developer resource to progressively target various devices.
>>>> I fear that it might be a perpetual game of catch up to make the ROMs,
>>>> and there is a question of cost-effectiveness.
>>>>
>>>> This is why Serval has been thinking for a while now about making a
>>>> mesh helper device instead.  Basically, people keep using their
>>>> existing android (or other platform phone), and it associates to the
>>>> mesh helper as a WiFi client, and they run only a "normal" non-root
>>>> application on their phone.
>>>>
>>>> The mesh helper simultaneously runs a WiFi AP and ad-hoc interface,
>>>> thus offloading the ad-hoc WiFi from the phone where support is hard,
>>>> but also reducing the power requirements for the user's phone, because
>>>> client mode is more energy efficient than ad-hoc mode.  The helper
>>>> device would itself be mobile-phone hardware derived, as this is the
>>>> cheapest way to make it.
>>>>
>>>> Another nice thing about the helper device is that one helper can be
>>>> shared by a number of people in its range. It can also serve up the
>>>> APKs for the various mesh applications that people might want to use.
>>>>
>>>> We are also planning that the mesh helper device should have an
>>>> Arduino or similar built in, so that we can add arbitrary RF front
>>>> ends to allow long-range mesh communications.  For example in
>>>> countries where the ISM 915MHz band is available (USA, AU, NZ, ZA,
>>>> Israel and a number of others, but not Europe), we can use a HopeRF
>>>> RFM23BP to transmit at 1W with a simple wave form at 128kbit/sec,
>>>> gaining approximately 25db -- 29db over 2.4GHz WiFi, resulting in 16x
>>>> - 30x range compared with WiFi.
>>>>
>>>> We have some initial funding from NLnet Foundation to prototype this
>>>> using Draginos, and have made some progress, and once we have a few
>>>> other blocking tasks out the way, will begin to work on integrating an
>>>> RFM23BP as a 915MHz frontend.  See the following URL for some
>>>> information on what we have been doing and plan to do over the next
>>>> few months:
>>>>
>>>> http://developer.servalproject.org/dokuwiki/doku.php?id=content:meshhelper:main_page
>>>>
>>>> Paul.
>>>>
>>>> On Tue, Jan 22, 2013 at 4:38 AM, stoker <mistr.stoker at gmail.com> wrote:
>>>>> Hi Teco,
>>>>>
>>>>> The Manet Manager app has an integrated Manet Service that lets other
>>>>> apps configure the network through an API call. Another app can create
>>>>> a ManetConfig object, set all of the parameters, and pass it down to
>>>>> the service. It's optional. A user can also configure the mesh through
>>>>> the Manet Manager UI.
>>>>>
>>>>> I understand your use of scripts. Under the hood both the Manet
>>>>> Manager and Serval Mesh apps use edify scripts to detect devices and
>>>>> configure them for ad-hoc mode. The apps execute the edify scripts in
>>>>> a native process. The edify scripts provide some additional Android
>>>>> functions versus shell scripts, such as loading/unloading the wifi
>>>>> module. When the Manet Manager needs to execute other native commands
>>>>> with elevated privileges (like starting olsrd) it writes those
>>>>> commands to a script on the fly and executes the script with su.
>>>>>
>>>>> Creating a set of scripts and limiting their access to the Manet
>>>>> Manager / Serval Mesh app in a custom ROM is an interesting idea.
>>>>> We've thought about creating a ROM where the Manet Manager would be a
>>>>> system app and therefore have advanced privileges and not be randomly
>>>>> killed off by the performance manager.
>>>>>
>>>>> I highly encourage updating / branching CyanogenMod. Certain devices
>>>>> require certain modifications to enable wext support and enable ad-hoc
>>>>> mode. At this time my team doesn't have a large enough developer base
>>>>> to make custom modifications to each CyanogenMod kernel, so it's a
>>>>> task we haven't addressed. Maybe it would be best to select one device
>>>>> at first and go from there? If that's the case, I support choosing the
>>>>> Galaxy Nexus or Nexus 7.
>>>>>
>>>>> - stoker
>>>>>
>>>>>
>>>>> On Mon, Jan 21, 2013 at 5:09 AM, Teco Boot <teco at inf-net.nl> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I would love a flexible ad hoc / manet management app. And have
>>>>>> integrated network setting functions in "user apps" as optional,
>>>>>> or taken out there.
>>>>>>
>>>>>> I use scripts myself, where I configure and start/stop what I need.
>>>>>> I have a wlan nic settings script, a script for olsrd, for openvpn
>>>>>> and iptables. I expect more to come (e.g.DNS).
>>>>>> Reasoning behind scripts: in Linux, daemons are managed with scripts,
>>>>>> this provides custom modifications.
>>>>>> What about having scripts for each sub-task and an app as interface
>>>>>> to the scripts?
>>>>>>
>>>>>> Another thought for longer term: have a non-rooted custom rom with
>>>>>> all of this. Scripts have root privilege, needed for for example
>>>>>> managing routing table.
>>>>>>
>>>>>> I use Galaxy Nexus, adjusted CM10. I have ipip enabled (for olsrd
>>>>>> smartgateway). The bmf plugin is fixed for tuntap (to be included
>>>>>> in next olsrd version).
>>>>>> Shall we try to update CM10, with wext and ipip?
>>>>>>
>>>>>> Teco
>>>>>>
>>>>>>
>>>>>> Op 20 jan. 2013, om 23:03 heeft Paul Gardner-Stephen het volgende geschreven:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> On Mon, Jan 21, 2013 at 7:36 AM, stoker <mistr.stoker at gmail.com> wrote:
>>>>>>>> Hi Paul,
>>>>>>>>
>>>>>>>> We look forward to trying out the Serval Mesh app update. The current
>>>>>>>> app supports a number of features, including text chat, placing calls,
>>>>>>>> sharing files, and mapping. Does your team have plans to separate each
>>>>>>>> of those features out into separate app? I believe that will make
>>>>>>>> matters simpler from a developer's as well as from a user's
>>>>>>>> perspective.
>>>>>>>
>>>>>>> Maps is already a separate app for this reason.  However, the calling,
>>>>>>> text messaging and file exchange are all based on the core Serval
>>>>>>> protocols, and past experience has shown that having (at least the
>>>>>>> core function of) those in separate apps that require installation is
>>>>>>> disadvantageous, because they are naturally closely coupled, calls and
>>>>>>> MeshMS in particular.  The Rhizome protocol that facilitates the file
>>>>>>> sharing is used under the hood to power MeshMS and software updates as
>>>>>>> well as regular file exchange.
>>>>>>>
>>>>>>>> Thanks for pointing us to your handset detection and support code.
>>>>>>>> Since both of our projects are using the edify approach, I believe it
>>>>>>>> won't be difficult to integrate our code. However, I believe that it
>>>>>>>> would be best for the Commotion team to integrate all of our
>>>>>>>> mesh-enabling code into their Mesh Tether app.
>>>>>>>>
>>>>>>>> As I see it, there are three kinds of devices that the teams are
>>>>>>>> primarily targeting:
>>>>>>>> - devices which support wext and can be put into ad-hoc mode without
>>>>>>>> kernel mods (Serval)
>>>>>>>> - devices which don't support wext and can be put into ad-hoc mode
>>>>>>>> without kernel mods (Commotion)
>>>>>>>> - devices which require kernel mods (SPAN)
>>>>>>>>
>>>>>>>> I believe we'd all like to see one app which can support all three. I
>>>>>>>> believe that the Commotion team is best suited for the task
>>>>>>>> considering their focus and large developer base. More developers
>>>>>>>> means a wider array of devices to test on and more long-term support.
>>>>>>>
>>>>>>> I totally agree. We would love to see a single app that just provides
>>>>>>> ad-hoc wifi and the related functions, and has wide support as you
>>>>>>> envisage.
>>>>>>>
>>>>>>> Paul.
>>>>>>>
>>>>>>>> - stoker
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Jan 19, 2013 at 3:44 PM, Paul Gardner-Stephen
>>>>>>>> <paul at servalproject.org> wrote:
>>>>>>>>> Hi Stoker,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sat, Jan 19, 2013 at 8:39 AM, stoker <mistr.stoker at gmail.com> wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> For those who want to get geeky, I just posted three apps to Google
>>>>>>>>>> Play: https://play.google.com/store/apps/developer?id=stoker
>>>>>>>>>>
>>>>>>>>>> Try 'em out.
>>>>>>>>>>
>>>>>>>>>> Both the Manet Visualizer and Manet Voice Chat apps make use of a
>>>>>>>>>> common API for interacting with the Manet Service that comes bundled
>>>>>>>>>> with the Manet Manager app. I believe that the idea of a common API
>>>>>>>>>> for making use of the mesh platform may be one of the aspects that
>>>>>>>>>> sets SPAN apart from other projects.
>>>>>>>>>
>>>>>>>>> This is great.
>>>>>>>>>
>>>>>>>>> The Serval Mesh app (which is about to get a HEAVY update) also offers
>>>>>>>>> some APIs, but probably mostly in complementary areas to your Manet
>>>>>>>>> Manager.  We will endeavour to take a look at your apps soon.
>>>>>>>>>
>>>>>>>>> With regard to handset support, it might be worth taking a look at our
>>>>>>>>> handset detection and support code
>>>>>>>>> (https://github.com/servalproject/batphone), as we have already built
>>>>>>>>> support for a number of other handsets, and an automatic guessing
>>>>>>>>> engine that can build support scripts for some new handsets it
>>>>>>>>> encounters.  It's not perfect, but it may be useful to incorporate
>>>>>>>>> into Manet Manager.
>>>>>>>>>
>>>>>>>>> Paul.
>>>>>>>>>
>>>>>>>>>> - stoker
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Commotion-dev mailing list
>>>>>>>>>> Commotion-dev at lists.chambana.net
>>>>>>>>>> https://lists.chambana.net/mailman/listinfo/commotion-dev
>>>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Commotion-dev mailing list
>>>>>>> Commotion-dev at lists.chambana.net
>>>>>>> https://lists.chambana.net/mailman/listinfo/commotion-dev
>>>>>>>
>>>>>>
>>>
>