Category Archives: Hacking

3D-Printed Parts Torture-Tested in Nitro Engine — Briefly

Additive manufacturing has come a long way in a short time, and the parts you can turn out with some high-end 3D-printers rival machined metal in terms of durability. But consumer-grade technology generally lags the good stuff, so there’s no way you can 3D-print internal combustion engine parts on a run of the mill printer yet, right?

As it turns out, you can at least 3D-print connecting rods, if both the engine and your expectations are scaled appropriately. [JohnnyQ90] loves his miniature nitro engines, which we’ve seen him use to power both a rotary tool and a hand drill before. So taking apart a perfectly good engine and replacing the aluminum connecting rod with a PETG print was a little surprising. The design process was dead easy with such a simple part, and the print seemed like a reasonable facsimile of the original when laid side-by-side. But there were obvious differences, like the press-fit bronze bearings and oil ports in the crank and wrist ends of the original part, not to mention the even thickness along the plastic part instead of the relief along the shaft in the prototype.

Nonetheless, the rod was fitted into an engine with a clear plastic cover that lets us observe the spinning bits right up to the inevitable moment of failure, which you can see in the video below. To us it looks like failing to neck down the shaft of the rod was probably not a great idea, but the main failure mode was the bearings, or lack thereof. Still, we were surprised how long the part lasted, and we can’t help but wonder how a composite connecting rod would perform.

Still in the mood to see how plastic performs in two-stroke engines? Break out the JB Weld.

from Blog – Hackaday http://ift.tt/2opDVgx
via IFTTT

Skull Cane Proves Bondo Isn’t Just for Dents

[Eric Strebel] is quickly becoming a favorite here at Hackaday. He’s got a fantastic knack for turning everyday objects into something awesome, and he’s kind of enough to document his builds for the viewing pleasure of hackers and makers everywhere. It also doesn’t hurt that his voice and narration style gives us a real Bob Ross vibe.

The latest “Happy Accident” out of his workshop is a neat light-up cane made from a ceramic skull found at a local store. But while the finished cane itself might not be terribly exciting, the construction methods demonstrated by [Eric] are well worth the price of admission. Rather than using Bondo like the filler we’re all accustomed to, he shows how it can be used to rapidly build free-form structures and components.

After building up layers of Bondo, he uses a cheese grater to smooth out the rough surface and a hobby knife to clean up the edges. According to [Eric], one of the benefits of working with Bondo like this is that it’s very easy to shape and manipulate before it fully hardens; allowing you to really make things up as you go.

[Eric] also shares a little secret about how he makes his gray Bondo: he mixes some of the toner from a laser printer cartridge into it. This allows you to very cheaply augment the color of the filler, and is definitely something to file away for future reference.

If the video below leaves you hungry for more [Eric Strebel], check out his fantastic series on working with foam core, which should lead you right down the rabbit hole to his DIY foam core spray painting booth.

from Blog – Hackaday http://ift.tt/2EM5Mmb
via IFTTT

QuickBASIC Lives On with QB64

When I got my first computer, a second hand 386 running MS-DOS 6.22, I didn’t have an Internet connection. But I did have QuickBASIC installed and a stack of programming magazines the local library was throwing out, so I had plenty to keep myself busy. At the time, I thought QuickBASIC was more or less indistinguishable from magic. I could write simple code and compile it into an .exe, put it on a floppy, and give it to somebody else to run on their own machine. It seemed too good to be true, how could this technology possibly be improved upon?

Of course, that was many years ago, and things are very different now. The programming languages du jour are worlds more capable than the plodding BASIC variants of the 80’s and 90’s. But still, when I found a floppy full of programs I wrote decades ago, I couldn’t help but wonder about getting them running again. With something like DOSBox I reasoned I should be able to install the QuickBASIC IDE and run them like I was back on my trusty 386.

Unfortunately, that was not to be. Maybe I’m just not well versed enough in DOSBox, but I couldn’t get the IDE to actually run any of the source code I pulled off the floppy. This was disappointing, but then it occured to me that modern BASIC interpreters are probably being developed in some corner of the Internet, and perhaps I could find a way to run my nearly 30 year old code without having to rely on 30 year old software to do it.

The QB64 Project

After searching around a bit, I found the very cool QB64 project. This is an open source QuickBASIC development environment that is not only completely compatible with existing programs, but adds in functions and capabilities that were unthinkable back on my 386. Displaying a PNG, loading TTF fonts, or playing an MP3 in the background can be accomplished with just one or two commands.

Such things were possible with the original QuickBASIC, but existed more in the realm of tech demos than anything else. Oh the games I could have made back in the day with software like this! I had to be content with bleeps and bloops, and even that required you to figure out the timing for the tones yourself.

Even better, QB64 is cross-platform and supports compiling into native binaries for Linux, Windows, and Mac OS. That meant that not only could I run my old code within the IDE, but I could actually compile it into a binary for my Linux desktop. I don’t own a Windows computer anymore, but with WINE I was able to run the Windows version of QB64 and compile an .exe that I could give to my friends who are still living in the dark ages.

You can even use QB64 to compile QuickBasic code into an Android application, though there’s considerable hoops to jump through and it currently only works on Windows.

Conjuring Black Magic

This might be lost on those who never wrote BASIC code on a vintage machine, but the following code creates a 800×600 screen, puts a full screen PNG up, plays an MP3, and writes a message using a TrueType font.

' Init screen
SCREEN _NEWIMAGE(800, 600, 32)

' Load files
menubg& = _LOADIMAGE("splash.png")
menufont& = _LOADFONT("font.ttf", 30)
theme& = _SNDOPEN("theme.mp3", "SYNC,VOL")

' Set theme volume, start playing
_SNDVOL theme&, 0.3
_SNDPLAY theme&

' Load font
_FONT menufont&

' Show full screen image
_PUTIMAGE (0, 0), menubg&

' Say hello
PRINT "Hello Hackaday!"

As a comparison, this QuickBasic tool for simply displaying a JPEG image clocks in at 653 lines of code.

Revisiting a Project

In my edgy teenage days, I created a graphical version of the “Drugwars” style game. You moved a little stick man around a pixelated environment, buying and selling substances that I had heard about in movies but certainly had never seen in person. It was terrible. But it was part of my youth and I thought it would be fun to see if I could shoehorn in some modern flash using QB64.

As it turns out, transparent PNGs and the ability to display proper fonts makes things a lot easier. Being able to play music and ambient sound effects in the background makes even sloppily done games seem a lot better. The following screenshots are of the main menu of my little teenage crime fantasy, before and after the application of QB64. Note that the core source code itself is more or less the same, I’m just interleaving it with the ability to load and display external files.


Should You Be Using QuickBasic?

No, you definitely should not. I didn’t write this to try and convince anyone to jump on a programming language that peaked before many of our readers were even born. QuickBASIC is an antiquated language, stuck with outdated methods and limitations that are confounding to the modern programmer. But QB64 does do an excellent job of modernizing this classic language, if only to a relatively small degree in the grand scheme of things, for those of us who cut our teeth on it.

Being able to take a disk with BASIC code I wrote on a DOS 386 in the early 90’s and turn it into a Linux binary in 2018 is a pretty neat accomplishment, and I salute the QB64 development team for making it possible. I won’t be writing any new code in the language, and I don’t suggest you do either, but it was a lot of fun being able to revisit this period in my life and drag it kicking and screaming into the modern era.

from Blog – Hackaday http://ift.tt/2otiUlk
via IFTTT

France Proposes Software Security Liability For Manufacturers, Open Source As Support Ends

It sometimes seems as though barely a week can go by without yet another major software-related hardware vulnerability story. As manufacturers grapple with the demands of no longer building simple appliances but instead supplying them containing software that may expose itself to the world over the Internet, we see devices shipped with insecure firmware and little care for its support or updating after the sale.

The French government have a proposal to address this problem that may be of interest to our community, to make manufacturers liable for the security of a product while it is on the market, and with the possibility of requiring its software to be made open-source at end-of-life. In the first instance it can only be a good thing for device security to be put at the top of a manufacturer’s agenda, and in the second the ready availability of source code would present reverse engineers with a bonanza.

It’s worth making the point that this is a strategy document, what it contains are only proposals and not laws. As a 166 page French-language PDF it’s a long read for any Francophones among you and contains many other aspects of the French take on cybersecurity. But it’s important, because it shows the likely direction that France intends to take on this issue within the EU. At an EU level this could then represent a globally significant move that would affect products sold far and wide.

What do we expect to happen in reality though? It would be nice to think that security holes in consumer devices would be neutralised overnight and then we’d have source code for a load of devices, but we’d reluctantly have to say we’ll believe it when we see it. It is more likely that manufacturers will fight it tooth and nail, and given some recent stories about devices being bricked by software updates at the end of support we could even see many of them willingly consigning their products to the e-waste bins rather than complying. We’d love to be proven wrong, but perhaps we’re too used to such stories. Either way this will be an interesting story to watch, and we’ll keep you posted.

Merci beaucoup [Sebastien] for the invaluable French-language help.

French flag: Wox-globe-trotter [Public domain].

from Blog – Hackaday http://ift.tt/2HCT1Il
via IFTTT

Mechanisms: Mechanical Seals

On the face of it, keeping fluids contained seems like a simple job. Your fridge alone probably has a dozen or more trivial examples of liquids being successfully kept where they belong, whether it’s the plastic lid on last night’s leftovers or the top on the jug of milk. But deeper down in the bowels of the fridge, like inside the compressor or where the water line for the icemaker is attached, are more complex and interesting mechanisms for keeping fluids contained. That’s the job of seals, the next topic in our series on mechanisms.

Packing it In

One of the simplest seals is packing, or compressing some sort of flexible material into a space to control the flow of a fluid. Packing probably dates to at least the time when humans began making boats more complicated than a simple dugout canoe, in response to the fact that it’s really difficult to keep water from leaking between two pieces of wood. Ship seams have been caulked with fibers like hemp and cotton soaked in pitch or tar for millennia.

Marine propeller shaft stuffing box. The gland compresses the seals against the shaft, controlling water flow into the bilge. Source: Engineman 1 & C

A more complex seal, in the form of a stuffing box around the tiller post of an inboard rudder, extended the concept of caulking into a more dynamic environment. A tiller post is a vertical shaft that penetrates the bottom hull of a vessel and connects the submerged rudder to a tiller or other steering gear. To staunch the flow of water through such a gaping wound, a stuffing box was built inside the hull around the shaft and packed full of old rope fibers, rags, bits of sailcloth — anything fibrous and compressible. Soaked with tallow or fat for lubrication and water repellency, the stuffing was compressed with a gland around the shaft that was tightened down under screw pressure or using wedges. Stuffing boxes are still used to this day for all kinds of shafts that penetrate a vessel’s hull, including where the propeller shaft exits the stern, in which case the assembly is called a stern gland.

Maritime tradition has stuck with compression packing. While far from perfect, compression packing seals are cheap and easy to engineer, and so still see service to this day. Compression seals are used in water pumps and as a seal around the pump shaft to keep the process fluid controlled. While the materials used have come a long way, with highly engineered Teflon and graphite packing replacing hemp and lard, the basic technique is still the same — squeeze the packing as tightly as possible around the shaft to make it hard for fluid to penetrate. Hard, but not impossible — compression packing always leaks to some degree. Packed joints therefore require constant maintenance, including frequent tightening of the gland to maintain compression and eventually replacement of the old packing with fresh material.

Sealing the Deal

Ongoing maintenance costs and the tendency of compression packing to wear out the shaft they are wrapped so tightly around are two of the biggest drawbacks to these seals, and so other types of seals for rotating shafts were invented. Your car engine has a ton of seals, but the ones that can cause you to have a really bad day when a mechanic tells you you’ve “blown a seal” are the crankshaft seals. There are usually two, one where the crankshaft exits the crankcase at the rear to connect to the transmission, and one at the front where the crank pulley that runs the water pump, alternator, and other engine accessories exits. Seals are needed around the crankshaft because the crankcase is full of oil; the seals keep the oil inside the engine while allowing the crankshaft to rotate and run the car.

Crankshaft oil seals are known as radial shaft seals or lip seals, where a flexible material is formed into a ring that fills a space between the stationary part (the crankcase in our example) and a rotating shaft (the crankshaft journal). Like compression packing materials, lip seals were once made from natural substances like leather, but today elastomeric substances like Viton and Buna N are used. Most modern oil seals are composite mechanisms, too, with the elastomer bonded to a metal case that can be pressed into a recess in a crankshaft in an interference fit.

Typical radial seal. Note the difference in lip angle between the wet and dry sides. Source: SKF

Radial shaft seals seem simple enough, but there are several critical factors in designing a seal that’ll work. Aside from choices like material compatibility with the process fluids and heat ratings, the geometry of the flexible lip is crucial to the design. Looked at in cross-section, the lip forms a triangular profile with the apex touching the shaft at a single contact point. The angle of the lip on the wet side of the seal must be steeper than the angle on the dry side, so that hydraulic pressure from the process fluid (oil in our crankshaft example) tends to force the seal tighter around the shaft. Process fluid pressure is a major consideration as well — too much and the lip can deform enough to increase the contact area, causing premature wear and failure. That’s why we’re warned that too much oil in an engine can be just as bad as too little — more volume means more pressure, leading to the classic “blown seal” symptom of leaking from either the front or rear of the engine.

For viscous process fluids like grease, a plain elastomeric lip seal might suffice. But thinner fluids generally need extra circumferential force to help keep the lip in firm contact with the shaft. Such seals are likely to incorporate a garter spring into the lip to preload the seal on the shaft and to help make up for any irregularities in the shaft. Garter springs also help compensate for any radial oscillations of a shaft.

We’ve only touched on a few of the hundreds of types of seals for both dynamic and static applications here. The engineering behind them is pretty interesting, though, especially when you realize that it all started with a box of greasy rags.

Featured image source: American High Performance Seals

from Blog – Hackaday http://ift.tt/2EJkE0s
via IFTTT

OBD-Sniffing A Caddy PHEV

The Cadillac ELR is a plug-in hybrid car with a bit of class, it has the beating heart of a Chevy Volt in a nice coupé body with some up-market styling and a nice interior. Since it wasn’t on the market for long and some consumers are still wary of cars with electric motors, it also represents something of a sweet spot: according to [Andrew Rossignol] you can pick them up for less outlay than you might imagine. He bought one, and being an inquisitive soul decided to probe its secrets through its OBD-II ports.

OBD-II sniffing is nothing especially new, but his write-up provides an interesting run-down of the methodology used to identify the different proprietary pieces of data that it makes available. His Python script attempted to parse the stream as though it were multi-byte words of different lengths, plotting its results as graphs, It was then a straightforward process of identifying the graphs by eye that contained useful data and rejecting those that were obviously garbage. He was able to pick out the figures in which he was interested, and write an interface for his little Sony VAIO UX to display them on the move.

We’ve covered OBD hacks too numerous to mention over the years, but perhaps you’d like to read our history of the standard.

from Blog – Hackaday http://ift.tt/2EIXOG9
via IFTTT

At 71,572 KM, You Won’t Beat This LoRa Record

A distance record for LoRa transmission has been set that you probably won’t be able to beat. Pack up your gear and go home, nothing more to achieve here. At a superficial reading having a figure of 71,572 km (44,473 miles) seems an impossible figure for one of the little LoRa radio modules many of us have hooked up to our microcontrollers, but the story isn’t quite what you’d expect and contains within it some extremely interesting use of technology.

So the folks at Outernet have sent data over LoRa for that incredible distance, but they did so not through the little ISM band modules we’re used to but over a suitably powerful Ku-band uplink to a geostationary satellite. They are also not using the LoRaWAN protocols of the earthbound systems, but simply the LoRa modulation scheme. So it’s not directly comparable to terrestrial records such as the 702 km we reported on last year, and they are the first to admit that.

Where their achievement becomes especially interesting though is in their choice of receiver. We are all used to Ku-band receivers, you may even have one on your house somewhere for satellite TV. It will probably involve a parabolic dish with a narrow beam width and an LNB whose horn antenna is placed at its focus. It would have required some skill and effort to set up, because it has to be pointed very carefully at the satellite’s position in the sky. Outernet’s mission of delivering an information service with the lowest possible barrier to entry precludes the extra expense of shipping a dish and providing trained staff to align it, so they take a very different approach. Their receiver uses either an LNB horn or a small patch antenna pointing at the satellite, with none of the dishes or phased arrays you might be used to in a Ku-band installation.

You might wonder how such a receiver could possibly work with such a meagre antenna, but the secret lies in LoRa’s relatively tiny bandwidth as well as the resistance to co-channel interference that is a built-in feature of the LoRa modulation scheme. Even though the receiver will be illuminated by multiple satellites at once it is able to retrieve the signal and achieve a 30 kb/s data rate that they hope with technical refinements to increase to 100 kb/s. This rate will be enough over which to push an SD video stream to name just one of the several examples of the type of content they hope to deliver.

It’s likely that the average Hackaday reader will not be hiring satellite uplink time upon which to place their LoRa traffic. But this story does provide a demonstration of LoRa’s impressive capabilities, and will make us look upon our humble LNBs with new eyes.

Via ABOpen.

from Blog – Hackaday http://ift.tt/2BGRf8G
via IFTTT