Dear Sir,
I am interfacing ADS1271 for one of my Automation project using PIC IC. I am Getting very unstable Counts which fluctuates in 10 lakhs and its not getting saturated with Vref also.
I have been working for long time. I am using High Resolution Mode, SPI interface. But the DRDY is coming inverse with ref to datasheet. I could not find the problem.
Since its time bound project pl guide me at the earliest. Here with I attach my shematic and Signal images and code.
4572.ads1271.pdf
2425.ADC.c
Radha,
Can you tell us more about your scope shots? Where do you have your scope probes connected for each picture?
Best regards,
Bob B
Dear Bob,
Thanks for your interest. In attached Pictures. The First one is DRDY signal probe kept at pin DRDY of ADS1271.
The second on SCLK of ADS1271 ,the Third one is SDATA kept at DOUT pin of ADS1271. Pl give me the valuable suggestion at the earliest.
Regards
Radha
It is a little hard to tell for sure, but it appears from the second picture and from the code that SCLK is dwelling high before DRDY goes low. SCLK must dwell low as data will shift at falling edge of SCLK. In this case you will miss the most significant bit. With bit-bang code you should read the input after SCLK transitions from low to high ( or SCLK at high state.)
I have tried SCLK as per your reply but still the fluctuations are there. Can u look into my code or ado you any sample code to try at earliest.
I'm sorry I don't have any example code for PIC microcontrollers. Please send me a scope picture of the communication with SCLK and DOUT on the same scope plot so that I can verify communications.
Bob,
Its OK u don't have code for PIC Controller.I just need procedure of CLK and DATA reading and other signal condition. Send me if u have for any other controller.
Here with I attach my Screen shot took on same shot for CLK and DATA . The Top one is data and Bottom one is CLK
start of DATA
END of DATA.
Kindly check and reply at the earliest
Can U check out my code and conclude?
Notice how erratic the clock pulses are? These pulses should be very clean and uniform. In the clocks that appear slightly darker, I suspect that there is an issue with stability in the clock signal itself. These are probably two quick clock transitions, and they must conform to the timing constraints of the timing diagram in the datasheet.
You need to analyze why some clock pulses are very long as compared to others. Do you have interrupts that are taking place that are inferring with consistency? You also need to zoom in and verify that each clock pulse is valid.
Ya. I have disable the interrupts wen clocking which makes the pulse clean and uniform.
Still the issue is same.
1. Counts fluctuates in lakhs.
2. Its not saturated with Vref. still oscilatting more than vref. means reading is invalid?
3. DRDY is inverse wrf to datasheet.
In data sheet SPI Interface ,SCLK data shfits in falling edge. User should read at rasing edge is given. make clock zero wen data read.
which mean for each bit?
can u procedure me the reading / interfacing?
Radha.P
Now that you have a clean scope picture, you need to verify that the count is really moving as much as you are saying. What you have said is that there is instability with about 12 to 13 bits. Do you really see that much movement on the scope?
If your reference is noisy or unstable, then you will see fluctuations in your result. You may want to place a capacitor at the ADS1271 (or very close to it) across the VrefP and VrefN pins.
I suspect you have an issue with number conversion. You say you cannot reach saturation. Does the scope picture show this? It is not possible to get a number above VREF unless you are misinterpreting the number. The output code is binary two's complement. If the most significant bit is high, then the number is actually a negative number. Are you properly interpreting and signing your number appropriately? You are using a 32 bit signed value (long) in your program and reading in data that is 24 bit. If the MSB is high in the data result captured, then the value is negative and this means that the most significant byte of the long (ADCOUNTSDATA) must also be high for the value to be considered a negative value.
DRDY will appear differently depending on whether you are reading the data or not reading the data. When you are reading the data, the DRDY will appear as shown in the datasheet. If you are not reading data, you will see DRDY dwelling low most of the time with a short pulse from low to high to low which means that new results are being posted when DRDY goes high and are available with DRDY goes low. The big thing to remember is the transition from high to low which signals new data is available.
As far as procedure for communication this will depend a lot on the controller. Generally I prefer to use a hardware peripheral instead of manually controlling the port pins for communication (bit-banging.) Hardware peripherals will work independently of your control loop and will make clocking problems less of an issue. If your PIC controller has a SPI hardware peripheral I would suggest using that over bit-banging.
Thanks for your input so far.Pl clear this also. I have checked the number conversion there is no issue in that. i Have found if i wait for DRDY to Low and then to High
while(DRDY);
while(!DRDY) loop counts is stable for 22 bit also. but change in mv miss 2 or 3 readings.
If i wait only to low while(DRDY) then counts fluctuates in high range. Can u guide me what to do?
Sir,
The Last two digits are same in reading for data .What would be the reason?
The best way to know when data is available is by using an interrupt driven system to capture data as soon as DRDY transitions from high to low. The problem with polling, especially when it involves a processing loop, is that the data can be missed or only partially read. On page 25 of the datasheet under the description for DRDY/FSYNC and just above Figure 63 it says "The new data is loaded within the ADS1271 one CLK cycle before DRDY goes low. All data must be shifted out before this time to avoid being overwritten."
At higher data rates you have a very small window to capture the data as you must do so within the specified constraints. A certain amount of machine cycles are spent just to poll for a change in DRDY. Also, while polling you can do nothing else or you risk having corrupted data. In an interrupt driven system you can always generate the call for reading as soon as the interrupt flag is set. In this way the data read is very consistent, and will be read out within the correct time frame. It also allows you to process other code instead of locking up your process in a 'while' loop. You will have much better success using an interrupt driven system.
My interface working with low speed, SPI currently not available in my chip.Let me try for future design but still. Basically it should work right?
Any how If i use MCLK 2 mhz overall my conversion time is 80ms. which is 5samples per second very low. If change mclkto 20MHZ the same code not working and no improvement in cnv time also. what is the max speed i can achieve? How to improve the speed?
That is exactly the problem I'm talking about. Even if your controller does not have a hardware SPI peripheral it should have interrupt capability. Even then you may have problems as the micro must take a specific amount of machine cycles to complete the read of the data. If while you are polling DRDY and if you start your read cycle too late you may start to read the conversion results from the next conversion. The two results get mixed together and the data is invalid.