discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Re: Preliminary In-band signaling


From: Eric Blossom
Subject: [Discuss-gnuradio] Re: Preliminary In-band signaling
Date: Fri, 23 Feb 2007 14:09:21 -0800
User-agent: Mutt/1.5.9i

On Thu, Feb 22, 2007 at 12:43:13AM -0500, Brian Padalino wrote:
> On 2/21/07, Eric Blossom <address@hidden> wrote:
> >I'm planning on adding a section talking about the control channel.
> >I expect the control channel payload to be composed of a sequence of
> >ops + args that is reasonably easy to parse in the FPGA.  Control
> >channel ops will honor the timestamp too.
> >
> >One of the ops will be WRITE_REGISTER.
> >Others will include the rest of the stuff that can't be squeezed into
> >WRITE_REGISTER such as I2C_READ/WRITE, SPI_READ/WRITE
> 
> Very nice.  Are you thinking more of like a special machine language
> that gets put together based on daugherboards PLL locking times and
> sequencing of the bring up / tear down of the RF section?

I was thinking of something less general than that, though I like the
idea!  Maybe  we do it in two passes.  First pass is to implement the
existing "host driven" tuning processes by providing the appropriate
primitives for reading and writing the SPI, I2C, etc., then the second
pass is to move the actual daughterboard specific "tune" code into the
FPGA.  This would enable FPGA controlled frequency hopping, amongst
other things.

There's probably some kind of minimalistic microcontroller core at
opencores.org that we could use for this.  Something like an micro- or
pico-blaze, but free and not tied to a particular vendor.

> Knowing the sequencing times for all the daughterboards and how
> quickly we can switch between TX/RX and change frequencies is
> definitely essential to calculating guard times.  Are these documented
> anywhere, or does it require going through the datasheets and picking
> Matt's brain?

Matt's brain and the data sheets ;)

> >One of the use cases we want to be able to satisfy is TDMA waveforms.
> >In those cases you need to be able to hit a transmit slot that is
> >defined in relationship to some other receive slot.  Think about how
> >cellular mobiles work.
> >
> >The timestamp will be a free running counter that is logically
> >adjacent to the A/D and D/A i/o pins.  On receive, the value stuck into the
> >packet is the value of the counter that corresponds to the first
> >sample in the payload.  On Tx, the timestamp corresponds to the tick
> >that the first sample of the payload will be sent to the DACS.
> 
> Since all real processing occurs inside the host computer, how do we
> know how many samples we need to send back to the host during one of
> these RX sessions?  Should the duration be set in terms of samples or
> in terms of start time / stop time?

First pass, I think we just leave the RX signal processing path
running all the time.  We can control the RF front end T/R switch as
needed, but (outside of wasted bandwidth), I don't see any harm in
running the Rx chain.  

I think we'll want to stick the current value of the RSSI into the
received packet header too.

See below on h/w agc for packet based processing.


> The way I've seen it done in the past is to use an acquisition matched
> filter and look for the correlation peak, but with all the different
> modulation types available, it might not be feasible to run them all
> in the same FPGA load.

Yes.

A related issue is the control loop for the hardware AGC.
I think that there are at least two modes or versions, the continuous
stream and and the packet based version.  With the packet based
version it looks like we need quick acquistion and lockup, so that we
don't miss much of the packet.  We'll need to lock it up for the
duration of the packet for amplitude sensitive demods such as QAM or OFDM.

> As for the sequencing and setting up time slots, it might be easy to
> be able to set up some sort of TDMA epoch editor which would
> inherently have the rollover included from one epoch to the next.
> This could easily be accomplished in an M4k block in the FPGA where
> each address is the next coarse time in the transmit sequence.
> 
> In other words, if the sequence were to:
>  * Lock PLL
>  * Wait 200 us
>  * Unmute TX
>  * Wait 10 us
>  * Ramp up Modulated TX data
> 
> That could be a RAM with the subsequent addresses have a resolution of
> 10us in ticks.  The first could be a control word to lock the PLL, the
> next 20 would be NOP commands, the next command Unmute TX, NOP,
> TX_DATA.

I see.

> The only thing that might have to be considered is frequency offset
> and correction of timestamps as to account for sliding timeslots in
> the TDMA sequence.  Do you know, off hand, what the maximum frequency
> offset is for the USRP oscillator?

I believe the standard oscillator is spec'd at 50 ppm.

> On a side note, I suppose the AGC loop should be figured out to
> calculate settling time to cover the entire range for all
> daugherboards.
> 
> >We'll provide some way for the host to set or reset the counter, but
> >this really only matters in multi-board setups.  In that case (on the
> >upcoming USRP2), we'll provide h/w that supports coherent timing
> >across multiple boards.
> 
> USRP2?  Is this a major upgrade, or just a slight one?  Will there be
> a change in FPGAs to one with embedded multipliers?

Bigger FPGA (good sized Spartan III), faster/better converters,
gigabit ethernet for connection to the host.

I'm hoping that what we come up with for USB inband signaling works
pretty much the same for ethernet.  On ethernet we get variable length
packets, but other than that, I think the mapping is pretty much 1:1.

> I'm too used to these Cyclone II/III FPGA's with loads of RAM and
> loads of multipliers.

Good stuff to have!

> >No problem.  I'm planning on doing more work on the description this
> >evening or tomorrow morning.  Let me know if you think I'm missing
> >something, or if I'm designing something that's hard to implement, or
> >if you think you've got a better way to approach the problem.
> 
> I look forward to hearing your comments on my comments.
> 
> >Thanks for all your efforts on the Wiki!
> 
> No problem - I just hope the information I am reading is actually
> accurate.  I am trying my best to figure out everything you guys are
> doing as I hope to try to bring our RF channel simulator software over
> to the GNU Radio framework for work.  Our current C model is a pretty
> accurate model but can be considered a coding mess.
> 
> Brian

Also, given the FPGA resource constraints on the current USRP, I think
we should only worry about implementing a single Rx and Tx path.  I
want a solution that will work in general (and we can synthesize and
test on the Spartan III), but I don't want to spend lots of time
trying to jam multiple channels into the EP1C12.

Eric




reply via email to

[Prev in Thread] Current Thread [Next in Thread]