In the previous installment of this article we talked about the National Instruments VISA (Virtual Instrument Software Archetecture) standard for communicating with your instruments from a computer, and introduced its Python wrapper with a simple demonstration using a Raspberry Pi. We’ll now build on that modest start by describing a more useful application for a Raspberry Pi and a digital oscilloscope; we’ll plot the bandwidth of an RF filter. We’ll assume that you’ve read the previous installment and have both Python and the required libraries on your machine. In our case the computer is a Raspberry Pi and the instrument is a Rigol DS1054z, but similar techniques could be employed with other computers and instruments.

Our Real World Problem: A Low Pass Filter

A prototype low-pass filter for the 10m amateur radio band was designed using the QUCS simulator. The band sits at the top of the HF spectrum, from about 28 to 30 MHz, so the idea was to create a filter that lets everything below 30MHz through and attenuates everything above that frequency. The simulation showed a cut-off at 30MHz and a flat response for the upper 2 MHz of the passband. Almost perfect for the application.

But before celebrating it’s worth checking, does the filter really perform as well as its simulation? For that we need to measure its real-world performance, and to save the effort of repeated manual readings and calculations we’re going to automate the task using a Raspberry Pi.

Our task is to measure input and output voltages for a range of RF frequencies covering the filter’s pass and stop bands, and to calculate the attenuation for each set of readings. As a source of our RF we’re going to use the Raspberry Pi’s on-board clock generator. This produces a logic-level output on pin 7 of the expansion connector which, after passing through a DC blocking capacitor, we’ll send to our filter.

Both input and output are taken into 50 ohm loads from which the ‘scope measures the RMS voltage. Our script then takes the two readings, and calculates a dB figure for the filter’s attenuation. It’s not the perfect measurement in that the input is not a sine wave, however once it has been through the DC blocking capacitor and faces the filter input at the terminator on the scope it’s a nasty rounded off waveform that for our purposes we can assume is an approximation to a sine wave without too much bother. We are interested in the shape of the curve rather than the absolute quality of the readings, so all that matters for us is that they are consistent.

Taking The Measurements

So our filter was mounted on our Raspberry Pi, and the ‘scope was hooked up with BNC leads, T-pieces, and terminators. The channels were enabled, what next? We already had Python and the required libraries from our previous excursion into Pi-scope communication, so it only remained to download and compile a copy of [Jan Panteltje]’s freq_pi signal generator.

This version has a mod to recognize more recent Pi processors, which the original lacked. Then the script below was created, and modified to reflect the path to the freq_pi executable and the Rigol’s resource name as described in the previous installment of this series. A better script might retrieve this last value from the ‘scope, but is beyond this demonstration. Specify start, end, and step frequencies in Hertz, and it will loop through each value and calculate a dB attenuation figure from the input and output readings for each one.

We saved our copy of the Python code as db-filter-analyser.py.

#!/usr/bin/env python
import time
import math
import subprocess
import visa
import matplotlib.pyplot as plt
#Start, end, and step frequencies in Hertz
startfreq = 25000000
endfreq = 32000000
freqstep = 100000
#The resource name for your 'scope, you'll need to change this line
resourcename = 'USB0::6833::1230::DS1ZA123456789::0::INSTR'
#Location of the freq_pi executable
freqgen = "/home/pi/freq_pi/freq_pi"
#Open the resource manager
rm = visa.ResourceManager('@py')
#Open the 'scope by name
oscilloscope = rm.open_resource(resourcename)
#Return its ID string to tell us it's there
print(oscilloscope.query('*IDN?'))
#Set up arrays, then loop
graphfreqs,graphdbs = [],[]
for freq in xrange(startfreq,endfreq,freqstep):
    print freq
    subprocess.call([freqgen, "-f", str(freq)]) #Call the RF generator
    #Read the input values from the 'scope and extract a float.
    #Input
    time.sleep(0.1) #Let everything catch up
    #Change CHAN to your channel number
    oscilloscope.query(':MEAS:SOUR:CHAN1')
    fullreading = oscilloscope.query(':MEAS:ITEM? VRMS,CHAN1')
    readinglines = fullreading.splitlines()
    inputreading = float(readinglines[0])
    #Output
    time.sleep(0.1) #Let everything catch up
    #Change CHAN to your channel number
    oscilloscope.query(':MEAS:SOUR:CHAN2')
    fullreading = oscilloscope.query(':MEAS:ITEM? VRMS,CHAN2')
    readinglines = fullreading.splitlines()
    outputreading = float(readinglines[0])
    #Calculate a dB value from the two readings
    decibels = 20*math.log10(outputreading/inputreading)
    print decibels
    #Add the values to the arrays
    graphfreqs.append(freq)
    graphdbs.append(decibels)
#Stop the RF
subprocess.call([freqgen, "-q"])
#Create our graph
plt.plot(graphfreqs,graphdbs)
plt.ylabel('dB')
plt.xlabel('Frequency')
plt.show()

Running the code requires sudo to use the USB port, for simplicity in this demonstration. If you are pursuing this you may want to allow your ‘scope to be used by non-root users by setting up udev rules for it. So meanwhile with the ‘scope turned on, connected, and with the respective channels enabled, we ran the script as follows:
sudo python db-filter-analyser.py

How Well Did It Match The Simulation?

A list of dB readings from the filter scrolled up the screen, and eventually the graph appeared. So, how did our filter do? As you can see from the resulting plot on the left it exhibited a sharp cut-off, so it’s good at the job of being a low-pass filter. Unfortunately though it’s about a MHz too low, cutting off just below 29 MHz rather than the 30 we found in our simulation. Perhaps this is a function of component tolerances, or maybe just a misplaced trust in simulation. For this design at least it seems a return to the drawing board is in order.

The filter characterization shown here is not the most elegant way to perform the task, but it shows how it (and measurement problems like it) can be performed with the kind of equipment you have on your bench. You can control your instruments and take measurements from a computer — it’s no Dark Art — and you should have a go yourself with your own instruments and measurement problems. Whatever you do, be sure to share it with us on Hackaday.io!

Breakfast, a Brooklyn-based hardware firm known for creative marketing installations, unveiled their Flip-Disc Display System this morning. Used displays have come up on the usual sites from time to time, but often without a controller. Traditional flip-dot manufacturers haven’t sought out the individual hacker or hackerspace, and a click-to-buy option has been difficult if not impossible to find.

Breakfast’s offering modernizes the driver used to manage all of those electro-mechanical pixels. Whether this will make the displays more accessible is a question that still needs to be answered.

Breakfast has designed their own driver circuit for each panel of 28×28 pixels which includes a Cortex-M microcontroller. The easily daisy-chainable panels (using cat5 + power) pump up the maximum data propagation across a display by at least two orders of magnitude over traditional drivers. The demo video below shows 30 FPS being controlled by a time-of-flight camera (an ASUS Xtion in this case but that could change for production). Each panel draws about 300 mW at rest and typical full-motion operation is 25-50 W per panel but the system does have intelligent power design to cap total power draw.

Can you own one? Probably not — but that’s just because of your pocketbook. Breakfast wouldn’t give an exact price, but they did oblige when we asked for an approximation in terms of Honda Fits. Minimum order is 15 panels (140×84 pixels or about 7’x4.25′) and will run you about 6.25 Honda Fits.

Despite your not having low-six-figures lying around to spend on this, it is a notable development. The modernization of the driver, addition of an app and programming API, and a push to sell to a wider customer base should reinvigorate the occurrence of flip-dot displays which have been all but extinct this century. If there is a surge in purchases it will be many years before the secondary market benefits, but hopefully a groundswell of interest will encourage them to make the hacker-edition of their display available for a more… flippant… price.

We’ve seen a lot of work come out of Breakfast, notably this 6,400 pixel colored-thread display which is a mechanical engineering playground. When it comes to flip-dots, nothing beats what we saw at CES in 2015.

Choice is always a good thing, and now SiFive, a fabless semiconductor company, has released the HiFive1 as a crowdfunding campaign on CrowdSupply. It’s a RISC-V microcontroller, completely open source, and packaged in the ever so convenient Arduino form factor.

The heart of the HiFive1 is SiFive’s FE310 SoC, a 32-bit RISC-V core running at 320+ MHz. As far as peripherals go, the HiFive1 features 19 digital IO pins, one SPI controller, 9 PWM pins, an external 128Megabit Flash, and five volt IO. Performance-wise, the HiFive1 is significantly faster than the Intel Curie-powered Arduino 101, or the ARM Cortex M0+ powered Arduino Zero. According to the crowdfunding campaign, support for the Arduino IDE is included. A single HiFive1 is available for $59 USD.

Since this is an Open Source chip, you would expect everything about it to be available. SiFive has everything from the SDK to the RTL available on GitHub. This is an impressive development in the ecosystem of Open Hardware, and something we’re going to take a look at when these chips make it out into the world.

The previous installment of Life on Contract discussed how one might find clients as an engineering contractor or consultant while also taking a bit of time to pull apart the idea of whether life on contract is appropriate as opposed to, for example, bootstrapping a business instead. Assuming you are set on working as a contractor, let’s talk about what happens after you have found a prospective client (or perhaps more likely: after they have found you.)

WARNING: this article features an utter lack of success tips and tricks. Partly because those can be found in any seminar or business self-help book, but mostly because I do not have a foolproof recipe for success, and cheat codes to unlock easy mode still elude me. But I have witnessed (or committed) and reflected on many excellent ways to fail at contracting; or at the very least succeed in not being invited back.

Just because I won’t be sharing success stories doesn’t mean success has no learning value. Got a success story, or a better way to fail? Tell us about it in the comments!

How to Fail (or at Least Not be Invited Back)

The kind of contracting or consulting I’m discussing is mainly about solving problems. Put another way, I have found that successful contracting is mostly about taking problems away, and making your client’s life easier. They should see you as money well spent.

Failing at contracting is all about making life harder for your client. Barring actual negligence or incompetence, there are plenty of ways this can happen.

Talk the Client Out of Wanting You

Clients will have problems, and one or two of them will happen to be ones they want you to solve; that’s why they are seeking expert help. Their problem may be specific — “we need someone to convert these from through-hole to surface mount” — or it may be something broader — “we’ve been making these in our garage but need to make them faster and cheaper, how do we do that?”. There’s always a clear need, even if the client is having trouble articulating it.

The simplest and most efficient way to fail is to nip the whole contract in the bud. A client decides against hiring you when they don’t see you as an added value. The reasons for failing in this way (again, barring negligence or incompetence) always come down to a tragic failure to communicate. You may genuinely fail to understand the client’s needs, you may fail to communicate to them that you do understand, or you may otherwise fail to present yourself as a viable solution to any of their problems.

Let’s examine some excellent and common ways to make a client decide against hiring you:

• Don’t speak the client’s language. You don’t know their terms and don’t understand anything about their industry. If they are a print shop, you have no idea how print shops operate or do business. If they are artists, you speak only in engineering terms and jargon. Being unable to relate makes clients feel that they are out of their depth, or that you’re just from a different and less-compatible world. It ensures that explaining things always takes maximum effort, and a client is never really certain you’re actually on the same page. Avoid this by studying the client’s industry and terminology.

• You aren’t on the same wavelength. If a client is focused on wanting to understand how to best do a small in-house production run versus offloading it to a contract manufacturer, then focusing on specific yet irrelevant details like the finer points of injection molding, or KiCad vs Eagle, can lead to failure. You’re on the same topic, but not at all in tune to what they actually want to do or know. Avoid this by taking time to ensure you understand what advice the client is actually seeking, even if they haven’t asked for it in the most direct way.

• Be a Magic 8-Ball whose only answer to every question is “it depends.” If you can’t provide direct answers to most questions, then regardless of how correct your waffling is you’re probably not understanding what the client needs from you. In all likelihood, what your prospective client actually needs is an understanding of a situation or process they are facing. Put another way, they don’t need exact numbers and you’re not being asked to commit to a deadline; they’re asking because they need to understand what has to happen and when, so they can budget and plan. You are being asked because they want someone who has been-there-done-that to “get” what they are doing and be a guide. Waiting patiently while prospective clients ask you question after question (to which every answer is some form of “it depends”) is an excellent way to talk a client out of contracting you, because it makes it clear you won’t be making their problem or uncertainty go away.

The best thing about these methods of failure is that they don’t require all that much effort. In fact, simple inattention or inaction is most of what’s needed. So long as you’re not actively trying to help communication in an initial meeting, things have an excellent chance of going wrong all on their own.

Give the Client Second Thoughts After You Get the Contract

An engineering contractor is not normally involved in a client’s day-to-day business operations; at least, not in the kind of contracting and consulting we’re talking about. Your work and the expectations from you — both explicit and implicit — are different from those of an employee. Failing to meet those expectations is the key to making your client wonder if contracting you was a mistake.

For example, let’s say a client has a product and you have been hired to optimize the board layouts and reduce PCB costs. Showing up on the first day with open hands and an open heart, brightly asking “Okay! Where do you want me to start?” is a great way to make your client think twice about hiring you as an expert; someone who was supposed to know more than they did themselves.

In addition to whatever you were officially hired for, you need to be money well spent. If you are not actively solving or removing problems in some way, then you are probably not clearly adding value. You may even be making your client’s life harder instead of easier.

It may remain unsaid, but as a contractor or consultant you are at least partly being hired for your judgment. The less effectively you wield your judgment, the more your client will start to think you were a mistake. Here are some great ways to ensure that happens.

• Constantly halt what you’re doing with “how do you want me to…” questions for your client. The more this happens, the more likely you are to plant second thoughts in the mind of the client. Asking this for what seems like every conceivable detail, and at every possible fork in the road and failing to gather information you need up front will raise red flags. It’s bad form to be seeking approval and direction for issues you should be able to handle yourself if you actually understood the client’s needs and problem scope. This behavior makes sure that the problems stay front and center, and very much still on the client’s plate. As a bonus, you will almost certainly appear to be “winging it” instead of having experience and a plan.

• Be overly focused on details unrelated to your client’s actual needs. If your client thinks you’re focused on irrelevant details, they won’t see that your work has any value. If the details in question actually are relevant (but perhaps not obviously so) then you must ensure your client understands the relevance. You may be extremely knowledgeable, but that doesn’t mean you can’t spend the first weeks of a contract installing and minutely benchmarking every possible different database backend to find out which one yields marginally better performance, only to find out that your client isn’t actually willing to change database software and (shocker!) frankly doesn’t see how a marginal improvement could possibly be worth all that effort when they just wanted you to integrate a live stock count into their e-commerce site.

• Be unable to actually get something done. Having a poor sense of proportion can hobble your measurable progress. If firmware on a given microcontroller architecture is 90% working, throwing it all out to begin again the instant a newer and faster part comes out is a great way to fail. There is such a thing as smart people who are unable to get a job done. In the business world where everything is a trade-off because everything costs in one way or another, clients are well aware that there is “good” and there is “good enough.” Does a solution do the job? Can it be achieved within the budget and time allowed, without painting you into an unacceptable corner? If so, then that’s Good Enough. Smart, knowledgeable people who can crank out high-quality work quickly may still never actually get anything done because they constantly take off like a heat-seeking missile after the latest and greatest, or obsess over details irrelevant to making something work.

Have you managed to get a job done despite all that? Don’t worry, there’s still a chance to fail!

Make Sure You Don’t Get Invited Back

Life on Contract: How to Find Clients as an Engineering Contractor matched my own experience, particularly in the observation that a good portion of your work will come from referrals. That means that if you really want to make a go of life on contract, leaving a client feeling like you didn’t really add value is a really great way to snatch failure from the jaws of success.

If your client doesn’t feel that you were worth the money, or that you were just too hard to work with, you won’t be invited back — either to more work, or to conversations that begin with “who can we talk to about…”

Here are ways to tarnish the shine of a completed project:

• You didn’t do things when you agreed they would be done. Failing to keep deadlines or to report on your progress is a great way to get ejected from a client’s contact list. If your estimates and progress reporting become known for not being reliable, even if your work is of outstanding quality, you may simply be judged Too Hard To Work With. As covered in Life On Contract: Estimating Project Time, estimates are important for planning and budgeting both time and money. Making sure yours aren’t reliable is a great way to cause cascading disruption in other people’s work every time it happens.

• You didn’t take (or make) time to polish the results of your work. Finishing touches on something go a long way to communicating value and the work that went into it. Whether it’s software or hardware, you may know it inside out by the time you’re done but most people won’t be seeing it as a raw expression of function. Leave your work looking like a hack job, and you’ll be thought of as one.

• Let the value you added go unnoticed. There is a somewhat cynical saying about work that no one knows was done: it might as well not have happened. As a contractor there will always be some pressure to show you were worth what you charged. You may be making tremendous progress and adding excellent value, but if your client is unaware of any of it, they won’t know you were responsible for that value. Modesty may be a virtue, but also another way to fail at getting called back.

All of this type of behavior will ensure that if you find a client, they won’t hire you. If they do, they’ll regret it. And if your contract completes, they won’t want you back. Since a good chunk of work will come from people knowing you as “the person who knows about that stuff and can get it done”, falling into these bad habits will virtually guarantee you are free from clients.

These are of course from my own observations in both the working and hiring ends of contracting, but they are still only my own narrow slice of a wide and varied field. Have you got your own success or failure stories to add or admit to? You know you do; share them in the comments.

Many decades later that early crop of reactors has now largely been decommissioned. Power too cheap to meter turned into multi-billion pound bills for safely coping with the challenges posed by many different types of radioactive waste generated by the dismantling of a nuclear reactor, and as the nuclear industry has made that journey it in turn has spawned a host of research projects based on the products of the decommissioning work.

One such project has been presented by a team at Bristol University; their work is on the property of diamonds in generating a small electrical current when exposed to radioactive emissions. Unfortunately their press release and video does not explain the mechanism involved and our Google-fu has failed to deliver, but if we were to hazard a guess we’d ask them questions about whether the radioactivity changes the work function required to release electrons from the diamond, allowing the electricity to be harvested through a contact potential difference. Perhaps our physicist readers can enlighten us in the comments.

So far their prototype uses a nickel-63 source, but they hope to instead take carbon-14 from the huge number of stockpiled graphite blocks from old reactors, and use it to create radioactive diamonds that require no external source. Since the output of the resulting cells will be in proportion to their radioactivity their life will be in the same order of their radioactive half-life. 5730 years for half-capacity in the case of carbon-14.

Of course, it is likely that the yield of electricity will not be high, with tiny voltages and currents this may not represent a free energy miracle. But it will be of considerable interest to the designers of ultra-low-maintenance long-life electronics for science, the space industry, and medical implants.

We’ve put their video below the break. It’s a straightforward explanation of the project, though sadly since it’s aimed at the general public it’s a little short on some of the technical details. Still, it’s one to watch.

Maybe the expense involved limits the number of diamond stories we cover here at Hackaday, but they can still be a hacker’s best friend. How about diamonds in thermal paste, or even for data storage?

[via Phys.org]

This play button isn’t just a bit of pot metal ensconced in a frame brought to you by Audible dot com; this YouTube play button actually does something useful. It’s a PCB with 144 LEDs working together as a display. There’s an Atmel SAMD21 microcontroller on board to drive the LEDs, and an ESP8266 to pull data down from the Internet. What data is worthy enough to go on an Arduinofied YouTube play button? The subscriber count for [Sean]’s channel, of course. Go subscribe, it might crash his Play button.

Admittedly, there were a few problems with this Play button PCB. Firstly, the ESP8266 can’t directly communicate with the YouTube API to pull down the subscriber count. That problem was fixed with a Raspberry Pi that could connect to the API, and programming the ESP to pull the data from the Pi. Second, this was [Sean]’s first experiment with double-sided SMD boards reflowed in a toaster oven. The first side to be assembled was easy, but to get the second side on, [Sean] turned to low-temp bismuth solder paste. Except for a small error in assembling the board, everything worked as planned.

It’s a great project, and if you want to check out what the better parts of YouTube look like, check out [Sean]’s video below. Don’t forget to rate, comment, like, unlike, or subscribe.

To solve this problem, [Audrey] created OpenWheel, a system of parametric, 3D-printable wheels, tweels, tires, and tracks for robotics and more.

Like all good parametric 3D-printable designs, OpenWheel is written in OpenSCAD. These aren’t 3D designs; they’re code that compiles into printable objects, with variables to set the radius, thickness, diameter of the axle, bolt pattern, and everything else that goes into the shape of a wheel.

Included in this toolset are a mess of wheels and gears that can be assembled into a drivetrain. 3D-printable track that can be printed out of a flexible filament for something has been almost unobtanium until now: completely configurable 3D-printable tank treads. All we need now is a 3D-printable tank transmission, and we’ll finally have a complete hobby robotics chassis.