<div dir="ltr">Hello,<div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 5, 2016 at 3:42 PM, Jonathan Morton <span dir="ltr"><<a href="mailto:chromatix99@gmail.com" target="_blank">chromatix99@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> We need to be able to have Mesh Extenders imported into practically any country at short notice, e.g., if we succeed in having the Red Cross/Crescent movement adopt them.<br>
><br>
</span><span class="">> Where it gets complicated is if we have the <insert random small pacific, african, european, south american, middle-eastern or other country here> regulator and customs people want a rapid assurance that the devices cannot be operated except on some band (which they might authorise for us at short notice to meet a humanitarian need).<br>
<br>
</span>“Complicated” isn’t the word.  “Fundamentally incompatible requirements” is.<br>
<br>
On the one hand, you need to be able to “rapidly reconfigure” your hardware for a different frequency band, at short notice, from generic stock, and without making actual hardware changes.<br>
<br>
On the other hand, you anticipate needing to be able to show that the preceding action *cannot* be done to these same devices once deployed in the field.<br>
<br>
You have a big problem here.  Something has to give.<br></blockquote><div><br></div><div>Agreed in general.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
As a related problem, consumer-grade APs are already easy to physically transport between Europe, America and Asia.  I’ve literally done that myself on occasion while visiting; I have a habit of bringing a reasonably complete computing environment with me wherever I go.<br>
<br>
But my European AP is not FCC-compliant, because it is trivially capable of transmitting on frequencies that are not permitted in the USA (eg. 2.4GHz channels 12 & 13).  What’s more, it cannot be made FCC-compliant, even temporarily, because the firmware is locked down so that I can only select from European regulatory domains.  I suspect there’s a jumper somewhere enforcing this.<br>
<br>
I think the correct solution is as follows:<br>
<br>
1: Allow software-level reconfiguration of the radios.  Make it as easy as possible to select the correct regulatory domain, using geolocation if practical.  Before selling/deploying hardware, set it up correctly for its intended region, or for a failsafe composite region which is compliant in all of the most common domains.<br></blockquote><div><br></div><div>Unfortunately we know from the TP-LINK case just now, that the FCC doesn't like this, and experience from RC and others, is that the staff on the border during disasters also get cagey about any purely software option.  </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2: Make the end-user liable for the emissions of his hardware, if he has explicitly set an incorrect regulatory domain or made hardware modifications (eg. to increase its power output).  Place a prominent notice, as Juliusz suggested, informing the end-user of this responsibility. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This solves both problems: freedom and flexibility is retained, and the FCC still has a way to enforce the regulations (with boots on the ground).<br></blockquote><div><br></div><div>Except that they will instead enforce (as will many other national regulators) by declining approval to import/use.  We know stories from RC national societies where it has taken weeks to get vital communications components in because the people at the border didn't feel comfortable -- and this is a key point: If we can straight-faced say that this hardware (ME + cable) can only operate on the approved band(s) for that country, then they will wave it through. If not, it will get held up for weeks.</div><div><br></div><div>This is why I have gone for the minimum hardware restraint, that is by design, able to be easily bypassed by the people who need to do so.  Also, the value of being able to configure the device for a region simply by supplying the correct lead should not be underestimated, because it removes a significant training/deployment complication.  </div><div><br></div><div>I should also add, that the power cables for countries that don't get upset if there is only software configuration preventing use of other bands, that we can wire those cables to allow 3rd party firmware -- that is, we can minimise the hardware interlock to exactly only those places that need it, and it can be left to software in all other jurisdictions.</div><div><br></div><div>That is, with the power cable approach, we can simply give devices to people, they turn them on, and they are automatically operating in the correct regional settings.  This is not possible with the software approach.  Can you think of a solution to this ease of deployment problem with the purely software approach?  Similarly, can you think of a solution to overstrained border personnel using only software (and the related problem of regulatory approval)?</div><div><br></div><div>Paul.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
 - Jonathan Morton<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
Battlemesh mailing list<br>
<a href="mailto:Battlemesh@ml.ninux.org">Battlemesh@ml.ninux.org</a><br>
<a href="http://ml.ninux.org/mailman/listinfo/battlemesh" rel="noreferrer" target="_blank">http://ml.ninux.org/mailman/<wbr>listinfo/battlemesh</a><br>
</div></div></blockquote></div><br></div></div>