• 0

Analog Discovery 2, analog input problem


Question

Hello.

 

I am developing a system with Analog Discovery 2 and SDK (C++).

It uses 1 channel DA output, 2 channels AD input, and 1 channel DIO output.

I use "FDwfAnalogInStatus" command to detect the end of AD input. (Refer to the sample program.)

Normally, returned status should be "DwfStateDone" (2) or "DwfStateRunning" (3).

But sometimes it returns "DwfStateReady" (0) and never return "DwfStateDone".

I wonder if AD was not triggered to start for some reason at that time.

It seems that it occurs frequently when input voltage was high at previous measurement.

I wonder if there were some errors in previous measurement. (Over range or something?)

If it become that situation, it cannot recover until closing and opening the device again.

It cannot recover if "FDwfAnalogOutReset" and "FDwfAnalogInReset" commands were sent and setting parameters from the first.

I want to know how to detect the error status of the device that AD cannot start, and how to recover that situatuion.

 

Link to post
Share on other sites

Recommended Posts

  • 0

Hi @S.Kagawa

Depending on the configuration and inputs the state can be: ready (configured and not started or stopped), config (doing internal configuration), prefill (pre-trigger stage), armed (waiting for trigger), triggered=running (post-trigger stage), done

See the examples in the WF SDK/ samples/ py and the manual:
image.png.d1e3c9818883286cfb85f0fc69f6fea0.png

You could also send or post your code.

Link to post
Share on other sites
  • 0

Thank you for information.

 

It is not the cause of the problem, but I met a strange phenomenon.

 

After AD input, returned status code by "FDwfAnalogInStatus" command changed from "DwfStateRunning" (3) to "DwfStateDone" (2).

Normally, then break from the while-loop like sample program.

But I just do "FDwfAnalogInStatus" again for debug.

Then return status code changed from "DwfStateDone" to "DwfStateArmed" (1).

In case of DA output ("FDwfAnalogOutStatus" command), this phenomenon did not occurred.

After returning "DwfStateDone" by "FDwfAnalogOutStatus" command, "FDwfAnalogOutStatus" again, but returned status code also "DwfStateDone".

 

Is it a specification?

 

 

 

 

Link to post
Share on other sites
  • 0

Thank you for information and sorry for late reply.

After that, I found that the status value was not abnormal, but  the return value of status getting function ("FDwAnalogInStatus") was ERROR (0).

 

We are developing measurement system with Analog Discovery2.

It judges if electric discharging (spark) phenomenon was occurred through near 2 probes charging high voltage (MAX 250V).

It uses 1ch DA, generating 0-4V and boosted to 0-250V by amplifier.

It makes output wave data by custom setting mode. (0V->250V->0V)

And also it uses 2ch AD for recording voltage and current, which are synchronized with the start of DA output.

It watches the end of AD by poling AD status getting function ("FDwAnalogInStatus") until the status value would be "DwfStateDone"(==2).

 

Problem:

Sometimes "FDwAnalogInStatus" function returns "0" (== ERROR).

Once it become such a situation, "FDwAnalogInStatus" and other communication commands always return "0".

In short, the USB communication become broken.

It would not be recovered until executing device open from the first.

This problem used to be occurred when electric discharge (spark) phenomenon was occurred actually.

I think there maybe the influence of noise of discharging (spark).

But it would not be improved if shield reinforced.

 

Environment:

Host PC: Windows XP (32bit),  Visual Studio 2008 (VC++)

PC and Analog Discovery2 are connected with USB cable, but isolated by USB isolator. ("USB-029L2" by HUMANDATA Co,Ltd., corresponded to High Speed USB)

 

Is there any solution to prevent this problem?

If there were some similar case, please give me information.

Link to post
Share on other sites
  • 0

Hi @S.Kagawa

We have not tested the device in such extreme conditions.

'Faraday' shielding of the device should protect it from EMI. Are you using shielded USB cable

Could you provide details about the scope input connection? are you using BNC/ 10x scope? 

 

Link to post
Share on other sites
  • 0

Thank you for reply.

 

This system is for embedded in an equipment.

BNC / x10 scope is not used because it is connected to the analog circuit directly through 2x15P connector.

Attache PDF is the circuit.

J1 (2x15P connector) is connected to Analog Discovery 2.

"W1"(P5) is for DA 0-ch, wave data output.

0-4V voltage will be amplified to 0-250V by an amplifier.

"+1"(P1) is for AD 0-ch, voltage measurement.

0-250V voltage is changed to 0--2V by voltage-dividing circuit and input in "+1".

"+2"(P2) is for AD 1-ch, current measurement.

0-10mA current is changed to 0--10V voltage by current-shunting circuit and input in "+2".

 

AD2 and PC are connected USB-cable through USB-Isolater ("USB-029L2" by HUMANDATA Co,Ltd).

The GND of PC and AD2 are isolated by it.

 

We heva tried to reinforce shield, inserting ferrite core with USB-cable, putting AD2 in a metalic box, connecting the GND of AD2 to the GND of PC through capacitor (3000Pf).

But the situation would not be improved.

spark check.pdf

Link to post
Share on other sites
  • 0

Hi @S.Kagawa

1. It could be a grounding issue.
You could try to connect the device/your circuit ground to the isolator device gnd or to short the ferrite (FB19) on the device under the USB connector. See the pictures below.
2. The isolator could be also influenced by the EMI.
Try shielding this too or try without isolator and use a 'disposable'/old laptop.

image.png.475ce31de95e3115f9dd083b4916d8c6.png

image.png

 

Link to post
Share on other sites
  • 0

Thank you for reply.

I'll try 1.

I have already tried 2. (without USB isolator).

Communication error was not occurred if USB was connected directly, but USB isolator is necessary in this system to reduce analog input noise from the PC (equipment).

Shielding isolator also tried, input in a metal box.

But it was not so effective.

Link to post
Share on other sites
  • 0

I have tried item 1. (short ferrite FB 19), but the result seemed not changed.

By the way, I confirmed the last error code and last error message by "FDwfGetLastError" and "FDwfGetLastErrorMsg" when this error (return value of function was FALSE) occurred.

The error code was 0 and the error message was "DptiIO failed ERC:0x2".

If USB cable was unplugged, the error code was 0 and the error message was "DptiIO failed ERC:0x7".

The phenomenon was similar but the error message was a little different.

What is the meaning of "DptiIO failed ERC:0x2"?

 

 

Link to post
Share on other sites
  • 0

Thank you for reply.

I found that the error of USB communication almost occurred in "FDwfAnalogInStatus" function.

Sorry, I don't know the details of USB interface, but I heard that there are some protocols of USB transfer.

Some protocols have auto re-send function if there were some errors, but others not.

I wonder if "FDwfAnalogInStatus" function was a latter one?

 

Link to post
Share on other sites
  • 0

Hi @S.Kagawa

The FDwfDeviceOpen, FDwfAnalog/Digital-In/Out-Status, -Config (and -Set with the default AutoConfigure option) functions communicate with the device.
The -StatusData (-Status...) returns the fetched data with the last -Status call. The -Get returns the last configured/set parameters.

The FTDI driver/device uses USB control and bulk data transfers. The crc/ack/resend should be handled by the low level system/device.

Since you have noticed the problem is when using the USB HS isolator, you could try using a cheaper USB FS isolator like an ADUM3160 based one.
With the FS communication you will have lower transfer rate (2MBps vs 20-40MBps), lower capture rate, but this is suffice for normal usage of the device.
The speed difference is noticeable when using streaming modes, Wavegen/AnalogOut Play or Scope/AnalogIn Record.

Link to post
Share on other sites
  • 0

Thank you for reply.

I have already tested cheaper FS isolator (ADUM4160) at first, because I did not notice the speed at that time.

But I found the speed was slow compared with direct connection (no isolator).

Then I changed to HS isolator.

In case of FS isolator, the rate of error occurrence seemed low, but also occurred sometimes.

By the way I 'm testing other isolator, USB-029H2-RP (HUMANDATA).

It has external power input and AC power adapter, able to use bus power or external AC power. (USB-029L2, the original one can use only bus power.)

I found the error occurred very often (worse than USB-029L2) if using AC power adapter, but if using bus power, it changed seem stable.

Also I tested lap-top PC for host.

Error occurred very often(worse than original desk-top PC)  if using AC adapter (not for isolator but PC), but if using battery, it changed seem stable.

Behavior changed if using AC power adapter or not in above mentioned 2 cases.

Is it common case?

Link to post
Share on other sites
  • 0

Hi @S.Kagawa

This is the first time I hear of such USB EMI problem.
Here in the last post mentions that the issue is solved by using floating/battery power laptop and USB optical link:
https://electronics.stackexchange.com/questions/31417/how-can-i-improve-usb-emi-insensitivity

I'm using laptop and didn't notice any signal quality difference when using isolator. Probably noisy PC supplies and ground loops could affect the signals.

Link to post
Share on other sites
  • 0

Thank you for reply.

 

I sum up the current situation.

 

Specifications of the power of USB isolator :

USB-029H2-RP : Work by bus power or external AC adapter. +5V is supplied to target USB connector.

USB-029L2 : Work by only bus power. No power is supplied to target USB connector.

 

(Temporaly) Results :

1. USB-029H2-RP + bus power : Good. No error occurred yet.

2. USB-029H2-RP + AC Adapter : Bad. Error occurred very often.

3. USB-029L2( + bus power) : Not good. Rarely error occurred.

 

In case of USB-029H2-RP, the power of AD2 is supplied by both external AC adapter and bus power.

On the other hand, in case of USB-029L2, the power of AD2 is supplied only by external AC adapter,  no bus power.

The result of 3.USB-029L2 was not so bad, but not good because rarely error occurred. (The worst was 2.)

One difference between USB-029H2-RP and USB-029L2 is power supply to target USB.

Is it OK if only external power was supplied, no bus power?

 

(Of cource there are other differences between USB-029H2-RP and USB-029L2.

Only USB-029H2-RP has "repeat function" to receive and remake signal.

But it is not sure if this function was effective or not.)

 

Link to post
Share on other sites
  • 0

I'm testing other environment (PC), and found that it was OK if using isolator USB-o20H2-RP by bus power with some PCs, but not good with some other PCs.

Returned value of "FDwAnalogInStatus" would be FALSE with some other PCs, too.

But the last error message was sometimes different.

Sometimes "DptiIO failed ERC:0xA" was returned.

What is the meaning of "ERC:0xA" and the difference between "ERC:0x2" ?

 

 

Link to post
Share on other sites
  • 0

When "FDwAnalogInStatus" returns FALSE, the last error code would be "0" and the last error message would be "DptiIO failed ERC:0x2" or "0xA".

It is able to restart from opening device by "FDWfDeviceOpen" function.

But sometimes the last error message would be changed from "0x2" or "0xA" to "ERC:0x7".

In case of "ERC:0x7", it is not able to restart.

The returned value of "FDWfDeviceOpen". would be FALSE, and the last error code would be "1", the last error message would be "The device is being used by other application. Device programing failed."

It is not able to open device until the PC (Windows) restarted.

What is the situation of "ERC:0x7" ?

 

Link to post
Share on other sites
  • 0

Hi @S.Kagawa

When the reconnect is not working probably the PC disabled the port due to its power surge detection.

The errors are not too meaningful in this case.

const ERC ercTransferCancelled = 2; // The transfer was cancelled or timeout occurred
const ERC ercDataSndLess = 7; // Data send failed or peripheral did not received all the sent data
const ERC ercDataSndLessRcvLess = 10; // Two errors: ercDataSndLess and ercDataRcvLess

 

Link to post
Share on other sites
  • 0

Thank you for information.

By the way, I have another problem.

This system uses 1-ch AD converter, generating voltage wave by custom mode.

The voltage of output is 0-4V because amplitude is set  4 by "FDwfAnalogOutNodeAmplitudeSet".

The problem is that the output voltage sometimes (very rarely) include certain offset value.

There are 3 steps of offset values, usualy 0V, but rarely about +200mV or -200mV .

Of course the output offset is set 0 by "FDwfAnalogOutNodeOffsetSet".

But rarely the real output voltage shifted about 200mV in plus or minus.

It seems to change offset values after un-plugged and plugged USB connector and opening device again.

What dou you think the cause?

 

Link to post
Share on other sites
  • 0

Hi @S.Kagawa

If the output would have only 2 steps, like 0 and +0.2 I would guess the calibration reading failure but with 3 steps I have no idea.

To catch such issues you could add FDwfGetLastErrorMsg right after FDwfDeviceOpen, like:

dwf.FDwfDeviceOpen(c_int(-1), byref(hdwf))
szerr = create_string_buffer(512)
dwf.FDwfGetLastErrorMsg(szerr)
print(szerr.value)

 

Link to post
Share on other sites
  • 0

Thank you for reply.

Does "calibration" mean voltage calibration for DA output?

I wonder if the reference (standard) voltage for DA output  is initialized when system started (device open or reset), but rarely it failed to set correct value.

And can "FDwfGetLastErrorMsg" get message string in any case if the returned value of previous function was "TRUE"?

I have implemented to get error message by  "FDwfGetLastErrorMsg" after functions concerned with USB communication, but  only the case if returned value of the function was "FALSE".

Link to post
Share on other sites
  • 0

Calibration parameters for all AD, DA... Scope, Wavegen, Supplies
These are stored in an eeprom and read on device opening.

When device opening succeeds, the last error could could return warnings.

Link to post
Share on other sites
  • 0

Thank you.

I checked FDwfGetLastErrorMsg after FDwfDeviceOpen, but found that the string was empty when offset value changed.

There are 3 patterns of offset, 0V, -200mV and +200mV.

+200mV occurred vely rarely, but the phenomenon is a little different from othe 2 patterns.

Please take notice light blue waves.

They are output voltage of DA converter.

"Zero.png" is pattern "0V" or "-200mV".

"Plus.png" is pattern "+200mV".

The voltage is rising from 0V to 4V by 2500 steps.

But "Plus.png" seems like stairs.

Is it somethig to get hints?

 

Zero.png

Plus.png

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now