TechyMagThings

Although vapor-compression refrigeration is a simple concept, there are still a lot of details in the implementation of such a system that determines exactly how efficient it is. After making a few of such systems, [Hyperspace Pirate] decided to sit down and create a testing system that allows for testing of many of these parameters.

Some of the major components that determine the coefficient of performance (COP) of a heat pump or similar system include the used refrigerant, as well as the capillary tube diameter or expansion valve design. For the testing in the video three refrigerants are used: R600 (N-Butane), R134a (tetrafluoroethene, AKA Freon) and R290 (propane), with R134a being decidedly illegal in places like the EU. The use of R600 instead of R600A is due to the former allowing for a lower pressure system, which is nice for low-power portable systems.

The test rig has the typical fresh-from-the-scrap-heap look that we’re used to and love from [Hyperspace Pirate], but does exactly what it says on the tin, and is easy for any DIY enthusiast to replicate. Which compressor to pick for a specific refrigerant is also covered in the video, along with oil type and more.

For basic systems you’d use a simple capillary tube, whereas an airconditioner or similarly more complex system would use an adjustable valve design. With the rig you can test the efficiency of different tube diameters, with three sizes available in this version. Unfortunately the electronic expansion valve (EEV) that was going to be used didn’t get a chance to shine due to unforeseen events.

With the R134a and butane a COP of 2.0 – 2.5 was achieved when taking power factor into account, which was reasonable considering a compressor was used that targets R134a. Regardless, if you have ever felt like repurposing that old compressor from a fridge or AC unit, this might be a fun afternoon project.

Kiki bills itself as the “array programming system of unknown origin.” We thought it reminded us of APL which, all by itself, isn’t a bad thing.

The announcement post is decidedly imaginative. However, it is a bit sparse on details. So once you’ve read through it, you’ll want to check out the playground, which is also very artistically styled.

If you explore the top bar, you’ll find the learn button is especially helpful, although the ref and idiom buttons are also useful. Then you’ll find some examples along with a few other interesting tidbits.

One odd thing is that Kiki reads right to left. So “2 :* 3 :+ 1” is (1+3)2 not (23)+1. Of course, you can use parentheses to be specific.

If you are jumping around in the tutorial, note that some cells depend on earlier cells, so randomly pressing a “run” button is likely to produce an error.

Would you use kiki? There are plenty of array languages out there, although perhaps none that have such poetic documentation. Let us know if you have a favorite language for this sort of thing and if you are going to give Kiki a try.

If you want to try old school APL, that’s easier than ever.

There’s a long history of devices originally used for communication being made into computers, with relay switching circuits, vacuum tubes, and transistors being some well-known examples. In a smaller way, pneumatic tubes likewise deserve a place on the list; [soiboi soft], for example, has used pneumatic systems to build actuators, logic systems, and displays, including this latching seven-segment display.

Each segment in the display is made of a cavity behind a silicone sheet; when a vacuum is applied, the front sheet is pulled into the cavity. A vacuum-controlled switch (much like a transistor, as we’ve covered before) connects to the cavity, so that each segment can be latched open or closed. Each segment has two control lines: one to pressurize or depressurize the cavity, and one to control the switch. The overall display has four seven-segment digits, with seven common data lines and four control lines, one for each digit.

The display is built in five layers: the front display membrane, a frame to clamp this in place, the chamber bodies, the membrane which forms the switches, and the control channels. The membranes were cast in silicone using 3D-printed molds, and the other parts were 3D-printed on a glass build plate to get a sufficiently smooth, leak-free surface. As it was, the display used a truly intimidating number of fasteners to ensure airtight connections between the different layers. [soiboi soft] used the display for a clock, so it sits at the front of a 3D-printed enclosure containing an Arduino, a small vacuum pump, and solenoid valves.

This capacity for latching and switching, combined with pneumatic actuators, raises the interesting possibility of purely air-powered robots. It’s even possible to 3D-print pneumatic channels by using a custom nozzle.

Thanks to [Norbert Mezei] for the tip!

Although we can already buy commercial transceiver solutions that allow us to use PCIe devices like GPUs outside of a PC, these use an encapsulating protocol like Thunderbolt rather than straight PCIe. The appeal of  [Sylvain Munaut]’s project is thus that it dodges all that and tries to use plain PCIe with off-the-shelf QSFP transceivers.

As explained in the intro, this doesn’t come without a host of compatibility issues, least of all PCIe device detection, side-channel clocking and for PCIe Gen 3 its equalization training feature that falls flat if you try to send it over an SFP link. Fortunately [Eli Billauer] had done much of the leg work already back in 2016, making Gen 2 PCIe work over SFP+.

The test setup involves a Raspberry Pi 5 on a PCIe breakout board and a PCIe card connected to the whole QSFP intermediate link with custom SFP module PCBs for muxing between PCIe edge connector or USB 3.0 connectors to use those cheap crypto miner adapter boards. The fiber is just simple single-mode fiber. Using this a Gen 2 x1 link can be created without too much fuss, demonstrating the basic principle.

Moving this up to Gen 3 will be challenging and will be featured in future videos, involving more custom PCBs. With Gen 5 now becoming standard on mainboards, it would be great to see this project work for Gen 3 – 5 at link sizes of x4 and even x16 so that it might be able to run external GPUs at full bandwidth unlike Thunderbolt.

Thanks to [zoobab] for the tip.

With multiple rovers currently scurrying around on the surface of Mars to continue a decades-long legacy, it can be easy to forget sometimes that repeating this feat on other planets that aren’t Earth or Mars isn’t quite as straightforward. In the case of Earth’s twin – Venus – the surface conditions are too extreme to consider such a mission. Yet Mercury might be a plausible target for a rover, according to a study by [M. Murillo] and [P. G. Lucey], via Universe Today’s coverage.

The advantages of putting a rover’s wheels on a planet’s surface are obvious, as it allows for direct sampling of geological and other features unlike an orbiting or passing space probe. To make this work on Mercury as in some ways a slightly larger version of Earth’s moon that’s been placed right next door to the Sun is challenging to say the least.

With no atmosphere it’s exposed to some of the worst that the Sun can throw at it, but it does have a magnetic field at 1.1% of Earth’s strength to take some of the edge off ionizing radiation. This just leaves a rover to deal with still very high ionizing radiation levels and extreme temperature swings that at the equator range between −173 °C and 427 °C, with an 88 Earth day day/night cycle. This compares to the constant mean temperature on Venus of 464 °C.

To deal with these extreme conditions, the researchers propose that a rover might be able to thrive if it sticks to the terminator, being the transition between day and night. To survive, the rover would need to be able to gather enough solar power – if solar-powered – due to the Sun being very low in the sky. It would also need to keep up with the terminator velocity being at least 4.25 km/h, as being caught on either the day or night side of Mercury would mean a certain demise. This would leave little time for casual exploration as on Mars, and require a high level of autonomy akin to what is being pioneered today with the Martian rovers.

Top image: the planet Mercury with its magnetic field. (Credit: A loose necktie, Wikimedia)

Most rhythm games have a community creating custom charts, and Trombone Champ is no exception. What is exceptional, however, [CraftedCart]’s osu! played in a Trombone Champ chart.

It all started as a challenge to make the most unserious chart possible. Among some other ideas, [CraftedCart] eventually decides to make an osu! chart but play it in Trombone Champ. Okay, not a problem, let’s just–oh, you can’t run arbitrary code without a making a mod. So instead, they decided to use shaders on the GPU. There are, of course, all sorts of problems with such an idea. Being stuck in the fixed render pipeline of a game, you can’t just add any resources to your shader you want. This leads to using textures as memory, both the game state and the osu! chart are actually textures. Another interesting one is getting user input into the shader. [CraftedCart] solves that by connecting the position of the game object the background is rendered to to the cursor; then, the shader reads the world to local transform matrix to determine the mouse position. Finally, the graphics the player ends up seeing are rendered using ray marching.

Video after the break.

After users of Battle Born LFP batteries encountered issues such as a heavily discolored positive terminal and other signs of overheating, multiple autopsies showed that the cause appeared to be the insertion of a thermoplastic between the bus bar and the terminal. Over time thermal creep loosened the connections, causing poor contact and melting plastic enclosures. According to Battle Born, this is actually part of an ingenious thermal safety design, and in a recently published article they explain how it works.

The basic theory appears to be that if there’s a thermal event, the ABS thermoplastic will soften and reduce the pressure on the bolted-together copper bus bar and brass terminal. This then allows for an aluminium-oxide layer to form on the aluminium connecting bolt courtesy of the dissimilar copper/aluminium interface. Aluminium-oxide is non-conductive and thus interrupts the flow of current.

Of course, there are countless issues with that theory, least of all the many reports of in-field failures. We recently covered [Will Prowse] studying the death of one of these 100 Ah LFP batteries from brand-new to failure under controlled circumstances. This clearly shows the thermal creep loosening up the connection and causing poor contact between the bus bar, the bolt and the terminal, with poor contact and thermal issues resulting.

Naturally, [Will Prowse] had to address this most recent statement by Battle Born, with the latter taking care to indirectly attack and dismiss his findings. Here Battle Born’s argument seems to hinge on the removal of the lid damaging this aluminium-oxide layer and preventing the ‘thermal safety’ from working, yet not addressed are the many batteries that failed in the field and showed loose connections due to thermal creep from the ABS layer.

It’s also never addressed why these LFP batteries cannot simply be equipped with a traditional thermal fuse rather than this convoluted contraption, among many other questions that remain. Correspondingly [Will] is rather incredulous at this response, as should anyone be who has been following this saga.