kcatthedog
Temp
Super Helpful Dude
Posts: 16,043
Member is Online
|
Post by kcatthedog on Mar 4, 2015 15:42:01 GMT -6
Well it sounds like exploring the cause of the heat and establishing if that is a normal range or not makes sense.
|
|
|
Post by svart on Mar 5, 2015 15:36:24 GMT -6
Thinking about it, I'm wondering if the negative currents from the DAC outputs are pushing the I/V opamps into pseudo class A operation. This would explain their heat output. I might not continue this investigation if this proves true, and just work on the heat dissipation instead.
|
|
kcatthedog
Temp
Super Helpful Dude
Posts: 16,043
Member is Online
|
Post by kcatthedog on Mar 5, 2015 15:48:14 GMT -6
If the heat is normal for the circuit then controlling its potentially negative effect on the rest of the circuit through dissipation is the only remedy required; right ?
|
|
|
Post by svart on Mar 6, 2015 13:13:29 GMT -6
If the heat is normal for the circuit then controlling its potentially negative effect on the rest of the circuit through dissipation is the only remedy required; right ? Yes, that's about it. I have a few requirements that need to be met concerning thermals. One is keeping the parts in a region where power excursions won't violate maximum working temperatures. Secondly I need to make sure that there is no thermal runaway in certain parts. Some regulators have problems where their peak current handling drops as temperatures rise in the silicon die. Essentially they can self-heat over time with lack of consideration for changes in current draw, voltage fluctuation or heatsinking, and either switch into thermal protection modes or simply die. I measured the temps on some of the parts today and they weren't as alarming as I thought by touch. The regulators were around 130F, the I/V integrators were around 150F and the output opamp was 135F. The DAC itself was 130F. I consider this pretty normal based on the current draws of the parts. I found that the regulator oscillation was also not the fault of the regulators themselves as I thought initially, but my fault for not accounting for the ceramic output caps heating up. I used ceramic output caps, and the location of the caps allowed them to heat and drop in capacitance to below the stability limit for the regulator at the measured current draw. Increasing the value of these caps or changing to tantalum fixes the issue with the cap tempco. I'm sure TI and Micrel would be happy to hear that their parts are actually good and work as the datasheet says.
|
|
|
Post by svart on Mar 11, 2015 13:21:39 GMT -6
Time for an update! the day job has been sucking up a lot of time lately, but I'm continuing to do work on this as I can.
So I received the fixed DAC boards and I've built one. Looks like everything is good.
Now I have to revise chassis with another dimple on the bottom to heatsink off the DAC opamps specifically. I could just not do this and they'd still operate within their limits, but I'm not going to chance it.
All the regulators are within their temp/current tolerances. One is close to it's limit for the voltage drop and current, but I have special plans to fix that one.
I've decided on the best capacitor values for decoupling the parts for lowest noise as well.
Now I just need to finish the code for the DAC board and I'm going to send JohnnyK a unit for him to test as he sees fit. I won't have time to go up to Nashvegas for maybe another month, but he'll have a unit within the next few weeks.
I still have to finish the bezel design too.
|
|
|
Post by svart on Mar 11, 2015 14:20:42 GMT -6
Oh and here's the DAC board.
|
|
kcatthedog
Temp
Super Helpful Dude
Posts: 16,043
Member is Online
|
Post by kcatthedog on Mar 11, 2015 14:30:15 GMT -6
Cool !
|
|
|
Post by Johnkenn on Mar 11, 2015 14:38:42 GMT -6
Woohoo!
|
|
|
Post by svart on Mar 11, 2015 14:46:37 GMT -6
I also just placed orders for the parts to build the 10 DAC boards. The next and final large $$$ order should be the bezels when I get those done.
Whew, my bank account is hating me.
|
|
|
Post by svart on Mar 17, 2015 11:23:05 GMT -6
So I'm at a crossroads with the DAC code.
The DAC is somewhat autonomous in that it essentially sets itself to whatever the incoming SPDIF rate is. I simply check the status of the chips and pass that info on to the ADC master board over I2C so that the status can be displayed on the LCD.
In this way, it can be used standalone, or with the ADC as master, but it seems that I can't make the DAC a master without significant re-writing of the ADC code. What this means that if someone buys a DAC only, they wouldn't be able to add an ADC board to the unit later. They could get an ADC board and still add the DAC board later, or they could use them both as standalone units. This is because the LCD/button code needs to be handled by one board only, but if a person purchases the DAC board, then the DAC will have the physical connections for the LCD/buttons and need to pass the settings from the front panel to the ADC board. this is the portion that is not written in the code now.
So right now here are the possible configurations:
ADC standalone W/LCD
ADC master/DAC slave
DAC standalone w/LCD
DAC standalone W/O LCD
I had intended to make the DAC be able to run as a master as well, but I'm running out of time with this project I think. So what do you folks think, should I take on the task of re-writing the code so that either board could be a master controller?
|
|
|
Post by tonycamphd on Mar 17, 2015 11:42:18 GMT -6
So I'm at a crossroads with the DAC code. The DAC is somewhat autonomous in that it essentially sets itself to whatever the incoming SPDIF rate is. I simply check the status of the chips and pass that info on to the ADC master board over I2C so that the status can be displayed on the LCD. In this way, it can be used standalone, or with the ADC as master, but it seems that I can't make the DAC a master without significant re-writing of the ADC code. What this means that if someone buys a DAC only, they wouldn't be able to add an ADC board to the unit later. They could get an ADC board and still add the DAC board later, or they could use them both as standalone units. This is because the LCD/button code needs to be handled by one board only, but if a person purchases the DAC board, then the DAC will have the physical connections for the LCD/buttons and need to pass the settings from the front panel to the ADC board. this is the portion that is not written in the code now. So right now here are the possible configurations: ADC standalone W/LCD ADC master/DAC slave DAC standalone w/LCD DAC standalone W/O LCD I had intended to make the DAC be able to run as a master as well, but I'm running out of time with this project I think. So what do you folks think, should I take on the task of re-writing the code so that either board could be a master controller? I know you think i'm here just to guff you, but i'm not, i KNOW you put a tremendous amount of time and your expertise into this, I totally respect that and your abilities, i would absolutely love to see you have extreme success with this! That said, this has me a little puzzled? i think everyone here will give you as much time as you need to suss out exactly what you want, i wouldn't put a time pressure on yourself and settle for something less than you see fit, if you have another reason for feeling that? then so be it, but i think you should do your best with no worries of outside pressures, do your thing man.
|
|
kcatthedog
Temp
Super Helpful Dude
Posts: 16,043
Member is Online
|
Post by kcatthedog on Mar 17, 2015 11:49:00 GMT -6
IF one wanted this unit's DAC to be used for your print track, then don't you need it to be master clock or isn't that arguably preferred ? I am with Tony or let people decide but wouldn't you want to have only one type of functionality out thee in the field, 4 permutations could drive people crazy
|
|
|
Post by svart on Mar 17, 2015 11:57:16 GMT -6
So I'm at a crossroads with the DAC code. The DAC is somewhat autonomous in that it essentially sets itself to whatever the incoming SPDIF rate is. I simply check the status of the chips and pass that info on to the ADC master board over I2C so that the status can be displayed on the LCD. In this way, it can be used standalone, or with the ADC as master, but it seems that I can't make the DAC a master without significant re-writing of the ADC code. What this means that if someone buys a DAC only, they wouldn't be able to add an ADC board to the unit later. They could get an ADC board and still add the DAC board later, or they could use them both as standalone units. This is because the LCD/button code needs to be handled by one board only, but if a person purchases the DAC board, then the DAC will have the physical connections for the LCD/buttons and need to pass the settings from the front panel to the ADC board. this is the portion that is not written in the code now. So right now here are the possible configurations: ADC standalone W/LCD ADC master/DAC slave DAC standalone w/LCD DAC standalone W/O LCD I had intended to make the DAC be able to run as a master as well, but I'm running out of time with this project I think. So what do you folks think, should I take on the task of re-writing the code so that either board could be a master controller? I know you think i'm here just to guff you, but i'm not, i KNOW you put a tremendous amount of time and your expertise into this, I totally respect that and your abilities, i would absolutely love to see you have extreme success with this! That said, this has me a little puzzled? i think everyone here will give you as much time as you need to suss out exactly what you want, i wouldn't put a time pressure on yourself and settle for something less than you see fit, if you have another reason for feeling that? then so be it, but i think you should do your best with no worries of outside pressures, do your thing man. Thanks Tony. The folks waiting patiently for these have been seriously cool with waiting so far. I've not heard a peep about it taking 3-4 months to develop. That said, I kinda put my own schedule on this and I wanted to be done by end of March. Day job responsibilities have been taking chunks out of the time I've been putting into this lately so I'm falling behind on my personal schedule. The last thing I want to happen is drag this thing out to the point where people start questioning the project, or start thinking it's going to be another RM 6-8 month wait.. It's just a lot of little loose-ends that need to be tied up or trimmed. I definitely want this to be pretty modular, but I don't really have an issue making two products, a DAC in a box and an ADC in a separate box if folks think that might be the way to go. I also don't have a problem trying to work out having a modular setup with both boards in a box either, it's just going to take a bit more time to write and debug that code.
|
|
kcatthedog
Temp
Super Helpful Dude
Posts: 16,043
Member is Online
|
Post by kcatthedog on Mar 17, 2015 12:00:10 GMT -6
I think you will find people will want one of those 3 configurations.
|
|
|
Post by svart on Mar 17, 2015 12:01:04 GMT -6
IF one wanted this unit's DAC to be used for your print track, then don't you need it to be master clock or isn't that arguably preferred ? I am with Tony or let people decide but wouldn't you want to have only one type of functionality out thee in the field, 4 permutations could drive people crazy The DAC should always be a slave to the incoming SPDIF signal. Retiming an extracted clock from the SPDIF signal is tricky and hard to do correctly, and can lead to timing slip, which manifests as pops and clicks here and there in the audio. Most of the time you can't properly jitter clean the extracted clock without leading to slipping some data. unfortunately that is the nature of embedded-timing data streams like AES/MADI/SPDIF, etc.
|
|
|
Post by svart on Mar 17, 2015 12:05:17 GMT -6
I think you will find people will want one of those 3 configurations. I think the goal for most folks is to have the ADC/DAC combo. Some folks have expressed interest in starting with either the ADC or DAC boards and adding the other later. That was also my initial desire, to have folks add the missing card later to save space and money, but since I'm not a firmware writer, it's proving more difficult to implement. I still want to do it though. Here's what I hope to accomplish: ADC standalone.. Upgrade to ADC master/DAC slave by inserting DAC board DAC standalone.. Upgrade to DAC master/ADC slave by inserting ADC board ADC Master/DAC slave
|
|
|
Post by svart on Mar 17, 2015 12:17:36 GMT -6
I think the biggest point of contention is the pin setup on the microcontroller. I need the firmware to self-check and then set itself up based on the board that it's loaded onto, and then only run the routines that are required for that board. That means changing the assignments of the pins too.
I'll have to add a lot of bits for storing settings across the boards rather than running them in the loops.
|
|
|
Post by formatcyes on Mar 17, 2015 14:46:44 GMT -6
Release what you have and just be open about it's limitations. As long a everyone knows exactly what you are offering no problem.. I just want a great AD NOW...
|
|
|
Post by LesC on Mar 17, 2015 15:13:12 GMT -6
The folks waiting patiently for these have been seriously cool with waiting so far. I've not heard a peep about it taking 3-4 months to develop. That said, I kinda put my own schedule on this and I wanted to be done by end of March. Day job responsibilities have been taking chunks out of the time I've been putting into this lately so I'm falling behind on my personal schedule. The last thing I want to happen is drag this thing out to the point where people start questioning the project, or start thinking it's going to be another RM 6-8 month wait.. It's just a lot of little loose-ends that need to be tied up or trimmed. I definitely want this to be pretty modular, but I don't really have an issue making two products, a DAC in a box and an ADC in a separate box if folks think that might be the way to go. I also don't have a problem trying to work out having a modular setup with both boards in a box either, it's just going to take a bit more time to write and debug that code. I agree with Tony that I want you to take the time you need to get this right. There is no comparison here to waiting for an RM unit. In your case, we're looking at complete design, testing, parts sourcing, building, debugging, software development, etc. Once all that is done, and you've sold out all you've built, then from that point on people will be making the RM build-time comparisons. My only concern is getting a top-notch unit, I'm willing to wait as long as it takes. I also would like to avoid separate boxes for the DAC and the ADC, one box if possible please! Personally, I don't think I would ever order the box without both DAC and ADC, even if I only really needed one or the other at the time, I'd find a use. From my own personal selfish point of view, I wish we could see a UA2192 equivalent eventually, with a great DAC and a great ADC and an ADAT interface in one box, but I'm hoping that might happen in the future after you're wildly successful with your initial design.
|
|
|
Post by Martin John Butler on Mar 17, 2015 15:37:02 GMT -6
I'm most interested in a two way solution, ADC/DAC.
|
|
|
Post by Johnkenn on Mar 17, 2015 17:44:04 GMT -6
So - you mean use the DAC as a master clock for all the other digital components? Isn't that unusual? Isn't that usually handled by the ADC? If that's the case, I wouldn't worry about it.
|
|
|
Post by svart on Mar 17, 2015 18:18:22 GMT -6
So - you mean use the DAC as a master clock for all the other digital components? Isn't that unusual? Isn't that usually handled by the ADC? If that's the case, I wouldn't worry about it. I mean internal to the unit. Only one of the boards can be the master and has to control the other boardand lcd.
|
|
|
Post by tonycamphd on Mar 17, 2015 19:17:19 GMT -6
The folks waiting patiently for these have been seriously cool with waiting so far. I've not heard a peep about it taking 3-4 months to develop. That said, I kinda put my own schedule on this and I wanted to be done by end of March. Day job responsibilities have been taking chunks out of the time I've been putting into this lately so I'm falling behind on my personal schedule. The last thing I want to happen is drag this thing out to the point where people start questioning the project, or start thinking it's going to be another RM 6-8 month wait.. It's just a lot of little loose-ends that need to be tied up or trimmed. I definitely want this to be pretty modular, but I don't really have an issue making two products, a DAC in a box and an ADC in a separate box if folks think that might be the way to go. I also don't have a problem trying to work out having a modular setup with both boards in a box either, it's just going to take a bit more time to write and debug that code. I agree with Tony that I want you to take the time you need to get this right. There is no comparison here to waiting for an RM unit. In your case, we're looking at complete design, testing, parts sourcing, building, debugging, software development, etc. Once all that is done, and you've sold out all you've built, then from that point on people will be making the RM build-time comparisons. My only concern is getting a top-notch unit, I'm willing to wait as long as it takes. I also would like to avoid separate boxes for the DAC and the ADC, one box if possible please! Personally, I don't think I would ever order the box without both DAC and ADC, even if I only really needed one or the other at the time, I'd find a use. From my own personal selfish point of view, I wish we could see a UA2192 equivalent eventually, with a great DAC and a great ADC and an ADAT interface in one box, but I'm hoping that might happen in the future after you're wildly successful with your initial design. this^ is a GREAT point, everyone here is watching you build this, imaginations aren't drifting to "why the hell is this taking so long"(which it isn't), everyone is watching it happen right in front of their eyes, it's totally impressive and pretty ridiculously exclusive to watch someone birth and bring a product to life right before your eyes in real time! Seriously, these are amazing times we live in! 8)
|
|
|
Post by Johnkenn on Mar 17, 2015 19:28:17 GMT -6
Plus, nobody has ponied up any dough either.
|
|
ericn
Temp
Balance Engineer
Posts: 16,096
Member is Online
|
Post by ericn on Mar 22, 2015 21:48:49 GMT -6
I think YOU need to sit back take a deep breath and figure out what You need to do both financially and product wise! YOUR the one who's invested YOUR time and money in this!
|
|