Visualizing FIR filter output on oscilloscope

[Ahmed Alfadhel]

Hi ,

Previously, I succeeded to generate a sinewave and visualize it on oscilloscope as shown in this post. Then I learnt how to use FIR filter compiler as shown in this post.

Now, I am trying to visualize the FIR output on oscilloscope. I generated the bit stream file for the intended design (screenshot attached) then I viewed the output using Pmod DA3 , then the surprise it was only 1s and 0s ! as shown in the second attached picture.

 Note : I tried to pass 16 kHz by the FIR.

I need your help about this issue. Any ideas about the reasons that make the output digital even when I am using DAC (Pmod DA3) ?

Thanks.

 

 

[D@n]

@Ahmed Alfadhel,

Any ideas?  Yes--watch the sign bit.  Some DACs count from zero to maximum, others from a negative number to a maximum.  If you get the sign bit wrong, you'll get a bunch of sudden and large jumps anytime your output signal crosses zero.

Dan

[Ahmed Alfadhel]

Hi @D@n,

33 minutes ago, D@n said:

@Ahmed Alfadhel,

Any ideas?  Yes--watch the sign bit.

I did a two 's complement for each byte to be written to the Pmod DA3.

As shown below:

void DA3_WriteSpi(PmodDA3 *InstancePtr, u32 wData)
{

    u8 bytearray[4];      

                                          // u32 wData it is the same tdata from fir  

                                        bytearray[0] = ((wData & 0xFF) ^ (0x80));
                                        bytearray[1] = (((wData & 0xFF00) >> 8 ) ^ (0x80));
                                        bytearray[2] = (((wData & 0xFF0000) >> 16) ^ (0x80));
                                        bytearray[3] = (((wData & 0xFF000000) >> 24) ^ (0x80));

            XSpi_Transfer(&InstancePtr->DA3Spi, bytearray, NULL, sizeof(bytearray));

}
 

___________________________________________________

Thanks

[D@n]

@Ahmed Alfadhel,

The PModDA3 has a 16-bit DAC.  Why are you sending it 8-bits at a time?  Why are your samples sourced from a 32-bit value?  Have you "packed" them somewhow and so need to unpack them?

Dan

[Ahmed Alfadhel]

@D@n,

I have to sample the FIR data in 8 bits packets (Array of bytes) each time since 

13 minutes ago, Ahmed Alfadhel said:

XSpi_Transfer(&InstancePtr->DA3Spi, bytearray, NULL, sizeof(bytearray));

is declared in xspi.c library as follow:

int XSpi_Transfer(XSpi *InstancePtr, u8 *SendBufPtr,
          u8 *RecvBufPtr, unsigned int ByteCount)
{
    u32 ControlReg;
    u32 GlobalIntrReg;
    u32 StatusReg;
    u32 Data = 0;
    u8  DataWidth;

    /*
     * The RecvBufPtr argument can be NULL.
     */
    Xil_AssertNonvoid(InstancePtr != NULL);
    Xil_AssertNonvoid(SendBufPtr != NULL);
    Xil_AssertNonvoid(ByteCount > 0);
    Xil_AssertNonvoid(InstancePtr->IsReady == XIL_COMPONENT_IS_READY);

    if (InstancePtr->IsStarted != XIL_COMPONENT_IS_STARTED) {
        return XST_DEVICE_IS_STOPPED;

.

.

.

.

.

(long code)

Thanks.

[D@n]

@Ahmed Alfadhel,

SPI transfers don't need to be 32bits in width.  Neither do they need to be 8-bits in width.  This particular SPI device appears to want 16-bit data.  I can't speak to whether or not Xilinx's SPI library is broken and unable to handle 16bit transfers, but I would be surprised if that were the case.

Looking over your block design, it looks like you are running a DDS into an FIR filter and then .... reading the results from a GPIO port??  That doesn't make any sense.

Signal processing in general is very sensitive to lost/dropped/inserted samples.  CPUs aren't known for processing data at known rates, and MicroBlaze CPUs aren't any different.   That means I'd expect your design to have gaps where data is getting dropped just from examining this structure alone.

Consider redesigning your structure to (ideally) remove the MicroBlaze/CPU from your data path entirely.  If  you can't do that, then at least place FIFOs between the data source and the CPU, as well as between the CPU and the DAC.  Otherwise you are likely to spend quite a bit of time chasing even stranger bugs than this one.

Dan