Hi,
I have got this error message when i’m trying to use this two commands
to free up the usb resource,
modprobe -vr ehci_hcd
modprobe -v ehci_hcd
the error message is:
usb_control_msg failed: error sending control message: Cannot send after
transport endpoint shutdown
Can anyone help me with this? i don’t really quite understand this error
message… It was initially working fine until i tried it for the second
time… Regards,Joreen
On Wed, Jan 28, 2009 at 01:41:06PM +0800, Joreen T. wrote:
usb_control_msg failed: error sending control message: Cannot send after transport endpoint shutdown
Can anyone help me with this? i don’t really quite understand this
error message… It was initially working fine until i tried it for
the second time… Regards,Joreen
From the modprobe man page, note particularly the second paragraph:
-r --remove
This option causes modprobe to remove, rather than insert
a mod-
ule. If the modules it depends on are also unused,
modprobe
will try to remove them, too. Unlike insertion, more
than one
module can be specified on the command line (it does
not make
sense to specify module parameters when removing modules).
There is usually no reason to remove modules, but some
buggy
modules require it. Your kernel may not support removal
of mod-
ules.
Eric
I’m trying it on the benchmark_tx and benchmark_rx scripts as i need to
make it at least a half duplex communication between the two devices, i
need to free up the resources if not i will get error message that
states that the resource is busy.
Another question that i observed is that, there seems to be no way to
stop the receiver once it is activated unlike the transmitter. Any
suggestions to that?Regards,Joreen> Date: Tue, 27 Jan 2009 21:48:10
-0800> From: [email protected]> To: [email protected]> CC:
[email protected]> Subject: Re: [Discuss-gnuradio] help: cannot
send after transport endpoint shutdown> > On Wed, Jan 28, 2009 at
01:41:06PM +0800, Joreen T. wrote:> > > > Hi,> > > > I have got this
error message when i’m trying to use this two commands to free up the
usb resource,> > > > modprobe -vr ehci_hcd> > modprobe -v ehci_hcd> > >
the error message is: > > > > usb_control_msg failed: error sending
control message: Cannot send after transport endpoint shutdown> > > Can
anyone help me with this? i don’t really quite understand this> > error
message… It was initially working fine until i tried it for> > the
second time… Regards,Joreen> > > From the modprobe man page, note
particularly the second paragraph:> > -r --remove> This option causes
modprobe to remove, rather than insert a mod-> ule. If the modules it
depends on are also unused, modprobe> will try to remove them, too.
Unlike insertion, more than one> module can be specified on the command
line (it does not make> sense to specify module parameters when removing
modules).> > There is usually no reason to remove modules, but some
buggy> modules require it. Your kernel may not support removal of mod->
ules.> > Eric
On Wed, Jan 28, 2009 at 04:43:36PM +0800, Joreen T. wrote:
I’m trying it on the benchmark_tx and benchmark_rx scripts as i need
to make it at least a half duplex communication between the two
devices, i need to free up the resources if not i will get error
message that states that the resource is busy.
It’ll run half duplex automatically if you enable “auto_tr” mode…
…And benchmark_{rx,tx} are already set to do that.
See line 73 in receive_path.py and line 99 in transmit_path.py (line
numbers are from the trunk.)
Another question that i observed is that, there seems to be no way to
stop the receiver once it is activated unlike the transmitter.
“Auto T/R” (Automatic Transmit/Receiver switching) handles it for you.
With Auto T/R enabled, the receiver runs unless there are samples in
the Transmit FIFO. This is handled in the FGPA.
See the USRP FAQ and look at the inline docs in usrp_standard.h and
usrp_basic.h. These two files implement the fundamental interface to
the USRP. Almost all of that interface is available in Python.
http://gnuradio.org/trac/wiki/UsrpFAQ
Eric
On Thu, Jan 29, 2009 at 01:56:43PM +0800, Joreen T. wrote:
If i want the usrp to act as both of a transmitter and a receiver at
one station, meaning i want the usrp to be able to transmit and
receive at the same time, which file should i activate instead?
Do you want to transmit and receive simultaneously or half-duplex?
I was under the impression that you were trying to do half-duplex.
Take a look at tunnel.py for a half-duplex example.
I don’t understand the following statement “Auto T/R” (Automatic
Transmit/Receiver switching) handles it for you. With Auto T/R
enabled, the receiver runs unless there are samples in the Transmit
FIFO. This is handled in the FGPA", could you provide some sample
code or example to illustrate how to achieve this
See tunnel.py (it’s got a lame MAC, but it demonstrates auto_tr).
Eric
If i want the usrp to act as both of a transmitter and a receiver at one
station, meaning i want the usrp to be able to transmit and receive at
the same time, which file should i activate instead?
I don’t understand the following statement “Auto T/R” (Automatic
Transmit/Receiver switching) handles it for you. With Auto T/R enabled,
the receiver runs unless there are samples in the Transmit FIFO. This is
handled in the FGPA", could you provide some sample code or example to
illustrate how to achieve this?Regards,Joreen> Date: Wed, 28 Jan 2009
10:36:05 -0800> From: [email protected]> To: [email protected]> CC:
[email protected]> Subject: Re: [Discuss-gnuradio] help: cannot
send after transport endpoint shutdown> > On Wed, Jan 28, 2009 at
04:43:36PM +0800, Joreen T. wrote:> >> > I’m trying it on the
benchmark_tx and benchmark_rx scripts as i need> > to make it at least a
half duplex communication between the two> > devices, i need to free up
the resources if not i will get error> > message that states that the
resource is busy.> > It’ll run half duplex automatically if you enable
“auto_tr” mode…> > …And benchmark_{rx,tx} are already set to do
that. > See line 73 in receive_path.py and line 99 in transmit_path.py
(line> numbers are from the trunk.)> > > Another question that i
observed is that, there seems to be no way to> > stop the receiver once
it is activated unlike the transmitter.> > “Auto T/R” (Automatic
Transmit/Receiver switching) handles it for you.> With Auto T/R enabled,
the receiver runs unless there are samples in> the Transmit FIFO. This
is handled in the FGPA.> > See the USRP FAQ and look at the inline docs
in usrp_standard.h and> usrp_basic.h. These two files implement the
fundamental interface to> the USRP. Almost all of that interface is
available in Python.> > http://gnuradio.org/trac/wiki/UsrpFAQ> > Eric
On Sat, Jan 31, 2009 at 10:59:10PM +0800, Joreen T. wrote:
The program is able to activate and start to receive. However, i couldn’t actually stop the receiver to go back to the transmitter mode after doing so.
Some help on this will be much appreciated! thanks!Regards,Joreen> Date: Thu, 29 Jan 2009 11:20:59 -0800> From: [email protected]> To: [email protected]> CC: [email protected]> Subject: Re: [Discuss-gnuradio] help: cannot send after transport endpoint shutdown> > On Thu, Jan 29, 2009 at 01:56:43PM +0800, Joreen T. wrote:> > > > If i want the usrp to act as both of a transmitter and a receiver at> > one station, meaning i want the usrp to be able to transmit and> > receive at the same time, which file should i activate instead?> > Do you want to transmit and receive simultaneously or half-duplex?> I was under the impression that you were trying to do half-duplex.> > Take a look at tunnel.py for a half-duplex example.> > > I don’t understand the following statement “Auto T/R” (Automatic> > Transmit/Receiver switching) handles it for you. With Auto T/R> > enabled, the receiver runs unless there are samples in the Transmit> > FIFO. This is handled in the FGPA", could you provide some sample> > code or example to illustrate how to achieve this> > See tunnel.py (it’s got a lame MAC, but it demonstrates auto_tr).> > Eric
Joreen, your message quoting style (reflowing the “quoted” text, thus
destroying its structure) makes your messages nearly impossible to sort
out. See above. Please figure out how to tame your email tool.
Thanks,
Eric
Hi, I’m so sorry. This is the original email message.
I am actually trying to do a half duplex (receive) using one board
(900MHz) and half duplex (transmit) using another board (1800MHz) in the
same usrp. I have another usrp for the same function. I actually make
use of the benchmark_rx and benchmark_tx files to modify the codes to
make the receiver send an acknowledgement back to the transmitter to
acknowledge the receive of the packet and proceed with asking the
transmitter to send the next packet. I used the following code inside
the transmitter, to call the receiver to wait for an ack.
os.system(“python benchmark_tx.py --freq 900 --bitrate 500k”)The program
is able to activate and start to receive. However, i couldn’t actually
stop the receiver to go back to the transmitter mode after doing so.
Some help on this will be much appreciated! thanks!Regards,Joreen
Hi,
i am actually trying to do a half duplex (receive) using one board
(900MHz) and half duplex (transmit) using another board (1800MHz) in the
same usrp. I have another usrp for the same function.
I actually make use of the benchmark_rx and benchmark_tx files to modify
the codes to make the receiver send an acknowledgement back to the
transmitter to acknowledge the receive of the packet and proceed with
asking the transmitter to send the next packet.
I used the following code inside the transmitter, to call the receiver
to wait for an ack.
os.system(“python benchmark_tx.py --freq 900 --bitrate 500k”)
The program is able to activate and start to receive. However, i
couldn’t actually stop the receiver to go back to the transmitter mode
after doing so.
Some help on this will be much appreciated! thanks!Regards,Joreen> Date:
Thu, 29 Jan 2009 11:20:59 -0800> From: [email protected]> To:
[email protected]> CC: [email protected]> Subject: Re:
[Discuss-gnuradio] help: cannot send after transport endpoint shutdown>
On Thu, Jan 29, 2009 at 01:56:43PM +0800, Joreen T. wrote:> > > > If
i want the usrp to act as both of a transmitter and a receiver at> > one
station, meaning i want the usrp to be able to transmit and> > receive
at the same time, which file should i activate instead?> > Do you want
to transmit and receive simultaneously or half-duplex?> I was under the
impression that you were trying to do half-duplex.> > Take a look at
tunnel.py for a half-duplex example.> > > I don’t understand the
following statement “Auto T/R” (Automatic> > Transmit/Receiver
switching) handles it for you. With Auto T/R> > enabled, the receiver
runs unless there are samples in the Transmit> > FIFO. This is handled
in the FGPA", could you provide some sample> > code or example to
illustrate how to achieve this> > See tunnel.py (it’s got a lame MAC,
but it demonstrates auto_tr).> > Eric
On Sat, Jan 31, 2009 at 10:59:10PM +0800, Joreen T. wrote:
Hi,
i am actually trying to do a half duplex (receive) using one board
(900MHz) and half duplex (transmit) using another board (1800MHz) in
the same usrp. I have another usrp for the same function.
I actually make use of the benchmark_rx and benchmark_tx files to
modify the codes to make the receiver send an acknowledgement back
to the transmitter to acknowledge the receive of the packet and
proceed with asking the transmitter to send the next packet.
I used the following code inside the transmitter, to call the
receiver to wait for an ack.os.system(“python benchmark_tx.py --freq 900 --bitrate 500k”)
The program is able to activate and start to receive. However, i
couldn’t actually stop the receiver to go back to the transmitter
mode after doing so.
Joreen, I think this will be easier if you keep both the transmitter
and receiver in a single top_block, like is done with tunnel.py.
benchmark_rx uses receive_path as does tunnel.py. Likewise
benchmark_tx uses transmit_path as dooes tunnel.py
My thought is that you ought to be able to reuse the guts of
benchmark_tx and rx in a single program that does what you want.
Also, I don’t think that you need to explicitly stop the receiver.
The Auto T/R stuff will ensure that it’s stopped when the transmitter
is running.
Eric
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs