posts tagged with the keyword ‘fail’


Ethernet Tester

I should probably just submit this to Hackaday’s Fail of the Week because this is full of fail. I’m going to share it all anyway.

Sometimes at work we make our own Ethernet cables, and we usually test them by connecting them to computers, or whatever weird electronic thing we’ve built, and we hope they work. They usually do, but we don’t have a good way to test them. I know there are network cable testers but they are expensive. (Mistake #1, more on that later.)

I had some RJ45 8-Pin Connectors and some RJ45 Breakout Boards on hand that I never used so I came up with the “brilliant” idea of building a simple Ethernet Cable Tester. (Mistake #2.)

Ethernet Fail

The idea was that you could make an Ethernet cable, plug it in to each end, and then use a multimeter to check continuity by matching up the colored wires on each side. Simple, right? Right…

Ethernet Tester

I decided to use a piece of stripboard, which seemed perfect for this project. For whatever reason, my soldering skills went out the window. I swear I know how to solder, and I’m actually pretty good at it. Maybe it was just one of those nights where everything goes wrong. And when I tried to clean things up my solder sucker kept not working. Just, not working. Why? I don’t know!

Ethernet Tester

Oh, and you see those notches in the board? I had to Dremel those out because it was too difficult to press the little lever that releases the RJ45 connector. It was even worse with cables that had boots on them. (Mistake #3, or #4, I lost count.)

Ethernet Tester

There’s also a lot of hot glue on there. I was using that to hold the wires in place because it seemed like some didn’t take to the stripboard very well and I had to add more solder. Yes… more solder! (Mistake #4 or maybe #5.)

Ethernet Tester

Sure, more hot glue. This time to make the breakout boards stay level and not flex around when plugging in cables. This sort of worked, so it’s not terrible, but yeah… hot glue. Fine.

Ethernet Tester

So the good news is, it does work. I tested some cables. I didn’t have to build an expensive Ethernet Cable Tester. I was so proud of myself I decided to see how much money I saved the company.

Oh hey, look… I can find some cheap network cable testers on Amazon (with Prime!) for under $10. Aw, shit… I give up.


Sir Like-A-Lot

My latest project was sort of a failure, but I’m going to post about it anyway, because such things are important.

For a recent event I wanted to create a unique way for people to LIKE something, and get a reward for it, so I grabbed a Raspberry Pi and got to work. The idea was pretty simple, a full screen display showing the number of Facebook likes, with the URL for people to visit the page (on their mobile devices) and like it. The display would then update in “near” real-time (Well, every 10 seconds) and there would also be a surprise…

Step #1 is always configuring the Raspberry Pi. I installed Raspbian, had it set to boot to the desktop, and installed the packages I needed, mainly Apache and Chromium, since I’d be using a local web server and web browser for the display.

Getting the Raspberry Pi to work as a kiosk display was next. I didn’t want any menus or OS parts showing, so I used Chromium running in kiosk mode. My /etc/xdg/lxsession/LXDE/autostart file looked like this:

# config to launch Chromium in kiosk mode and load our application
@xset s off
@xset -dpms
@xset s noblank
@chromium --kiosk --incognito

We got rid of the part that lets a screensaver run, and added in the bits to fire up Chromium in full-screen kiosk mode. (Oh, one note about Kiosk mode, it does not hide the mouse pointer, but we’ll deal with that later.)


The results on the screen looked like this. Full screen, no browser or OS bits showing. I like this solution as it can be used for pretty much anything you can code up as a web page.

The display is set to refresh every 10 seconds, so it’s pretty up-to-date, and you’re really only limited by what you can display in a browser (Chromium) running on Linux (on a Raspberry Pi, in this case.)

As for the code, it’s less than 50 lines of Perl running as a CGI, and about a dozen lines of HTML in an HTML::Template file. There’s also a little CSS and an image.

Speaking of the CSS, it was the solution to hiding the mouse pointer for Chromium running in kiosk mode. I just added this bit:

 * using CSS to hide the pointer
* { cursor: none !important }

For an informational kiosk you just want people to look at and not have to interact with using a mouse or keyboard, this solution works well.


You might be saying “Hey! How do you get the number of likes!?” Well, you just ask JSON, or to be more precise. Facebook Graph API data holds the key, you just need the value.

Oh, there was one more really fun bit! When someone liked the page and the page refreshed and the number increased, you’d hear applause!

The original idea was to just have the CGI do a system call to play the file using aplay. That did not work. I also tried mpg321 and that didn’t work. In the end I went the other way around and added… another Perl script! There’s a cron job that runs on startup, which launches a Perl script, which loops forever and looks at the counter file that the CGI uses. Every time the counter file changes (due to the CGI updating the number) the Perl script uses aplay to play the applause file.

The end result is pretty good. A person sees the display, goes to Facebook, likes the page, and within 10 seconds the display updates and you hear some applause!

I planned on making a sign or adding some text to entice people take action and get a “reward”. And of course the URL isn’t as helpful on a mobile device where you probably use an app instead of a browser, but this is all a good start.

Now, I mentioned a failure, so I should explain that part. For anything like this, where it needs to run for hours reliably and not just be a quick technology demo, you need some burn-in time. I had this running for a week with no issue. The first issue that came up was, what to do if you lose the Internet connection. (Hey, we use Time Warner, it happens!) You really don’t want to see a default Apache 500 error page, so the error page looked just like the main page, but with a message that said ‘Please stand by…”. That 500 page was set to redirect to the main page after 10 seconds, which would deal with occasional Internet or network outage situations. Since we were also using a WiFi connection with the Raspberry Pi, there’s always the chance of losing the WiFi connection. This didn’t seem to happen much, but it’s something you may need to deal with.

I also set Apache to not do any logging, as there’s really nothing valuable gained from logging after you’ve got everything running. It also helps to write less data to the SD card that holds the system because… corruption.

Oh yes, corruption! Every now and then I would reboot the system to make sure it would start up properly. It almost always did. Except when it didn’t. Once the Pi booted and there was a warning that the file system needed repair, so I repaired it, and all seemed well. I tested again for another week, and things seemed good. But then…

The day of the event, I had to move the system into place, and when I did that, and started it up, Linux would not boot. Even after 13 years I am still not enough of a Linux expert to fix every problem it throws at me, and I was stuck, and had a dozen other things to do, so it was dead.

I did the dozen other things and then ended up reinstalling Raspbian and trying to quickly reconfigure it, and get all my files in place, and got everything working except the audio… and the WiFi. There are a few tricks to getting audio working properly on the Raspberry Pi. I eventually got it working, but it was too late to deploy it. Oh well…

So next time, I will have a BACKUP SD card ready to put in place when the first one destroys itself. Or maybe I’ll just build two complete Raspberry Pi systems. Backups are good. Backups are good. Backups are good.

But don’t worry, I’ll take all the successful bits of this project and re-implement it in some other way in the future.



Oh Linux… sometimes you make it really hard to love you.

While the recent data rescue went well, other things have not been as easy. Let’s see where we are, shall we?

Home Server
This is the old dead-screen PowerBook that ran for years without issue. Until it had an issue. I rescued the data from it, and then I figured I would do a re-install of Linux on it, but so far it’s been all failure. The external VGA connection doesn’t seem to want to display anything, so without a screen to see the install, I don’t even know if it’s booting up properly. (This is a recurring theme, btw.)

Raspberry Pi
One of my Raspberry Pis occasionally hangs on boot. Sometimes. Other times it works fine. Since it’s headless I needed to attach it to a TV to see this. The other Raspberry Pi I have does have an HDMI-VGA adapter, which works when you edit config.txt properly. Sometimes. And yeah, my RF Modulator to use the composite video seems to have died, so that option was out as well. Also, the SD card cracked. These are all fairly minor things, but they add up.

(New) Xubuntu Laptop
While it’s a new machine to me, it’s a 10 year old laptop running Xubuntu. It was going to be (will be?) my new Lab Computer, controlling the RepRap, and hopefully running Octoprint, which won’t run on the Eee PC I now use to control the RepRap. I left it running with my account logged in and it went offline… kernel panic. Hmmm, let me check right now. Yeah, it’s hosed up. I try to ssh in and get ‘Input/output error’ so something isn’t right. Dammit.

Eee PC
Well, this little beast keeps chugging along. Besides the fact that it can’t do much, it can control the RepRap, and it does a pretty good job of not losing the wifi connection. All good.

Another One
Since I may need a replacement for the old PowerBook that was the Home Server, I figured I’d try an old G4 iMac with a dead display. Multiple attempts with Ubuntu Server and Xubuntu Desktop all failed. Won’t boot from a CD or DVD. I did read about an NVIDIA driver conflict, urgh. I may try some other distros, but I’m thinking it may be an issue with the fact that the built-in display is dead and the external VGA connection isn’t doing the right thing. Bummer.

Keep in mind I’m considered really good at this stuff… but I guess when shit goes wrong, it really goes wrong.


Bad Dates

And people wonder why I complain so much about date formatting… (See Also: raster’s rants on 4-digit years.)

Take this example from Nikon’s web site, captured lovingly in the screen shot above.

If you’re in a hurry, and don’t have time to read everything (I hear that covers 75% of the people who use the Internet) you might need info on the D4 and see that it’s at the top of the list, and hey… looks like it was updated December 4, 2010! At least that may be your assumption by seeing 12/04/10.

You also need info on the D40, and you see 08/04/04 and think “Wow, it was last updated in 2004!” which is weird, because the D40 didn’t come out until 2006. (And yeah, the D4 wasn’t around in 2010 either.)

If you scan the whole column, you’ll see that first part of the date is the year, followed by the month, and then the day. While I do prefer year, month, day, I definitely prefer YYYY-MM-DD.

This isn’t 1975, you’re not saving vast amounts of computer memory by typing “08″ instead of “2008″ and all your really doing is creating opportunities for people to get confused.

Yes, I know people should actually read things in a critical fashion especially if it has to do with an SDK for hardware, but this is just one example of many.


Time Warner Fail

After repeated attempts to register, I concluded that Time Warner really doesn’t like my mail server, so I ended up using a Gmail address (which I didn’t want to do) and found the registration in the spam folder…

After a few failed login attempts, their system let me in, and I get this awesome “Try again later” message.

Keep up the good work Time Warner!

P.S. The Moxi kicks the Mystro’s ass.

« Older Entries |

buy the button:

Buy The Button