Hi Just a reasonably quick video on the Power Supply Design series. again. I Wasn't going to do this one, but I thought Well, while I'm troubleshooting this thing, I might as well turn the camera on and give you a look at it. Now Yes, I'm up to the PCB Here it is.

I've built the thing up and if you've been following me on uh Twitter and the Forum, you'll know I've been having a whole bunch of issues. It's taken me a couple of days to get this stupid thing running because of the stupid Arduino software and the Arduino interface in the AVR studio. and the AVR Mark Anyway, I won't go into it. it's a whole other video.

Anyway, it's been frustrating. but Beauty I've got it working I've got the LCD working I've got the pots working I've got the switches working. Everything's sweet and looking good. but um, now I'm starting to talk to my deck and as you know, it's an SPI deck.

It's A. It's A and it's a software interface. It doesn't use a hardware SPI interface. Um, on on the AVR micro software interface.

So I wrote my code based on the data sheet bit. banging the serial Port crossed my fingers, stuck my tongue at the right angle and what do you know, it didn't work first. Go go figure. Murphy So I thought I'd just uh, turn on the camera while I'm uh, troubleshooting this thing and we'll take a look at it.

Let's go. And for those playing along at home, there was a small error in my schematic too. This is the Rev one schematic and of course I had it. uh, correct because I uh, bread barded the thing and the ADC I out is going to the non-inverting input of this opamp here.

So that's the output from my uh, current sense amplifier. So it's going to Pin five there. But what on rev B here I've got it going into pin six fail eh? Um, the reason that happened is because when I was uh, rejigging this uh PCB you know, making it look pretty I was moving, moving things around, dragging, cutting and pasting and those lines obviously got moved and I put them back and I accidentally swapped them. Oops trap for young players.

and of course the ERC checking in. The these types of uh CAD programs aren't magic, they can't cater for fires up in the gray matter do all right? So this is what we're going to take a look at in in this video. My deck isn't working here. I've got my SPI bus on the input, which as I said, is a software SPI bus.

It doesn't use the hardware interface bus so I'm riding my own library for that because it's so incredibly simple and I'll show you the code in a minute. That actually does it, but it's not working and it could be something incredibly simple. I've probably done something dumb in software. Maybe there's a hardware fault buil in it.

We won't know until we track it down. I Think it's most likely to be uh, you know I've done something uh, dumb in the Arduino uh driver software for this SPI interface and it's just not uh talking. But let's just check the hardware pinouts. Analog VSS is ground as it should be Vdd and I've checked these voltages.

they are 3.3 ground uh Vref on the inputs. We'll have to check those uh, Ldac the uh, that's the load output. Now the data sheet specifically says you can actually tie that low and then rely on the positive going chip select at the end of the data, send in the data to actually latch the internal data that you send from the SPI through to the analog uh outputs here. and that's it.

It's a pretty darn easy uh chip. It's not in shutdown mode because that, uh, that shutdown pin N9 there is connected high so it's an active low shutdown. So all right, everything should be working. So we've got to check our Um chip select.

Make sure our chip selects working might have to get the logic analyzer out for this one. We can probe it with the scope first to see if it is a protocol issue. We'll have to get down into the logic analyzer, get down and dirty and take a look. But basically I'm getting zero on the output here.

I'm changing my Um input voltage as we'll see and getting nothing. So let's try and debug this thing all right. So here's my board here and I won't go into details I'm going to have a whole video on how I designed the board, how it fits into the case, and all the system engineering that goes into that. so don't worry about that.

That'll eventually come. and we're just doing debugging today. And here's the LCD It's a uh my uh New Haven uh display with the RGB lead back light I haven't hooked up yet. It's a 20x two instead of the more common 16x two which is really good.

and uh, I've got it. So it um has the set output voltage and the set output current here and then the measured output voltage and the measured output current here. This may change on the final interface, but I reckon that's pretty good interface and my knobs work. Check it out.

There's my voltage control uh Noob there. My rotary encoder works just fine. It's uh, jumping up in 10 molt steps at the moment and the current limit can also jump up in 1 milliamp steps like that. and uh, this is all work working in code so that this value at the moment, what I'm trying to do is send uh, this uh milliamp value directly out to my uh deck.

Here, this is my deck and uh, I'm getting no output value at all. So I'm trying to that uh value is already in memory and I'm trying to shift it out through the SPI bus and well, it's just not working. So uh, we're going to have to look into it and see what's going on now. Now what I've got here is I've got an Arduino Deilan No, if that's how you pronounce it correctly.

I've actually removed the chip and what I'm doing here is I'm just using this as an Ftdi interface. If you've been following my Twitter and uh Forum things, then you'll know I had to do this because I couldn't find my other interface. So basically I've got my reset line, my transmit and receive, and my ground uh, using this as a basic Um Ftdi interface to the Arduino IDE environment and it's working. Uh, just fine.

And with the boot loader here, I've got an At Mega 328 AVR chip on here exactly like what's on an Arduino Pro and this serial interface is also exactly the same as the Arduino Pro. The I've got to fix the pin out for the reset line, but apart from that, uh, it is an identical interface. So I've programmed the bootloader firmware on my PSU board to be exactly the same firmware as what is on an Arduino Pro board. So as far as the Arduino ID is concerned, you just set it to talk to one of these genuine Arduino Pro boards and it does.

Doesn't know the difference? It'll talk to my power supply board instead. Beauty All right, One of the first things I want to do is, uh, just compare the data sheet pinout against what I've got on my schematic here just to make sure there wasn't an issue with the pinout in my library component for that and that looks sweet. So I don't see any issues there at all. So and um, because I've done a DRC check between the schematic and the PCB I know the PCB is going to match the schematic, so it should be sweet.

All right, the next thing I'm going to want to do is, uh, just, uh, check a few things. Uh, just to check pin one here. that's my Vdd. that's 3.3 volt.

say it's 1 volt per division. Not a problem at all. Um, I've already checked the Vref voltage. that's 2.0 volts and 2.04 eight volts.

and that's pins 11 and 13. There it is there. and uh, check pin 11 as well cuz there's two separate voltage references for both Um A and B voltage outputs and they're working just fine and the ground is connected. So really, that leaves the Um SPI interface.

So let's do Pin8, which is the low deck that should be low and it is permanently low, so data Sheet says we can do that. The shutdown pin pin 9 should be high because it's an active low shutdown so the chip is not shut down. Beautiful, right? Let's take a look at the chip select pin because my software here I don't have to actually do anything. It's continually updating and sending the latest current data as you saw on the LCD sending that value through to the deck.

So let's prob pin three here, which is a chip select and see if we get anything. Bingo There we go. We do. We're getting uh, how much worth of uh, 5 milliseconds per division? 5? 10? 15 milliseconds? Um, sounds okay for sending all that data.

it's an active low chip select. So clearly that's working because um, that was an issue because um, well, that may have been an issue because that was going through my I S C IO expander. So if my I I Squ C Iio expander wasn't working, then the chip select for the Dack wouldn't work and so on. If you're following the schematic along at home, you'll know what I'm talking about.

So um, let's check the data in Pin five Bingo we're getting data. not a problem and that data should change if I chase the pot. Yes, it does. it's it's not.

Uh, it's not terribly, uh, stable there. But you can see the the uh trigger changes. but you can see that data change as I change the pot. The pot is still and bingo so no problems at all with the data.

and um, you? you don't really? Um, sometimes if you don't have a scope available with you, you can use a uh, just a standard logic probe. Old old school logic probe to see that your data is actually transitioning here. Um, but it's handy. With the scope.

you can actually see the data and well, it's looking like we may have to get out the logic analyzer because uh, let's Well, let's check I've got one line left which is pin Four, which is the uh clock line. So let's go to Pin Four here. Aha, there you go. That's the culprit.

Pin Four is not working. There's no clock. No wonder I'm getting no data out of my deck. D Dead easy.

All right, let's fix that. So there's nothing getting to Pin four of my Dck. Well, is it coming from the output of my Uh AVR chip here? because there could be a break in the PCB. There could have been an eching fault I Doubt it comes from my new New Zealand uh supplier.

It looks first class quality Circuit labs in New Zealand or um PCB zone. Uhet there this board is manufactured in New Zealand I Might give you a closer look at that later. but let's check this pin here which is the output of the AVR No, it's exactly the same on the scope. so what fail? So what I want to do here is check my SPI clock here pin 26.

It is actually the Uh Adc3 input or uh A3 input. So if I go to my Uino code Let's uh, check out to see if that's actually correct and there it is. SPI s clock A3 and the others work. I've defined that pin and we can go down and check it further down.

but I don't know that should work H Now if I have a look at my Dax send routine here. I've actually defined the DAC clock toggle here. I've actually defined that as an operation where the SPI clock goes high and I added this delay extra while I was trying to debug it without a scope before and then uh, digital right low. so it's supposed to.

So every time I CL call Daak clock toggle. it's supposed to go high and then delay for a millisecond and then go low and well, it's not doing that. So I don't know what you know. I'm calling it a whole bunch of times throughout here that clock toggle and it doesn't like it at all.

And here where I Define my pin mode. there it is SPI clock is an output. Not a problem at all. just like the SPI data so it should be working I'm not sure why.

very puzzling and I'll just double check the Arduino Pro schematic. There it is Adc3 pin 26 A3 three. So that's the pin I'm using. Why doesn't it work? well? What do you know I found it look silly naming thing which the Arduino environment didn't pick up because it already has a names registered I defined here SPI s clock.

but if you go down the bottom here where I uh Define where I actually do the output here SPI clock not s clock. there's no s in there. so the Arduino didn't pick that up because SPI clock must be uh defined uh, somewhere else, maybe in like an internal uh library or something like that. So um, yeah, if I change that to SPI s clock do and I have I goofed up the routine up here as well SPI clock.

Yeah, there we go. Let's change that to Spis clock spis clock and that should be sweet. We don't need that um, 1 millisecond delay in there. that debug delay in there anymore.

and let's uh, compile and download that and see what happens. So it's compiling the sketch now and I'm using n 7.3k of my 30k already which uh, isn't too bad at all I guess cuz I'm using some um s uh, printf stuff which um adds about 1.7k or thereabouts and it's done uploading and let's give this a go. Tada There it is there. It is not a problem at all.

awesome, so it should be fixed if I stick my multimeter on the output of that deck. Um, assuming that I've got my algorithms correct um for my SPI serial interface, then uh, I should get the exact value out I Expect All right, let's check a couple of things. let's check our voltage reference. For starters, there you go.

2.04 n should be 2.04 nearer enough and let's uh, adjust our um, our current output pot here. as you can see, it's zero. So let's measure the output. Let's probe the output pin which is pin uh 7, uh, 8, 9, 10 I believe currently Zer volts and what? No, nothing.

what's going on? Bummer. And I just check the other out put to just in case. I didn't get it wrong in software. but no, nothing.

what's going on. This is hopeless. It should at least be outputting. We saw that data changing as we Chang the pot.

so there's some data going into it. So unless I've uh, screwed, um, something in the well I've obviously screwed something in the software, something's going on because um, all, we're getting all the signals on the SPI bus now. so well, I think it's time to crack out the logic analyzer. Now What we're going to do is have some fun with our Agilant 3000 Series with the built-in logic analyzer uh capability in here and the serial triggering because it can, uh, do SPI serial bus debugging.

You don't have to have a fancy mix signal scope like this. You can do it with a cheap, simple uh PC based USB logic analyzer that supports these serial uh decodes and we can change the number of bits here and we can do all sorts of things. And we can set up our trigger I'm triggering from the SPI Uh bus at The moment. As you can see, we can trigger off all sorts of things and we can trigger off two different types of Serial buses and it's really is quite neat.

But we can go into trigger setup and once we get all this set up, we'll be able to trigger of this SPI bus and see exactly what's Happening Here We don't have to do this, we can actually just singleshot, uh, capture this thing using the regular Um scope if we want. um, but it just it'll be nice because it'll give us our data. uh, decode here and we can see that the data will actually match what we're sending in our software. Now, what we want to trigger off here, we want to trigger off.

Um Mozzy Master out Slave in because our AVR is our master and it's sending data to the slave in, we're not actually using the fourth Channel um Mi So because we're not actually retrieving data back out of this deck, we're only sending data to it. so we only need the three signals so we can just ignore the fourth one now. I Haven't actually done um SPI debugging on this scope before and I'm not sure why only offers um to trigger off the data it doesn't offer. You offer you to trigger off the Uh clock or the chip select or anything that chip select would be.

um, a nice one to trigger off. So I'm not sure what's actually going on there. Pretty happy with that. I Love that it gives you the waveforms and stuff like that here.

It's really nice. we don't want to trigger off the Mozzy data because it it's actually a data pattern which is why it's not actually uh triggering at the moment. I'm doing I'm Press Start single shot and it's still sitting there waiting for the trigger. So that's no good because we don't want to trigger off a bit of data I Want to actually trigger off the Uh chip select or something like that instead of um, the SPI is just the data.

It only gives you the options for the data so we don't want that. We want to actually trigger off and an edge for one of the Uh Source channels. And here's where you should label them so that instead of having one two 34 like that, you should actually go to the effort to label them. but ah, I'm not going to bother today.

Um, and we'll trigger off the Uh chip select. Of course our chip select is Channel 4 here and the threshold voltages. They're all okay. So let's uh, go back into our trigger menu here and we want to trigger off Channel four like that bang which will be our chip select.

So there we go. Captured it. single shot mode, bang and there's our data. Ah, beautiful.

Let's single shot capture that. And as you can see, our chip Select is the top Trace up here. Uh, this is our D and the yellow one down here is our clock and if we scroll along and zoom into that, you'll notice that the chip Select is actually a long way past here Because to do the chip select, we're using the I Squ C bus so our software has to actually send. during this time.

it has to send a command through to the I Squ C buus to actually switch that on and that's 200 microc per division. So it's roughly taking you know, 200, 400, 600, 800. It's roughly taking 1 m second to actually send that command before it gets through to change the chip select High and um I Don't know if that is actually an issue. maybe uh, that time there to set the chip select back high is causing the deck I Don't know I'd have to read the uh data sheet.

But let's go in and we can actually examine the data in here. and uh, as you can see, it hasn't actually decoded individual data here. it's just got B611. It hasn't actually um, decoded our data like I wanted there.

So maybe I haven't set the thing up properly yet. But there you go. there's our data and our chip Select. sorry our our clock here.

The data should be stable when it transition. So when it clocks high here, then uh, that is going to read in a one from the data. When it clocks high here, it's going to read in a zero 1, 1, 0, 1, 1. and well, this pretty much matches up with the data sheet precisely.

And there's the timing diagram for our data sheet. so as you can see, chip select where that goes low first which is exactly what we got on the scope screen. and then uh, the positive um edge of the uh Sc- clock. here is where is smack in the middle of the data bite which is where it samples at and it sending 16 bytes, uh, 16 bits, uh, total.

regardless of whether or not it's the 12bit uh, Dack the 10bit deck or the 8bit deck. Um, it. Just if you scroll down here, you'll see that. The good thing is it's totally software compatible To just ignore on the 10bit deck, it ignores the last two bits over here and you go down to the 8bit deck and it simply ignores the last four bits.

It's great. So you can, um, completely software compatible. You can just plug in an 8, 10, or 12bit deck and just send out the data cuz it'll ignore those least significant bits. Oh I think I figured it out I'm only sending 14 bits, not the Tire 16 I'm missing out on the last two bits I wasn't sending them cuz I decided to only um, send 10 bits uh worth of data because it matched up with my output Vol output current correctly and stuff like that.

So ah, oops, duh I got to fix that in software. send the extra two bits presumably it's waiting for those. so that's why I'm getting nothing out. So there you go.

I've added in, uh, two extra bits here I've set them both, hardcoded them both to zero because are only sending out 10 bits worth. So I'll upload that, click on upload and in a few seconds, it uh, should output on my little board here. So hopefully, um, that's all the problem is. we'll find out in a sec.

Okay, I won't even bother. uh, retriggering the data over there to see if I've got uh, 16 bits. I'm pretty sure I will. And so let's um, increase our current here and see, probe the output.

Ah bingo, Bingo, There we go. I knew it I knew it. There we go, we're getting our output voltage. Fantastic.

There you go. So it looks like that deck did not like um, being two bits short, it just didn't recognize it as a valid command. Now curiously, this is supposed to be one bit per Mill volt uh output. but I'm not getting that I'm getting I'm um, sending 100 milliamps here and I'm getting 200 molts out and that basically if you increase that, it actually is two times.

So I wonder if I've got there is a two times amplifier in this thing. So I wonder if the bit for that is set incorrectly? Well, what do you know? There we go. I didn't read the data sheet correctly. the output gain is actually always referenced to 4,096 or the output voltage is always referenced to 12 bits regardless of what device you use, whether it's an 8, 10, or 12bit one, or we're trying to do 10 bits.

In this case, it's always referenced to D on 4,096 and it does have two Uh gains there. and I'm actually sending out a one uh for GA here. at least that was what my um, that's what I programmed in in my Arduino software. So we're using that formula there.

so there's two things that are wrong here. One is that I'm using the wrong gain I'm going to need the two times and I've got my bits uh shifted. I'll show you the code in a sec. I've actually got my bits all on the high side I need to shift them towards the low side.

You know how I added those two bits on the least significant Uh digits I need to add them on the most significant digits, don't? So what we want say if we feeding 100 uh from our you know 100 Milli Uh amps which will be a value of 100 directly in the internal register, then we want to divide that 100 by 4,096 Okay, and then we times it by our voltage reference which is 2.04 vol. Bingo It's only going to give us 50 Mt We want that to map to 100 so we want to use the times to Output So let's change that around and we'll find it'll work precisely the way we want. These sort of things always happen first. go when you don't engage your mind before you write the software I Just whacked it in there and ah, sort it out later, she'll be right right? So in our routine here up here where we've got output voltage gain select x 1 We want to change that to x two.

So we want that to be a low and we want, um, we have to shift all this data here so that, uh, we're Shifting the 10 bits at the top So we'll send let's go home here and we'll We'll copy these two bits we've got down here. We'll copy those and we'll put those right at the start here and Bam that should do it. Let's download and try it again. All right, let's probe the output here.

We've got uh, zero milliamps there. We get zero on the output. Well, we're actually getting one molt there, but you know it's down in the noise. so let's shift it up by one.

it doesn't go anywhere, we're down in the noise. but let's say take it to 10 and no, no, we're not quite there. we're 5 Mt so we're still down in in lawers, but we should find let's go up to 100 milliamps. We should find that to be.

It's a it's a bit off 96, but there you go. It is actually mapping and we're mapping at 500 milliamps too. It's slightly low, but if we go up to a volt, we'll find that one will map as well. And it does.

But we are once again, uh, about 5 MTS or 5 milliamps short. Now the interesting thing is is that our refence voltage here is Uh 2.04 N3 volts and that's well within uh spec. The spec of this voltage reference is .25% and .1% um of 2.04 Vols is 2 molt, so we're well under .1% there. So really? um, that doesn't explain a.

5% discrepancy or 5 MTS in 1,000 on our output. Strange, this meter is bloody annoying by the way. it keeps Auto switching off even though I'm using the damn thing and measuring stuff crazy now. Um, I'll just probe directly on the pins of the deck to make sure that we're getting I've set it for 500 here and we're getting still getting in that 5 molt uh, differential there.

Not that there was any major current flowing through here anyway, cuz I was probing on the other side of the board before. You just have to be uh, careful of that that you're not getting a voltage drop there, but that's directly on, um, the Uh pins of the deck and the same thing with the Uh reference voltage. I'm measuring directly on the input pins and once again, it's still the same. There was no drop elsewhere as you'd expect.

2.04 N2 Let's have a look at our raw data here. if we uh, start out here. here's the bit. okay at the first that first transition there.

so it's 0000 0, 1, 1, 1, 1, 1, 0, 1, 0 and if you convert that to decimal, that's 500. It's exactly what I'm feeding in. and if you plug the actual values into the formula in the data sheet, the actual voltage reference we're feeding in 500 / 4,096 times the voltage reference 2.0 493 We actually should and then multiply by two for our internal gain. Amp should get uh, precisely um 53 Vols out.

But we don't We actually get 495 And now what I've done is changed the Um software so that it also outputs it on the other channel too. and there's the other channel. Got it set to 500 again and we getting 497.org Error is is uh, typically Uh minus 0.1% of the full scale reading not including the offset era which could be up to 20 MTS um at the Uh low end, but it's a maximum of 1% so it's it's pretty horrid. and if we actually disable that time 2 Gain amp I've got uh 1,000 milliamps so we expect 500 on the output and let's check it out.

that's the Uh Channel um, that's the current Channel Output 497.org 12-bit deck. So we'll uh, see if it performs any better. um, by getting the actual Uh 10bit version. so stay tuned.

Ah, but wait. I've got a couple of more chips. Let's try it out and see if they're any different. All right here we go: I've got it once again, set to a gain of one still.

so that's 500 milliamps there. We should expect 250. So I've got a another chip in there. It's the same chip.

it's still the Uh mCP 4922. Let's measure the output. Ah, look at that. 23.9 M Vols There you go.

20. Well, 254 Mill volts. And let's check the other channel which has exactly the same number 248. Look at the discrepancy.

first Channel 246.50 the other channel 23.0 There you go. These specs on these things are as Loose as a Goose but hey, there you go. mCP 4922 Integral Nonlinearity Error plus typically plus - 2 least significant bits can be as much as plus - 12 least significant bits. which is, you know pretty much uh, what we're seeing there so it's certainly not meeting.

its uh, typical figures. So I guess I can't be too harsh on this thing. You know it's uh, it certainly U it does meet its uh specs. It's just.

uh, you know I was hoping for spot on. You know it's a 12bit deck, that's what you expect. But anyway, um I might see if I can pick up some mCP 491 12s here and uh, see if they perform any better cuz really, probably don't need a 12bit deck on this thing. it's a bit Overkill I think I'll just go for the Uh 10bit deck and uh so I'll pick some uh, some of those up uh tomorrow from Fels Hopefully they got some in stock.

they may or might not I have to check anyway. I hope you enjoyed that, that's that's a bit of uh uh, duck debugging on the new power supply. I'll catch you next time. Now just as a little aside, uh I thought I'd show you this on the Uh I Squar C bus that actually uh drives the LCD it also drives those um Iqu C decoda IO chips but this is an actual problem with uh the LCD display.

I'm getting I this is our um, uh, our clock and this is our SDA our d look at that little run pulse in there. Check that out now. I've got my scope set up to trigger on the uh start condition I'm using serial protocol uh triggering here so let's trigger on the start and let's capture that and Bam Let's uh, hang on, let's do that again. let's there we go.

That is uh, the data going onto my I Squ C bus and this is probably the decoder over here. but this is the LCD Trust me if um I've looked at this before and it's rather interesting, look at that. It's almost as if there's a bus. Well, there is some sort of bus contention there.

uh, that is actually causing that thing cuz it's not supposed to be a tri level bus like that. It's only supposed to be two levels data one and zero. Of course it's digital, but we're not. So it looks like there's actually some contention caused by the LCD And trust me, I've isolated it down.

It's not the other Ice squ uh C chips. They haven't got the same address or anything like that. Trust me. I've isolated it down and it is the LCD and it's not actually my code doing that either cuz I originally wrote my own um, uh, LCD driver code from scratch and I got this result and I thought it was funny I thought my code was doing something weird.

um, even though I copied it directly from the Uh data sheet of the LCD manufacturer and um I thought okay, as see Uino, the one wire library has been giving me troubles. Maybe there's an issue there there and that could still be it. but uh, I downloaded somebody else's code I searched around. Sure enough, the Arduino had a library for my exact uh New Haven LCD display and even using that, I get the same data and but the LCD Works um so I haven't really looked into that in detail, but um, so I'm not sure either if it's the uh one wire, uh driver doing something funny or it's the LCD actually uh, doing something and dragging the bus down when the uh drivers trying to do something, but clearly there's a conflict there and uh, well, at this stage, I'm not going to look into it cuz my LCD is working I'm happy with it.

so I'll have to leave that fight for another day, but that happens even on the Um Library that's already out there for the New Haven display. so something going on there catch you next time.