The simplest way to look for meteors is to go outside at night and look up — but it’s not terribly effective. Fortunately, there’s a better way: radio. With a software-defined radio and a little know-how from [Tech Minds], you can easily find them, as you can see in the video below.
This uses the UK meteor beacon we’ve looked at before. The beacon pushes an RF signal out so you can read the reflections from meteors. If you are too far from the beacon, you may need a special antenna or you might have to find another beacon altogether. We know of the Graves radar in France and we have to wonder if you couldn’t use some commercial transmitter with a little experimentation.
[Tech Minds] has some practical tips to share if you want to try doing it yourself. If you want to see what a detected meteor looks like, you can visit the UK beacon’s gallery page.
We saw another presentation on the UK beacon earlier this year. Using commercial transmitters sounds like it might be easy, but apparently, it isn’t.
Some professional coders are absolutely adamant that learning to program in assembly language in these modern times is simply a waste of time, and this post is not for them. This is for the rest of us, who still think there is value in knowing at a low level what is going on, a deeper appreciation can be developed. [Philippe Gaultier] was certainly in this latter camp and figured the best way to learn was to work on a substantial project.
Now, there are some valid reasons to write directly in assembler; for example hand-crafting unusual code sequences for creating software exploits would be hindered by an optimising compiler. Creating code optimised for speed and size is unlikely to be among those reasons, as doing a better job than a modern compiler would be a considerable challenge. Some folks would follow the tried and trusted route and work towards getting a “hello world!” output to the console or a serial port, but not [Philippe]. This project aimed to get a full-custom GUI application running as a client to the X11 server running atop Linux, but the theory should be good for any *nix OS.
Hello World! In X11!
The first part of the process was to create a valid ELF executable that Linux would work with. Using nasm to assemble and the standard linker, only a few X86_64 instructions are needed to create a tiny executable that just exits cleanly. Next, we learn how to manipulate the stack in order to set up a non-trivial system call that sends some text to the system STDOUT.
To perform any GUI actions, we must remember that X11 is a network-orientated system, where our executable will be a client connected via a socket. In the simple case, we just connect the locally created socket to the server path for the local X server, which is just a matter of populating the sockaddr_un data structure on the stack and calling the connect() system call.
Now the connection is made, we can follow the usual X11 route of creating client ids, then allocating resources using them. Next, fonts are opened, and a graphical context is created to use it to create a window. Finally, after mapping the window, something will be visible to draw into with subsequent commands. X11 is a low-level GUI system, so there are quite a few steps to create even the most simple drawable object, but this also makes it quite simple to understand and thus quite suited to such a project.
We applaud [Phillip] for the fabulous documentation of this learning hack and can’t wait to see what’s next in store!
It is hard to imagine today, but there was a time when there were several competing network technologies. There was Ethernet, of course. But you could also find token ring, DEC Net, EcoNet, and ARCNet. If you’ve never dug into ARCNet, [Retrobytes] has a comprehensive history you can watch that will explain it all.
Like token ring, ARCNet used a token-passing scheme to allow each station on the network to take turns sending data. Unlike token ring and Ethernet, the hardware setup was much less expensive. Along the way, you get a brief history of the Intel 8008 CPU, which, arguably, started the personal computer revolution.
Like most networking products of the day, ARCNet was proprietary. However, by the late 1980s, open standards were the rage, and Ethernet took advantage. Up until Ethernet was able to ride on twisted pairs, however, it was more expensive and less flexible than ARCNet.
The standard used RG-62/U coax and either passive or active hubs in a star configuration. The coax could be up to 2,000 feet away, so very large networks were feasible. It was also possible to share the coax with analog videoconferencing.
Looking back, ARCNet had a lot to recommend it, but we know that Ethernet would win the day. But [Retrobytes] explains what happened and why.
Ignoring all of the regulations, band allocations, and “best amateur practices,” there’s no real fundamental difference between the frequencies allocated to the Family Radio Service (FRS), the General Mobile Radio Service (GMRS), the Multi-Use Radio Service (MURS), and the two-meter and 70-centimeter bands allocated to licensed ham radio operators. The radio waves propagate over relatively short distances, don’t typically experience any skip, and are used for similar activities. The only major difference between these (at least in the Americas or ITU region 2) is the licenses you must hold to operate on the specific bands. This means that even though radios are prohibited by rule from operating across these bands, it’s often not too difficult to find radios that will do it anyway.
[Greg], aka [K4HSM], was experimenting with a TIDRADIO H8 meant for GMRS, which in North America is a service used for short-range two-way communication. No exams are required, but a license is still needed. GMRS also allows for the use of repeaters, making it more effective than the unlicensed FRS. GMRS radios, this one included, often can receive or scan frequencies they can’t transmit on, but in this case, the limits on transmitting are fairly easy to circumvent. While it isn’t allowed when programming the radio over Bluetooth, [K4HSM] found that programming it from the keypad directly will allow transmitting on the ham bands and uses it to contact his local two-meter and 70-cm repeaters as a proof-of-concept.
The surprising thing about this isn’t so much that the radio is physically capable of operating this way. What’s surprising is that this takes basically no physical modifications at all, and as far as we can tell, that violates at least one FCC rule. Whether or not that rule makes any sense is up for debate, and it’s not likely the FCC will break down your door for doing this since they have bigger fish to fry, but we’d definitely caution that it’s not technically legal to operate this way.
In a world of 32-bit and 64-bit processors, it might surprise you to learn that Intel is releasing a 12-bit chip. Oh, wait, we mean 12-qubit. That makes more sense. Code named Tunnel Falls, the chip uses tiny silicon spin quantum bits, which Intel says are more advantageous than other schemes for encoding qubits. There’s a video about the device below.
It is a “research chip” and will be available to universities that might not be able to produce their own hardware. You probably aren’t going to find them listed on your favorite online reseller. Besides, the chip isn’t going to be usable on a breadboard. It is still going to take a lot of support to get it running.
Intel claims the silicon qubit technology is a million times smaller than other qubit types. The size is on the order of a device transistor — 50 nanometers square — simplifying things and allowing denser devices. In silicon spin qubits, information resides in the up or down spin of a single electron.
Of course, even Intel isn’t suggesting that 12 qubits are enough for a game-changing quantum computer, but you do have to start somewhere. This chip may enable more researchers to test the technology and will undoubtedly help Intel accelerate its research to the next step.
There is a lot of talk that silicon is the way to go for scalable quantum computing. It makes you wonder if there’s anything silicon can’t do? You can access today’s limited quantum computers in the proverbial cloud.
New angles and concepts in 3D printing are always welcome, and we haven’t seen anything quite like [Horn & Rhode]’s 3D prints that do not look anything like 3D prints, accomplished with an experimental tool called HueForge. The concept behind it is simple (though not easy), and the results can be striking when applied correctly.
3D prints that really don’t look 3D-printed.
The idea is this: colored, melted filament is, in a sense, not that different from colored paint. Both come in various colors, are applied in thin layers, and blend into new colors when they do so. When applied correctly, striking imagery can emerge. An example is shown here, but there are several more both on the HueForge project page as well as models on Printables.
Instead of the 3D printer producing a 3D object, the printer creates a (mostly) flat image similar in structure to a lithophane. But unlike a lithophane, these blend colors in clever and effective ways by printing extremely thin layers in highly precise ways.
Doing this effectively requires a software tool to plan the color changes and predict how the outcome will look. It all relies on the fact that even solid-color filaments are not actually completely opaque — not when printed at a layer height of 0.08 mm, anyway — and colors will, as a result, blend into one another when layered. That’s how a model like the one shown here can get away with only a few filament changes.
Of course, this process is far from being completely automated. Good results require a solid amount of manual effort, and the transmissivity of one’s particular filament choices plays a tremendous role in how colors will actually blend. That’s where the FilaScope comes in: a tool to more or less objectively measure how well (or how poorly) a given filament transmits light. The results plug into the HueForge software to better simulate results and plan filament changes.
Print result, showing results of filament blending.
Tilted to catch the light, giving an idea of how the print is structured.
When done well, it’s possible to create things that look nothing at all like what we have come to expect 3D-printed things to look. The cameo proof-of-concept model is available here if you’d like to try it for yourself, and there’s also an Aztec-style carving that gives a convincing illusion of depth.
[Horn & Rhode] point out that this concept is still searching for a right-sounding name. Front-lit lithophane? Reverse lithophane? Filament painting? Color-blended bas-relief? If you have a better idea, we urge you not to keep it to yourself because [Horn & Rhode] absolutely want to hear from you.
The world’s tech companies must harbour a hearty dislike for the European Union because when the many cogs of its bureaucracies turn, they find themselves with little choice but to follow or risk losing access to a huge and affluent market. There are a few areas of technology that don’t have some concessions to EU rules in their manufacturing process, and if a common charging connector or right to repair weren’t enough, they’re back for another clash with the mobile phone industry. If you hanker for the days of replaceable mobile phone batteries, you’re in luck because an EU Parliament vote has approved a set of rules covering batteries among which will be a requirement for replaceable cells in portable appliances.
We expect that the phone manufacturers will drag their feet just as some of them have over charger ports, but the greater ease of maintenance, as well as extra longevity for phones, can only be a good thing. There are a few other measures in the package, and one of them caught our eye, the introduction of a battery passport for larger industrial and EV batteries. There’s little more information in the press release, but we hope that it doesn’t inhibit their exploitation by people in our community when introduced.
