Just for interest I commented out this line:
SPI.setClockDivider(SPI_CLOCK_DIV16);
Thus the SPI was running faster. It still worked, in the sense that I got data back, but the 2.5V reading was out. It gave around 2.19V. So clearly the internal capacitor hadn't had time to charge fully. So that's why you need to slow it down a bit.
Nick, thank you very much for this, it's awesome! I shall try some more debugging with my chips and see what is wrong. If you have the time to answer them, I have a few questions:
The streaming library is something I have never seen until your post. It's something I'm very interested in, is this the one you use?
Streaming | Arduiniana
You set your Serial speed to 115200. Is that personal preference or does it affect the program in any way?
In this line of code,
bitnum = word (msb & 0x1F, lsb) >> 1;
where does the "word" function come from? I've seen it before with single variables but never with the comma in it.
Once again, I really appreciate your help!
madvoid:
- The streaming library is something I have never seen until your post. It's something I'm very interested in, is this the one you use?
Streaming | Arduiniana
Yes I think that's it. Makes printing easier and handles floats.
- You set your Serial speed to 115200. Is that personal preference or does it affect the program in any way?
My debugging comes out faster. 
- In this line of code,
bitnum = word (msb & 0x1F, lsb) >> 1;where does the "word" function come from? I've seen it before with single variables but never with the comma in it.
Check out:
One of the forms of that lets you combine two bytes into a word.
- What are your thoughts on the accuracy?
It looks reasonably accurate. In what sense do you mean? My meter measured 2.504V on the ADC, and on the monitor it reported 2.5V, so I can't complain.
It looks reasonably accurate. In what sense do you mean? My meter measured 2.504V on the ADC, and on the monitor it reported 2.5V, so I can't complain.
That's what I was wondering, how well it compared to a meter, thank you!
Final Update: I found what was wrong, and it was ridiculous! The wire used to connect the two clock pins together had broken inside the insulation, which is why the ADC that worked was dependent on whichever wire was directly connected to the Arduino. Nick and graynomad, thank you for your help. Nick, sorry for all the trouble just to find out it was a trivial problem. I guess this is one of those things that I would have never learned unless it happened to me...
Oddly enough there was another post a while back on similar lines. That time someone hadn't noticed that the breadboard (some breadboards) don't have the power and Gnd lines connected all the way across. So some of his sensors worked and not others. A similar sort of thing.
Just when you are wondering about SPI, clock rates, decoupling etc., it turns out to be a wiring issue! Ah well. Probably helps to know that someone else got the concept working, so it helped refocus your thoughts.
Glad that worked out.
We've all been there. I had a bug once that was eventually fixed by just turning the wire around, and it wasn't the connection because I unplugged/replugged it several times. But swapping the ends worked :~
Probably helps to know that someone else got the concept working, so it helped refocus your thoughts.
Exactly, there's a big difference when you know the concept works, then you can forget about that and look for physical problems.
Well done here to Nick, above and beyond the call of duty and I think one reason this forum is so popular.
Rob
One alternative to consider is the MCP 3421 and 342Xfamily of ADCs. I have used them to good effect, Jeelabs uses the MCP 3424 on its ADC daughterboard, IIRC. If I were you, I'd go with the MCP3422, offering two channels on a single chip, if 60 samples/s is fast enough.
Painless to hook up. Others have built examples (eg Phil Anderson, among others) that you can use as inspiration, and a single chip can handle up to 4 channels. The only limitation is the sampling speed, I hope that 120 samples /s @ 12 bits is fast enough. Additionally, these chips do decimation on-board so they can offer 14, 16, and 18 bit resolution also, though with the limitation that the external sampling speed gets progressively slower (i.e. 3.75 samples/s @ 18 bits).
I2C bus is also easier to handle, IMO, for multiple devices on a bus. The trick for the single and dual channel versions of these ADCs is to ensure you place the right chips in the right locations, since the I2C addresses are burnt into the chips and there are no opportunities to manipulate the I2C address through the use of addressing pins on the chip like with the MCP3423 and MCP3424.
IIRC, some SPI devices like the Wiznet 5100 controller are problematic re: giving up the bus after the their CS has been pulled back up. Maybe the ADCs you are having trouble with fall into the same category? Have you reviewed the spec sheet twice to ensure that you don't need any pull-up magic or whatnot that is not normally specified for SPI devices? Additionally, the forums over at MCP are usually pretty helpful. Worth a try, anyway. Cheers!
Probably helps to know that someone else got the concept working, so it helped refocus your thoughts.
I think that is exactly what happened. I thought it was a much more complicated problem and knowing that it works made me look at the simpler things.
@ Constantin - I might upgrade later on and I'll keep the ADC's you mentioned in mind. Thank you for letting me know about the SPI devices refusing to give up the bus though. That's a problem that I wasn't aware of existing so it's good to at least be aware of it.