xiphmont: (Default)

I'm about to get an official press release together, but in the meantime, I'm pleased to announce we've released Opus 1.2!

Quoting Jean-Marc Valin, the Opus lead developer:

Opus gets another major upgrade with the release of version 1.2. This release brings quality improvements to both speech and music, while remaining fully compatible with RFC 6716. There are also optimizations, new options, as well as many bug fixes. This Opus 1.2 demo describes a few of the upgrades that users and implementers will care about the most. You can download the code from the Opus website.

xiphmont: (Default)

I'll guess I'm not the first person to make that joke.

I'll be back to working on the laser cutter soon. I really don't want this project to hit second anniversary before it's functional...

xiphmont: (Default)

It tries so hard to look like an Olympus SZ series, but no.... not quite.

It's not actually terrible, it's fairly decent. But it's not the real thing either.

xiphmont: (Default)

Packaging of the Chinese backlight kits I used to order tended to be... disappointing. Parts arrived broken on a regular basis, and there was never any moisture or static protection.

As a result, I put a little effort into my packaging.

With a paper cutter and an impulse sealer, it's easy to make moisture and ESD-proof bags of any size. The little table around the sealer was a quick afternoon toss-together made of MDF and a quick layer of paint. It locks into the lip along the bottom.

And of course, I make my own boxes! ThinkPad modders have taken to calling them Toblerones, which is kind of obvious, really.

xiphmont: (Default)

The ThinkPad LED backlight kits consist of two major pieces; an LED strip and an LED driver. The driver boards are designed to fit onto existing CCFL inverter boards after removing the CCFL step-up coil.

For good measure, I pull off the CCFL driver chip as well. Simply disabling it doesn't keep it from drawing a [very small] amount of current.

Removing the driver chip also opens up additional possibilities for reusing traces on the existing PCB. I don't like running long wires across the width of the inverter when hooking up the LED driver board. They'd need to be glued down to avoid accidental snagging, and that's a complication I don't need.

Instead, I re-route power, ground and the ENA and DIM signals through the original board, using solder bridges and 0-ohm bridge resistors where possible. On most boards, one or two jumpers are still needed, though a few boards I can get away without using any.

This work is most definitely all done under the microscope.

That also reminds me-- I need to get my library of reference modification pictures up somewhere.

xiphmont: (Default)

The first step is admitting you have a problem...

The problem being, specifically, that this stuff does not come in gallon cans.

xiphmont: (Default)

The LED strips are the big reason I still pick-and-place everything by hand. My tolerances here are just a few mils, and I've machined myself steel-and-aluminum templates to make the placement easier.

The idea is actually to place with looser tolerances, dropping the LEDs into the trough where the strip is clamped the check spacing and orientation with the microscope before reflow.

During reflow I tighten the guides on the jig and level the LEDs using a little precision squeegee I made out of aluminum and high-temp silicone.

Once the strip cools, I can pull it out of the jig, remove excess solder beads under the microscope, check for obvious defects, test on a power supply, and wash down with flux remover. Then it's on to applying the teflon layer, soldering pigtails, an up-to-temperature burn-in and flex test, and finally packaging.

xiphmont: (Default)

Initial functional testing of the LED drivers is just to find obvious reflow defects, mostly solder-bridges and non-obvious tombstoning.

Read more... )

xiphmont: (Default)

I'm currently on rev 3 of my ThinkPad-specific LED retrofit driver boards. They fit into the space on a stock inverter freed up by removing the CCFL step-up coil.

I'm on pace to make about 200-300 kits this year, and I'm still making them all by hand. Solder paste applied using a pneumatic dropper, components placed using tweezers and stereo microscope, then reflowed using a hotplate (thus the little placement jigs with silicone handles).

more after the cut... )

xiphmont: (Default)

LEDs and LED strip PCBs are finally here!

So now it's time to catch up with the LED backlight kit orders, aka, I know where all my free time is going the next few weeks...

(Does anyone else still remember the Dunkin' "Time to make the donuts" commercials?)

Red Efts

Jun. 5th, 2017 03:43 am
xiphmont: (Default)

The property is currently crawling with these little guys. Camilla is finding them everywhere.

Soooooo cute!

xiphmont: (Default)

Last week, Fraunhofer and Thomson suspended their MP3 patent licensing program because the patents expired. We can finally welcome MP3 into the family of truly Free codecs!

Then came a press push calling MP3 dead. That's dumb. Fraunhofer is only calling MP3 dead to push unwary customers into 'upgrading' to AAC for which they can still charge patent fees.

This is a bit like the family pediatrician telling you that your perfectly healthy child in college is dead-- and solemnly suggesting you have another child immediately. Just to keep making money off of you.

I would call that disingenuous at best.

No, MP3 isn't dead, and it's not pining for any fjords. The money that Thomson and Fraunhofer were previously collecting in patent royalties now stays in your (and everyone else's) bottom line. Don't license something new and unnecessary just to spend more money.

If you really do need something more advanced than MP3, the best alternatives are also open and royalty-free. Vorbis is the mature alternative with 20 years of wide deployment under its belt. Better yet, consider Opus, the world's most advanced officially standardized codec.

That said, the network effects that have kept MP3 dominant for so long just got stronger. Nothing beats its level of interoperability and support. There's no reason to jump off a thoroughbred that’s still increasing its lead.

xiphmont: (Default)

First, the big if belated news: I'm now selling complete kits for T-series machines from the T20 through T500, as well as the W500. Oh, and let's not forget the T70. I do need to update the kits webpage to reflect all the new models.

This adds to the X-series kits I already offer for the X20 through the CCFL versions of the X200. And yes, the X62 as well.

That said, I'm waiting on an order of LEDs from Nichia. My most recent order collided badly with the beginning of Golden Week, so the arrival ETA is around May 30th. I won't be able to build new kits until then, and the buyers queue is currently about a week deep.

xiphmont: (Default)

Seriously, there are so many winners on the full list I don't even know where to start.

xiphmont: (Default)

Another post I meant to make a while ago... George, my Tiniest of Tinies, has taken a liking to lasers and mirrors.

eBay and Amazon advertise a number of little Chinese 'optics experiments' kits with a laser line source that makes three parallel beams, a number of partially frosted lenses, prisms and mirrors, and a few other fun things. There's no English version but it looked like a good gift anyway.

Using Google's realtime image translate and no knowledge of technical Chinese whatsoever, I cobbled together a partly translated box and a translated instruction manual. Unless the original Chinese was quite subtle, I don't think there was actually a ton of useful content there, but hey.

In any case, here's scans: My English translation, and the original Chinese pages (in the event someone would like to improve on my atrocious hack job). Given the Amazon comments, I expect a few others may be interested :-)

(Empire of the Lasers has nothing to do with the original Chinese. It's a silly take on George's usual gaming handle.)

xiphmont: (Default)

At the moment, the result is "the only reasonable way for a member of the public to post to their Google+ profile is via the web-facing interface". Well, Sort of. OK, not really.

There's a ton of what looks like undocumented/exposed API surface for getting to Google+ through the OAuth2 interfaces, but it's reasonably well locked down with white-listing as per documentation. I can see and access posting calls, but all return 403 or 405. The Google+ Domains interface, naturally, only works on GSuite/GApp profiles. In short, after some light probing with a stick, it's all pretty much exactly as documented.

I can use the 'share' URLs, but those require an SID, which requires a browser and user interaction. Snagging and reusing an SID works, but they time out in six months. That's not really acceptable. Storing a Gmail username and password in cleartext on a remote server would be far far super-balls even worse.

And then I noticed that Buffer implements an OAuth2-facing programmatic post interface that happily forwards to Google+ without mangling anything. Their API is exactly what I wanted. And the documentation was even good. Like really good.

Well, foo. That kind of took the wind out of my sails. Someone did all the work for me, exactly like I'd have done it, after all.

So I actually get exactly what I wanted, even if it's slightly Rube Goldberg-y. No idea how long it will last, but I suspect that if things break it's more likely to be changes to Google+ than something at Buffer.

xiphmont: (Default)

It turns out forwarding posts to Google+ is a royal pain in the patookas, mainly because it's intended to be.

One small omission in all the Google documentation about programmatic access to Google+ streams is that, although there appear to APIs for doing this, eg, through plusDomains, none of them will work because write access to Google+ accounts tied to a Gmail address is 403 forbidden. The main Plus API is read-only.

And this probably isn't going to change. Google development is on record stating that they want to keep 'low quality' posts to a minimum on Plus, so there is no programmatic way to interact with it. Paraphrasing Google, 'even if a user only has to click on a Javascript 'Share' button, that level of interaction raises the bar.'

More about that Share button in a bit.

It's easy to say 'I don't believe that rationale' given that access is protected by OAuth2, and every third-party interaction must be explicitly approved by the user (as an aside, this is also algorithmically annoying, since all the approved ways of doing so are effectively browser-based interactions. It is difficult to ask for pre-authorization or authorization on the command line. There's no 'here's a pair of keys with secrets, have fun' like in Oauth1). In any case, if you wanted to access Google+ with your own app, there's a laborious multi-step web setup with 'enable this and click that and provide all your personal details' to make it work. It's locked down so tight, it's a wonder anyone bothers to use it.

Or is it? It looks hard from the developer and administrator standpoint, but if I maliciously targeted a user, all they'd see is e.g. 'Google Docs wants permission to access your contacts', and surely no one would fall for that. So I'm actually willing to grant Google their point here.

But there's another consideration. I'm of the technical priesthood, and it really annoys me when developers try to apply rules meant to keep the rabble in line to me.

Anyway, there's that share button.

It's run by several pages of densely packed and obfuscated javascript. It's always possible to pick that sort of thing apart slowly, but the easy chink in the obfuscation is that it has to communicate with the outside world somehow, and we can watch the requests and responses. We know it probably uses either Oauth2 or session cookies, and it's likely using unsigned and unobfuscated data within the TLS stream. It might even still be XHR-based like it was a few years ago, the last time someone decided to write a third-party Google+ API with write access.

Any success will be relatively temporary; there is no published API, so Google can change the internals whenever they want, and they do. There are a couple old third-party Google+ API libs, and they no longer work. But I think I'm going to play with it anyway. I mean, I already have this lovely little OpenGraph card generator...

xiphmont: (Default)

It's all bolted into my personal crontab, and watching my RSS feed. Now let's see if it properly makes a twittercard and gets it into my timeline.

If it works... Google+ is next.

If it doesn't... well, some more debugging is next. After work.

xiphmont: (Default)

I noticed Dreamwidth injects a comment counter and image into the RSS feed, which is great for RSS readers and kinda sucks if you're using the RSS feed to crosspost to other sites via something like IFTTT.

So I *think* I've got things set up now to have Motherfish at xiph.org poll the RSS, filter the injected content out, and then offer that to IFTTT. I suppose I'll find out real soon now if that's actually working :-)


xiphmont: (Default)


RSS Atom

Most Popular Tags