Jump to content


  • Content Count

  • Joined

  • Last visited

  1. I wouldn't use pwm. What does 60ms work out as distance? Also, if you're calculating whilst measuring distance then you may have the problems you describe unless you've taken steps to ensure the current measurement doesn't affect the calculation of the previous measurement.
  2. The operation is the same regardless of what processor is used. Those ultrasonic modules have been around well before the Arduino. Basically you give the module a 10uS pulse to send the ping then measure the time for the return. The arduino code should work in energia.
  3. Atx power supplies conform to a standard. Yes, they are regulated. They may require a minimum load on the outputs in order to work correctly. Be aware these power supplies can output a number of amps so ensure your wiring is adequate otherwise you may have a possibility of fire.
  4. From what i can recall, you have a 32bit timer or two 16 bit timers A and B. So, i would say the answer is no.
  5. Here's a spectrum emulator. Should be easy to port.http://mikrocontroller.bplaced.net/wordpress/?page_id=2736
  6. I was joking regarding Nina Hagen! You will need to change the clock setup in the code. The actual cpu will run at a multiple of the crystal frequency. For the timers you would choose the crystal frequency as the source. You would setup one of the timers to divide your crystal frequency and output it on an associated pin. For the spi you can choose your clock source and prescaler to suit. If you set the timer for your 44.1kHz to interrupt, the code for this interrupt would load the spi with the data you want to send from a memory buffer. Alternately, it could trigger the dma to do it for you. In the background you read the data from the sdcard (or usb stick) and keep the buffer topped up. You should have enough time to update the user interface and respond to inputs. Read the user manual for the stm32f4 - it's only a thousand pages or so........
  7. The stm32f429 disco board already has the touch screen lcd. It has usb host, so you can use a usb memory stick instead of a sd card. Why do you think lvc161 would have less jitter than the counters in the stm32f429? As i said before, the silicon in the stm32 is faster than the lvc161. Again, if the cpu is clocked from the magic oscillator, its timers can do the division for you synchronously. You can also use the stm32 pwm outputs to vary the grid bias on the 12AX7. You would most likely use the spi peripheral to output the bits. Since your worried about jitter, how are you going to manage the layout of your circuit? Do you know what 1ps is in distance relative to the speed of light? Not much, i can tell you. So you will need to ensure the output latch clock signal to the 595s is equal in distance otherwise you'll get clock skews on the data output to the dac. Nina Hagen wont sound quite as good as we would like.
  8. It's interesting how the tda1541 only implemented the hi 10 bits as a resistor ladder but used charge balancing techniques for the least sig bits. Why would you not do that? It's bound to be more accurate than using discrete resistors. I think philips were trying to tell us something. Never outside of automotive circles have i read so much unsubstantiated rubbish. Clearly the people that rabbit on about the type of capacitors have NFI. I think it is time for you to start some experimentation as i'm answering your questions but you're not really grasping what i'm saying. It will become clear as you actually start to do something. What you're want to do is highly complex, so be prepared for a challenge.
  9. I think you misunderstand how the hc595 works. You can clock the bits in at any rate as long as it is faster than the update rate. The outputs do not change until you toggle the output clock. The output clock is the critical one. Therefore the processor can be the source of the bit clock. As i've said before - you can probably feed your low jitter oscillator to clock the cpu. The cpu timers can divide the clock to generate the 44.1kHz output clock. This is your master clock divided by 256. So putting your master clock close to the dac is of little consequence - you still need to divide it down by some method - be it a hc4040 ic or a cpu timer peripheral. The stm32f429 has a sdio interface - this is much faster than using the spi for the sdcard. Even so, many cpus have multiple spi ports these days, so you would have separate spi for sd card and dac. Mosfets have gate capacitance and many of their parameters are temperature dependent. It won't help the glitching. Linearity (actually monotonicity) is the critical performance parameter of a dac - if it has poor performance in this regard, it will introduce significant distortion and artifacts to the sound. I think you've got a bit of learning ahead. Funnily enough, i was fixing a 90's digital synth with a tda1541 dac tonight.
  10. Phase jitter is the least of your worries. If you were using a pll to multiply or divide your frequencies, then yes, phase jitter is a concern. As an engineer, one has to qualify and quantify - what is the problem and how big is it. So what is the phase jitter on a standard crystal oscillator? How does this relate to your phase noise spec? Since you cant measure it, be sure not to chase ghosts. In the link you gave there is the argument between the golden ear brigade and engineers. This is akin to a religious argument. The reality is that you want to reproduce the original analog signal as faithfully as possible. To do this you need to mirror the digitising process. Unfortunately they didn't use discrete dacs to digitise the signal and they did use filters and sample and holds. What we do know is your discrete dac will glitch - and it is easy to measure. Nothing in this world is perfect - even though your 595's are all clocked the same - the outputs wont all change at the same time. This is why you need a sample and hold. You also need a reconstruction filter to get rid of the discrete steps in the output. These steps give you audible artifacts that are easy to hear and measure - even with a PC sound card spectrum analyser. No buffer on the output of the dac! What about the impedance of the amplifier? The load presented will vary with frequency thus causing more problems. So back to your specific question - you can slave the spi to and external clock, but how would you synchronise the data to the 595s? I think it would be much easier to run the cpu off your crystal oscillator. The cpu has timers that can divide the clock and generate synchronous signals. Besides, the stm32 silicon is faster than the 595 silicon. I've yet to read the stm32f429 datasheet yet - my disco board will turn up tomorrow. My advice is to work with smaller challenges - prioritise your problems and don't try to make the whole thing in one go- otherwise you'll go around in circles. This is complex stuff - even for experienced people.
  11. I did a bit of Googling - http://www.diyaudio.com/forums/digital-line-level/206258-diy-discrete-r-2r-ladder-dac-serial-data-demultiplexing.html seems I wasn't far from the mark. Besides, if you're worried about the sound - everyone knows that digital is crap - you need an expensive turntable and a valve amplifier with oxygen free copper wires facing towards Mecca. Other boards might be the STM32F429 disco - it has a display on it already. I haven't read enough of the datasheet to see if you could use the 11.xxx MHz source as a clock - you might need to divide it by 2 and the STM32 internal PLL will multiply it up to 100+MHz for the cpu. Exactly how will you generate the 11.xx MHz with low phase jitter? The DAC is going to be so poor in performance that phase noise will be the least of your problems. As I said before - the only critical timing is the latch for the dac output - as long as everything gets the data out in time, it doesn't have to be synchronous.
  12. Well, I think you'll learn some lessons along the way. Just the thermocouple effects will equate to a couple of bits of resolution - unless you run a higher voltage, say 10 volts. I think you really don't understand how the sd card works. First up, whilst the clocking of the bits is synchronous, the reading of the sector is not necessarily so - it has an internal controller that tells you when it's ready. Since the memory technology requires error detection and correction, the controller may take a variable amount of time to do this. Next is the file system - if you choose to use FAT32 file system, you need to read the FAT table for each cluster, so this means you need to do extra reads and computation to find out the next sector to read in the file. As such, this is not a problem - you buffer the data in memory (circular buffer). As for clocking out the data to the shift registers, this does not have to be synchronous - you can clock your 32 bits at any speed you like - as long as it happens within the sample period. The sample clock is the critical one. As to what processor you choose - well there's many. Reading a sd card and pumping the bits out the spi port is quite easy. A cheap TIVA board would do this and you could use Energia to program it.
  13. As for reading the data synchronously from the sd card - forget it. You can only expect to read the data from the sdcard asynchronously and use a circular buffer to negotiate the sync output rate from the async input data. Even cd players buffer the data.
  14. I'm sorry to sound negative, but even with 0.01% resistors the hc595s arent up to the task. You also will have thermal issues - keeping all your precision resistors isothermal will be fun. There's a number of fundamental issues you're up against. I really don't think you'll achieve 16 bits of resolution. And how will you be able to measure it?
  • Create New...