<div>Thanks, that was a complete answer - I was actually thinking more about memory and processing requirements.</div><div><br></div><div>Arm is something we are looking at right now, but we have two problems:</div><div><br>

</div><div>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.</div>

<div><br></div><div>2 - Other bigger developers are not interested in sharing the discoveries they have made, so having a start point it's being difficult.</div><div><br></div><div>If you know any good chip to look at, please let me know</div>

<br clear="all">Érico V. Porto<br>
<br><br><div class="gmail_quote">On Fri, Mar 11, 2011 at 11:29 PM, Harald Geyer <span dir="ltr"><<a href="mailto:harald@lefant.net">harald@lefant.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

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