Soliciting input into MP2.0 design

[Song, Stephen]

Hi all,

I am going to use UserVoice to solicit public input into the MP2.0 design.

https://villagetelco.uservoice.com/forums/20556-mesh-potato-2-0-design-and-features

Could I ask you to take a look at the wording and see if I am getting
the message across clearly? Anything you would add or change?

Thanks... Steve

[T Gillett]

Hi Steve
Looks good.
Small typo in second para.
"... plans are..."
Regards
Terry

--
You received this message because you are subscribed to the Google Groups "village-telco-dev" group.
To post to this group, send email to village-...@googlegroups.com.
To unsubscribe from this group, send email to village-telco-...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Pieter van Zyl]

Stephen can you possible indicate with how much the extra ethernet and FXS ports will increase the unit price respectively?

If the cost for these are minimal then they should be standard I would think !?

Pieter van Zyl

South Africa

[T Gillett]

Hi Pieter

Another approach to this might be to allow for expansion of a base unit as far as possible, without increasing the base cost that all users have to pay for the unit. What I mean is to have one PCB design that can be populated in various combinations.

A good example is the extra Ethernet you mentioned. I'm sure many MP01 installations don't use the Ethernet connector at all once the unit is installed on a mast, so having a second one is a real cost overhead. But there are use cases where a second port would be really useful.

If it were possible, in some cost effective way, to provision one port in the base unit, but allow for a second to be provisioned, either by an end user or by way of a special manufacturing run, without the really expensive exercise of producing a new PCB, we might satisfy both requirements.

The PCB is the most expensive item in the unit, taking into account the design costs. The additional cost of having a PCB with some unpopulated areas for the base production run should be minimal, but would allow for the additional facilities to be added as required.

This approach might be also be used for things like the USB connectors, as well as Flash and RAM memory sizes.

Regards
Terry

--

[Andrés Leopoldo Pacheco Sanfuentes]

Excellent idea, Terry! This would make the design spec, in C++ lingo, a "base class," or "superclass," surely not "abstract" nor necessarily "virtual," that would accommodate different "instantiations," or specializations/customizations depending on the application.

[Steve Song]

Great questions and comments all. Modularity is definitely a design
goal. The question for me is what does the base class or basic Mesh
Potato look like.

I think there is a basic equation for all features that looks like
"usefulness" divide by "manufacturing cost" = "value".

We don't know all the costs yet and we'll share as much information as
possible as we gather it but here are some ways in which that might
play out.

Dual ethernet ports. The AR9331 has support for up to 4 ethernet
ports built in. I agree with Terry's point about the marginal utility
of a second ethernet port. However, if the build-out cost of a second
ethernet port is something on the order of $.50, is this something we
would like to see in the base design? Don't get me wrong, $.50 is not
nothing. It doesn't take too many $.50 add-ons to seriously affect
the BoM. What we'd like to hear from the community is your perception
of the utility of a second ethernet port.

Dual FXS ports. We are currently exploring the feasibility and cost
of this. It is not clear yet whether the AR9331 easily supports a
dual FXS port option. There are now dedicated chips for both single
and dual FXS port support. Have a look at
http://www.silabs.com/products/voice/Pages/default.aspx We don't know
the cost differential yet either but we should know soon. The
question for the community is how much would you value a dual versus
single FXS Mesh Potato base model. Based on feedback I have had to
date, this appears to me to be a fairly high value option. Consider
that it might effectively halve the cost of deployment for an urban
village telco. BUT... this assumption on my part needs to be
validated by the community.

Audio out. Another feature of the AR9331 is an audio interface.
Would having a miniature audio jack be a high value proposition? For
a speaker phone option or perhaps a mesh-WiFi streaming radio station.
Perhaps that is a better candidate for the modularity approach for
which someone might design and produce an Audio Potato.

USB support. For me this is a given but I've been wrong before.
Assuming we do have it, should it be internally mountable so whatever
is plugged into the USB port is protected by the weather-proof
enclosure or should it be mounted more typically where the other ports
are at the bottom of the unit?

The list goes on. What we are trying to establish with the Uservoice
site (https://villagetelco.uservoice.com/forums/20556-mesh-potato-2-0-design-and-features)
is where the highest value is placed by the community for a base
model, mass production Mesh Potato. As such we really need both your
new ideas and your votes on the features presented.

Once we have a basic production of a few hundred units, we plan to
launch a crowd-funded (via IndieGoGo or similar) campaign for a much
larger production run that will hopefully allow us to realise larger
economies of scale than we have been able to achieve with the MP01.

You have our commitment that the design will be open to anyone who
would like to spin-off their own version.

Best... Steve



On 28 September 2012 07:40, Andrés Leopoldo Pacheco Sanfuentes

Steve Song
+1 902 529 0046
+27 83 482 2088 (SMS only)
http://villagetelco.org

[Glen Steedman]

802.3af PoE to power the MP would be a nice addition. but im guessing if there is any 802.3af with the chipset it would be to provide power to the lan port rather then receiving powering.

Im just thinking its going to be cheaper at some point to use a cheap voip phone, then buy an analogue fxs phone, if you dont need to be more then 90Meters away from the MP. prices keep tumbling.  Maybe we should check this post in a years time and see if its cheaper yet again.

you could in theory pickup a AT610P or GXP1405 (~50$) which would give you callerid, enhance provisioning...

not sure what the development cost is going to be to add callerid and a few other features to the existing fxs port, or if that is planned ? 

or go the deluxe route with a 8port switch, with 4ports PoE for (~$50) http://www.amazon.com/TP-Link-TL-SF1008P-8-Port-Desktop-Switch/dp/B003CFATT2

--
Cheers, Glen

[Song, Stephen]

Hi Glen,

On 28 September 2012 10:45, Glen Steedman <gste...@gmail.com> wrote:
> 802.3af PoE to power the MP would be a nice addition. but im guessing if
> there is any 802.3af with the chipset it would be to provide power to the
> lan port rather then receiving powering.

I think remote powering of the MP is essential. Terry proposed
(https://villagetelco.uservoice.com/forums/20556-mesh-potato-2-0-design-and-features/suggestions/3210539-single-cat-5-cable)
a single CAT5 cable to carry power,data, and voice. Personally I
think this is the route to go. Standard CAT5 cables could then be
used and a VT could be built without a crimper.

> Im just thinking its going to be cheaper at some point to use a cheap voip
> phone, then buy an analogue fxs phone, if you dont need to be more then
> 90Meters away from the MP. prices keep tumbling. Maybe we should check this
> post in a years time and see if its cheaper yet again.

This is a fundamental question. Is there still a need for an AP w/ an
FXS port? Otherwise why not just a Pico/Nano/Loco device and a SIP
phone. Or as someone has proposed
(https://villagetelco.uservoice.com/forums/20556-mesh-potato-2-0-design-and-features/suggestions/3211656-use-a-standard-router-e-g-tp-link-703n-and-mesh)
use an AP with USB port and plug in a USB phone.

My gut feel is that even if SIP phones get really cheap they are
unlikely to be as rugged or basic as a POTs phone. I am not
necessarily talking about a wired phone either. I use a pair of
Panasonic DECT wireless phones with my Mesh Potato at home which works
amazingly well.

My personal take is that the more likely replacement route for the MP
will be via WiFi-enabled smartphones. We need more input from
everyone on this though.

> you could in theory pickup a AT610P or GXP1405 (~50$) which would give you
> callerid, enhance provisioning...
> not sure what the development cost is going to be to add callerid and a few
> other features to the existing fxs port, or if that is planned ?

My impression is that the dedicated FXS chipsets have very robust
support for all modern phone features

http://www.silabs.com/products/voice/slic/Pages/Si3217xProSLIC.aspx

Cheers... Steve

Steve Song
+1 902 529 0046
+27 83 482 2088 (SMS only)

http://manypossibilities.net
http://villagetelco.org

[Glen Steedman]

Gday Steve

On 29 September 2012 00:24, Song, Stephen <stephe...@gmail.com> wrote:

Hi Glen,

On 28 September 2012 10:45, Glen Steedman <gste...@gmail.com> wrote:
> 802.3af PoE to power the MP would be a nice addition. but im guessing if
> there is any 802.3af with the chipset it would be to provide power to the
> lan port rather then receiving powering.

I think remote powering of the MP is essential.  Terry proposed
(https://villagetelco.uservoice.com/forums/20556-mesh-potato-2-0-design-and-features/suggestions/3210539-single-cat-5-cable)
a single CAT5 cable to carry power,data, and voice.  Personally I
think this is the route to go.  Standard CAT5 cables could then be
used and a VT could be built without a crimper.

Yep i will be voting for this one, Single rj45 interface that does power,data,voice would make it very plug and play.

802.3af would be nice to have as an option to power the MP, but i doubt a 802.3af injector is as cheap as the existing 12v on the spare pairs, with the PoTL. 

 

> Im just thinking its going to be cheaper at some point to use a cheap voip
> phone, then buy an analogue fxs phone, if you dont need to be more then
> 90Meters away from the MP. prices keep tumbling.  Maybe we should check this
> post in a years time and see if its cheaper yet again.

This is a fundamental question.  Is there still a need for an AP w/ an
FXS port?  Otherwise why not just a Pico/Nano/Loco device and a SIP
phone.  Or as someone has proposed
(https://villagetelco.uservoice.com/forums/20556-mesh-potato-2-0-design-and-features/suggestions/3211656-use-a-standard-router-e-g-tp-link-703n-and-mesh)
use an AP with USB port and plug in a USB phone.

Sorry, i should of put it in to context, that for more then 1 phone it might be better to go down the IpPhone path, rather then adding more FXS ports or having a different model run. The FXS as a fallback option is still a good idea, more so if the MP is going to be powered from a Batt/SolarCell , and if you are able to obtain surplus analogue phones really cheap.

 

My gut feel is that even if SIP phones get really cheap they are
unlikely to be as rugged or basic as a POTs phone. I am not
necessarily talking about a wired phone either.  I use a pair of
Panasonic DECT wireless phones with my Mesh Potato at home which works
amazingly well.

This is true, the old saying, you get what you pay for rings true, the casing could be cheap and not stand the test of time, plus there is more things to go wrong compared to an analogue handset.

 

My personal take is that the more likely replacement route for the MP
will be via WiFi-enabled smartphones.   We need more input from
everyone on this though.

Very possible, though i find voice on 2.4ghz is a bit hit and miss, works better on 5ghz (could just be the interference here) 

DECT works very well, and usually a better result to roll a DECT phone system, then ip wireless phones, in my experience anyway.

> you could in theory pickup a AT610P or GXP1405 (~50$) which would give you
> callerid, enhance provisioning...
> not sure what the development cost is going to be to add callerid and a few
> other features to the existing fxs port, or if that is planned ?

My impression is that the dedicated FXS chipsets have very robust
support for all modern phone features

http://www.silabs.com/products/voice/slic/Pages/Si3217xProSLIC.aspx

Ahh if the fxs chip does it out of the box then all good, i thought maybe you would of had to written/design the other features (not 100% across the background of the orginal FXS port, apart from it runs on the serial port).

I agree you can get a few features with a simple hookflash

[Dave Duchesneau]

Hi All,

Here's my two cent's worth as a response in the list, but I will also add a
version of it to the UserVoice via individual postings:

> Dual ethernet ports... What we'd like to hear

> from the community is your perception of the
> utility of a second ethernet port.

The Open-Mesh OM2P has two Ethernet ports, and they have proven to be VERY
handy. One port can be used for upstream (e.g., toward the internet/WAN
connection or another network) and the other for downstream toward a private
LAN or other device. While this may be uncommon in a village situation
where the MP is the ONLY device at a location, it is very common in many
other scenarios. In particular, given almost any scenario where there is
available bandwidth available at some kind of gateway, this allows a mesh
radio to be easily injected (in a virtually idiot-proof manner) between the
gateway and whatever downstream device is currently plugged into it. For
example, if a camera (or as easily, a Ubiquiti base station) is plugged into
a gateway, the mesh radio simply goes between them. Under normal
conditions, upstream WAN communications from the downstream device simply
pass through the mesh device, and cause no negative impact to the equipment
owner. However, if the WAN link fails for any reason, the mesh device
simply routes the WAN communication over the mesh to a gateway located
elsewhere, which provides a significant benefit to the equipment owner, and
thus a bona fide reason to sponsor a mesh node at his gateway.

> Dual FXS ports... how much would you value a dual versus
> single FXS Mesh Potato base model?

Potentially halving the cost might be a powerful reason in a village
scenario, but also in any OFFICE/business/clinic/school scenario. In
disaster recovery, it would double the number of lines available for
essentially the same price. Even for non-developing-country scenarios,
having a second port could be useful, such as for a fax machine, which in
some places may be the only "printer" available. If the chipset set
supports a second FXS port and the incremental cost is small enough, it
might be a very worthwhile feature. However, on a prioritized list of
features, this would seem to be pretty far down, in the nice-to-have
category. Ignoring the cost-halving merits of a second FXS port, most
applications where a second port is actually needed would generally be
better served by having a second mesh node, thus potentially strengthening
the mesh network while providing redundancy. If there were provisions for
at least a pair of piggybacked daughterboards, then the necessary combo of
one or two FXS ports could be deployed, along with whatever other options
might be needed, while eliminating them from the underlying MP PCB. For
general I/O options, any piggyback connections on the PCB need to be
interchangeable though, each with its share of power, GPIO, etc.

> Audio out... Would having a miniature audio jack

> be a high value proposition?

Personally, I think so. Although the jack can be very cheap if designed in,
it is virtually impossible to add in otherwise. The uses you noted for such
a jack (speakerphone, internet radio, etc.) can also be added later at an
optional (and importantly, DEFERRED) cost that is tailored to the specific
application, but only if a jack is present. Also, there are other very
important applications, such as paging, public address, or alarm
enunciation. In these application, the mesh network serves as the means for
wirelessly conveying important information to where the people are located,
enabling communities to have warning systems that they could otherwise never
afford. Importantly, note that such as system would work fine even without
an Internet connection, and its public-safety implications (i.e., value) may
persuade a local community's government (or businesses) to sponsor a bunch
of mesh nodes. The software can be added later, but only if hardware
support is present.

> USB support. For me this is a given... should it be
> internally mountable...?

USB 2.0 is also a given for me, because it is has ubiquitous device support
and provides essentially infinite expansion options, such as modems
(cable/DSL, 2G/3G/4G cell phones or air cards, V.92 dial-up, LEO/GEO
satellite), GPS/GLONASS, storage (HD/SSD), cameras, printers, etc. USB is
super important, and probably the most important of all the optional
features on the table. I do not think the presence or absence of USB should
even be on the table, but rather, we need to discuss how many USB ports
should there be, and how they should be arranged. I believe there should be
AT LEAST TWO USB ports, because the need for USB connections is often
multiple, with conflicting devices, and the significant expense is in the
connected device, not the USB port itself. Having two USB ports also solves
the where-to-put-it problem (internal/external), which is itself caused by
the single-port assumption. The obvious answer, which dissolves the
location problem, is "internal AND external". Even if the ultimately chosen
chipset were to support only one USB port, a 2-port hub chip is super-cheap
if designed in (such a hub is used to provide 2 USB ports, for instance, on
the $25 Raspberry Pi, which also has an SD slot, HDMI, audio, etc.).

As long as the USB ports are in the hardware (at the PCB level), packaging
can be designed flexibly. For example, the waterproof housing could
internally support a standard USB connector, with sufficient roof for a
typical USB air card. The same housing could have a knockout that will
reveal a second, externally accessible USB port (not for outdoor use). This
approach avoids having an IP-rated external USB connector (which can cost as
much as the MP itself), or failing that, trying to seal an indoor rated USB
connector. Also, as long as the PCB provides the necessary USB support,
additional housings can be designed and produced later, so as to accommodate
special configurations whose requirements emerge on the basis of actual need
(such as to incorporate an internal mix of USB devices, and other goodies,
such as batteries, drives, etc.).

> The list goes on...

Yes, it does! While the level of how-to support from VT developers has been
phenomenal, most of the advanced needs moving forward should be easy (or
easier) to meet out of the box, without resorting to a soldering iron, etc.
From my viewpoint, one of the top requirements is to provide for flexible
antenna reconfiguration without resorting to hacks that risk damaging the
PCB or changing the impedance or increasing the SWR seen by the radio.
Although it may be too expensive to add external RP-SMA connectors (one per
802.11n stream), it may be feasible to have internal u.FL connectors (or
their equivalent). In the production units, the internal antennas can be
connected via u.FL (or alternatively, soldered adjacent to them if properly
designed for that, RF-wise, saving half the u.FL connector cost by leaving
the u.FL connector open). The production housing could have knockouts for
external RP-SMA connectors which are easily usable in non-basic
configurations. This keeps the basic housing both weatherproof and cheap.
Advanced antenna configurations can use the RP-SMA knockouts, or some other
altogether approach, with internal connections via the low-cost u.FL
connectors on the PCB. Such an approach can be seen in the attached photo,
where the two chrome metal things that look like clips are actually
antennas.

I am completely in favor of having POE (passive or active), but I still want
to see a standard power jack, which is not only cheap, but incredibly
useful. One of my favorite design ideas, which can only be done as part of
a PCB redesign, would be to have the ability to import and/or export DC
power via the standard power jack. Ideally, there would also be an "power
mode" that is controlled by a DIP switch or jumper/berg connector on the PCB
(not externally accessible). This is how it could work:

1. The "Import-Only" power mode would operate similarly to the current MP,
with one exception. Both the POE section and the standard power jack would
both accept a wide voltage range as it is now, but a comparator circuit
would select power from the source with the higher voltage. In this
approach, remote power via POE (which may or may not be battery-backed)
would not be selected if the local voltage is higher (e.g., from a
co-located solar panel). Since the two DC power sources are essentially
isolated inputs, they need not be compatible, and fluctuations in either
would be handled invisibly and automatically. The absence of either source,
whether intentionally or through failure, is equivalent to using the other
source. Provisioning of power sources could be reconfigured in many ways.

2. The "Import-Export" power mode would be like the "Import-Only" mode, with
an important exception. If the voltage from the POE source is sufficiently
high, then a fixed, current-limited "float voltage" is exported to the
standard DC power jack, and this can be used to charge a co-located battery
and/or operate a co-located low-voltage device. In the simplest case, the
appropriate circuitry could be embedded directly on the MP's PCB. Another
option would be to support the "Import-Export" power mode by having a small
"daughterboard" that can piggyback onto a header on the MP's PCB. This
allows the cost of "Import-Export" power mode (which is arguably very low)
to be deferred almost entirely, while also enabling multiple future versions
of the daughterboard that implements it. For example, one version of a
daughterboard might have one or more additional jumpers/DIP switches that
are used to select the exported float voltage (there are perhaps eight
really useful basic float voltages that collectively cover multiple battery
designs, chemistries, and cell configurations, which would require only
three additional jumpers). At some locations, temperature extremes can
occur at both ends of a wide range, so the float voltage setting could be
modified by a simple thermistor, rather than a jumper that might require
seasonal adjustment.

In the arena of add-on features that increase MP2 flexibility, I am highly
in favor of having at least one SDHC card slot on the MP2. The idea would
be to not depend on it if possible (which would mean having other flash
storage on the MP2 for booting, etc.), unless you're already planning on an
SD card. Obviously, the SD card itself would be optional if not needed for
booting, which keeps costs down. The ability to add an SDHC card that is
appropriate for specific requirements (capacity, speed, cost) would be very
valuable. The storage in an SD card could be easily partitioned into a
local volume and a fractional one (the latter being part of one or more
shared volumes that distributed over a SECN mesh, using FEC for redundancy).
The software to implement storage in this way should be well within the
capabilities of a mesh node, and any heavy lifting can be relegated to one
or more network-attached "server" devices (like a $35 Raspberry Pi, with its
256 MB of memory).

Speaking of memory, it would be nice for mesh nodes to have more memory.
Since memory capacity is typically limited by the chipset, it should be a
factor in chipset selection.

With respect to add-on feature that increase reliability, I would want to
ensure that hardware watchdog timers are available to reboot the MP if it
fails. On a separate but related note, I would also like to see a
piggybacked daughterboard that includes a watchdog-controlled power-control
circuit and external DC power connector for power-cycling a co-located
gateway device. Although such a daughterboard may not be designed or
available initially, some provision for it would need to be incorporated
into the MP's PCB design.

With respect to chipset/mesh radio decisions, I would really like to see a
more powerful radio, and/or multiple 802.11n MIMO streams. There's a huge
difference in range and penetration between a 100mW 802.11g node and, for
example, a 400mW 802.11n node, partly due to a 6 dBm increase in power, and
partly due to upgrading from 802.11g to a one or more 802.11n streams (1x1,
2x2,2x3, 3x3, etc.). With regard to interference in high-density
deployments, and energy usage in general, there's no reason the default
power level cannot be set to, say, 100 mW or even less, which would still
provide better range than the current MP (assuming the MP2 is 802.11n rather
than 802.11g). When longer range or more penetration is needed, the
appropriate combination of increased power, external antennas, and narrower
channels could be used. Narrower channels decrease the bandwidth (bad), but
increase the range (good) and decrease the channel-to-channel interference
(good). At a given power level, the bandwidth can be increased as a
multiple of the number of MIMO streams, so the loss of bandwidth (bad) due
to a narrower channel can be compensated (good), for instance, by a second
MIMO stream (e.g., 2x2 MIMO), without increasing the power (good). MIMO
also helps significantly with multi-path interference (normally bad), and
actually turns it into a bandwidth-enhancing asset (good).

I won't go into multi-band radios, even though that's one of my favorite
mesh topics... I assume a dual-radio MP2 configuration is not on the table.
Who knows? Maybe a second WiFi-class radio could end up on a daughterboard,
or, better still, attached via a USB port (like an aircard)...

All the best,

Dave Duchesneau
d...@crisis-force.org
CRISIS-FORCE Emergency Network

[Wayne Abroue]

Hi All

My take

On Fri, Sep 28, 2012 at 4:24 PM, Song, Stephen <stephe...@gmail.com> wrote:
> Hi Glen,
>
> On 28 September 2012 10:45, Glen Steedman <gste...@gmail.com> wrote:
>> 802.3af PoE to power the MP would be a nice addition. but im guessing if
>> there is any 802.3af with the chipset it would be to provide power to the
>> lan port rather then receiving powering.
>
> I think remote powering of the MP is essential. Terry proposed
> (https://villagetelco.uservoice.com/forums/20556-mesh-potato-2-0-design-and-features/suggestions/3210539-single-cat-5-cable)
> a single CAT5 cable to carry power,data, and voice. Personally I
> think this is the route to go. Standard CAT5 cables could then be
> used and a VT could be built without a crimper.

I agree that the all in one cable is essential, with the split
happening at the injector side. Have we explored the costs to do this?
Must a injector be specifically designed?

>> Im just thinking its going to be cheaper at some point to use a cheap voip
>> phone, then buy an analogue fxs phone, if you dont need to be more then
>> 90Meters away from the MP. prices keep tumbling. Maybe we should check this
>> post in a years time and see if its cheaper yet again.
>
> This is a fundamental question. Is there still a need for an AP w/ an
> FXS port? Otherwise why not just a Pico/Nano/Loco device and a SIP
> phone. Or as someone has proposed
> (https://villagetelco.uservoice.com/forums/20556-mesh-potato-2-0-design-and-features/suggestions/3211656-use-a-standard-router-e-g-tp-link-703n-and-mesh)
> use an AP with USB port and plug in a USB phone.
>
> My gut feel is that even if SIP phones get really cheap they are
> unlikely to be as rugged or basic as a POTs phone. I am not
> necessarily talking about a wired phone either. I use a pair of
> Panasonic DECT wireless phones with my Mesh Potato at home which works
> amazingly well.
>

I also find that most of the time POTS phones are readily available,
collecting dust in the users cupboard. So no need to purchase more
ancilliary equipment.

> My personal take is that the more likely replacement route for the MP
> will be via WiFi-enabled smartphones. We need more input from
> everyone on this though.
>

While this is a option, and works very well. I have tested within a
100M radius from any AP on the mesh. The two reasons for not making it
standard at this point is the challenge of having a low penetration of
smartphones in rural area's, and most importantly the challenge of
battery life while having wifi on 24/7.


Wayne

[Song, Stephen]

Thanks Dave and Wayne. More insightful input!

Dave, you brought up the antenna question which has been a subject of
much debate in the past. Well, here we are. An opportunity to
integrate everything we've learned in the last couple of years about
antennas and mesh WiFi networks. Questions:

1) integrated antenna or just a jack like an Ubiquiti Bullet or other?
2) if integrated antenna, omni, semi-directional, or fully directional?
3) if integrated antenna, should make it easier for external
alternatives RP-SMA jack similar to Nanostation, more robust but also
more expensive N-type? stick with motherboard connector?
4) design the enclosure to support simple to locally manufacture reflector?

just some initial ideas... lots of opportunity for innovation here I think.

Cheers... Steve

[VT Scroll Keeper]

I sugest an internal antenna for quick deployment and an optional N-type
connector for an external antenna. This way the end-user can addapt his
MP to local needs and conditions.


Michel


Op 30-09-12 16:26, Song, Stephen schreef:

Michel
Village Telco Scroll Keeper

[Wayne Abroue]

Hi

> 3) if integrated antenna, should make it easier for external
> alternatives RP-SMA jack similar to Nanostation, more robust but also
> more expensive N-type? stick with motherboard connector?

I would go with the integrated semi directional, with U.FL connectors
(low cost) and breakout holes as Dave suggested for those wanting to
upgrade to a n-type by adding a all in one pigtail. No soldering ,
Maybe jumper change.Openwrt has software antenna select built in IIRC.
Just Breakout hole and fit.

Wayne

[Meftah Tayeb]

Guys:
what will be the Wireless ship used for MP2?
dont exit atheros please, use ath9k both for CPU and Wireless. dual band if
pocible 5GHZ for P2P LINKS

----- Original Message -----
From: "Wayne Abroue" <ple...@gmail.com>
To: <village-...@googlegroups.com>
Sent: Sunday, September 30, 2012 8:29 PM
Subject: Re: [vt-dev] MP2.0 design - Stephen wrote "Design ideas include
things like 1 or 2 ethernet ports, 1 or 2 FXS ports"

> --
> You received this message because you are subscribed to the Google Groups
> "village-telco-dev" group.
> To post to this group, send email to village-...@googlegroups.com.
> To unsubscribe from this group, send email to
> village-telco-...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>

> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 7404 (20120821) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>


__________ Information from ESET NOD32 Antivirus, version of virus signature database 7404 (20120821) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

[T Gillett]

Hi Meftah

I believe the proposed chip for the MP-02 is the Atheros AR9331 'System on a Chip' the same as is used in the TP Link WR703, MR3020 and others.

This chip supports a single radio on 2.4GHz and is used to get an economical design.

There has been some discussion on ways to support a second radio device as an add-on although I haven't seen any details on how this would be done.

If you are interested in trying some existing dual band devices, you might like to look at the TP Link WDR4300 which is a dual radio device supporting 2.4 and 5GHz with 3x3 and 2x2 antennas respectively. 

The antennas are removable and use standard reverse SMA connectors so allowing for other antennas to be used.

The devices are 12V powered and draw around 300mA, They have a built in switch with five Ethernet ports, as well as two USB ports.

I have ported the SECN-2.0 Alpha  firmware to these devices and it is available here if you want to try it out:

http://villagetelco.org/download/firmware/secn/unstable/secn-2/alpha-2/build-2012-09-22-TP-SECN-2-Alpha-2/ 

Regards
Terry

On Mon, Oct 1, 2012 at 1:38 AM, Meftah Tayeb <tayeb....@gmail.com> wrote:

Guys:
what will be the Wireless ship used for MP2?
dont exit atheros please, use ath9k both for CPU and Wireless. dual band if pocible 5GHZ for P2P LINKS
----- Original Message ----- From: "Wayne Abroue" <ple...@gmail.com>

To: <village-telco-dev@googlegroups.com>

Sent: Sunday, September 30, 2012 8:29 PM

Subject: Re: [vt-dev] MP2.0 design - Stephen wrote "Design ideas include things like 1 or 2 ethernet ports, 1 or 2 FXS ports"

Hi

3) if integrated antenna, should make it easier for external
alternatives RP-SMA jack similar to Nanostation, more robust but also
more expensive N-type?  stick with motherboard connector?

I would go with the integrated semi directional, with U.FL connectors
(low cost) and breakout holes as Dave suggested for those wanting to
upgrade to a n-type by adding a all in one  pigtail. No soldering ,
Maybe jumper change.Openwrt has software antenna select built in IIRC.
Just Breakout hole and fit.

Wayne

--
You received this message because you are subscribed to the Google Groups "village-telco-dev" group.

To post to this group, send email to village-telco-dev@googlegroups.com.
To unsubscribe from this group, send email to village-telco-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

__________ Information from ESET NOD32 Antivirus, version of virus signature database 7404 (20120821) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus signature database 7404 (20120821) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

--
You received this message because you are subscribed to the Google Groups "village-telco-dev" group.

To post to this group, send email to village-telco-dev@googlegroups.com.
To unsubscribe from this group, send email to village-telco-dev+unsubscribe@googlegroups.com.

[Dave Duchesneau]

Hi Steve, and all,

> Questions:
> 1) integrated antenna or just a jack like an Ubiquiti Bullet or other?
> 2) if integrated antenna, omni, semi-directional, or fully directional?
> 3) if integrated antenna, should make it easier for external
> alternatives RP-SMA jack similar to Nanostation, more robust but
> also more expensive N-type? stick with motherboard connector?
4) design the enclosure to support simple to locally manufacture reflector?

Great questions. Before I address them, which I will do at the end of this
rather long message, let me establish a backdrop against which we might
think about the underlying requirements. I'm not a marketer, so I'll
paraphrase a marketing maxim into terms for us more technical folks:

"If you design a product that attempts to meet the needs of the union of
your customers, the end result will appeal to the intersection of them."

Personally, I still tend toward designing for the union (doing the most
good), while identifying which requirements are "above the line" (MUST have)
and "below the line" (e.g., SHOULD have, nice to have, possibly nice to
have, don't need, etc.). In other words, I do acknowledge that you cannot
please everyone. This exercise clearly identifies the requirements which
are non-negotiable (with respect to some stated goal) as being ONLY those
above the line. These are also the only requirements that SHOULD drive the
critical path (in project management terms), in most circumstances.
Everything else should then be prioritized, and thus accommodated according
to priority.

To be clear, I should suggest that the needs of various deployers (e.g.,
Village Telco and CRISIS-FORCE, to name two) may differ in some very
important ways, while also having a great deal in common. While both
organizations care greatly about cost, they are not at the same place on the
cost scale, largely because of key differences in non-negotiable
requirements.

Whereas device cost, ease of deployment, device survivability, and network
survivability are major drivers for both organizations, Village Telco seems
to be primarily concerned about establishing reasonably reliable
communications affordable for individuals sharing a smallish mesh network
(i.e., a virtual switch). The CRISIS-FORCE Emergency Network (CFEN) is more
oriented around establishing affordable and highly survivable communications
BETWEEN meshes (connecting virtual switches across a country). Thus, the
two efforts are quite complementary, and require some interoperability.

A key goal for CFEN nodes is that they not survive bad weather and very long
power outages, but also fairly arbitrary E³ (Electromagnetic Environmental
Effects), which includes lightning, electromagnetic pulses (EMP, SEMP, HEMP,
NEMP, etc.), geomagnetic storms, etc. One consequence of this is that all
the electronics must be included within a suitable Faraday cage, and there
must be suitable filtering and E³ protection circuitry between the
electronics and any antennas or other conductors exiting the Faraday cage
(e.g., power, Ethernet, etc.). The more that some of these requirements are
also met by local VT mesh nodes, the more resilient the system is with
respect to a particular community.

Antenna-wise, what this means is that to qualify for use in a proper CFEN
node, radios cannot depend on internal antennas, because their signals
cannot escape the Faraday cage (no receive, no transmit). For this reason,
CFEN can use Ubitquiti Rocket M series radios (which have two external
RP-SMA ports), but not the Nanostation devices, because the latter have an
internal antenna (even the 900 MHz device, which has an internal antenna and
one RP-SMA port). It turns out that the E³ protection circuitry associated
with each antenna typically costs as much or more than the underlying radio
it protects, but there is no alternative for pre-deployed infrastructure
like long-haul connections between communities...

Within a localized community mesh, however, there are many alternatives.
For example, if a standard VT node (like the next-gen MP02) had a way to
utilize only external antenna connectors (thus disabling any internal
antennas), then we could use a cheap coffee-can Faraday cage design for
protecting it from E³ at modest cost. Combined with small, low-gain
antennas, VT's MP2 devices would be at substantially lower risk than
unprotected nodes would be on CFEN's long-haul gear. For personally owned
equipment, the needed power to supply VT's MP2 gear may be addressed on an
individual basis, whereas that is not an option for pre-deployed long-haul
gear, which adds to CFEN's cost.

Now, for my take on your questions:

> 1) integrated antenna or just a jack like an Ubiquiti Bullet or other?

If you have to choose one or the other, I'd choose a jack, for reasons that
should be apparent from my verbose discussion above. However, you could
still connect an internal antenna to the jack, if the jack itself is
internal. It's interesting that you mentioned a Ubiquiti Bullet, since it
differs from the norm in numerous ways. First, it is much higher power than
most radios. Second, it has only an external N-type connector, rather than
the cheaper, less durable, and more common RP-SMA connector. Third, it
supports 802.11g, but not 802.11n. Fourth, despite its high power and
expensive N-type connector, the Ubiquiti Bullet is one of the least
expensive radios you can buy for outdoor use. If it supported 802.11n
(e.g., 1x1 MIMO), and other radio bands, then it would be nearly the perfect
radio for CFEN's outdoor use. For CFEN, the N-type connector is a plus,
because the E³ protection circuits for RF also use N-type connectors. If it
was 2x2 MIMO and had RP-SMA jacks instead, it would be a Rocket M.

> 2) if integrated antenna, omni, semi-directional, or fully directional?

Ubiquiti's Nanostation series is very directional (about a 60-degree beam, I
think), because it is designed to be a low-cost client station that is aimed
directly toward a high-powered base station, typically one having sectorized
antennas. This makes it very unsuitable for general purpose mesh use,
unless multiple Nanostations are used to point in different directions, or
unless a remote client is pointing it toward a distant mesh. Of course, it
makes a wonderful relay.

To be of general use, the MP02 almost certainly must support omnidirectional
patterns out of the box. Highly directional patterns should be supportable
as a special case. From a VT viewpoint, I would think the best option would
be 2x2 MIMO with disconnectable internal antennas. Although N-type
connectors are more rugged, RP-SMA connectors offer a huge improvement in
reliability over typical on-board connectors like u.FL. A lot of reference
boards for development work will put RP-SMA connectors right on the PCB, and
this might be a very good option for the MP02. External access to the
RP-SMA connectors could still be via knockouts in the weatherproof chassis,
so that high-gain antennas with a desired pattern could be utilized.

> 3) if integrated antenna, should make it easier for external
> alternatives RP-SMA jack similar to Nanostation, more robust but
> also more expensive N-type? stick with motherboard connector?

As noted above, I personally think RP-SMA connectors would be more than
adequate. Ubiquiti must think so too, because all of its latest Rocket
M-series devices have dual RP-SMA ports, and NOT N-type connectors. It's a
good compromise between cost and reliability. If you did the same, then you
would also have Ubiquiti's full line of 2x2 MIMO antenna at your disposal
for specialized products (your packaging might not snap into some of their
antennas, but that's a separately addressable issue).

4) design the enclosure to support simple to locally manufacture reflector?

That's actually a no-brainer, from my viewpoint. Even if you had internal
RP-SMA connectors on the PCB, with internal antennas, the weatherproof case
itself would have to be radio transparent (i.e., a radome). Thus, since you
have knowledge (and control) of how the antennas are positioned within the
case, there's nothing to prevent designing an external user-attachable
reflector as part of the package design. It could definitely be designed up
front with something accessible to end users, so the reflector could be
manufactured and attached in the field by users themselves, with simple
directions (e.g., "cut and bend a 5-inch coffee can into this shape and
attach at these points..."). Of course, there could be different reflector
designs based on available material, tools, required longevity, etc.

Well, I think I've covered my immediate thoughts sufficiently that I
probably have crossed the line into being long-winded. I just blasted this
out, so I probably rambled a bit. Sorry about that.

All the best,

Dave Duchesneau
d...@crisis-force.org
CRISIS-FORCE Emergency Network




-----Original Message-----
From: village-...@googlegroups.com

[mailto:village-...@googlegroups.com] On Behalf Of Song, Stephen
Sent: Sunday, September 30, 2012 7:26 AM
To: village-...@googlegroups.com
Subject: Re: [vt-dev] MP2.0 design - Stephen wrote "Design ideas include
things like 1 or 2 ethernet ports, 1 or 2 FXS ports"

[Dave Duchesneau]

CORRECTION:
(replace not survive with "not only survive", as below)

> A key goal for CFEN nodes is that they NOT ONLY SURVIVE

> bad weather and very long power outages, but also fairly

> arbitrary E³ > (Electromagnetic Environmental Effects)...


Dave

[Dave Duchesneau]

Hi Wayne,

> I would go with the integrated semi directional, with U.FL connectors
> (low cost) and breakout holes as Dave suggested for those wanting to
> upgrade to a n-type by adding a all in one pigtail. No soldering ,

> Maybe jumper change. Openwrt has software antenna select built in IIRC.

> Just Breakout hole and fit.

Thanks for the affirmation, although I'm not so sure about the
semi-directional idea. If the radio is a 2x2 MIMO internally connectorized
omnidirectional antennas, then you can always leave one antenna connected
for omni (or substitute an external omni), and use the other MIMO stream
with an external antenna of arbitrary directionality. Separating the MIMO
streams can be very useful for low-cost relays (point directional antennas
in opposite directions, or different directions). Although this may cut the
2x2 MIMO bandwidth in half in a particular direction, it's no worse than a
1x1 MIMO stream, and might be better. A signal sent in the opposite
direction will often bounce off something and then reverse itself, causing
multipath (reflected signals arrive at the receiver later, and possibly out
of phase). Although multipath is bad thing with current MPs, it can be a
good thing with MIMO radios, which use encoded multipath signals to improve
bandwidth and overall link integrity.

I should note that u.FL connectors (and others like them) are quite fragile,
but are definitely the lowest cost connector option. If a slightly higher
cost can be tolerated, RP-SMA connectors on the PCB is another option. As
you note, pigtails are available for U.FL to RP-SMA or N-type connectors,
and also for RP-SMA to N-type connectors, and many other others.

I think we agree that the main thing is to have some kind of connector that
avoids the need to solder anything. Unless one is skilled at soldering,
it's really easy to ruin the device, or to cause a problem that doesn't show
up until the device has been deployed (e.g., broken joint, high-impedance
connection, etc.). The impedance is especially important for RF
connections.

Also, some thought needs to go into any knockouts in the case design, so
that the knockout action occurs easily, is correctly sized, and so forth.
It's easier if the knockout hole is only for indoor use, since a grommet or
seal of some kind will need to be accounted for if the case is to remain
weatherproof for outdoor use.

I think knockouts can be very valuable, but still require engineering.

Dave


-----Original Message-----
From: village-...@googlegroups.com
[mailto:village-...@googlegroups.com] On Behalf Of Wayne Abroue
Sent: Sunday, September 30, 2012 10:29 AM
To: village-...@googlegroups.com
Subject: Re: [vt-dev] MP2.0 design - Stephen wrote "Design ideas include
things like 1 or 2 ethernet ports, 1 or 2 FXS ports"

[Elektra]

Hi all -

> I would go with the integrated semi directional, with U.FL connectors
> (low cost) and breakout holes as Dave suggested for those wanting to
> upgrade to a n-type by adding a all in one pigtail. No soldering ,
> Maybe jumper change.Openwrt has software antenna select built in IIRC.
> Just Breakout hole and fit.

unfortunately, a jumper is not a good option in a microwave RF path. Switching the antenna port in software requires a physical RF switch. The AR9331 chip, that our design will be based on, has support for two antennas, but is supports RX antenna diversity only. So we can not just switch between an internal antenna and an external antenna port. In order to do that we would have to add an external RF switch, which will cost some RF performance due to losses and adds to the cost.

I'd like to suggest a pcb antenna for the RX-only port and a UFL socket on the pcb or, alternatively, a R-SMA socket soldered to the pcb, as you can see on many SOHO products. If I remember correctly, the Ubiquity Pico-Station has such an antenna socket on the top of the device, so you can directly attach a omnidirectional antenna on top or connect a RF-cable.

With regards to USB 2.0, I am sure we will implement this, I have no doubt about that. USB adds the option of adding another Wifi interface or a soundcard, and these are just two of many options.

With regards to the idea of having an additional audio interface, the chip has only one PCM bus, which will be occupied by the FXS port(s). There is one GPIO that can be used for S/PDIF according to the data sheet, but I don't see much use for that. In case someone needs an additional audio interface, one can be added for ~5$-US, by connecting a USB sound card.

A metal housing is nice, but would require two external antennas outside of the RF shield of a metal housing. And I guess it is the most expensive solution.

Cheers,
Elektra

[Carlos Rey-Moreno]

Hi everyone! sorry for having been out for a while, lecturing restarted and can't cope with everything at once.

I have a couple of comments to what I've read so far.

Moving  towards users with WiFi enabled smartphones as a standard solution I don't think is good idea since, as Wayne said, in rural areas very few people count with one, and, from my experience it's unlikely that, apart from young generations, they change their phones to a data able one. Also as, Wyane was pointing out, the lack of electricity in those areas and the consumption of the wifi radio powered 24/7 would keep those young generations out of the network most of the time.

I think also that having an FXS port to use an analogue telephone is very interesting in power constrained areas, since the consumption of the phone is minimal compared to DECT or Digital phones. The same applies to two FXS ports, that in our context of providing public phones (or even in between neigbouring houses depending on the maximum length of the cable) to the community could increase cheaply the use of the system.

Regarding the antennas, for us the possibility to access the UFL port inside open a whole range of possibilities, although the very same lack of electricity would make it impossible for locals to replicate given the electricity needed for the soldering iron. Some external connector us in the Nano stations would make it easier for local non-experience people to adapt the solution.

Having a single injector would be great too, but as Wayne was pointing out, would it very expensive to produce?

The last thing I wanted to comment is on the USB port, I think that given the increasingly better coverage of 3G in rural areas, and the availability of USB dongles, counting with such a port would be great. If the connection inside the case is possible and easy, I would rather prefer the dongle been waterproofed.

Hope my contribution helps. I'll try to read Dave's contributions and comment more along the week.

BTW it's great the open approach you follow to consult everyone and consider the votes of the same value. Thanks

Carlos

--
Note that I am using a new email account carlos.r...@gmail.com, and that the former email address cr...@ehas.org will be disappearing soon. Thanks for changing this in your contact list.

Carlos Rey-Moreno
Research Assistant
Office 1.28
Department of Computer Science
University of the Western Cape
Private Bag X17 - Bellville, 7535
Cape Town - South Africa

Tel: +27 (0) 21 959 2562
Cel: +27 (0) 76 986 3633

Skype: carlos.reymoreno
Twitter: Creym

[Marshall Anako]

Hi Steve,

Pls is the MP2 and Android handsets interchanged ?

I know Stephen was working on that sometimes back.

Pls let me know.

Marshall

--
You received this message because you are subscribed to the Google Groups "village-telco-dev" group.
To post to this group, send email to village-...@googlegroups.com.
To unsubscribe from this group, send email to village-telco-...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Marshall MbekAnako
Phoenix Arizona
(623)570-8306

[Song, Stephen]

Hi Marshall,

Sorry I am not sure I understand the question.  Can you give a little more detail?

-Steve

You received this message because you are subscribed to the Google Groups "Village Telco Development Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to village-telco-...@googlegroups.com.

To post to this group, send email to village-...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Steve Song

+1 902 529 0046

http://manypossibilities.net
http://villagetelco.org

[Marshall Anako]

Ok I mean if android phones can get MP2 signal and act as a wireless handset within the domain where the wireless signal roams. Iam talking about things like Serval Arkaroola Demo which uses handset but get mesh signal.

Marshall.

[Wayne Abroue]

Hi Marshall

I still think Android has challenges with Adhoc, and then if you get your device to connect in Adhoc, there is still the BSSID challenge to overcome. Some people have had limited success with this, though I havn't been able to replicate it as yet.

Using SECN though phones connect to the AP and work as if you were part of the mesh.

I am now testing on JB 4.2 using a S3 samsung.

The problem does not lie with MP's but rather the android drivers.

Wayne 

[Song, Stephen]

Hi Marshall,

Any WiFi-enabled smartphone can connect to a Village Telco network simply by associating with a Mesh Potato hotspot.    It is possible to move across Mesh Potato hotspots and maintain connectivity with a WiFi-enabled client device.  I tested this myself last week and was able to move from one Mesh Potato hotspot to another and maintain a VoIP call.  Granted the Mesh Potatoes were not that far apart (10m) so there was a good overlap but it definitely works.

As Wayne points out, there are challenges in getting Androids to directly participate in the mesh   To begin with, in order to put the WiFi of an Android device into ad-hoc mode, you need root access to the Android phone.  This could change if Google/Android ever decide to allow access to ad-hoc mode by default but it is hard to know whether they ever will.  Second, most mesh protocols have been designed for networks that are not changing all the time.  As a result, protocols like batman take a while to "settle down" as they evaluate and optimise routing on the network.  A mobile device, or at least a WiFi device that is moving around, thus can run into problems running an ad-hoc protocol as the network can find itself constantly in a state of settling down.  Finally there is the load on a mobile phone in maintain its role as a network node in the mesh.

The Serval Project is dealing with the above issues in a number of ways.  First, they have designed their own overlay mesh protocol which doesn't require root access and which is designed for mobile networks.  Second, they are working on mesh extender devices which are intended to create more flexible connectivity for android phones running the Serval mesh.

Cheers... Steve

[Paul Gardner-Stephen]

Hello all,

To expand on this discussion with regard to Serval and what you are trying to achieve, the Mesh Extender concept is probably the most interesting.

Mesh Extenders will, among other things, act as Wi-Fi client to ad-hoc bridges.  Thus if you carry one (we plan to have a small battery powered form-factor option), then you wouldn't need to root your phone to participate in the mesh, as the Mesh Extender would do the Wi-Fi protocol conversion.  Note that this can already be done with a little fiddling by flashing something like a TP-LINK WR703N and running it off battery and running BATMAN on it.  What the Mesh Extender will additionally do, for countries where the spectrum is allowed to be used, is offer an ISM-band packet radio that will offer much greater range compared with Wi-Fi.

Paul.

Cheers... Steve

Marshall.

-Steve

To post to this group, send email to village-telco-dev@googlegroups.com.
To unsubscribe from this group, send email to village-telco-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
Marshall MbekAnako
Phoenix Arizona
(623)570-8306

--
You received this message because you are subscribed to the Google Groups "Village Telco Development Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to village-telco-dev+unsubscribe@googlegroups.com.

To post to this group, send email to village-telco-dev@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Steve Song

+1 902 529 0046

http://manypossibilities.net
http://villagetelco.org

--
You received this message because you are subscribed to the Google Groups "Village Telco Development Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to village-telco-dev+unsubscribe@googlegroups.com.
To post to this group, send email to village-telco-dev@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Marshall MbekAnako
Phoenix Arizona
(623)570-8306

--
You received this message because you are subscribed to the Google Groups "Village Telco Development Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to village-telco-...@googlegroups.com.
To post to this group, send email to village-...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "Village Telco Development Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to village-telco-...@googlegroups.com.
To post to this group, send email to village-...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Marshall Anako]

I really want to thank you Steve and all the mesh potato team, hopefully one day soon you will be given Nobel Peace Price for alleviating millions of people from the shackles of profit driven telco companies.

Marshall Anako

To view this discussion on the web visit https://groups.google.com/d/msg/village-telco-dev/-/9MceBNifRWoJ.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Song, Stephen]

Kind words Marshall.  I will be happy simply to get the Mesh Potato 2.0 into production.  

-Steve

[NicoEchániz]

On 04/30/2013 10:09 PM, Paul Gardner-Stephen wrote:
> Hello all,
>
> To expand on this discussion with regard to Serval and what you are
> trying to achieve, the Mesh Extender concept is probably the most
> interesting.
>
> Mesh Extenders will, among other things, act as Wi-Fi client to ad-hoc
> bridges. Thus if you carry one (we plan to have a small battery powered
> form-factor option), then you wouldn't need to root your phone to
> participate in the mesh, as the Mesh Extender would do the Wi-Fi
> protocol conversion. Note that this can already be done with a little
> fiddling by flashing something like a TP-LINK WR703N and running it off
> battery and running BATMAN on it. What the Mesh Extender will
> additionally do, for countries where the spectrum is allowed to be used,
> is offer an ISM-band packet radio that will offer much greater range
> compared with Wi-Fi.

Hi Paul, could you clarify this last paragraph a bit? Are you just
proposing to use 900Mhz routers, or is it something else?


cheers,
NicoEch�niz

[Vickram Crishna]

Will it be possible to use the walkie talkie band for the extender?

--
Vickram

>
> cheers,
> NicoEchániz

[Paul Gardner-Stephen]

Hello,

We are using the RFD900 and similar UHF packet radios with Serval's Rhizome and MDP transports directly.

See http://developer.servalproject.org/dokuwiki/doku.php?id=content:meshextender:main_page for current notes on options we have been exploring.

Paul.

 

cheers,
NicoEch�niz

[Paul Gardner-Stephen]

Hello,

On Friday, May 3, 2013 9:53:45 PM UTC+9:30, Vic wrote:

On May 3, 2013 5:49 PM, "NicoEchániz" <nicoe...@altermundi.net> wrote:
>
> On 04/30/2013 10:09 PM, Paul Gardner-Stephen wrote:
> > Hello all,
> >
> > To expand on this discussion with regard to Serval and what you are
> > trying to achieve, the Mesh Extender concept is probably the most
> > interesting.
> >
> > Mesh Extenders will, among other things, act as Wi-Fi client to ad-hoc
> > bridges.  Thus if you carry one (we plan to have a small battery powered
> > form-factor option), then you wouldn't need to root your phone to
> > participate in the mesh, as the Mesh Extender would do the Wi-Fi
> > protocol conversion.  Note that this can already be done with a little
> > fiddling by flashing something like a TP-LINK WR703N and running it off
> > battery and running BATMAN on it.  What the Mesh Extender will
> > additionally do, for countries where the spectrum is allowed to be used,
> > is offer an ISM-band packet radio that will offer much greater range
> > compared with Wi-Fi.
>
> Hi Paul, could you clarify this last paragraph a bit? Are you just
> proposing to use 900Mhz routers, or is it something else?
>
Will it be possible to use the walkie talkie band for the extender?

Which walkie-talkie band are you thinking of, and for which country?

There are different bands and different regulations for each country, so it is hard to say ahead of time.

BUT for most UHF walkie-talkie bands it would be technically feasible, assuming the legal situation is acceptable.

For VHF/HF walkie-talkie bands, e.g. 27MHz and nearby bands in many countries we would need to look at different

radios that can work in that band. Also, you would need a very long antenna due to the long wave-lengths involved.

If you can tell me what country/countries you are thinking of, we can try to find out a bit more about the regulatory and technical feasibility.

Paul.