This follows the logic and should be correct.
-Michael
↧
Re: Accessing control pins in OSC application
↧
Re: AD5116
Hello,
Thank you for your answer.
I have to elaborate on my question a little more.
During inspection of the AD5116 we have discovered a bad behavior of the Automatic Save Enable function.
The wiper position was not saved to the EEPROM.
Test conditions :
1. The required capacitance is connected between vdd and gnd as mentioned in the DS (10uF +100nF).
2. ASE pin is connected with a 100kOhm resistor to gnd.
Test Steps:
1. Powering the AD5116 with 5V.
2. Changing the wiper position using the push-up and push-down pins.
3. Releasing push-up/push-down pins and waiting more than 1 second to make sure the automatic save operation has done successfully.
4. Shutting down the AD5116.
5. Powering up the AD5116 and checking if the wiper position is the same as the last position before the last power down.
What can cause the AD5116 not saving the wiper position to the EEPROM while using the automatic save?
Thanks.
Additional information :
1. While using the AD5116 in automatic save enable (as described above), we found that the ASE changed to high when the wiper is in end position (working well exact as mentioned in the DS).
2. The manual save function worked well in our tests.
↧
↧
Re: AD9375. RX Framer Data same on both serial lanes.
Hello,
I will upload the file that initializes the TX and RX links. Please let me know if this is what you are looking for. We have not enabled the PRBS test patterns on the Mykonos but we have inserted logic probes inside our FPGA that show the data coming out of each transceiver. Here is an example of the data inside the FPGA:
FPGA TX to MYKONOS RX DEFRAMER 527d9afc56f8aef0 |
527d9afc56f8aef0 |
527d9afc56f8aef0 |
527d9afc56f8aef0 |
af69980f95662a01 |
af69980f95662a01 |
af69980f95662a01 |
af69980f95662a01 |
001ebc07de669102 |
001ebc07de669102 |
001ebc07de669102 |
001ebc07de669102 |
MYKONOS TX FRAMER to FPGA RX 56f8aef056f8aef0 |
56f8aef056f8aef0 |
56f8aef056f8aef0 |
56f8aef056f8aef0 |
95662a0195662a01 |
95662a0195662a01 |
95662a0195662a01 |
95662a0195662a01 |
de669102de669102 |
de669102de669102 |
de669102de669102 |
de669102de669102 |
As you can see the data from the FPGA to the Mykonos is 64bits and has two unique 32bit words. The data back from the Mykonos has the same data (the first 32 bit word) copied into the upper word.
I will try to enable the PRBS generator on the Mykonos to verify my link.
Could you let me know if you see something wrong with the link init file.
Thanks
Ryan
↧
Re: AD9361 Tuning Rx Failed
Hi,
First of all, did your hardware setup works with our unmodified reference design (please note that you have to enable XILINX_PLATFORM and FMCOMMS5 in config.h). My advice is to use the 2017_R1 no-OS and HDL branches - they require Vivado 2016.4. Please do another test using this version.
To enable the 1x1 mode, you need to clear the two_rx_two_tx_mode_enable flag from the initialization structure.
The CMOS will not work because of the FMC connector: AD9361, AD9364 and AD9363 [Analog Devices Wiki]
Regarding the FPGA design questions, please open a thread in the FPGA Reference Designs community if the subject was not already discussed.
Thanks,
Dragos
↧
Re: What means "Only the z-axis response is specified to validate device functionality" for ADXL357 component?
I am glad that this helps. Here are a few points of perspective, for your consideration:
1. The response to the self-test actuation is not what most would refer to as "precise." Review of recent data on the z-axis suggests that the range of normal response is between 1g and 1.6g.
2. The x-axis and y-axis accelerometers will have a response to the self-test inputs, but this response is was not large enough to support the level of assurance that we anticipated as "required," from many of the original target applications. You are welcome to observe this and make your own judgments, but we are unable to specify the range of "normal responses" for these two axes at this time.
3. Based on what I am reading in the datasheet, you cannot validate the x and y signal chains, by only reading the z-axis.
I hope that this helps.
↧
↧
(ADV8005)Can ADV8005 change 3K 30fps to 3K 60fps and output from HDMI using only one port?
Hi !
I have a question about ADV8005.
Can ADV8005 change RGB888 24bits 3K82560×1600) 30fps to 3K(2560×1600) 60fps and output from HDMI using only one port?
Best regards
Kawa
↧
AD9371: TES not working with our custom board
Hello Team,
We are working with our AD9371 custom board. We have connected Zync ZC706 with AD9371 custom board via interface card. Pin connection in custom AD9371 board are same as AD9371 EVK board. (Please go through following image for connection between zyncZC706 and AD9371 custom board.)
We are trying to program AD9371 in custom board using TES. We are using TES SD card which we got with AD9371 EVK Board. But we are getting following error. We have closed all other application running in my PC.
Please kindly suggest us if we are missing something.
Thanks,
Abhishek Naik.
↧
Re: AD9371: Error:- Unable to get dev clk
Hello Michael,
Thanks a lot for the support.
Now we are not getting that error.
In the way is there any other entry to be changed in .dts file for SYSCLK from AD9528 to AD9371?
Thanks
Abhishek Naik
↧
Accelerometer Tolerances to Magnetic Fields and Radiation
I am working on a project that requires me to detect and measure magnetic fields with a Raspberry Pi. However, the project will operate within a 10 tesla field. As part of this project, I need to include an accelerometer to keep track of the kit's movements.
I found some accelerometers from Adafruit with accelerometers from Analog Devices, such as the ADXL335, the ADXL345, the ADXL326, and the ADXL377. Will there be any issues if they were to be subjected to a very large magnetic field? Will they work properly without being destroyed?
Also, if they work, are there any variants of the devices that are radiation-hardened? The kit may be subjected to radiation, so having a variant that is radiation-hardened will be very helpful.
↧
↧
Fastlock Pin control
It is mentioned in the reference manual that CTRL_IN0, CTRL_IN1 and CTRL_IN2 pins can be used to select a profile by setting 0x03 in register 0x29A(Tx) and 0x25A(Rx). I tried the same method in shell script and the registers were automatically self clearing back to 0x01( initially i put 0x03) and profiles are not changing.
Whats going wrong here? Is there any procedure to follow?
I also take a look at the script mentioned in this link:https://github.com/analogdevicesinc/linux_image_ADI-scripts/blob/master/test_tx_fastlock_pinctrl.sh
In this code i) the gpio number for control input pins itself is wrong
ii) instead of ctrl_in0,ctrl_in1,ctrl_in2 pins they are using ctrl_in3,ctrl_in2,ctrl_in1 pins
iii) they didn't set the registers 0x25A or 0x29A anywhere in that program. How will you set the register ? Is there any API commands for that, or we are forced to use direct_reg_access?
↧
Re: Delay and Jitter in generation of HF PULSES using OSK
The data sheet indicates CFR1[9] as External OSK enable. This is a bit misleading, because CFR1[9] actually controls whether the OSK function is automatic (1) or manual (0). It would be more clear if the bit were named Automatic OSK enable, instead.
In any case, because you indicate the use of External OSK, I assume you have CFR1[9]=1. This invokes automatic OSK, which makes use of the internal amplitude ramp generator. I suspect the bulk of the variability you are seeing has to do with the timing control of the internal ramp generator.
Try using manual OSK control rather than automatic. That is, set CRF1[9]=0 (manual OSK). Then, when the OSK pin is 0 the output is 0. When the OSK pin is 1 the output amplitude depends on the value of the selected profile amplitude.
Keep in mind that the OSK pin is gated by the internal SYNC_CLK signal. This is important, because toggling the OSK pin asynchronous to SYNC_CLK will give the appearance of variable startup time. When it is actually the variation between the OSK pin edge and the internal SYNC_CLK edge.
↧
Re: Getting make error 2 trying to build git hdl
Hi,
I moved this conversation to the FPGA reference design space. Good luck with your project.
Regards,
David
↧
Re: How to set up AD9172 in mode 12 (12-bit High Density)
Hello Arik and Michele,
Are there any updates about progress or possible solutions for this issue?
Thanks,
Dan
↧
↧
Re: AD9361 initialization error on ZCU102
Thanks! It's working now.
-Aswathy
↧
Re: AD-FMCDAQ2-EBZ No-OS Drivers Download Links
Hi,
Yes, you can use a different jesd configuration.
In the hdl_2017_r1 you have an ADI JESD204B IP. The answer to your last question is not that straightforward. You will find your answer here JESD204B Link Receive Peripheral [Analog Devices Wiki]
Andrei
↧
AD9172 Mode 20, Nyquist zones and Maximum instantaneous bandwidth
Hi,
DAC - AD9172, as per the highlighted mode 20,21 can operate in 6.16 Gsps if 8 lanes operated at 15.4 Gbps with no interpolation. I am not able to get the information related to Nyquist zones for this DAC operation.
What is the maximum possible instantaneous bandwidth we can obtain using this mode of operation.
kindly please clarify the query.
Regards,
Rajesh khanna
↧
Re: What is the output of the BIST mode
Thank you for responding Sripad.
I read the BIST FAQ, and it mostly says the same things I’ve seen the Reg Map and Ref Manual (except that there are details on Tx that I’m not using yet).
One question though: I have the data ports set for DDR, LVDS, full duplex, dual port and full port (reg 0x012). For the loopback test, the BIST FAQ says the ENSM has to be in FDD mode to use dual port and full duplex (bottom of page 4). Yesterday I did a hardware reset before any calibrations, then used FDD mode for the calibrations, but then I switch to TDD and set the BIST regs at the end of my initialization. I got the attached waveform from the Rx port. It’s half sine wave and half bouncing around. Is that because I’m using TDD with the settings I described in reg 0x012? I haven’t done a loopback yet, but is there a restriction for Rx alone that I should be aware of?
↧
↧
Linux Kernel Driver support for ADIS16465
Hi,
I am looking for Linux driver support for the newly released ADIS16465. It is my understanding that the interface should be similar to the earlier IMU's in the 164xx series, so the AD kernel driver (ADIS16480 IIO Inertial Measurement Unit Linux Driver [Analog Devices Wiki] ) should only need minor changes.
1. Is there plans for official support for this device?
2. If I want to adapt it myselves, which of the earlier devices matches closest to 16465 in terms of register access method and triggering?
Best regards,
Kristian
↧
Re: Calculating IIR DF1 coefficients
I am afraid I cannot point any documentation for this
↧
ADXL362 Expected Sensitivity Range
In production we do a calibration of the ADXL362 by taking static +/- 1G and 0G readings for each axis. We then do a calibration check to make sure they are within the expected range for the ADXL362. The data sheet specifies the nominal sensitivity to be 250 LSB/g for +/-8g range, with a sensitivity calibration range of +/-10%. We have our limits for each axis set to 220-280 LSB/g, which is +/-12% of the nominal 250LSB/g. We are getting some units that have sensitives as low as 215 LSB/g. I want to verify that this is expected, and why we might see this behavior.
To get the sensitivity for each axis we take the +1G reading minus the -1G reading and divide by 2.
Thank You
↧