How noisy is my ATX power supply?

Like so many others, I have constructed a simple lab supply, mainly for 12v DC, from an old but usable ATX power supply. The instructions on how to do this are countless, and there’s really nothing very complicated about it. I thought I’d done fairly well when I was finished with it – it delivers far more power than any of the proper lab supplies at OSAA, and it was very, very cheap. Free, mostly.

As it turns out, there is a bit of noise on the output of one of these ATX supplies. I discovered this after working some hours on a design involving a MAX660CPA at OSAA, and in particular on eliminating the noise it produced. After succeeding, I came home only to discover that the noise had reappeared! And even spread to the +5v rail, not just the -5v. And the +12v rail… at which point I started considering that it might not be the MAX660.

Today I decided to do a quick measurement of the noise produced at idle from the power supply (the +5v and +3.3v rails are loaded by resistors inside the PSU to stabilize the outputs). All the following pics are quick snaps from my phone, at 50μs/div horizontal:

12v rail - 50mV/div vertical

5v rail - 10mV/div vertical

3.3v rail - 10mV/div vertical

To summarize:

  • 12v rail shows 50mV consistent ripple, and 200mV peak-to-peak spikes
  • 5v rail shows about 30mV consistent ripple, and about 60mV peak-to-peak spikes
  • 3.3v rail shows a very clear 20mV peak-to-peak square wave, and about 50mV peak-to-peak spikes

My guess is my next post is going to have to be on how to clean up these power outputs for the sort of work I want to do currently of measuring a few mV of change across a small resistor to calculate current. ;-)

Simple fan mod for Tektronix 2235

After repairing my Tektronix 2235 oscilloscope, I noticed that the heat sink cooling the MOSFET in the switching power supply, as well as the two transistors in the inverter circuit, was getting rather warm – and more than I liked it, anyway. I definitely didn’t fancy having to repair it all again, or getting something happen to it like the 2230 we looked at fixing – briefly – at OSAA.

So I decided to do a little mod, inspired by the service manual for a Tektronix 2236 – same scope with a counter/multimeter addon, and, crucially, a fan to cool the power supply. All the markings etc. were there on the circuit board of my scope, it just didn’t have any components installed.

To do the mod, you need:

  1. 270μF capacitor, 25v or summat. I used a 220μF low ESR one I had anyway.
  2. A 22 Ohm resistor, 1/4 watt
  3. A diode. I used a BYV 26C, 1A 600V switchmode-diode. This is absolutely overkill, but then again, I had one from when I fixed the power supply… It needs to rectify the -8.6V 20KHz from the transformer, and deliver enough power to run the fan, so possibly not a 1N4148..
  4. 60mm 12V fan – the one I used is 1.4W at 12V, and ends up running at -5.71V, slowly and quietly. The original specs call for using +5 instead of ground, giving about 10V total across the fan – but then it’ll be noisy.

The components are the 965 components on the circuit – they’re near all the caps for the low voltage supplies. CR965 is the diode, C965 is the capacitor and R965 is the resistor. And there’s even two pads for soldering in a connector for the fan.

Of course, this is all done at your own risk – I’ve yet to see if my scope blows up from this, though I doubt it. And it does mean I’ll be able to hear if it’s on or not, rather than having to wait for something to show up on the CRT … :-)

Notes on fixing a Tektronix 2235

A colleague found an old Tektronix 2235 in his shed, and thought nicely I might like to have it. Sadly, it blew its fuse after working for a few minutes when he plugged it in – and I decided to have a go at fixing it.

MOSFET P9070 had died a violent death, with notable effects on the MOLEX connector it’s in, as well as the plastic surround strapping it to the heat sink. It had killed R909 – the 39 ohm resistor between it and Q908, not on the schematic but in an addendum – Q908 and CR907 as well.

The MOSFET can be an IRF720 it seems, which is a nice and cheap component. Q908 I ended up using a 2N2907, which was slightly more difficult to come by. It’s just a PNP switching transistor, so might be easier to find something else that’ll stand the voltage.

The diode I first tried replacing with a 1N4007 – this didn’t turn out well. Another colleague found me a BYV 26E, 1000v/1a 75ns fast recovery diode, which works fine. However: After the first killing of the diode, it appears the MOSFET and transistor were taken out again, and I failed to notice. Caveat: Check these components every time a line power trial fails, as they may just be fried…

I ended up replacing U930 with a TL494 (about $1 for that) as well, and found a good way of testing it: Apply ~10v between TP940 and pin 12 of U930, and look for a sawtooth signal at pin 5.

Some of my testing I did with line voltage, but as mentioned before, I had problems with components dying on me. I ended up using a lab DC supply, set to between 25v and 50V, connected between TP950 and the upper leg of R926, so just after the rectifier. When connected this way, with a BAD MOSFET in place, output voltage could be seen at measuring points 42 and 43 – just after Q946/7 that is.

With a good MOSFET in place, the switch-mode circuit wouldn’t start (and P9070 not open) as the trigger voltage across VR925 does not rise high enough (at 50V DC supply) – shorting VR925 briefly opens Q930, and the supply starts running. I’m not entirely sure why this is necessary; I hope it will work just fine once I put in the proper 400v MOSFET and give it 240v AC …

Other observations: I disconnected the high-voltage wire to the voltage tripler, and taped up the end securely, while working on the prereg. This removed the nasty 2Kv from the board, but there’s still 100v around there, so don’t touch it … :-)

I changed a few capacitors, since I was changing components anyway, but it seems that the ones I pulled out of it – from 1985 – were just fine, and didn’t need replacement. Quality stuff.

Oracle released Beehive 2.0.1

Just a quick reminder, as much for myself as for my readers – Oracle has released Beehive 2.0.1, which I will be looking at in about two weeks, to see if it will be able to replace our current Collaboration Suite Calendar installation. Sadly, it still seems like Oracle insist that you must use their inferior email server to use the rest of the system.

New Android app: ICSReader

After having ranted quite a bit about the lack of support for standards-based calendars and PIM in Android, I decided to implement something myself, to at least get it to a level where an Android phone would be of use to me. Since we have a functioning iCalendar export from our Oracle Collaboration Suite calendar at work, I decided to start out writing a parser for that. ICSReader is the result.

The software does a bit more than just read iCalendar files by now, and since it’s reached the critical junction where I want to expand the functionality significantly, the time has come where it gets its very first version number: 0.1

The very first version, 0.1, has the following features:

  • Imports an ICS file into a local database from an HTTP URL
  • Display of current events (ongoing, as well as -10/+30 minutes)
  • Display of the events of the next 48 hours
  • Display of events on a day by day basis
  • Detail display for each event

More importantly, it lacks the following features:

  • Support for multiple iCalendar sources
  • Support for individual ICS files, for instance from emails (via Intents)
  • A week view
  • A month view
  • Notifications, alarms, participants, GPS integration, peace on earth, end to world hunger, etc. etc.

The observant reader will have noticed that I have yet to provide a link to this software. Currently, it’s only been built for Android 2.0, and while it may serve a purpose for some people in need of an iCalendar reader, it is not yet sufficiently polished for me to feel comfortable in publishing it. If you happen to need it, post a comment, and I might well reconsider and post a usable build. Otherwise, I am going to work towards a new version with at the least support for multiple iCalendar sources before releasing it.

Got some new features you really want in an Android calendar application? Post a comment, and I’ll have a look. :-)

Update: I released the app.

Creating a custom CursorAdapter for Android

I’ve been writing a bit more Android code, and came upon the need to write a custom CursorAdapter for a ListView, as the way I wanted to display data from a Cursor was dependent on relationships between different fields of the database.

Of the problems I encountered, the most obvious was when I tried to inflate views using View.inflate(), and found I would get the following error:

UnsupportedOperationException: addView(View, LayoutParams)
is not supported in AdapterView at android.widget.AdapterView

After a bit of rummaging around, I found that the following bit of code would work when attached to a ListView using setAdapter().

public class ExampleCursorAdapter extends CursorAdapter {
	public ExampleCursorAdapter(Context context, Cursor c) {
		super(context, c);
	}
 
	@Override
	public void bindView(View view, Context context, Cursor cursor) {
		TextView summary = (TextView)view.findViewById(R.id.summary);
		summary.setText(cursor.getString(
				cursor.getColumnIndex(ExampleDB.KEY_EXAMPLE_SUMMARY)));
	}
 
	@Override
	public View newView(Context context, Cursor cursor, ViewGroup parent) {
		LayoutInflater inflater = LayoutInflater.from(context);
		View v = inflater.inflate(R.layout.item, parent, false);
		bindView(v, context, cursor);
		return v;
	}
}

The above example code doesn’t actually require a CursorAdapter, it would easily be implemented using a SimpleCursorAdapter, but it serves to show the idea. Basicly, get a LayoutInflater from the context, and use the version of inflate() that does not attach to the root view.

Writing Parcelable classes for Android

I’ve just released version 0.3 of Xydroid, my small Xymon monitoring app. It should now be a bit more suited to Android 2.0, and have just a couple fewer bugs in it.

As it turns out, the main problem with running under Android 2.0 for my app was de-parceling of a Parcelable representation of the XML files used by Xydroid. Up until now, I had just written out all the data in the tree when parceling, and read until no data was left when de-parceling. As it turns out, if this parcelable class is put into a bundle with other data, such as strings or integers, the de-parceling code will just continue reading along the bundle. The error I tended to encounter would be “Unmarshalling unknown type code 6946932″ (or some other number), presumably as I tried to read a String from where an integer existed or similar.

The solution seems to be to write how much data you are planning to parcel as the first bit of information, and only read back this many chunks before passing control back. This works both in 2.0 and 1.5/1.6, whereas reading until there was no more data seemed to work in 1.5/1.6 but not 2.0 — though this might just have been pure luck.

Update: I thought I had better actually show how I ended up implementing my Parcelable classes, so here is a quick example of how to wrap a HashMap in something parcelable:
Continue reading

New SDK means strange new bugs

When I noticed the Android 2.0 software development kit had been launched, I hurried up and installed it. Okay, it did take the better part of 5 hours before it was properly installed, as Google’s servers were probably overloaded. None the less, I managed it at least, and fired up an Android 2.0 emulator, taking a moment to marvel at the fancy new settings that have been added for creating AVDs, before hurrying on to install my app, Xydroid.

As usual, it exhibited the crash right at first time start, probably as both the main thread and the update thread try to create the database, and they step on each others toes. I’ll be sure to get that fixed any day now. Somehow.

There’s also a new crash, though — this one is right after adding a new source, where the app tries to launch an activity that lets the user select the services to monitor. This gets a runtime error with a null pointer exception, whereas launching the activity separately, after the source has been added works fine. This could be a change in the way bundles between activities are handled in Android 2.0 versus 1.6.

I will probably have to get my act together and release a version 0.3 with these couple of bugs fixed, as well as plenty of testing done for differing screen sizes. One of the great advantages of Android can be said to be the number of different devices you can use it on — and it’s one of the major drawbacks as well, as there will always be a lot of different things to consider when designing the user interface. I do still prefer it over the iPhone, though :-)

What are Google going to do about PIM? Well, more…

A short while ago, I asked what Google were going to do with PIM in Android. Now it seems there’s an answer, or at least part of it, in the release of the Android 2.0 SDK: They’re going to support third party adapters.

The nice people at Engadget have a summary of some of the changes, and among them one can find:

  • Third-party “sync adapters” allow apps to tie in to the phone’s sync services

Hopefully, this means they’re actually going to start working on some nice built-in adapters as well, but at least it seems they’re opening up the sync parts of the platform from 2.0, contrary to what had earlier been reported. Yay.