mhostetter

The OOOs are likely overflows from the SDR. So it is producing more samples than the receiver can process. What is the HackRF's sample rate? I would consider halving it...

> I think you need to use the future annotations feature to retain type aliases. I did have `from __future__ import annotations` at the top of my file. I forgot...

I still run into this issue, any thoughts? I find myself changing the APIs and functionality of functions to avoid these unreadable call signatures. I appreciate the help! 🙏 Reproducer...

You need to lower the sample rate to reduce the overflows. The overflows will drop samples, which can corrupt packets and lead to CRC failures.

What branch are you building? What version of GNU Radio? What is your OS? It seems your OS is headless / doesn't have a terminal? Is that correct?

I found this https://stackoverflow.com/a/67483317/11694321. It says to add `from __future__ import annotations` to the top of the module to add this to `conf.py`. ```python autodoc_type_aliases = { "npt.DTypeLike": "~numpy.typing.DTypeLike", }...

I got no warnings. I'm including a reproducible example. [foo-270.zip](https://github.com/jbms/sphinx-immaterial/files/12044248/foo-270.zip) - With no `from __future__ import annotations` and nothing special in `conf.py` I get the expanded Union. - Adding `from...

This may be another clue... Using the `autodoc_type_aliases` trick above, the following give these outputs. ### Acceptable ```python def unpack(x: np.ndarray, bpe: int, dtype: npt.DTypeLike) -> np.ndarray: ```  ###...

I'm running into this again. This function (no `from __future__ import annotations`) ```python def db( x: npt.ArrayLike, type: Literal["value", "power", "voltage"] = "value", ) -> npt.NDArray[np.float_]: ``` is rendered like...

@ZachPence sorry for the delayed reply. Creating `GFp = GF(p)` once and then using `GFp` inside of `with Pool(2) as pool:` seems to re solve the issue. Is that satisfactory...