Hi,
I have a little bit strange usecase for a wireless mesh network, and I'm wondering if B.A.T.M.A.N could be a good choice: my network stations, which are part of an industrial application, are located in a line:
Gateway - A1 - A2 - A3 - A4 - A5 - ... - A120
Any station generates data and wants to transmit it to the gateway, with the smallest possible latency. The distance of the stations is pretty small: about 3...4 m.
It might happen that someone re-arranges the stations:
Gateway - A9 - A17 - A1 - A47 - A9 - ... - A6
but the topology stays the same (a line).
It is allowed that one station sends its data to the farest reachable hop, so i.e. for my first example, if A5 wants to send data and is able to reach A2, it could directly do so.
- What do you think, could B.A.T.M.A.N be a solution? - Could the short distance be a problem? - Is it possible to regulate the transmission power in order to avoid disturbance?
Any hint, literature or link is appreciated.
rsc
Hey Robert,
Hi,
I have a little bit strange usecase for a wireless mesh network, and I'm wondering if B.A.T.M.A.N could be a good choice: my network stations, which are part of an industrial application, are located in a line:
Gateway - A1 - A2 - A3 - A4 - A5 - ... - A120
Any station generates data and wants to transmit it to the gateway, with the smallest possible latency. The distance of the stations is pretty small: about 3...4 m.
It might happen that someone re-arranges the stations:
Gateway - A9 - A17 - A1 - A47 - A9 - ... - A6
but the topology stays the same (a line).
It is allowed that one station sends its data to the farest reachable hop, so i.e. for my first example, if A5 wants to send data and is able to reach A2, it could directly do so.
- What do you think, could B.A.T.M.A.N be a solution?
Yes, BATMAN could help in this situation - its better than doing it statically at least, since batman can decide how many intermediate hops to skip.
- Could the short distance be a problem?
well you have interference between the nodes and the typical throughput limitations because of the half-duplex nature of WiFi. But if you take that into consideration and don't expect the same throughput as on a single link, 3-4 meter should be fine.
It also depends on what kind of data you will send (many industrial applications use broadcast, for example).
- Is it possible to regulate the transmission power in order to avoid disturbance?
There are WiFi driver which allow that, yes. However I'd recommend to keep it as it is and change the broadcast rate to something higher (e.g. 18M or more) to force to only use good links, even if they are a little shorter.
Cheers, Simon
On Wed, Mar 12, 2014 at 11:36:16AM +0100, Simon Wunderlich wrote:
Gateway - A1 - A2 - A3 - A4 - A5 - ... - A120 Gateway - A9 - A17 - A1 - A47 - A9 - ... - A6 [...]
- What do you think, could B.A.T.M.A.N be a solution?
Yes, BATMAN could help in this situation - its better than doing it statically at least, since batman can decide how many intermediate hops to skip.
That's what I hoped.
- Could the short distance be a problem?
well you have interference between the nodes and the typical throughput limitations because of the half-duplex nature of WiFi. But if you take that into consideration and don't expect the same throughput as on a single link, 3-4 meter should be fine.
Do you have any good literature/link recommendation where I could learn more about the low level WiFi mechanics?
It also depends on what kind of data you will send (many industrial applications use broadcast, for example).
Broadcast is not necessary, all traffic is generated somewhere on the line and sent out to the Gateway. The datasets are in the 500 KiB range, it could be UDP or TCP, not decided yet. But it's definitely unicast.
- Is it possible to regulate the transmission power in order to avoid disturbance?
There are WiFi driver which allow that, yes.
Can you give me a hint which feature I need to search for in the kernel drivers?
As the stations will be built from scratch (SoC+RAM+Flash+Wifi-Chipset), we can chose the right chipsets, as long as it's possible to buy them somewhere.
However I'd recommend to keep it as it is and change the broadcast rate to something higher (e.g. 18M or more) to force to only use good links, even if they are a little shorter.
Ok. I'll setup a bunch of prototype devices in the first place anyway, so we can try it out then.
Thanks for the infos!
rsc
Hey Robert,
- Could the short distance be a problem?
well you have interference between the nodes and the typical throughput limitations because of the half-duplex nature of WiFi. But if you take that into consideration and don't expect the same throughput as on a single link, 3-4 meter should be fine.
Do you have any good literature/link recommendation where I could learn more about the low level WiFi mechanics?
Mhm, I'd generally recommend the Matthew Gast books on 802.11, these are very good.
The throughput limitation I'm talking about is a mesh-network specific problem when you use single radios only: as a wifi radio can only transmit or receive at the same time, the throughput will be cut to 50% with the first hop, and will decrease furhter with more hops. I don't know if there are books about such effects, but there are certainly papers ...
It also depends on what kind of data you will send (many industrial applications use broadcast, for example).
Broadcast is not necessary, all traffic is generated somewhere on the line and sent out to the Gateway. The datasets are in the 500 KiB range, it could be UDP or TCP, not decided yet. But it's definitely unicast.
OK, then you can use high datarates too.
Is it possible to regulate the transmission power in order to avoid
disturbance?
There are WiFi driver which allow that, yes.
Can you give me a hint which feature I need to search for in the kernel drivers?
ath9k supports that for example. you can set the txpower using "iw wlan0 set txpower 1500" for example to set to 15dBm output pwoer
As the stations will be built from scratch (SoC+RAM+Flash+Wifi-Chipset), we can chose the right chipsets, as long as it's possible to buy them somewhere.
I'd definitely recommend to buy WiFi modules (e.g. pci-e) or off-the-shelf boards with WiFi SoCs on it. If you don't have experience in building WiFi routers, you might have a lot of fun otherwise. :)
However I'd recommend to keep it as it is and change the broadcast rate to something higher (e.g. 18M or more) to force to only use good links, even if they are a little shorter.
Ok. I'll setup a bunch of prototype devices in the first place anyway, so we can try it out then.
Thanks for the infos!
Good luck! Simon
Hi Simon,
On Wed, Mar 12, 2014 at 02:51:09PM +0100, Simon Wunderlich wrote:
Mhm, I'd generally recommend the Matthew Gast books on 802.11, these are very good.
Thanks, sounds good! Is "802.11 Wireless Networks: The Definitive Guide" recent enough? Seems to be from 2005.
The throughput limitation I'm talking about is a mesh-network specific problem when you use single radios only: as a wifi radio can only transmit or receive at the same time, the throughput will be cut to 50% with the first hop, and will decrease furhter with more hops. I don't know if there are books about such effects, but there are certainly papers ...
Will search.
Would having a 2nd transmitter help?
Can you give me a hint which feature I need to search for in the kernel drivers?
ath9k supports that for example. you can set the txpower using "iw wlan0 set txpower 1500" for example to set to 15dBm output pwoer
Thanks, txpower is a good hint.
As the stations will be built from scratch (SoC+RAM+Flash+Wifi-Chipset), we can chose the right chipsets, as long as it's possible to buy them somewhere.
I'd definitely recommend to buy WiFi modules (e.g. pci-e) or off-the-shelf boards with WiFi SoCs on it. If you don't have experience in building WiFi routers, you might have a lot of fun otherwise. :)
The issue is that the stations need to be very low power, so I'd like to leave everything out which draws power but isn't absolutely needed. The HF part should be solvable, that's something the hardware developers have experience with. I'm aiming for a low power ARM cpu, which basically rules out anything that needs PCIe and leaves us with SDIO or USB for the connection of the transmitters.
rsc
I'd definitely recommend to buy WiFi modules (e.g. pci-e) or off-the-shelf boards with WiFi SoCs on it. If you don't have experience in building WiFi routers, you might have a lot of fun otherwise. :)
The issue is that the stations need to be very low power, so I'd like to leave everything out which draws power but isn't absolutely needed. The HF part should be solvable, that's something the hardware developers have experience with. I'm aiming for a low power ARM cpu, which basically rules out anything that needs PCIe and leaves us with SDIO or USB for the connection of the transmitters.
I'm hoping i can get my hands on one of these soon:
http://www.logicpd.com/products/system-on-modules/dm3730-torpedo-wireless-so...
There is a kernel patch around for one of the Yocto kernels, which i expect you guys would have no trouble cleaning up.
Andrew
On Wed, Mar 12, 2014 at 03:54:48PM +0100, Andrew Lunn wrote:
I'd definitely recommend to buy WiFi modules (e.g. pci-e) or off-the-shelf boards with WiFi SoCs on it. If you don't have experience in building WiFi routers, you might have a lot of fun otherwise. :)
The issue is that the stations need to be very low power, so I'd like to leave everything out which draws power but isn't absolutely needed. The HF part should be solvable, that's something the hardware developers have experience with. I'm aiming for a low power ARM cpu, which basically rules out anything that needs PCIe and leaves us with SDIO or USB for the connection of the transmitters.
I'm hoping i can get my hands on one of these soon:
http://www.logicpd.com/products/system-on-modules/dm3730-torpedo-wireless-so...
There is a kernel patch around for one of the Yocto kernels, which i expect you guys would have no trouble cleaning up.
Nice little system. I already have the TI WiLink chips on my list of possible devices (we have an older one on an SDIO card for testing).
Thanks for the pointer!
rsc
Hi,
On 12 Mar, 2014, at 18:20 , Robert Schwebel r.schwebel@pengutronix.de wrote:
On Wed, Mar 12, 2014 at 03:54:48PM +0100, Andrew Lunn wrote:
I'd definitely recommend to buy WiFi modules (e.g. pci-e) or off-the-shelf boards with WiFi SoCs on it. If you don't have experience in building WiFi routers, you might have a lot of fun otherwise. :)
The issue is that the stations need to be very low power, so I'd like to leave everything out which draws power but isn't absolutely needed. The HF part should be solvable, that's something the hardware developers have experience with. I'm aiming for a low power ARM cpu, which basically rules out anything that needs PCIe and leaves us with SDIO or USB for the connection of the transmitters.
I'm hoping i can get my hands on one of these soon:
http://www.logicpd.com/products/system-on-modules/dm3730-torpedo-wireless-so...
There is a kernel patch around for one of the Yocto kernels, which i expect you guys would have no trouble cleaning up.
Nice little system. I already have the TI WiLink chips on my list of possible devices (we have an older one on an SDIO card for testing).
Thanks for the pointer!
For an complete solution you can have this nice device:
http://8devices.com/carambola-2
Appart from GPS it has all the features
Bruno
rsc
Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Hi,
On Mon, Mar 31, 2014 at 12:06:24PM +0100, Bruno Antunes wrote:
For an complete solution you can have this nice device:
http://8devices.com/carambola-2
Appart from GPS it has all the features
There are some more constraints which rule out the (otherwise nice) carambola2. We need extended temperature range, long term availability on chip level and some other missing peripherals.
However, thanks for the hint :-)
rsc
b.a.t.m.a.n@lists.open-mesh.org
-
Andrew Lunn -
Bruno Antunes -
Robert Schwebel -
Simon Wunderlich