On Wed, Feb 21, 2007 at 11:11:43PM -0500, Brian Padalino wrote: > Eric, > > I realize what you have checked in is strictly very preliminary (hence > keeping this off-list), but I was curious if you had plans to add > basically every one of the FPGA register settings that might get set > for each burst transmission.
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 > I was also curious in regards to the timestamp field and > synchronization. Since the FPGA has no sense of time other than clock > ticks, what kind of reference does that timestamp really give? 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. 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. We'll also have to work out some way for the host to estimate round-trip latency looped-back through the Tx/Rx path. > Sorry if this is just too soon. 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. Thanks for all your efforts on the Wiki! Eric _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio