Probably the best way to do this is to get your phone to either tell you
the ARFCN it's on (and not many do), or the cell ID. If you get a cell ID,
you'd need to scan the downlink frequencies for that particular cell ID.
Once you find the downlink frequency, the uplink should be a constant
offset a
There are also far-field RFID systems, such as the EPC Gen2 standard that
was intended to replace product barcodes but has found itself in other
applications such as toll road tags and DHS-compliant IDs.
One potential problem with trying to detect these systems with GNU Radio is
that the tags them
The volk issue is old:
https://gnuradio.org/redmine/issues/722
On Sun, Mar 27, 2016 at 6:21 PM, Alexander Levedahl <
alexanderleved...@gmail.com> wrote:
> Two questions:
> 1) Have you been able to run any that do not require a GUI? There error
> appears to be related to a GUI.
> 2) What happens
I believe so; see gnuradio/gr-digital/python/digital/generic_mod_demod.py:
...
# symbol timing recovery with RRC data filter
taps = filter.firdes.root_raised_cosine(nfilts,
nfilts*self._samples_per_symbol,
1.0, self._excess_bw, ntaps)
I'm trying to use the correlate_and_sync block to get an initial timing
estimate from a packet radio, but it doesn't seem to work at all. I decided
to dig a bit deeper and try to figure out what it was doing. As it turns
out, the sequence it correlates against seems to be completely wrong.
Here's a
If the packets have a preamble, there's a block called correlate_and_sync
which should do what you want, although it has some issues. See a thread I
started a few days ago about that...
On Thu, Apr 2, 2015 at 3:36 PM, Mike Willis wrote:
> I have an application that needs to decode short bursts o
