[Commotion-dev] SPAN Apps Published to Google Play

Tue Jan 22 06:36:26 UTC 2013

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.

I still like the wlan ad hoc mode, for short range / high data rate. 
Energy consumption shouldn't be a problem when the MANET protocol and 
beaconing is quit. Maybe take the reactive approach. Do you use the 
RF22 mesh protocol?

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
>>>> 
>>> 