Friday, August 31

Lead in US school water “disturbing”—Detroit just shut off all fountains

EU Commission President supports ending seasonal time changes

Dumping A Zelda SNES ROM, And Learning A Few Things Along The Way

For many of us, being given a big old DIP ROM from nearly thirty years ago and being told to retrieve its contents would be a straightforward enough task. We’d simply do what we would have done in the 1980s, and hook up its address lines to a set of ports, pull its chip select line high, and harvest what came out of the data lines for each address.

But imagine for a minute that an old-fashioned parallel ROM is a component you aren’t familiar with, as [Brad Dettmer] did with the ROM from a SNES Zelda cartridge. We’ve seen plenty of reverse engineering stories with ancient computing gear as their subject, but perhaps it’s time to accept that some of the formerly ubiquitous devices are edging towards that sort of status.

So [Brad] takes us through the process of using the Saleae logic analyser to interrogate the chip while an Arduino stepped through its address lines, and the lesson is probably that while it seems like a sledgehammer to crack a nut it is important to factor in that unfamilarity. If you’d never worked with a 1980s ROM, it would make sense to use the tool you are familiar with, wouldn’t it?

Anyway, all’s well that ends well. While we’re on the subject of Nintendo ROMs, have a read about extracting the boot ROM from a cloned Game Boy.

Tips of the Week: Drilling Glass, Ice Pick Level, Organizing Small Parts, Combo Squares, and Clean Your Fingernails!

Another week, another roundup of great tips and tricks from the maker community.

Read more on MAKE

The post Tips of the Week: Drilling Glass, Ice Pick Level, Organizing Small Parts, Combo Squares, and Clean Your Fingernails! appeared first on Make: DIY Projects and Ideas for Makers.

Exclusive: Valve walks us through Artifact’s new demo, leaves us wanting more

Boeing wins competition to build Navy drone tanker prototypes

Optimizing Screen Time To Heart Beats

Medieval artisans built a glass-walled palace in the desert

Learn FPGA with this Persistence of Vision Hack

Everybody wants to give FPGA development a try and here’s a great way to get into it. You can build your own Persistence of Vision display using a $30 dev board. It’s a fun project, and you’ll learn quite a bit about designing for an FPGA, as well as using the Quartus design software.

The inspiration for this article comes from [vpecanins] who did an example project where you wave the board back and forth and a message appears in mid air. This uses the MAX1000, a pretty powerful yet odd FPGA board for about $30. It contains an Intel MAX10 (when did Intel start making FPGAs? Remember, Intel bought Alterra back in 2015). I find the board odd because it also holds an accelerometer that you can talk to using SPI. That’s a little strange for a generic FPGA board, but paired with eight on-board LEDs it’s perfect for this demo.

Since I didn’t find any written documentation for this example, I thought we’d help out and take you on a step-by-step tour of the project. What’s more, in a future installment, I’ll show you how to make some significant changes to the tutorial that will make it even more practical as a base for other projects.

Just for motivation, have a look at the video below to see what the project does. I modified the text (WD5GNR is my call sign), of course. The effect is better in real life, but the video will give you the idea. The FPGA monitors the accelerometer reverses the order for flashing the LEDs on and off to form the characters. It is a pretty impressive demo since it takes advantage of the unique features of the board, is non-trivial, and isn’t too much Verilog to swallow if you are just getting started.

Prerequisites

To start with, you’ll need to install Quartus. The Lite edition is free and very capable. You can download the files and open the test0.qpf file in the demo02_led_text directory. You may get a nasty dialog about replacing the database if you have a newer version of Quartus than the original files used. You can safely agree to that.

File Tour

On the project navigator inside Quartus, you can select Files and you’ll see the project has only a few:

  • top.v – The main Verilog code.
  • programming_chain.cdf – This file should tell Quartus how to program the configuration into the chip, but it is missing. That’s not a problem though. It isn’t really necessary and it is easy to recreate.
  • font_rom.qip – A component that uses Altera IP (Intellectual Property) to create a ROM with the character patterns in it.
  • spi_master.v – Code for talking to the accelerometer.
  • macro.do – This file doesn’t actually exist and is apparently left over from the author’s earlier efforts.
  • sequencer.v – Code for using the accelerometer.

If you expand the font_rom.qip componet in the list, you’ll see there is a Verilog file hidden there. That file was generated by an IP wizard, so while you can look at it, you shouldn’t need to touch it. It uses the Altera Sync RAM IP block to create a chunk of memory. One thing to note is that the Verilog file does specify an init file which is font5x7.hex. That’s a standard hex file with the contents of the ROM. By the way, this is a ROM in name only. It is implemented in RAM but there’s no interface to write to it so from the design’s point of view it is read-only. It is not, however, nonvolatile. It will get rewritten every time you reconfigure the FPGA.

Again, all of that was set up by answering some questions in an IP wizard. You should be able to open the IP to change it with the Parameter Editor, but there seems to be some file missing to allow that or, perhaps, the author set it up by hand. However, you can see the process if you go to the IP Catalog in Quartus and open up Library | Basic Functions | On Chip Memory | ROM: 1 Port. It would be easy to replace the existing ROM with your own if you wanted the practice.

The Top Module

The top module has an interface to the 12 MHz system clock, the user button (which it uses as a reset), and the 8 LEDs. It also contains the signals to talk to the SPI accelerometer and 8 bits of parallel I/O that appears to be used for debugging (the design just copies some internal signals to those pins).

To tell the software where those ports need to go, you need to set location constraints, which the author already did. There are many ways you could do this. However, one way is to locate the tasks section of Quartus and pick “Full Design.” Then you’ll see a folder for “Assign Constraints.” Open that up and pick Edit Pin Assignments. From there you can set up all the I/O pins for the top module — their names, the type of pin it is, and exactly which pin on the FPGA it maps to.

If you prefer, you can use the Assignments item on the main menu and pick Assignment Editor. I like that better as it is like an easy-to-read spreadsheet format. If you didn’t already have the starter project, how would you know which pins the LEDs and things are on? That data is in the technical reference manual for the board. There’s also a spreadsheet in the directory that documents the assignments.

The rest of the module creates the SPI component and the sequencer component. If you notice, the sequencer has a single output “direction” which is mapped to the dir signal in the module. The other connections are just housekeeping like a clock and a connection to the SPI component.

What Do the Blocks Do?

There are a series of always blocks in the rest of the file. These generally correspond to a block of logic and, when combined with the posedge or negedge keywords, usually define a flip flop circuit.

always @(posedge CLK12M or negedge nrst) begin
        if (!nrst) begin
                divider <= 32'b0;
                divider_out <= 1'b0;
        end else begin
                if (divider != div_coef) begin
                        divider <= divider + 1;
                        divider_out <= 1'b0;
                end else begin
                        divider <= 32'b0;
                        divider_out <= 1'b1;
                end
        end
end

The first one simply divides the clock down since 12 MHz is a little fast. You can adjust the speed by changing the value of div_coef near the top of the file. The second block handles the ROM addressing.  Each character is 5 consecutive bytes out of the ROM. So the addr_lsb counts from 0 to 4 and then rolls over, setting char_inc to 1 as a signal to go to the next character.

always @(posedge CLK12M or negedge nrst) begin
        if (!nrst) begin
                addr_lsb <= 3'b0;
                char_inc <= 1'b0;
        end else begin
                if (divider_out) begin
                        if (addr_lsb == 3'b101) begin
                                addr_lsb <= 3'b0;
                                char_inc <= 1'b1;
                        end else begin
                                addr_lsb <= addr_lsb+1;
                                char_inc <= 1'b0;
                        end
                end else begin
                        char_inc <= 1'b0;
                end
        end
end

Another always block handles the character address. There are 16 characters stored in the foo array. The pos variable starts at zero and increments when char_inc is set. It rolls over at 16. This is good defensive programming because you might change the 16 number to something else. However, the 4 bit counter would roll over at 16 anyway, so in this case, it is a bit superfluous and I wouldn’t be surprised if the tools optimize that logic out anyway.

always @(posedge CLK12M or negedge nrst) begin
        if (!nrst) begin
                addr <= 10'b0;
        end else begin
                if (dir) begin
                        addr <= {foo[4'b1111 - pos] - 'h20, 3'b101 - addr_lsb};
                end else begin
                        addr <= {foo[pos] - 'h20, addr_lsb};
                end
        end
end

The foo array is where you can change the message. It really isn’t an array in the strictest sense. It is just some assignments that are indexed. That means at the moment you can’t change the message without rebuilding the FPGA, but we will fix that in the next installment. The real heart of everything, though, is the following always block. It forms an address where the top bits are the current character minus 20 hex. That subtraction cuts off non-printable characters. The bottom bits are the 3 bits counting from 0 to 4. That means the first location in the ROM is a space and takes up the first 5 words. Then the rest are the ASCII characters in order, each taking their own 5 words.

However, the address has an odd property. If the dir bit is set from the accelerometer, the character that provides the top bits is “flipped” end-to-end by subtracting the index into foo from 1111 binary. The bottom bits are also flipped by subtracting them from 5. This makes the foo index go 15, 14, 13… instead of 0, 1, 2… and also makes the line count go backwards.

So if dir is 0, the message is played back left to right and if dir is 1, it plays in reverse. The rest of the file is simple. The code instantiates the ROM and assigns its outputs to the various LEDs.

And the Rest…

I’ll let you explore the spi_master.v and sequencer.v files on your own. I will point out, though, that the sequencer is a good example of a state machine. There are 11 states, and the circuit moves from one to the next to send and receive the data it needs from the accelerometer. So, for example, here’s the code for the first three states:


case (state)

// 1. Read WHO_AM_I register (Addr 0x0F)
STATE_Whoami: begin
state <= STATE_Whoami_Wait;

spi_request <= 1'b1;
spi_nbits <= 6'd15;
spi_mosi_data <= 31'b10001111_00000000;
end

STATE_Whoami_Wait: begin
if (spi_ready) begin
state <= STATE_Init;
led_out <= spi_miso_data[7:0];
end
spi_request <= 1'b0;
end

// 2. Write ODR in CTRL_REG1 (Addr 0x20)
STATE_Init: begin
state <= STATE_Init_Wait;

spi_request <= 1'b1;
spi_nbits <= 6'd15;
spi_mosi_data <= 31'b00100000_01110111;
end

Note that led_out is for debugging and in the final code, that output isn’t connected to anything. The general structure of each state is to either do some action and set the next state or wait for some action to occur and then set the next state. Pretty easy. Of course, more complex state machines might have to decide which state is next, but not in this case. The real work is in the STATE_Compare state:

                        // 6. Compare X_OUT of the accelerometer to know the swipe direction
                        // The acceleration is maximum at the edges of the swipe, detect that
                        // and change direction accordingly.
                        STATE_Compare: begin
                                state <= STATE_Read;
                                
                                if (saved_acc < -8'Sb0010_0000) begin
                                        led_out <= 8'b1110_0000;
                                        direction <= 1'b0; end else if (saved_acc >  8'Sb0010_0000) begin
                                        led_out <= 8'b0000_0111;
                                        direction <= 1'b1;
                                end else begin
                                        led_out <= 8'b0001_1000;
                                end
                        end
                endcase

Don’t forget that led_out isn’t used in the actual project — it was just for debugging. When the sign of the acceleration changes beyond a dead band, the direction bit changes. Simple.

Configuration

You know you want to change the message to say something else so go ahead and modify the code where it sets up foo. Double clicking the compile design task will generate a SOF and POF file. The SOF file will send the configuration to the board but won’t save it. If you reset or power cycle you’ll lose that configuration on the board. You must program the POF file for the board to dutifully reload the configuration on start up.

If you double click the Program Device entry in the task list you’ll get a separate window for the programmer. You can follow the instructions in the MAX1000 user’s guide for the exact details, but the idea is to associate the SOF or POF file with the FPGA on the JTAG chain. If you see the device in the programmer, that’s good but if not you can always Auto Detect. Just make sure you have the hardware set for Arrow-USB-Blaster and the mode set to JTAG. You also may need drivers for your particular set up, so take a look at the user’s guide.

The only tricky part is when you program a POF file you need to be sure the Program Configuration check box is ticked. Then press Start and you are on your way.

Wrap Up

Learning FPGAs can be daunting. After all, you need to learn a complex piece of software, plus you need to learn Verilog (or VHDL) and get used to a new way of thinking about solving problems. On top of that, there are the usual things you have to learn about anything like how the devices connect and how to download a “program” to the board. But playing around with known working examples like this is a great way to gain an intuitive sense of how everything works.

With so much to learn, the [vpecanins] tutorial might not be your first step. But it wouldn’t be a bad second step. You can check out our FPGA boot camp if you want a gentler introduction. The first 3 boot camps are hardware agnostic, so what you learn would apply to the MAX1000. Intel has a lot of training available to learn about Quartus. In fact, there’s so much training it is sometimes hard to know where to start.

Next time, I’ll show you how to add a UART to the project so you can change the display on the fly through the USB port. That sounds hard but I’ll use a few tricks to make it relatively easy. If you want to try something easy, consider changing the code to use the LEDs like a bargraph to show the acceleration it reads.

Fertility doc inseminated dozens of women with own sperm, DNA sites find

New Mooltipass Begins Development with Call for Collaborators

One of the most interesting aspects of our modern world is the ability to work collaboratively despite the challenges of geography and time zones. Distributed engineering is a trend which we’ve watched pick up steam over the years. One such example is the Mooltipass offline password keeper which was built by a distributed engineering team from all over the world. The project is back, and this time the goal is to add BLE to the mini version of the hardware. The call for collaborators was just posted on the project page so head over and check out how the collaboration works.

The key to the hardware is the use of a smartcard with proven encryption to store your passwords. Mooltipass is a secure interface between this card and a computer via USB. The new version will be a challenge as it introduces BLE for connectivity with smart phones. To help mitigate security risks, a second microcontroller is added to the existing design to act as a gatekeeper between the secure hardware and the BLE connection.

Mathieu Stephan is the driving force behind the Mooltipass project, which was one of the first projects on Hackaday.io and has been wildly successful in crowd funding and on Tindie. Mathieu and five other team members already have a proof of concept for the hardware. However, more collaborators are needed to help see all aspects of the project — hardware, firmware, and software — through to the end. This is a product, and in addition to building something awesome, the goal is to turn a profit.

How do you reconcile work on an Open Source project with a share of the spoils? Their plan is to log hours spent bringing the new Mooltipass to life and share the revenue using a site like colony.io. This is a tool built on the Ethereum blockchain to track contributions to open projects, assigning tokens that equate to value in the project. It’s an interesting approach and we’re excited to see how it takes shape.

You can catch up on the last few years of the Mooltipass adventure my checking out Mathieu’s talk during the 2017 Hackaday Superconference. If this article has you as excited about distributed engineer as we are, you need to check out the crew that’s building this year’s Open Hardware Summit badge!

“Gold standard” net neutrality bill in US approved by California Assembly

Make Your Python Prettier With Decorators

Many Pythonistas are familiar with using decorators, but far fewer understand what’s happening under the hood and can write their own. It takes a little effort to learn their subtleties but, once grasped, they’re a great tool for writing concise, elegant Python.

This post will briefly introduce the concept, start with a basic decorator implementation, then walk through a few more involved examples one by one.

What is a decorator

Decorators are most commonly used with the @decorator syntax. You may have seen Python that looks something like these examples.

@app.route("/home")
def home():
    return render_template("index.html")

@performance_analysis
def foo():
    pass

@property
def total_requests(self):
    return self._total_requests

To understand what a decorator does, we first have to take a step back and look at some of the things we can do with functions in Python.

def get_hello_function(punctuation):
    """Returns a hello world function, with or without punctuation."""

    def hello_world():
        print("hello world")

    def hello_world_punctuated():
        print("Hello, world!")

    if punctuation:
        return hello_world_punctuated
    else:
        return hello_world


if __name__ == '__main__':
    ready_to_call = get_hello_function(punctuation=True)

    ready_to_call()
    # "Hello, world!" is printed

In the above snippet, get_hello_function returns a function. The returned function gets assigned and then called. This flexibility in the way functions can be used and manipulated is key to the operation of decorators.

As well as returning functions, we can also pass functions as arguments. In the example below, we wrap a function, adding a delay before it’s called.

from time import sleep

def delayed_func(func):
    """Return a wrapper which delays `func` by 10 seconds."""
    def wrapper():
        print("Waiting for ten seconds...")
        sleep(10)
        # Call the function that was passed in
        func()

    return wrapper


def print_phrase(): 
    print("Fresh Hacks Every Day")


if __name__ == '__main__':
    delayed_print_function = delayed_func(print_phrase)
    delayed_print_function()

This can feel a bit confusing at first, but we’re just defining a new function wrapper, which sleeps before calling func. It’s important to note that we haven’t changed the behaviour of func itself, we’ve only returned a different function which calls func after a delay.

When the code above is run, the following output is produced:

$ python decorator_test.py
Waiting for ten seconds...
Fresh Hacks Every Day

Let’s make it pretty

If you rummage around the internet for information on decorators, the phrase you’ll see again and again is “syntactic sugar”. This does a good job of explaining what decorators are: simply a shortcut to save typing and improve readability.

The @decorator syntax makes it very easy to apply our wrapper to any function. We could re-write our delaying code above like this:

from time import sleep

def delayed_func(func):
    """Return `func`, delayed by 10 seconds."""
    def wrapper():
        print("Waiting for ten seconds...")
        sleep(10)
        # Call the function that was passed in
        func()

    return wrapper


@delayed_func
def print_phrase(): 
    print("Fresh Hacks Every Day")


if __name__ == '__main__':
    print_phrase()

Decorating print_phrase with @delayed_func automatically does the wrapping, meaning that whenever print_phrase is called we get the delayed wrapper instead of the original function; print_phrase has been replaced by wrapper.

Why is this useful?

Decorators can’t change a function, but they can extend its behaviour, modify and validate inputs and outputs, and implement any other external logic. The benefit of writing decorators comes from their ease of use once written. In the example above we could easily add @delayed_func to any function of our choice.

This ease of application is useful for debug code as well as program code. One of the most common applications for decorators is to provide debug information on the performance of a function. Let’s write a simple decorator which logs the datetime the function was called at, and the time taken to run.

import datetime
import time
from app_config import log

def log_performance(func):
    def wrapper():
        datetime_now = datetime.datetime.now()
        log.debug(f"Function {func.__name__} being called at {datetime_now}")
        start_time = time.time()

        func()

        log.debug(f"Took {time.time() - start_time} seconds")
    return wrapper


@log_performance
def calculate_squares():
    for i in range(10_000_000):
        i_squared = i**2


if __name__ == '__main__':
    calculate_squares()

In the code above we use our log_performance decorator on a function which calculates the squares of the  numbers 0 to 10,000,000. This is the output when run:

$ python decorator_test.py
Function calculate_squares being called at 2018-08-23 12:39:02.112904
Took 2.5019338130950928 seconds

Dealing with parameters

In the example above, the calculate_squares function didn’t need any parameters, but what if we wanted to make our log_performance decorator work with any function that takes any parameters?

The solution is simple: allow wrapper to accept arguments, and pass those arguments directly into  func. To allow for any number of arguments and keyword arguments, we’ve used *args, **kwargs, passing all of the arguments to the wrapped function.

import datetime
import time
from app_config import log

def log_performance(func):
    def wrapper(*args, **kwargs):
        datetime_now = datetime.datetime.now()
        log.debug(f"Function {func.__name__} being called at {datetime_now}")
        start_time = time.time()

        result = func(*args, **kwargs)

        log.debug(f"Took {time.time() - start_time} seconds")
        return result
    return wrapper


@log_performance
def calculate_squares(n):
    """Calculate the squares of the numbers 0 to n."""
    for i in range(n):
        i_squared = i**2


if __name__ == '__main__':
    calculate_squares(10_000_000) # Python 3!

Note that we also capture the result of the func call and use it as the return value of the wrapper.

Validation

Another common use case of decorators is to validate function arguments and return values.

Here’s an example where we’re dealing with multiple functions which return an IP address and port in the same format.

def get_server_addr():
    """Return IP address and port of server."""
    ...
    return ('192.168.1.0', 8080)

def get_proxy_addr():
    """Return IP address and port of proxy."""
    ...
    return ('127.0.0.1', 12253)

If we wanted to do some basic validation on the returned port, we could write a decorator like so:

PORTS_IN_USE = [1500, 1834, 7777]

def validate_port(func):
    def wrapper(*args, **kwargs):
        # Call `func` and store the result
        result = func(*args, **kwargs)
        ip_addr, port = result

        if port < 1024:
            raise ValueError("Cannot use priviledged ports below 1024")
        elif port in PORTS_IN_USE:
            raise RuntimeError(f"Port {port} is already in use")

        # If there were no errors, return the result
        return result
    return wrapper

Now it’s easy to ensure our ports are validated, we simply decorate any appropriate function with @validate_port.

@validate_port
def get_server_addr():
    """Return IP address and port of server."""
    ...
    return ('192.168.1.0', 8080)

@validate_port
def get_proxy_addr():
    """Return IP address and port of proxy."""
    ...
    return ('127.0.0.1', 12253)

The advantage of this approach is that validation is done externally to the function – there’s no risk that changes to the internal function logic or order will affect validation.

Dealing with function attributes

Let’s say we now want to access some of the metadata of the get_server_addr function above, like the name and docstring.

>>> get_server_addr.__name__
'wrapper'
>>> get_server_addr.__doc__
>>>

Disaster! Since our validate_port decorator essentially replaces the functions it decorates with our wrapper, all of the function attributes are those of wrapper, not the original function.

Fortunately, this problem is common, and the functools module in the standard library has a solution: wraps. Let’s use it in our validate_port decorator, which now looks like this:

from functools import wraps

def validate_port(func):
    @wraps(func)
    def wrapper(*args, **kwargs):
        # Call `func` and store the result
        result = func(*args, **kwargs)
        ip_addr, port = result

        if port < 1024:
            raise ValueError("Cannot use priviledged ports below 1024")
        elif port in PORTS_IN_USE:
            raise RuntimeError(f"Port {port} is already in use")

        # If there were no errors, return the result
        return result
    return wrapper

Line 4 indicates that wrapper should preserve the metadata of func, which is exactly what we want. Now when we try and access metadata, we get what we expect.

>>> get_server_addr.__name__
'get_server_addr'
>>> get_server_addr.__doc__
'Return IP address and port of server.'
>>>

Summary

Decorators are a great way to make your codebase more flexible and easy to maintain. They provide a simple way to do runtime validation on functions and are handy for debugging as well. Even if writing custom decorators isn’t your thing, an understanding of what makes them tick will be a significant asset when understanding third-party code and for utilising decorators which are already written.

8 Projects You Can`t Miss at Maker Faire Moscow 2018

This year, the third annual Maker Faire Moscow festival coincides with the celebration of Moscow’s birthday.

Read more on MAKE

The post 8 Projects You Can`t Miss at Maker Faire Moscow 2018 appeared first on Make: DIY Projects and Ideas for Makers.

This city has a vision for mass transit that doesn’t involve city buses

Rocket Report: Exos flies, China sets launch record, new Falcon Heavy data

Single-Rotor Drone: a Thrust-Vectoring Monocopter

We’re not entirely sure what to call this one. It’s got the usual trappings of a drone, but with only a single rotor it clearly can’t be called by any of the standard multicopter names. Helicopter? Close, but not quite, since the rotor blades are fixed-pitch. We’ll just go with “monocopter” for now and sort out the details later for this ducted-fan, thrust-vectored UAV.

Whatever we choose to call it — builder [tesla500] dubbed it the simultaneously optimistic and fatalistic “Ikarus” — it’s really unique. The monocopter is built around a 90-mm electric ducted fan mounted vertically on a 3D-printed shroud. The shroud serves as a mounting point for the landing legs and for four servos that swivel vanes within the rotor wash. The vanes deflect the airstream and provide the thrust vectoring that gives this little machine its control.

Coming to the correct control method was not easy, though. Thanks mainly to the strong gyroscopic force exerted by the rotor, [tesla500] had a hard time getting the flight controller to cooperate. He built a gimballed test stand to work the problem through, and eventually rewrote LibrePilot to deal with the unique forces on the craft and tuned the PID loops accordingly. Check out the results in the video below.

Some attempts to reduce the number of rotors work better than others, of course, but this worked out great, and we’re looking forward to the promised improvements to come.

Thanks [Larry] and [Danie] for the tip!

Scientists found brain’s internal clock that influences how we perceive time

Senator to FTC: You guys really should look at Google one more time

Science Shows Green Lasers Might Be More Than You Bargained For

This may come as a shock, but some of those hot screaming deals on China-sourced gadgets and goodies are not all they appear. After you plunk down your pittance and wait a few weeks for the package to arrive, you just might find that you didn’t get exactly what you thought you ordered. Or worse, you may get a product with unwanted bugs features, like some green lasers that also emit strongly in the infrared wavelengths.

Sure, getting a free death ray in addition to your green laser sounds like a bargain, but as [Brainiac75] points out, it actually represents a dangerous situation. He knows whereof he speaks, having done a thorough exploration of a wide range of cheap (and not so cheap) lasers in the video below. He explains that the paradox of an ostensibly monochromatic source emitting two distinct wavelengths comes from the IR laser at the heart of the diode-pumped solid state (DPSS) laser inside the pointer. The process is only about 48% efficient, meaning that IR leaks out along with the green light. The better quality DPSS laser pointers include a quality IR filter to remove it; cheaper ones often fail to include this essential safety feature. What wavelengths you’re working with are critical to protecting your eyes; indeed, the first viewer comment in the video is from someone who seared his retina with a cheap green laser while wearing goggles only meant to block the higher frequency light.

It’s a sobering lesson, but an apt one given the ubiquity of green lasers these days. Be safe out there; educate yourself on how lasers work and take a look at our guide to laser safety.

Laser Arm Cannon Scares More than Metroids

There’s an interesting side effect of creating a popular piece of science fiction: if you wait long enough, say 30 or 40 years, there’s a good chance that somebody will manage to knock that pesky “fiction” bit off the end. That’s how we got flip phones that looked like the communicators from Star Trek, and rockets that come in for a landing on a tail of flame. Admittedly it’s a trick that doesn’t always work, but we’re not in the business of betting against sufficiently obsessed nerds either.

Coming in right on schedule 32 years after the release of Metroid on the Nintendo Entertainment System, we now have a functional laser arm cannon as used by the game’s protagonist Samus Aran, courtesy of [Hyper_Ion]. It’s not quite as capable as its video game counterpart, but if your particular corner of the solar system is under assault from black balloons you should be in good shape. Incidentally no word yet on a DIY Power Suit that folds the wearer up into a tiny ball, but no rush on that one.

Modeled after the version of the weapon Samus carried in 2002’s iconic Metroid Prime, [Hyper_Ion] 3D printed the cannon in a number of pieces that screw together in order to achieve the impressive final dimensions. He printed it at 0.3 mm layers to speed up the process, but as you can probably imagine, printing life-size designs like this is not for the faint of heart or short of time. While the use of printed threads does make the design a bit more complex, the fact that the cannon isn’t glued together and can be broken down for maintenance or storage is a huge advantage.

Ever popular NeoPixel strips give the cannon a bit of flash, and a speaker driven by a 2N2222 transistor on an Arduino Nano’s digital pin allows for some rudimentary sound effects with nothing more than a PWM signal. In the video after the break you can see how the lights and sounds serve as a warning system for the laser itself, as the cannon can be seen “charging up” for a few seconds before emitting a beam.

Of course, this is the part of the project that might have some readers recoiling in horror. To provide some real-world punch, [Hyper_Ion] has equipped his arm cannon with a 2.5W 450nm laser module intended for desktop engraving machines. To say this thing is dangerous is probably an understatement, so we wouldn’t blame you if you decided to leave the laser module off your own version. But it certainly looks cool, and as long as you’ve got some proper eye protection there’s (probably) more dangerous things you can do in the privacy of your own home.

Shame this kind of technology wasn’t really practical back when [Ryan Fitzpatrick] made this fantastic Power Suit helmet for a Metroid fan production.

The Boldport Cordwood And Cuttlefish, Together As A Guitar Tuner

As regular readers will know, here at Hackaday we are great enthusiasts for the PCB as an art form. On a special level of their own in that arena are the Boldport kits from [Saar Drimer], superlative objets d’art that are beautifully presented and a joy to build.

The trouble some people find with some of their Boldport kits though is that they are just too good. What can you do with them, when getting too busy with hacking them would despoil their beauty? [Paul Gallagher] has the answer in one case, he’s used not one kit but two of them as for a guitar tuner project.

At its heart is a Boldport Cuttlefish ATmega328 development board, and for its display it uses a Cordwood Puzzle as an LED array. All the details are available on a GitHub page, and it’s a modified version of an Arduino guitar tuner he found on Instructables. In particular he’s using a different pre-amp for an electret microphone, and a low-pass filter with a 723Hz cut-off to reduce harmonic content that was confusing the Arduino’s algorithm.

The result is a simple-to-use device with an LED for each string of his guitar, which you can see in the very short YouTube clip below. It joins many other tuners we’ve featured over the years, of which just one is this ATmega168-powered project with MIDI-out.

BladeRF 2.0 Micro is Smaller, More Powerful

When it was launched in 2013, the BladeRF was one of the most powerful of the new generation of Software Defined Radios. Now, Nuand, the producers of the BladeRF are looking to up the ante again with the BladeRF 2.0 Micro. This new version has a huge list of changes and improvements, including a more bad-ass FPGA processor and support for receiving and transmitting from 47 MHz all the way up to 6 GHz, with 2x MIMO support and an impressive 56 Mhz of bandwidth. It also retains backwards compatibility with the original BladeRF, meaning that any software written to support it (which most SDR packages do) will just work with the new device.

At the heart of the BladeRF 2.0 Micro is an Altera Cyclone V FPGA. Nuand are producing two versions of the Micro: the $480 xA4 uses the 49KLE Cyclone V FPGA, while the $720 XA9 is built around the 301KLE Cyclone V FPGA. The extra power of the xA9 lies in the larger amount of logic gates and elements on the FPGA, which means that the card can do more signal processing itself. That should make it easier to create stand-alone devices that process a signal and output the results. Nuand demonstrated this on the BladeRF by creating an ADS-B receiver that ran on the card itself, outputting the decoded airplane data to the USB port. The xA9 could do significantly more than this, and the possibilities are intriguing.

The new card is also, as the name suggests, smaller, measuring 2.5 by 4 inches, which would make it easier to integrate with devices like the Raspberry Pi, although it is still a little larger than the Pi.

The SDR marketplaces has changed a lot since 2013, with a profusion of cheap, open-source SDR receivers and transceivers like the LimeSDR and SDRPlay. These devices are cheaper than the BladeRF, and offer most of the same features. So, is there still a place in the market for a more powerful, more expensive device like the BladeRF 2.0 Micro? That, as they say, is up in the air.

Thursday, August 30

Researchers show Alexa “skill squatting” could hijack voice commands

Alex Arrives at the Ultimate Pasta Machine

Alex of French Guy Cooking finally completes his ultimate pasta and ramen noodle machine.

Read more on MAKE

The post Alex Arrives at the Ultimate Pasta Machine appeared first on Make: DIY Projects and Ideas for Makers.

Metroid, Zelda, and Castelvania Auto-Mapped with NES Emulation & Heuristics

The NES was one of the flagship consoles of the glorious era that was the 1980s. Many of the most popular games on the platform involved some sort of adventure through scrolling screens — Metroid, Super Mario, and Zelda all used this common technique. For many games, keeping track of the map was a huge chore and meant mapping by hand on graph paper or using the screenshots published in Nintendo Power magazine. These day’s there’s a better way. [Daniel] set out to automatically map these huge two-dimensional worlds, developing software he calls WideNES to do it.

WideNES is an add-on to [Daniel]’s own NES emulator, ANESE. As part of the emulator, WideNES can easily read the various registers of the NES’s Picture Processing Unit, or PPU. The registers of the PPU are used to control the display of the background and sprite layers of NES graphics, and by monitoring these, it is possible to detect and map out the display of levels in various NES games.

It’s an interesting piece of software that relies on a thorough understanding of the NES display hardware, as well as the implementation of some neat tricks to deal with edge cases such as vertical scrolling in The Legend of Zelda or room changes in games like Castlevania — the use of perceptual hashing is particularly genius. There’s source and more available on the project page, including a GitHub link, if you’re interested in getting down to brass tacks.

We’re impressed by the manner in which WideNES is able to so neatly map out these games of yesteryear, and can’t wait to see where the project goes next. [Daniel] notes that it should be possible to integrate into more popular emulators without too much trouble. If that’s not enough, check out this reverse-emulation Nintendo hack.

[Thanks to Michael for the tip!]

Apple to debut new iPhones during September 12 event

Dealmaster: Get a Dell desktop with a Core i7 and 16GB of RAM for $700

Greetings, Arsians! Courtesy of our friends at TechBargains, we have another round of deals to share. Today's list is headlined by a deal on Dell's XPS Tower desktop, a configuration of which with a six-core Intel Core i7-8700 chip and 16GB of RAM is going for $700 as of this writing.

You do have to deal with a 1TB HDD here instead of a faster SSD, but the machine is easy to upgrade, and you get a full array of ports, including two USB-C ports. While Intel's 9th-generation chips aren't too far from an unveiling, this is still a good price for a solid amount of horsepower, particularly if you're planning to grab a new Nvidia GPU in the near future. Just note that the deal appears to be in limited stock, so you may need to move quickly.

If you don't need a new desktop, we also have deals on the Apple Watch Series 3, Bose noise-cancelling headphones, portable batteries, and more. Have a look for yourself below.

Read 7 remaining paragraphs | Comments

Lenovo ditches halo keyboard for e-ink slab in new $999 Yoga Book

Valentina Palladino

Lenovo didn't forget about its quirky, keyboard-less Yoga Book. The netbook-like device that came out in 2016 was an acquired taste, to say the least, but it was also a chance for Lenovo to experiment with the traditional two-in-one form. The company returns in 2018 with a new version still named the Yoga Book (officially it's the Yoga Book C930), but it now has an e-ink panel attached to the main touchscreen slab and powerful internals that kicked its price up by quite a bit.

Lenovo abandoned the "halo" keyboard found on the last Yoga Book and replaced it with an e-ink slab that transforms from keyboard to sketch pad to e-reader. The e-ink keyboard fills the entire screen when activated, and a small, square area at the bottom, directly underneath the space bar, brings up an e-ink trackpad when tapped. Considering the overall size of the device, the trackpad is still small like it was on the old Yoga Book. However, its collapsible nature gives the rest of the keyboard more room to breathe when you're not using it. Also, you have two input options since you can use the trackpad or the Yoga Book's touchscreen.

Read 6 remaining paragraphs | Comments

Lenovo’s ThinkPad X1 Extreme: Hex-core, GTX 1050 Ti, 64GB RAM under 4 pounds

Lenovo

The ThinkPad X1 series has firmly established itself as one of the best thin-and-light laptops around. But what if you need a bit more oomph packed into its 13-inch frame? Enter the ThinkPad X1 Extreme.

This is a 15-inch X1. It's still thin and light—the weight starts at under 4lbs (1.7kg), and it's 0.7 inches (18mm) thick—but Lenovo is making good use of the extra space afforded by the 15-inch screen. The processor is bumped up to a hex-core 8th-generation Coffee Lake, paired with up to 64GB RAM. For graphics, there's an Nvidia GeForce GTX 1050 Ti. This can drive up to a 2840×2160 HDR display with support for Dolby Vision and Dolby Atmos, and it's capable of showing 100 percent of the Adobe RGB color space. The screen also supports touch and a tilt-sensitive pen. And it comes with all the bells and whistles we'd expect from a premium Lenovo machine: two Thunderbolt 3 ports, HDMI, gigabit Ethernet, 802.11ac, Bluetooth 5, two USB 3.1 generation 1 ports, an SD card reader, fingerprint authentication, a shutter for the webcam. The battery is 80WHr, with a 135W charger.

Read 2 remaining paragraphs | Comments

Lenovo’s new Yoga C930 hides a sound bar in its hinge, a stylus in its corner

Valentina Palladino

The Yoga family is one of Lenovo's most well-known PC lines, but the company doesn't want consumers to see it and only think "two-in-ones." Lenovo is transitioning the Yoga line to encompass all things premium, not just those with a hinge that flexes 360 degrees. To usher in the new Yoga era, Lenovo came out with the Yoga C930, a two-in-one with a new hinge style and a hidden stylus enclosure, and the new Yoga S730, a thin-and-light clamshell PC that may tempt some MacBook lovers.

The Yoga C930 embodies "premium" in nearly every way. The all-metal Ultrabook looks much like past Yoga devices but with one immediately noticeable difference: Lenovo didn't carry over its signature watchband hinge to this new convertible. Instead, it created a new hinge that holds the device's Dolby Atmos-ready speakers.

Read 6 remaining paragraphs | Comments

Lenovo pushes Chromebooks upmarket with the Yoga Chromebook

Lenovo

Lenovo has three new Chromebooks coming in October. Two of these are very traditional Chromebooks: the $280 C330 and $250 S330 are designed for affordability in highly price-sensitive markets such as education. But the third, the $600 Yoga Chromebook, is a bit different: it's a Chromebook aimed at a more discerning, upmarket buyer.

The C330 and S330 are more similar than they are different. On the inside, they have a quad-core MediaTek ARM processor, 4GB RAM, and 32 or 64GB of eMMC storage. They have the same connectivity options (802.11ac with a 2×2 antenna, Bluetooth 4.1) and the same ports—one USB 3.1 generation 1, HDMI, SD Card, a headset jack, a 720p webcam, and one USB Type-C, which supports charging and video output, as well as USB).

Read 4 remaining paragraphs | Comments

Turning A Fitness Tracker Into An EEG

T-Mobile/Sprint merger will bring higher prices, small carriers tell FCC

GSM Phone Network At EMF Camp Built on Raspberry Pi and LimeSDR

This is your brain on air pollution

Data vandal changes name of New York City to “Jewtropolis” across multiple apps

LEGO built a life-size, drivable Bugatti Chiron out of Technic pieces

Lego

As a gigantic LEGO nerd and a gigantic car nerd, the last few years have been pretty great. LEGO's Speed Champions range has brought us brick versions of Le Mans prototypes like the Porsche 919 Hybrid and Audi R18 e-tron quattro, and classics like the Ferrari 250GTO and Ford GT40. (In fact, all of the above might be within arm's reach on my increasingly messy desk). For those willing to spend a little more, the LEGO Technic line has bigger replicas you can build, like the yet-to-be-completed LMP2 car still in its box here in my office. (I may have a LEGO problem.) But none of them compare to LEGO's latest creation: a full-size, drivable Bugatti Chiron.

Earlier this year, LEGO Technic released a $349, 3,599-piece scale model of the Chiron, but this latest creation is way more impressive. Made from more than a million pieces, it's the first fully functional, self-propelled life-size LEGO Technic car ever built. In fact, LEGO says it's the first non-glued LEGO Technic model of such complexity ever made.

Read 5 remaining paragraphs | Comments

Competitive Soldering is Now a Thing

400mph, 50 feet up—what it takes to race and win world’s fastest motorsport

PHOTO 01 Aviation Photography

In the summer of 2013, Andy Findlay found himself glancing down from the cockpit of his Lancair Super Legacy sport plane as he passed the start/finish pylon on the race course at Stead Airport, home of the Reno National Championship Air Races. Findlay was flying the famed Reno course for the first time."It was one of those moments in life where you knew that was exactly where you were supposed to be," Findlay says.

The Reno Air Races are the only bastion of competitive airplane racing in the world. For 54 years, pilots have raced airplanes there around an oval track in the sky, 50 to 100 feet (15-30m) above the desert at up to 500mph (800km/h). There is no faster head-to-head motorsport.

Read 14 remaining paragraphs | Comments

The Challenges of Shipping From China – Life of a Flailing Tube Man

Let Your Props Shine With Our Cosplay Contest At World Maker Faire New York

Get a fresh blade on your X-acto, a new roll of 3d printer filament, and your best inspiration handy because we’re throwing another cosplay contest! We experimented with having a prop contest at Maker Faire Bay Area back in May and it went fantastic. We’ve learned a few things and […]

Read more on MAKE

The post Let Your Props Shine With Our Cosplay Contest At World Maker Faire New York appeared first on Make: DIY Projects and Ideas for Makers.

This Week’s Recode Decode Podcast: Kara Swisher Talks Making with Dale Dougherty and Mike Senese

A couple weeks ago Dale and I visited the Vox studios in San Francisco to be part of Kara Swisher‘s great podcast, Recode Decode. In it we run through the history of the maker movement, but more importantly, talk about the opportunities it has since opened up and how it […]

Read more on MAKE

The post This Week’s Recode Decode Podcast: Kara Swisher Talks Making with Dale Dougherty and Mike Senese appeared first on Make: DIY Projects and Ideas for Makers.

Blackmagic external GPU review: A very Apple graphics solution

Samuel Axon

Is the eGPU the future of Mac graphics? Apple wants you to think so, and, for the first time, it has worked with an outside firm (Blackmagic Design) to produce a sanctioned eGPU solution for the Mac. Simply titled the Blackmagic Design eGPU, it's available for $699 exclusively through the Apple Store.

It includes a Radeon Pro 580 GPU with 8GB of GDDR5 memory, two Thunderbolt 3 ports, four USB-3 ports, and one HDMI 2.0 port—and it's only compatible with Macs with Thunderbolt 3 ports. When Apple first mentioned this product, it claimed that it's easier to set up, quieter, and smaller than most existing external GPU enclosures.

Read 30 remaining paragraphs | Comments

WideNES emulation expands NES scenes past the usual SD screen borders

Here at Ars, we're big fans of emulators that go past perfectly recreating the original hardware and move on to enhancing the game-playing experience. Whether that means converting 2D NES sprites to 3D polygons or removing latency frames after controller presses, we're there.

So we were more than happy to recently stumble upon WideNES, a new emulation project that extends the visible area of an NES game map past the usual 4:3, 256x240 resolution screen area we're used to. Using WideNES, you can even zoom out and pan through previous screens using the keyboard and mouse wheel while still playing the game.

The generalized methods used by WideNES are described in a fascinating blog post by University of Waterloo student Daniel Prilik, who created the algorithm. Basically, the WideNES system watches the background "map" data constantly scrolling through the emulated NES PPU as you play. It also closely monitors the PPUSCROLL register, which controls the actual screen scrolling by pointing to different parts of VRAM as the player moves.

Read 4 remaining paragraphs | Comments

Garmin’s Vivosmart 4 combines pulse-ox and a week of battery life for $129

Real or Fake? Robot Uses AI to Find Waldo

The last few weeks have seen a number of tech sites reporting on a robot which can find and point out Waldo in those “Where’s Waldo” books. Designed and built by Redpepper, and add agency. The robot arm is a UARM Metal, with a Raspberry Pi controlling the show.

A Logitech c525 webcam captures images, which are processed by the Pi with OpenCV, then sent to Google’s cloud-based AutoML Vision service. AutoML is trained with numerous images of Waldo, which are used to attempt a pattern match.  If a pattern is found, the coordinates are fed to PYUARM, and the UARM will literally point Waldo out.

While this is a totally plausible project, we have to admit a few things caught our jaundiced eye. The Logitech c525 has a field of view (FOV) of 69°. While we don’t have dimensions of the UARM Metal, it looks like the camera is less than a foot in the air. Amazon states that “Where’s Waldo Delux Edition” is 10″ x 0.2″ x 12.5″ inches. That means the open book will be 10″ x 25″. The robot is going to have a hard time imaging a surface that large in a single image. What’s more, the c525 is a 720p camera, so there isn’t a whole lot of pixel density to pattern match. Finally, there’s the rubber hand the robot uses to point out Waldo. Wouldn’t that hand block at least some of the camera’s view to the left?

We’re not going to jump out and call this one fake just yet — it is entirely possible that the robot took a mosaic of images and used that to pattern match. Redpepper may have used a bit of movie magic to make the process more interesting. What do you think? Let us know down in the comments!

The Electric Vehicles Of Electromagnetic Field: The Ottermobile And The Ottercar

If you’ve followed these pages over the last few weeks, you’ll have seen an occasional series of posts featuring the comedic electric vehicle creations of the British Hacky Racers series, which will make their debut at the forthcoming Electromagnetic Field hacker camp. So far these intrepid electro-racers have come largely from the UK hackerspace and Robot Wars communities, but it was inevitable that before too long there would arrive some competition from further afield.

[Jan Henrik] and [Niklas Fauth] are a pair of prolific German hardware hackers whose work you may have seen from time to time in other fields. When they heard about Hacky Racers with barely two weeks until they were due to set off for England for EMF, they knew they had to move fast. The Ottermobile and the Ottercar are the fruits of their labours, and for vehicles knocked together in only two or three days they show an impressive degree of sophistication.

In both cases the power comes courtesy of hoverboard wheels with integrated motors. If you cast your mind back to last year’s SHA Camp in the Netherlands, our coverage had a picture of them on a motorised armchair, so this is a drive system with which they have extensive experience. The Ottercar is based upon a lengthened Kettler kids’ tricycle with the larger variant of the hoverboard motors, and unusually it sports three-wheel drive. Control for the rear pair comes from a hoverboard controller with custom firmware, while the front is supplied by a custom board. The Ottermobile meanwhile is a converted Bobby Car, with hoverboard drive. It’s an existing build that has been brought up to the Hacky Racer rules, and looks as though it could be one of the smaller Hacky Racers.

At the time of writing there is still just about enough time to create a Hacky Racer for Electromagnetic Field. Following the example set from Germany, it’s possible that the hoverboard route could be one of the simplest ways to do it.

$99 Pinebook Gets KDE Neon Port

If you’re the kind of person who likes small and cheap Linux devices, you’re definitely alive in the perfect moment in history. It seems as if every few months we’ve got another tiny Linux board competing for our pocket change, all desperate to try to dethrone the Raspberry Pi which has already set the price bar exceptionally high (or low, as the case may be). We’ve even started to see these Linux boards work their way into appropriately cheap laptops, though so far none have really made that great of an impression.

But thanks to the efforts of Blue Systems and Pine64, the situation might be improving: they’ve worked together on a build of KDE Neon for the $99 Pinebook. The fact that they’ve gotten Plasma, KDE’s modern desktop environment, running on the rather mediocre hardware at all is an accomplishment by itself. But they’ve also set out tailor the entire system for the Pinebook, from the kernel and graphics drivers all the way up to Qt and Plasma tweaks.

In a blog post announcing the release candidate of the OS, Neon developer [Jonathan Riddell] says that these top-to-bottom improvements show that you can turn a super cheap Linux laptop into a practical computer if you’re willing to really get in there and optimize it. He also says the project has been something of a two-way street, in that improvements made for the Pinebook build have also been applied to upstream development.

The last time we looked at the Pinebook, we came away cautiously optimistic. It wasn’t great, but it was about as good as you could possibly expect given the price. If more developers are willing to go out on a limb and start optimizing their software for the device, it might become a very promising platform for low-cost mobile hacking.

Governor’s desk last stop to California pledging 100% carbon-free energy by 2045

Linux Fu: Modernize Your Command Line

If you use Linux and its associated tools on the desktop or on a Raspberry Pi, or on a server, you probably have used the command line. Some people love it and some people hate it. However, many of us have been using Linux for years and sometimes Unix before that, and we tend to use the same old tried-and-true tools. [Remy Sharp] had a recent post talking about how he had created aliases to replace those old tools with great modern replacements and it is definitely worth a read.

We’ll be honest, when we first saw the post we almost skipped reading it. A lot of Linux tip posts are pretty uninteresting unless you are a total beginner. But [Remy] has a lot of really great tools and how he has them installed including bat, which is like cat but with syntax coloring (see picture above), and fzf — a command line history search on steroids. He even shows how to join fzf and bat to make a very cool file browser from the command line (see below).

That’s not all of the replacements, either. He had htop of course, which we’ve used for a long time. There are some nicer replacements for htop, like glance. There was also prettyping (that is pretty ping, not pret typing) which is a nice alternative to ping. We were less convinced of the need to replace find and grep because we are pretty happy with them and we have our own favorite replacement for diff which does launch a GUI, so we didn’t try those.

You might not like all the choices on the list — we didn’t. But that’s the nice thing about Linux. You can use what you want, more or less. Which is another of our favorite aliases, replacing more with less. We also like cdfunc and fasd and we manage all that madness using a system for putting .bash.rc under git control. That also keeps it synchronized between machines.

If you like tools to help run your system, we talked about a few before. If you don’t care for [Remy’s] choice of tldr instead of man, you might like our take on help for Bash. Of course, if you don’t mind abandoning bash, we know lots of people like Fish and zsh which have a lot of additional features, too.