Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid obsolete samples in the RX Stream #255

Closed
kartarr opened this issue Jun 11, 2014 · 8 comments
Closed

Avoid obsolete samples in the RX Stream #255

kartarr opened this issue Jun 11, 2014 · 8 comments
Assignees
Labels
Issue: Bug It's a bug and it oughta be fixed

Comments

@kartarr
Copy link

kartarr commented Jun 11, 2014

There is a phase jump after the first 9728 (19x512) samples in the RX signal. In the following measurements without re-opening the device, this samples are filled with old data.

The quick fix is to draft first 9728 samples from the RX signal.

@kartarr kartarr closed this as completed Jun 11, 2014
@kartarr kartarr reopened this Jun 11, 2014
@bpadalino
Copy link
Contributor

It appears that the stale samples in the stream can be discarded by opening the device and closing it again. This should give a clue as to where the samples are still being buffered - in the FX3 or in the FPGA.

My inkling is that it is in the FX3 somewhere, but further analysis is required to squash this bug.

Thanks for being persistent on this issue, @kartarr!

@bpadalino
Copy link
Contributor

The DMA channel is cleared on set/clear_feature(ep_halt). Need to make sure that both the EP and GPIF DMA buffers are cleared since this isn't done automatically with the FX3.

Assigning to @jynik since he is most familiar with this functionality.

@jynik jynik added the bug label Jul 5, 2014
@jynik jynik changed the title [libbladeRF] Avoid obsolete samples in the RX Stream Avoid obsolete samples in the RX Stream Jul 5, 2014
jynik added a commit that referenced this issue Jul 12, 2014
Stale RX and TX samples have been reported (issue #255). This occurs
because the CyU3PResetEp() call does not reset DMA channels and their
underlying DMA buffers, nor does it clear the DMA buffers associated
with an endpoint.

Use of the existing ClearDMAChannel() as is would have required some
ridiculous shoehorning, so some cleanup was done:

    - Endpoint halt & ACK operations have been removed from
      ClearDMAChannel(). These operations are outside of the scope
      of clearing DMA buffers, and have been moved to their respective
      locations in handling set/clear halt endpoint requests.

    - reset_endpoint() has been added to the NuandApplication function
      table. Internally, this operation is now used in performing
      the halt_endpoint() operation.

    - Misc return value checks added. Granted, these don't help much
      as there's no accessible debug log.
@jynik
Copy link
Contributor

jynik commented Jul 12, 2014

I've pushed a pending fix to dev-issue_255.

@robertghilduta, @bpadalino, and @kartarr -- Could I trouble you guys to take a look and test drive this as well? For your convenience, a pre-built image is up here

(The above file will be removed after this issue is resolved.)

@bpadalino
Copy link
Contributor

Confirmed that it appears fixed to me, but input fro @kartarr is still recommended.

@kartarr
Copy link
Author

kartarr commented Jul 15, 2014

Hi guys...
Sorry for the late reply. The obsolete samples are gone.

However I can still notice the phase jump between samples 9727-9728. It seems like a variable number of samples is missing. I am using sync interface. The occurrence is rare, irregular and impossible to detect (no gap between the timestamps if meta enabled). I am trying to find how to reproduce or detect it, but in the moment, I can't find any hints. Opening the device and closing it again doesn't have impact on it.

One observation: If I reopen device between measurements, in some cases there is a gap in the timestamps between packets 22 and 23 (i.e. 24272 followed by 40904). I think, this could have a connection to the phase jumps. Without reopen, the timestamps are always consistent.

@jynik
Copy link
Contributor

jynik commented Jul 15, 2014

I'll plan to merge fix for the stale samples in to master, tag and post a new firmware, and mark this issue closed.

Let's plan to open a separate issue tracker item for the phase jump. @robertghilduta, @bpadalino and I are actively working on getting timestamp support into libbladeRF, we will likely run into this while running some tests.

@kartarr, your above observations pertain to issue #265, correct? If so, let's copy your observations into that issue, to keep the thread self-contained.

@kartarr
Copy link
Author

kartarr commented Jul 15, 2014

Sure, you made a good job...

I am not sure if my observations is the same as in #265 or new issue. It seems to be more general problem. I will make a couple more tests to make the decision...

jynik added a commit that referenced this issue Jul 19, 2014
Stale RX and TX samples have been reported (issue #255). This occurs
because the CyU3PResetEp() call does not reset DMA channels and their
underlying DMA buffers, nor does it clear the DMA buffers associated
with an endpoint.

Use of the existing ClearDMAChannel() as is would have required some
ridiculous shoehorning, so some cleanup was done:

    - Endpoint halt & ACK operations have been removed from
      ClearDMAChannel(). These operations are outside of the scope
      of clearing DMA buffers, and have been moved to their respective
      locations in handling set/clear halt endpoint requests.

    - reset_endpoint() has been added to the NuandApplication function
      table. Internally, this operation is now used in performing
      the halt_endpoint() operation.

    - Misc return value checks added. Granted, these don't help much
      as there's no accessible debug log.
jynik added a commit that referenced this issue Jul 19, 2014
Stale RX and TX samples have been reported (issue #255). This occurs
because the CyU3PResetEp() call does not reset DMA channels and their
underlying DMA buffers, nor does it clear the DMA buffers associated
with an endpoint.

Use of the existing ClearDMAChannel() as is would have required some
ridiculous shoehorning, so some cleanup was done:

    - Endpoint halt & ACK operations have been removed from
      ClearDMAChannel(). These operations are outside of the scope
      of clearing DMA buffers, and have been moved to their respective
      locations in handling set/clear halt endpoint requests.

    - reset_endpoint() has been added to the NuandApplication function
      table. Internally, this operation is now used in performing
      the halt_endpoint() operation.

    - Misc return value checks added. Granted, these don't help much
      as there's no accessible debug log.
@jynik
Copy link
Contributor

jynik commented Jul 20, 2014

Fix introduced in 55713e8, which is included in FW v1.7.1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue: Bug It's a bug and it oughta be fixed
Projects
None yet
Development

No branches or pull requests

3 participants