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.

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 …

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.

I may well release the code, but I’d have to have a quick look through it first.

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.

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.

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:

ParcelTest.java

import java.util.HashMap;
 
import android.os.Parcel;
import android.os.Parcelable;
 
public class ParcelTest implements Parcelable {
    private HashMap map;
 
    public ParcelTest() {
        map = new HashMap();
    }
 
    public ParcelTest(Parcel in) {
        map = new HashMap();
        readFromParcel(in);
    }
 
    public static final Parcelable.Creator CREATOR = new Parcelable.Creator() {
        public ParcelTest createFromParcel(Parcel in) {
            return new ParcelTest(in);
        }
 
        public ParcelTest[] newArray(int size) {
            return new ParcelTest[size];
        }
    };
 
    @Override
    public int describeContents() {
        return 0;
    }
 
    @Override
    public void writeToParcel(Parcel dest, int flags) {
        dest.writeInt(map.size());
        for (String s: map.keySet()) {
            dest.writeString(s);
            dest.writeString(map.get(s));
        }
    }
 
    public void readFromParcel(Parcel in) {
        int count = in.readInt();
        for (int i = 0; i < count; i++) {
            map.put(in.readString(), in.readString());
        }
    }
 
    public String get(String key) {
        return map.get(key);
    }
 
    public void put(String key, String value) {
        map.put(key, value);
    }
}

Update 2: Stefan requested that I post some code showing how to use this implementation, so here is a supplier and a consumer activity, using this Parcelable object:

ExampleSupplierActivity.java

import android.app.Activity;
import android.content.Intent;
import android.os.Bundle;
 
public class ExampleSupplierActivity extends Activity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        ParcelTest p = new ParcelTest();
        p.put("green", "go");
        p.put("yellow", "wait");
        p.put("red", "stop");
 
        Bundle b = new Bundle();
        b.putParcelable("com.example.trafficlight", p);
 
        Intent i = new Intent(this, ExampleConsumerActivity.class);
        i.putExtras(b);
 
        startActivity(i);
    }
}

ExampleConsumerActivity.java

import android.app.Activity;
import android.os.Bundle;
 
public class ExampleConsumerActivity extends Activity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        Bundle b = getIntent().getExtras();
 
        ParcelTest p = b.getParcelable("com.example.trafficlight");
 
        String red = p.get("red");
        // ...
    }
}

Disclaimer: This isn’t the actual code from my system, and I haven’t tested it. If you want efficient code, you will likely need to change things; If you want safe code, you will most certainly need to do things in a less careless way. If you find any bugs, please leave a comment.

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

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.