Tuesday, January 23, 2018

Senior High School Student who Built Prosthetic Arm will Teach Other Kids How to do it Too #3DPrinting

from Senior High School Student who Built Prosthetic Arm will Teach Other Kids How to do it Too #3DPrinting
by Jessie Mae

This inspirational story comes via Via Fox4kc

Krishon Harris isn’t your typical 17-year-old despite what he says.

“I’m just a high school student who’s just doing my part in the world,” he said.

But the Rockhurst High senior did something pretty incredible. He built a rare type of prosthetic arm for a metro boy born without one.

“Try to be the best person I can be every day,” Harris said.

Fox 4 caught up with Harris, volunteering at the Children’s Center for the Visually Impaired as part of his senior project.

In recent weeks, he’s received a lot of praise for helping a 4-year-old boy named Hudson who was born without a forearm. Harris built him a prosthetic arm, using a 3-D printer.

“He had a really big smile on his face,” Harris said of the 4-year-old. “He kind of knew it was coming, but he didn’t know what it would look like. And we made it Chiefs themed, so he was really excited.”

But the task came with its own set of challenges.

“The one that me and Hudson chose together, there has never been an arm that has been built that small,” Harris said. “There are like eight different parts, and some pieces we could go smaller and make it work. But some pieces, if we made them too small, they would be brittle, and they would break.”

With a lot of trial and error — and with the help of the original design creator — Harris was able to build the perfect model.

“He’ll be able to move his arm, his elbow in and then the fingers will clinch so he can grip stuff,” Harris said.

Harris is part of his school’s STEAM Studio, which stands for science, technology, engineering, art and math. Kansas city nonprofit Variety KC reached out to Rockhurst’s STEAM adviser for help.

Harris said adviser Mandi Sonnenberg, who is a Rockhurst University professor, knew the tech-savvy teen was the perfect person to head the project.

It took six weeks to build, but in the end, it fit like a charm.

Now, Harris is gearing up to pay it forward.

“We’re going to have some kids do the project,” Harris said. “They’re going to be building an arm, and I am going to be the head of them, teaching them what they need to learn about 3-D printing and coding.”

Harris said in the coming months, he’ll mentor a team of middle school students who will complete the same task.

See more!

Monday, January 22, 2018

New – Inter-Region VPC Peering

I’m still catching up with the last couple of AWS re:Invent launches!

Today I would like to tell you about inter-region VPC peering. You have been able to create peering connections between Virtual Private Clouds (VPCs) in the same AWS Region since early 2014 (read New VPC Peering for the Amazon Virtual Cloud to learn more). Once established, EC2 instances in the peered VPCs can communicate with each other across the peering connection using their private IP addresses, just as if they were on the same network.

At re:Invent we extended the peering model so that it works across AWS Regions. Like the existing model, it also works within the same AWS account or across a pair of accounts. All of the use cases that I listed in my earlier post still apply; you can centralize shared resources in an organization-wide VPC and then peer it with multiple, per-department VPCs. You can also share resources between members of a consortium, conglomerate, or joint venture.

Inter-region VPC peering also allows you to take advantage of the high degree of isolation that exists between AWS Regions while building highly functional applications that span Regions. For example, you can choose geographic locations for your compute and storage resources that will help you to comply with regulatory requirements and other constraints.

Peering Details
This feature is currently enabled in the US East (Northern Virginia), US East (Ohio), US West (Oregon), and EU (Ireland) Regions and for IPv4 traffic. You can connect any two VPCs in these Regions, as long as they have distinct, non-overlapping CIDR blocks. This ensures that all of the private IP addresses are unique and allows all of the resources in the pair of VPCs to address each other without the need for any form of network address translation.

Connections are requested by sending an invitation from one VPC to the other and the invitation must be accepted in order to establish the connection. You can set up a peering connection using the AWS Management Console, the VPC APIs, the AWS Command Line Interface (CLI), or the AWS Tools for Windows PowerShell.

Data that passes between VPCs in distinct regions flows across the AWS global network in encrypted form. The data is encrypted in AEAD fashion using a modern algorithm and AWS-supplied keys that are managed and rotated automatically. The same key is used to encrypt traffic for all peering connections; this makes all traffic, regardless of customer, look the same. This anonymity provides additional protection in situations where your inter-VPC traffic is intermittent.

Setting up Inter-Region Peering
Here’s how I set up peering between two of my VPCs. I’ll start with a VPC in US East (Northern Virginia) and request peering with a VPC in US East (Ohio). I start by noting the ID (vpc-acd8ccc5) of the VPC in Ohio:

Then I switch to the US East (Northern Virginia) Region, click on Create Peering Connection, and choose to peer with the VPC in Ohio. I enter the Id and click on Create Peering Connection to proceed:

This creates a peering request:

I switch to the other Region and accept the pending request:

Now I need to arrange to route IPv4 traffic between the two VPCs by creating route table entries in each one. I can edit the main route table or one associated with a particular VPC subnet. Here’s how I arrange to route traffic from Virginia to Ohio:

And here’s how I route it from Ohio to Virginia:

To learn more about how to do this, read Updating Your Route Tables for a VPC Peering Connection.

The private DNS names for EC2 instances (ip-10-90-211-18.ec2.internal and the like) will not resolve across a peering connection. If you need to refer to EC2 instances and other AWS resources in other VPCs, consider creating a Private Hosted Zone using Amazon Route 53:

Unlike VPC peering within a single region, you cannot reference security groups across Inter-Region VPC Peering. Also, jumbo frames cannot be send between regions.

Jeff;

 



from AWS News Blog http://ift.tt/2DtzSGn
via IFTTT

Saturday, January 20, 2018

Fitbit moves to deal with diabetes

from Fitbit moves to deal with diabetes
by John Weir

Wearable fitness pioneer Fitbit is making moves in the growing market for diabetes management.

Having recently invested $6 million in Sano, a company that makes a coin-size glucose monitor, it has also announced a partnership with Dexcom to let users track their glucose levels (via the Dexcom G5 sensor) on the Fitbit Ionic smartwatch.

It’s new initiative is with American healthcare insurer UnitedHealthcare on a type 2 diabetes management pilot program. Participants will be given either a Fitbit Charge 2 or Ionic, which they’ll use along with a Dexcom monitor, to see how their activity levels are impacting their glucose levels.

This constant monitoring might be able to help patients determine what behaviours positively or negatively affect their glucose levels, and take action accordingly. And thanks to the personalized coaching and activity monitoring provided by the Fitbit device, users should be able to turn insights into action.

Friday, January 19, 2018

Recent EC2 Goodies – Launch Templates and Spread Placement

We launched some important new EC2 instance types and features at AWS re:Invent. I’ve already told you about the M5, H1, T2 Unlimited and Bare Metal instances, and about Spot features such as Hibernation and the New Pricing Model. Randall told you about the Amazon Time Sync Service. Today I would like to tell you about two of the features that we launched: Spread placement groups and Launch Templates. Both features are available in the EC2 Console and from the EC2 APIs, and can be used in all of the AWS Regions in the “aws” partition:

Launch Templates
You can use launch templates to store the instance, network, security, storage, and advanced parameters that you use to launch EC2 instances, and can also include any desired tags. Each template can include any desired subset of the full collection of parameters. You can, for example, define common configuration parameters such as tags or network configurations in a template, and allow the other parameters to be specified as part of the actual launch.

Templates give you the power to set up a consistent launch environment that spans instances launched in On-Demand and Spot form, as well as through EC2 Auto Scaling and as part of a Spot Fleet. You can use them to implement organization-wide standards and to enforce best practices, and you can give your IAM users the ability to launch instances via templates while withholding the ability to do so via the underlying APIs.

Templates are versioned and you can use any desired version when you launch an instance. You can create templates from scratch, base them on the previous version, or copy the parameters from a running instance.

Here’s how you create a launch template in the Console:

Here’s how to include network interfaces, storage volumes, tags, and security groups:

And here’s how to specify advanced and specialized parameters:

You don’t have to specify values for all of these parameters in your templates; enter the values that are common to multiple instances or launches and specify the rest at launch time.

When you click Create launch template, the template is created and can be used to launch On-Demand instances, create Auto Scaling Groups, and create Spot Fleets:

The Launch Instance button now gives you the option to launch from a template:

Simply choose the template and the version, and finalize all of the launch parameters:

You can also manage your templates and template versions from the Console:

To learn more about this feature, read Launching an Instance from a Launch Template.

Spread Placement Groups
Spread placement groups indicate that you do not want the instances in the group to share the same underlying hardware. Applications that rely on a small number of critical instances can launch them in a spread placement group to reduce the odds that one hardware failure will impact more than one instance. Here are a couple of things to keep in mind when you use spread placement groups:

  • Availability Zones – A single spread placement group can span multiple Availability Zones. You can have a maximum of seven running instances per Availability Zone per group.
  • Unique Hardware – Launch requests can fail if there is insufficient unique hardware available. The situation changes over time as overall usage changes and as we add additional hardware; you can retry failed requests at a later time.
  • Instance Types – You can launch a wide variety of M4, M5, C3, R3, R4, X1, X1e, D2, H1, I2, I3, HS1, F1, G2, G3, P2, and P3 instances types in spread placement groups.
  • Reserved Instances – Instances launched into a spread placement group can make use of reserved capacity. However, you cannot currently reserve capacity for a placement group and could receive an ICE (Insufficient Capacity Error) even if you have some RI’s available.
  • Applicability – You cannot use spread placement groups in conjunction with Dedicated Instances or Dedicated Hosts.

You can create and use spread placement groups from the AWS Management Console, the AWS Command Line Interface (CLI), the AWS Tools for Windows PowerShell, and the AWS SDKs. The console has a new feature that will help you to learn how to use the command line:

You can specify an existing placement group or create a new one when you launch an EC2 instance:

To learn more, read about Placement Groups.

Jeff;



from AWS News Blog http://ift.tt/2FXiUSc
via IFTTT

Recent EC2 Goodies – Launch Templates and Spread Placement

We launched some important new EC2 instance types and features at AWS re:Invent. I’ve already told you about the M5, H1, T2 Unlimited and Bare Metal instances, and about Spot features such as Hibernation and the New Pricing Model. Randall told you about the Amazon Time Sync Service. Today I would like to tell you about two of the features that we launched: Spread placement groups and Launch Templates. Both features are available in the EC2 Console and from the EC2 APIs, and can be used in all of the AWS Regions in the “aws” partition:

Launch Templates
You can use launch templates to store the instance, network, security, storage, and advanced parameters that you use to launch EC2 instances, and can also include any desired tags. Each template can include any desired subset of the full collection of parameters. You can, for example, define common configuration parameters such as tags or network configurations in a template, and allow the other parameters to be specified as part of the actual launch.

Templates give you the power to set up a consistent launch environment that spans instances launched in On-Demand and Spot form, as well as through EC2 Auto Scaling and as part of a Spot Fleet. You can use them to implement organization-wide standards and to enforce best practices, and you can give your IAM users the ability to launch instances via templates while withholding the ability to do so via the underlying APIs.

Templates are versioned and you can use any desired version when you launch an instance. You can create templates from scratch, base them on the previous version, or copy the parameters from a running instance.

Here’s how you create a launch template in the Console:

Here’s how to include network interfaces, storage volumes, tags, and security groups:

And here’s how to specify advanced and specialized parameters:

You don’t have to specify values for all of these parameters in your templates; enter the values that are common to multiple instances or launches and specify the rest at launch time.

When you click Create launch template, the template is created and can be used to launch On-Demand instances, create Auto Scaling Groups, and create Spot Fleets:

The Launch Instance button now gives you the option to launch from a template:

Simply choose the template and the version, and finalize all of the launch parameters:

You can also manage your templates and template versions from the Console:

To learn more about this feature, read Launching an Instance from a Launch Template.

Spread Placement Groups
Spread placement groups indicate that you do not want the instances in the group to share the same underlying hardware. Applications that rely on a small number of critical instances can launch them in a spread placement group to reduce the odds that one hardware failure will impact more than one instance. Here are a couple of things to keep in mind when you use spread placement groups:

  • Availability Zones – A single spread placement group can span multiple Availability Zones. You can have a maximum of seven running instances per Availability Zone per group.
  • Unique Hardware – Launch requests can fail if there is insufficient unique hardware available. The situation changes over time as overall usage changes and as we add additional hardware; you can retry failed requests at a later time.
  • Instance Types – You can launch a wide variety of M4, M5, C3, R3, R4, X1, X1e, D2, H1, I2, I3, HS1, F1, G2, G3, P2, and P3 instances types in spread placement groups.
  • Reserved Instances – Instances launched into a spread placement group can make use of reserved capacity. However, you cannot currently reserve capacity for a placement group and could receive an ICE (Insufficient Capacity Error) even if you have some RI’s available.
  • Applicability – You cannot use spread placement groups in conjunction with Dedicated Instances or Dedicated Hosts.

You can create and use spread placement groups from the AWS Management Console, the AWS Command Line Interface (CLI), the AWS Tools for Windows PowerShell, and the AWS SDKs. The console has a new feature that will help you to learn how to use the command line:

You can specify an existing placement group or create a new one when you launch an EC2 instance:

To learn more, read about Placement Groups.

Jeff;



from AWS News Blog http://ift.tt/2FXiUSc
via IFTTT

NEW PRODUCT – Make: Magazine – Vol 61 – Spotlight Shenzhen with Naomi Wu @RealSexyCyborg

from NEW PRODUCT – Make: Magazine – Vol 61 – Spotlight Shenzhen with Naomi Wu @RealSexyCyborg
by Angelica

3717 top down TEMP

NEW PRODUCT – Make: Magazine – Vol 61 – Spotlight Shenzhen with Naomi Wu @RealSexyCyborg


Make: Volume 61 features one of our absolute favorite makers, Naomi Wu, better known online as @RealSexyCyborg! We are so thrilled she’s getting this exposure that we want everyone to have a copy of the magazine! Considering that Naomi is the creator of China’s first certified Open Source Hardware Project, this editorial has been a long time coming!

This volume has an excellent cover story on Naomi and other inspiring makers based in Shenzhen, including Vicky Xie, Shirley Feng, Lin Jie (a.k.a. 00), Lit Liao, and Carrie Leung. Additional featured articles cover Fighting Disasters, VR Reality Check, and drones. Fun projects listed are a rainbow lightbox, “Text a Treat” SMS pet treat dispenser, robot-ready radar, and more!

Get yours before they’re all gone!

3717 inside 01 ORIG 2018 01

3717 inside 02 ORIG 2018 01

3717 inside 03 ORIG 2018 01

In stock and shipping now!

NEW PRODUCT – Adafruit SGP30 Air Quality Sensor Breakout VOC and eCO2

from NEW PRODUCT – Adafruit SGP30 Air Quality Sensor Breakout VOC and eCO2
by Angelica

3709 iso ORIG 2018 01

NEW PRODUCT – Adafruit SGP30 Air Quality Sensor Breakout VOC and eCO2


Breathe easy with the SGP30 Multi-Pixel Gas Sensor, a fully integrated MOX gas sensor. This is a very fine air quality sensor from the sensor experts at Sensirion, with I2C interfacing and fully calibrated output signals with a typical accuracy of 15% within measured values. The SGP combines multiple metal-oxide sensing elements on one chip to provide more detailed air quality signals.

This is a gas sensor that can detect a wide range of Volatile Organic Compounds (VOCs) and H2 and is intended for indoor air quality monitoring. When connected to your microcontroller (running our library code) it will return a Total Volatile Organic Compound (TVOC) reading and an equivalent carbon dioxide reading (eCO2) over I2C.

The SGP30 has a ‘standard’ hot-plate MOX sensor, as well as a small microcontroller that controls power to the plate, reads the analog voltage, tracks the baseline calibration, calculates TVOC and eCO2 values, and provides an I2C interface to read from. Unlike the CCS811, this sensor does not require I2C clock stretching.

3709 quarter ORIG 2018 01

This part will measure eCO2 (equivalent calculated carbon-dioxide) concentration within a range of 0 to 60,000 parts per million (ppm), and TVOC (Total Volatile Organic Compound) concentration within a range of 0 to 60,000 parts per billion (ppb).

Please note, this sensor, like all VOC/gas sensors, has variability and to get precise measurements you will want to calibrate it against known sources! That said, for general environmental sensors, it will give you a good idea of trends and comparison. The SGP30 does have built in calibration capabilities, note that eCO2 is calculated based on H2 concentration, it is not a ‘true’ CO2 sensor for laboratory use.

Another nice element to this sensor is the ability to set humidity compensation for better accuracy. An external humidity sensor is required and then the RH% is written over I2C to the sensor, so it can better calculate the TVOC/eCO2 values.

For your convenience we’ve pick-and-placed the sensor on a PCB with a 1.8V regulator and some level shifting so it can be easily used with your favorite 3.3V or 5V microcontroller.

3709 top ORIG 2018 01

In stock and shipping now!