Re: [Discuss-gnuradio] Smart Antenna

2007-01-21 Thread Lin HUANG

In gnuradio-examples/python/multi-antenna or multi_usrp

Lin


2007/1/22, Roberto Mastrodonato <[EMAIL PROTECTED]>:


Hi

where cai I find MIMO USRP codes?

10x
R

2007/1/19, Lin HUANG <[EMAIL PROTECTED]>:
>
> Hi Roberto,
>
> I don't think there is code related to Smart Antenna, but many people
> are working on MIMO-USRP. The difference between them is the correlation
> between antennas. If you have antenna array for smart antenna, I think you
> may utilize some code of MIMO.
>
> Lin
>
>
> 2007/1/18, Roberto Mastrodonato <[EMAIL PROTECTED]>:
> >
> > Hi all
> >
> > is there anybody that experienced USRP projects with SMART Antenna
> > technology? If yes, where can I find codes or something else related to
> > USRP-SMART Antenna?
> > Thanks a lot
> >
> > Roberto
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
> >
>

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


[Discuss-gnuradio] Re: more gmsk issues

2007-01-21 Thread Patrick Strasser

Brett Trotter wrote:

I switched to NFS for my testing and I can transfer about 600 KiB before it
stalls for a while, but NFS seems to be good enough at re-trying over cruddy
networks


Hello Brett!

You should be aware that you are using quite high level protocols when 
using SSH or NFS. You are moving in OSI Layer 5 (Session).

Layer 1 would be PHY, the radio part.
Layer 2 would be MAC, physical addressing, media access (timing, 
concurrent access).

Layer 3 would be IP, "logical" addressing, first error detection.
Layer 4 would be TCP/UDP, with subaddressing for both, retransmistion 
and congestion control with TCP.

Layer 5 finally is your SSH/NFS.

You see an error in layer 5, which leaves lots of possibilities for 
underlying errors or misconfigurations. In general TCP is quite capable 
of recovering from lots of errors, but it's busy with itself for this 
purpose, which leaves less capacity for its payload. IP does not correct 
errors, only detects (checksums). This leaves possible error correction 
to layer 2 and 1. In layer 2 we have a mixture of Ethernet and a back 
off algorithm, pretty like ethernet, but in Python code: the framing and 
thus addressing is done by the operating system, media access is handled 
by Python, using an exponential backoff when a carrier is sensed. Note: 
AFAICS check for successful transmission is done. On Ethernet you have 
Collision Detection, which leads to backoffs and retransmits. The 
current tunnel implementation seems to just listen for traffic that 
could jam the transmission before sending. As there is no reliable way 
to detect concurrent transmissions while sending (in contrast to wire 
bound Ethernet)[1] some kind of reservation like in WLAN or at least 
acknowledge would be desirable. Layer 1 finally uses whatever modulation 
you have available, without channel coding, like forward error 
correction (FEC) with convolution codes or Reed-Solomon code.


This is quite a stack of systems with lots of places for errors. I'd 
suggest to get some levels lower and analyse at MAC (L2) and network 
layer (L3, IP). IP has checksums, so errors are very likely to be 
reported by the IP stack in the kernel. Take a look at 'iptraf'. As 
presumingly 'ifconfig' and and 'netstat -i' show interface statistics, 
that is of the MAC, you probably want to take a look at the packets 
directly. As pointed out before, tcpdump get you the packets. I like 
wireshark, formerly ethereal, for analysing data, but it needs X, 
something that is not always accessible at test machines (especially 
remote machines). nevertheless tcpdump saves data in a format that is 
fine readable for wireshark. Take a look at the IP checksum under heavy 
load. You may want to check some timing statistics too see if collision 
has probably happened. TCP retransmits are a sign for connections that 
have gone haywire.


> Anyone have any thoughts on improving the stability?

FEC would be necessary, media reservation or at least acknowledging 
would be fine.

Perhaps CRC at data link layer (L2) would bring some light in.
Emulab should have the right setup to test these things.

Patrick

[1] ALOHA as predecessor of Ethernet and being a radio system used 
acknowledge messages and retransmits. See code at

http://typo3.cs.uni-paderborn.de/en/research-group/research-group-computer-networks/projects/gsr.html
--
Engineers motto: cheap, good, fast: choose any two
Patrick Strasser 
Student of Telematik, Techn. University Graz, Austria



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Smart Antenna

2007-01-21 Thread Martin Dvh
Roberto Mastrodonato wrote:
> Hi all
> 
> is there anybody that experienced USRP projects with SMART Antenna
> technology? If yes, where can I find codes or something else related to
> USRP-SMART Antenna?
> Thanks a lot
I have been experimenting with direction finding and passive radar using 
gnuradio and multiple antenna's.
These experiments are on hold for now, due to lack of time, but I hope to 
continue with them sometime in the future.

What exactly would you like to do and with how much array-elements.
The simplest smart antenna using usrp/gnuradio I can think of is a smart 
transmitter using two antenna's.
The phase-difference you introduce between the two signals, combined with the 
positioning of your two antenna's determines the maximum and
minimum gain direction(s) of the whole system.

Introducing a fixed phase difference is just multiplying with a const complex 
number.
Phi=wanted phase difference in radians
signal=original signal to transmit
sink1=sink where the first output should go
sink2=sink where the second output should go

phasediff=gr.multiply_const_cc(gr_complex(cos(Phi),sin(Phi))
fg.connect(signal,sink1)
fg.connect(signal,phasediff,sink2)

The same goes for reception:
Phi=expected phase difference in radians

input1=signal from first antenna
input2=signal from second antenna
receiver=reception chain

phasediff=gr.multiply_const_cc(gr_complex(cos(Phi),sin(Phi))
adder=gr.add_cc()
fg.connect(signal1,(adder,0))
fg.connect(signal2,phasediff,(adder,1))
fg.connect(adder,receiver)

If you want to automatically determine the phase-differences and amplitudes 
things get much more complicated but can still be done.

I even tested with a very slow correlator and agc which automatically 
determined the phase difference of the strongest signal received and tuned
the two antenna array for maximum sensitivity for this signal.


Greetings,
Martin
> 
> Roberto
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Smart Antenna

2007-01-21 Thread Roberto Mastrodonato

Hi

where cai I find MIMO USRP codes?

10x
R

2007/1/19, Lin HUANG <[EMAIL PROTECTED]>:


Hi Roberto,

I don't think there is code related to Smart Antenna, but many people are
working on MIMO-USRP. The difference between them is the correlation between
antennas. If you have antenna array for smart antenna, I think you may
utilize some code of MIMO.

Lin


2007/1/18, Roberto Mastrodonato <[EMAIL PROTECTED]>:
>
> Hi all
>
> is there anybody that experienced USRP projects with SMART Antenna
> technology? If yes, where can I find codes or something else related to
> USRP-SMART Antenna?
> Thanks a lot
>
> Roberto
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio