Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple Radio Support #25

Open
ehresman opened this issue Jan 31, 2014 · 4 comments
Open

Multiple Radio Support #25

ehresman opened this issue Jan 31, 2014 · 4 comments

Comments

@ehresman
Copy link

Scott:

The Pi has the horsepower to support multiple radios (with a high current USB hub).

My thought is it would be useful to be able to set up individual radios with completely different profiles. I can think of 3 immediately I wish I could do.

  1. Mesh (of course)
  2. Access Point
  3. Client

Imagine a Pi with 3 radios in it. One on an HSMM mesh, one providing AP to those nearby, and a client radio providing WAN off a public access point. Add in a simplified GRE configuration, and it would be a snap to pop up an adhoc mesh node that connects back through Starbucks to a larger but RF unreachable mesh.

Pis could support routing between different frequency bands such as 13, 9 and 5 cm. One Pi, multiple radios.

73;
Bob KV4PC
kv4pc at qsl dot net

@urlgrey
Copy link
Owner

urlgrey commented Jun 12, 2014

Duplicate of #5. I really like the use-case you described, and will consider adding this feature in the future!

@bsl2ck
Copy link

bsl2ck commented Apr 11, 2016

Has any progress been made on this enhancement. I am looking to create a backhaul 5.8ghz mesh atop the 2.4ghz meshes that support users. so I would need some of the 2.4ghz nodes to also have a 2nd 5.8ghz radio as their wan port and a series of 5.8ghz radios in a separate mesh with some as external gateways as well. Is anything close to that capable with the software today? I know that I could do some of this by pairing a 2.4ghz and a 5.8ghz PIs for the backhaul gateway access points, but that gets more expensive and complex. I would also have a problem in reversing the wan/lan structure on the backhaul gateways.
Any thoughts?

@mathisono
Copy link
Contributor

Spend you money and effort buying ubiquity hardware. I dont think the Rpi platform is going to preform well as "Backhaul". Once you get Antennas and enclosures, powersupplys, usb hubs. Its not well suited for thru-put 5mb max. Check out AREDN.

Mesh + AP is a good idea except There is going to be inter-modulation between the radios. I run my HSMM-pi node with a Mesh-lan on the ether Ethernet port... so I think running an AP would let me connect via my android, and have ez access to ARDEN apps like MeshChat on my phone.

One of the AREDN Site that's Solar powered has a AP for regular wifi access. As that its on the 11th floor, Wifi helps bridge the gap.

@bsl2ck
Copy link

bsl2ck commented Apr 11, 2016

On 4/11/2016 2:14 PM, mathison wrote:

Spend you money and effort buying ubiquity hardware. I dont think the
Rpi platform is going to preform well as "Backhaul". Once you get
Antennas and enclosures, powersupplys, usb hubs. Its not well suited
for thru-put 5mb max. Check out AREDN.

Mesh + AP is a good idea except There is going to be inter-modulation
between the radios. I run my HSMM-pi node with a Mesh-lan on the ether
Ethernet port... so I think running an AP would let me connect via my
android, and have ez access to ARDEN apps like MeshChat on my phone.

One of the AREDN Site that's Solar powered has a AP for regular wifi
access. As that its on the 11th floor, Wifi helps bridge the gap.


You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#25 (comment)

I was considering other hardware platforms such as the Ubiquiti
devices. But I am concerned that I have started to see vendors like
TP-Link state that they will no longer allow firmware downloads to their
newer devices as an easy way to comply with the FCC certification
requirements from last year. I believe I saw something on the Ubiquiti
site stating a similar position. Thus, I was exploring the possibility
of doing the similar tasks with general purpose devices that I could
hook together to get the same job done. I totally agree that that would
be no where near as optimum or cost efficient. Again just defensive
thinking.
Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants