discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] looping with work() function


From: Activecat
Subject: Re: [Discuss-gnuradio] looping with work() function
Date: Thu, 13 Mar 2014 14:59:42 +0800

Dear Sumedha,

My idea is to create a custom block of type "general".
This block takes an input from a File Source. It has an output connect
to USRP (for transmitting signal).
It has another input port connected to USRP for receiving ACK.

See below inline answers for further elaboration.

On Thu, Mar 13, 2014 at 1:42 PM, Sumedha Goyal <address@hidden> wrote:
>> Hi Activecat,
>
> This is true that I am trying to accomplish the same task that you have
> mentioned . But the difference is:
>
> 1. I pass a threshold value to my "test_demo" block from the
> "top_block"(Example: top_block(options, 0.4)). A random number is generated
> inside the "test_demo" block and compared to this threshold.
> 2. If the random number is more than threshold, the transmission process
> starts.

We make this threshold value an argument to the constructor of the
custom block. The block will store this threshold value as its class
variable.
The random number could be generated inside the general_work() function.
Hence, before transmission of packet starts, a random number will be
generated each time the general_work() is called.
If the random number is lower than the threshold, then the
general_work() just return without performing any other action.
But make sure the returned value will make this general_work() to be
continuously called repeatedly.

> 3. The block makes transmitter USRP to send data packets in a specified
> format(source_address+destination_address+packet_sequence_no+message).
> 4. Upon receiving a packet, the receiver USRP sends an ACK.

Hence the transmitting USRP needs to have the hardware capability to
receive signal.  We feed this signal from USRP back to the custom
block.
In alternative, you could use the 3rd USRP attaching to PC#1 to
receive the ACK, but this is not likely the preferable way.

> 5. Meanwhile, the transmitter USRP counts number of data packets sent before
> receiving an ACK. As soon as the transmitter USRP receives first ACK, it
> should stop data transmission and reception of further packets from anywhere
> (from the user payload from a file source on harddisk).

Data packet counting can be done on this custom block.
When not transmitting data packets, the output of the block to USRP is
just a series of zeros.
We need to set_max_noutput_items() to a small value, so that the block
response fast enough to the ACK signal.
This block should continuously consuming input from USRP (to detect
ACK) while sending output (either data packets, or a series of zero)
to the USRP.
I think these two ports (the input and output connecting to USRP)
should have the same data rate as they are connecting to the same
USRP.

> 6. At this point, I want to be able to change the threshold value for the
> block and start the process again. The random number will be generated again
> and so on.

Without interrupting the flow graph, we can change this threshold
value using WX GUI Slider, because the threshold value is stored as a
class variable of the custom block.

> 7. I want to continue this process for several number of times and plot a
> graph between the threshold and the number of packets transmitted.

As the custom block is doing the counting of data packets, it can save
the packet counts information into a file. You could later retrieve
data from this file to plot graph, after stopping the flow graph.
If you insist to plot graph in real time, then this block could send
the packet counts information to another output port.  Be careful here
because all output ports must have same data rate. Nevertheless there
is a workaround for overcome this issue.

>
> How should I proceed?

If this confirms what you want, I could then send you a sample code.
Make sure the requirements is correct first.

Additional question to you:
When PC#1 transmit packets, PC#2 may miss the few packets before
detecting the first one.
That's why you want PC#1 to count the number of packets transmitted
before receiving ACK.
But have you ever think that, the ACK sent by PC#2 may also be missed
out by PC#1.
Then how would you handle this ..?

Regards,
Activecat



reply via email to

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