Dear All, I'm currently evaluating the AD7793 \Sigma-\Delta converter. I'm using an A= duino Due (SAM3X8E) connected to the ADC through SPI with CS permanently ti= ed low. I use the Arduino's SPI library to control the SPI UART and AD's li= brary (available on-line) to access the ADC. After correcting a couple of bugs in both libraries, I'm able to read the A= D7793 on-chip registers but something wired happens. From two of them, I do= n't get the values sated on the datasheet. Were's what I get (power-on defa= ults): Register Datasheet I get ----------------------------- ID 0xXB 0x4A <- datasheet states that ID code for 7792 is 0x= XA STATUS 0x88 0x48 IO 0x00 0x00 MODE 0x000A 0x000A CONF 0x0710 0x0710 OFFSET 0x800000 0x800000 =20 FULLSCALE 0x5XXX00 0x54BB00 Do you thing this could be a mistake on the datasheet or is something wrong= in my code? (I really don't have a clue!) Regards jmariano
AD7793 error?
Started by ●July 25, 2014
Reply by ●July 25, 20142014-07-25
On 7/25/2014 2:50 PM, jmariano wrote:> Dear All, > > I'm currently evaluating the AD7793 \Sigma-\Delta converter. I'm using an Aduino Due (SAM3X8E) connected to the ADC through SPI with CS permanently tied low. I use the Arduino's SPI library to control the SPI UART and AD's library (available on-line) to access the ADC. > > After correcting a couple of bugs in both libraries, I'm able to read the AD7793 on-chip registers but something wired happens. From two of them, I don't get the values sated on the datasheet. Were's what I get (power-on defaults): > > Register Datasheet I get > ----------------------------- > ID 0xXB 0x4A <- datasheet states that ID code for 7792 is 0xXA > STATUS 0x88 0x48 > IO 0x00 0x00 > MODE 0x000A 0x000A > CONF 0x0710 0x0710 > OFFSET 0x800000 0x800000 > FULLSCALE 0x5XXX00 0x54BB00 > > Do you thing this could be a mistake on the datasheet or is something wrong in my code? (I really don't have a clue!) > > Regards > > jmarianoI think there is something wrong with your post. Your data table shows the actual value read as 0x4A and you are complaining that it should be 0xXA according to the data sheet. But the datasheet column shows 0xXB for that value. Do you have your columns mixed up in your post perhaps? -- Rick
Reply by ●July 25, 20142014-07-25
On 7/25/2014 2:50 PM, jmariano wrote:> Dear All, > > I'm currently evaluating the AD7793 \Sigma-\Delta converter. I'm using an Aduino Due (SAM3X8E) connected to the ADC through SPI with CS permanently tied low. I use the Arduino's SPI library to control the SPI UART and AD's library (available on-line) to access the ADC. > > After correcting a couple of bugs in both libraries, I'm able to read the AD7793 on-chip registers but something wired happens. From two of them, I don't get the values sated on the datasheet. Were's what I get (power-on defaults): > > Register Datasheet I get > ----------------------------- > ID 0xXB 0x4A <- datasheet states that ID code for 7792 is 0xXA > STATUS 0x88 0x48 > IO 0x00 0x00 > MODE 0x000A 0x000A > CONF 0x0710 0x0710 > OFFSET 0x800000 0x800000 > FULLSCALE 0x5XXX00 0x54BB00 > > Do you thing this could be a mistake on the datasheet or is something wrong in my code? (I really don't have a clue!) > > Regards > > jmariano >Good news: you just misread the datasheet. The AD7793 is supposed to respond "0xXB". Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
Reply by ●July 25, 20142014-07-25
On 7/25/2014 3:38 PM, rickman wrote:> On 7/25/2014 2:50 PM, jmariano wrote: >> Dear All, >> >> I'm currently evaluating the AD7793 \Sigma-\Delta converter. I'm using >> an Aduino Due (SAM3X8E) connected to the ADC through SPI with CS >> permanently tied low. I use the Arduino's SPI library to control the >> SPI UART and AD's library (available on-line) to access the ADC. >> >> After correcting a couple of bugs in both libraries, I'm able to read >> the AD7793 on-chip registers but something wired happens. From two of >> them, I don't get the values sated on the datasheet. Were's what I get >> (power-on defaults): >> >> Register Datasheet I get >> ----------------------------- >> ID 0xXB 0x4A <- datasheet states that ID code for 7792 >> is 0xXA >> STATUS 0x88 0x48 >> IO 0x00 0x00 >> MODE 0x000A 0x000A >> CONF 0x0710 0x0710 >> OFFSET 0x800000 0x800000 >> FULLSCALE 0x5XXX00 0x54BB00 >> >> Do you thing this could be a mistake on the datasheet or is something >> wrong in my code? (I really don't have a clue!) >> >> Regards >> >> jmariano > > I think there is something wrong with your post. Your data table shows > the actual value read as 0x4A and you are complaining that it should be > 0xXA according to the data sheet. But the datasheet column shows 0xXB > for that value. Do you have your columns mixed up in your post perhaps?Ah, I just saw what you are talking about. You are saying the return value you are reading corresponds to a different part! I missed that before. Check the data sheet for the 7792 and see if the status value matches. Maybe a part was mislabeled somehow or maybe these parts are the same die tested to different specs using a laser trim to set the ID code? -- Rick
Reply by ●July 25, 20142014-07-25
Hi, Thanks for the help. The 7792 is basically the same as the 7793, the only difference being the n= umber of bits - 92 is 16 and 93 is 24. The datasheet for both parts is actu= ality the same. At first I was convinced that I was having a timing error since the differe= nce from A to B is the LSB, but if this is true, I don't understand why i'm= reading 0x48 instead of 0x88 on the status reg (now the difference is on t= he two MSB) and all the others are being read correctly. On the other hand, if this is an error on the datasheet, AD would have swit= ched the ID codes for both parts (so 92 would be B and 93 A) and wrongly st= ated the default value of the status reg (should be 48 instead of 88). So, before I plunge into the code armed with a scope, my question for you m= ore experienced guys is: do you think this could be just an error on the da= tasheet? Regards jmariano
Reply by ●July 25, 20142014-07-25
On Fri, 25 Jul 2014 16:34:42 -0700 (PDT), jmariano <jmariano65@gmail.com> wrote:>Hi, > >Thanks for the help. > >The 7792 is basically the same as the 7793, the only difference being the number of bits - 92 is 16 and 93 is 24. The datasheet for both parts is actuality the same. >At first I was convinced that I was having a timing error since the difference from A to B is the LSB, but if this is true, I don't understand why i'm reading 0x48 instead of 0x88 on the status reg (now the difference is on the two MSB) and all the others are being read correctly. > >On the other hand, if this is an error on the datasheet, AD would have switched the ID codes for both parts (so 92 would be B and 93 A) and wrongly stated the default value of the status reg (should be 48 instead of 88). > >So, before I plunge into the code armed with a scope, my question for you more experienced guys is: do you think this could be just an error on the datasheet? > >Regards > >jmarianoWe use the AD7793 in several products, over 3000 pieces so far, and they work great. But we just read the analog value and ignore the ID and status registers. The 7792 and 7793 are probably the same chip inside, with some bits zapped or something. ADI is making more errors on their data sheets than they used to, and seldom corrects them. Just got burned on the ADR363. Why are mixed-signal part data sheets so terrible? -- John Larkin Highland Technology, Inc jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
Reply by ●July 25, 20142014-07-25
In article <gjq5t9do42boqbhppuk5ahhtbk3qvr6aee@4ax.com>, jlarkin@highlandtechnology.com says...> > On Fri, 25 Jul 2014 16:34:42 -0700 (PDT), jmariano > <jmariano65@gmail.com> wrote: > > >Hi, > > > >Thanks for the help. > > > >The 7792 is basically the same as the 7793, the only difference being the number of bits - 92 is 16 and 93 is 24. The datasheet for both parts is actuality the same. > >At first I was convinced that I was having a timing error since the difference from A to B is the LSB, but if this is true, I don't understand why i'm reading 0x48 instead of 0x88 on the status reg (now the difference is on the two MSB) and all the others are being read correctly. > > > >On the other hand, if this is an error on the datasheet, AD would have switched the ID codes for both parts (so 92 would be B and 93 A) and wrongly stated the default value of the status reg (should be 48 instead of 88). > > > >So, before I plunge into the code armed with a scope, my question for you more experienced guys is: do you think this could be just an error on the datasheet? > > > >Regards > > > >jmariano > > We use the AD7793 in several products, over 3000 pieces so far, and > they work great. But we just read the analog value and ignore the ID > and status registers. The 7792 and 7793 are probably the same chip > inside, with some bits zapped or something. > > ADI is making more errors on their data sheets than they used to, and > seldom corrects them. Just got burned on the ADR363. > > Why are mixed-signal part data sheets so terrible?They're just testing the audience to see how many actually read them! Jamie
Reply by ●July 25, 20142014-07-25
On 7/25/2014 7:34 PM, jmariano wrote:> Hi, > > Thanks for the help. > > The 7792 is basically the same as the 7793, the only difference being the number of bits - 92 is 16 and 93 is 24. The datasheet for both parts is actuality the same. > At first I was convinced that I was having a timing error since the difference from A to B is the LSB, but if this is true, I don't understand why i'm reading 0x48 instead of 0x88 on the status reg (now the difference is on the two MSB) and all the others are being read correctly. > > On the other hand, if this is an error on the datasheet, AD would have switched the ID codes for both parts (so 92 would be B and 93 A) and wrongly stated the default value of the status reg (should be 48 instead of 88). > > So, before I plunge into the code armed with a scope, my question for you more experienced guys is: do you think this could be just an error on the datasheet?I don't have the data sheets here so I can't keep up with the values and part numbers. But I believe you are saying your ID matches the '92 and not the '93 while the status value does not match either part. I'm not clear on the status reg when you say the "default" value. What is the meaning of the bits that are different? It has been a while since I've used SPI, but I seem to recall there is a signal that controls the framing. Isn't that the CS? There is a clock, data in and data out then the CS strobe says all the data has been shifted in so latch it, no? You say you aren't using CS, does that work? -- Rick
Reply by ●July 26, 20142014-07-26
On Fri, 25 Jul 2014 16:46:53 -0700, John Larkin <jlarkin@highlandtechnology.com> wrote:> >Why are mixed-signal part data sheets so terrible?IMO it's because the parts can be very complicated, and the datasheets are often not written by the designers but by apps people, frequently younger engineers, who just aren't as familiar with their intricacies. Designer reviews are often cursory because many designers think this work is boring or beneath them and don't take it seriously. And these are _all_ engineers, who often lack technical writing skills. I've been working on a datasheet for a fairly complex mixed-signal product for much of the last two months, and intermittently for several months before that. It's now at 112 pages, and still only covers internal stuff we need to guide the design team, like register and functional definitions. It doesn't yet include the required customer-facing things like detailed specifications, applications data, and performance plots (that have to wait for silicon). It's based on several successful prior product generations, so I can re-use parts of those earlier datasheets, but *every* section so far has required extensive data table and text changes to cover the expanded functionality of the new product; it's safe to say that I've had to modify every paragraph for content, clarity, and accuracy. The public datasheet will be a bit shorter because I can remove the proprietary internal and DFT stuff. I *am* the (lead) designer, and still find errors during reviews of what I thought were completed sections. Writing a good datasheet is surprisingly hard work. It's a pity that more companies (and engineers) don't recognize the importance of the task and treat it with the respect it deserves.
Reply by ●July 26, 20142014-07-26
On Sat, 26 Jul 2014 09:11:30 -0400, Steve Goldstein <sgoldHAM@alum.mit.edu> wrote:>On Fri, 25 Jul 2014 16:46:53 -0700, John Larkin ><jlarkin@highlandtechnology.com> wrote: > >> >>Why are mixed-signal part data sheets so terrible? > >IMO it's because the parts can be very complicated, and the datasheets >are often not written by the designers but by apps people, frequently >younger engineers, who just aren't as familiar with their intricacies. >Designer reviews are often cursory because many designers think this >work is boring or beneath them and don't take it seriously. And these >are _all_ engineers, who often lack technical writing skills.More likely, they're overworked and have other fish to fry. Checking, particularly other people's work, is the first thing to go out the window.>I've been working on a datasheet for a fairly complex mixed-signal >product for much of the last two months, and intermittently for >several months before that. It's now at 112 pages, and still only >covers internal stuff we need to guide the design team, like register >and functional definitions. It doesn't yet include the required >customer-facing things like detailed specifications, applications >data, and performance plots (that have to wait for silicon). It's >based on several successful prior product generations, so I can re-use >parts of those earlier datasheets, but *every* section so far has >required extensive data table and text changes to cover the expanded >functionality of the new product; it's safe to say that I've had to >modify every paragraph for content, clarity, and accuracy. The public >datasheet will be a bit shorter because I can remove the proprietary >internal and DFT stuff. I *am* the (lead) designer, and still find >errors during reviews of what I thought were completed sections.Processor architecture documents are similar. A few thousand pages is certainly not unusual. The public datasheets that large are common. Ours were written by the architects, then rewritten by the designers, and again by the verification engineers.>Writing a good datasheet is surprisingly hard work. It's a pity that >more companies (and engineers) don't recognize the importance of the >task and treat it with the respect it deserves.Apparently, it's often done after the part is cooked. That never works out. Anyone else notice that Asian and European datasheets are particularly bad? Content free. It's not just the translation (but that's a part of it).
