Go Back   Home > Forums > Blogs > abraxalito

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Rate this Entry

I2S transcoder

Posted 7th July 2013 at 12:57 PM by abraxalito
Updated 16th September 2013 at 01:32 AM by abraxalito (Schematics added, pic of 2nd build added)

Here's a circuit that's been a long time in gestation - some logic that converts I2S from 64fs (32bits per sample) down to 32fs (16bits).

Almost all the S/PDIF receiver chips nowadays output a bit clock at 64fs (2.8MHz for RBCD) because the format has the potential to support up to 24bits. When being driven from a CD player though, there's no chance of any useful information occupying those spare bits. As my interest is to run all signals as slow as possible to keep noise to the absolute minimum, 64fs to me is profligate generation of RF when 32fs will do the job. But only the WM8805 supports this format and then only when software programmed.

The other reason for wanting the slower bit clock is that my LAID design relies on shift registers and the 32fs clock gives me twice as good utilization of the serial storage - no bits are being wasted on zero padding.

This circuit is designed to do the job with the fewest standard logic chips I could manage it with - 8, at a total cost around $1. The 'traditional' way to implement such a design would be via serial-parallel and then parallel-serial conversion at half the original clock speed but the number of chips needed to go this route would be higher, mainly because latency is being introduced in the conversion to parallel, latency means storage and storage means chips. Here I present a way of doing this 'on-the-fly' with reduced complexity owing to the omission of any conversion to parallel. If for any reason you're concerned about latency (I'm not), then I reckon this is the lowest latency solution

The central core is 16 bits of shift register (two HC595s) with outputs tapped off into an 8-way mux (HC4051). 5bits of counter (HC161 plus a f/f) keep the mux and other logic sync'd to the incoming audio and increase the operative delay on a clock-by-clock basis. The result is a 'time stretching' function on the incoming datastream

Initial listening tests into a TDA1387 DAC give a more involving sound than when fed with 64fs but I'm blowed if I can put my finger on what the differences are. Needless to say I'm not going to feed any 16bit DACs in future with 64fs

Schematic notes......

IC list 74HC595 * 2; 74HC161; 74HC4051; 74HC86; 74HC04; 74HC74 * 2

For clarity, not all pins are shown. HC74 set/reset (1,4,10 & 13) to logic 1 when not shown. Preset pins on HC161 (3-6) are don't care, enables (7,9 & 10) to logic 1. HC595 MRs (10) to logic1. Unused inputs on logic gates should be tied to 0 or 1.

Update - I've added a photo of the 2nd build - here I've modified the design very slightly to accomodate the EIAJ serial format used by the TDA1545A. One HC74 has been replaced by an HC175 giving the extra cycle of delay to WS. I've also added an HC86 as a buffer stage, so the total's now 9 chips.

Incidentally I just used the SDcard player as a test bed for verifying its operation - I haven't noticed any SQ changes in driving the TDA1543. Recommended for CMOS DACs only
Attached Thumbnails
Click image for larger version

Name:	I2Slogic1.JPG
Views:	346
Size:	69.0 KB
ID:	1110   Click image for larger version

Name:	I2Slogic2.JPG
Views:	233
Size:	63.1 KB
ID:	1111   Click image for larger version

Name:	P3110065.JPG
Views:	172
Size:	673.7 KB
ID:	1134  
Views 1193 Comments 28 Email Blog Entry
Total Comments 28

Comments

  1. Old Comment
    fas42's Avatar
    Very nice little experiment - reminds me of an exercise I did some years ago, interfacing a CD player without volume control to the power amp with minimal circuitry. I steer well clear of preamps, and the PGA2320 volume chip looked like it might be an answer which was relatively transparent.

    I didn't want to go down the microcontroller route - extra complexity, and the concern with digital fidgeting injecting noise, even though theoretically the processor chip could be put to sleep. So, implemented the logic totally in 74 series chips - just a rough breadboard with spare wallwart power supplies, and a couple of buttons, for Up and Down volume.

    Worked quite nicely, considering rough power supplies, demonstrated to me that these volume chips are better than the better pots and perhaps, switching attenuators ...

    Frank
    permalink
    Posted 9th July 2013 at 10:36 AM by fas42 fas42 is offline
  2. Old Comment
    abraxalito's Avatar
    Its not just in theory that micros can be put to sleep - though with today's ARM chips the sleep mode isn't the lowest power as it keeps certain clocks running.
    permalink
    Posted 9th July 2013 at 11:59 AM by abraxalito abraxalito is offline
  3. Old Comment
    Certainly an interesting circuit abraxalito!

    I've recently been thinking about a circuit for sample clock for a SAR 1MSPS ADC ... it's data output is i2c/spi and the only hard part is to generate a single pulse to trigger sample then hold the sample pulse line low until after data is read.

    I've been looking at binary counters and similar to achieve this from an OSC. Not come to an idea that I'm happy with yet. The propagation delay uncertainty on counter ICs looks a bit hairy and I'm not convinced I could achieve better with discrete logic gate (NOR, NAND, AND, inverter plus a bunch of flip flops would be needed) chips.

    NXP says @5V to expect 20 - 35ns or @2V 60-190ns roughly for the HC161. That variance concerns me.

    Have you done any analysis of the variation of those times and the impact on your circuit?
    permalink
    Posted 9th July 2013 at 01:17 PM by hochopeper hochopeper is offline
  4. Old Comment
    fas42's Avatar
    Hmmm, I wouldn't be happy unless all clocks stopped ticking - but, there are always ways of achieving a complete shutdown of unnecessary electrical activity, so it's not really ultimately a problem.

    Nice that you got the improvement with the slowdown - wouldn't it be great if one could insert an impressive metric of 'quality', rather than use expressions like "more involving sound" - might get a few people around here to tune in a bit more ...

    Frank
    permalink
    Posted 9th July 2013 at 01:21 PM by fas42 fas42 is offline
  5. Old Comment
    abraxalito's Avatar
    Quote:
    Originally Posted by hochopeper View Comment
    Have you done any analysis of the variation of those times and the impact on your circuit?
    No, I haven't - the part I have is from TI and it only shows the maximum tp along with one typical. What was the concern you had - that it would vary over time/temp or part-to-part variations? I guess there'll be some jitter introduced but I haven't had any problems so far with jitter affecting SQ with my DACs.
    permalink
    Posted 9th July 2013 at 02:41 PM by abraxalito abraxalito is offline
  6. Old Comment
    Quote:
    Originally Posted by abraxalito View Comment
    No, I haven't - the part I have is from TI and it only shows the maximum tp along with one typical. What was the concern you had - that it would vary over time/temp or part-to-part variations? I guess there'll be some jitter introduced but I haven't had any problems so far with jitter affecting SQ with my DACs.
    Variation over time was my concern, the variation from NXP is for t=25degC.


    For a 20bit ADC at 1MSPS I believe jitter will need consideration to ensure that it doesn't limit the SNR of the measurement ...

    (not recording audio, just fooling around with the idea for a DIY electronics measurement tool)
    permalink
    Posted 9th July 2013 at 11:34 PM by hochopeper hochopeper is offline
  7. Old Comment
    abraxalito's Avatar
    I saw your posting on the DIY ADC thread, this topic interests me as I plan to develop an SAR-based ADC at some point in the future - primarily for measurement purposes, but eventually for recording.

    I don't believe that the figures in the DS about the variation of tp have much to do with short-term variation (i.e. jitter). I agree jitter's a concern - best addressed by using faster logic for this purpose. The lowest jitter logic is probably bipolar, or build this part yourself using discretes. For myself I'd probably kick off with something like LVC (low voltage CMOS) logic and then characterize the performance to see how much jitter was happening in practice.

    If you're concerned about variation over time, that's over a rather long timescale I reckon so you feel jitter down to sub-millihertz is a matter of importance? I know Jocko says its important down to 0.1Hz...
    permalink
    Posted 10th July 2013 at 02:42 AM by abraxalito abraxalito is offline
  8. Old Comment
    Quote:
    Originally Posted by abraxalito View Comment
    I saw your posting on the DIY ADC thread, this topic interests me as I plan to develop an SAR-based ADC at some point in the future - primarily for measurement purposes, but eventually for recording.

    I don't believe that the figures in the DS about the variation of tp have much to do with short-term variation (i.e. jitter). I agree jitter's a concern - best addressed by using faster logic for this purpose. The lowest jitter logic is probably bipolar, or build this part yourself using discretes. For myself I'd probably kick off with something like LVC (low voltage CMOS) logic and then characterize the performance to see how much jitter was happening in practice.

    If you're concerned about variation over time, that's over a rather long timescale I reckon so you feel jitter down to sub-millihertz is a matter of importance? I know Jocko says its important down to 0.1Hz...

    Yeah I guess my comment on variation over time is a rather poor choice of words. I just meant that without an understanding of how that distribution is made up its a bit hard to know.

    Knowing your passion for ARM processors, I think you'll be even more interested when you know that I'm planning on sending it all into an ARM AM3359 (perhaps via the PRU-ICSS if necessary)

    A bit more reading and thinking to do at my end so I'll leave you to get back to i2s transcoding discussion
    permalink
    Posted 10th July 2013 at 11:58 AM by hochopeper hochopeper is offline
  9. Old Comment
    abraxalito's Avatar
    Ah I see that ARM is well above my station being an A8. I don't consider TI being true believers in ARM either - they have prevaricated over M4s for what seems like an eternity because they are scared of cannibalizing themselves (their own DSP business). No matter, others truly dedicated to ARM for DSP are inexorably eating their business....

    I reckon at 204MHz the LPC4320 (Cortex M4) would be fast enough to do useful work from a 1MHz ADC. Why go so far as an A8?
    permalink
    Posted 11th July 2013 at 04:41 AM by abraxalito abraxalito is offline
    Updated 11th July 2013 at 04:45 AM by abraxalito
  10. Old Comment
    OK, I’m not an EE. I spent my career writing software. I’m retired now and I trying to learn how digital circuits work. Maybe I’m missing something but I don’t see how your I2S Transcoder can do anything useful. Did you really build it?
    permalink
    Posted 15th September 2013 at 07:52 PM by Tam Lin Tam Lin is offline
  11. Old Comment
    abraxalito's Avatar
    Yep - have built two incarnations now. I found my schematic has an error which I'll get around to correcting sometime, especially if anyone else wants to build it.
    permalink
    Posted 16th September 2013 at 01:09 AM by abraxalito abraxalito is offline
  12. Old Comment
    Indeed, the design has a gross error. You’re lucky it works at all. You’re latching the I2S data on the falling edge of CLK. That’s when the data is changing and there is a lot of unrelated circuit noise. The data should be latched on the rising edge when the data is stable and most of the surrounding gates are quiet.

    You’re handling of OE1/OE2 is a kludge. A wise engineer once posed this question to me: “When is a clock not a clock?” Answer: “When it comes from combinatorial logic.” TC is not a clock! If you need more bits use a wider counter.

    You say you want to minimize circuit noise, RF, etc., yet you have a string of 5 inverters. One inverter is enough to do the job. Relying on propagation times to adjust the timing means the design is broken: Fix the design. Hacks like that have no place in clocked logic.

    It may be clever but your transcoder is overly complex and poorly implemented. If your goal is the least number of standard logic chips then you missed the mark. I’m sure it can be done using fewer chips. I’ll post my solution when I have time.
    permalink
    Posted 17th September 2013 at 07:52 AM by Tam Lin Tam Lin is offline
  13. Old Comment
    abraxalito's Avatar
    Thanks for the comments - I look forward to seeing your fewer chip design, however I'm not holding my breath. I'm happy with all my kludges, I don't deny they're kludges but my aim wasn't to produce a design which passes muster as 'proper' synchronous logic.

    Incidentally its not 'you're' rather 'your' - ironically, this is an example of the kinds of comments you've made about my design. You could patch your English to correct this mistake, just as I could patch my design to address my kludges. I can't see the point though, can you?

    Back to your original remark - you still can't see how it does anything useful? Or have you now seen the light?
    permalink
    Posted 17th September 2013 at 08:51 AM by abraxalito abraxalito is offline
    Updated 17th September 2013 at 08:58 AM by abraxalito
  14. Old Comment
    The I2S spec says nothing about the data setup and hold times relative to the falling edge of the bit clock. Your circuit could be latching the data from the previous frame, the following frame, or garbage. I say it's not useful unless it works, as intended, with all implementations of I2S. The fact that you had to add an additional cycle of delay proves my point.

    My version of the transcoder: Four chips and ZERO latency! I haven't built it because I have no use for I2S. I just enjoyed the challange. All I have is an anotated timing diagram. I hope you can figure it out.

    Click the image to open in full size.
    permalink
    Posted 19th September 2013 at 06:40 AM by Tam Lin Tam Lin is offline
  15. Old Comment
    abraxalito's Avatar
    I haven't tried to figure it out as your design fails on a number of points unrelated to whether it works as advertised. Let's assume that it does, however the power budget rules it out. Having looked at the DSs, the current draw for the total will typically be in excess of 100mA. Bear in mind that this design would typically be paired up with an S/PDIF receiver chip - they tend to run on 10-20mA typically so its power budget is way out of line with how it'll be used.

    The second point it fails on is chip cost - a quick scan of TI shows you've spent slightly over $20 on your four chips. That's taking chips at 100+ prices (1k+ in the case of the 804), DIYers tend to order much smaller quantities.

    Thirdly it fails as a DIY design because of lack of wide availability of the ALS804. According to TI, its only available in Asia but the link they supplied to a distributor did not work so I was unable to verify that.

    I disagree with your claim that its (my design I'm speaking of now) only useful if it works with all I2S implementations, I'd observe its useful when functional. Its posted up here in the hope that if it turns out not to work in some implementations, I'll figure out why and the design will evolve.

    So in conclusion, I accept you win on chip count, however your design loses on other major parameters, assuming that it does indeed work when built.
    permalink
    Posted 19th September 2013 at 02:16 PM by abraxalito abraxalito is offline
    Updated 19th September 2013 at 02:19 PM by abraxalito
  16. Old Comment
    What planet do you come from? Findchips shows 35,183 ALS804 available from distributors, worldwide. In the US there are 705 ready to ship, in prototype quantities, from Avnet, Newark, Mouser, and Digikey, 157 in the EU from Farnell, and 173 in Asia from Element 14.

    I chose the ALS parts because my goal was the lowest chip count and ALS has a higher ‘functional density’ than CMOS. I did a couple different variations with all CMOS but the chip count was higher. Incidentally, if you are willing to accept RC one-shots, I am not, you can eliminate the HCT74. If you took the time to understand my circuit you would realize the ALS804 can easily be replaced with a HCT08 and HCT04.

    Regardless, latching a data bit on the falling edge of the bit clock is bad practice. And when transcoding in real-time, zero latency is best.
    permalink
    Posted 21st September 2013 at 08:37 PM by Tam Lin Tam Lin is offline
  17. Old Comment
    Update: I priced a 5-chip CMOS version of my transcoder. At quantities of 1 each, from US distributors that have the chips in stock, the total price is $6.05. Doing the same pricing for your original 8 chip version, the total is $1.14. For an additional Lincoln I’d prefer the design that follows best design practice and has zero latency. If you want to cling to your demonstrably faulty but less expensive kludge, so be it.
    permalink
    Posted 21st September 2013 at 11:30 PM by Tam Lin Tam Lin is offline
  18. Old Comment
    abraxalito's Avatar
    You're welcome to cling to your noisy, expensive low chip count paper design if you wish. I'll continue to listen through a quiet and cheap one.

    Just as an aside, and this is most likely casting pearls before swine - if you'd like people to take time over understanding your designs, make them relevant to the context. Your approach is rather like the 'objectivist' amplilfier designers (Doug Self springs to mind) who go all-out on THD measurements but don't realize that amplifiers are to be listened through. So here you took chip count as an over-arching priority, despite noting in an earlier comment that I'm concerned about RF noise. Designs are an optimization process over all parameters not just the parameter the designer happens to like at the time. Since you used to be a software engineer I'd recommend 'The design of design' as a book you might gain insight from, from the writer of my favourite software book (Fred P Brooks).
    permalink
    Posted 21st September 2013 at 11:40 PM by abraxalito abraxalito is offline
    Updated 22nd September 2013 at 12:22 AM by abraxalito
  19. Old Comment
    fas42's Avatar
    Good ref, Richard - I've picked up the gist of what he talks about from a number of reviews - and having been in the software game many years can only nod my head vigorously in agreement with his approach.

    Interestingly, I was fortunate enough to be able to work like that over my whole career - I always had full control over design, and implementation of all projects - the spiral, or iterative, evolutionary method was instinctive for me. The key was having an excellent relationship with the crucial, knowledgeable and highly motivated, individual on the customer side ...
    permalink
    Posted 22nd September 2013 at 02:15 AM by fas42 fas42 is offline
    Updated 22nd September 2013 at 02:18 AM by fas42
  20. Old Comment
    abraxalito's Avatar
    Yes Frank, spot on there with your remark about the excellent relationship with the customer being crucial. Such a relationship maintains the reality - that its not about the numbers I can get (ego trip stuff), rather how many of the customer's requirements I can fulfill.

    Speaking of the numbers game style of designing, Bruno's another one doing this. Over on his Mola-mola blog he admits getting the final few ppm out of the distortion figure he was getting for his DAC 'is a matter of pride' (i.e. ego). If he asked himself 'which customers will I lose if I leave it as it is?' he might be prompted to ponder further what the point of it was and whether by the excessive devotion to this single metric he was swallowing a camel while straining out his gnats.....
    permalink
    Posted 22nd September 2013 at 06:55 AM by abraxalito abraxalito is offline
 
Hide this!Advertise here!

New To Site? Need Help?

All times are GMT. The time now is 04:39 AM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright ©1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2