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

[Brian Padalino]

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?

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?

> 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?

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.

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.

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?

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?

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

> 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.

> Eric

Brian