L.S.
Recent events may have forced the need for more clarity. Perhaps sooner that really needed. So far we've mostly don the technical issues.
I'm going to tap into the collective brain here.
In order to protect the EOMA standard. To what terms should a manufacturer/vendor comply to become EOMA compliant?
Things like: - Technical: Adhere tot the physical dimensions, tolerance, heat. - Safety - What would be a reasonable price/pricing structure - Environmental footprint - etc.
And how to deal with leeches and blacklists etc.
I know the technical side is already coming along but anything you like to to mentioned write it down.
Luke join if you like, but we know you are busy, collecting funds to pay the bill etc. And the technical side of things still need some tinkering, USB3, etc.
Kr, Mike
Mike, great call.
Firstly I'd like to refer to the Arduino-approach, which seems to be rather refined: 0) Official Arduino products 1) Certification: A certification program which strongly integrates the product in the official Arduino line of products. (https://arduino.cc/en/ArduinoCertified/) 2) Regulation: Via the Arduino AtHeart project. Some minimal requirements on technology and openness, a fee, and a marketing-deal benefiting both the regulator and the regulated. (https://arduino.cc/en/ArduinoAtHeart/) 3) Recommended: Single-sided plug by the Arduino-crew on their homepage. 4) Other related hardware: Arduino-maintained list of compatible products covering all types and boards also (https://playground.arduino.cc/Main/SimilarBoards) 5) Unregulated: Any party can call their products 'Arduino-compatible', like the Sparkfun RedBoard. (https://www.sparkfun.com/products/11575)
I assume that both regulation and certification would require certain technical compatibility although the officially stated requirements are quite limited.
What I like about that way of certification is that it is not a requirement, but if you do, it creates a synergistic relationship between both parties.
More overall requirements related to EOMA I would assume to be: - Meeting consumer certifications (FCC, CE). - Preventing faulty installation by way of enclosure (shifting pin-out or rotating EOMA). - Proper handling of signals when plugging. - Withstanding power outages. - Withstanding all possible operating states.
As for what low-level technical requirements are feasible and how to test them, I have no knowledge on that.
Kind regards, Nico Rikken
just wanted to contribute my knowledge and vision
On Wed, May 28, 2014 at 9:23 PM, Nico Rikken nico@nicorikken.eu wrote:
Mike, great call.
Firstly I'd like to refer to the Arduino-approach, which seems to be rather refined:
nico this is absolutely great. thank you
arm-netbook@lists.phcomp.co.uk