Category Archives: Aggregated

Duelling pianos. Literally.

via Raspberry Pi

When someone mailed me a link to this performance, I assumed it was going to be one of those setups where two pianists play jolly tunes together in a bar. How wrong I was.

These two pianists (Alvise Sinivia and Léo Jassef from the Conservatoire National de Paris) are trying to kill each other in Streetfighter. Tunefully.

These pianos have been transformed by Eric and Cyril of Foobarflies (let me know your full names, Eric and Cyril, so I can add them here!) into Playstation controllers, using piezo triggers, a Pi, some Arduinos, and some custom Python firmware. The installation was set up for the reopening of Paris’ Maison de la Radio, now a cultural space open to the public.

Eric and Cyril have made a comprehensive writeup available (and if, like me, you’re terribly excited by the insides of pianos, you’ll love this one). This is one of my favourite projects in ages – thanks Foobarflies!

On the Origin of Thermal Sensors

via SparkFun Electronics Blog Posts

The arctic is changing, and unfortunately we don’t really know how or why. The question of why is one that people can become overly argumentative about, so let’s focus on the how instead. We’ve been tracking the extent of ice and snow for a long time now. NOAA has a whole division dedicated to that. However, they only track the surface area of the sea ice. This tells us clearly that the area of sea ice is shrinking but leaves out any information about the actual volume of ice. Naysayers can use this to their advantage by saying the ice could be decreasing in area but increasing in depth keeping the volume the same. Although this argument glazes over many other issues with changes in the sea ice, it can be made.

The need to determine the volume of the sea ice brought my research group from the Southwest Virginia Governor’s School and Radford University to the arctic. It is an amazing place, and anyone who has not gone should try to visit. There is nothing more invigorating than stepping off an airplane, taking a deep breath, and realizing that your entire nasal cavity has frozen together (keep in mind doing this is a bad idea).

On the initial visits to Barrow, Alaska, our group tried to use different geophysical equipment to measure the resistivity of the sub-­surface structure. However, this was never enough so a few trips back some of my students from the Southwest Virginia Governor’s School came up with a new idea. They wanted to measure the surface temperature to see if there is a correlation between the thickness of the ice and the surface temperature. They had just finished the chapter on thermal conduction in my physics class a few days earlier. The idea was that if the ice is thin the warm water, which is at about -­2.1C, would conduct heat to the surface, which is at around -­20C faster than thicker ice. So we set out to find thermal sensors. We started with thermochrons, however, the first year we lost about five because they were so small, and they would take almost 20 minutes to come to equilibrium after they were touched for a few seconds by a glove.

This lead my research team and me to develop an Arduino based non-­contact thermal sensor and then to revise that system on subsequent trips. The final product was named Whistler, for no better reason than it needed a name, and made use of many SparkFun products. The workhorse of Whistler is an Arduino ProMini. The ProMini coordinates between the SparkFun OpenLog, switches and wires, LED indicators (it turns out knowing the thing is on is important), a linear temperature sensor, a hall sensor to determine distance traveled, a LiPo and power cell and most importantly the MLX90614. All these parts worked together fantastically, and I was able to run code that looped in under 15ms. Even with more sensors, this was over 2x as fast as version 2.0, known as Therma. I also started using Github to track all the changes so you can actually see all the files for the PCB, data sheets (I love a good data sheet), and the code for the microcontroller.

The other big change we implemented was that everyone going on the trip had to learn how to use an Arduino. Luckily our Governor’s School had 20 SIK’s from the SparkFun National Tour in which we took part. We let each student check out his or her own SIK to learn how to use an Arduino. By the time we got up to the arctic all members of the research team could successfully program an Arduino, fix code, and use the sensors that were part of Whistler.

The actual Whistler unit was relatively cheap to build, considering geophysics equipment usually starts at around $50,000, and worked well. The team used the setup for almost two weeks in the frigid cold and had little to no trouble. The SMD microUSB connector on the power cell was manhandled a little and broken off, but that’s why we brought spares. In fact, they took all the equipment out one day when it was around -­55F with the windchill, and Whistler was the only piece of equipment that was still working after three hours. The only reason they didn’t test it longer was because the students stopped working at that point!

The best part about this was that the students had direct input on the design, development, survey techniques, data analysis, fame, and glory associated with it. Usually they only get to use something pre-­built, but now they’ve had the opportunity to see why it’s so hard to make something that works. They found out that shadows on ice can cause a temperature difference of around -­4C compared to ice that is in direct sunlight. So the next group of students will have to answer “is this albedo or emissivity that’s the problem, and how can we account for it?” Time to start planning version 4.0 (project Snobird)!

Melissa Brett examines the TMP36 with Dr. Rhett Herman before leaving for the trip.

Melissa Brett and Dr. Rhett Herman

Melissa Brett gets personal with the Redboard.

RedBoard

Jesse Dodson and Corey Roadcap stare longingly at the Arduino IDE.

Jesse Dodson and Corey Roadcap

Governor’s School students, Ashley Jordan and Austin Owen, fight for supremacy to find out who can get the TMP36 sensor to work first.

Ashley Jordan and Austin Owen

Whistler’s first trip out on the ice with Austin Owen and Erica Martin.

Whistler

Corey Roadcap forgets what he was going to say as he shows the raw unprocessed Whistler data.

Corey Roadcap

Sarah House shows the temperature, -­20F (real feel -­49F).

Sarah House

Jessi Basham, Jordan Eagle, Dr. Rhett Herman, and Jesse Dodson examine Whistler while reminiscing about arcade buttons from their childhood.

Whistler group

Whistler actually has a fraternal twin who is badly in need of having her zipties clipped.

Fraternal twin

The innards of Whistler!

Inside Whistler

Close ups of the Hall sensor, MLX90614, and TMP36 sensors. The meat and potatoes of Whistler!

Hall sensor

The next image is the resistivity data plotted with the thermal data on top. You can start to see the general trend in the data. Maybe the next trip will be the one that gives all the glorious data we need to confirm!

Chart

comments | comment feed

Making Makers: Reflections on (Many) Childhoods

via SparkFun Electronics Blog Posts

This guest post is courtesy of AnnMarie Thomas, author of Making Makers: Kids, Tools, and the future of Innovation.


I’m always interested in hearing about the childhoods of people I admire. As a parent and professor, I can’t help but be curious about the experiences that have, in some part, made them who they are today. So many of the attributes I see in the Maker Movement – a willingness to learn new things, to collaborate, to help others, and an emphasis on process – are ones I wish for my daughters. Thus I set out, a few years ago, to collect stories from makers about what they were like as children. Over the course of more than 70 interviews I heard some amazing tales and realized that quite a few themes were emerging:

  • Makers are curious. They are explorers. They pursue projects that they personally find interesting.

  • Makers are playful. They often work on projects that show a sense of whimsy.

  • Makers are willing to take on risk. They aren’t afraid to try things that haven’t been done before.

  • Makers take on responsibility. They enjoy taking on projects that can help others.

  • Makers are persistent. They don’t give up easily.

  • Makers are resourceful. They look for materials and inspiration in unlikely places.

  • Makers share – their knowledge, their tools, and their support.

  • Makers are optimistic. They believe that they can make a difference in the world.

Not surprisingly, quite a few SparkFun employees ended up on my interview list. Dr. Lindsay Diamond, SparkFun’s Director of Education, and Nate Seidle, Sparkfun’s CEO, even shared some childhood pictures. So what were these two like as children? Below I share some excerpts from Making Makers: Kids, Tools, and the Future of Innovation (Maker Media, 2014).

Taking (Unexpected) Things Apart

alt text

Lindsay Diamond, future Director of Education at SparkFun

When the Maker Movement is brought up in education conferences, I’ve seen that many people assume that all makers were avid “take apart”-ers as kids. While many makers I spoke to did enjoy taking things apart, many others didn’t, preferring instead to read, play outdoors, or explore other pursuits. In other cases, some young makers did enjoy taking systems apart, but not necessarily the sort of things you might expect.

Dr. Lindsay Levkoff Diamond, director of education at SparkFun Electronics, immediately answered yes when I asked her about this aspect of growing up. I began to imagine toasters and VCRs strewn about, but she quickly explained that, growing up in Florida, they had “an unbelievably large population of lizards. They were already deceased. I would take sticks and try to see what was inside.” Lindsay’s take-apart subjects included “all things biological,” both plant and animal-based. Flashing forward twenty some years, Lindsay is now a champion of open source education, particularly as it relates to electronics. Whether it’s lizards or flashlights, Lindsay is among those educators promoting the importance of letting kids follow their curiosity.

Open Source from an Early Age

alt text

Nathan Seidle, future CEO of SparkFun

In high school, Nathan Seidle had a fancy graphing calculator. Given that he was a talented mathematics student with a strong interest in computers, it’s not surprising that he wanted to find a way to connect his calculator to his computer. Such cables were commercially available, but they weren’t cheap. So Nathan went on a BBS (bulletin board system, a type of online message system that was popular in the 1980s and 90s) and started looking for information on how to make such a cable. He found a schematic online, which he used to build a functioning cable (which is particularly impressive when you consider that the BBS was text-based, and so was the schematic). This was the first project of this type that Nathan had undertaken, so he didn’t even know where to buy the parts. Other posters on the BBS advised him to buy them at RadioShack, which he did, thus beginning a small business of building and selling these cables to his friends at a price much cheaper than the commercial rate (when I asked if the cables worked, Nathan’s reply was an enthusiastic, “A few of them did!”). While making his first cable, he accidentally got solder on two of the connector’s pins. He used a box knife to remedy this and ended up cutting himself, leaving a scar. Now he looks back and thinks, “that’s the scar that started SparkFun.”

Perhaps the biggest lesson I was able to take away from these discussions is that while there were many similarities that popped up among the stories, every maker I spoke to had their own unique path that they followed. We, as parents and mentors, don’t always need to have all of the answers. Our support can be sufficient. Allowing children, and the children-at-heart, to explore their own interests, and empowering them to figure out how to make their ideas come to life, are some of the best ways to help them define success for themselves.

comments | comment feed

Launch day – what happened to the website?

via Raspberry Pi

Liz: As you may recall, back on February 2 we launched a new product. This website buckled a little under the strain (as did some of our partners’ websites). At the time, we promised you a post about what happened here and how we dealt with it, with plenty of graphs. We like graphs.

Here’s Pete Stevens from Mythic Beasts, our hosts, to explain exactly what was going on. Over to you, Pete!

On Monday, the Raspberry Pi 2 was announced, and The Register’s predictions of global geekgasm proved to be about right. Slashdot, BBC News, global trending on Twitter and many other sources covering the story resulted in quite a lot of traffic. We saw 11 million page requests from over 700,000 unique IP addresses in our logs from Monday, around 6x the normal traffic load.

The Raspberry Pi website is hosted on WordPress using the WP Super Cache plugin. This plugin generally works very well, resulting in the vast majority of page requests being served from a static file, rather than hitting PHP and MySQL. The second major part of the site is the forums and the different parts of the site have wildly differing typical performance characteristics. In addition to this, the site is fronted by four load balancers which supply most of the downloads directly and scrub some malicious requests. We can cope with roughly:

Cached WordPress 160 pages / second
Non cached WordPress 10 pages / second
Forum page 10 pages / second
Maintenance page at least 10,000 pages / second

Back in 2012 for the original launch, we had a rather smaller server setup and we just put a maintenance page up and directed everyone to buy a Pi direct from Farnell or RS, both of whom had some trouble coping with the demand. We also launched at 6am GMT so that most of our potential customers would still be in bed spreading the initial surge over several hours.

This time, being a larger organisation with coordination across multiple news outlets and press conferences, the launch time was fixed for 9am on Feb 2nd 2015 so everything would happen then, apart from the odd journalist with premature timing problems – you know who you are.

Our initial plan was to leave the site up as normal, but set the maintenance page to be the launch announcement. That way if the launch overwhelmed things, everyone should see the announcement served direct from the load balancers and otherwise the site should function as normal. Plan B was to disable the forums, giving more resources to the main blog so people could comment there.

The Launch

turtlebeach

It is a complete coincidence that our director Pete took off to go to this isolated beach in the tropics five minutes after the Raspberry Pi 2 launch.

At 9:00 the announcement went live. Within a few minutes traffic volumes on the site had increased by more than a factor of five and the forum users are starting to make comments and chatter to each other. The server load increased from its usual level of 2 to over 400 – we now had a massive queue of users waiting for page requests because all of the server CPU time was being taken generating those slow forum pages which starved the main blog of server time to deliver those fast cached pages. At this point our load balancers started to kick in and deliver to a large fraction of our site users the maintenance page containing the announcement – the fall back plan. This did annoy the forum and blog users who had posted comments and received the maintenance page back having just had their submission thrown away – sorry. During the day we did a little bit of tweaking to the server to improve throughput, removing the nf_conntrack in the firewall to free up CPU for page rendering, changing the apache settings to queue earlier so people received either their request page or maintenance page more quickly.

Disabling the forums freed up lots of CPU time for the main page and gave us a mostly working site. Sometimes it’d deliver the maintenance page, but mostly people were receiving cached WordPress pages of the announcement and most of the comments were being accepted.

Super Cache not quite so super

Unfortunately, we were still seeing problems. The site would cope with the load happily for a good few minutes, and then suddenly have a load spike to the point where pages were not being generated fast enough. It appears that WP Super Cache wasn’t behaving exactly as intended. When someone posts a comment, Super Cache invalidates its cache of the corresponding page, and starts to rebuild a new one, but providing you have this option ticked… supercache-anonymouse …(we did), the now out-of-date cached page should continue to be served until it is overwritten by the newer version. After a while, we realised that the symptoms that we were seeing entirely consistent with this not working correctly, and once you hit very high traffic levels this behaviour becomes critical. If cached versions are not served whilst the page is being rebuilt then subsequent requests will also trigger a rebuild and you spend more and more CPU time generating copies of the missing cached page which makes the rebuild take even longer so you have to build more copies each of which now takes even longer. Now we can build a ludicrously overly simple model of this with a short bit of perl and draw a graph of how long it takes to rebuild the main page based on hit rate – and it looks like this. Supercache performance This tells us that performance reasonably suddenly falls off a cliff at around 60-70 hits/second. At 12 hits/sec (typical usage) a rebuild of the page completes in considerably under a second, at 40 hits/sec (very busy) it’s about 4s, at 60 hits/sec it’s 30s, at 80hits/sec it’s well over five minutes – the load balancers kick in and just display the maintenance page, and wait for the load to die down again before starting to serve traffic as normal again. We still don’t know exactly what the cause of this was, so either it’s something else with exactly the same symptoms, or this setting wasn’t working or was interacting badly with another plugin, but as soon as we’d figured out the issue, we implemented the sensible workaround; we put a rewrite hack in to serve the front page and announcement page completely statically, then created the page fresh once every five minutes from cron picking up all the newest comments. As if by magic the load returned to sensible levels although there was now a small delay on new comments appearing.

Re-enabling the forums

 

With stable traffic levels, we turned the forums back on. And then immediately off again. They very quickly backed up the database server with connections, causing both the forums to cease working and the main website to run slowly. A little further investigation into the InnoDB parameters and we realised we had some contention on database locks, we reconfigured and this happened.

Our company pedant points out that actually only the database server process fell over, and it needed restarted not rebooting. Cunningly, we’d managed to find a set of improved settings for InnoDB that allowed us to see all the tables in the database but not read any data out of them. A tiny bit of fiddling later and everything was happy.

The bandwidth graphs

We end up with a traffic graph that looks like this. raspi-launch-bwgraph On the launch day it’s a bit lumpy, this is because when we’re serving the maintenance page nobody can get to the downloads page. Downloads of operating system images and NOOBS dominates the traffic graphs normally. Over the next few days the HTML volume starts dropping and the number of system downloads for newly purchased Raspberry Pis starts increasing rapidly. At this point were reminded of the work we did last year to build a fast distributed downloads setup and were rather thankful because we’re considerably beyond the traffic levels you can sanely serve from a single host.

Could do a bit better

The launch of Raspberry Pi 2 was a closely guarded secret, and although we were told in advance, we didn’t have a lot of time to prepare for the increased traffic. There’s a few things we’d like to have improved and will be talking to with Raspberry Pi over the coming months. One is to upgrade the hardware adding some more cores and RAM to the setup. Whilst we’re doing this it would be sensible to look at splitting the parts of the site into different VMs so that the forums/database/Wordpress have some separation from each other and make it easier to scale things. It would have been really nice to have put our extremely secret test setup with HipHop Virtual Machine into production, but that’s not yet well enough tested for primetime although a seven-fold performance increase on page rendering certainly would be nice.

Schoolboy error

Talking with Ben Nuttall we realised that the stripped down minimal super fast maintenance page didn’t have analytics on it. So the difference between our stats of 11 million page requests and Ben’s of 1.5 million indicate how many people during the launch saw the static maintenance page rather than a WordPress generated page with comments. In hindsight putting analytics on the maintenance page would have been a really good idea. Not every http request which received the maintenance page was necessarily a request to see the launch, nor was each definitely a different visitor. Without detailed analytics that we don’t have, we can estimate the number of people who saw the announcement to be more than 1.5 million but less than 11 million.

Flaming, Bleeding Servers

Liz occasionally has slightly odd ideas about exactly how web-servers work: 

is-this-thing-on

Now, much to her disappointment we don’t have any photographs of servers weeping blood or catching fire. [Liz interjects: it’s called METAPHOR, Pete.] But when we retire servers we like to give them a bit of a special send-off: here’s a server funeral, Mythic Beasts-style.

Making a lasercut Movie Recommender with Intel Edison

via Arduino Blog

movie-recommender

Some days ago we posted on Intel Makers Community an educational tutorial focused on Intel Edison. Our team explored Internet Queries to build a lasercut Movie Recommender and help you find a good movie title  extracted from The Open Movie Database starting from the 50s to the 10s and according to your favourite genre:

Pressing the button will activate the Movie Recommender and the search begins. After the magic is done, the curtain will open to reveal the movie that fits the criteria.

So get this project done, make some popcorn, dim the lights, and get ready to watch a sci-fi movie from 1988… “My Stepmother is an Alien”?!

Follow the link and create your DIY Movie Recommender!

intel3

Take a look at the video below to see how it works!

Using The Red Pitaya As An SDR

via Hackaday » hardware

The Red Pitaya is a credit-card sized board that runs Linux, has Ethernet, and a good bit of RAM. This sounds a lot like a Raspberry Pi and BeagleBone Black, but the similarities end there. The Red Pitaya also has two RF inputs, two RF outputs, and a load of digital IOs, all connected to an Xilinx SoC that includes an FPGA. [Pavel] realized the Pitaya had all the components of a software-defined radio, and built an implementation to prove it.

The input for the SDR taps directly into one of the high impedance inputs with a simple loop antenna made out of telephone cable. The actual software-defined part of this radio borrows heavily from an Xilinx application note, while everything is controlled by either SDR# or HDSDR.

[Pavel] included a pre-built SD card image with all his software, so cloning this project is simply a matter of copying an SD card and building an antenna. The full source is also available, interesting if you would like to muck about with FPGAs and SDRs.


Filed under: FPGA, hardware, radio hacks

The Wisest Wizard Doesn’t Drink from Cans

via Hackaday » hardware

“Wizard Staff” or “Wisest Wizard” is a drinking game played at parties where the attendees participate by taping the empty cans of the drinks they’ve consumed on top of one another to form a staff of inebriated power. A person with a longer staff is considered to be at a higher level and can therefore command lesser wizards to pound their current beverage to a point they see fit. Not everyone at a party necessarily drinks their tasty libation of choice from a can however. So, [Ahmed] and his group came up with a solution for those of us who might alternately prefer to wield a pint glass of power instead.

In their hardware project for Hack Illinois 2015, [Brady Salz], [Ahmed Suhyl], [Dario Aranguiz], [Kashev Dalmiaand] decided to add a zest of tech to the game. For their updated rendition, glasses are equipped with battery packs for mobility, a Spark micro-controller, and different colored LEDs as indicators. A couple of wires reach into the bottom of each glass to measure conductivity and keep track of the number of times it is filled and then emptied. In leu of towers of aluminum husks and duct-tape, the group developed a simple Android app for participants to log into which will track and visualize the standings of each player registered to one of the glasses. They even created a pebble version of the app that will display all the same information in case you don’t want to risk handling your phone while drinking… heh.

For an added level of fun, once a player reaches a certain level above someone else, they unlock the option to “challenge” the lesser adversary. By selecting that person’s user name in the app, the LED and buzzer on their glass will spring to life, letting them know they’ve been chosen to chug the rest of their drink. If you’re curious how they made it work, you can check out the team’s code on Github and maybe take a stab at giving the game a makeover of your own.


Filed under: Android Hacks, hardware

Coming soon: The SparkFun Guide to Processing!

via SparkFun Electronics Blog Posts

This is Derek.

alt text

Derek is our Department of Education’s Educational Technologist, responsible for creating outstanding curriculum and materials for electronics education. He has spent the last 16 months writing a thorough guidebook to getting started with Processing, and we’re excited to share that it will be published by No Starch Press in June!

alt text

Our Sr. Designer Pete created the super fancy cover

Processing is a free, beginner-friendly programming language designed to help non-programmers create interactive art with code. Over the course of the book, readers learn the basics by drawing simple shapes, move on to photo editing and video manipulation, and ultimately affect the physical world by using Processing with an Arduino.

Even though he just spent 16 months immersed in the land of Processing and book-authoring, he was nice enough to talk about the process with us before he takes a very long nap.

What was it like writing a book for the first time?

In a lot of ways it’s similar to your first international flight. About 80 percent of it you have done before, but it’s the 20 percent that’s new to you that really gets you. In the past I have written papers, blog posts and content for the classroom. For much of that it was just me; writing a book has been eye opening and I never really realized how many people it takes to pull it off.

To be honest, it has been the most fun and frustrating project I have worked on in my professional life. When I was a teacher my content was mine; I delivered it to students and my students could ask me to clarify something or ask questions. With a book we want a reader to get it, crystal clear. They don’t really have the option of raising their hand and asking what a word means or why they are having trouble. I think that is the one thing that I had to get used to in the writing & editing process – a reader that I will never meet, and who will never be learning this stuff from me in the classroom.

What was the hardest part?

There were a number of things that were difficult with the process of writing the book. Most of them were self inflicted, so I can’t really blame the process. I enjoy being on the edge of my knowledge. I thrive when I am learning and being challenged in that way. In essence, writing a book was the opposite of that. It was documenting the stuff that was core knowledge to me while I wanted to go off and chase the new squirrels every day.

The editing process for the book has also been hard for me. It is really humbling to get a chapter back from my editor and there is more red than black on the page. This rapidly made me a better writer and editor.

What was the motivation for writing about Processing?

This is a good question, especially since we work for a hardware company. The motivation stems from my experience teaching middle school students how to use Arduino. I was frustrated with the number of errors students were getting. I ended up being a stop for the SparkFun west coast tour, Jeff Branson ran a simple Processing workshop for my classes, and I was hooked.

I saw Processing as a way to start students down the road of Arduino without having to deal with hardware and wiring right away. The goal was to teach just enough in Processing to make my students comfortable with programming and the syntax of Processing (which is the same as Arduino), so that they would be “skilled” programmers, and I could then focus on the circuit and hardware side of things when they picked up Arduino.

The unintended side effect of this was that students would naturally gravitate towards Processing for projects. Once they learned that an Arduino could talk to Processing through serial, all bets were off. I changed my class curriculum to reflect that interactive creative side of this technology, and I started to document my work through a site called Processing and Interactivity for Educators.

To make a long story a little longer, I was offered a job here at SparkFun in the Department of Education, and was given the freedom to expand my collection of content around Processing, which in the end has turned into a book. We now use Processing as an introduction to programming tool to build interactive displays, data dashboards and a whole slew of other widgets and tools. We see it as computational duct tape.

What was the most fun?

The most fun was getting see my content go into book form. I am really proud of the work that not only I put into building a progression of learning around Processing, but also the content and code snippets from my co-workers. During the writing process there were a number of times where I really liked something I saw someone else teach or create and said to myself, “That’s going in the book!”

I also took great pleasure in writing the chapter about using images in Processing. I have been torturing my co workers by using their pictures for examples and modifying and contorting them, knowing full well that they would end up in a book. There is a specific image that I am especially proud of; you will know it when you see it!

What was the least fun?

You would think technical editing would be easy for me to go through since I work here at SparkFun – it wasn’t. With no formal background in computer science or programming, I have found that how I describe what is going on, the terms I use, and sometimes my complete understanding of things is, well…wrong. But I think there is a need for a book and content that is somewhere in between oversimplification and a stuffy textbook; I hope this book is it.

I am working with technical editing to compromise on some of the things that turn many people off to programming and programming books in general. I usually take the stance that as long as I get people in the right frame of mind or understanding using metaphors, I can be close to correct but not technically correct. Technically correct doesn’t condone play; I prefer to make someone comfortable with what they are learning, to get the big picture and then act on it. I don’t know how many technical books I have read that caused me to lock up mentally and not know how to put any of it into practice. I want to make sure that this book is not one of those books. The professors can deal with technical and theoretical, I am concerned with the reader diving in and doing.

What advice would you give someone considering writing a book?

There is a lot of advice I could give, but even I wouldn’t follow it. Take it with a grain of salt.

  • If you feel that you are too busy to write a book…you are.
  • Develop thick skin, you will see a lot of red on your work – that is a good thing! (Thank you Jennifer!)
    • I know there will be things people will see as “wrong” in the book; don’t take trolls personally.
  • There will be a conflict between your writing process and your schedule and due dates; it is a known fact.
  • You will end up hating your book until you finish it, and then it will be precious to you.
  • Humility is always the answer.
  • Be reading something other than your own work while you are writing.
  • Walk away, don’t write for a while and do something of a different modality.
  • Print out a chapter every once and a while and literally burn it, tear it up and/or yell insults at it. Trust me, it will make you feel better.
  • Do it!

Thanks Derek - great job and we can’t wait to see the book when it comes out!

comments | comment feed

Big Birthday Bash – the aftermath

via Raspberry Pi

We are all very tender, aching and sleepy. It was a fantastic weekend.

1300 of you came to see us at the University of Cambridge Computer Laboratory over the weekend, where you listened to 24 lecture theatre talks, took part in 14 workshops, shared hundreds of incredible projects you’d made with your Pis, and ate 110 pizzas.

2015-02-28 13.21.11

2015-02-28 13.20.57

The workshops were amazing: thanks so much to everybody who helped run them. Here’s Imogen, age 10, who is a Scratch pro (we loved your maze game, Imogen!): this is the first time she’s ever done any robotics, and we thought her robot turned out just great.

Alan McCullagh came all the way from France, where he runs the Rhône Valley Raspberry Jams, to join the other volunteers teaching kids in the Beginners’ Workshop.

16508273319_41bbbd7aaa_z

(Private note for Alan: ROWER. I said ROWER.)

The projects on display were brilliant. Phil Atkin brought along PIANATRON, his Raspberry Pi synthesiser. Pete from Mythic Beasts (you can only see his hands), who is such a good pianist I’m always too embarrassed to play in front of him, was joined by Jonathan “Penguins” Pallant on the “drums”. (Jonathan gave me an update on the penguins project: the Pis all survived the Antarctic winter; however, the solar panels did not, so some more work’s being done on how to manage power.)

We loved watching kids see the music they were making.

magic keyboard

Some kids learned a bit of history.

2015-02-28 12.46.45

Others got to work on custom devices.

2015-02-28 14.34.33-1

Brian Corteil’s Easter Bunny (which he lent us last year for YRS) made an appearance, and laid several kilos of chocolate eggs.

16072840153_6b9898bddd_z

We found more kids in quiet corners, hacking away together.

kids

Workshops aren’t just for young learners: here’s Dave Hughes, the author of the PiCamera library, giving a PiCamera workshop to some grown-up users.

davepicamera

There were 24 talks: here’s our very own Carrie Anne explaining what we do in education.

16487145207_f8944e2252_z

A certain Amy Mather made a Pi photobooth, the results of which, in this particular instance, I found horrifying.

lizphotobooth

Vendors set up stands to sell Pis and add-ons on both days. Here’s Pimoroni’s stand, as gorgeous as ever.

16675607665_17b9204e05_z (1)

All the cool kids played retro games.

gaming

Poly Core (Sam Aaron and Ben Smith) provided live-coded evening entertainment. (My Mum, who came along for the day, is still adamant that there must have been a tape recorder hidden in a box somewhere.) They were amazing – find more snippets on their Twitter feed.

Dan Aldred brought a newly refined version of PiGlove. The capitalisation of its name is of utmost importance.

Screen Shot 2015-03-02 at 14.17.00

Ben Croston from the Fuzzy Duck Brewery (and author of RPi.GPIO) uses a Raspberry Pi controller in the brewing process, and made us a batch of very toothsome, special edition beer called Irration Ale (geddit?) for the Saturday evening event.

Screen Shot 2015-03-02 at 10.52.17

There was cake.

cake

It was a bit like getting married again.

weddingphoto

There was more cake.

B_AF-wlXIAA70AR

After the beer (and raspberry lemonade for the kids) and cake, several hundred people played Pass the Parcel.

The foyer centrepiece was a talking throne which we borrowed from an exhibition at Kensington Palace (thank you to Henry Cooke and Tim from Elkworks for making it, and for your heroic work getting it to Cambridge!) We understand a door had to be removed from its frame at Kensington Palace to get it here.

throneempty

A selection of members of Team Pi were photographed on it. Please note the apposite labelling – the throne uses a Pi with RFID to read what’s on the slates out loud. (Ross has cheese on his mind because we interrupted his burger for this shot.)

gameofthrones

And we appear to have lost Eben. He was last seen heading towards Bedford in an outsized, Pi-powered Big Trak.

Enormous thanks to all the exhibitors and volunteers – and most especially to Mike Horne, Tim Richardson and Lisa Mather, who made this weekend what it was. We can’t thank the three of you enough.

There was so much more – we were so busy we didn’t get pictures of everything, and I didn’t manage to get to talk to anything like as many of you as I’d like to have done. (Does anybody have a picture of the gerbils?) I’ll add links to other people’s accounts of the weekend’s events as they come in.

Thank you to the University of Cambridge Computer Laboratory for letting us take over the building for the weekend.

Thank you to our incredibly thoughtful and generous sponsors for the pass-the-parcel gifts, the contents of the goodie bags, and other giveaways:

  • 4tronix
  • @holdenweb
  • @ipmb
  • @whaleygeek
  • Adafruit
  • AirPi (Tom Hartley)
  • Bare Conductive
  • Brian Cortiel
  • CamJam
  • CPC
  • CSR
  • Cyntech
  • Dawn Robotics
  • Dexter Industries
  • Django
  • Eduboard
  • Energenie
  • Farnell
  • GitHub
  • IQaudIO
  • Low Voltage Labs
  • Manchester Girl Geeks
  • ModMyPi
  • MyPiFi
  • NewIT
  • No Starch Press
  • O’Reilly
  • PiBorg
  • Pimoroni
  • PiSupply
  • RasPi.TV
  • RealVNC
  • RS Components
  • RyanTeck
  • Sugru
  • The Pi Hut
  • UK Space Agency
  • Watterott
  • Wiley
  • Wireless Things

Tableware and Decorations were kindly sponsored by:

  • @WileyTech
  • @RealVNC

 Wood and Laser Cutting was generously sponsored by:

  • @fablabmcr (FabLab Manchester)

rainbow

Low-Voltage Tesla Coil Uses a Relay Instead of a Spark Gap

via Hackaday » hardware

[Teodor] writes in with a unique Tesla coil he designed and built. Unlike most Tesla coils, [Teodor]’s design is able to run with a fairly low input voltage because it doesn’t use a static spark gap like most Tesla coils. Instead, his coil uses a relay in place of a spark gap.

[Teodor] built his coil using leftover components from his old school, making good use of some parts that might have otherwise been thrown away. The most critical component of his circuit, the relay, is just a standard normally-closed relay that is rated at 20A. [Teodor] wired the relay so that it energizes its own coil whenever it is shut. This causes the relay to briefly open every time the coil is energized, creating a resonant circuit. The resonant circuit charges a tank capacitor and places it in series with the primary coil inductor every time the relay closes, forming the tank circuit of his design.

With [Teodor]’s design, the resonant frequency of the secondary is nearly identical to that of the primary. This creates a significant voltage boost, helping produce very high voltages from such a low input voltage. The only downside to this design that [Teodor] recently discovered is that the relay contacts get red-hot after a few minutes of operation. Not optimal, but it still works! Check out [Teodor]’s writeup for more details and instructions on how to build your own.


Filed under: hardware, how-to

Reverse Engineering Wireless Temperature Probes

via Hackaday » hardware

[bhunting] lives right up against the Rockies, and for a while he’s wanted to measure the temperature variations against the inside of his hour against the temperature swings outside. The sensible way to do this would be to put a few wireless temperature-logging probes around the house, and log all that data with a computer. A temperature sensor, microcontroller, wireless module, battery, case, and miscellaneous parts meant each node in the sensor grid would cost about $10. The other day, [bhunting] came across the exact same thing in the clearance bin of Walmart – $10 for a wireless temperature sensor, and the only thing he would have to do is reverse engineer the protocol.

These wireless temperature sensors are exactly what you would expect for a cheap piece of Chinese electronics found in the clearance bin at Walmart. There’s a small radio operating at 433MHz, a temperature sensor, and a microcontroller under a blob of epoxy. The microcontroller and transmitter board in the temperature sensor were only attached by a ribbon cable, and each of the lines were labeled. After finding power and ground, [bhunting] took a scope to the wires that provided the data to the radio and took a look at it with a logic analyzer.

After a bit of work, [bhunting] was able to figure out how the temperature sensor sent data back to the base station, and with a bit of surgery to one of these base stations, he had a way to read the temperature data with an Arduino. From there, it’s just a data logging problem that’s easily solved with Excel, and [bhunting] has exactly what he originally wanted, thanks to a find in the Walmart clearance bin.


Filed under: hardware, home hacks

Happy birthday to us!

via Raspberry Pi

It’s the Raspberry Pi’s third birthday today (or as near as we can get: we launched on February 29 in a leap year). To celebrate we’re having a huge party/conference/scrum over the weekend in Cambridge – we’ve sold 1,300 tickets and I’m currently hiding in the press room to get this post written. I’m on a really overloaded WiFi network, so I’m having trouble uploading pictures at the minute: we’ll have some for you next week.

Three years ago, we made 2,000 little computers, and I remember looking at the pallet, and thinking: “Cripes. Can’t believe we’ve made so many computers. That’s amazing.”

We’ve sold half a million of the things just this month. Thanks to everyone who’s joined us on this extraordinarily weird journey – you’re all brilliant.

This is becoming an annual tradition: Matt Timmons Brown, one of my favourite 15-year-olds, has made us another celebratory video. (Here’s last year’s.) Thank you Matt!

 

 

New Product Friday: MicroView Mayhem

via SparkFun Electronics Blog Posts

This is an interesting week for new products. We have a bit of a dichotomy in the product selection. One on side, we have a flagship product, the new SIK for MicroView. On the other side, we have the stuff that didn’t pass quality control.

You might think it’s fun running your fingers through a box full of PCBs. But it’s not. Not only are the edges sharp, but the headers are like little knives. Sure, it looked cool. But I don’t recommend anyone trying this at home. I also don’t recommend doing this in multiple takes.

SparkFun Inventor's Kit for MicroView

KIT-13205
$ 89.95

You might remember the MicroView from the Kickstarter. It’s now a fully-fledged product on our site, and is at the heart of the new SparkFun Inventor’s Kit for Microview. The SparkFun Inventor’s Kit for MicroView provides you not only with the MicroView module and its programmer, but also everything you need to hook up and experiment with multiple electronic circuits!

If you want to learn more about the kit, we made a special video that you should check out.

Ding and Dent Production Builds

DD-13265
$ 2.95

Ding and dent. Who doesn’t love the rush you get placing an order for something, not knowing what it will be, or if it will even be remotely usable? This week we’ve combined all of our production ding and dents into a single SKU that’s just overflowing with who-knows-what. The picture above is a good representation of what you MIGHT get, but there are no guarantees. Just under $3 gets you one piece (limit 10 per customer). We can’t provide tech support and can’t say what you’ll get, so if gamlbing isn’t your thing, this might not be for you.

That’s all we have for this week. But don’t worry, there’s more coming next week, so be sure to check back. Thanks for watching and reading, see you then!

comments | comment feed