[Discuss] is this mailing list working?

[Érico Porto]

Thanks, that was a complete answer - I was actually thinking more about
memory and processing requirements.

Arm is something we are looking at right now, but we have two problems:

1 - Our projects do not aim to result in million products or something like
this, we will use really small quantities during development and not a lot
processors after when shipping the products - they are meant to provide
web/connected access to small cities AFAIK... So no company is really
interested in providing us development kits and processors - with a
reasonable lead time.

2 - Other bigger developers are not interested in sharing the discoveries
they have made, so having a start point it's being difficult.

If you know any good chip to look at, please let me know

Érico V. Porto


On Fri, Mar 11, 2011 at 11:29 PM, Harald Geyer <(spam-protected)> wrote:

> Hi!
>
> > First, thanks for answering, I liked that very much! Actually we are,
> also
> > deciding what hardware to go for it, so what would be the needs here? I'm
> > asking because we are at a point that there is not much more we can add
> in
> > our hardware, so we are looking to redesign it. If I could bring the
> needs
> > in a open mesh project it would be like foreseeing the troubles we will
> > have.
>
> The hardware we are using falls into several categories:
>
> Linksys type devices
> These are the famous origninal WRTG54 and some firmware-compatible
> clones from other vendors. - This is the hardware traditionally used
> for meshes, but it now is really old. It uses the broadcom chip that
> only runs with proprietary drivers and the proprietary drivers only
> support linux kernel 2.4. So that's a big mess. Also this hardware
> is quite big which in many situations is inconvenient and has somewhat
> limited performance - only able to route about 30 Mbit/s of traffic.
>
> Fonera and other atheros SoC devices
> This HW got somewhat popular about 3 years ago, when fon.com offered
> their routers at really low prices. This HW typically is quite small
> but often uses cheap DC-DC converters (especially between the 3.3V
> rail (ethernet, wifi, serial) and 1.9V rail (CPU power)) and thus
> produces more heat then desireable. Also adhoc mode doesn't work on
> ath5k properly yet, so we are mostly bound to madwifi, which has
> lots of stablity issues (though Felix from OpenWRT claims to have
> fixed them all) and generally is a huge mess of flavors and patches.
> Also madwifi has its own implementation of quality-of-service which
> doesn't play nice together with standard linux traffic control (tc).
>
> Routerboards
> These became popular when we were looking for more powerful HW for
> our backbone links. There is big variety of RBs for various CPU
> architectures and with several ethernet and mini-pci slots, to
> insert custom wifi cards. However the firmwares are typically
> closed source and jailbreaking them isn't supported by the vendors.
> Trying the get the source via gplviolations has mostly been ignored
> so far. Also the price is quite high.
>
> ARM-Board+USB-Wifi
> That's our latest experiments mostly targeted at nodes with special
> power requirements. It turns out that modern ARM-boards are powerful
> enough to run a linux distro with serveral cheap USB-wifi adapters
> attached. I think there is not productive setup like that yet, but
> it looks very promising and it might become our new default setup
> if the price goes down a bit further. There are some notes about
> possible HW setups on http://alpenrouter.xaok.org
>
>
> I can think of the following issues that we are struggling with:
>
> wifi chips
> The wifi chip should be supported by recent versions of the linux kernel,
> come with completely free drives and work well in adhoc mode and on long
> distance links. Atheros and broadcom both fail this currently, and there
> is little experience with other chips like ralink.
>
> wifi driver
> I have already mentioned some issues. Additionally there is the problem
> of whether the driver conforms to the wifi specs. Just some anecdotes:
> In the early days of Funkfeuer we had problems with netsplits and with
> bursts of management traffic because the official broadcom driver (and
> probably any driver conforming to the specs) doesn't work well with very
> big adhoc networks. The problem was only solved when Sven-Ola used
> a hex editor to patch some no-op instructions into binary driver to
> cripple the parsing of beacons and thus make the network more stable.
>
> So telling if a driver behaves well in large networks can only be done
> by experiment. But it help a lot, if you can patch the source and not
> some binary blob. Also good integration into the facilities of the
> linux kernel is important, otherwise you have to repeatedly reinvent
> the wheel.
>
> power supply issues
> Typically the users connect to there nodes via ethernet. So using PoE
> for the nodes seems like a natural choice. However cables tend to be
> quite long and thus high voltage and low current is important, but not
> many devices support power supply above 5V. Since most routers are
> in small boxes on some roof in direct sunlight, the get quite hot
> in summer during the day. So not producing any extra heat is important
> too.
>
> size
> There are many reasons to want routers as small as possible:
> 1) smaller water proof boxes tend to be cheaper
> 2) there is less risk to lose smaller boxes during storms
> 3) we try to keep our installations as invisible as possible
> 4) I sure forgot something ...
>
> antennas
> We prefer routers without diversity chip because diversity chips cost
> signal strength and also are rumored to degrade over time. OTOH some
> people prefer routers with serveral real wifi interfaces, because
> this helps to keep power consumption low (connecting two routers via
> 100 Mbit/s ethernet needs quite some power - even in the link is idle).
> Other people like to have routers with only one single wifi interface,
> because they attach it directly to the antenna without any cable in
> between. This is good for signal strength and saves one component.
>
> humidity
> You have to think how to protect your HW from humidity. I know of two
> approaches. You can infuse it into plastic with only the connectors
> getting out or you can put it into some box with a medium sized hole
> in the bottom to allow for some air circulation.
>
> hackability
> Most people using the Funkfeuer network have at least some modest
> soldering experience. And some even like to add some mods like a speaker
> on some gpio pin or compile a custom kernel or whatever, but almost
> nobody has experience using JTAG and similar low-level stuff. Therefor
> hardware should provide quite easy access to serial ports, some gpio pins
> and come with a handy bootloader.
>
> price
> While people generally don't mind spending some extra euros if the
> overall quality of the HW is ok you must also consider that mesh HW
> is pretty much fire and forget: You might lose it in a strong storm,
> or from lightning or even because water got into the box. Most people
> do prefer cheap HW even if it isn't perfect.
>
> > Also, is there any good paper over the Vienna case?
>
> Some people do write papers (actually some peoples main motivation
> to participate in the network is to have something to write papers
> about it seems) but I won't call them "good". IMO they are strongly
> biased towards the authors pet routing protocol and neither innovative
> nor methodically valid. But if you really want some papers, then I'm
> sure Aaron Kaplan can help you with that.
>
> > Sorry for taking three days, it was carnival here and I didn't look
> > carefully at my mails.
>
> No problem. I'm in no hurry.
>
> HTH,
> Harald
>
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/discuss/attachments/20110315/82d68668/attachment.htm>