Voyager 1 In Trouble As Engineers Scramble To Debug Issue With Flight Data System

Recently the team at JPL responsible for communication with the Voyager 1 spacecraft noticed an issue with the data it was returning from the Flight Data System (FDS). Although normally the FDS is supposed to communicate with the other subsystems via the telecommunications unit (TMU), this process seems to have broken down, resulting in no payloads from the scientific instruments or engineering sensors being returned any more, just repeating binary patterns. So far the cause of this breakdown is unknown, and JPL engineers are working through potential causes and fixes.

This situation is not unlike a similar situation on Voyager 2 back in 2010 when the returned data showed a data pattern shift. Here resetting the memory of the FDS resolved the garbled data issue and the engineers could breathe a sigh of relief. This time the fix does not appear so straightforward, as a reset of the FDS on Voyager 1 did not resolve the issue with, forcing the team to consider other causes. What massively complicates the debugging is that each transmission to and from the spacecraft takes approximately 22.5 hours each way, making for an agonizing 45 hour wait to receive the outcome of a command.

We wish the JPL engineers involved all the luck in the world and keep our collective appendages crossed for Voyager 1.

X86 ENTER: What’s That Second Parameter?

[Raymond Chen] wondered why the x86 ENTER instruction had a strange second parameter that seems to always be set to zero. If you’ve ever wondered, [Raymond] explains what he learned in a recent blog post.

If you’ve ever taken apart the output of a C compiler or written assembly programs,  you probably know that ENTER is supposed to set up a new stack frame. Presumably, you are in a subroutine, and some arguments were pushed on the stack for you. The instruction puts the pointer to those arguments in EBP and then adjusts the stack pointer to account for your local variables. That local variable size is the first argument to ENTER.

The reason you rarely see it set to a non-zero value is that the final argument is made for other languages that are not as frequently seen these days. In a simple way of thinking, C functions live at a global scope. Sure, there are namespaces and methods for classes and instances. But you don’t normally have a C compiler that allows a function to define another function, right?

Turns out, gcc does support this as an extension (but not g++). However, looking at the output code shows it doesn’t use this feature, but it could. The idea is that a nested function can “see” any local variables that belong to the enclosing function. This works, for example, if you allow gcc to use its extensions:

#include <stdio.h>

void test()
{
   int a=10;
   /* nested function */
   void testloop(int n)
   {
      int x=a;
      while(n--) printf("%d\n",x);
   }
   testloop(3);
   printf("Again\n");
   testloop(2);
   printf("and now\n");
   a=33;
   testloop(5);
}

void main(int argc, char*argv[])
{
   test();
}

Continue reading “X86 ENTER: What’s That Second Parameter?”

NASA Blames Probe Chute Failure On Wire Labels

When NASA’s OSIRIS-REx sample return capsule screamed its way through the upper atmosphere, it marked the first time the space agency had brought material from an asteroid back to Earth. Hundreds of thousands tuned into the September 24th live stream so they could watch the capsule land at the Utah Test and Training Range. But about ten minutes before the capsule was set to touchdown, keen eyed viewers may have noticed something a bit odd — when ground control called out that the vehicle’s drogue parachute was commanded to deploy…nothing seemed to happen.

Now NASA knows why it didn’t work as expected, and it ended up being the sort of Earthly problem that we’d wager a few in this audience have run into themselves from time to time.

Continue reading “NASA Blames Probe Chute Failure On Wire Labels”

ThunderScan: The Wild 1980s Product That Turned A Printer Into A Scanner

Back in the 1980s, printers were expensive things. Scanners were rare, particularly for the home market, because home computers could barely handle basic graphics anyway. Back in these halcyon days, an obscure company called Thunderware built a device to convert the former into the latter. It was known as the Thunderscan, and was a scanning head built for the Apple ImageWriter dot matrix printer. Weird enough already, but this device hides some weird secrets in its design.

The actual scanning method was simple enough; the device mounted a carriage to the printer head of the ImageWriter. In that carriage was an optical reflective sensor which was scanned across a page horizontally while it was fed through the printer. So far, so normal.

The hilarious part is how the scanner actually delivered data to the Macintosh computer it was hooked up to. It did precisely nothing with the serial data lines at all, these were left for the computer to command the printer. Instead, the output of the analog optical sensor was fed to a voltage-to-frequency converter, which was then hooked up to the handshake/clock-in pin on the serial port.

The scanner software simply looked at the rate at which new characters were becoming available on the serial port as the handshake pin was toggled at various frequencies by the output of the optical sensor. Faster toggling of the pin indicated a darker section of the image, slower corresponded to lighter.

Interestingly, [Andy Hertzfeld] also has his own stories to tell on the development, for which his software contribution seems to have netted him a great sum of royalties over the years. It’s funny to think how mainstream scanners once were; and yet we barely think about them today beyond a few niche uses. Times, they change.

Thanks to [J. Peterson] for the tip!

Cheap Computer PSU Puts On Weight With Box Of Iron

Humans are funny creatures. For whatever reason, when handling a piece of electronics, we tend to equate heft with value.  If something feels too light, it gives the impression of being cheap or inferior. As such, it’s not unheard of for gadgets to include a little chunk of metal that serves no purpose other than to add weight.

But a recent discovery by the aptly named [RedditCringe990] really takes things to a new low. Upon opening up the cheap power supply that came with their computer case, they noticed an odd little box that didn’t appear to have any electrical connection to the rest of the device. After unscrewing it from the metal body of the power supply and pulling the bottom panel off, they found it was packed full of iron filings.

At some level, you have to appreciate the attention to detail here. At first glance, especially if you were peeking through the PSU’s air vents, you could be forgiven for thinking the box was some kind of transformer. It’s even got some alphanumeric gibberish written on the side to help complete the look. Makes us wonder how many of these things might actually have gone undetected by less curious PC-builders.

As you might expect, the weighted box is only one of the issues with this particular PSU. As pointed out by fellow Redditor [Hattix], even the functional components are worthy of suspicion. There’s no protection on the input or output, no safety capacitor, and (unsurprisingly) no regulatory marks.

We’d say the thing might still be useful as a boat anchor, but now that the box of iron fillings has been removed, it’s probably not even heavy enough. Stay safe out there, folks.

Some Bacteria Could Have A Rudimentary Form Of Memory

When we think of bacteria, we think of simple single-celled organisms that basically exist to consume resources and reproduce. They don’t think, feel, or remember… or do they? Bacteria don’t have brains, and as far as we know, they’re incapable of thought. But could they react to an experience and recall it later?

New research suggests that some bacteria could have a rudimentary form of memory of their experiences in the environment. They could even pass this memory down across generations via a unique mechanism. Let’s dive into the latest research that is investigating just what bacteria know, and how they happen to know it.

Continue reading “Some Bacteria Could Have A Rudimentary Form Of Memory”

Oddball LCDs Reverse Engineered Thanks To Good Detective Work

Is there anything more discouraging to the reverse engineer than to see a black blob of epoxy applied directly to a PCB? We think not, because that formless shape provides no clue as to what chip lies beneath, and that means a lot of detective work if you’re going to figure out how to use this thing.

[Sudhir Chandra]’s detective story starts with a bunch of oddball LCDs, slim 1×32 character units rather than the more familiar 2×16 displays. Each bore the dreaded black COB blob on the back, as well as a handful of SMD components and not much else. Googling revealed no useful documentation, and the manufacturer wasn’t interested in fielding calls from a hobbyist. Reasoning that most manufacturers wouldn’t spin up a custom chip for every display, [Sudhir] assumed there was an ST7066, a common LCD driver chip, underneath the blob, especially given the arrangement of external components. But a jumper set was bodged together under this assumption didn’t get the display going.

Next up were more destructive methods, to decap the COB and see what kind of numbers might be on the chip. Sandpaper worked at first, but [Sudhir] eventually turned to the “Chips a la [Antoine]” method of decapping, which uses heat and brute force to get at the goods. This got down to the chip, but [Sudhir]’s microscope wasn’t up to the task of reading the die markings.

What eventually cracked the case was tracing out the voltages across the various external resistors and matching them up to other chips in the same family as the ST7066, plus the realization that the long, narrow epoxy blob probably covered a similarly shaped chip, which led to the culprit: an ST7070. This allowed [Sudhir] to build an adapter PCB for the displays, with plans for a custom Arduino library to talk to the displays.

This was a great piece of reverse engineering and a good detective story to boot. Hats off to [Sudhir] for sticking with it.