I have an idea and would like to get a sense as to whether there is interest is pursuing it.  Thus I would appreciate feedback.

The current broadband mesh development effort is based on the use of Ubiquity routers.  While this has served well we are still limited by some of the decisions made by he manufacturer.  For example this limits the ability to access certain ham bands and it limits the available power levels.  In this context would there be an interest in a router hardware platform that would allow Hams to modify the lower level firmware, and to add transceivers for different Amateur bands.  Other capabilities are open for discussion.

I know an experienced hardware engineer who might be interested in leading the effort.  We would need somebody with the skills and interest to write firmware to support the BBHN software.  This could be somebody in your group or somebody else willing to work closely with your group.

Initially the router would be released in a kit form.  Later versions would be fully assembled and have FCC certification.  While the mature versions of the platform would be a commercial product the idea is that there would be documented interfaces to allow for extensive customization.  It could come with the HSMM-Mesh software preinstalled.  The idea is that a Ham could buy one of these units and use it in a plug and play mode or he/she could modify it if she/he has the need and the desire.

The idea is in the formative stages and your input would be appreciated.  What do you see as the demand for such a router.

KD6MZC

Well...

• Power adjustable in 1dB increments up to 1watt
• Coverage throughout the 900MHz, 2.4GHz, 3.4GHz, 5.8GHz ham band (not limited to ISM bands)
• Supports both CSMA and TDMA protocols
• Supports MIMO
• Configurable parameters down at the RF protocol level
• Military environmental specs
• PoE powered
• Easily tower mountable
• Remote reset via Ethernet cable

 That's a start.  Interesting proposition.  Can't be an easy assignment.

Andre, K6AH

The cost of the hardware is a non-trivial factor to consider. While there is great appeal to extend bbhn image support for the features that ubiquiti lacks, the hardware will inherently be higher cost--from $100 to $100s for a node-antenna--particularly for support in the non-ISM bands. The hardware designed for and supported in the ISM bands has economies of scale to drive down the cost.

If the more capable hardware/device being considered is supported by the OpenWRT community, then this could be considered for bbhn support. If the hardware was not supported by OpenWRT, then it is unlikely to ever be a candidate for bbhn. The effort to port bbhn to a non-OpenWRT device would be exponentially more.  If OpenWrt community doesn't extend support to any hardware you are considering, there may be a reason why they wouldn't.

Joe AE6XE

Glenn All depends what route and what hardware he goes with.

If he does what I think he might do (Atheros chipset)  for the WIFI modem  it actually becomes very trivial to make OpenWRT work with it.   Atheros chips have a wide design range (You can almost go from DC to Daylight with their chipsets)  and they are designed to do such (though much more heavily used in the ISM bands)  or if it uses a different method all together it just has to be implemented into Linux user space

The biggest factors from my standpoint as a developer whom has actually worked on the code when taking in the context of Atheros is calibration data. Over the past year I understand now that going away from the preset calibration channels means we switch to an extrapolated calibration and not calibration for each channel.  We would want to embed this into the new devices (to provide wider access)  if such a device required it.  Patches would then need to be submitted to us (not necessarily OpenWRT)  to be able to pull that caldata into the system.

The same holds true for Operating System, as long as we can get patches to make the firmware work (which is much easier to do when the "vendor" is willing to say "RF chip is on I/O pins 1,2,3,4,  LED's are IO pins 5,6,7,8    Power feedback control is done via blah" vs the reverse engineering that normally has to be done (still not that easy, but easier at least)

I will +1 the weather resistant side, maybe not MILSPEC but these need to be able to handle the similar range as a Ubquiti for me to be able to use them in my personal network.

And yes probably don't go Broadcom, Atheros is much more open source friendly (to the extent they actually publish code)  Glenn forgets this is part of the reason the Linksys had to EoS'ed because it was far too closed to actually fix anything bugs with (Like wifi: the modem was its own independent module, all you could do was tell it was basic things, it actually if you look at the hardware design is a fully self contained ethernet to wifi bridge chip aka its own wifi device inside a wifi device design)

Ultimately though it could be any vendor, or even a 100% custom design, as long as the drivers got written for the Linux kernel and patches provided to integrate it into the OpenWRT buildroot.