If there’s one bright spot on the blight that is this pandemic, it’s got to be all the extra time we’re spending with our pets. Dogs especially love that we’re home all the time and want to spend it playing, but sometimes you need to get stuff done. Why not head outside with your laptop and keep the dog happy with an automatic ball launcher?
All [Connor] has to do is drop the ball in the top, which you know is going to lead to training the dog to do it himself. A proximity sensor detects the ball and starts up a pair of 540 R/C motors, then a servo drops the ball down the internal chute. The motors spit the ball out with great force with a pair of profiled, 3D-printed wheels that are controlled by a Turnigy ESC and an Arduino Nano.
In the future, [Connor] plans to print a cover for the electronics and enlarge the funnel so it’s easier for the dog to drop in the ball. Check out the brief demo and build video after the break.
There’s a document I had to sign to wrap up a community responsibility in rural Oxfordshire. At the bottom, dotted lines for signature and date. My usual illegible scrawl for a signature, and scribble in the date below it. Then there’s the moment when the lady handling the form scans it with a puzzled face for a minute, before accepting it with a smile. She’s just been ISO’d!
I’m telling you, you’ve got Pi Day wrong. Evan Shelhamer, CC BY 2.0.
Where I come from in England, it’s the norm to represent dates in ascending order: day, month, year. Thus the 4th of March 2021 becomes 04/03/2021 when written down on a form. This is entirely logical, and makes complete sense given the way a date is said aloud in English and other languages.
Meanwhile in America it’s the norm to represent dates in a different manner: month, day, year. Thus March 4th, 2021 becomes 03/04/2021 when written down on a form. This is also entirely logical, and makes complete sense given the way dates are pronounced in American English.
As someone whose job entails crossing the Atlantic in linguistic terms, I am frequently confused and caught out by this amusing quirk of being divided by a common language. Is 03/04/2021 the 3rd of April or March 4th? “Why can’t Americans use a logical date format!” I cry as in a distant transatlantic echo I hear my friends over there bemoaning our annoying European ways. It’s doubtful that this divergence has caused any satellites to crash, but it sure can be annoying.
Confusing Everyone For Over Three Decades
So I took a stand. A couple of decades ago I adopted ISO 8601 in writing dates, an international standard that’s been with us for well over three decades. It too is an entirely logical way to express time, but unlike the two mentioned earlier it’s not tied to any linguistic quirks. Instead it starts with the largest unit and expresses a date or time in descending order, and extends beyond dates into time. Thus the date on my form that caused the puzzlement was 2021-03-04. I’m guessing that here at Hackaday I’m preaching to the choir as I certainly won’t be the only one here using ISO 8601 in my daily life, but while we’re talking about alternative date formats within our community it’s an opportunity to take stock of the situation.
UNIX time is probably the most instantly recognisable of all our measurement schemes, being a count of seconds elapsed since the Unix epoch of 1970-01-01T00:00:00+00:00 UTC. Coincidentally this is also an auspicious date for many readers, as it’s our birthday. If I’d written the 4th of March on that form as 1614816000 though I would have been met with complete incomprehension, so aside from the occasional moment of coming together to observe a rollover it’s not something we use outside coding.
But it does lead neatly to another question: since UNIX time is most often expressed in text as a base-10 number, why on earth does our clock time work in base 60 for seconds, base 12 or 24 for hours, and then base 12 for months? Why don’t we use a base 10 metric time system?
It makes sense for our annual calendar and the length of our day to be derived from Earth’s orbit, as we use dates as a measure of season and times as a measure of the daily progress rather than simply elapsed periods. We owe our twelve-hour days and nights to the ancient Greeks and our 60 seconds and minutes to the ancient Babylonians, while our twelve months come from the ancient Romans. It’s clear that a 365.24-day year with four seasons doesn’t divide neatly into ten months, so we’re at the mercy of our own set of celestial bodies when talking about dates. But surely we could move on from ancient Greece and Babylon when it comes to the time of day?
Liberté, Égalité, Ponctualité!
A 10-digit Revolutionary French clock. DeFacto, CC BY-SA 4.0
Probably the most famous attempt at a decimal calendar came in the aftermath of the French Revolution; the French Republican calendar perhaps wisely stuck with twelve months but made each of them of three 10-day weeks, and then split the day by 10 hours, with each further subdivision being by base 10. The months each had 30 days, with the remaining 5 days (or 6 in leap years) being public holidays.
It came to an official end when the revolutionary government that had introduced it was replaced by that of Napoleon. Unlike other French Republican measurements such as the meter, it evidently didn’t provide enough advantage for its popularity to outlive its political origins.
There’s an interesting parallel in the decimalisation of British currency in 1971. Previously, a pound was 20 shillings, each of which were 12 pence. Afterwards, a pound became 100 new pence, and that’s stuck. Despite some people’s lingering nostalgia for the old system, the utility of decimialisation was self-evident.
The moral of the French time-decimalization story was that people simply use a calendar and time system to tell the date and time. When you need to do frequent arithmetic, as is the case with currency, distance, or weights, this is made significantly easier through decimals. But when nature hands you four seasons, you’re pressed into twelve months. Perhaps when we slip the bonds of Earth, we’ll use decimal Stardates, but in the mean-time, ISO might just be the way to go.
MQA is an audio format that claims to use a unique “origami” algorithm, promising better quality and more musicality than other formats. At times, it’s been claimed to be a lossless format in so many words, and lauded by the streaming services that use it as the ultimate format for high-fidelity music. With the format being closed source and encoders not publicly available, these claims are hard to test. However, [GoldenSound] wasn’t born yesterday, and set out to test MQA by hook or by crook. The results were concerning. (Video, embedded below.)
To actually put the format through its paces, the only easy way available was to publish music to the Tidal streaming service, which uses the format. [GoldenSound] went this route, attempting to get some test files published. This hit a brick wall when the publishing company reported that the MQA software “would not encode the files”. The workaround? [GoldenSound] simply cut some audio test content into the middle of an acoustic track and resubmitted the files, where they were accepted without further complaint.
Testing with the content pulled from Tidal, [GoldenSound] found concerning evidence that the claims made around MQA don’t stack up. Significant amounts of added noise are often found in the MQA-processed files, and files served from Tidal are clearly not lossless. Additionally, MQA’s “blue light” authentication system, designed to guarantee to listeners that they’re listening to a identical-to-studio release, is demonstrated to be misleading at best, if not entirely fake.
Upon writing to MQA to get a response to his findings, [GoldenSound]’s test files were quickly stripped from Tidal. The company eventually disputed some of the findings, which is discussed in the video. The general upshot is that without open, transparent tools being made publicly available to analyse the format’s performance, it’s impossible to verify the company’s claims.
[Mansour Behabadi] wanted to harness the high power capability of USB-C using as simple a hardware design as possible. After some research and experimental prototyping, he designed the fpx — an easy to use USB‑C power delivery board. The fpx is an improved follow up to his earlier USB PD project fabpide2 which we featured some time back. However, practical implementation of the USB PD protocol can be a bed of thorns. Negotiating power delivery usually requires a dedicated PD controller coupled with a micro-controller for user control.
With USB PD, a USB-C port can be configured as either a source, a sink, or both and allows connected devices to negotiate up to 100 W (20 V, 5 A) of power. The fpx is based around the popular STUSB4500 PD controller, which does most of the PD heavy lifting. To program the STUSB4500, he used an ATtiny 816 micro-controller, whose UPDI programming and debugging interface consumes lower board real estate.
However, what’s a little bit different is the way the fpx is programmed — by sending binary black and white flashes from any device that can display a web page. Using light isn’t a particularly new way of programming. We’ve seen it used almost a decade back by WayneAndLayne for their Blinky PoV projects, and later by the Electric Imp’s BlinkUp app. The fpx uses a similar method to read flashes of light from a screen which are picked up by a photo-transistor connected to the ATtiny. The ATtiny then communicates with the STUSB4500 over I2C. This eliminates the requirement for special software or an IDE for programming and doesn’t need any physical cable connection. Check out [Mansour]’s blog post where he walks us through the details of how he managed to wrangle the optical programming challenge.
Many of the commercially available USB PD decoy/detector/trigger boards use either solder jumpers or a switch with an RGB LED to adjust Power Delivery Output (PDO). [Mansour]’s method may be a little more robust and reliable. The STUSB4500 can store two separate PDO values and can negotiate with a source according to its capability. If the source cannot offer either of these options, the fpx can either request for a minimal 5 V / 100 mA setting, or disable the output. The fpx is an open source project, accessible on Github. Check out the video after the break for an overview of the fpx.
This is a work in progress, and [Connor] plans to publish a BOM and the STL files once it’s all finished. For now, it’s a working prototype that shoots a ball into the air and about 25 feet away, from the looks of it. Far enough to be fun, but not so far that it goes over the fence.
