[Discuss-gnuradio] Error with ctrl+z
Hi, I am implementing a stop-and-wait ARQ system using RFX2400 boards. Sometimes the transmitter suddenly stops working , and if I do ctrl+c the programs stops but does not work wheras if I do ctrl +z, I recieve following error after sometime: ICE default IO error handler doing an exit(), pid = 3793, errno = 0 And, if I try to run the program again, it stops communicating with USRP with following error messages: File ./mcl_snwARQ_tx.py, line 118, in ? main() File ./mcl_snwARQ_tx.py, line 100, in main fg_rx = my_rx_graph(demods[options.modulation], rx_callback, options) File ./mcl_snwARQ_tx.py, line 30, in __init__ self.rxpath = receive_path(self, demod_class, rx_callback, options) File /root/gnuradio-3.0.2/gr-mcl/receive_path.py, line 59, in __init__ self._setup_usrp_source() File /root/gnuradio-3.0.2/gr-mcl/receive_path.py, line 119, in _setup_usrp_source fusb_nblocks=self._fusb_nblocks) File /usr/local/lib/python2.4/site-packages/gnuradio/usrp.py, line 248, in __init__ fpga_filename, firmware_filename) File /usr/local/lib/python2.4/site-packages/gnuradio/usrp1.py, line 1229, in source_c return _usrp1.source_c(*args) RuntimeError: std::runtime_error After that I need to unplug plug the USB cable to start working with it. Ultimately I need to do ctrl+z and then unplug-plug the USB cable to start woking. Can somebody help me out to resolve the problem which I am facing? I am using following settings for transmitter side: --tx-freq 2.4G --rx-freq 2.48G -r 500k -v -m gmsk --tx-amplitude 550 --rx-gain 60 and following settings for receiver side: --rx-freq 2.40G --tx-freq 2.48G -r 500k -v -m gmsk --tx-amplitude 2000 --rx-gain 75 Thanks in advance. Regards, Tarun University of Texas - Dallas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error with ctrl+z
On Tue, Mar 13, 2007 at 03:53:31PM -0600, Tarun Tiwari wrote: Hi, I am implementing a stop-and-wait ARQ system using RFX2400 boards. Sometimes the transmitter suddenly stops working , and if I do ctrl+c the programs stops but does not work wheras if I do ctrl +z, I recieve following error after sometime: ICE default IO error handler doing an exit(), pid = 3793, errno = 0 And, if I try to run the program again, it stops communicating with USRP with following error messages: I suspect that you may have missed the very first line of the debugging output which probably explains why it couldn't open the USRP. Did you capture both stdout and stderr? Eric File ./mcl_snwARQ_tx.py, line 118, in ? main() File ./mcl_snwARQ_tx.py, line 100, in main fg_rx = my_rx_graph(demods[options.modulation], rx_callback, options) File ./mcl_snwARQ_tx.py, line 30, in __init__ self.rxpath = receive_path(self, demod_class, rx_callback, options) File /root/gnuradio-3.0.2/gr-mcl/receive_path.py, line 59, in __init__ self._setup_usrp_source() File /root/gnuradio-3.0.2/gr-mcl/receive_path.py, line 119, in _setup_usrp_source fusb_nblocks=self._fusb_nblocks) File /usr/local/lib/python2.4/site-packages/gnuradio/usrp.py, line 248, in __init__ fpga_filename, firmware_filename) File /usr/local/lib/python2.4/site-packages/gnuradio/usrp1.py, line 1229, in source_c return _usrp1.source_c(*args) RuntimeError: std::runtime_error After that I need to unplug plug the USB cable to start working with it. Ultimately I need to do ctrl+z and then unplug-plug the USB cable to start woking. Can somebody help me out to resolve the problem which I am facing? I am using following settings for transmitter side: --tx-freq 2.4G --rx-freq 2.48G -r 500k -v -m gmsk --tx-amplitude 550 --rx-gain 60 and following settings for receiver side: --rx-freq 2.40G --tx-freq 2.48G -r 500k -v -m gmsk --tx-amplitude 2000 --rx-gain 75 Thanks in advance. Regards, Tarun University of Texas - Dallas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error with ctrl+z
Hi Eric
Thank you for your reply.
On 3/13/07, Eric Blossom [EMAIL PROTECTED] wrote:
I suspect that you may have missed the very first line of the
debugging output which probably explains why it couldn't open the
USRP. Did you capture both stdout and stderr?
I didn't capture the stdout and stderr, but checked with $ dmesg command and
could not find anything which could catch my eyes.
I am little bit confused about the performance of my code. Sometimes it
works properly and sometimes not. Please find the entire code for the
Transmitter end:
from gnuradio import gr, gru, modulation_utils
from gnuradio import usrp
from gnuradio.eng_option import eng_option
from gnuradio import eng_notation, tx_debug_gui
from optparse import OptionParser
import random, time, struct, sys
from transmit_path import transmit_path
from receive_path import receive_path
import fusb_options
global tx_buffer, data_counter
class my_tx_graph(gr.flow_graph):
def __init__ (self, modulator_class, options):
gr.flow_graph.__init__(self)
self.txpath = transmit_path(self, modulator_class, options)
class my_rx_graph(gr.flow_graph):
def __init__(self, demod_class, rx_callback, options):
gr.flow_graph.__init__(self)
self.rxpath = receive_path(self, demod_class, rx_callback, options)
def main ():
global tx_buffer, data_counter
data_counter=50 #No of data packets to send
def send_pkt(payload='', eof=False):
return fg_tx.txpath.send_pkt(payload, eof)
def rx_callback(ok, payload):
global tx_buffer, data_counter
(rx_data,) = struct.unpack('!H', payload[0:2])
time.sleep(0.25)
if rx_data == 255:
print Correctly Sent Data = '%d' % (tx_buffer)
data = random.randint(0,500)
send_pkt(struct.pack('!H', data) + (pkt_size - 2) * chr(data
0xff))
tx_buffer=data
data_counter-=1
else:
send_pkt(struct.pack('!H', tx_buffer) + (pkt_size - 2) *
chr(tx_buffer 0xff))
print Resend Data = '%d' % (tx_buffer)
if data_counter == 0:
send_pkt(eof=True)
sys.exit(1)
mods = modulation_utils.type_1_mods()
demods = modulation_utils.type_1_demods()
parser = OptionParser (option_class=eng_option,
conflict_handler=resolve)
expert_grp = parser.add_option_group(Expert)
parser.add_option (-m, --modulation, type=choice, choices=
mods.keys(),
default='dbpsk',
help=Select modulation from: %s [default=%%default]
% (', '.join(mods.keys()),))
parser.add_option (-s, --size, type=eng_float, default=1500,
help=set packet size [default=%default])
parser.add_option(-M, --megabytes, type=eng_float, default=1.0,
help=set megabytes to transmit [default=%default])
receive_path.add_options(parser, expert_grp)
for mod in demods.values():
mod.add_options(expert_grp)
transmit_path.add_options(parser, expert_grp)
for mod in mods.values():
mod.add_options(expert_grp)
fusb_options.add_options(expert_grp)
(options, args) = parser.parse_args ()
if len(args) != 0:
parser.print_help()
raise SystemExit
if options.rx_freq is None:
sys.stderr.write(usrp_siggen: must specify Rxeceiver RF center
frequency with -F \n)
parser.print_help()
raise SystemExit
if options.tx_freq is None:
sys.stderr.write(usrp_siggen: must specify Transmitter RF center
frequency with -f \n)
parser.print_help()
raise SystemExit
# build the graph
fg_rx = my_rx_graph(demods[options.modulation], rx_callback, options)
fg_tx = my_tx_graph(mods[options.modulation], options)
r = gr.enable_realtime_scheduling()
if r != gr.RT_OK:
print Warning: Failed to enable realtime scheduling.
fg_rx.start() # start flow graph
fg_tx.start() # start flow graph
# Start the packet transmission
pkt_size = int(options.size)
tx_buffer=0
send_pkt(struct.pack('!H', tx_buffer) + (pkt_size - 2) * chr(tx_buffer
0xff))
fg_tx.wait() # wait for it to finish
fg_tx.stop()
fg_rx.stop()
if __name__ == '__main__':
try:
main()
except KeyboardInterrupt:
pass
the reciever end has little bit of changes, but not much. For the time being
I am transmitting 0xff for ACK and 0x00 for NAK in a packet rather than
single bit.
Can you please look at the code and guide me in right direction?
Eric
Tarun
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
