Issue transmitting samples using vector i/o

GNU Radio
1

I’m running into issues with the sendmsg command in the vectorized
send path. Depending on the buffer size I get an error returned for
“Bad Address”

ethernet:write_packetv: send: Bad address

I’m working at the c++ level right now and my program is pretty simple:

usrp2::usrp2::sptr u2 = usrp2::usrp2::make(interface,mac_addr);

usrp2::tx_metadata md;
md.timestamp = -1;
md.start_of_burst = 1;
md.send_now = 1;

uint32_t buf[1000];
u2->tx_raw(0,buf,sizeof(buf),&md);

around a buffer size of 200 I will start seeing some sends get bad
address returned, for a size less than 200 it may happen but I have
not seen any occurrences. Something like a buffer of 1000 (11 frames
needed to be transmitted) never succeeds.

Any ideas about the relation between this buffer size/num frames and
sendmsg returning bad address? Am I using this incorrectly (i know I
should be using something like tx_fc32, but the data doesn’t matter to
me right now) ?

Also, what are the reasons for using the vector i/o in this instance?

OS: Ubuntu 9.04
Using dev code from git

Charles

2

On Mon, Feb 08, 2010 at 12:23:25PM -0500, Charles I. wrote:

usrp2::tx_metadata md;
md.timestamp = -1;
md.start_of_burst = 1;
md.send_now = 1;

uint32_t buf[1000];
u2->tx_raw(0,buf,sizeof(buf),&md);

/*!
* \brief transmit raw uint32_t data items to USRP2
*
* The caller is responsible for ensuring that the items are
* formatted appropriately for the USRP2 and its configuration.
* This method is used primarily by the system itself. Users
* should call tx_32fc or tx_16sc instead.
*
* \param channel specifies the channel to send them to
* \param items are the data items to transmit
* \param nitems is the number of items to transmit
* \param metadata provides the timestamp and flags
*/
bool tx_raw(unsigned int channel,
const uint32_t *items,
size_t nitems,
const tx_metadata *metadata);

The 3rd arg is the number of 32-bit items.

Try using sizeof(buf)/sizeof(buf[0])

Also, unless you’re running on a big endian machine, you’re going to
need to handle the endianness issue or use the slightly higher level
interfaces tx_32fc or tx16_sc.

Eric