DIY long lasting voltage regulator circuit for Raspberry Pi

Jithin @ rootsaid.com writes:

Raspberry Pi is simple, handy and cheap yet powerful single board computers of all time. It has USB ports to connect hardware such as pen drive, keyboard, mouse, HDMI port for display out, 3.5 mm port for audio and several GPIO pins to work with embedded projects, all of which can be powered using a mobile charger. You can even make it portable by simply connecting the mini USB port to a mobile phone power bank so that you can use your pi on the go. But if you connect more USB devices and use the GPIO pins, the power bank will drain off quickly. In this post, I will tell you how i made my own power supply unit using a Lithium Polymer battery and a voltage regulator.

Project info at rootsaid.com.

Read more »

Enginursday: Switching Sensors with a WS2811 Addressable LED Driver

Sometimes we sign up to do crazy things - like going skydiving with your best friend or running a marathon in flip flops. In this case I wound up hatching a plan to use 192 of the same I2C sensor in an interactive installation. As the sheer size and complexity of the goal sank in I grew increasingly curious if there was a simple way to wire all those sensors together. The result is elegant in theory, noisy in reality, and probably won't work at scale. However it is really fun to talk about so stick around to hear about using addressable LED drivers as software switches!

A Collaborative Staff

The task: create an interactive installation that allows young children to play with sound and color collaboratively. When the Museum of Boulder asked me and Joe Ryan create this we started thinking big! Joe's fantastic idea was to create a larger-than-life musical staff that kids could place notes on to craft their very own song. The color of the notes would determine what kind of instrument was used. After settling on a size (four measures, four positions per measure, and 12 notes per position) we needed to find a way to actually make it work.

Color Nodes

Sensing colors has been made easy by ICs such as the ISL29125. The general idea was to use one of these at every note position along with an addressable LED that could be used to both illuminate the notes for a reading and serve as a visual guide for getting started. A central system would take readings to determine which notes should be played and by which instruments. The challenge was to connect 192 I2C devices that all use the same address.

There are several ways to accomplish this task - perhaps using a tree of I2C multiplexers, using several independent sensing groups each with its own microcontroller, and even extravagant methods using wireless communication. I went in search of a solution that would minimize cost and installation complexity. What I found was the WS2811 addressable LED driver IC.

WS2811-Based Switch Design

Knowing that LED data would need to be sent to every node gave me an idea - what if the power to the color sensor could be controlled in the same way? Perhaps this would allow all the sensors to share one I2C bus, as long as only one was powered at a time. In retrospect it is hard to remember which search terms exactly led me to what I needed but eventually I found the datasheet for the WS2811. A companion to the popular WS2812B addressable led, the WS2811 encapsulates the same driver but instead breaks out the R, G and B output pins so that you can attach your own LEDs.

The datasheet indicated that the outputs were constant-current drains of up to 18.5 mA. Not ideal - a controllable voltage output would have been simpler to use but fortunately we know how to convert current to voltage and vice-versa.

V = I • R
I = 18.5 mA
V = 3.3 V (using ISL29125 supply voltage)
R = V / I = (3.3 / 0.0185) = 178.37 ?

A 178.37 ohm resistor with 18.5 mA current flowing through it will drop 3.3 V. In other words a constant current driver set to pull 18.5 mA from 3.3 V through a 178.37 ohm resistor would need to set its output at 0V!

Now it's not quite that simple, unfortunately. It would be if the LED driver was a true "analog" constant current driver, but LED drivers typically use Pulse Width Modulation (PWM) to approximate constant current. The duty cycle of the PWM signal is what we perceive as the brightness of the LED. When trying to use an LED driver as a switch you run into a problem - your switch changes quite frequently, even when you have it set to just one value!

PWM Cuty Cycle Diagram

pwm duty cycle diagram
Image: Android Developer's Site

You might hope that asking the LED for either a 0% or 100% duty cycle would work well enough, but we can't guarantee how the driver operates. In the case of the WS2811 I found that a channel value of 0 results in a true 100% duty cycle (this makes sense for a common anode LED driver), but the max value (255) only approaches a 6% duty cycle.

The ability to reach a true 100% duty cycle is good for powering the sensor because it means minimal noise. The fact that the supply voltage will occasionally come up, however, is concerning because that may cause any one of the sensors to turn on and interfere with communication on the I2C bus. In order to combat this I used a low-pass RC filter that incorporates the current-limiting resistor.

The WS2811 uses a PWM frequency of 2 kHz, so a 6% pulse would have a width of (6 / 100) • (1 / 2000) = 30 ?s. A 30 ?s square wave pulse contains many frequency components, the slowest of which is (1 / 30 ?s) = 33.3 kHz. In order to block that frequency one would choose a corner frequency below that value. Using a simulated circuit on falstad.com/circuit, I played around with various capacitor values to get a good balance of high-frequency blocking (higher capacitor values) and the time it takes to power on a sensor (low capacitor values)

falstad circuit simulator for RC filter on LED driver output

falstad.com/circuit simulation of WS2811 switch

fc = 1 / (2 • ? • R • C)
R = 220 ? (choose a common resistor value greater than 170.37 ?)
C = 1 ?F
fc = 1 / (2 • ? • 220 • 1 • 10-6) = 723 Hz

Using the design parameters from above I laid out a prototype schematic and board in Eagle.

circuit schematic in Eagle PCB

Testing

In an effort to move quickly I ordered PCBs and the WS2811 driver ICs at the same time. In fact my original design used a slightly more complicated circuit that I was able to simplify during testing. We've been discussing the simpified circuit but the boards contain a few extra components and a host of white-wire fixes. That's a lesson in why you should always do a 1:1 scale package check for any new parts that you intend on using! Below is an image of the prototype as tested:

prototype v01 with white wire fixes and simplified circuit

To test the board I wrote a quick test sketch. It uses the FastLED library to control the LED data line (for the WS2811 as well as the WS2812B illumiator LED), and the SparkFun ISL29125 Arduino library to read from the RGB sensor.

/******************************************************************************
Color_Node_Test.ino

Test sketch for for turning on/off an ISL29125 RGB sensor using a WS2811 LED 
driver IC. 

Owen Lyke 
25 Mar 2020

Requires:
SparkFun_ISL29125_Arduino_Library
FastLED library by Daniel Garcia
ESP32 based microcontroller such as the SparkFun ESP32 Thing Plus (https://www.sparkfun.com/products/15663)

Setup:
- Build your own color node based on the schematics shown at: https://www.sparkfun.com/news/3266
- Connect the I2C pins SCL and SDA to the Wire port of your ESP32 based board
- Connect the LED data line to pin 18 of the ESP32 on your board
- Connect GND and 5V lines

This code is beerware.
Distributed as-is; no warranty is given. 
******************************************************************************/

/********************/
/* USER SETUP BEGIN */

#define DISPLAY_TITLES 1      // 1 to print field names to serial
#define DISPLAY_RGB 0           // 1 to print r g b values to serial
#define DISPLAY_HUE 1           // 1 to print computed h value to serial
#define DISPLAY_COLOR 1         // 1 to print nearest color to serial

// Define a type to hold detectable colors
typedef struct _color_t 
  float hue;
  const char* name;
color_t;

// Here's the list of colors that the system can name on its own (you may add your own based on hue angle [0.0, 360] )
color_t colors[] = 
  0.0, "Red",
  60.0, "Yellow",
  120.0, "Green",
  180.0, "Cyan",
  240.0, "Blue",
  300.0, "Magenta",
;

/* USER SETUP END */
/******************/

// Includes
#include <math.h>
#include <Wire.h>
#include <FastLED.h>          // Click here to get the library: http://librarymanager/All#FastLED_Daniel_Gracia
#include "SparkFunISL29125.h" // Click here to get the library: http://librarymanager/All#SparkFun_ISl29125

// RGB sensor control
SFE_ISL29125 RGB_sensor;
unsigned int red = 0;
unsigned int green = 0;
unsigned int blue = 0;

// WS2811 / WS2812B control
#define DATA_PIN 18
#define NUM_LEDS 2    // Each color node has two 'leds' - one WS2811 to control the sensor power and one WS2812B for illumintation
CRGB leds[NUM_LEDS];

void setup() 
  Serial.begin(115200);                                     // Start Serial 

  FastLED.addLeds<WS2811, DATA_PIN, RGB>(leds, NUM_LEDS);

  sensorPower(true);
  FastLED.show();
  delay(1000);

  while(!RGB_sensor.init())                                // Initialize the ISL29125 with simple configuration so it starts sampling
    Serial.println("trying to start the sensor!");
    delay(50);
  
  Serial.println("Sensor Initialization Successfulnr");


void loop() 
  /* Begin Taking a Reading */

  sensorPower(true);                // Turn on the sensor  
  setLED(200, 200, 255);            // Turn on the LED to illuminate the subject area
  FastLED.show();                   // ^- adjust the balance of white here... blue seems to need some help (higher Vf than other leds..)

  delay(2);                         // some time for sensor to come online
  RGB_sensor.init();                // now perform initialization since the sensor had been asleep

  delay(200); // sensor continuously runs ADC at ~ 10 hz so to be sure wait 0.2 seconds before reading

  delay(300); // delay to combat voltage sag from turning on all the leds...
              // I've experimentally determined that while there is no LED brightness that completely 
              // eliminates noise in detected color there is a minimum total delay between turning on
              // the leds and taking a sample that gets darn close. Its approx 500 ms total (including
              // time dedicated to letting the sensor read)

              // the final product may as well turn on all the leds, wait half a second, and then sample
              // all of the color sensors rapidly. 


  red = RGB_sensor.readRed();     // Sample the sensor
  green = RGB_sensor.readGreen();
  blue = RGB_sensor.readBlue();


  sensorPower(false);             // Turn off the sensor
  setLED(0, 0, 0);                // Turn off the LED
  FastLED.show();                 // Apply changes to the 'LED' data (includes WS2811 'switch' changes)

                                  // Now let's try to sample the sensor to show that it has really been shut down
  delay(1);                       // Time for the sensor VDD line to fall to 0
  RGB_sensor.init();
  RGB_sensor.readRed();
  RGB_sensor.readGreen();
  RGB_sensor.readBlue();

  printResults();                 // Show the results on the Serial monitor

  delay(200);                     // delay 200 ms before taking another reading


void sensorPower(bool on)
  LEDS.setBrightness(255);                                  // Ensure full brightness so that WS2811 controls are not scaled

  if(on)
    leds[0] = CRGB(0, 0, 0);                                // Turn on the sensor by writing a 0 value to the R channel
  else
    leds[0] = CRGB(255, 0, 0);                              // Turn off the sensor by writing 255 to the red channel
  


void setLED(uint8_t R, uint8_t G, uint8_t B)
  leds[1] = CRGB(R, G, B);                                  // The LED is the second item in the 'led' array (the first is the WS2811 sensor switch)




/*********************/
/* UTILITY FUNCTIONS */

float max3( float Rp, float Gp, float Bp, uint8_t* index )
  // hacky way to find maximum of three (not tested well or even well-thought-through)...
  float Cmax = 0.0;
   if(Rp >= Gp)
      if(Rp >= Bp)
        Cmax = Rp;
        *index = 0;
      
    
    if(Gp >= Bp)
      if(Gp >= Rp)
        Cmax = Gp;
        *index = 1;
      
    
    if(Bp >= Gp)
      if(Bp >= Rp)
        Cmax = Bp;
        *index = 2;
      
    
    return Cmax;


float min3( float Rp, float Gp, float Bp, uint8_t* index )
  // hacky way to find minimum of three (not tested well or even well-thought-through)...
  float Cmin = 0.0;
   if(Rp <= Gp)
      if(Rp <= Bp)
        Cmin = Rp;
        *index = 0;
      
    
    if(Gp <= Bp)
      if(Gp <= Rp)
        Cmin = Gp;
        *index = 1;
      
    
    if(Bp <= Gp)
      if(Bp <= Rp)
        Cmin = Bp;
        *index = 2;
      
    
    return Cmin;


void printResults( void )
    float Rp = (float)red/255;
    float Gp = (float)green/255;
    float Bp = (float)blue/255;

    uint8_t max_ind = 0;
    uint8_t min_ind = 0;
    float Cmax = max3(Rp, Gp, Bp, &max_ind);
    float Cmin = min3(Rp, Gp, Bp, &min_ind);
    float delta = Cmax - Cmin;

    float hue = 0.0;
    if(Cmax == 0.0)
      hue = 0.0;
    else
      switch(max_ind)
        case 0: hue = 60 * (fmod(((Gp-Bp)/delta), 6.0)); break;
        case 1: hue = 60 * (((Bp-Rp)/delta) + 2); break;
        case 2: hue = 60 * (((Rp-Gp)/delta) + 4); break;
        default: break;
      
    

    // search list of colors for the closest one 
    //  (todo: when overall lux levels are low just say nothing is there)
    const char* identified_color = NULL;
    float prev_diff = 360.0;                              // start with a high (impossibly so) difference
    float diff = 0.0;
    uint8_t num_colors = sizeof(colors)/sizeof(color_t);
    for(uint8_t indi = 0; indi < num_colors; indi++)     // loop through all the named colors
      diff = abs(hue - colors[indi].hue);                     // find the difference between the selected color hue and the calculated hue
      if ( diff >= 180.0 )                                   // correct for differences over 180 degrees because the spectrum is circular
        diff = 360.0 - diff;
      
      if( diff < prev_diff )                                 // if this difference is smaller change the detected color to this name
        prev_diff = diff;
        identified_color = colors[indi].name;
      
    

#if DISPLAY_RGB
#if DISPLAY_TITLES
    Serial.print("B: "); 
#endif
    Serial.print(blue);
    Serial.print(" ");

#if DISPLAY_TITLES
    Serial.print("R: "); 
#endif
    Serial.print(red);
    Serial.print(" ");

#if DISPLAY_TITLES
    Serial.print("G: "); 
#endif
    Serial.print(green);
    Serial.print(" ");
#endif

#if DISPLAY_HUE
#if DISPLAY_TITLES
    Serial.print("Hue: ");
#endif
    Serial.print(hue);
    Serial.print(" ");
#endif

#if DISPLAY_COLOR
#if DISPLAY_TITLES
    Serial.print("Color: ");
#endif
    Serial.print(identified_color);
    Serial.print(" ");
#endif

    Serial.println();

Using a digital logic analyzer I was able to record some great data. You can see that the rise time of the sensor VDD line matches what is expected from the simulation, as well as the same small ripples when the sensor is turned off. You can also see that the sensor responds to I2C transactions while it is powered. Shortly after sending the 'off' command, the VDD line falls and the sensor no longer responds to I2C transactions. This suggests that turning off unused sensors should be enough to allow using more than one sensor on the same I2C bus.

digital logic analzer trace of sensor VDD line and I2C transactions

Further Considerations

This project is a work in progress. To scale this single test up to an array of 192 nodes will present more challenges such as:

  • Sample speed - the test above does not leave any time for the sensor to make ADC conversions, so the readings come out as 0. In reality each sensor will need to be on for 100 to 200 ms to get a good sample.
  • I2C Bus Capacitance - generally it is challenging to use I2C over long distances because of the open-drain topology.

These challenges will likely preclude the use of this method in the Rainbow Forest project. Still, using the WS2811 in creative ways could like this can be useful in a host of projects that already involve addressable LEDs such as model train layouts, DIY LED shows with special effects, and much more!

If you use the WS2811 in a project of your own let us know!

comments | comment feed

Read more »

From Qwiic Temp Sensing to Binho USB Hosting

Hello everyone and welcome to another Friday Product Post. We have been hard at work while staggering shifts and maintaining physical distance to make sure new products still arrive. We may not have a huge amount every week for a while, but we are doing our safest and best!

This week we start a new version of our classic TMP102 Digital Temperature Sensor, now with Qwiic! Following our new sensor, we have three new Binho products including a USB host hub, breadboard breakout, and a Qwiic adapter. We finish out the week with the Logitecch C270 webcam - it can be found in the SparkFun DLI Kit for Jetson Nano but it can also be really helpful if you are working from home.

Speaking of which, do you have bored kids at home? Keep them engaged and learning with the help of our Spring Kit Sale - available through April 17th! Designed with beginners in mind, these kits offer a springboard into electronics through circuit building, creating e-textile crafts, measuring the weather, practicing soldering, and exploring the Internet of Things (IoT).

Now onto the new products!

Qwiic, cheap and digital temperature sensing

SparkFun Digital Temperature Sensor - TMP102 (Qwiic)

added to your cart!

SparkFun Digital Temperature Sensor - TMP102 (Qwiic)

In stock SEN-16304

The SparkFun TMP102 Qwiic is an easy-to-use digital temperature sensor equipped with a couple of Qwiic connectors for easy I2…

$5.95

We all like to know the temperature, right? Well, with the SparkFun Qwiic TMP102 Digital Temperature Sensor, we've made it about as easy as it gets. Based on the original Digital Temperature Sensor Breakout - TMP102, we've added Qwiic connectors to bring this board into our plug-and-play Qwiic Ecosystem and added an address jumper instead of breaking out the address pin.


Binho Nova Multi-Protocol USB Host Adapter

added to your cart!

Binho Nova Multi-Protocol USB Host Adapter

In stock DEV-16382

The Binho Nova Multi-Protocol USB Host Adapter allows one to interface their computer directly to hardware circuits.

$149.00

The Binho Nova Multi-Protocol USB Host Adapter allows one to interface their computer directly to hardware circuits. This device is powered by the USB connection to the host PC and is also able to provide downstream power to test circuits.


Binho Breadboard Breakout

added to your cart!

Binho Breadboard Breakout

In stock BOB-16419

The Binho Breadboard Breakout breaks a male 2x5 1.27mm connector out to breadboard-friendly 2.54mm / 0.1in pitch headers.

$2.50

The Binho Breadboard Breakout breaks a male 2x5 1.27mm connector out to breadboard-friendly 2.54mm pitch headers. It's an easy way to interface your Binho Nova host adapter with other circuits using standard jumper wires as well.


Binho Qwiic Interface Board

added to your cart!

Binho Qwiic Interface Board

In stock BOB-16420

The Binho Qwiic Interface Board makes it easy for you to interface your Binho Nova host adapter with up to four strings of Qw…

$7.50

The Binho Qwiic Interface Board makes it easy for you to interface your Binho Nova host adapter with up to four strings of Qwiic devices. It also breaks out all of the pins to a series of headers for convenient jumping to other circuits, or perhaps to your Logic Analyzer to monitor everything while you develop and debug.


Logitech C270 Webcam - USB 2.0

added to your cart!

Logitech C270 Webcam - USB 2.0

29 available SEN-16299

Experience sharp, smooth video calling (720p/30FPS) in a widescreen format with the C270 HD Webcam.

$39.95

This is the Logitech C270 Webcam. With a sleek compact look and a black finish, this economical choice provides a 720p/30FPS HD resolution in a 16:9 widescreen format. The Logitech C270 webcam is compatible with most major messaging applications like Skype, Windows Live Messenger, Yahoo Messenger and more, giving you a wide selection of use.


That's it for this week! As always, we can't wait to see what you make! Shoot us a tweet @sparkfun, or let us know on Instagram or Facebook. We’d love to see what projects you’ve made!

Never miss a new product!

hbspt.forms.create( portalId: "2224003", formId: "e963ae12-71f6-46d7-bb00-126dbfef8636" );

comments | comment feed

Read more »

3D Printed Valves Are Saving Lives In Italy

We’ve been seeing this story pop up all over the web. A group in Italy has been 3D printing valves that are saving people’s lives. In this case, the valve is a mixing device that is combining room air with pure oxygen before it is delivered to the patient. The […]

Read more on MAKE

The post 3D Printed Valves Are Saving Lives In Italy appeared first on Make: DIY Projects and Ideas for Makers.

Read more »

Face Surveillance Is Not the Solution to the COVID-19 Crisis

In the current moment, governments may be tempted to funnel scarce public health resources into the use of face recognition to curtail the spread of COVID-19. Public health crises, especially a global pandemic, may require extraordinary measures in favor of the public good—but invasive face surveillance is not in the public’s interest.

This approach could involve building new infrastructure to conduct more face surveillance and large government contracts with some of the most nefarious surveillance technology vendors in the world. Companies like Clearview AI, which uses over two billion face images scraped from social media to track individuals and identify them with real-time face surveillance, are already in talks with agencies to provide assistance. Even as civil liberties groups call for a national ban on government use of face recognition, U.S. Customs and Border Protection is currently touting face recognition at airport check-ins as supposedly more hygienic than other screening. 

Face recognition may seem convenient and useful, but is actually a deeply flawed technology that exposes people to constant scrutiny by the government.

The massive infrastructure required to run face recognition (such as cameras, software, and open-ended contracts with vendors) cannot be easily dismantled when the public health crisis is over. We cannot allow law enforcement and other government officials to normalize this invasive tactic. We know the truth about this spy tech: face recognition may seem convenient and useful, but is actually a deeply flawed technology that exposes people to constant scrutiny by the government, and has the potential to chill free speech and movement by identifying and tracking people as they visit their doctors, lawyers, houses of worship, or political demonstrations. It also can generate inaccurate reports. 

It is all too likely that any new use of face surveillance to contain covid-19 would long outlive the public health emergency. In a year, systems that were put in place to track infected individuals as they moved through a city could be re-deployed to track people as they walk away from a political demonstration or their immigration attorney’s office. Face recognition software that is able to identify people even when they’re wearing surgical masks, as the company Hanwang has developed, could also be used to identify people who obscure their face at political protests out of fear of retribution from the government. We have to consider the afterlives of these technologies and the way their use can creep into everyday life after the emergency is over.

This is why EFF and concerned citizens continue to call on Congress to ban the government use of face recognition. You can take action here by telling your elected officials that this technology, today and in the future, erodes our civil liberties and undermines our participation in a free society.

You can also take EFF’s new quiz to see what government agencies use or share your photograph for the purpose of conducting face recognition.

Take Action

Tell your elected officials to ban government use of face recognition

Read more »

Linkdump: January 2020

PCBs swung out on wiring harness acting as hinge or book spine

Read more »

NEW PRODUCTS – DIN Rail Terminal Block Adapters + Mount Bracket for Raspberry Pi / BeagleBone / Arduino

4555 4556 4557

NEW PRODUCTS – DIN Rail Terminal Block Adapters + Mount Bracket for Raspberry Pi / BeagleBone / Arduino


We’ve got a slew of new DIN rail adapters. First up, the DIN Rail Terminal Block Adapter to Metro or Arduino Uno!

4556 iso ORIG 2020 3

This one’s going out to all the makers and designers who use DIN railing in their builds. This adapter plate is perfect for simplifying complex wiring. You connect an Arduino Uno or Adafruit Metro to this breakout PCB, which can be DIN rail-mounted. All wires are broken out into terminal blocks, so you can connect and power your sensors, displays, microcontrollers, etc.

No soldering required! Place the microcontroller face-down onto the headers, unscrew the terminal blocks, and slide in your stranded or solid-core wire.

Note: DIN Rail and microcontroller are not included.

4556 side detail ORIG 2020 03

4556 top ORIG 2020 03

4556 quarter ORIG 2020 3

4556 iso demo ORIG 2020 03

Next up, the DIN Rail Terminal Block Adapter to Grand Central or Arduino Mega!


4555 iso 01 ORIG 2020 03

This one’s going out to all the makers and designers who use DIN railing in their builds. This adapter plate is perfect for simplifying complex wiring. You connect an Arduino Mega or Grand Central M4 Express to this breakout PCB, which can be DIN rail-mounted. All wires are broken out into terminal blocks, so you can connect and power your sensors, displays, microcontrollers, etc.

No soldering required! Place the microcontroller face-down onto the headers, unscrew the terminal blocks, and slide in your stranded or solid-core wire.

Note: DIN Rail and microcontroller are not included.

4555 side detail ORIG 2020 03

4555 top ORIG 2020 03

4555 quarter ORIG 2020 03

4555 iso demo ORIG 2020 03

And last, but not least, the DIN Rail Mount Bracket for Raspberry Pi / BeagleBone / Arduino!


4557 iso demo ORIG 2020 03 copy

This one’s going out to all the makers and designers who use DIN railing in their builds. This adapter plate is perfect for simplifying complex wiring. It’s pretty neat and compatible with a slew of microcontrollers and microcomputers: Raspberry Pi (any modern ones with 4 mounting holes such as the Zero, Pi 4, etc), Adafruit Metro or Arduino Uno, Adafruit Grand Central Express or Arduino Mega, or BeagleBone.

Please note that this product is only the mounting bracket – No breakout terminal blocks are included! For Raspberry Pi, match it up with a 2×20 IDC to Terminal Block Adapter and a GPIO Ribbon Cable to get started on your DIN rail project.

No soldering required! Take your favorite microcontroller and mount it to the bracket using the 10mm standoffs.

Includes:

  • 1 x Aluminum bracket
  • 1 pair DIN rail adapter legs and mount screws
  • 6 x M2.5x10mm standoffs
  • 6 x M2.5x6mm flat head screws
  • 6 x M2.5x6mm pan head screws

Note: DIN Rail itself, terminal block breakout and microcontroller / Pi board are not included!

4557 kit ORIG 2020 03

4557 top demo ORIG 2020 03

4557 quarter ORIG 2020 03

4557 iso demo ORIG 2020 03

In stock and shipping now!

Read more »

.ORG Isn’t Broken, and We Don’t Need Private Equity to ‘Fix’ It

Ethos Capital—the private equity firm poised to purchase the .ORG domain registry for $1.1 billion—and Public Interest Registry (PIR, the entity Ethos wants to buy) have been attempting to respond to the concerns raised by the .ORG community. These after-the-fact changes just make clear that while there is nothing currently wrong with .ORG, there is a lot that could go wrong if this deal moves forward. 

Last week, we wrote about a proposal by Ethos Capital to add certain “Public Interest Commitments” to the contract governing the operation of the .ORG domain registry. Our post explained why that proposal doesn’t solve the problems with the planned sale. Since then, Ethos and PIR have hosted two webinars to discuss how their plan supposedly addresses the concerns that EFF and over 800 other organizations—along with Members of Congress, UN Special Rapporteurs, and state charity regulators [pdf]—have raised. Nothing said on those webinars changed our analysis. Instead, they only further reinforced that Ethos’s plan for a for-profit PIR is one that’s unsound at its very foundation.

While we can—and will—point to specific places where Ethos and PIR’s arguments fall apart, the broader theme to take note of is that this cannot be fixed. All of the proposed changes have holes that don’t get at the underlying problems presented by the deal. On the other hand, the current system is stable and functional, and changing it threatens to introduce instability and dysfunction with no countervailing benefit to the community.

Ethos Touts Its Willingness to Take Risks—But at Whose Expense? 

Ethos and PIR have repeatedly defended the proposed deal by arguing that converting PIR to a privately owned, for-profit enterprise will allow it to offer “new products and services,” but without explaining what those new offerings might be. On Thursday, they finally admitted that they actually don’t know what additional products and services .ORG registrants want or need, citing a lack of market research. Ethos founder and CEO Erik Brooks then made a troubling case for why Ethos’s purchase of PIR would make these hypothetical new offerings possible: Launching new products requires taking financial risks, and non-profit organizations “are not in the business of taking risks”—but Ethos is.

This is not the selling point Brooks seems to think it is.  .ORG’s value to its registrants is being a reliable and recognized domain for hosting their websites and email systems—which it already offers. The .ORG registry should decidedly not be in the business of taking risks with non-profits’ essential infrastructure by adding bells and whistles that no one is asking for. If those risks don’t pan out, it may well be the non-commercial .ORG community that suffers as Ethos makes up for the loss by skimping on technical upkeep, raising prices, engaging in censorship-for-profit—or bankrupting PIR and walking away with the gains.

A Misleading Financial Picture

Ethos and PIR continue to push a narrative that goes like this: PIR currently has to send all of the money it makes to its non-profit parent organization, the Internet Society (ISOC); ISOC then uses those funds for purposes that don’t benefit PIR. As a result, PIR has not had funds to invest in reaching new markets or introducing new offerings. If PIR is freed of that burden, every dollar that PIR would have sent to ISOC will now be available for reinvestment in PIR.

There are a few problems with this narrative. For one, the assertion that PIR is required to send its entire net income to ISOC is at odds with PIR’s articles of incorporation, which establishes charitable purposes other than just financially supporting ISOC. And history shows that PIR can, in fact, invest in itself should it choose to. PIR’s 2018 Form 990, for example, states that PIR spent $1,369,537 on “advertising and promotion” and another $863,042 on “marketing” that tax year. In 2012, PIR took a gamble and applied for six new gTLDs (including .ngo and .ong) to add to its domain portfolio, costing $1.1 million in application fees alone.  In short, we’ve seen no evidence that PIR is an organization in crisis, in need of the kind of radical, fundamental change that Ethos has planned.

At the same time, the financial analysis Ethos presented last Thursday didn’t account for additional expenses that PIR would face post-acquisition. In particular, it didn’t factor in the tax burden that PIR will face if it gives up its tax-exempt status. Nor did it make clear whether PIR will face costs associated with other credit or financing obligations, dividend recapitalizations, or being forced to do business with Ethos’s favored vendors.  A letter we sent to ICANN in partnership with Americans for Financial Reform Education Fund explains our questions and concerns about the financial terms of the proposed transaction, which remain unanswered by Ethos and PIR.

Illusory Safeguards

In both recent webinars, Ethos and PIR have sought to assure community members that they would never take actions that would harm the .ORG community—and that even if they wanted to, their proposed Stewardship Council would stop them. Based on what we know about the Stewardship Council, we’re not convinced. Here’s why:

  • The member selection process guarantees that the Council will always be composed of people friendly to PIR’s board and owners and will not be truly independent. Six out of seven inaugural Council members will be selected by the board, while the seventh inaugural member and all subsequent members will be subject to the board’s veto.
  • The Council’s remit will be narrow—effectively as narrow as PIR’s board and management want it to be. The Council’s charter allows PIR to keep virtually any of the company’s actions or decisions outside of the Council’s scope simply by framing them as operational or financial matters. We’ve already seen PIR do this to justify not consulting its existing Advisory Council about the Ethos deal before agreeing to it. It’s also something we see frequently at ICANN, where any issue relating to registry contracts—including the changes to PIR’s contract that we challenged last year—is framed as an operational, non-policy matter, delegated to staff and exempt from multi-stakeholder processes.
  • It’s a safe bet that the Stewardship Council will be kept in the dark about critical decisions, just as PIR’s current Advisory Council was in the lead-up to the Ethos deal. We asked in both webinars how we could be sure that wouldn’t happen. PIR’s Jon Nevett responded that the Stewardship Council would have a larger role on “certain issues,” but he had no answer to whether and how the Council would have access to information it would need to make informed decisions.
  • Although PIR’s spokespeople repeatedly touted their dedication to free speech, they haven’t offered to change their existing anti-censorship policy one bit. It’s full of loopholes: PIR reserves the right to make websites go dark for “illegal or fraudulent actions.” Depending on which laws are applied and how they’re applied, anything from satire to political commentary to trivial copyright infringement on the website of a business competitor could be justification for taking away a site’s domain name. The power to interpret and apply this policy would rest entirely with PIR and its secretive owners. Nothing in PIR’s “PIC” and “Stewardship Council” announcements would change this—the risk of censorship-for-profit remains.

In Conclusion, Ethos and PIR Want to Change Something That Works Into Something Untested

The for-profit PIR that Ethos envisions would be a fundamentally different organization than today’s PIR, and we have serious concerns about its business model and financial stability.  Nothing we’ve heard from PIR and Ethos has convinced us that PIR should be transformed from something that we all know works to something that’s unproven. To the contrary, the Ethos deal raises concrete dangers of censorship, financial and technical instability, and price-gouging of non-commercial .ORG registrants. And despite making their case for months, proponents of the deal haven’t identified any specific benefits it would impart to .ORG users.

ICANN can, and should, reject this change to the .ORG registry. But that time is running out; ICANN’s current deadline to make a decision is Friday, March 20. You can still speak out: the ICANN Board is holding a public forum next week, Monday March 9 at 10am–11:30am Eastern Daylight Time. Anyone can join by videoconference and address the Board.

Read more »

This Clever Trick Embeds Holographic Patterns In Your 3D Prints

This clever trick popped up on Reddit recently and I’m very amused. Apparently you can use textured sheets on your 3d printer’s print bed to imprint that texture on the first layer of your print. Sounds obvious right? Well, what if that textured sheet is fine enough to give an […]

Read more on MAKE

The post This Clever Trick Embeds Holographic Patterns In Your 3D Prints appeared first on Make: DIY Projects and Ideas for Makers.

Read more »

Linkdump: November 2019

Screenshot of Enigma machine simulator encoding Hello World

Read more »