Direct Data Transmission

[ismagom]

Hi,

I am trying to build software radio application with the X5-400. Currently, everything works fine in normal data mode, and I can transmit and receive to and from the converters.

My application is built in C, so I managed to copy the data from the Buffer objects to my C arrays. Now I am trying to use direct data mode to achieve better performance. I followed the Snap example to configure the AD for reception in direct mode and found no problems (and a great improvement in CPU usage).

I would like to do the same with the DA. I attached my handler to the OnDirectDataRequired.SetEvent() but receive only two or three callbacks. Then the execution stops. I didn't found any documentation on this issue. In fact, I don't even try to put data into the board buffer, only use the

Event.Sender->DirectDataTransmitAck(packet_size);

function to acknowledge the transmission. My questions are:
- Where should I put my data, to Event.Slab.Address()??
- Does the function Module.Input().PacketSize() or Output.PacketSize() do something in direct mode? Actually I found that packets size from the A/D is fixed to 512 kbytes (I use the Slab.SizeInInts() function).

Thank you very much,
regards

[csmith]

Direct data mode does not change the operation of the board itself, which is still using packets. Therefore the packet size registers mean what they always have - the input packet size is the size that the logic will generate.

On input, in direct data mode, the contents of the slab are the packets generated by the logic - headers and data both. When sending data in direct data mode, you have to do the same thing - construct in the slab a proper data stream consisting of packet headers and data. If you just write data in, as I assume you did, the stream will be corrupt and fail. Since the slab size is a quarter of the full busmaster size, this explains why you get three notifications - you can fill 3/4 of the region before you need to wait for the board to have completed a slab. Doing an ack without copying data has the same effect - the garbage in the busmaster region is also not a valid packet stream and will cause failure virtually immediately.

To get the output to work, you need have a slab filled with entire packets - header and body. The normal application for direct data mode is to play back a data stream read earlier, so that you get this for free. If you are trying to construct the slabs yourself, its likely that you will lose most of the efficiency gains for direct mode in creating each slab by hand.

The slab size is not the same as the packet size. It is 1/4 of the busmaster region size. However the size of the packets inside the slab is controlled by the packet size parameter for input. For output, each packet can be whatever size you like, as long as the correct size is included in the packet header.

The first word of the packet header has a 8 bit PID giving the destination of the data. The remainder is the size of the entire packet (header plus body). This size must be an even number of words. The second word of the header is empty. Then comes the data block, completing that packet. this is repeated for each packet. Note that packets do not have to fit evenly in a slab or in the region, so you have to handle partial packets or be clever in sizing your data packets.