Hi, Tomas,
The frequency on the CFB pin is not the same as the oscillation frequency. It is an internal frequency. The waveform on that pin should have a Vpp of around 1V. Make Cf greater to reduce the Vpp, and vise versa. Setting Vpp on CFB to 1Vpp help deliver the best performance of the IC.
Best regards,
Don
Does anyone else actually use this part?
G
Hi,
Thank you for your answer.
Check the power supply is the first that I have done. I didn't see noise or voltage drop...
I think there is an PLL instability. Maybe some bad or wrong component has been put on the board.
Have you got any idea about which component or signal could produce a PLL instability ?
Hi Don san,
Thank you for your response.
The following information that I have.
Plating thickness ： 1 to 5μm
Plating materials ： Electroless nickel plating
Float ball diameter ： 5/32"(3.97mm)
Tapered tube ： PYREX,66mm(H),φ9.5mm
Best Regards,
Seishin
Hi,
You can use the Save as CSV function to save the tone generator data.
Regards,
Matt Guibord
Hi Evgeny,
I really appreciate your assistance. On some additional info and news...
I am using the ADT7310 temperature sensors in addition of the LDC1000s, I found differences on the SPI protocol among this two devices, according to their datasheet.
Also I have way better results using the normal SPI communication rather than the extended SPI transaction method, that gives me lots of errors.
Some differences I try were concerning the rising/falling edge detection, delays after CS selection, SPI speed.
So now i am not using the SPI library, but manually I code the protocol on the Arduino, to better control de SPI clock and data.
I also tested multiple values for different delays (a variation of a single 1 microsecond after shift-register updates a CS pin make a huge difference in the readings of the sensors).
Anyways, I manage to read 4 of each now.
But, all the values from the LDC (the values from the temperature sensors are perfect) are precise but not quite accurate. At least stable. With the same configuration I have values of the proximity data from 4400 to 8000 under the same conditions (nevertheless all four inductance throws the correct and same value, 6uH)
So, precise values now but not accurate. Still minimal variations on the CS sync, and SPI clock shows multiple results.
My suggestion is: What if I choose to share the same CS pin among all sensors (controlled directly by the Arduino, activating all at once), BUT add a buffer to each one, before going into the SPI bus. And then use the shift register to enable or disable each buffer (74LS244 or similar), do you think that would help? What do you think?
Andres.
Hi Henry,
[quote user="Henry Choi"]let me understand what you mean by "monitor the digital lines": do you mean I monitor the SPI communication in logic analyzer, or do you mean I monitor the SYNC line?[/quote]
I mean monitoring the voltage level on SYNC line. My hypothesis is that the large current draw can be causing the power supplies to droop.
Can you try drawing 10A again? Maybe this makes the issue more apparent.
Hi,
The DAC38J82 recommends a ‘gapped periodic’ or ‘one shot’ SYSREF for lower the interference between SYSREF and Device CLK.
Could LMK04906 generate the ‘gapped periodic’ SYSREF signals and achieve deterministic latency ? If it is possible, what is the difference between LMK04906 and LMK04826/28 ?
Best Regards,
kato
Hello Vitalii,
Thank you for bringing this to our attention. I'll take a look at this in more depth and get back to you ASAP.
Please let me know if you need anything else,
Nate
Hello Napat,
Thank you for the post. I can take a look at this. Could you tell me a little bit more about your setup?
1) What are you driving with the PCM5102A (i.e. where does the line out go?) Is there a headphone or speaker power stage after the dac?
2) Are you doing any configurations to the device in between songs? (i.e. writting any scripts or changing settings?)
3) Do you have a way of recording the sound and posting it? It is sometimes helpful to hear the issue.
4) do you get the same results on our evm? http://www.ti.com/tool/pcm5102evm-u If so, this could suggest a software configuration problem.
This information will be very helpful for narrow down this pop issue,
Thanks,
Nate
Hi,
Sounds like you have done a good job so far of debugging. It sounds like a setup issue somewhere.
Also, you should not have to loop through your I2C data. Once the registers are written they should stay in that state unless you power down or have some other reason for clearing them.
I would try writing a single register to a different value than the default, just once using your MCU with the EVM mod plugged into your computer.
Then pull up the “register tables” and “Status Flags” window in the AIC3204 CS software to see if you are writing that register. The status flag may also show why it is not working. Make sure to hit refresh to get the most recent register readings. You may have to change the I2C source between the MCU and the USB_MOD when you write to the EVM from the MCU vs. reading registers from the CS software to do this test. In other words you need to make sure you are using the right I2C source at the right time.
Have you made sure that when using MCU, you are not trying to communicate I2C through the EVM-MOD at the same time? Use the oscilloscope to make sure your MCU can drive the datelines correctly and that the EVM-MOD I2C source is not holding those pins at the wrong state.
See section 2.4 in EVM user’s guide.
Have you checked the position of SW1 & SW2?
Have you verified that your pull-up is correct with the oscilloscope/multimeter?
Regards,
Matt
Kang,
Thank you for the kind reply. I have verified the DAC is operational by following your steps. I enabled a constant input, and enabled the course mixers. As expected, I received oscillating outputs of varying speeds as I changed the course mixer settings.
Moving on, I have loaded the default firmware for the DAC34H84 using HSDC Pro, and set up a basic configuration of the DAC based off of one of the configurations provided with the program. The configuration I started with was:
DAC34H84_FDAC_1228p8MHz_4xint_NCOoff_QMCoff.txt
I made a few modifications, as I did not have available an external clock anywhere near 1 GHz readily available. The only changes I made were to set the interpolation down to 2x, and setup the CDCE62005 to match the requirements. Attached is the configuration. With this setup, I get the warnings FIFO 1 away, FIFO 2 away, IO Test, and OSTR Pattern. However, I do not get any FIFO collisions.
Loading the default firmware into HSDC Pro, I create a single tone, and 'Send' it to the DAC. I chose a single tone at 10 MHz, with the sampling speed set the 62.5 MHz (specified from the CDCE62005 settings). With this configuration, however, I am still getting zero output on the DAC.
Thank you again for your time,
Nicholai
Hi Sasa,
Welcome to the TI E2E Forums!
The ways to speed up reading data for multiple devices over SPI are the following:
Some other alternatives to help read back all the data in time are:
Let me know if any of these suggestions help.
Best Regards,
Chris
I can't see anything obviously wrong.
Do all 4 status registers report the same unlock?
BR,
Steve
Houssem,
In general, your process looks correct, but I did have a few questions.
First, what data do you receive? Is it consistently the same or similar values? Second, how long do you wait send the RDATA command and to read the data? Are you polling for the DOUT/DRDY line to indicate that the data is ready?
Joseph Wu
Hi Vishal,
I'm glad I could help clarify. Let me know if you have any other questions!
Best Regards,
Chris
Hello,
It looks like the current source is being set up correctly.
The read command also looks correct.
Have the channels been set up correctly for how the RTD is connected to the LMP90100?
If you measure at the IB1 pin, when the current source is turned on, is there a voltage drop across the RTD and across Rref?
Mike
Hi,
This usually means that the NI VISA driver needs to be installed on your system. You can download the latest version from the ni.com web site.
Mike
Hi,
I have not been able to find a 4:1 analog switch, so you will need to use 3 2:1 analog switches. Take a look at the TS3A24159 or TS5A22362.
Mike
Hello Chie,
Turns out the code for each particular codec is controlled by the compilation flag (enabled manually by the developer).
For building the Linux Audio Driver for AIC3106, please enable the AIC3104_CODEC_SUPPORT macro in the soc/codecs/tlv320aic310x.h header file.
Please let me know if this solves your issue,
Nate