[Commotion-dev] SPAN Apps Published to Google Play

Teco Boot teco at inf-net.nl
Tue Jan 22 13:46:30 UTC 2013 

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.

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

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

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

More information about the Commotion-dev mailing list