Syndicate content
Fresh hacks every day
ถูกปรับปรุง 1 ชั่วโมง 9 min ก่อน

Tightly Packed Raspberry Pi Tricorder Impresses

2 hours 26 minก่อน

We’ll say upfront that we don’t have nearly as much information about this 3D printed Star Trek: The Next Generation tricorder as we’d like. But from the image galleries [Himmelen] has posted we know it’s running on the Raspberry Pi Zero W, has a color LCD in addition to a monochrome OLED, and that it’s absolutely packed with gear.

So far, [Himmelen] has fit an NESDR RTL-SDR dongle, a GPS receiver, an accelerometer, and the battery charging circuitry in the top half of the case. Calling it a tight fit would be something of an understatement, especially when you take into account all the wires snaking around in there. But as mentioned in the Reddit thread about the device, a custom PCB backplane of sorts is in the works so all these modules will have something a little neater to plug into.

There are a lot of fantastic little details in this build that have us very excited to see it cross the finish line. The female USB port that’s been embedded into the top of the device is a nice touch, as it will make it easy to add storage or additional hardware in the field. We also love the keyboard, made up of 30 individual tact switches with 3D printed caps. It’s hard to imagine what actually typing on such an input device would be like, but even if each button just fired off its own program or function, we’d be happy.

Judging by the fact that the LCD shows the Pi sitting at a login prompt in all the images, we’re going to go out on a limb and assume [Himmelen] hasn’t gotten to writing much software for this little gadget yet. Once the hardware is done and it’s time to start pushing pixels though, something like Pygame could be used to make short work of a LCARS-style user interface that would fit the visual style of The Next Generation. In fact, off the top of our heads we can think of a few turn-key projects out there designed for creating Trek UIs, though the relatively limited computational power of the Pi Zero might be a problem.

We’ve seen several projects that tried to turn the iconic tricorder into a functional device. Some have focused on the arguably more recognizable Next Generation style such as this one, and others have targeted the more forgiving brick-shaped unit from Kirk and Spock’s era. The Wand Company is even working on a officially licensed tricorder that will supposedly be as close to we can get to the real thing with modern tech and a $250 USD price tag, though we’d wager COVID has slowed progress down on that one. In any event, whether you build it or buy it, the tricorder seems destined to become reality before too long.

3D Animation for All Thanks to Google AI

5 hours 25 minก่อน

Google rarely fails to impress with technology demos. Their latest — Monster Mash — is aimed at using artificial intelligence to allow the creation of simple 3D animations without a lot of training or trouble. We’ll warn you: we aren’t artists so we didn’t get the results the demos were showing, but then again, if you are even a little artistic, you’ll probably have better luck than we did. You might want to start watching the video, below.

There’s also a research paper if you are more interested in the technology. The idea is to make simple line drawings in 2D. Then you inflate the object to 3D. The final step is to trace out animation paths.

It sounds simple, but there are a few things you need to know. The object’s main body needs to be a closed stroke. After that, you can draw open shapes to cue the system that they are body parts. Drawing with a right click puts objects behind existing objects and double-clicking a shape creates a symmetric copy (for example, a right and left leg).The inflation step has some high-power math behind it, while the final step is to create control points on the model and deform them to produce the appearance of movement.

The project had contributors from the Czech Technical University, ETH Zürich, and the University of Washington. The code is open source, too.

Programming PALs in 2021

8 hours 26 minก่อน

The [IMSAI Guy] has posted a follow-up video with all the details of how he programs GAL22V10 chips in the modern era. We noted that this was missing from his stepper motor project a few days ago, and before we could even ask him, he answered. And no, you won’t have to dig that old Intel 486 DX2-66 out of the closet and search eBay for working floppy drives. It turns out the answer is easier than you’d think.

Microchip now owns WinCUPL through its acquisition of Atmel in 2016, and offers WinCUPL as a free download from the Microchip website. This runs only in Windows, although some users report success running under Wine on Linux. This tool will compile the design, but you still need to program the chip. If you’ve done any EEPROM programming lately, chances are you have one of the TL866A MiniPros laying around — this programmer can handle CPLDs, PALs, and GALS as well as EEPROMS. [IMSAI Guy] walks you through the programming procedure, and if you’ve programmed EEPROMs before, the process will be familiar.

For those who prefer the Linux or Mac environment, there are some alternatives. We’ve seen GALasm used on several projects such as [Ken Yap]’s 8085 Minimax. The GitHub repository for GALasm states that commercial use is strictly prohibited, so take note if this applies to your project. As for controlling the TL866A, there is a Linux port called minipro available on GitLab. The remaining hurdle if you want to experiment with these programmable logic chips it to actually get them — many are now obsolete. But it looks like you can still buy Lattice and Microchip (Atmel) ones from various sources. Happy Programming.

Virtual Reality Gloves Aim To Improve Interactivity

11 hours 26 minก่อน

Virtual reality is a slow-moving field in some respects. While a lot of focus is put on optical technologies and headsets, there’s a lot more involved when it comes to believably placing a human being in a virtual environment. So far, we’ve gotten a good start at the visuals and head tracking, but interaction technology is still lagging behind a lot. [Lucas] is working in just that area, iterating heavily on his homebrew VR gloves.

The gloves consists of potentiometers, fitted with spools and attached to the tip of each digit on a wearer’s hand by a string. As the user curls their fingers, the potentiometers turn and the position of the fingers can be measured. The potentiometers are all read via an Arduino, which communicates back to a PC via USB. A custom driver is then used to interact with Valve’s SteamVR software, allowing the glove to be used with a wide variety of existing software.

Thus far, the system is merely tracking finger position, but the spool and string based design is intended to support motors down the line for each finger to create resistance, so the user can gain the feeling of touching and interacting with virtual objects.  The project has the potential to be a cheaper, more accessible alternative than current off-the-shelf solutions. We’ve seen other hand-tracking gloves before, too – though none that track the spread of a wearer’s hand as well as the finger extension. If you’re working on precisely that, please do drop us a line. Video after the break.

Heavy Metal Cyberdeck Has an Eye Towards Expansion

12 hours 56 minก่อน

Whether we’re talking about Gibson’s Sprawl or our increasingly dystopian reality, one of the defining characteristics of a cyberdeck is that it can be easily customized and upgraded over time. While a few of the builds we’ve covered over the last couple of years have focused more on style than substance, we really appreciate the designs that embrace the concept of modularity to make sure the system can evolve to meet the changing demands of hacking on the go.

To that end, the M3TAL from [BlastoSupreme] is a perfect example of what a cyberdeck should be. Naturally it’s got the cyberpunk aesthetics we’ve come to expect, but more importantly, it’s designed so modifications and repairs are as quick and painless as possible. The trick is the use of a 2020 aluminum extrusion frame, which allows external panels and components to be attached anywhere along the length of the deck using T-Nuts. Similarly, by mounting internal components to “sleds” that ride between the pieces of extrusion, the electronics can easily be removed or swapped out as complete modules.

The M3TAL is currently outfitted with a Raspberry Pi 4 and a pair of 26650 batteries.

Furthering the idea of expandability, [BlastoSupreme] included an authentic 3.5 floppy drive on the M3TAL that allows him to pack an incredible 1.44 MB onto each rugged and portable disk. OK, so maybe the floppy drive isn’t terribly impressive compared to 2021 tech, but it does seem oddly appropriate for a cyberdeck. On the opposite side of the deck there’s a RetroCART slot, which cloaks modern USB devices in clunky faux cartridges. This provides a unified physical format for everything from removable storage to microcontrollers and software defined radio receivers.

[BlastoSupreme] also put quite a bit of time and effort into the input devices on the M3TAL. There’s a mechanical keyboard onboard, as is something of a tradition for cyberdecks, but this one is notable for the meticulous hand-wiring and Teensy 2.0 microcontroller hiding underneath. Next to that is a small joystick intended for the Nintendo Switch which has been converted to USB by way of an Arduino Pro Micro.

Looking at the M3TAL, it probably won’t surprise you to hear that this isn’t the first custom cyberdeck [BlastoSupreme] has built. Last year we covered his gargantuan NX-Yamato, and it’s interesting to see the evolution of his technique. Clearly this isn’t a maker who’s content to rest on his laurels, so we’re eager to see what he’s got in store for his next project.

The $50 Ham: A Simple WSPR Beacon

14 hours 26 minก่อน

I was having a chat recently with someone, and it surprised me that she had an amateur radio license. I suppose it shouldn’t have come as much of a surprise; after all, getting a ham radio license is a pretty common rite of passage in the life of a hardware hacker. I guess it surprised me because she’d never mentioned it in our past conversations, and as we talked about it, I learned why. “I got my license because I thought ham radio was about building radios, ” she said. “But it’s not.”

In a lot of ways, she is right about the state of ham radio. There was a time that building one’s own gear was as central to the hobby as getting on the air, and perhaps more so. Now, though, with radios as cheap as $30 and the whiz-bang gear that can make reaching out across the planet trivially easy, building your own radios has slipped down a few notches. But homebrewing is far from a dead art, and as we’ll see in this installment of “The $50 Ham”, a WSPR beacon for the HF bands is actually a fun and simple — and cheap — way for the homebrew-curious to get a taste of what it’s like to build your own transmitter.

A Minimalist Approach

In the last $50 Ham installment, I talked about how the Weak Signal Propagation Mode, or WSPR, is used to explore propagation conditions across the world. The concept is simple: a transceiver connected to a WSPR client program, such as the one built into WSJT-X, listens for the FSK-modulated signals that are being transmitted by other stations. The low-bit-rate signals encode a minimal message — the transmitting station’s callsign, Maidenhead grid location, and the transmit power — into a digital signal that takes nearly two full minutes to send. The receiving station then reports the decoded message to a central WSPR database, which keeps track of the contacts and can display a map of paths between stations.

On the receiving end, most of the magic of WSPR lies in the software, particularly in the digital signal processing that pulls data from the oftentimes weak and degraded signal. But the transmitting side is another story; there, the software needed to encode the minimal message is pretty simple, so simple that not much more than a microcontroller is needed to do the job. Really, all that’s needed is an oscillator capable of generating a signal at a fixed frequency, and varying that frequency under software control to encode the message.

There are a lot of ways to go about this, including using the GPIO pins on a Raspberry Pi to generate the RF signal directly. In this case, though, I decided to follow the lead of a lot of other hams and use an Si5351 clock generator breakout board and an Arduino Nano. The clock generator board sports a three-channel PLL-controlled oscillator that talks I2C and has a well-supported library, making it easy to implement a simple oscillator for just about any band.

I decided to make my WSPR beacon for the 20-meter band, for no real reason other than I’ve always had good luck making WSPR contacts on that band during the daylight hours, which is when I spend the most time in my shack. I also decided that for at least my first pass at this project, I’d strip out all the bells and whistles that are so easy to add to an Arduino project. WSPR transmissions need to be carefully synchronized to start at the top of every even-numbered minute, so many of these projects include elaborations such as a GPS receiver or an NTP client to take care of timing. I figured it would be a lot quicker and easier for me to simply watch the clock and press a button to start the WSPR transmission cycle at the proper time.

To that end, I searched for “minimal WSPR transmitters” and found a number of designs that would work for me, including this one by Peter B. Marks. He adapted the code from Jason Milldrum’s (NT7S) examples in his excellent Etherkit library for the Si5351 — we all borrow from each other. My only addition to the code is support for a button to kick off the transmitter. The code simply takes my callsign, grid square, and transmit power, encodes it into a WSPR message, and tells the Si5351 to send the sequence of four different FSK tones that make up the 162-symbol-long message.

/* * Minimal WSPR beacon using Si5351Arduino library * * Based on code: * Copyright (C) 2015 - 2016 Jason Milldrum * * * This program is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation, either version 3 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program. If not, see * https://gist.github.com/NT7S/2b5555aa28622c1b3fcbc4d7c74ad926. */ #include "Arduino.h" #include "si5351.h" #include "Wire.h" #define TONE_SPACING 146 // ~1.46 Hz #define WSPR_CTC 10672 // CTC value for WSPR #define SYMBOL_COUNT WSPR_SYMBOL_COUNT #define CORRECTION 94674 // Determined experimentally -- parts per billion? #define INPUT_PIN 7 // pushbutton #define TX_LED_PIN 13 Si5351 si5351; JTEncode jtencode; unsigned long freq = 14097100UL; // Transmit frequency char call[7] = "N7DPM"; // Callsign char loc[5] = "DN17"; // Grid square uint8_t dbm = 10; // Transmit power uint8_t tx_buffer[SYMBOL_COUNT]; int val = 0; // Global variables used in ISRs volatile bool proceed = false; // Timer interrupt vector. This toggles the variable we use to gate // each column of output to ensure accurate timing. Called whenever // Timer1 hits the count set below in setup(). ISR(TIMER1_COMPA_vect) { proceed = true; // Serial.println("timer fired"); } // Loop through the string, transmitting one character at a time. void encode() { uint8_t i; Serial.println("encode()"); jtencode.wspr_encode(call, loc, dbm, tx_buffer); // Reset the tone to 0 and turn on the output si5351.set_clock_pwr(SI5351_CLK0, 1); digitalWrite(TX_LED_PIN, HIGH); // Now do the rest of the message for (i = 0; i < SYMBOL_COUNT; i++) { uint64_t frequency = (freq * 100) + (tx_buffer[i] * TONE_SPACING); si5351.set_freq(frequency, SI5351_CLK0); Serial.print("freq = "); Serial.println(tx_buffer[i]); proceed = false; while (!proceed); } Serial.println("message done"); // Turn off the output si5351.set_clock_pwr(SI5351_CLK0, 0); digitalWrite(TX_LED_PIN, LOW); } void setup() { Serial.begin(115200); Serial.println("setup"); // Use the Arduino's on-board LED as a keying indicator. pinMode(TX_LED_PIN, OUTPUT); digitalWrite(TX_LED_PIN, LOW); // Initialize the Si5351 // Change the 2nd parameter in init if using a ref osc other // than 25 MHz si5351.init(SI5351_CRYSTAL_LOAD_8PF, 0, CORRECTION); // Set CLK0 output si5351.set_freq(freq * 100, SI5351_CLK0); si5351.drive_strength(SI5351_CLK0, SI5351_DRIVE_8MA); // Set for max power si5351.set_clock_pwr(SI5351_CLK0, 0); // Disable the clock initially // Set up Timer1 for interrupts every symbol period. noInterrupts(); // Turn off interrupts. TCCR1A = 0; // Set entire TCCR1A register to 0; disconnects // interrupt output pins, sets normal waveform // mode. We're just using Timer1 as a counter. TCNT1 = 0; // Initialize counter value to 0. TCCR1B = (1 << CS12) | // Set CS12 and CS10 bit to set prescale (1 << CS10) | // to /1024 (1 << WGM12); // turn on CTC // which gives, 64 us ticks TIMSK1 = (1 << OCIE1A); // Enable timer compare interrupt. OCR1A = WSPR_CTC; // Set up interrupt trigger count; interrupts(); // Re-enable interrupts. pinMode(INPUT_PIN, INPUT); } // wait for button press at the top of any even-numbered minute void loop() { val = digitalRead(INPUT_PIN); if (val == LOW) { encode(); // transmit once and stop } } Cleaning Up the Signal

Like any good ham, I tested my tiny transmitter before putting it on the air. The simple dummy load I built back near the beginning of this series came in hand for that, since I was able to hook it up directly to the SMA connector on the breakout board. I connected my oscilloscope to the output and fired up the code. The Si5351 is supposed to generate a square wave; it ended up looking more like a sawtooth wave, but either way, the signal was loaded with harmonics and would need to be cleaned up before going on the air.

Cleaning up harmonics from the Si5351. Yellow trace is the raw ouput from the dev board; green trace is output from the low-pass filter.

Luckily, low-pass filters that take care of this important bit of spectral hygiene are pretty simple. You can buy them, but this is all about homebrewing, so I spun up a Charlie Morris (ZL2CTM) video on filter design, ran through his math, and came up with values for the capacitors and inductors needed for a filter that cuts off everything above about 14.2 MHz. I used this toroid calculator to figure out how to wind the coils, soldered everything up on a scrap of PCB that had pads cut into it using a cheap plug-cutter bit from Harbor Freight, and tested it using my NanoSA spectrum analyzer.

Having never built a filter like this before, I was surprised how well it did cleaning up the harmonics. The waveform on the scope was a nice, smooth sine wave, and the spectrum analyzer showed a marked decrease in harmonics. The second harmonic, which at 42 MHz is well up into the VHF band, was attenuated by 35 dBm. That’s exactly the kind of spurious a responsible ham wouldn’t want to be spewing around, so I’m glad I built the filter.

On the Air – Sort Of Doesn’t look like much of a transmitter, but I’m on the air.

Once I was confident that my little transmitter was putting out a clean signal, I checked to make sure it was putting out signal that was both on-frequency and properly encoded. The Si5351 dev board isn’t exactly a lab-quality signal source — while it holds the set frequency pretty well, it may or may not output the programmed frequency. So the board needs to be calibrated, which is normally a simple matter of tweaking a correction factor in code while monitoring the output on a frequency counter. Sadly, there’s no “NanoFrequencyCounter” in my tiny test suite — yet — so I had to get creative.

My approach was to tune my HF rig to the desired frequency of the WSPR transmitter — 14.097100 MHz — and slowly adjust the transmitter’s frequency while transmitting into a dummy load. This produces an audible beat frequency which pretty much disappears when the two frequencies match. I wasn’t able to completely eliminate the beat frequency, but I did get it down to a couple of Hertz, which I considered close enough.

I next checked for a decodable signal by firing up WSJT-X and “broadcasting” to my HF rig. Even with the dummy load connected, I was getting a very strong signal on the waterfall display, and could clearly see the FSK-modulated signal. And I was very pleased to see that WSJT-X cleanly decoded my message.

Decoding my own signal, to make sure everything is working. The range was only a few meters and the power was only 13 mW, but it worked! Better Luck Next Time

Encouraged by these successes, and knowing that plenty of people have made transcontinental WSPR contacts with less power than the 13 mW my little beacon was putting out, I tried getting on the air for real. I hooked the beacon up to my end-fed half-wave antenna and pushed the send button at the appointed time. Sadly, though, I was never able to get any other station to decode my signal. I’ve tried dozens, perhaps hundreds, of times in the last week or so, but I don’t appear to be getting through.

I know my signal is properly encoded, and I know I’m on frequency, so I’m pretty sure the problem is either my antenna or my low-power signal. Given the nature of this series, I’m more inclined to address the latter with a simple power amplifier build. I’ve got a couple of designs in mind for that and I’ve ordered some parts, so we’ll look at that in the next installment and see if I can unlock this particular achievement.

Portrait of a Digital Weapon

พฤ, 04/15/2021 - 22:30

Over the years, artists have been creating art depicting weapons of mass destruction, war and human conflict. But the weapons of war, and the theatres of operation are changing in the 21st century. The outcome of many future conflicts will surely depend on digital warriors, huddled over their computer screens, punching on their keyboards and maneuvering joysticks, or using devious methods to infect computers to disable or destroy infrastructure. How does an artist give physical form to an unseen, virtual digital weapon? That is the question which inspired [Mac Pierce] to create his latest Portrait of a Digital Weapon.

[Mac]’s art piece is a physical depiction of a virtual digital weapon, a nation-state cyber attack. When activated, this piece displays the full code of the Stuxnet virus, a worm that partially disabled Iran’s nuclear fuel production facility at Natanz around 2008.

It took a while for [Mac] to finalize the plan for his design. He obtained a high resolution satellite image of the Iranian Natanz facility via the Sentinel Hub satellite imagery service. This was printed on a transparent vinyl and glued to a translucent poly-carbonate sheet. Behind the poly-carbonate layer, he built a large, single digit 16-segment display using WS2812 addressable LED strips, which would be used to display the Stuxnet code. A bulkhead USB socket was added over the centrifuge facility, with a ring of WS2812 LEDs surrounding the main complex. When a USB stick is plugged in, the Stuxnet code is displayed on the 16-segment display, one character at a time. At random intervals, the LED ring around the centrifuge building lights up spinning in a red color to indicate centrifuge failure.

The 16-segment display was built on an aluminum base plate, with 3D printed baffles to hold the LED strips. To hold the rest of the electronics, he built a separate 3D printed frame which could be added to the main art frame. Since this was too large to be printed in one piece on the 3D printer, it was split in parts, which were then joined together using embedded metal stud reinforcement to hold the parts together. Quite a nice trick to make large, rigid parts.

An Adafruit Feather M0 micro-controller board, with micro SD-card slot was the brains of the project. To derive the 5 V logic data signal from the 3.3 V GPIO output of the Feather, [Mac] used two extra WS2812 LEDs as level shifters before sending the data to the LED strips. Driving all the LEDs required almost 20 W, so he powered it using USB-C, adding a power delivery negotiation board to derive the required juice.

The Arduino code is straightforward. It reads the characters stored on the SD-card, and sends them sequentially to the 16-segment display. The circular ring around the USB bulkhead also lights up white, but at random intervals it turns red to simulate the speeding up of the centrifuges. Detecting when the USB stick gets plugged in is another nice hack that [Mac] figured out. When a USB stick is plugged in, the continuity between the shell (shield) and the GND terminal was used to trigger a GPIO input.

Cyber warfare is here to stay. We are already seeing increasing attacks on key infrastructure installations by state as well as non-state actors around the world. Stuxnet was one of the first in this growing category of malicious, weaponized code. Acknowledging its presence using such a physical representation can offer a reminder on how a few lines of software can wreak havoc just as much as any other physical weapon. Check out the brief project video after the break.

Crew Dragon’s Short Hop Begins the Era of Valet Parking at the ISS

พฤ, 04/15/2021 - 21:01

They weren’t scheduled to return to Earth until April 28th at the earliest, so why did NASA astronauts Michael Hopkins, Victor Glover, and Shannon Walker, along with Japan Aerospace Exploration Agency (JAXA) astronaut Soichi Noguchi, suit up and climb aboard the Crew Dragon Resilience on April 5th? Because a previously untested maneuver meant that after they closed the hatch between their spacecraft and the International Space Station, there was a chance they weren’t going to be coming back.

On paper, moving a capsule between docking ports seems simple enough. All Resilience had to do was undock from the International Docking Adapter 2 (IDA-2) located on the front of the Harmony module, itself attached to the Pressurized Mating Adapter 2 (PMA-2) that was once the orbital parking spot for the Space Shuttle, and move over to the PMA-3/IDA-3 on top of Harmony. It was a short trip through open space, and when the crew exited their craft and reentered the Station at the end of it, they’d only be a few meters from where they started out approximately 45 minutes prior.

The maneuver was designed to be performed autonomously, so technically the crew didn’t need to be on Resilience when it switched docking ports. But allowing the astronauts to stay aboard the station while their only ride home undocked and flew away without them was a risk NASA wasn’t willing to take.

What if the vehicle had some issue that prevented it from returning to the ISS? A relocation of this type had never been attempted by an American spacecraft before, much less a commercial one like the Crew Dragon. So while the chances of such a mishap were slim, the crew still treated this short flight as if it could be their last day in space. Should the need arise, all of the necessary checks and preparations had been made so that the vehicle could safely bring its occupants back to Earth.

Thankfully, that wasn’t necessary. The autonomous relocation of Crew Dragon Resilience went off without a hitch, and SpaceX got to add yet another “first” to their ever growing list of accomplishments in space. But this first relocation of an American spacecraft at the ISS certainly won’t be the last, as the comings and goings of commercial spacecraft will only get more complex in the future.

Unprecedented Activity

During the Space Shuttle years NASA didn’t have to worry about relocating their spacecraft, as there was never more than one of the winged orbiters in space at the same time. But since the Shuttle was capable of simultaneously carrying seven crew members and an incredible amount of cargo, this wasn’t a problem. All of NASA’s operational needs on the ISS were more than met by a single vehicle.

Of course, all that changed when the Shuttle was retired in 2011. NASA began making deals with its international partners, and eventually even commercial companies, to bring crew and cargo to the Station on a wide array of smaller and more operationally nimble spacecraft. Today these vehicles, in addition to Russia’s Soyuz and Progress spacecraft, occupy most of the available docking and berthing ports on the ISS at any given time. In the coming years even more commercial spacecraft are expected to be brought online, meaning traffic is only going to get worse at the orbiting outpost.

All of the spacecraft docked to the ISS as of April 9th, 2021.

With the US segment of the ISS now busier than ever, NASA is faced with a logistical challenge that their Russian counterparts are already well accustomed to. This may have been the first time an American spacecraft had to be relocated to another docking port during a mission, but to date, 19 Soyuz capsules have had to make similar treks; the most recent of which having just occurred a few weeks prior on March 19th.

A Complicated Dance

Given that Resilience ended up moving to a docking port that’s only a few meters away from where it was originally, it’s easy to think the whole thing was some kind of experimental proof of concept. Perhaps as a test for future, more complex maneuvers. But in fact, the two International Docking Adapters are currently the only spots on the ISS where commercial vehicles such as the Crew Dragon, Boeing’s Starliner capsule, and eventually Sierra Nevada’s Dream Chaser spaceplane, can attach. In short, while the destination will alternate, port relocations for US spacecraft will always be a short hop.

But why? What difference could a trip of such a short distance make? The answer lies in the unique design of the Dragon’s Cargo variant, which is able to carry large bulky objects in the hollow “trunk” behind the pressurized capsule. Generally speaking cargo brought up in the rear of the Cargo Dragon is intended to be mounted to the outside of the Station, and is retrieved from the spacecraft using the orbiting laboratory’s robotic arm. As it so happens, this is how both IDA-2 and IDA-3 were delivered to the Station in 2016 and 2019.

The trick is, Station’s arm can’t reach into the trunk of the Dragon if it’s docked to Harmony’s forward port. That’s not a problem currently, as Resilience isn’t carrying any external cargo. But it will be in June, when a Cargo Dragon delivers a new set of deployable solar arrays for the Station as part of the CRS-22 mission . To further complicate matters, another four astronauts are slated to dock with the Station at the end of April aboard Crew Dragon Endeavour.

A rendering by Raffaele Di Palma illustrates the limited reach of the Station’s robotic arm.

That meant Resilience needed to move to PMA-3/IDA-3 so Endeavour can dock to PMA-2/IDA-2 at the end of the month. Then once Resilience leaves, the upper docking port will be free to accept CRS-22 in June so the solar arrays can be removed from its trunk with the robotic arm. After CRS-22 departs, Endeavour will need to make its own “up and over” hop to PMA-3/IDA-3, as a Boeing Starliner needs to dock at PMA-2/IDA-2 as part of its first test flight to the Station in July.

Sound complicated? That’s because it is. But unfortunately for NASA, unless plans for a commercial expansion to the International Space Station go through, this is the orbital game of “musical chairs” they’ll be forced to deal with. With only two viable docking ports available for current and future spacecraft, the United States should quickly catch up with their Russian counterparts when it comes to the fine art of spacecraft juggling. Except now those relocations will be autonomous.

3D Printing A Long Range Nerf Blaster

พฤ, 04/15/2021 - 18:00

The modified Nerf scene used to be about getting the absolute maximum performance out of Hasbro’s off-the-shelf foam dart blasters. The community quickly found the limits of plastic parts made down to a price, and an underground market for heavier springs and CNC-machined upgrades sprung up. Eventually, however, the advent of 3D printing and cheaper home machine tools led to a rise in popularity of bespoke blasters. [Zach] has long advocated for their supremacy, and has made a long-range blaster aimed at newcomers to the hobby. (Video, embedded below.)

The blaster is built around the popular Caliburn spring-powered design, originally created by [Captain Slug]. Modifications by [Zach] involve a longer barrel, relocated side-feeding magazine port, and other modifications designed to suit the long-range sniping role. There’s even a special “rifled” stabiliser on the end designed to reduce the effects of muzzle blast from disturbing the dart as it leaves the barrel.

It’s a design that very much builds on the efforts of the wider Nerf community, and is all the better for it. [Zach] has shared files and links to parts bundles to help get enterprising builders up and running with a minimum of fuss. We’d love to take the long blaster out for a round or three ourselves – it may just be time to fire up the 3D printer!

WiFive55: More Than a Smart 555 Replacement

พฤ, 04/15/2021 - 15:00

“You could’ve done that with a 555 timer.” But what if all you have on hand is an ESP8266? [TechColab] needed to control a solenoid valve with a short pulse via a solid-state relay (SSR) but found that the trusty 555 timer was tricky to set properly. Additionally, they wanted to add features, such as fixed pulse length, that were difficult to implement—even with multiple timers. Still wanting to keep things cheap and accessible, [TechColab] has created the WiFive55, a 555 replacement based on the ESP-01 ESP8266 board.

[TechColab] began by investigating existing ESP-01 solid-state relay boards but found that many of them momentarily enable the output on startup—a risk [TechColab] deemed unacceptable. This was resolved in the WiFive55 by adding an RC filter to the SSR output, eliminating the output glitches at the cost of slowing switching time to around 20 ms—an acceptable trade for many SSR applications.

Since they were going to design a new PCB to support this improved ESP-01 SSR controller, [TechColab] decided to go all-out. To support loads of widely varying sizes, the PCB supports an optoisolator that switches up to 1 A, a MOSFET that switches up to 2 A, and an on-board relay or SSR that can switch up to 3 A. For heavy loads, it includes connections for an off-board SSR, which allow it to switch whatever current the SSR can handle (easily over 50 A). Because the ESP-01 is slightly more capable than the 555, the WiFive55 supports control via WiFi, GPIO, serial, and push-button. Keeping with the WiFive55’s original role as a 555 replacement, it even includes a header exposing a 555-like trigger and output interface!

We always like seeing inexpensive boards like the ESP-01 being used to their full potential, and we can’t wait to see what software [TechColab] cooks up for this! If you’re interested in getting started with the ESP-01, you might consider starting with this guide to blinking an LED over WiFi.

A Faux BBS Gets Software On To Your Vintage Machines

พฤ, 04/15/2021 - 12:00

Back in the golden age of modems and phone lines, bulletin board systems, or BBSes, were a great way to find new software from the comfort of your own home. Most have shut down over the past few decades, as the Internet took over as a more flexible method of cat picture software distribution. [equant] was a fan of browsing for warez through a text interface however, so recreated the experience in a way that’s useful today. The result is RetroBridgeBBS.

The software runs on a modern PC, ideally a Linux one that runs Python 3 and has a serial port. Then, you can hook up your old retro computers via serial using a null modem cable. Fire up appropriate terminal software on the retro computer and you’re rewarded with a BBS-like interface. From here, you can search selected online repositories for software, and download what you like. The host PC parses requests from the retro PC over the serial link, and shuffles back the requested files downloaded from the Internet. Currently it’s set up primarily for Macintosh users, with some useful features to avoid downloading StuffIt archives of the wrong version – a perennial frustration in the 90s. Future plans involve expanding the system to suit more platforms.

It’s technically anachronistic, but it feels like a period-correct way to get software onto a vintage computer. It’s also a great way to do so when you’re lacking appropriate floppy hardware, hard disk emulators, or network cards – all of which can be expensive and in short supply. There’s other ways to go about it, too, of course – you can do some nifty things with an ESP8266, don’t you know! Video after the break.

Morrowind Rebooted The Original Xbox Without You Ever Noticing

พฤ, 04/15/2021 - 09:00

The original Xbox was well-known for being based on basic PC hardware, and among developers, well known for having just 64 megabytes of RAM which even at the time wasn’t a lot to be working with. In a recent podcast, [Todd Howard] of Bethesda related an anecdote from the era, claiming that Morrowind occasionally invisibly rebooted the Xbox without user’s knowledge in order to free up RAM. [Modern Vintage Gamer] wanted to determine if this was true or not, and began an investigation.

The investigation begins with the aid of an Xbox Development Kit. Noting that the original anecdote mentioned the reboots occurring during the loading process, the devkit Xbox was soft rebooted after executing a load. Rather than going back to the title screen of the game, it kicked straight back into the loading screen and brought up the last save game instead. This suggested that the game was indeed capable of rebooting in the midst of the loading routine.

[Modern Vintage Gamer] had a hunch that this was being achieved with the use of a routine called XLaunchNew Image, a piece of the Xbox API that could be used to soft-reboot the console and start an executable. Upon decompiling Morrowind, a call was found that fit the bill. Further analysis showed that the game was indeed calling XLaunchNewImage upon loading and launching a new game, and was confirmed by finding an *.ini file that contained flags to enable this behaviour.

Presumably, the reason for this behaviour was that it was simpler to boot the game fresh when loading a save, rather than trying to unload all the game assets in memory from the current game. It’s a neat trick that likely made the development team’s lives much easier once they implemented it.

We don’t often talk about The Elder Scrolls series around here, though we’ve seen someone modify an exercise bike to work with Skyrim. Video after the break.

Remote Controlled Car Gets Active Suspension

พฤ, 04/15/2021 - 06:00

Active suspensions are almost a holy grail for cars, adding so much performance gain that certain types have even been banned from Formula 1 racing. That doesn’t stop them from being used on a wide variety of luxury and performance cars, though, as they can easily be tuned on the fly for comfort or improved handling. They also can be fitted to remote controlled cars as [Indeterminate Design] shows with this electronic servo-operated active suspension system for his RC truck.

Each of the four servos used in this build is linked to the mounting point of the existing coilover suspension on the truck. This allows the servo to change the angle that the suspension is positioned while the truck is moving. As a result, the truck has a dramatic performance enhancement including a tighter turning radius, more stability, and the capability of doing donuts. The control system runs on an Arduino with an ESP32 to enable live streaming of data, and also includes an MPU6050 to monitor the position of the truck’s frame while it is in motion.

There’s a lot going on in this build especially with regard to the control system that handles all of the servos. Right now it’s only programmed to try to keep the truck’s body relatively level, but [Indeterminate Design] plans to program several additional control modes in the future. There’s a lot of considerations to make with a system like this, and even more if you want to accommodate for Rocket League-like jumps.

Logic Chip Teardown From Early 1990s IBM ES/9000 Mainframe

พฤ, 04/15/2021 - 03:00

The 1980s and early 1990s were a bit of an odd time for semiconductor technology, with the various transistor technologies that had been used over the decades slowly making way for CMOS technology. The 1991-vintage IBM ES/9000 mainframe was one of the last systems to be built around bipolar transistor technology, with [Ken Shirriff] tearing into one of the processor modules (TCM) that made up one of these mainframes.

A Thermal Conduction Module from an IBM ES/9000 mainframe.

Five of these Thermal Conduction Modules (127.5 mm a side) made up the processor in these old mainframes. Most of note are the use of the aforementioned bipolar transistors and the use of DCS-based (differential current switch) logic. With the already power-hungry bipolar transistors driven to their limit in the ES/9000, and the use of rather massive DCS gates, each TCM was not only fed many amperes of electricity, but also capable of dissipating up to 600 Watts of power.

Each TCM didn’t contain a single large die of bipolar transistors either, but instead many smaller dies were bonded on a specially prepared ceramic layer in which the wiring was added through a very precise process. While an absolute marvel of engineering, the ES/9000 was essentially a flop, and by 1997 IBM too would move fully to CMOS transistor technology.

Over the years we’ve featured a lot of [Ken]’s work, perhaps you’d like to know more about his techniques.

SV Seeker Is Recycling Batteries

พฤ, 04/15/2021 - 01:30

SV Seeker is a home-made boat currently being built by [Doug Jackson] just north of Tulsa, Oklahoma. It’s a bit different than what you might imagine as a typical DIY boat, though. You see, Seeker is a 75 ft steel boat, intended to work as a research vessel. Doug and his crew proudly refer to Seeker as “The boat the internet built”, and he’s our kind of people. We’ve covered them before, the first time way back in 2013. Doug’s Youtube channel does double duty, both teaching the rest of us all the skills he’s learned while building, and also serving as the eventual user and repair manual for the boat.

Building such a big project, and none of it contracted out, has presented its own challenges. Today’s topic is batteries. Even with a diesel power plant, and a couple generators on board, a boat like this has to have a battery bank for daily operations. They have a reverse osmosis water maker to make fresh water, 120 and 240 volt power, and several other systems that all run off their battery bank. The first iteration of the design was to re-use a set of Edison batteries, AKA nickel-iron batteries. Those didn’t work out, so they’ve decided to bite the bullet and go with Lithium-ion. Just buying a pre-built kit is anathema to their maker ethos, not to mention the project’s minuscule budget, so they’re improvising. The idea is to collect a boatload of old 18650 cells, found commonly in the battery packs for laptops and cordless tools. When those packs die, it’s commonly just a single cell that has gone bad, meaning that an enterprising hacker can harvest the good cells for another project.

I anticipate seeing a video on the making of the big battery bank in another couple months, but until then think about sending some old lithium-ion packs their way. Better hurry though, because Seeker is scheduled to launch from the Tulsa Port of Catoosa on August 21st. If you have a battery or five to donate the effort, mail them to:
42Fab LLC
941 West I35 Frontage Road Ste. 116 #540​
Edmond, OK 73034

Include a return address, and you even get a keychain made from the steel offcuts sent back to you.


History of Closed Captions: The Analog Era

พฤ, 04/15/2021 - 00:01

Closed captioning on television and subtitles on DVD, Blu-ray, and streaming media are taken for granted today. But it wasn’t always so. In fact, it was quite a struggle for captioning to become commonplace. Back in the early 2000s, I unexpectedly found myself involved in a variety of closed captioning projects, both designing hardware and consulting with engineering teams at various consumer electronics manufacturers. I may have been the last engineer working with analog captioning as everyone else moved on to digital.

But before digging in, there is a lot of confusing and imprecise language floating around on this topic. Let’s establish some definitions. I often use the word captioning which encompasses both closed captions and subtitles:

Closed Captions: Transmitted in a non-visible manner as textual data. Usually they can be enabled or disabled by the user. In the NTSC system, it’s often referred to as Line 21, since it was transmitted on video line number 21 in the Vertical Blanking Interval (VBI).
Subtitles: Rendered in a graphical format and overlaid onto the video / film. Usually they cannot be turned off. Also called open or hard captions.

The text contained in captions generally falls into one of three categories. Pure dialogue (nothing more) is often the style of captioning you see in subtitles on a DVD or Blu-ray. Ordinary captioning includes the dialogue, but with the addition of occasional cues for music or a non-visible event (a doorbell ringing, for example). Finally, “Subtitles for the Deaf or Hard-of-hearing” (SDH) is a more verbose style that adds even more descriptive information about the program, including the speaker’s name, off-camera events, etc.

Roughly speaking, closed captions are targeting the deaf and hard of hearing audience. Subtitles are targeting an audience who can hear the program but want to view the dialogue for some reason, like understanding a foreign movie or learning a new language.

Titles Before Talkies Intertitles from the 1920 film The Cabinet of Dr Caligari

Subtitles are as old as movies themselves. Since the first movies didn’t have sound, they used what are now called intertitles to convey dialogue and expository information. These were full-screens of text inserted (not overlaid) into the film at appropriate places. Some attempts were made at overlaying the subtitles which used a second projector and glass slides of text which were manually switched out by the projectionist, hopefully in synchronization with the dialogue. One forward-thinking but overlooked inventor experimented with comic book dialogue balloons which appeared next to the actor who was speaking. These techniques also made distribution of a film to other countries a relatively painless affair — only the intertitles had to be translated.

This changed with the arrival of “talkies” in the late 1920s. Now there was no need for intertitles since you could hear the dialogue. But translations for foreign audiences were still desired, and various time-consuming optical and chemical processes were used to generate the kind of subtitles we think of today. But there were no subtitles for local audiences — no doubt to the irritation of deaf and hard-of-hearing patrons who had been equally enjoying the movies alongside hearing persons for years.

Television Malcolm J. Norwood

As television grew in popularity, there were some attempts at optical subtitles in the early years, but these were not wildly successful nor widely adopted. In the United States, there was interest brewing in closed captioning systems by the end of the 1960s. In April 1970, the FCC received a petition asking that emergency alerts be accompanied by text for deaf viewers. This request came at a perfect point in time when the technology was ready, and the various parties were interested and prepared to take on the challenge.

It was at this time that deaf bureaucrat Malcolm Norwood from the Department of Education (then HEW) enters the story. He had been working in the Captioned Films for the Deaf department since 1960. Today he is often called the Father of Closed Captioning within the community. He was the perfect leader to champion this new technology and he accepted the challenge.

The FCC agreed in principle with the issues raised, and in response issued Public Notice 70-1328 in December 1970. Malcolm and the DOE brought together a team in 1971 which included the National Bureau of Standards, the National Association of Broadcasters, ABC, and PBS. They held a conference in Nashville (PDF) in December of 1971, which we can say was the birthplace of closed captioning.

First Captioned TV Program in 1972, The French Chef hosted by Julia Child. These were Open Captions and could not be turned of by the viewer.

It turns out that the technical implementation of broadcasting captions built on existing work. Over at the the National Bureau of Standards, engineer Dave Howe had been developing a system called TvTime to distribute accurate time signals over the air. This system sent a code over a video line in the VBI, using a method which eventually morphed into the CC standard. They had been testing the system with ABC, PBS, and NBC. ABC had even begun using this system to send text messages between affiliate stations.

Another system presented at the conference by HRB-Singer altered the vertical scanning of the receiver so that additional VBI lines were visible, and transmitted the caption text digitally, but visually, in those newly-exposed lines. This caused some concern among the TV set manufacturers, and thankfully the NBS system eventually won out.

After a few promising demonstrations, in 1973 PBS station WETA in the District of Columbia was authorized to broadcast closed captioned signals in order to further develop and refine the system. These efforts were successful, and in 1976 the FCC formally reserved line 21 for closed captions.

Adapting Broadcasts for Line 21 This is an index card that kicked around in my briefcase for many years. Can you spot the error?

In its final form, the signal on line 21 had a few cycles of clock run-in to lock the decoder’s data recovery oscillator, followed by a 3-bit start pattern, and finally two parity-protected characters of text. The text encoding is almost always ASCII, with a few exceptions and special symbols considered necessary for the task. Text was always transmitted as pair of characters, and has traditionally been sent in all capital letters. Control codes are also byte pairs, and they perform functions like positioning the cursor, switching captioning services, changing colors, etc. Because control codes were so crucial to the proper display of text, parity protection wasn’t enough — they were usually transmitted twice, the duplicate control code pair being ignored if the first pair was error-free.

Summary of Line 21 data Basic Rate 503.496 kBd (32 x Horiz freq) Grouping 2 each 7-bit + parity bit characters / video line Encoding ASCII, with some modifications Services odd fields: CC1/CC2, T1/T2 even fields: CC3/CC4, T3,T4, XDS Specification EIA-608, 47 CFR 15.119, TeleCaption II

Today we are accustomed to near-perfect video and audio programming, thanks to digital transmissions and wired/optical networks. Adding a few extra bytes into an existing protocol packet would barely give us pause. But back then, other factors had to be considered. The resulting CC standard was fine-tuned during lengthy and laborious field tests. The captioned video signal had to be robust when transmitted over the air. Engineers had to address and solve problems like signal strength degradation in fringe reception areas and multipath in dense urban areas.

Pop-On CC Demo Frame from Felix the Cat

As for the captioning methods, there were a few different types available. By far the most common styles were POP-ON and ROLL-UP. In POP-ON captioning, the receiver accumulated the incoming text in a buffer until receipt of a “flip-memory” control code, whereupon the entire caption would immediately appear on-screen simultaneously with the spoken dialogue. This style was typically used with prerecorded, scripted material such as movies and dramas. On the other hand, with ROLL-ON captioning, as its name implies, the text physically rolled-up from the bottom of the screen line-by-line. It was used for live broadcasts such as news programs and sporting events. The text naturally must be delayed from the audio due to the nature of the live speech transcription process.

The Brits Did it Differently, and Implemented Teletext in the Process

Across the pond, broadcast engineers at the BBC approached the issue from a different angle. Their managers asked if there was any way to use the transmitters to send data, since they were otherwise idle for one quarter of each day. Therefore they worked on maximizing the amount of data which could be transmitted.

The initial service worked like a FAX machine by scanning, transmitting, and printing a newspaper page. Eventually, the BBC adopted an all-digital approach called CEEFAX developed by engineer John Adams of Philips. Simultaneously, a competing and incompatible service called ORACLE was begun by other broadcasters. In 1974, everyone finally settled on a merged standard called World System Teletext (WST) adopted as CCIR 653. Broadcasters in North America adopted a slight variant of WST called the North American Broadcast Teletext Specification (NABTS). Being a higher data rate than CC, teletext is less forgiving of transmission errors. It employs a couple of different Hamming codes to protect and optionally recover from errors in key data fields. It is quite a complex format to decode compared to line 21.

British Radio Equipment Manufacturer’s Association, Broadcast Teletext Specification

As for the format, teletext services broadcast three-digit pages of text and block graphical data — conceptually an electronic magazine. Categories of content were grouped by pages:

Example of Teletext Magazine Page
  • 100s – News
  • 200s – Business News
  • 300s – Sport
  • 400s – Weather and Travel
  • 500s – Entertainment
  • 600s – TV and Radio Listings

These text in these magazine pages are an integral part of the packet structure. For example, the text of line 4 in page 203 belongs in a specific packet for that page/line. Since the broadcaster is continuously transmitting all magazines and their pages, it may take a few seconds for the page you request to appear on-screen. NABTS takes a more free-form approach. The data can almost be considered a serial stream of text, like a connection of a terminal to a computer. If you need a new line of text, you send a CR/LF pair.

Summary of Teletext Data Basic Rate 6.938 MBd Grouping 360 bits/line, 40 available text characters Encoding Similar to Extended ASCII, with code pages Services Multiple page magazines, 40×24 chars each page Specifications Europe: WST ITU-R BT.653 (formerly CCIR 653) North America: NABTS EIA-516 The Hacks That Made It All Work

Most of my designs were for use in North America, but I needed to learn about European teletext for a few candidate projects. In Europe, page 888 of the teletext system was designated to carry closed captioning text. This page has a transparent background and the receiver overlays it onto the video. The visual result was practically the same as in North America. But it posed some problems regarding media like VHS tapes.

The teletext signal couldn’t be recorded or played back on your typical home VHS recorder. To solve this, many tapes were made using an adaptation of the North American line 21 system, but applied to the PAL video format. This method was variously called line 22 or line 25 (the confusion being that PAL line #1 is different place than NTSC line #1), but was basically the same. A manufacturer who has a CC decoder in their NTSC product can easily adapt it to work in PAL countries.

How did I get PAL VHS tapes? I asked an engineer colleague at Philips Southampton if he could send me some sample tapes for testing. His wife bought some used from a local rental store and sent them to me. This was before the days of PayPal, so I sent her an international money order for $60. This covered the price of the tapes and shipping, plus a few extra dollars “tip” for her trouble. Some weeks later, I got an email from him saying that “you Americans sure give generous tips”. His wife had received my money order for $600, not $60! It took many months, but eventually the post office caught their mistake and she returned the overage.

The Author Troubleshooting a DVD Closed Caption problem at LG in 2003

In South Korea, a colleague was involved in the captioning industry back in the late 1990s. He was asked to participate on a government panel considering the nationwide adoption of closed captioning. The final result was comical — instead of CC, the committee decided to provided extremely loud external TV speakers free-of-charge to people with hearing difficulties. Fortunately, the conventional form of closed captioning has since been adopted with the advent of digital television broadcasting.

Designing on the Trailing Edge

By the year 2000, almost all televisions had CC decoders built-in. As a result, there were a variety of ICs available to extract and process the line 21 signal. One example was from Philips Semiconductor (which became NXP and is now Freescale). As a key developer of teletext technology and a major chip supplier to the television industry, they offered a wide variety of CC and teletext processors. I developed several designs based on a chip from their Painter family of TV controllers. These were 8051-based microcontrollers with all the extras needed for teletext, closed captions, and user menus. They had VBI data slicers, character generators and ROM fonts, all integrated onto one die.

Philips Saa55xx datasheet (page 91)

I still remember discovering the Painter chip buried pages deep in an internet search one day. When I couldn’t find any detailed information, I called the local rep and was told, “You aren’t supposed to even know about this part number — it’s a secret!”. Eventually the business logistics were resolved and I was allowed to use the chip. That was the only masked-ROM chip I ever made. I can still feel the rumbling in my stomach on the day I delivered the hex file to the local Philips office. The rep and I were hunched over the computer as we double- and triple-checked each entry on their internal ordering system. Once we pressed SEND, the bits were irrevocably transmitted to the factory and permanently burned into many thousands of chips. Even though we had thoroughly tested and proven the firmware in the lab, it was nevertheless a stressful day.

Philips Painter Chip

As I developed several other designs, it became clear that these special purpose chips should be avoided if any reasonable longevity was needed. The Painter chips were being phased out, several other options were disappearing as well. The writing was on the wall — digital broadcasting was here to stay, and the chip manufacturers were no longer making or supporting analog CC chips. I decided that future CC projects had to be done using general purpose ICs. I plan to delve into that in a future article along with unexpected applications of CC technology, the process of making captions, and how captioning made (or didn’t make) the transition to digital broadcasting and media.

You Need an Automated Overhead Camera Assistant

พุธ, 04/14/2021 - 22:30

It’s 2021. Everyone and their mother is filming themselves doing stuff, and a lot of it is super cool content. But since most of us have to also work the video capture devices ourselves, it can be difficult to make compelling footage with a single, stationary overhead view, especially when there are a lot of steps involved. A slider rig is a good start, but the ability to move the camera in three dimensions programmatically is really where it’s at.

[KronBjorn]’s excellent automated overhead camera assistant runs on an Arduino Mega and is operated by typing commands in the serial monitor. It can pan ±20° from straight down and moves in three axes on NEMA-17 stepper motors. It moves really smoothly, which you can see in the videos after the break. The plastic-minimal design is interesting and reminds us a bit of an ophthalmoscope — that’s that main rig at the eye doctor. There’s only one thing that would make this better, and that’s a dedicated macro pad.

If you want to build your own, you’re in luck — there’s quite a lot of detail to this project, including a complete BOM, all the STLs, code, and even assembly videos of the 3D-printed parts and the electronics. Slide past the break to check out a couple of brief demo videos.

Not enough room for a setup like this one? Try the pantograph version.

Magna Announces Simple Drive Solution For Electric Pickup Trucks

พุธ, 04/14/2021 - 21:00

Thus far, the majority of electric cars on sale have been aimed at commuters, fitting into the sedan and SUV segments of the marketplace. Going forward, there’s a very real need for electrification to touch the whole spectrum of automobiles, and that includes work vehicles like pickup trucks. A company called Magna have recently thrown their hat into the ring in just this space, developing a simple drivetrain that can be readily installed in pickup trucks without major modifications. 

It’s All About The Form Factor The eBeam motor slots into the chassis in place of a traditional rear differential, requiring no special adaptation to the suspension or braking systems.

The aim of Magna’s eBeam technology is to make it easier to build electric pickup trucks and other related work vehicles. The basic concept is one of an electric motor drive unit built into a form factor that mimicks that of traditional beam axles, commonly used with leaf spring suspension designs in most pickups. This has the possibility of being a drop-in motor solution for a wide variety of trucks, the vast majority of which use broadly similar rear suspension setups.  By simply changing the axle shafts and spring mounts to suit, Magna’s eBeam motor can be fitted to virtually any pickup. The eBeam setup is designed to work with OEM braking and suspension systems, though regenerative brake assist is likely a possibility as well.

Beam axles are common on pickup trucks and other load-carrying vehicles. Magna’s eBeam motor system is aimed at these applications.

The eBeam is a rear-drive solution only, of course, though it need not be limited to only two wheel drive trucks. Magna have already developed a series of electric drive solutions that can be used up front in order to handle four wheel drive, something often considered a must in the truck market. This obviously necessitates a second motor and associated control hardware, but avoids the hassle of differentials, transfer cases and driveshafts typical of traditional four-wheel drive systems.

The line of eBeam motor drives is slated to come in three different combinations. A single-motor drive, a single-motor drive with two-speed gearing, and a twin-motor drive with torque vectoring. Power ranges are slated to be from 120 kW (160 hp) up to 250 kW (335 hp). This is roughly on par with existing engine choices in most low-to-mid market pickups, though falls short somewhat compared to the most powerful truck engines currently on the market which are pushing in excess of 400 hp (~300 kW). Against this, electric motors have the benefit of delivering maximum torque right from zero RPM – a major benefit when it comes to pulling heavy loads. It’s likely that for many jobs, an electric powertrain of slightly lesser peak power would nonetheless fare well against a petrol or diesel competitor.

Currently, Magna are marketing the eBeam axles towards automakers, hoping to secure a slice of the not-yet-mainstream electric pickup market. Nevertheless, the homebrew conversion scene is a lively one, with enthusiasts taking whatever parts are available to create their own electric rides. It’s easy to imagine there’d be a healthy market in selling such conversion parts for popular older trucks, such as Ford’s F-series and older Rams and Silverados.

This cutaway shows the eBeam rear axle and one of Magna’s existing front-drive motor solutions.

Regardless of the target vehicle, however, the Magna eBeam is not an all-in-one solution. Although it solves the problem of how to drive the rear wheels with an electric motor, that’s all it does. Figuring out a battery solution, charging, and other such concerns are left as an exercise for the buyer.

For the dedicated gearhead, hacking in some salvaged parts from crashed EVs would likely get one most of the way there. For automakers, however, significant design effort is still required to take platforms originally designed for fuel tanks and big combustion engines, and shake everything around until it fits.

More likely, we’ll see electric pickups designed around battery packs from the ground up, for safety, packaging and performance concerns. The market has a heavy focus on the range of electric vehicles, and this is dependent on battery size and performance. While the eBeam design makes for a drop-in rear drive solution, vehicles hoping to compete in the marketplace will still need well integrated battery solutions if they’re going to convince buyers to adopt.

With electric pickups like the Rivian R1T and Tesla Cybertruck reportedly just around the corner, the electric pickup battle is about to begin.

Overall, the eBeam is an interesting product, though one that seems better suited to a thirsty conversion market rather than established automakers. While one can appreciate an integrated rear drive motor solution, it’s something that’s well within the design abilities of just about any top-20 automaker, so we don’t know why they buy it externally. The real challenge lies in the integration of electric drive systems with the rest of the vehicle, and that’s something that a beam-axle motor can’t solve.

Whether Magna’s hardware takes off in the industry depends on what automakers themselves have been developing behind closed doors, and one would imagine they’d started with the motors a long time ago. As always, time will tell.


Gaming With 1 Horsepower Of Rumble Feedback

พุธ, 04/14/2021 - 18:00

Force feedback took off in a big way in the late 90s, bringing a sense of realism to flight sticks and racing wheels that hadn’t been there before. Its cheaper haptic cousin was rumble feedback via vibration motors, which does add a little something but it’s more an idea of a feeling than anything relevant to real life. It’s also usually pretty weak, but [teenenggr] has a way around that.

The build takes a regular Playstation controller, and disconnects the internal rumble motors. The controller’s motor output is instead linked to an Arduino Uno’s digital input. When the Arduino detects the rumble motor signal switching on, it turns on a relay, supplying power to a hefty one horsepower induction motor, fitted with an eccentric weight.

What happens next is pure chaos. Essentially equivalent to throwing a brick in a washing machine, the motor shakes the entire desk at the slightest hint of rumble signals from the gain. Sustained vibration commands, such as when firing machine guns in Crysis, flung [teenenggr]’s monitor from the desk. Even with it taped down, game play quickly became impossible as he inadvertently hits ALT-Tab and leaves the game while trying to hang on to the desk for dear life.

Is it a useful hack? No, but it would make an excellent prank if bolted underneath your friend’s gaming rig for a laugh. With that said, the intense vibration probably won’t do any good for mechanical hard drives, anything with edge connectors, or just their computer in general. It’s a big step up from the last [teenenggr] project we featured – a rumble feedback mouse. Video after the break.

Sanity Check your Engines with this Dynamometer

พุธ, 04/14/2021 - 15:00

As you get ready to pop the hood of your RC car to drop in a motor upgrade, have you ever wondered how much torque you’re getting from these small devices? Sure, we might just look up the motor specs, but why trust the manufacturer with such matters that you could otherwise measure yourself? [JohnnyQ90] did just that, putting together an at home-rig built almost from a stockpile of off-the-shelf parts.

To dig into the details, [JohnnyQ90] has built himself a Prony Brake Dynamometer. These devices are setup with the motor shaft loosely attached to a lever arm that can push down on a force-measuring device like a scale. With our lever attached, we then power up our motor. By gradually increasing the “snugness” of the motor shaft, we introduce sliding friction that “fights” the motor, and the result is that, at equilibrium, the measured torque is the maximum amount possible for the given speed. Keep turning up that friction and we can stall the motor completely, giving us a measurement of our motor’s stall torque.

Arming yourself with a build like this one can give us a way to check the manufacturer’s ratings against our own, or even get ratings for those “mystery motors” that we pulled out the dumpster. And [JohnnyQ90’s] build is a great reminder on how we can leverage a bit of physics and and a handful of home goods to get some meaningful data.

But it turns out that Prony Brake Dynamometers aren’t the only way of measuring motor torque. For a disc-brake inspired, have a look at this final project. And if you’re looking to go bigger, put two motors head-to-head to with [Jeremy Felding’s] larger scale build.