Jump to content

AlanB

Members
 View Profile  See their activity

  • Posts

    21

  • Joined

  • Last visited

 Content Type 

Posts posted by AlanB

    Use Digital Discovery as a quadrature decoder

    in Test and Measurement

    Posted

    3 minutes ago, attila said:

    The latest version adds data compression for Digital Discovery. This could be used to decode such signals with higher resolution.

    That's excellent, thanks.  I know we were talking about that in a different thread, and being able to increase the rates would help a certain amount here.  However, the "feature" in question was related to the ABN signals being decoded as a protocol within the Digital Discovery itself.  Do you see that as being possible/likely?

    Use Digital Discovery as a quadrature decoder

    in Test and Measurement

    Posted

    I have an application that needs to be able to decode/count the output from a quadrature encoder (A/B pulse output with an N pulse at the zero position) over a longer period of time than the internal buffer is able to capture.  I have managed to make it work by using the Digital Discovery's acqmodeRecord streaming capture and processing the samples in my application, but this will only work at lower rates than are ideal.

    It seems like it should be comparatively simple for the hardware within the Digital Discovery to decode ABN signals as a "protocol" and output the current count value.  Is it possible to achieve this at the moment, or to add it in the future?

    Sample rate divider with acqmodeRecord

    in Test and Measurement

    Posted

    Thanks for the response.

    I've just discovered that FDwfDigitalInDividerGet() returns the expected value if I call it after starting the capture with FDwfDigitalInConfigure().

    So I can keep turning down the divider value until I start seeing data being lost/corrupted in the call to FDwfDigitalInStatusRecord()?  (And then back off a bit to account for fluctuations in USB traffic on my bus!).

    Is there any compression applied to the data in transit over USB?  Or can I expect the same results from a static signal as with a rapidly changing signal?

    Sample rate divider with acqmodeRecord

    in Test and Measurement

    Posted

    I'm trying to set up a Digital Discovery with Python to use DigitalIn/acqmodeRecord to get a constant stream of data (from inputs 24-31).  I have it set up such that I can use repeated calls to FDwfDigitalInStatus(), FDwfDigitalInStatusRecord() and FDwfDigitalInStatusData() to retrieve the samples and process them, and this seems to be OK at slower rates.  I'd like to increase the sample rates as high as possible.

    I can use FDwfDigitalInDividerSet() to set a divider to the 800MHz clock.  If I use a divider of 800 I think I get the expected pattern back from my test input.  However, reading the divider value using FDwfDigitalInDividerGet() gives a value of 1.  If I try to vary the divider that I set, the rate of my test pattern doesn't seem to match the expected rate and the read-back rate of the divider is still 1.

    It seems from the discussion in https://forum.digilent.com/topic/25184-problem-with-aquisition-mode-record that I can set dividers of 1, 2, 4, 8, 16, etc.  However, I'm sure that these aren't all valid for acqmodeRecord and reading data back while simultaneously capturing data.  What are the constraints for setting a divider, and how can I tell what divider is being used if FDwfDigitalInDividerGet() always returns 1?

    Capturing during play mode - second time around DigitalIn gives status of NotDone

    in Test and Measurement

    Posted

    I've been quite successfully going through a cycle as follows, using Python:

    • open connection to Digital Discovery device
    • enable the device/power supplies
      • configure DigitalIn to be triggered from the start of the DigitalOut device (with appropriate buffer sizes, etc)
      • call FDwfDigitalInConfigure (at which point the DigitalInStatus goes from Ready to Arm)
      • configure the DigitalOut to operate in Play mode (with appropriate sample pattern, etc)
      • call FDwfDigitalOutConfigure to trigger output of the Play mode samples (at which point the DigitalInStatus goes from Arm to Done within the time it takes me to check)
      • read the received buffer back and process
    • close the connection to the Digital Discovery

    Now I want to perform the same steps multiple times, without opening/closing the device or removing the power supplies.  However, simply repeating the inner steps causes the DigitalInStatus to behave differently on the second time through.  When I check the status either side of the call to FDwfDigitalInConfigure, instead of switching from Ready to Arm, it switches from Ready to NotDone and remains there through all the other steps.  I normally loop waiting for the Done status after calling FDwfDigitalOutConfigure, but this never happens.  I can't see the NotDone state in the documentation, or how I can properly reinitialise the device to get the steps to operate as expected.

    Digital Discovery Play Mode not outputting

    in Test and Measurement

    Posted

    Thanks for the suggestions.  With the updated version of the SDK (3.18.50) and the change to param stop-on-close, I can see the expected output from the DigitalDiscovery_PlayRecord.py example as you've shown.  I haven't had the same success with DigitalDiscovery_Play.py (yet).  However, my original Python scripts appear to have started working again, outputting the expected patterns, so the latest SDK version is the one I'll carry on with.

    Digital Discovery Play Mode not outputting

    in Test and Measurement

    Posted

    On 8/29/2022 at 9:45 AM, attila said:

    Until this bug is solved use the following workaround, call DataSet twice, before and after Configure.
    FDwfDigitalOutPlayDataSet
    FDwfDigitalOutConfigure
    FDwfDigitalOutPlayDataSet

    I have copied line 64 of DigitalDiscovery_Play.py and placed it after the Configure call, as follows: 

    # set play data array of 16 bit samples
dwf.FDwfDigitalOutPlayDataSet(hdwf, byref(rgwPlay), c_int(16), c_int(int(nPlay)))

print("Starting Digital Out...")
dwf.FDwfDigitalOutConfigure(hdwf, c_int(1))
dwf.FDwfDigitalOutPlayDataSet(hdwf, byref(rgwPlay), c_int(16), c_int(int(nPlay)))

    But I'm still not seeing any output on the output pins.  Do I need to use different parameters for the two calls to DataSet?

    Digital Discovery Play Mode not outputting

    in Test and Measurement

    Posted

    I've recently come back to my Digital Discovery after a few months away.  I installed the latest version of WaveForms (3.18.49) and got started...

    I tried running my Python script (which I'm sure *used* to work) to load a signal and play it back with Play mode.  While it appeared to run without error, I was getting inconsistent output on the pins - usually nothing at all, but I think I once had a garbled version of the output I was expecting.

    I've gone to try running the example applications to try to understand the problem, and I'm not getting what I expect there either.  Running the file "DigitalDiscovery_Play.py" from the SDK examples doesn't appear to give any output at all on the pins (I have a logic analyser connected to most of the pins labelled 24-31).  It does print out the following: 

    DWF Version: b'3.18.49'
Opening first device
Configuring Digital Out...
Samples:134217728 Rate:100000000.0Hz  Period:1.34217728s

    Should I expect more than this?  Is installing older versions of the SDK likely to be the best route forwards?

    Corrupted output when using Play mode and logic capture

    in Test and Measurement

    Posted

    As hinted at in: 

    I am seeing an issue where a pattern that is sent to a Digital Discovery for use with Play mode occasionally ends up being corrupted, with a short section of it being repeated over and over.  I think this only occurs when also capturing digital signals at higher sampling rates.  The attached code is loosely based on DigitalDiscovery_PlayRecord.py, but reordered slightly and switched to use acqmodeSingle1.  Viewing the output on an external logic analyser, I can see that it outputs the expected pattern.  However, when I increase hzRecord to 400e6, I occasionally get the partial-repeat case - although the total length of the playback is the same as expected.  Is anyone seen this before, and able to suggest what I might be doing wrong?

    test_play_2.py

    Corrupt signal using Digital Discovery Play Mode

    in Test and Measurement

    Posted · Edited by AlanB

    I have been trying to set up a pattern to play back using Play Mode, and am finding that occasionally (1 time in ~10) I see a corrupted pattern being output.  This can manifest in one of a few ways.

    The first way uses code that I've modified from the DigitalDiscovery_Play.py example.  I've shortened the pattern and used FDwfDigitalOutRunSet to ensure that it is only played a single time.  The code is as follows: 

    """
   DWF Python Example
   Author:  Digilent, Inc.
   Revision:  2021-09-10

   Requires:           
       Python 2.7, 3
"""

from ctypes import *
from dwfconstants import *
import sys
import time


if sys.platform.startswith("win"):
    dwf = cdll.dwf
elif sys.platform.startswith("darwin"):
    dwf = cdll.LoadLibrary("/Library/Frameworks/dwf.framework/dwf")
else:
    dwf = cdll.LoadLibrary("libdwf.so")

hdwf = c_int()
sts = c_ubyte()

version = create_string_buffer(16)
dwf.FDwfGetVersion(version)
print("DWF Version: "+str(version.value))

print("Opening first device")
dwf.FDwfDeviceOpen(c_int(-1), byref(hdwf))

if hdwf.value == 0:
    print("failed to open device")
    szerr = create_string_buffer(512)
    dwf.FDwfGetLastErrorMsg(szerr)
    print(str(szerr.value))
    quit()

# dwf.FDwfDeviceParamSet(hdwf, DwfParamOnClose, c_int(0)) # 0 = run, 1 = stop, 2 = shutdown
# dwf.FDwfDeviceAutoConfigureSet(hdwf, c_int(0))# 0 = the device will be configured only when calling FDwf###Configure

print("Configuring Digital Out...")

hzPlay = 10e6
# for infinite playback fill the entire 256MiByte memory, or 128Mi 16bits samples
nPlay = 1*1024
rgwPlay = (c_uint16*int(nPlay))()

for i in range(len(rgwPlay)):
    rgwPlay[i] = i

print("Samples:"+str(nPlay)+" Rate:"+str(hzPlay)+"Hz "+" Period:"+str(nPlay/hzPlay)+"s")
dwf.FDwfDigitalOutPlayRateSet(hdwf, c_double(hzPlay)) # play sample rate

# enable play mode for the wanted signals
for i in range(0, 16):
    dwf.FDwfDigitalOutEnableSet(hdwf, c_int(i), c_int(1)) # enable
    dwf.FDwfDigitalOutTypeSet(hdwf, c_int(i), c_int(5)) # DwfDigitalOutTypePlay
    dwf.FDwfDigitalOutIdleSet(hdwf, c_int(i), DwfDigitalOutIdleLow)

# set play data array of 16 bit samples
dwf.FDwfDigitalOutPlayDataSet(hdwf, byref(rgwPlay), c_int(16), c_int(int(nPlay)))

dwf.FDwfDigitalOutRunSet(
    hdwf, c_double(nPlay / float(hzPlay))
)

print("Starting Digital Out...")
dwf.FDwfDigitalOutConfigure(hdwf, c_int(1))

time.sleep(1)

dwf.FDwfDeviceCloseAll()

    This usually gives me a 102.4us burst of output as I would expect.  However it occasionally gives me a random-looking output for the first  ~12us before becoming the pattern I expect for the remaining time.  I can see this corruption using a separate logic analyser connected to the Discovery outputs.  Changing the output sample rate changes the period of the corruption - whenever it happens, it appears to be 128 samples of garbage.

    I have also seen occasions when my pattern repeats - when I output at 10MS/s the repeat happens every 102.4us.  At 5MS/s it repeats every 204.8us.  This is when I have been generating longer patterns - and they appear slightly corrupted during the some of the repeat.  I haven't managed to reproduce my program down to a simple example yet, but hoped it might be connected in some way to the issues from the first example.

    Digital Discovery, Play mode

    in Test and Measurement

    Posted

    @attila ah - that's really interesting.  So if I explicitly want to use the same rate for custom patterns for each of my (up-to-)16 outputs, I can have a far longer buffer using Play mode than if I use "normal" mode?  In normal mode I can have 32KiS/wire, but in Play mode I can have 128MiS (where each sample contains the bits for all 16 outputs).  And none of this depends on shuttling data to over USB mid-pattern?  If that's the case, then that helps a lot.

    And to confirm - this can be used at the same time as using the logic analyser capture in the same way as when generating patterns in normal mode?

    Digital Discovery, Play mode

    in Test and Measurement

    Posted

    33 minutes ago, attila said:

    Hi @AlanB

    See the WaveForms application Help and for custom application the SDK / samples/ py/ DigitalDiscovery_Play.py DigitalDiscovery_PlayRecord.py DigitalDiscovery_RecordToFile.py DigitalDiscovery_RecordToFile16.py
    It can be used at up to 100MHz and 100M samples.

    image.thumb.png.15ca1f21d34f7d3d5fc2b603db019b7e.png

    Thanks for the references.  I'd found them, but they didn't really help me to understand what's going on.  The reference manual (https://digilent.com/reference/test-and-measurement/digital-discovery/reference-manual#multi-purpose_digital_io) talks about having 32kSamples/channel when used as a pattern generator.  How is play mode different?  Is the host streaming the samples?  The demo (DigitalDiscovery_Play.py) seems to show the pattern carrying on after the application has closed, so does it have the entire 100M samples stored on the Discovery unit?

    Digital Discovery, Play mode

    in Test and Measurement

    Posted

    I have a Digital Discovery, and can use the SDK to load a 32kSample pattern to be played back as described in the reference manual.  The SDK also mentions using Play Mode, and the examples refer to what appear to be much longer buffer sizes.  Is there any documentation about how Play Mode works, what sample rates can be achieved, etc?  Can I get the full amount of digital capture at the same time?  Does it depend on available USB bandwidth to the host?  While I can find many references to it being available, I can't find a description of what its capabilities are.

×
×
  • Create New...