Your parts look very clean, I can clearly read their marking codes, as you didn't used too much flux and isopropyl alcohol to clean the board. Don't be affraid to use more flux. I would recommend you to put more flux on all 4 sides of FPGA, then use your soldering iron to resolder every pin. You don't need much solder on the iron tip, because all the pins already have it. After that clean both top and bottom sides of board using a brush and isopropyl alcohol - a tooth brush can be used, then measure it again.
I have removed the EEPROM and that made no difference so I can fairly confidently say that the FPGA is toast. (I did also reflux and run the iron over the pins, etc, as described above)
I suspect I know what went wrong and that was down to a stupid mistake I made by rushing and not giving enough concentration to the task.
I had originally connected the PCM2DSD to the Transporter using LVDS modules. The receiver being powered by the 3.3v from the PCM2DSD's ADM7150. So far so good. However, when I had issues with the MCLK I stupidly tried to "simplify" the setup by attaching the PCM2DSD directly into the I2S lines from the Transporter.
HOWEVER, it's been such a long time when most logic is 3.3v that I completely didn't remember that the Transporter is so old that it might use 5v logic. D'oh!
In fact it does. 😱
So I had stuffed 5v into the 3.3v pins of the FPGA. I would've expected that the inputs might burn but taking the whole FPGA out was unexpected but I guess perhaps some protection diodes have blown or something?
So I'm kicking myself for the waste of all that effort and time, it just goes to show how important taking a step back and thinking everything out is.
The good news is that the Transporter is still fine and I can scavenge the ADM7150 off the failed board so really it's just the FPGA to pay out for. Plus I will need to level shift the I2S signals from the Transporter into the LVDS transmitter module since it is also 3.3v logic.
I suspect I know what went wrong and that was down to a stupid mistake I made by rushing and not giving enough concentration to the task.
I had originally connected the PCM2DSD to the Transporter using LVDS modules. The receiver being powered by the 3.3v from the PCM2DSD's ADM7150. So far so good. However, when I had issues with the MCLK I stupidly tried to "simplify" the setup by attaching the PCM2DSD directly into the I2S lines from the Transporter.
HOWEVER, it's been such a long time when most logic is 3.3v that I completely didn't remember that the Transporter is so old that it might use 5v logic. D'oh!
In fact it does. 😱
So I had stuffed 5v into the 3.3v pins of the FPGA. I would've expected that the inputs might burn but taking the whole FPGA out was unexpected but I guess perhaps some protection diodes have blown or something?
So I'm kicking myself for the waste of all that effort and time, it just goes to show how important taking a step back and thinking everything out is.
The good news is that the Transporter is still fine and I can scavenge the ADM7150 off the failed board so really it's just the FPGA to pay out for. Plus I will need to level shift the I2S signals from the Transporter into the LVDS transmitter module since it is also 3.3v logic.
I am assembling another PCM2DSD and I am wondering whether to supply the AMS1117 from the output of the 3.3v regulator (FB3) or from the incoming 5v (FB2).
I would assume that cascading it from the 3.3 reg would be superior? Why is the choice given? What is gained or lost for each option please?
I would assume that cascading it from the 3.3 reg would be superior? Why is the choice given? What is gained or lost for each option please?
AMS1117 is not as high performance as ADM7150. Maybe it would help AMS1117 PSRR if its used with a pre-regulator?
I presume the choise was given for a potential heating emergency. Feeding AMS1117 from 5V means much more heat just under FPGA. Feeding it from ADM we have the same heat, but it will be shared between AMS and ADM PCB regions.
OK, well I've used the pre-regulated mode now and all parts fitted apart from the Spartan, which I have ordered but will take some time.
3.3v and 1.2v spot on, no smoke!
I have realized that the LVDS sender module that I have uses the DS90 chip from TI and according to the data sheet can take up to 6v on Vcc. So I will be able to run the sender from the Transporter 5v and the receiver from 3.3v and so both ends will be happy. I will not have chance to try this for a while but I am more confident now that I understand what went wrong and there is an elegant solution.
3.3v and 1.2v spot on, no smoke!
I have realized that the LVDS sender module that I have uses the DS90 chip from TI and according to the data sheet can take up to 6v on Vcc. So I will be able to run the sender from the Transporter 5v and the receiver from 3.3v and so both ends will be happy. I will not have chance to try this for a while but I am more confident now that I understand what went wrong and there is an elegant solution.
I have successfully connected the "output" LVDS module to the Transporter I2S and the receiver to 3.3v and the signals look good and will be ready to go once I get the new Spartan.
I have a question relating to the I2S input format that the FPGA code is accepting.
The Transporter designers, for best reasons known to themselves implemented a slightly odd variant of I2S where the MSB comes on the first BCLK after the LRCLK change (rather than delayed by 1 BCLK)
The AKM4396 DAC that they used supports this mode (mode2), obviously but when I came to interface to TDA1541A I had to introduce some D flipflops to delay the data by one BLCK otherwise I was losing the MSB.
I can use the same logic that I have now to interface to the PCM2DSD but my worry is that currently I do not do anything with MCLK since the TDA1541A didn't require it. So the logic I have will delay the BLK (and data) by 2 gate delays but the MCLK will be unchanged. (74HC gates) Will this matter to the PCM to DSD conversion within the FPGA?
As an alternative, would it be possible to modify the FPGA code to interpret the MSB as happening on the LRCLK? That would obviously be far more elegant but I'm guessing that is way outside my pay grade!
I have a question relating to the I2S input format that the FPGA code is accepting.
The Transporter designers, for best reasons known to themselves implemented a slightly odd variant of I2S where the MSB comes on the first BCLK after the LRCLK change (rather than delayed by 1 BCLK)
The AKM4396 DAC that they used supports this mode (mode2), obviously but when I came to interface to TDA1541A I had to introduce some D flipflops to delay the data by one BLCK otherwise I was losing the MSB.
I can use the same logic that I have now to interface to the PCM2DSD but my worry is that currently I do not do anything with MCLK since the TDA1541A didn't require it. So the logic I have will delay the BLK (and data) by 2 gate delays but the MCLK will be unchanged. (74HC gates) Will this matter to the PCM to DSD conversion within the FPGA?
As an alternative, would it be possible to modify the FPGA code to interpret the MSB as happening on the LRCLK? That would obviously be far more elegant but I'm guessing that is way outside my pay grade!
Are you planning on using AK4396 for this? If so, doesn't look like it is designed to support DSD256?
Hi Mark, sorry no, I mentioned the AKM4396 since that is what is in the Transporter (and which I don't use as it sounds terrible!). However, the Slim Devices guys were designing their FPGA/CPLD logic to talk to that DAC, hence when I tap into the I2S I needed to know their format (and change it for the TDA1541A, which I do use but I will also output to LVDS to then pass to a 2nd box which will house the PCM2DSD and Marcel's RTZ DAC.
In this way I can keep my TDA1541 outputs and also have the RTZ DAC to compare with. (The TDA1541A stuff took me a lot of effort to implement so I'm not wanting to trash it, although Marcel's DAC wipes the floor with it, far more than I was expecting)
That is because it is not I2S. There are no variants. It is called Left or MSB justified data.
Can the Transporter work with DSD256 by any means at all? Would it have to be some kind of LJ DoP at 22.5MHz BLCK frequency?
Or, maybe its PCM that is to be 'transported' then converted to DSD256 at the receiving end. In that case you might need to make an LJ to I2S protocol converter. Not too hard to do reasonably well if you have a decent MCLK at the receiving end (or PLL might be used instead).
Something like SRC4392 has two I2S bus ports that can be configured for LJ or I2S protocols. Probably some way to do it like that.
Something like SRC4392 has two I2S bus ports that can be configured for LJ or I2S protocols. Probably some way to do it like that.
Hello everybody,
I am building the Marcel's RTZ DAC supported by the PCM2DSD.
Actually 95% os my music is PCM but I am relaly curios to listen the DSD DAC and I think that the PSM2DSD is exactly what I need. I don't stream with PC and Amanero, all my music in the NAS and I stream using the eRED-DOCK renderer connected on the same LAN.
I have some doubt about the connections between the 3 boards, eRED, PCM2DSD and RTZ DAC
Below is the oneline to show the signals connection.
Can someone kindly give a look and confirm that I am in the correct path or make some comments in case?
Also I have some doubt about the 2 signal MUTE and DSDON.
For the MUTE, if I understand well reading in the thread, the MUTE signal doesn't change passing through the PCM2DSD, so should not be a problem.
For the DSDON, I am playing only PCM from the ERED, that mean that the input signal DSDON in PCM2DSD should be reversed? I mean, I have to simulate the DSDON "1" when is playing PCM? I am right?
Thanks and Regards,
Enrico
I am building the Marcel's RTZ DAC supported by the PCM2DSD.
Actually 95% os my music is PCM but I am relaly curios to listen the DSD DAC and I think that the PSM2DSD is exactly what I need. I don't stream with PC and Amanero, all my music in the NAS and I stream using the eRED-DOCK renderer connected on the same LAN.
I have some doubt about the connections between the 3 boards, eRED, PCM2DSD and RTZ DAC
Below is the oneline to show the signals connection.
Can someone kindly give a look and confirm that I am in the correct path or make some comments in case?
Also I have some doubt about the 2 signal MUTE and DSDON.
For the MUTE, if I understand well reading in the thread, the MUTE signal doesn't change passing through the PCM2DSD, so should not be a problem.
For the DSDON, I am playing only PCM from the ERED, that mean that the input signal DSDON in PCM2DSD should be reversed? I mean, I have to simulate the DSDON "1" when is playing PCM? I am right?
Thanks and Regards,
Enrico
Simple DSD Modulator follows the Amanero standard:
If your DSD_ON signal is inverted, one option might be to use a single gate inverter such as:
If your DSD_ON signal is inverted, one option might be to use a single gate inverter such as:
Last edited:
Thanks Mark!
Regarding the DSDON, If i understand well how is working the input on PCM2DSD should be "1" when DSD are detected to bypass the conversion and have the DSD at the output. I am correct?
Regarding the DSDON, If i understand well how is working the input on PCM2DSD should be "1" when DSD are detected to bypass the conversion and have the DSD at the output. I am correct?
Yes.
BYW, the above DSD_ON inverter schematic also has a switch for use with DACs that can play DSD or PCM. The switch can be used to make the FPGA bypass both PCM and DSD.
Last edited:
For DSDON I am ok, from eRED datasheet the DSDON is "1" with DSD
The problem is in MUTE that is inverted... I don't think I can force the PCM2DSD input to "1" always
The problem is in MUTE that is inverted... I don't think I can force the PCM2DSD input to "1" always
Okay. You can invert MUTE the same way, with an inverter chip. Don't need a switch though. You can get +3.3v power from the DSD converter board. Its available on the same pins as for Amanero.
May be worth noting that there are different standards for counting pins numbers on pin header connectors. The more common standard which works with ribbon cable is more like:
Sometimes you may find these things numbered in different ways for connectors that are supposed to plug together. Its usually the mechanical pattern that has to match up that case, not the numbers. Pin-1 will normally be the same either way, so its typically the mechanical reference point.
May be worth noting that there are different standards for counting pins numbers on pin header connectors. The more common standard which works with ribbon cable is more like:
Sometimes you may find these things numbered in different ways for connectors that are supposed to plug together. Its usually the mechanical pattern that has to match up that case, not the numbers. Pin-1 will normally be the same either way, so its typically the mechanical reference point.
Last edited: