DAC8742H: Does DAC8742H has passed the physical layer test of Fieldbus foundation

Hello, 

Joseph will review your questions and provide a response soon. 

Best,

Katlynne Jones

Hi,

I'm not sure about the origin of the jitter tolerance specification. For min-max specifications, we generally have some amount of guard band to make sure we're not close to a specification edge case. However, for jitter tolerance, the value may be based on some timing related to an internal clock. I don't think there is a way to guess how likely a message would be received if the jitter is over the specification.

As for the testing of the device in a Fieldbus application, TI had started work on a design for PAFF but it was stopped due to priority changes in the group. There was a test circuit and TI had worked on a test board and a firmware stack with a third party. As I understand it, the hardware passed all physical layer tests except one test on the input impedance frequency response. There isn't any information on how it did not pass, and any modifications needed make the change.

There is an older post that does give some information about an example circuit here:

https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/821316/dac8740h-the-reference-design-of-field-transmitter-with-profibus-pa

Joseph Wu

Hi Joseph, great to know that the chip passed all the physical test, including the jitter tolerance test. So it is strange that my jitter test was fail. Could you please share the report on your jitter tolerance test? Did you successful receive 100% of 1000 packages with jitter of +-3.2ms 

Thong Tuan,

I don't have a specific report for the jitter tolerance test. I do have a bunch of log files from a company that started the process of testing the board being developed for Fieldbus.

To be clear, I'm not very familiar with Fieldbus and how it's tested, so I'm not sure exactly how to help with this question. and I don't know what each of these tests refer to. I'm much more familiar with the HART aspects of this device.

Regardless, I can check on the origin on the jitter specification and get back to you.

Joseph Wu

TI-FF-V301.complete.results

Dear Joseph

Thanks for sharing the test log, but these test are likely relevant to the Datalink layer test, not the Physical test where we check the electrical characteristic of the devices.

To shorten my question: Texas Instrument stated the chip can tolerance jitter of 3.2us, but my test showed the opposite. So I am asking for document/evidence/test procedure to check if I did something wrong, or the DAC8742H itself can NOT tolerance jitter of 3.2us. 

Or could I understand that the jitter tolerance has never been tested at TI, but just come from theory/calculation based on the internal clock?

Hi,

I did talk to one of the digital designers, and this specification comes as a percentage of the clock rate (at 31.25kbps, that would be 32us for a bit, and 3.2us would be 10% of the bit period). He thinks that they were able to simulate a 4us jitter error without a problem. However, if the clock source is off, or has additional jitter, that would add to the error.

Joseph Wu

Hi Joseph

I am now developing devices for PAFF using the DAC8742H. To be able to register the devices for the PAFF protocol compliant/certificate , we need to test or provide the evidence/ documentation to show that the devices could pass the protocol specification. Because TI have stated in the datasheet that the jitter tolerance is 3.2us, could you please send me any proof/statement/ documentation for that, so I can use it when registering for the PAFF certificate? This is very important for me because I have to consider if I should use the  DAC8742H or looking for another solution. 

Best.

Hi Thong,

We used the Foundation Fieldbus definition of the jitter specification, where we adjusted the midcell edge of every bit in a medium length command.  The jitter variation was implemented at random, but we ensured that some of the edges were >3.2us.  I dont have the distribution, but I recall we did approximately 15% the total bit time, which exceeds the jitter specification.  We send many hundreds of these commands (while changing the jitter every iteration) and then checked for errors across supply conditions and temperature.  We did not see any issues.

As far as documentation, we would direct you to our specification table in our datasheet as our statement of performance.  As with all devices, we can test and characterize our device to industry norms and under the conditions we specify in our table, as our terms and conditions define.

So I am interested in why your evaluation failed.  How was your jitter implemented?  Can you share more details?

Thanks,

Paul

Thong, 

Also, I was able to find the test report for our board using the DAC8742H. The first test results say that VBUS was 32V, with a waveform of ±3.2us of jitter. The second test results were with VBUS of 9V, with the same jitter.

For both tests, there were 1000 requests transmitted, and 1000 responses received. Again, this was a board that we put together, but was tested by a third party.

Joseph Wu

Thanks for the report, Joseph. Then I will double check my test to see if I did anything wrong.

Hi Paul, thanks for the information. In the test I made, I used a test board to sending a fixed probe node, but the zero crosses in the Manchester code was randomly delayed/preponed 3.2us at some random edges. My device under test, using the DAC8742H, try to capture all the probe nodes. And I received only around 95-97% of each 1000 sending messages 

Thong,

Let us know if you have any other questions. For the time being, I'll keep this thread open so you can post back to it.

Joseph Wu

Hi Paul

I did the test again but my best result is still 3-5 package lost every 1000. More investigation showed that the DAC chip sent nothing out at the UART when receiving a failed package ( for a good package, the DAC chip start to throw data to the UART just after the first coming data byte). That means the decoding process fail at the preample or the "starting delimiter" can not be detected. In you test, did you add jitter to the whole frame, or just after the starting delimiter?

Thong,

I'm sure that the test adds jitter to the preamble just as it does to the data. The preamble is part of the data frame as well. 

Is there a way to capture the error from the incoming frame and plot it with an oscilloscope? I think that the transmission and the UART would be offset by the time of a data byte. You can also check the CD pin to see if there is a valid carrier.

Joseph Wu

Hi Joseph

More investigation indicates that the starting delimiter is very sensitive to the jitter. I used a signal generator to generate 2 testing signal, one without jitter (blue) and the other one has 1 jitter of 3.2us (orange).  Vpp is 0.6V. I configured the DAC to use internal filter, and connect the waveform generator directly to MOD_IN

In the figure below, you see the 2 waveforms at the bottom part while the top part show the time between all 2 consecutive zero cross (to make sure the timing is correct) .

The DAC sent 1 data byte to UART with the not jitter signal. 100% stable.

When sending Signal with jitter, The DAC sent 1 byte to UART also, but not 100%. Example, if I repeatedly send the Signal with jitter 1000 times, interval of 50ms, the DAC will sent data to UART just 600-700 times, meaning around 30% loss. 

Thong,

I'm still not sure what the problem is at this point, but I did have some extra questions.

How do you generate the jitter in your setup? Do you use a specialized test system? At this point, I don't think I have a test system that could generate this type of jitter. If you have something that does, I might be able to duplicate your issue.

Also, have you checked the frequency of the oscillator clock? If the oscillator clock is not centered on the correct frequency, the skew of the clock could affect the digital timing and cause a lower jitter to throw up an error.

It looks like you're just adding an extra 3.2us delay into the middle of the delimiter byte. Just to get a feel for how the device is affected, is it similar when you remove 3.2us from the delimiter? Have you check what happens when you add or subtract different amounts of delay? Have you checked if adding more than one preamble to the start of the frame? I was just checking to see if any of these variations make the better or worse, and to see if the error is symmetric.

It also looks like you used the DAC8742HEVM to run these tests, is that the case? I just want to make sure that you've tested this with your own board and now with the DAC8742HEVM.

I'll check with design to see if they have any comments on how they tested jitter and if there are any differences in your tests.

Joseph Wu

Hi Joseph

I'm still not sure..... -> My problem is that adding 3.2us jitter makes the DAC8742H sometimes can not catch the FF frame

How do you generate ... -> I used an arbitrary signal generator to generate the FF frame with jitter ( orange line in the above figure). You can reproduce my test with an arbitrary signal generator (I can send the waveform in CSV file)

Also, have you checked the frequency ... ->  Yes, I measured the output of 4MHz crystal oscillator on the  DAC8742HEVM and it showed exactly 4MHz

It looks like you're just .... ->  Actually, the jitter test was failed with my self-developed DAC8742H board and my specialized test system. Then I used the DAC8742HEVM board to eliminate all problems (if any) in my self-developed DAC8742H board , still fail. Then I captured the jittered signal (that makes the test fail)  from my specialized test system, re-generated it with signal generator. Finally, with the signal generator, I removed the jitter at several positions ( in the preamble, starting delimiter, main data ), and figured out that even with a single jitter at starting delimiter (showed above), the jitter test still fail. In summary, I tried to simplify the test so that you can re-produce it at TI with a signal generator and a DAC8742HEVM evaluation board

Have you checked if adding more than one preamble ... -> Not yet, but I can check soon and let you know the result

It also looks like you used the DAC8742HEVM to run these tests ....-> Exactly, both test with the TI evaluation board and my own board showed the same failure 

I am very interesting to see if you can reproduce the test at TI and compare the result. You may need a micro controller to count the sending signal from the signal generator ( using the generator's output trigger maybe) and count the UART output of the DAC8742 

Thong,

One thing that I'd like you to change to your test is the method of adding jitter so that an added delay also has the complementary subtraction for each bit. 

When I first discussed this with the digital designer, he thought that adding a delay within a bit (or a byte) is more of a shift and not jitter. His point was that adding a delay also causes an apparent change in the clock frequency which is somewhat significant even if it is momentary.

Because you're adding in the shift through basically a lookup from a csv file, you should be able to add a delay within a bit and then remove it at the other side of the transition. This would keep the bit width the same, while adding the jitter in between. 

Joseph Wu

Hi Joseph

I generated a new jittered signal by moving an edge 3.2us ( orange line in figure below). Still the same 20-30% loss if I send 1000 jittered signals repeatedly (interval 50ms) 

Another test as you suggested: adding more than one preamble. 100% passed with the blue (no jitter, 1 more preamble added), but still 20-30% loss with the orange (1 jitter of 3.2us, 1 more preamble added),

Is it possible that you reproduce the test at TI to confirm?

Thong,

I'm looking into whether we can reproduce this test. I personally don't have that much experience with PAFF, and with writing firmware to run this sort of thing, so it may take some time to look at this.

Joseph Wu

Hi Joseph, how 's thing going? Do you able to verify my test? Just let me know if you need anything, such as the testing signal.

Best 

Thong,

We're still working on this. It's taken a some time to look for our previous testing method and past setup. 

In the mean time, have you completed the rest of the physical layer tests? Have there been any other issues passing them?

I'll take any information you have about your testing, and if possible, I'd like to see the schematic as well.

Joseph Wu

Hi Joseph

I started with the physical test 2 months ago, using the standard you sent. And the jitter test failed ( the jitter was generated exactly as you showed above). At lot of different jitter signals were created by this method and you will never know which signal makes it fail. So it took me one more month to find out that even with the same specific jittered signal, the DAC chip sometimes can not catch it. Then it took me another month to simplify the problem by indicating that adding jitter at the "start delimiter".

In short, I tried to simplify the test while waiting for your answer. I was able to pick one of the jitter signal in the Physical Layer Conformance test that causes the failure, and I found out the starting delimiter part in this signal is the problem. If it can not pass my test, it will never pass the Physical Layer Conformance test. But I think you now are investigating from the starting point?

So, I did the jitter test according to the Physical Layer Conformance test from the Fieldbus specifications (FF-830), and it did not pass. So, what should be the next step?

I try to simplify the test by using the DAC8742HEVM board with NUCLEO board. I add the code for the NUCLEO board and test set up here  https://www.dropbox.com/scl/fo/0acmv01p0dxfkzgj82l0j/ADUO9nfIZ_tgdkdzThnxQk4?rlkey=3lxade4zxvrsifqtc4h6ncbgh&st=m820yo9g&dl=0 . Also, the good and bad signal was added as CSV file that maybe used to program the signal generator to create the jittered signal.

With a signal generator, I hope you can reproduce the test quickly. Just let me know if you need more thing

Best

Hi Joseph

I also added another jittered signal generated as the Physical Layer Conformance test, i.e. add +-1.6us to every zero cross. The DAC chip can not 100% catch this jittered signal. You can find the signal at JitterFullSignal

Thong, 

Normally, we're blocked on our network from dropbox, but I was able to get an exception. I was able to download the two csv files, and the pdf figure, However, I'm still blocked from your zip file, because it's code.

However, I do have a board working and I did get FF working to write from the device and to read it back correctly. Paul did find the testbench and I think we should be able to test it Tuesday. 

Joseph Wu

Thong,

I wasn't able to get the 33220A until today, so we're still working on this. 

Joseph Wu

Hi Thong,

Our goal here is to recreate our validation configuration to dig into this.  As Joe has mentioned, we did pass this jitter requirement and physical layer testing at the time of development and some of our other customers have done so as well.  Your results are surprising to us, but we don't see any flaw in your test methodology to explain it.

Hi Joe

I added a new file TI_Jitter_PASS_123456dotzip.zip . You can unzip this file, rename the extracted file to .zip, and unzip it again with password 123456. Then you can get the code. I hope this can bypass your security block.

www.dropbox.com/.../TI_Jitter_PASS_123456dotzip.zip

Thong,

The new download was blocked. Security identified it as a zip file and prevented the download.

I mentioned last time that I found the testbench. This testbench wasn't the exact one used on the DAC8742H, but it was derived from that Labview used to test it. It has controls that set the amplitude, the rise/fall times, frequency, and the addition of the jitter. It also can change the number of preambles, and the data in the transmission. Here's what the controlling Labview looks like:

I didn't take too many scope shots, but here is at least some of the reception that I got.

While I am getting some extended results that pass with and without jitter, I still have some problems in getting proper results. The listed frequency from the Labview is a bit off more than I expected, and I do have some cases where I lose communication depending on the preamble and message data. This is both with and without the jitter added to the signal. Right now, I'm just debugging the resulting signal just to make sure that I'm getting the output that is expected, and that the jitter is correctly added in. The jitter is added from an excel file that has the sequence of adds and subtracts from the table in FF-830 that I had copied earlier.

Joseph Wu

The testbench is great Joe. Then you can reproduce my test now. To generate my signal, the jitter table should be like the figure below, where you first prepone the standard signal -1.6us, then add delay +3.2us at the 16th (or maybe the 15th) zero-cross.

I am very eager to see your result. Please remember to send the same jittered signal 1000 times and count how many pagakes the DAC got.

Best

Hi Joe, did you have time to do the test? If you need the code, just let me know. You may contact me through my email, tth@fint.no. 

Best

Thong,

I was able to reproduce your test, but I was able to get the test to pass. I did need to make a quick change to the basic schematic, but here is the result. I'll go through the test, explain my change, and show what the result was. I still have some thoughts about what might be the issue and I'll cover that at the end.

I started out using the DAC8742HEVM GUI to set up the device to receive a PAFF signal.

First, let me explain how the test is set up. The communication is set up using an Agilent 33220A as the AWG controlled through GPIB. The program first figures out what the communication will be, calculates the number of data periods that are needed for data and then uses a total of 16384 time periods to generate the signal.

For example, I used a test with two preambles and a PN command. This is a signal with two preambles (16 periods), a start and stop delimiter (16 periods), the command (10 bytes for 80 periods), and then an extra time period and the start and stop of the command.  This is a total of 114 periods. After that you calculate the frequency of the AWG based on 16384 time segments (and round down, with any extra appended to the extra time period). This becomes 16384/114 or 143 time segments for each bit. This gives the actual frequency of each bit segment to make 31.25kHz. For the AWG frequency you calculate 31.25kHz divided by the number of periods 114. This sets the AWG to 274.1228Hz.

The transitions for rise time and fall time for each byte is done by giving the 10%-90% time in us. You then multiply this time by 25% and calculate the number of transitions to rise and fall for each bit. In this calculation, this is the transition time divided by 1 over 16384 times the AWG frequency. These are the values so you can check:

PN test – 31.25kHz

Calculate # periods from data: (preambles + data bytes + delimiters) * 8 + 2 periods = 114 periods

Calculate frequency from number of time segments: 16384/114 periods, round down = 143 time segments/bit

Calculate AWG frequency: Frequency / # of periods = 31.25kHz/114 = 274.1228Hz

Calculate # of transitions from transition rate: (rate in us * 1.25)/(1/(16384*AWG frequency)) = 33 time segments

Everything can be set from the first window. Gain is the amplitude of the signal, offset of the AWG, jitter, transition rate, data frequency, number of preambles, and a short test data, PN, or PT command can all be added with this setup.

The jitter is added through a csv file, and I altered it to be similar to yours with the jitter added to a specific location. You can see it in the background csv file (element #23 from two preambles):

Running the test, I was able to pass both with and without jitter. This is what the test looks like without jitter:

And then with jitter (at your specific location), delayed as shown with the cursor:

If I zoom out, you can see the signal reception:

And then if I zoom out even further, I can see the reception multiple times.

I can just run this trace many times with a single captures and see if any of the receptions are completely missed. In both without and with jitter, I don’t have any losses.

As I mentioned before, I did have to make a small change to the EVM board. This is what the board looks like normally for PAFF.

I had to pull out the circled jumper on J16. This is the connection of the 120pF capacitor from the MOD_INF pin. I had found that playing with the filtering a little would give me better or worse results. I started by tuning the frequency first to get some amount of error, and then I could alter the filter a little to see if changes would make the error get better or worse. I’ve also tested this with the external filter and it seems that lowering some of the resistances and bringing in the bandwidth also seems to help. I've also played with other variables just to check. 

I would also note that I sometimes get some inconsistent results. There would be cases where I would set the number of preambles to different values and I would completely drop communication, even without adding jitter. I’ve seen some frequency changes make the problem better or worse, but it seems that slightly lower frequency is better.

I’m not sure what the issue is, but my first guess is that maybe there’s some added noise from the AWG that is causing some reception error. It seems that if there’s more filtering, I have fewer errors. We’ve ordered some boards that were tested by a third party and we’re checking to see if that board has more consistent results compared to the EVM. I’m hoping to have the board in a couple of days to see if I get something more consistent or different.

Regardless, look through my comments, and see if there’s any substantive differences in the way I tested it compared to yours.

Joseph Wu

Hi Joe

I am deeply appreciate your effort to reproduce the test. I am carefully looking through it now. 
Another issue which is not quite relevant to this jitter test but may be good to mention here is that the successful receiving rate depends somehow with the voltage amplitude, both the amplitude of FF signal and the Vcc for the DAC. I remember I can get a better receiving rate for the FF signal 1V peak peak by reducing the Vcc from 5V to 3V. You may play with it if you have more time.

Best regards
Thong

Hi again Joe
I got a much better result after removing the 120pF capacitor. In a picky way, there’s still a minor issue with 1 or 2 packet losses per 1,000 (I observed 3-4 losses out of 3,000 packets). That may be why you did not see the loss with single captures but need to count it precisely by microcontroller. But I hope it is good enough to pass the Physical Layer Conformance test. I’ll run the test again soon and update you on whether it passes  

Thong,

On the oscilloscope, I can extend out the time trace to show many more than just the 50-60 communication cycles that you see on the scope. You're right that losses of 1-2 packets out of a thousand is tough to find. In checking the packet losses with the change in the capacitor, I didn't need to look too hard. I'm hoping that the 1-2 per 1000 losses are elements of the same problem, but I don't know that for sure yet. If it does return, I would consider changing the capacitance on MOD_IN and MOD_INF to see if you can make the problem better or worse.

When I first removed the 120pF capacitor, I did check to see if I did have the rare loss, but didn't see any. I think that when the designers first calculated the values needed for filtering, the capacitances were set based on simulation, and they didn't include any potential parasitic capacitance. I wouldn't necessarily remove this capacitance completely, but I would reduce it. I'll see if I can find some documentation on the internal filtering of the device to shed some light on it. Again, are you using the internal or external filter? Were there any changes in the setup I used to what you used for the DAC8742HEVM? It might help me determine what other tests we could run to remove this problem.

I'll build up the original PAFF board when I get it and see if I can set up the test to detect any packet losses. based on that setup.

Joseph Wu

Hi Joe
I used the internal filter. (but I tested before with external filter and it also fails).
Your solution of remove the 120pF cap gave me a hint that the "actually signal seen by the DAC8742" can be measured at the MOD_INF pin, regardless internal or external filter is used. Is it correct?

I tried to select the external filter and feed the FF signal after the DC blocking cap directly to the MOD_INF pin. That means not filter is used at all. Got 100% pass.