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.
Thanks Brian, this is definitely helpful.
I think I'm going to have to pass on implementing this functionality.
1. 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?
2. 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.
3. 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.
- George
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
