Hi all,
I’m trying to understand if this is possible in the FPGA. Let’s assume
we initially tune a card to 2.4G and then every 650us we want to
retune it to the prev frequency plus 100MHz, up until 2.5G and then
wrap back to 2.4G. That is very easy to accomplish using inband
command packets with timestamps spaced by 650us IF the FPGA can
somehow retune the center freq. It would probably be best to recompute
the dxc freq and such from the host, who has access to the tuning
code, and then transfers the results. Is the FPGA able to directly
access what is needed for the retune?
Thanks!
George
On Tue, May 13, 2008 at 6:44 PM, George N. [email protected] wrote:
Hi all,
I’m trying to understand if this is possible in the FPGA. Let’s assume we
initially tune a card to 2.4G and then every 650us we want to retune it to
the prev frequency plus 100MHz, up until 2.5G and then wrap back to 2.4G.
That is very easy to accomplish using inband command packets with timestamps
spaced by 650us IF the FPGA can somehow retune the center freq. It would
probably be best to recompute the dxc freq and such from the host, who has
access to the tuning code, and then transfers the results. Is the FPGA able
to directly access what is needed for the retune?
Surprisingly enough, this came up recently on the IRC channel for a
DBS RX daughterboard. I think they wanted to tune the MAX2118 chip to
do GSM frequency hopping.
Anyways, the issue is that the SPI bus goes over to the FPGA, but not
the I2C bus which connects up to the daughterboard. From what I could
tell, the I2C bus is only connected up to the FX2 so unless the
frequency hopping commands were implemented within the FX2 with
specific timers, it will definitely involve some sort of USRP hardware
modification.
The last thing you’ll have to figure out is exactly how long it takes
for your system to lock. Hopping every 650us sounds like it’s pretty
darn quick. If locking doesn’t happen for 200us, you only really get
450us of usable data before you switch again. Is there a field in the
in-band stuff that says “this transmission was received on frequency
X”? That might be useful.
Anyway, sorry for rambling. I hope this somewhat answered your
question.
Brian
The last thing you’ll have to figure out is exactly how long it takes
for your system to lock. Hopping every 650us sounds like it’s pretty
darn quick. If locking doesn’t happen for 200us, you only really get
450us of usable data before you switch again. Is there a field in the
in-band stuff that says “this transmission was received on frequency
X”? That might be useful.
Thanks Brian, this is definitely helpful.
I think I’m going to have to pass on implementing this functionality.
-
according to Matt it takes ~200us to lock to a new frequency. I
still can’t find exact Bluetooth specs in terms of guard times (which
would be the max time to hop), but I suspect its tens of microseconds.
Do you know the GSM frequency hopping times?
-
there’s no way I’m making a USRP hardware modification. However,
could something be devised where the FPGA relay’s something encapsulated
back to the FX2 to get around this? Something such as encapsulating an
I2C write in a in-band command packet, wait for the timestamp to reach,
and then strip the in-band packet out and pass it from the FPGA to the
FX2? I don’t know how possible that is.
-
I think that the dboard tuning and control for USRP2 happens in the
FPGA, according to something Jonathan mentioned to me off list. Given
that I already have a 95% full FPGA with all of the MAC-enhancements…
I don’t even know if I’d be able to fit some sort of relaying
functionality in if its even possible… which will be much easier to
do in USRP2 if tuning is done in the FPGA. So if that’s the case, this
functionality will wait for USRP2.
On Wed, May 14, 2008 at 7:40 AM, George N. [email protected] wrote:
Thanks Brian, this is definitely helpful.
No problem.
I think I’m going to have to pass on implementing this functionality.
Well hold on now - there may still be things you can do!
- according to Matt it takes ~200us to lock to a new frequency. I still
can’t find exact Bluetooth specs in terms of guard times (which would be the
max time to hop), but I suspect its tens of microseconds. Do you know the
GSM frequency hopping times?
I believe they are in the 2ms range.
- there’s no way I’m making a USRP hardware modification. However, could
something be devised where the FPGA relay’s something encapsulated back to
the FX2 to get around this? Something such as encapsulating an I2C write in
a in-band command packet, wait for the timestamp to reach, and then strip
the in-band packet out and pass it from the FPGA to the FX2? I don’t know
how possible that is.
Sounds a bit tricky and a little too complicated. I’ve got an idea to
think about (further down).
- I think that the dboard tuning and control for USRP2 happens in the
FPGA, according to something Jonathan mentioned to me off list. Given that
I already have a 95% full FPGA with all of the MAC-enhancements… I don’t
even know if I’d be able to fit some sort of relaying functionality in if
its even possible… which will be much easier to do in USRP2 if tuning is
done in the FPGA. So if that’s the case, this functionality will wait for
USRP2.
What about bandpass sampling? Nyquist just requires that we sample 2x
the bandwidth. We have that criterion met with the 64Msps ADC, and
the CIC/halfband filtering that happens takes out the high frequency
images that will occur during the mixing stage (done by the CORDIC in
the FPGA).
If we know a) the frequency range it needs to cover and b) the
frequencies it’s going to hop to, you can pick a centralized frequency
that has the most image rejection, and just twiddle the phase
increment value connected to the CORDIC and let the CIC/halfband do
the rest. Only one tuned frequency, and something that is
controllable within the FPGA can give you some significant frequency
hopping capabilities.
So what do you think? Do we know (a) and (b) listed above for
Bluetooth? For GSM?
Brian
PS - I realize this works for RX only, but there might be the option
for a separate daughterboard for the TX portion of a frequency hopping
scheme to be figured out as well without hardware mods.
On May 14, 2008, at 2:01 PM, “Brian P.” [email protected]
wrote:
- according to Matt it takes ~200us to lock to a new frequency. I
However, could
Sounds a bit tricky and a little too complicated. I’ve got an idea to
its even possible… which will be much easier to do in USRP2 if
Brian
PS - I realize this works for RX only, but there might be the option
for a separate daughterboard for the TX portion of a frequency hopping
scheme to be figured out as well without hardware mods.
I think this is a good RX hack in an attempt to decode some specific
protocol. But I guess what I was hoping for was a general technique
that provided flexible frequency hopping for any protocol. So I think
if someone really wanted a full GSM or Bluetooth decoder this is a
good idea.
I do know some people on campus trying to write a full Bluetooth
decoder so i will pass this on.
Thanks 