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

The tracking loop can be locked only for 4s #11

Open
zhihangQ opened this issue Nov 16, 2023 · 2 comments
Open

The tracking loop can be locked only for 4s #11

zhihangQ opened this issue Nov 16, 2023 · 2 comments

Comments

@zhihangQ
Copy link

Dear tomojitakasu,

I am writing to discuss an issue we encountered while working on this project.

Firstly, we would like to express our gratitude for the amazing open source project you have provided. We followed the project guidelines and successfully created the PCB. Additionally, we completed the driver installation and all the required configurations.

Afterwards, we proceeded to capture the signal for a duration of 100 seconds and performed tests using the pocket_acq.py and pocket_trk.py scripts. The signal acq process did not encounter any problems. However, when testing with pocket_trk.py, we noticed that the tracking loop only remained locked for the initial 4 seconds of every 10-second interval. Interestingly, when using simulated signal testing, the lock was maintained continuously.

We are reaching out to seek your expertise in understanding the underlying cause of this issue and to inquire about potential solutions. We apologize for any inconvenience caused and genuinely appreciate any assistance you can provide.

Thank you for your time and consideration. We eagerly await your response.

Best regards

@tomojitakasu
Copy link
Owner

A potential cause of your problem is dropping some USB packets between the RF frontend and your PC when pocket_dump.exe is running. In my experience, this situation could be encountered in the following conditions:

(1) Other USB or BT device(s) connected to PC
(2) Higher sampling rate (e.g. 24 Msps)
(3) Poor PC performance
(4) Specific OS version and USB host driver (I confirmed Ubuntu 20.04 and libusb-1.0 have a problem)

In such conditions, OS-level higher priority tasks may block some USB interrupts and cause drop of the USB packets containing DIF sampling data.

In my environment (Laptop PC with Core i7-1260P, Windows 11, MSYS2 MinGW x64, with no BT mouse), I had have no problem even with the sampling rate of 24Msps.

@zhihangQ
Copy link
Author

Thanks for getting back to us! We conducted additional tests today, and it's confirmed that the data collection returned to normal after disabling the PC's Bluetooth. Your input has been invaluable in resolving this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants