trellis.fsm method invoked with polynomials
Hello, I have noticed that such a method ia available: //# Automatically generate the FSM from the generator matrix //# of a (n,k) binary convolutional code //## fsm::fsm(int k, int n, const std::vector& G) I am doing some experimentation with BPSK31 code generation which uses Rate=1/2, Constraint length=5 convolutional code, polys are 0x17 and 0x19 now, k = 5 and n = 2, but how do I describe the polys in terms of array? I though, being poly1=0b10111 and poly2=0b11001, I had to specify them as a single array [1,0,1,1,1,1,1,0,0,1], but the comment talks about the generator matrix. Unluckily any attempt to specify a matrix returns error, and the C code seems to confirm an array is expected. any help? thank in advance matteo
Re: [Discuss-gnuradio] Flow with multiple sources, modulators and single
I finally solved the problem, which was connected to the use of the NBFM modulator. Swapping it for an integrator followed by a VCO, everything works wonders. Here's the link to the working implementation of a multimode transmitter https://bitbucket.org/matteone/gnuradio/src/master/TX/HackRF-nbfm-am-dsb-usb-lsb-Transmit.grc Il gio 24 ott 2019, 07:11 Matteo Campanella ha scritto: > Thanks for the link Ron, that’s indeed an interesting solution. > > I’m still trying to understand why the matrix multiplier approach blocks > though, and if there is a way to make it work, as it is so easy to > implement a complete solution with multiple sources and multiple > modulations and a single sink that you can switch at runtime ... maybe it > blocks because of the different delays introduced by the filters on the two > branches I’m trying to multiply? > > Matteo >
Re: [Discuss-gnuradio] Flow with multiple sources, modulators and single
Thanks for the link Ron, that’s indeed an interesting solution. I’m still trying to understand why the matrix multiplier approach blocks though, and if there is a way to make it work, as it is so easy to implement a complete solution with multiple sources and multiple modulations and a single sink that you can switch at runtime ... maybe it blocks because of the different delays introduced by the filters on the two branches I’m trying to multiply? Matteo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Flow with multiple sources, modulators and single sink
Hello, I am trying to design a flow which implements a transmitter with two sources (a signal generator or an audio source), two modulator flows (nbfm and am) and a single sink (my hackrf device via osmosdr block). The idea would be to make the sources and modulators switchable via a GUI drop down; since I noticed the select has been deprecated as module, my idea was to use a matrix multiplier between sources and modulators flows (2 inputs, 2 outputs) and a matrix multiplier (2 inputs one output) between modulator flows and sink. I've noticed that this does not work. As long as I have one matrix multiplier only, with the two flows never recombining again, everything is fine; as soon as I add the output matrix multiplier, the whole graph gets stuck. I'm pretty sure it has to do with the synchronization of blocks, but I can't find a solution... anyone has a hint of how to make things work? The problem happens even if I swap the output matrix multiplier with an adder. here is the grc - https://bitbucket.org/matteone/gnuradio/src/master/TX/HackRF-nbfm-am-Transmit.grc best 73 de iz2eeq ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RDS decoder with graphuical interface
Hello everyone, I have just finished testing with good results a new implementation of RDS decoding. This work is based on the rds block published on the list some time ago from Ronnie Gaensli, and later adapted by Ryan Shoff. Main changes from the original version posted: biphase_decoder: 1) loss of sync implemented 2) samples consumption fixed when aligning clock and signal data_decoder_cc: 1) sync is now based on syndrome calculation 2) loss of sync implemented 3) group decoding for all of the 30 possible group types (work in progress) 4) message model implemented to send decoded information to graphical frontend The solution is made up of a custom block gr-rds, contained in the gr-rds-new.tgz archive, and some python files, stored in rds.tgz. After compiling and installing the block, you will need to run rds_scope.py to use the software. It makes use of rds_rx.py where the rds receiver chain is implemented, and rdspanel.py where the wxwidgets panel. As soon as valid RDS info is received and locked the appropriate fields on the interface will change accordingly - some fields as name of the station, program type and so on will show the appropriate strings, while the "flag" fields will light RED if the corresponding function is active according to decoded RDS. The whole thing gets reset upon frequency change. This is still work in progress as not all the group types are currently managed (there is a case in the switch, but no code into it). This is the link where you can download tgz archives from: http://digilander.libero.it/iz2eeq/#rds Reports, comments and suggestions are welcome as always. Matteo iz2eeq ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] error using SetLabel
Thank you so much Johnatan for the hint - that was the problem indeed!!! I followed the approach used in scopesink.py, encapsulating a gr message in a wx DATA EVENT, letting the panel manage the data extraction and presentation. It works fine now! thank you very much Matteo iz2eeq On Sun, 2007-01-14 at 08:30 -0800, Johnathan Corgan wrote: > On Sun, 2007-01-14 at 08:50 +0100, Matteo Campanella wrote: > > > Pango-ERROR **: file pango-layout.c: line 3230 > > (pango_layout_check_lines): assertion failed: (!layout->log_attrs) > > aborting... > > I have had a very similar problem in the past. > > I'd give it a high probability you are running into a threading issue. > wxWidgets is *not* reentrant, and updating controls from a thread > different from the one that is running the wxWidgets event loop will > create all sorts of problems eventually. > > The solution is to create a custom wxWidgets event, then use wxPostEvent > in your GR call back function. You then use a normal wxWidgets callback > function to handle that event to update the control. > > This link has some slightly outdated notes on doing this from C++; > you'll have to translate them mentally to the wxPython domain: > > http://www.wxwidgets.org/wiki/index.php/Custom_Events > > It's a major pain, especially if you have to do it for several different > event types. But the key difference is that wxWidgets main thread is > the one that is running and calling your wxWidgets event handler, so > there are no reentrancy issues. > > I beat my head against the wall for a couple days on this once :-( > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] error using SetLabel
Hello, I hope some wxWidgets / GNOME experts will know about this problem: I use the StaticText.SetLabel to change the value of a label at runtime from a python callback from a custom block. Randomly I get this GNOME error: Pango-ERROR **: file pango-layout.c: line 3230 (pango_layout_check_lines): assertion failed: (!layout->log_attrs) aborting... Thinking that there was something wrong with changing the text of a StaticText, I change the call into SetForegroundColour, but I have exactly the same behaviour... any hint? best regards Matteo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] strange consume behaviours on blocks with mulitple input channels
> // From this point sync clk
> //
> d_sign_last = (clk[0] > 0 ? 1: -1);
> for (i = 0; i < n_clk_in ; i++) {
> sign_current = (clk[i] > 0 ? 1: -1);
> if(sign_current != d_sign_last) {
> // zc in clock
> consume(1, i);
> break;
> }
> d_sign_last = sign_current;
> }
>
> enter_locked();
> return 0; // No output produced, but now sync...
>
>
> The break after consume may be incorrect. If it's executed you do not
> set d_sign_last to the new sign (sign_current).
>
> Eric
>
>
If the break is executed, we have clock and signal aligned; enter_locked()
and return are executed after break and on next work invocation we will be
in the sync state, that is the other case of the switch.
Matteo
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] strange consume behaviours on blocks with mulitple input channels
I have attached the source file where the work method is contained. I
cannot make any assumption on delta - it can be even or odd, the loss of
precision because of the division by two is not going to be a problem
though as there are many hundredths of samples per symbol (input sample
rate to block is 256kbps). More, the consume on the signal works, infact
on the next work invocation I get the signal samples the right way - the
problem is on the clock cycle:
// From this point sync clk
//
d_sign_last = (clk[0] > 0 ? 1: -1);
for (i = 0; i < n_clk_in ; i++) {
sign_current = (clk[i] > 0 ? 1: -1);
if(sign_current != d_sign_last) {
// zc in clock
consume(1, i);
break;
}
d_sign_last = sign_current;
}
enter_locked();
return 0;
here I would expect to consume clock samples up to the first sample after
level transition; however if I graph clock on the next work
run, clock is NOT a the transition point.
If I change the code this way:
i=i-(delta/2);
d_sign_last = (clk[i] > 0 ? 1: -1);
...code as above follows...
so that search for clock transition is done not starting from sample #0,
but from a sample somehow near to where I actually am on signal so that
consume on channel 1 will be similar (in number of samples to consume) to
consume on channel 0, then I experience correct sample consuming and
clock/signal alignment on the next work cycle.
regards
Matteo iz2eeq
> On Wed, Jan 03, 2007 at 09:32:06AM +0100, Matteo Campanella wrote:
>> There is no forecast method implemented, and the main cycle is
>> structured
>> so that it is impossible to consume more than offered from scheduler
>> (see
>> http://lists.gnu.org/archive/html/discuss-gnuradio/2006-12/msg00253.html
>> for code posting).
>
> The code's a little hard to follow in the archive. However, this
> piece of code looks potentially suspicious. Is delta always even, or
> always odd? Are you sure that this is correct?
>
> consume(0, i-(delta/2));
>
> Eric
>
>
gr_rds_biphase_decoder.cc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] strange consume behaviours on blocks with mulitple input channels
There is no forecast method implemented, and the main cycle is structured so that it is impossible to consume more than offered from scheduler (see http://lists.gnu.org/archive/html/discuss-gnuradio/2006-12/msg00253.html for code posting). The first version of the code is working more or less like this: when not in sync mode (still looking for sync), the distance between subsequent zero crossings is continuously measured (therefore consuming signal samples), until a valid time interval is found - at that point another cycle is started that examines the clock input samples till a transition is found, and consumes all the samples before the transition one; at this point the new synced state is entered where the clock and the signal are synced, and they are consumed synchronously from now on. Debugging revealed that averagely it took hundredths of samples on the signal side to find correctly spaced zero crossings and only tenths of clock samples to find the first transition; upon these conditions clock samples were not consumed correctly: if the transition was at sample #43 and I issued consume(43), then next work call was not presenting sample #44 for clock as the first clock (http://lists.gnu.org/archive/html/discuss-gnuradio/2006-12/msg00253.html carries the code of the work method and the gnuplot files that show what happens before and after consume) Then I thought to change the quest for clock transition so that it was not starting from sample #1, but from one much closer in time to the sample of signal where it was recognized as valid; that is, if I had valid signal @ sample #873, I now search a clock transition NEAR sample #873, and therefore I consume more or less the same amount of samples from both channels. This seems to works fine and from debugging I ALWAYS get clock transition in sync with symbol start. regards Matteo > On Tue, Jan 02, 2007 at 07:59:00PM +0100, Matteo Campanella wrote: >> Hi everyone, on Dec 25th I posted a message about a possible strange >> behaviour of consume in a block where there are two inputs and samples >> are >> consumed at different rates; in order to further check the nature of the >> problem, I changed to code so that the clock input was checked for a >> transition in the latest period, rather than since the beginning; that >> way, >> consume for the clock input consumed almost the same number of samples >> as >> the signal input - I made similar graphs to the ones I posted on 25th, >> and >> this time everything seems to work ok, that is, samples consumed are the >> same number as requested with the consume() call. So this further test >> makes >> me believe that something bad happens if in the general work I consume >> 1000 >> samples of one input and just few, let's say 30, of another. Should it >> be >> like that? Or is there something wrong? >> >> regards, hny >> Matteo iz2eeq > > I believe that consume works as expected. > > You may want to confirm that you are not eating more input that is > actually valid. What are you using for your forecast method? Does it > compute a reasonable answer given your circumstances? > > Eric > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] strange consume behaviours on blocks with mulitple input channels
Hi everyone, on Dec 25th I posted a message about a possible strange behaviour of consume in a block where there are two inputs and samples are consumed at different rates; in order to further check the nature of the problem, I changed to code so that the clock input was checked for a transition in the latest period, rather than since the beginning; that way, consume for the clock input consumed almost the same number of samples as the signal input - I made similar graphs to the ones I posted on 25th, and this time everything seems to work ok, that is, samples consumed are the same number as requested with the consume() call. So this further test makes me believe that something bad happens if in the general work I consume 1000 samples of one input and just few, let's say 30, of another. Should it be like that? Or is there something wrong? regards, hny Matteo iz2eeq ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Discuss-gnuradio Digest, Vol 49, Issue 49
Search the list on the subject - I did a posting some time ago about using DRM decoder with USRP bymeans of tmpfs ram based named pipe for interface... have a happy new year all - Original Message - From: <[EMAIL PROTECTED]> To: Sent: Friday, December 29, 2006 18:09 Subject: Discuss-gnuradio Digest, Vol 49, Issue 49 Send Discuss-gnuradio mailing list submissions to discuss-gnuradio@gnu.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.gnu.org/mailman/listinfo/discuss-gnuradio or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of Discuss-gnuradio digest..." Today's Topics: 1. DReaM and gnuradio (Charles Swiger) -- Message: 1 Date: Thu, 28 Dec 2006 20:58:08 -0500 From: Charles Swiger <[EMAIL PROTECTED]> Subject: [Discuss-gnuradio] DReaM and gnuradio To: discuss-gnuradio@gnu.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain Hi Gang - Did somebody have the DRM decoder working with a gnuradio receiver? The main issue is feeding the sound from gnuradio into DReaM, somehow, other than using two soundcards. I have DReaM 1.6.25 compiled. http://sourceforge.net/projects/drm/ TIA --Chuck -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio End of Discuss-gnuradio Digest, Vol 49, Issue 49 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] strange consume behaviours on input channels
First of all merry xmas to everyone on the list!
I was checking the code for byphase decoding of rds, and I have noticed
that in the ST_LOOKING state the author waits for two valid zero
crossings in the signal, spaced enough to look like symbols, and then
uses the consume function to "rewind" to the beginning of the symbol.
He also tries to put the clock in phase with the signal, trying to
consume enough samples from the clock to align the beginning of the
symbol with the zero crossing of the clock.
I have added a couple debugging fstreams, and what I get is that the
consume on the data input works ok, while the consume on the clock does
not; any explanation for this behaviour?
I am attaching a couple data files, aftersync and beforesync; they are
gnuplot ready and show what happens before and after consume.
The code responsible for looking state is copied below.
best regards
Matteo iz2eeq
case ST_LOOKING:
// adjust clock and signal; if fine: go locked
if(d_sign_last == 0) { d_sign_last = (in[0] > 0 ? 1 : -1); }
for( i = 0; i < n_in; i++) {
filetwo << i << " " << in[i] << " " << clk[i] << '\n';
sign_current = (in[i] > 0 ? 1 : -1);
if(sign_current != d_sign_last) {
// Remember the zero crossing and check next
time if it was a half
or a whole symbol...
#ifdef BIPHASE_VERBOSE
printf("Zero Crossing at i = %d\n", i);
#endif
if(d_last_zc != 0) {
int delta = i - d_last_zc;
#ifdef BIPHASE_VERBOSE
printf("Delta of Zero Crossing
= %d\n", delta);
#endif
if((delta >= SYMBOL_LENGTH - 5)) {
//if(abs(delta-SYMBOL_LENGTH)<20) {
// That was a 1, 0 or 0, 1 in
signal; i is now pointing the middle
of a symbol
#ifdef BIPHASE_VERBOSE
printf("sync...
consume: %d\n", (i-(delta/2)) );
#endif
consume(0, i-(delta/2));
// From this point sync clk
d_sign_last = (clk[0] > 0 ? 1: -1);
for (i = 0; i < n_clk_in ; i++) {
sign_current = (clk[i] > 0 ? 1: -1);
if(sign_current != d_sign_last) {
// zero crossing in clock
consume(1,i);
#ifdef BIPHASE_VERBOSE
printf("clock sync... consume:
%d\n",i);
#endif
break;
}
d_sign_last = sign_current;
}
enter_locked();
filetwo.close();
return 0; // No output produced, but now clock and
signal are synced
}
}
d_last_zc = i;
}
d_sign_last = sign_current;
}
d_last_zc = d_last_zc - n_in;
cons = (n_in > n_clk_in ? n_clk_in : n_in );
#ifdef BIPHASE_VERBOSE
printf("clock and data consume: %d\n",cons);
#endif
consume(0, cons);
consume(1, cons);
return 0;
aftersync.gz
Description: GNU Zip compressed data
beforesync.gz
Description: GNU Zip compressed data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] problem with just checked out and recompiled gnuradio
Hello folks, I've just wiped out and recompiled the whole GNURADIO on my FC5 64, and unfortunately now no application runs anymore... even the simplest dial_tone.py produces this output: [EMAIL PROTECTED] audio]$ ./dial_tone.py Traceback (most recent call last): File "./dial_tone.py", line 23, in ? from gnuradio import gr File "/usr/local/gnuradio/lib/python2.4/site-packages/gnuradio/gr/__init__.py", line 39, in ? from prefs import prefs File "/usr/local/gnuradio/lib/python2.4/site-packages/gnuradio/gr/prefs.py", line 115, in ? _prefs_db = _prefs() File "/usr/local/gnuradio/lib/python2.4/site-packages/gnuradio/gr/prefs.py", line 56, in __init__ _prefs_base.__init__(self) File "/usr/local/gnuradio/lib/python2.4/site-packages/gnuradio/gr/gnuradio_swig_python.py", line 7669, in __init__ return _gnuradio_swig_python.gr_kludge_copy_sptr_basic_block(*args) AttributeError: 'PySwigObject' object has no attribute 'this' swig/python detected a memory leak of type 'gr_prefs *', no destructor found. Does anyone have any clue at this? i have swig 1.3.31 and gcc 4.1.1 thanks in advance best regards Matteo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] RDS fun and hello from a new user
Hello Eric, I am basically doing the same you did on the RDS code and specification; right now I have introduced syndrome based sync and indeed it looks like it get synced much faster. I am using the wfm receiver (non pll), but, not having implemented the loss of sync yet, I cannot tell how fst sync comes and goes :) The ideal thing would be to build up a wxwidget from python able to show the rds data in a fancy way, in order to complete the FM receiver with RDS info on GUI - given the time left over from work I think it'll take ages, and right now priority one is to work Laccadive Islands DXpedition :) 73 matteo iz2eeq ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Fft scope frequent hangs
Hello every1, I haven't been playing with the fft scope for a while until yesterday, when I realized that it frequently hangs on my fc5 with two weeks ago trunk gnuradio... The scope freezes (in all modes) and it needs to be killed to get the control back. No underruns or any messgae that could give a further investigation advice. Has anyone experienced the same? Is there any suggestion that could help diagnose the problem? Btw, decimation and all the other parms where the default ones, I just retouched the dbs board gain. Regards Matteo iz2eeq ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Best way to demodulate ppm
hello, i would like to get list advice about the best way to demodulate pulse position modulation; i was thinking about envelope detection as in am, followed by a custom block to do packet start recognition and bits decision, but i am not sure it is the best approach... The ppm would be at 1mbps rate. Thanks Matteo iz2eeq ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ADS-B decoding
So I decided, after Eric posting to spend part of the Sunday taking care of ADS-B, and started doing some thinkering and frequency monitoring. >From the links read I thought I should expect bursts of radiofrequency at 1090MHz whose duration is 0.5 microseconds, differently spaced depending on whether I am getting the preamble or the bits. I have tried to monitor 1090MHz using DSB rx, but I could not see any carrier at all - my discone antenna is not really suited for 1090MHz, so I guess that either I do not have signals in my zone (quite strange, as I am close to 2 international airports), or my antenna does not do the job. Is there anyone on the list interested in the subject that could provide a recording of some ADS-B bursts? regards Matteo iz2eeq ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] All new packetradio 1200 and 9600 G3RUH with Muller and Mueller block
Hello, that sounds really strange. In order to be sure everything is at the right place, I downloaded the tgz myself and recompiled, and everything is ok. I did: make clean ./bootstrap ./configure --prefix=/usr/local/gr --enable-maintainer-mode make make install the file packetradio.i is there, in gr-packetradio/src/lib, as you can see yourself. let me know if you get any progress on this. best regards Matteo iz2eeq ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] All new packetradio 1200 and 9600 G3RUH with Muller and Mueller block
I've finally reviewed all the material and converted the old code to make it more user friendly as well as to make use of the great blocks GNURADIO offers. I am talking about the Mueller and Muller clock recovery and sampler. Now both 1200 and 9600 python code works, both for transmit and receive. I have isolated the framer functionality in a block, gr_framer, that takes care of HDLC and G3RUH LFSR scrambling/descrambling. This block uses the message queue model to return the packets back to the python code. Full option parser support has been added to the python code, so that usrp parameters and message to transmit can be passed to the programs via command line. A description od the python programs follows. For those interested, they can be downloaded at http://digilander.iol.it/iz2eeq/gnuradio.html. Feedbacks and evolutions are welcome. Matteo, iz2eeq 1200rx.py usage: 1200rx.py [options] options: -h, --help show this help message and exit -R RX_SUBDEV_SPEC, --rx-subdev-spec=RX_SUBDEV_SPEC select USRP Rx side A or B (default=A) -f FREQ, --freq=FREQ set frequency to FREQ -g GAIN, --gain=GAIN set gain in dB (default is midpoint) -d, --do-logging enable logging on datafiles -s, --use-datafile use usrp.dat (256kbps) as input This program receives packets and show them on terminal in this form: X CRC C75F C75F = Sat Nov 4 11:21:50 2006 fm IZ2EEQ-7 to SXQT16-0 via RELAY-0,WIDE7-7 UIv pid=F0 '+4il .K\> = XXX CRC 34EC 34EC = Sat Nov 4 11:27:42 2006 fm IK1ZNW-6 to I2ODL-6 via IK2NHL-4 I45^ pid=F0 PC19^0^IK5PWJ-6^0^5452^1^IZ5FSA-6^0^5452^0^IK2XDE-6^0^5432^0^IK5ZUK-6^0^5452^1^I5UXJ-2^0^5451^1^IR1BI-6^0^5451^1^IR8AW-6^0^5452^H2^ = he Xs are returned by the framer and indicate a candidate packet whose CRC check failed. When CRC check for a packet is ok, the framer prints the CRC value to standard output and returns the packet to python, whose function printpacket prints it in a readable format. 1200tx.py usage: 1200tx.py [options] options: -h, --help show this help message and exit -f FREQ, --freq=FREQ set frequency to FREQ -m MESSAGE, --message=MESSAGE message to send -c CALL, --mycall=CALL source callsign -t CALL, --tocall=CALL recipient callsign -v CALL, --via=CALL digipeater callsign -d, --do-logging enable logging on datafiles -s, --use-datafile use usrp.dat (256kbps) as output This program transmit a message from a source callsign to a dest callsign via a digipeater. It is made to work with a basic TX board (the only tx board I have), therefore it uses the repetition of spectrum of a sampled signal to go to VHF. I guess the code can be easily adapted for more serious transmit boards. 9600rx.py usage: 1200rx.py [options] options: -h, --help show this help message and exit -R RX_SUBDEV_SPEC, --rx-subdev-spec=RX_SUBDEV_SPEC select USRP Rx side A or B (default=A) -f FREQ, --freq=FREQ set frequency to FREQ -g GAIN, --gain=GAIN set gain in dB (default is midpoint) -d, --do-logging enable logging on datafiles -s, --use-datafile use usrp.dat (256kbps) as input This program receives packets and show them on terminal in this form: X CRC C75F C75F = Sat Nov 4 11:21:50 2006 fm IZ2EEQ-7 to SXQT16-0 via RELAY-0,WIDE7-7 UIv pid=F0 '+4il .K\> = XXX CRC 34EC 34EC = Sat Nov 4 11:27:42 2006 fm IK1ZNW-6 to I2ODL-6 via IK2NHL-4 I45^ pid=F0 PC19^0^IK5PWJ-6^0^5452^1^IZ5FSA-6^0^5452^0^IK2XDE-6^0^5432^0^IK5ZUK-6^0^5452^1^I5UXJ-2^0^5451^1^IR1BI-6^0^5451^1^IR8AW-6^0^5452^H2^ = he Xs are returned by the framer and indicate a candidate packet whose CRC check failed. When CRC check for a packet is ok, the framer prints the CRC value to standard output and returns the packet to python, whose function printpacket prints it in a readable format. 9600tx.py usage: 9600tx.py [options] options: -h, --help show this help message and exit -f FREQ, --freq=FREQ set frequency to FREQ -m MESSAGE, --message=MESSAGE message to send -c CALL, --mycall=CALL source callsign -t CALL, --tocall=CALL recipient callsign -v CALL, --via=CALL digipeater callsign -d, --do-logging enable logging on datafiles -s, --use-datafile use usrp.dat (256kbps) as output This program transmit a message from a source callsign to a dest callsign via a digipeater. It is made to work with a basic TX board (the only tx board I have), therefore it uses the repetition of spectrum of a sampled signal to go to VHF. I guess the code can be easily adapted for more serious transmit boards. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] DC offset filtering in gmsk
Hello, I have noticed that the DC offset removal IIR filter that was in the old gmsk2.py is not there anymore in the new gmsk.py - is there any particular reason for that? Or is it simply that it has been moved somewhere else along the modules chain? regards Matteo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Amateur Packet Radio with USRP
Hello everyone, I have just put together a working version of some python scripts and a GNURadio block to receive and trasmit Amateur Packet Radio packets. Only 1200 baud AFSK version is working right now, while the 9600 G3RUH is very work in progress (just started). The software can be found at http://digilander.iol.it/iz2eeq/gnuradio.html, together with a short explanation of how the whole thing works. regards Matteo iz2eeq ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OT - FC5 x64 on 2nd SATA
Hello and sorry for the off topic but maybe someone had the same problem. I just bought a disk to have gnuradio on fc5 on its own disk and put it on the second channel of my mb via sata controller... Surprise, the good 'ol anaconda from fc5 x64 dvd does not list second sata drive in the available drives for installation, but the kernel does see it, infact I am able to go to a shell and do fdisk on /dev/sdb - it's simply not shown by anaconda... Any clue at it ? Many thanks in advance! Matteo iz2eeq ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OK FC5
Hello folks, I've just added to http://gnuradio.org/trac/wiki/FC5Install what I do usually type in FC5 before happily building gnuradio from svn. Hope I got it right. cheers Matteo iz2eeq ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fedora Core 5 gnuradio vmware image
Hi Greg, svn, and grnuradio sources are already onboard, what is missing is geda and usrp schematics, which I can easily add sorry but I do not know what exactly fx2 microcontroller tools are...maybe I am still sleepy :-) (spent last night installing new Athlon64 MB after my XP died on friday ;( ) regards Matteo - Original Message - From: "Clark Pope" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; Sent: Friday, September 08, 2006 17:55 Subject: RE: [Discuss-gnuradio] Fedora Core 5 gnuradio vmware image This is a great idea as it took me about a week to install gnuradio and usrp my first try. If you can make an image that has ALL the gnuradio tools would be even better, e.g. at least: *fpga compile (is there a linux altera solution yet) *svn for pulling the latest code *gnuradio base and code compile *the gEDA software and usrp schematics, layout files *fx2 microcontroller tools As for distributing, if you can keep it to one dvd maybe Matt would agree to sell on his web site for a nominal charge, say $15. I think it's just a matter of time before vmware supports usb2.0. Once we have that, it's like you say one click to a working gnuradio and folks can spend more time developing and less time configuring. Thanks, Clark From: "Matteo Campanella" <[EMAIL PROTECTED]> To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] Fedora Core 5 gnuradio vmware image Date: Fri, 8 Sep 2006 15:06:13 +0200 (CEST) Hi everyone, I have built a brand new vmware image with updated fedora core 5 and latest gnuradio from trac - obviously the usrp won't work because of usb2 not supported on vmware, but it's a nice to have for on the run gnuradioing. Only problem is the image takes 5 GB so it's kinda akward to be exchanged via net...should there be anyone interested in getting it, we could find a way. cheers Matteo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio _ All-in-one security and maintenance for your PC. Get a free 90-day trial! http://www.windowsonecare.com/trial.aspx?sc_cid=msn_hotmail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Fedora Core 5 gnuradio vmware image
Hi everyone, I have built a brand new vmware image with updated fedora core 5 and latest gnuradio from trac - obviously the usrp won't work because of usb2 not supported on vmware, but it's a nice to have for on the run gnuradioing. Only problem is the image takes 5 GB so it's kinda akward to be exchanged via net...should there be anyone interested in getting it, we could find a way. cheers Matteo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] mode S ADS-B reception
Hi - I have not done anything along that path yet - in June, at the hamvention in Fredrichshafen I got the chance to see the SBS-1 device live... it does what we would like to do with the usrp - http://www.kinetic-avionics.co.uk/ and it was showing alot of traces by only means of the vertical shown in the picture. I am still interested in the subject but I haven't found any decent documentation about the protocol by googling a bit around... ciao matteo Eric Blossom wrote: On Thu, Sep 07, 2006 at 10:19:51PM +1000, Hugh Blemings wrote: Hiya, A long long time ago - Thu, 13 Apr 2006 11:46:29 +0200 (CEST) "Matteo Campanella" <[EMAIL PROTECTED]> wrote: Hello, has anyone tried reception of mode S ADS-B with the usrp/gnuradio? This has recently piqued my interest too but didn't see any response to Matteo's query. Has anyone looked into this ? If not, Matteo, I guess it's up to us :) Kind Regards, Hugh VK1YYZ/AD5RV Hi Hugh, I don't know of anyone who's done it. Dive in ;) Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_tv_rcv issues
Hello folks, here there is an interesting piece about the nice usrp_tx_rcv and the status of the art as of now. I am sending it to the list with the consensus of Martin. regards Matteo - Original Message - From: "Martin Dvh" <[EMAIL PROTECTED]> To: "matteo" <[EMAIL PROTECTED]> Sent: Monday, June 19, 2006 9:25 PM Subject: Re: [Discuss-gnuradio] usrp_tv_rcv issues matteo wrote: Hello Martin, I have just tested the tv receiver and what happens is that I can see the tv stations, only i see the picture repeated twice vertically (one picture over the other) and slowly shifting to the left. The arrangement of the pictures is so that the first picture is not complete, then there is a complete picture and in the end there is the piece that is missing from the first picture. Do you have any idea what is causing this? Yes, It is unfinished code. You see two pictures because analog Tv consists of two interlaced fields and I haven't written (or stolen) a de-interlacer yet. The picture is slowly shifting left -to right or right to left and also even more slowly down or up. This is because the synchronisation is not there (vsync and hsync) This is also the reason the picture is not nicely alighed with the screen (you mis a bit on the top which is shown at the bottom) I have been working on sync for some time now but I still haven't got it right so I did't check it in. (It really is not usable at the moment) I am very busy right now but I plan on working on it some more after my holiday (in juli) I would also like to understand your beautiful code, so any additional documentation you should have would be very nice to read. I didn't use much documentation because I Just happen to know about how TV-signals are build up. For the details I used google a lot. This site was very helpfull: http://www.pembers.freeserve.co.uk/World-TV-Standards/ Once I have the synchronisation working I might document my own code some more because I suspect interest on working on it will increase. But feel free to ask questions about specific parts of the code. A raw outline of the code is. Build an am-receiver flowgraph with several MHz bandwidth usrp ->channel filter -> amdetector (complex-to-mag) build a videosink which shows the demodulated video as gray-scale image on screen. (first sample coming in goes top-left, last sample of a frame goes bottom-right, then start-over) video-signal -> image-buffer ->screen (using SDL) I used a few timing tricks to keep the flowgraph running even if the videosink is too slow or too fast. for PAL TV the sink should output 25 frames (=two fields) per second. If The sink is too slow I skip whole frames. I don't remember exactly what the code does when the sink is too fast but I think It just waits for new samples. With a little work the video-sink should also be usable for digital TV once the digital-TV demodulation works. (Even HDTV should work) A needed add-on is also color-decoding, color-video-sink and audio-decoding. Audio-decoding should be straight-forward because it is just a variation on FM-radio (for PAL-TV) The problem is that you need the full 6Mhz bandwidth to get the color and audio sub-carriers and for most PC-s this is too much for realtime decoding. A quick-and-dirty solution could be to use a second channel in the usrp tuned to the audio-carrier with smaller bandwidth. (For color this will not work because you need exact phase-relationships.) I hope this helps, You might want to forward this to the mailing-list because other people might be interested too. Greetings, Martin best regards Matteo Campanella iz2eeq ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] sourceforge (usrp) cvs problems anyone?
hello, is anyone experiencing problems in checking out opensdr from sourceforge ? I am getting a "no route to host" since yesterday cheers Matteo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] usb rights on FC5 and udev
Hello, maybe this is not new, but I have found how to avoid the sudo on
Fedora Core 5 and run usrp python code as a normal user - the file that
needs to be modified is /etc/udev/rules.d/50-udev.rules, line 308 in my
fedora core 5 dist:
#
# Persistent block device stuff - end
#
ACTION=="add", SUBSYSTEM=="usb_device", \
PROGRAM="/bin/sh -c 'K=%k; K=$${K#usbdev}; printf
bus/usb/%%03i/%%03i $${K.*} $${K#*.}'", \
NAME="%c", MODE="0644"
ACTION=="add", SUBSYSTEM=="?*", ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe
$env{MODALIAS}"
ACTION=="add", SUBSYSTEM=="pcmcia", ENV{MODALIAS}=="*", \
RUN+="/bin/sh -c 'echo 1 > /sys/$DEVPATH/allow_func_id_match'"
Simply, change the MODE="0644" to 0666 or 0664 (if you want to use groups)
and, upon creation the udev subsystem will use these rigths to create
/dev/bus/usb/xxx/xx.
cheers
Matteo
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Gsm detection examples
hello list, Is there any example available for doing gsm cellphone detection, or even cell detection? I am thinking of the uk malls people flow monitoring presented in the article on wired, even though my need would be more in the rescue activity on the field. Regards Matteo iz2eeq ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Oregon Scientific Remote Sensors
Hello, has anyone any informations about the remote weather sensors from oregon scientific? I have one that I would like to receive with my computer and USRP - the one I have has five channels to choose from (I do not know if they are logical channels or physical different frequencies) and it transmits temperature, exact time as received from DCF77 and humidity. I have done some googling but have been not successful in finding protocol information. regards Matteo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Wired News Article on USRP and GNU Radio
Great article, Matt, congratulations - that would spread the software radio work even more. As much as it regards the freedom on bands, well it's a dream in my opinion, cause, as every freedom, it would be very easy to turn it into the adavantage of few individuals with a loose ethical sense. I mean that freedom is based on each other's respect, and this is something that even the most civilized society cannot still count on. Just as an example I can think about the ham radio bands, whithin which there is enough freedom, with only a few gentlemen agreements to respect. Well, you prefectly know how many individuals cannot cope even with these simple not written rules, and we're talking about a hobby - think about something that is business related and a greater form of freedom will soon turn into an advantage for those that circumvent rules as a lifestlyle. Neverthless I am a dreamer, and I hope that sooner or later we will arrive to that better sense of civil respect, where we will effectively need few regulations, because we will be able to auto regulate on the base of the good common sense, always keeping an eye on the fact that our freedom ends where the one of our neighbour begins. ciao Matteo - Original Message - From: "Matt Ettus" <[EMAIL PROTECTED]> To: Sent: Monday, June 05, 2006 6:49 PM Subject: [Discuss-gnuradio] Wired News Article on USRP and GNU Radio http://www.wired.com/news/technology/0,70933-0.html?tw=wn_index_1 ___ 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] HAM RADIO Friedrichshafen anyone?
Hi Alexander, I will be there with family and fellow hams! See ya! ciao Matteo iz2eeq > Hello, > > I wonder if anyone is coming to Friedrichshafen (Germany) for Ham Radio > 2006, June 23-25? > > http://www.hamradio-friedrichshafen.de/html/en/index.php > > Alex > > > ___ > 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] Trouble getting USRP up and running
Maybe a permissions problem? Have you tried with sudo, or simply eunning examples as root? mc -Original Message- From: "Richard Bitter"<[EMAIL PROTECTED]> Sent: 18/05/06 19.14.14 To: "discuss-gnuradio@gnu.org" Subject: [Discuss-gnuradio] Trouble getting USRP up and running I'm having problems getting the USRP up and running with GNU Radio. System: Fedora Core 5 GNURadio 2.8 everything builds and passes make check. some of the test apps in the usrp-0.12/host/apps directory work such as: usrper load_standard_bits usrper led1 on/off so i know i'm able to talk to the USRP, but the following apps dont: test_usrp_standard_rx test_usrp_standard_tx both fail with an error message of not being able to claim the USB interface. i also get this error when attempting to run any of the usrp examples in the examples tar ball. any help would be appreciated, rick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] WinDRM
Brett, here there is how I made it work on my install:
1) create a tmpfs on linux by adding this mount point to /etc/fstab:
ramfs /mnt/ramfs tmpfs defaults 0 0
2) mount the new ram file system "mount ramfs"
3) create a pipe with the command "mkfifo /mnt/ramfs/drm.raw"
4) attach the standard drm to the pipe: "drm --fileio /mnt/ramfs/drm.raw"
5) start drm.py with the correct frequency (see drm.py -help)
here follows the drm.py code:
#!/usr/bin/env python
from gnuradio import gr
from gnuradio import usrp
from math import pi
from gnuradio import eng_notation
from gnuradio.eng_option import eng_option
from gnuradio.wxgui import stdgui, scopesink, fftsink
from optparse import OptionParser
import wx
class app_flow_graph (stdgui.gui_flow_graph):
def __init__(self, frame, panel, vbox, argv):
stdgui.gui_flow_graph.__init__ (self, frame, panel, vbox, argv)
parser = OptionParser(option_class=eng_option)
parser.add_option("-f", "--freq", type="eng_float", default=5990e3,
help="set frequency to FREQ", metavar="FREQ")
parser.add_option("-g", "--gain", type="int", default=10,
help="set gain in dB (default is midpoint)")
(options, args) = parser.parse_args()
if len(args) != 0:
parser.print_help()
sys.exit(1)
adc_rate = 64e6
usrp_decim = 148
if_rate = adc_rate / usrp_decim
if_decim = 9
demod_rate = if_rate / if_decim#48048.048
src = usrp.source_c (0, usrp_decim)
src.set_rx_freq (0, -options.freq+7e3)
actual_freq = src.rx_freq(0)
src.set_pga(0,options.gain)
print "FREQ: ",actual_freq
print "Gain: ",options.gain
channel_coeffs = \
gr.firdes.low_pass (if_decim, # gain
if_rate,# sampling rate
14e3, # low pass cutoff freq
3e3,# width of trans. band
gr.firdes.WIN_HANN)
dec = gr.fir_filter_ccf(if_decim,channel_coeffs)
vc = gr.multiply_const_cc(10)
print "len(channel_coeffs) =", len(channel_coeffs)
fft, win = fftsink.make_fft_sink_c (self, panel, "Spectrum", 512,
demod_rate)
vbox.Add (win, 1, wx.EXPAND)
c2r = gr.complex_to_real()
r2s = gr.float_to_short()
out = gr.file_sink(gr.sizeof_short,"/mnt/ramfs/drm.raw")
# now wire it all together
self.connect (src, dec)
self.connect (dec, vc)
self.connect (dec,fft)
self.connect (vc,c2r,r2s,out)
def main():
app = stdgui.stdapp (app_flow_graph, "Spectrum Analyzer")
app.MainLoop ()
if __name__ == '__main__':
main()
> Apparently, a forked version of DRM using lower bandwidth codecs has
> been developed- originally called Hamdream by HB9TLK and was GUI-fied by
> N1SU and called WinDream. This particular version uses different codecs
> and supports two-way mode.
>
> It seems like this version would be more directly aimed at USRP/GNURadio
> users, though support for 'official' DRM would be obviously beneficial
> as well!
>
>
>
> ___
> 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: Amateur television ATV
Unfortunately, all the repeaters around here have a 1240MHz input and 10.470GHz output, so dbrx on its own won't help (unless I will be lucky enough to be in the uplink beam of a ham while transmitting :-) ). I am already working on a receiving system based on an offset dish and modified satellite tv lna feeding an analog receiver. As soon as I will get some result from the analog system, I will try to feed the usrp with the signal, provided that my hd will be fast enough... thanks Matteo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] measure of the SNR in a packet
The first method looks interesting, the only problem I find with it is that I cannot tell wether what I am getting from the channel is noise or noise plus some weak signal I cannot identify as such. When it comes to very busy channels (eg on APRS frequency, you have signals almost all of the time...) Matteo - Original Message - From: "Greg Troxel" <[EMAIL PROTECTED]> To: "Matteo Campanella" <[EMAIL PROTECTED]> Cc: Sent: Wednesday, April 26, 2006 2:47 PM Subject: Re: [Discuss-gnuradio] measure of the SNR in a packet Hello, I would like to write some code to calculate the SNR of a signal; in my case this signal is a packet radio AX25 1200 baud packet burst received thru TV RX and usrp. First you need to define SNR. If you measure the noise power of the background within the passband when there is no signal, and then measure the power of the signal+noise while receiving, you can calculate an estimate. Or, you can do coherent demod of the signal, and then regenerate a perfect signal at an amplitude that best matches the received data. Then you can subtract that and look at the residuals, and calculate power of the reconstructed signal and the residuals. The residuals will have not only noise and receiver distortion, but also components due to amplitude variations over the estimation period. This is probably much easier if you don't try to get accurate values at low SNR. But it's down low that it's a more interesting problem, at least to me. -- Greg Troxel <[EMAIL PROTECTED]> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] measure of the SNR in a packet
Hello, I would like to write some code to calculate the SNR of a signal; in my case this signal is a packet radio AX25 1200 baud packet burst received thru TV RX and usrp. Is there anything ready for use or has anyone good suggestions to implement this? thanks Matteo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Amateur television ATV
hello, In the case of atv, as I believe the passband of the signal is way too large for the throughput of usrp usb, are there any special techniques/tricks to achieve some sort of result? Regards Matteo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP+Digital Radio Mundial
The DRM is still sitting on sourceforge @ http://drm.sourceforge.net/
It builds nicely on FC4, provided that the instructions on
http://drm.sourceforge.net/installation.html are followed.
In order to make it work with usrp it is sufficient to write some python
code with a gr_file_sink of shorts @ 48000 samples per second, feed it
to a linux pipe on a tempfs and start the drm code with the -fileio
option to the same pipe.
regards
MC
#!/usr/bin/env python
from gnuradio import gr
from gnuradio import usrp
from math import pi
from gnuradio import eng_notation
from gnuradio.eng_option import eng_option
from gnuradio.wxgui import stdgui, scopesink, fftsink
from optparse import OptionParser
import wx
class app_flow_graph (stdgui.gui_flow_graph):
def __init__(self, frame, panel, vbox, argv):
stdgui.gui_flow_graph.__init__ (self, frame, panel, vbox, argv)
parser = OptionParser(option_class=eng_option)
parser.add_option("-f", "--freq", type="eng_float",
default=5990e3,
help="set frequency to FREQ", metavar="FREQ")
parser.add_option("-g", "--gain", type="int", default=10,
help="set gain in dB (default is midpoint)")
(options, args) = parser.parse_args()
if len(args) != 0:
parser.print_help()
sys.exit(1)
adc_rate = 64e6
usrp_decim = 148
if_rate = adc_rate / usrp_decim
if_decim = 9
demod_rate = if_rate / if_decim#48048.048
src = usrp.source_c (0, usrp_decim)
src.set_rx_freq (0, -options.freq+7e3)
actual_freq = src.rx_freq(0)
src.set_pga(0,options.gain)
print "FREQ: ",actual_freq
print "Gain: ",options.gain
channel_coeffs = \
gr.firdes.low_pass (if_decim, # gain
if_rate,# sampling rate
14e3, # low pass cutoff
freq
3e3,# width of trans.
band
gr.firdes.WIN_HANN)
dec = gr.fir_filter_ccf(if_decim,channel_coeffs)
vc = gr.multiply_const_cc(10)
print "len(channel_coeffs) =", len(channel_coeffs)
fft, win = fftsink.make_fft_sink_c (self, panel, "Spectrum",
512, demod_rate)
vbox.Add (win, 1, wx.EXPAND)
c2r = gr.complex_to_real()
r2s = gr.float_to_short()
out = gr.file_sink(gr.sizeof_short,"/mnt/ramfs/drm.raw")
# now wire it all together
self.connect (src, dec)
self.connect (dec, vc)
self.connect (dec,fft)
self.connect (vc,c2r,r2s,out)
def main():
app = stdgui.stdapp (app_flow_graph, "Spectrum Analyzer")
app.MainLoop ()
if __name__ == '__main__':
main()
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Consume_each
Hello, i have noticed the use of consume_each(n) in some of the block sources; for example in the simple correlator it is called once with n and once with n plus one - what is exactly its function and is it the only consume function? What is the meaning of the parameter? Thanks Mc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Maximum TX frequency limit
Hello, I found out that the max tx freq is limited in usrp_standard.cc to 44MHz (since USE_FPGA_TX_CORDIC is undef'd). Now, since a 128MSps should safely ensure 64MHz, what is actually imposing that limitation? I was trying to go to 6mtrs ham band... MC ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] mode S ADS-B reception
Hello, has anyone tried reception of mode S ADS-B with the usrp/gnuradio? MC ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] interfacing gnuradio as samples source to 3rd parties applications
hello, I found a simple way to interface sound applications with USRP and gnuradio; maybe it is already widely used, but I guess it is worth mentioning it - this method work provided that the application is able to get samples from file, my experience has been done with drm, that called with the option --fileio is able to get 16 bit integers from a file. I created a tmpfs on my linux by adding this mount point to /etc/fstab: ramfs /mnt/ramfs tmpfs defaults 0 0 and then i issued the command "mount ramfs" then I created a pipe with the command "mkfifo /mnt/ramfs/drm.raw" The game is almost done - start drm with "drm --fileio /mnt/ramfs/drm.raw" and start your python code providing a file sink with the same name as the pipe you created, in my case: ...omissis... out = gr.file_sink(gr.sizeof_short,"/mnt/ramfs/drm.raw") ...omissis... Maybe it's not going to work nicely for high sample rates, but it works lovely for this case as well as for gmfsk started in "demo" mode with the command: cat | gmfsk --testmode MC ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: FM demodulation of a real signal
hello, thanks to your suggestions I have been able to obtain a quite working demodulation, what I am actually trying to demodulate is AFSK 1200baud ax25 packet; the steps I am doing are 1) channeling from USRP stream - complex stream 2) fm demodulation - real stream at this point I have an audio signal with 1200 and 2200 tones 3) mix the signal with a complex sine @ 1700hertz this is an half complex mixer and it shifts my real spectrum 1700 hertx down the frequency axis, with the result I have now: a) one spectral line @ 500 (former 2200 tone) b) one spectral line @ -500 (former 1200 tone) c) one spectral line @ -2900 d) one spectral line @ -3900 4) 500Hz lowpass the complex signal to discard the negative unwanted frequencies 5) fm demodulation to restore the -1,1 symbol stream actually I am getting some ringing, but I guess it depends on the paramters of the lowpass filter that are not correctly choosen. Is there any better way to demodulate this? Do you think that the result would be better with the use of matched filters for mark and space frequencies? Would it get better if I use a particular shaping of the lowpass filter previous to final fm demod? thanks Matteo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FM demodulation of a real signal
I have tried building the analytic by hilbert, but I think that, because of the many near DC components of the signal, I do not get a nice quadrature demod output...I will try with a pll, thanks for the suggestion! MC > Matteo Campanella wrote: >> Hello, I am quite stuck at a problem, that is, how to demodulate a FM >> signal that is NOT in complex form using existing gnuradio blocks. The >> quadrature demodulator works only with complex input; I have tried to >> build an analytic signal out of my real one, but the result of the >> demodulation is then quite poor. > How did you try to "build an analytic signal out of my real one". > The easiest way of doing that is to use gr.hilbert_fc (numberoftaps) > The numberoftaps in combination with the samplerate determines the lowest > frequency for which the hilbert transform is accurate. > (The higher the number, the more accurate the transform) > Try and experiment with the numberoftaps value. > Most of the time a value like 256 will do. > > You can also try to use the usrp_wfm_pll.py example. > This one uses a pll to recover the frequency modulation which should > perform much better with a real source. > > The pll it uses is gr.pll_freqdet_cf > You could build a gr.gr_pll_freqdet_ff block to go straight from real data > to frequency detection. > > (You can look in the old code atsc/GrAtscFPLL.cc > This is the PLL which was used for atsc demodulation. It works with real > input data.) > Greetings, > Martin >> >> Any suggestions? >> Matteo >> >> >> >> ___ >> 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] FM demodulation of a real signal
Hello, I am quite stuck at a problem, that is, how to demodulate a FM signal that is NOT in complex form using existing gnuradio blocks. The quadrature demodulator works only with complex input; I have tried to build an analytic signal out of my real one, but the result of the demodulation is then quite poor. Any suggestions? Matteo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] usrp tx dac rate
Hello, Is there any python mapped function that allows to change the tx dac rate? Sometimes, when you start with a fixed baud rate, being the interpolation chain all made up by integer numbers, one does not end up with 128e6... it could be a good occasion to use a rational resampler, but when a slight change on dac rate could make the ends meet, maybe it'd be worth the additional computational complexity. Matteo iz2eeq ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] AFSK 1200 ax25 - first quasi light
Hello everyone, I have just finished drafting a working version of AX25
packet generator and AFSK modulator (baseband for the time being). The
ax25 related code is contained in the ax25.py file, that is far from being
nicely written.
I have tested the resulting audiofile with mixw on windoze and it decodes
ok; tests on the air with the usrp will be prabably run in the we.
Best documentation with code examples I have ever found on 1200 AFSK is here:
http://www.tnc-x.com/dcc.doc
http://www.tnc-x.com/dcc2.doc
thanks to W2FS and TAPR/ARRL
Matteo iz2eeq#!/usr/bin/env python
mark=-1 #2200
space=1 #1200
symbol=space
out=[]
packet=[]
flag=0
fcs=0
stuff=0
fcslo=0
fcshi=0
def sendzero():
global symbol,mark,space,out
if symbol==space:
sym=mark
else:
sym=space
out.append(sym)
symbol=sym
def sendone():
global symbol,out
out.append(symbol)
def fcsbit(bit):
global fcshi,fcslo
b1=fcshi&0x01
fcshi>>=1
b2=fcslo&0x01
fcslo>>=1
fcslo|=(b1<<7)
if b2 != bit:
fcshi=fcshi^0x84
fcslo=fcslo^0x08
def sendbyte(byte):
global flag,fcs,stuff
for k in range(8):
bt=byte & 0x01
if not fcs and not flag: fcsbit(bt)
if bt==0:
stuff=0
sendzero()
else :
stuff+=1
sendone()
if not flag and stuff==5:
stuff=0
sendzero()
byte>>=1
def dumppacket():
global packet
print "length: %d\n" % len(packet)
for byte in packet:
print "%02x %c" % (byte,byte)
def
buildpacket(source,source_ssid,dest,dest_ssid,digi,digi_ssid,control,pid,payload):
global packet
packet=[]
for j in range(6):
if j#!/usr/bin/env python
from gnuradio import gr
from gnuradio import audio_oss
from gnuradio import afsk
from math import pi
from gnuradio.wxgui import stdgui, scopesink
import wx
from ax25 import *
import struct
def main():
sf=48000
mark=1200
space=2200
dev=abs(mark-space)/2
cf=min(mark,space)+dev
bitrate=1200
sens=2*pi*dev/sf
interp=sf/bitrate
message=":ALL :this is a wide test";
buildpacket("IZ2EEQ",1,"CQ",0,"RELAY",0,0x03,0xf0,message)
v=sendpacket()
fg = gr.flow_graph ()
src = gr.vector_source_f(v)
sqv = (1,) * interp
fil = gr.interp_fir_filter_fff(interp, sqv)
mod = gr.frequency_modulator_fc(sens)
lo = gr.sig_source_c(sf, gr.GR_SIN_WAVE, cf, 1)
mix = gr.multiply_cc()
c2r = gr.complex_to_real()
dst0 = gr.file_sink(gr.sizeof_gr_complex,"test.raw")
dst1 = gr.vector_sink_f()
dst2 = audio_oss.sink(sf)
fg.connect(lo,(mix,0))
fg.connect(src,fil,mod,(mix,1))
fg.connect(mix,c2r,dst2)
fg.start()
fg.wait()
#print dst1.data()
if __name__ == '__main__':
try:
main()
except KeyboardInterrupt:
pass___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bell 202 modulation
yep, my fault to use the wrong name for it :-) I am indeed working on the bits to symbol (nrzi) block right now, and later on I am willing to do the HDLC block with flag, FCS and bit stuffing in order to put up the following chain: message_source->hdlc->nrzi->modulation->duc right now i am stuck at modulation, that is, to find a method to use the frequency modulator to do that at baseband, as suggested from Eric... 73, Matteo iz2eeq > Having been an innocent bystander here, I think I see a classic case of > people talking past each other. > > Matteo, the 1200 baud modulation used in AX.25 packet radio uses BEL 202 > tones, *but* the signal that's being provided to the modulator has been > through an HDLC chip (or equivalent) that converts the data stream into > a synchronous format that includes flags, FCS, etc., *and* uses NRZI > (non-return-to-zero, inverted) modulation. That HDLC activity isn't > part of the BEL 202 protocol. > > What you're trying to implement isn't BEL 202, but 1200 baud AX.25, and > those aren't the same things. > > Bob's answers were based on the assumption you were trying to produce a > BEL 202 data stream as it would appear on a telephone line. That data > stream is asynchronous and doesn't include any of the AX.25 frame > characteristics. > > The only connection between the two is that in the ancient, early days > of packet radio the first experimenters glommed onto some surplus BEL > 202 modems and used those as the last stage of their cobbled-together > TNCs; the use of AFSK with 1200 and 2200Hz tones is simply an artifact > of that. > > 73, > John N8UR > > > Matteo Campanella wrote: >> I'm quite surprised by this response of yours, as it is not exactly >> aligned with the friendly style of the list - I know that to make things >> clear is more difficult than slamming doors, but I like it more. >> >> Maybe I am referring to the BELL 202 erroneously, because I am actually >> trying to implement a modem for 1200 AFSK to use on AX25 on ham vhf band >> - >> I am not sure about it is BELL202, but I am sure it is encoded the way I >> said, as I have read this on a number of papers, including those from >> TAPR/ARRL Digital Communication Conferences, particularly: >> >> PIC-et Radio: How to Send AX.25 UI Frames Using Inexpensive PIC >> Microprocessors >> >> by John Hansen, W2FS >> State University of New York >> 49 Maple Avenue >> >> ... >> 3. Packet radio uses a modulation scheme called NRZI (Non-Return to >> Zero, >> Inverted). This means that the ones and zeros are not represented by >> high >> and low states (or tones). Rather, a zero is represented by a change in >> tone (if it was high, it goes low, if it was low, it goes high) while a >> one is represented by no change in tone. Together with bit-stuffing, >> this >> ensures that there will be a tone change at least every five bits, if >> not >> more often (except for flags). This helps the transmit and receive >> timing >> stay in sync.i >> >> maybe the correct name for this mod scheme is NRZI, and I wrongly called >> it BELL202 as I used an MX614 in one of my implementations, that is >> frequently reported as being BELL202 modem. >> >> useless to say, I do not consider anyone an idiot - neither in the list, >> nor in the whole world - that would be the very opposite of the HAM >> spirit >> you should know very well. >> >> yours truly >> Matteo iz2eeq >> >> >> >>>Matteo: >>> >>>Normally I do not play the game this way but let me suggest that you do >>>the following thing so we can get beyond this to give people the correct >>>information. >>> >>>Open up Google. Type in BEL-202, hit enter. Please tell me WHOSE NAME >>>and DSP assembler code you see on the first several entries and many of >>>the remaining entries. My code and name are not there by accident as >>>the most referred to pages in the world on BEL-202. >>> >>>The data is not Manchester encoded. It is not split level in the middle >>>of the bit. I think your safest bet is to assume that the people who >>>are in this group are not idiots. >>> >>> >>>100011010... is transmitted as >>>x10010101... >>> >>>The Bel-202 standard allows transmission up to 1800 bps. If it were >>>encoded biphase or Manchester, the channel would need to be > 3600Hz >>>wide. This was done back in the ancient days before equalizers, and >>>easy DSP so on
Re: [Discuss-gnuradio] bell 202 modulation
I'm quite surprised by this response of yours, as it is not exactly aligned with the friendly style of the list - I know that to make things clear is more difficult than slamming doors, but I like it more. Maybe I am referring to the BELL 202 erroneously, because I am actually trying to implement a modem for 1200 AFSK to use on AX25 on ham vhf band - I am not sure about it is BELL202, but I am sure it is encoded the way I said, as I have read this on a number of papers, including those from TAPR/ARRL Digital Communication Conferences, particularly: PIC-et Radio: How to Send AX.25 UI Frames Using Inexpensive PIC Microprocessors by John Hansen, W2FS State University of New York 49 Maple Avenue ... 3. Packet radio uses a modulation scheme called NRZI (Non-Return to Zero, Inverted). This means that the ones and zeros are not represented by high and low states (or tones). Rather, a zero is represented by a change in tone (if it was high, it goes low, if it was low, it goes high) while a one is represented by no change in tone. Together with bit-stuffing, this ensures that there will be a tone change at least every five bits, if not more often (except for flags). This helps the transmit and receive timing stay in sync.i maybe the correct name for this mod scheme is NRZI, and I wrongly called it BELL202 as I used an MX614 in one of my implementations, that is frequently reported as being BELL202 modem. useless to say, I do not consider anyone an idiot - neither in the list, nor in the whole world - that would be the very opposite of the HAM spirit you should know very well. yours truly Matteo iz2eeq > Matteo: > > Normally I do not play the game this way but let me suggest that you do > the following thing so we can get beyond this to give people the correct > information. > > Open up Google. Type in BEL-202, hit enter. Please tell me WHOSE NAME > and DSP assembler code you see on the first several entries and many of > the remaining entries. My code and name are not there by accident as > the most referred to pages in the world on BEL-202. > > The data is not Manchester encoded. It is not split level in the middle > of the bit. I think your safest bet is to assume that the people who > are in this group are not idiots. > > > 100011010... is transmitted as > x10010101... > > The Bel-202 standard allows transmission up to 1800 bps. If it were > encoded biphase or Manchester, the channel would need to be > 3600Hz > wide. This was done back in the ancient days before equalizers, and > easy DSP so one could not mitigate for channel edges. There is no split > phase data in BEL-202. > > Take it or leave it. I have left this conversation as of now. > > Bob > > > > > > > Matteo Campanella wrote: >> 100011010 should become >> 10 0 0 11 01 0 >> space-space,mark-mark,space-space,mark-mark-mark-mark,space-space-mark,space >> >> with the arbitrary decision on the first bit, that could be either space >> or mark, as there is no previous state. space is 1200Hz and mark is >> 2200Hz. >> I have already encoded this on a DDS based on PWM on a PIC 16F628, but I >> had control over REAL time there. >> I have just written a block to do the differential encoding, that is, to >> obtain the correct -1,1 sequence, but my doubt is how to apply this to >> the >> freq modulator in order to obtain exactly the two tones I need for mark >> and space, and the correct bit timing, as I do not have control over >> time... >> >> MC >> >> > > > -- > AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, > NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman > Laziness is the number one inspiration for ingenuity. Guilty as charged! > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bell 202 modulation
100011010 should become 10 0 0 11 01 0 space-space,mark-mark,space-space,mark-mark-mark-mark,space-space-mark,space with the arbitrary decision on the first bit, that could be either space or mark, as there is no previous state. space is 1200Hz and mark is 2200Hz. I have already encoded this on a DDS based on PWM on a PIC 16F628, but I had control over REAL time there. I have just written a block to do the differential encoding, that is, to obtain the correct -1,1 sequence, but my doubt is how to apply this to the freq modulator in order to obtain exactly the two tones I need for mark and space, and the correct bit timing, as I do not have control over time... MC > Bel 202 does NOT use Manchester encoding. The individual bits are NOT > sent bilevel but opposite polarity. Bel 202 very much as energy at DC > after demodulation which Manchester would eliminate. It does have > differential encoding but that is not Manchester. > > 100011010. > would be transmitted as > ?10010111 > > This is nothing to do with biphase elements. > > > Bob > > > > Matteo Campanella wrote: >> bell 202 coding requires to send a steady tone (mark or space depending >> on >> the previous state) on 1 and a tone change on 0, so the tone change must >> happen in the middle of a bit. >> >> in order to use a modulator I guess I should use a block to get a >> sequence >> of symbols that is twice as long as the bit sequence, that should be >> "played" twice as fast as the bit stream sequence, where bits at zero >> are >> represented by 1,-1 (or -1,1) and bits at one are represented by -1,-1 >> (or >> 1,1). >> >> is there any way to do that by using an already made block? >> >> Matteo >> >> >>> On Tue, Mar 28, 2006 at 11:51:03PM +0200, Matteo Campanella wrote: >>> >>>> Hello, I am trying to find the best way to implement a bell 202 modem >>>> in >>>> gnuradio. The problem I am facing is that I need to produce two tones, >>>> one >>>> for mark and one for space, and I have to switch from one to other >>>> depending on which symbol I am sending. The duration of the tone (or >>>> tone >>>> switch) must be set exactly according to the baud rate of 1200 I have >>>> to >>>> produce. >>>> >>>> I was thinking to use the nco class to generate the tones, and to >>>> output >>>> n >>>> samples per symbol at a certain fixed sample rate that would be enough >>>> for >>>> the 1200 baud, let´s say the standard audio 48000. >>>> >>>> Has anyone better suggestions to work this out? >>>> >>>> MC >>>> >>> Use the gr.frequency_modulator_fc block to generate complex baseband >>> FSK. >>> >>> You'll probably want to use gr.bytes_to_syms to in front of it, or in >>> the more general case: gr.packed_to_unpacked followed by >>> gr_chunks_to_symbols_bf. >>> >>> Eric >>> >>> >>> >> >> >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > > -- > AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, > NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman > Laziness is the number one inspiration for ingenuity. Guilty as charged! > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bell 202 modulation
bell 202 coding requires to send a steady tone (mark or space depending on the previous state) on 1 and a tone change on 0, so the tone change must happen in the middle of a bit. in order to use a modulator I guess I should use a block to get a sequence of symbols that is twice as long as the bit sequence, that should be "played" twice as fast as the bit stream sequence, where bits at zero are represented by 1,-1 (or -1,1) and bits at one are represented by -1,-1 (or 1,1). is there any way to do that by using an already made block? Matteo > On Tue, Mar 28, 2006 at 11:51:03PM +0200, Matteo Campanella wrote: >> Hello, I am trying to find the best way to implement a bell 202 modem in >> gnuradio. The problem I am facing is that I need to produce two tones, >> one >> for mark and one for space, and I have to switch from one to other >> depending on which symbol I am sending. The duration of the tone (or >> tone >> switch) must be set exactly according to the baud rate of 1200 I have to >> produce. >> >> I was thinking to use the nco class to generate the tones, and to output >> n >> samples per symbol at a certain fixed sample rate that would be enough >> for >> the 1200 baud, let´s say the standard audio 48000. >> >> Has anyone better suggestions to work this out? >> >> MC > > Use the gr.frequency_modulator_fc block to generate complex baseband FSK. > > You'll probably want to use gr.bytes_to_syms to in front of it, or in > the more general case: gr.packed_to_unpacked followed by > gr_chunks_to_symbols_bf. > > Eric > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] bell 202 modulation
Hello, I am trying to find the best way to implement a bell 202 modem in gnuradio. The problem I am facing is that I need to produce two tones, one for mark and one for space, and I have to switch from one to other depending on which symbol I am sending. The duration of the tone (or tone switch) must be set exactly according to the baud rate of 1200 I have to produce. I was thinking to use the nco class to generate the tones, and to output n samples per symbol at a certain fixed sample rate that would be enough for the 1200 baud, let´s say the standard audio 48000. Has anyone better suggestions to work this out? MC ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] (no subject)
hello everyone any documentation detail on: gr_pll_carriertracking_cc gr_pll_freqdet_cf gr_pll_refout_cc ? mny tnx ciao Matteo iz2eeq ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] jackit cvs rep not accessible
I mean without double sound card and external connectors... if you mean this as well, how do you configure oss or alsa to let usrp sink to something that is the sound source for such a program as gmsfk or drm? As far as I know only jack can... - Original Message - From: "Eric Blossom" <[EMAIL PROTECTED]> To: "Matteo Campanella" <[EMAIL PROTECTED]> Cc: "Robert McGwier" <[EMAIL PROTECTED]>; Sent: Monday, March 20, 2006 8:21 PM Subject: Re: [Discuss-gnuradio] jackit cvs rep not accessible On Mon, Mar 20, 2006 at 07:44:41PM +0100, Matteo Campanella wrote: Well, in the meanwhile, as jackaudio seems the only way to use a soundcard based decoding software as gmfsk or drm with usrp, is there anyone with a quite recent cva checkout willing to tarball it and send down here? gr-audio-alsa and gr-audio-oss both work. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] pure python block?
I guess that, being the array approach the one used in c++ blocks, that would be the best to use in python as well. So I would definitely work with input and output arrays. ciao Matteo > On Thu, Mar 23, 2006 at 09:31:01PM +0100, Matteo Campanella wrote: >> Suppose I am willing to test some ideas, and that I do not care about >> latency or speed - I just want to be able to drop some quick lines of >> code to see if the idea is a good one or not... it would be nice to >> write a function in python and put it in the graph to see how it >> performs in the chain, using no real time sources or sinks (eg files) >> >> is it possible? how? >> >> Matteo > > This is not currently possible. > > But then it's not impossible either ;) > > We could either leverage the "ufunc" framework that was briefly > mentioned in the past week, or create a new C++ block derived from > gr_block, gr_sync_block, etc, that accepts a python closure as a > constructor arg. The block's work method would then recursively > invoke the interpreter to evaluate the python code. > > What kind of args do think the python code would accept? > Is it sample at a time, or would you be passing, say NumPy arrays for > the input and output? > > Eric > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] pure python block?
Suppose I am willing to test some ideas, and that I do not care about latency or speed - I just want to be able to drop some quick lines of code to see if the idea is a good one or not... it would be nice to write a function in python and put it in the graph to see how it performs in the chain, using no real time sources or sinks (eg files) is it possible? how? Matteo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] manchester encoding and dpll
Hello, is there any gmsk like code that implements manchester rather than nrz? and maybe dpll demod? ciao matteo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] studying correlator and clock reconstructor
Hello, looking at the sources of those blocks, I have found calls to the function slice(), where is it defined? regards Matteo iz2eeq ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] jackit cvs rep not accessible
I am trying to use usrp as receiver and let it work in conjunction with let's say drm, that expects its input from a sound card. Is there any other way to make this happen than using jack audio? I have thoroughfully read the documentation of alsa, but I could not find any example or reference about how to build a virtual card able to "short-circuit" the output of an application to the input of another... any hint? ciao Matteo > - Original Message - > From: "Eric Blossom" <[EMAIL PROTECTED]> > To: "Matteo Campanella" <[EMAIL PROTECTED]> > Cc: "Robert McGwier" <[EMAIL PROTECTED]>; > Sent: Monday, March 20, 2006 8:21 PM > Subject: Re: [Discuss-gnuradio] jackit cvs rep not accessible > > >> On Mon, Mar 20, 2006 at 07:44:41PM +0100, Matteo Campanella wrote: >>> Well, in the meanwhile, as jackaudio seems the only way to use a >>> soundcard >>> based decoding software as gmfsk or drm with usrp, is there anyone with >>> a >>> quite recent cva checkout willing to tarball it and send down here? >> >> gr-audio-alsa and gr-audio-oss both work. >> >> Eric >> >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] jackit cvs rep not accessible
Well, in the meanwhile, as jackaudio seems the only way to use a soundcard based decoding software as gmfsk or drm with usrp, is there anyone with a quite recent cva checkout willing to tarball it and send down here? Matteo - Original Message - From: "Eric Blossom" <[EMAIL PROTECTED]> To: "Robert McGwier" <[EMAIL PROTECTED]> Cc: "Matteo Campanella" <[EMAIL PROTECTED]>; Sent: Monday, March 20, 2006 7:37 PM Subject: Re: [Discuss-gnuradio] jackit cvs rep not accessible On Mon, Mar 20, 2006 at 01:08:19PM -0500, Robert McGwier wrote: It really is a shame to see this once spectacular resource go straight across the River Styx into the fire. Do we have any idea what the overall problem is? Bob My guess is that they have insufficient revenue to support the infrastructure and staffing requirements. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] jackit cvs rep not accessible
Hello, the cvs repository for jackit seem not accessible from here at least from Sunday morning... it just hangs at login time. Alot of other projects, always located on sf are perfectly accessible instead... is any of you experiencing the same thing? regards Matteo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RF no tune preamplifier
I've just finished a low noise preamplifier prototype based on Avago MGA62563, and I would like to use it in conjunction with the tvrx - the device needs 3V @ 60mA, or 5V - is there any place on the board where I can get such a supply safely? ciao Matteo iz2eeq ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] usb and lsb transmission
Today i dedicated my spare time to the tx basci board, experimenting with usb, lsb and am signal synth. The idea was tp get voice from pc microphone and usb or lsb modulate it. I used a phasing modulator, based on the code excerpt reported below; basically I apply a pass band to the float source, then an hilbert filter followed by a software interpolation, to finish with the usrp interpolating the final jump to 128MS. To my surprise, I got USB with this graph, and i had to conjugate the output of the hilbert filter to get the LSB. That is because in my mind i had modelized the tx path of the usrp as the usual NCO (sine and cosine) multiplied by the real and imaginary stream arriving from usb and an ADDER in the end. Now, from what I recall, if I sum I should get LSB and if I subtract i should get USB; here it looks like it behaves the other way around. Any explanation for that? ciao Matteo iz2eeq audio_rate = 32000 sw_interp = 8 usrp_interp = 512 fg = gr.flow_graph () ampl = 2 src0 = gr.sig_source_f (audio_rate, gr.GR_SIN_WAVE, 700 , ampl) src2 = audio.source(audio_rate) moni = audio.sink(audio_rate) gain = gr.multiply_const_ff (2) interp_taps = gr.firdes.band_pass (sw_interp, audio_rate*sw_interp, 300, 3300, 1000, gr.firdes.WIN_HANN) print len(interp_taps) hilb_taps = gr.firdes.hilbert(199) hilb_filt = gr.filter_delay_fc(hilb_taps) interp = gr.interp_fir_filter_ccf (sw_interp, interp_taps) conj = gr.conjugate_cc() u = usrp.sink_c (0, usrp_interp) tx_subdev_spec = usrp.pick_tx_subdevice(u) m = usrp.determine_tx_mux_value(u, tx_subdev_spec) print "mux = %#04x" % (m,) u.set_mux(m) subdev = usrp.selected_subdev(u, tx_subdev_spec) print "Using TX d'board %s" % (subdev.side_and_name(),) print "Gain Range %s" % (subdev.gain_range(),) u.set_tx_freq (0, cordic_freq) u.set_pga(0,0) fg.connect (src2, gain) fg.connect (gain, hilb_filt) #fg.connect (src1,hilb_filt) fg.connect (hilb_filt,interp) fg.connect (interp,conj) fg.connect (conj,u) #LSB #fg.connect (interp, u)#USB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] first attempt at gnuradio - ssb phasing demod
Hello, I have made my first attempt at gnuradio and usrp today, trying to get a phasing ssb demod - what follows is what I got, any suggestion would be more than welcome. The demod is designed as a class to be istantiated by a gui (i am using a modified version of usrp_wfm_rcv gui). Right now the only sideband supported is LSB. Tested with the basic rx and my 40m vertical attached, it behaves nicely. ciao Matteo #!/usr/bin/env python from gnuradio import gr, gru from gnuradio import audio from gnuradio import usrp class ssb_phasing_demod: def __init__(self,gui): self.freq=gui.freq self.usrp_decim=gui.decim self.usrp_center=gui.center self.rf_sample_rate = 6400 / self.usrp_decim self.af_sample_rate = 32000 self.fir_decimation = self.rf_sample_rate / self.af_sample_rate self.fg=gui def set_freq(self,freq): self.freq=freq self.xlate_filt.set_center_freq(self.usrp_center - ( self.freq - self.tune_offset )) return True def set_center(self,center): self.src.set_rx_freq(0,-self.usrp_center) self.tune_offset = -self.usrp_center - self.src.rx_freq(0) self.xlate_filt.set_center_freq(self.usrp_center - ( self.freq - self.tune_offset )) return True def set_gain(self,gain): self.src.set_pga(0,gain) def build_graph (self): self.src = usrp.source_c(0,self.usrp_decim) mux = gru.hexint(0xf0f0f0f0) self.src.set_nchannels(1) self.src.set_pga(0,0) self.src.set_mux(mux) self.src.set_rx_freq(0,-self.usrp_center) self.tune_offset = -self.usrp_center - self.src.rx_freq(0) self.rf_LO = self.usrp_center - ( self.freq - self.tune_offset ) xlate_taps = gr.firdes.low_pass ( \ 1.0, self.rf_sample_rate, 20e3, 10e3, gr.firdes.WIN_HAMMING ) self.xlate_filt = gr.freq_xlating_fir_filter_ccf ( \ self.fir_decimation, xlate_taps, self.rf_LO, self.rf_sample_rate ) hilb_taps = gr.firdes.hilbert(199) self.hilb_filt = gr.filter_delay_fc(hilb_taps) self.split = gr.complex_to_float() bandpass_taps = gr.firdes.band_pass( \ 1.0, self.af_sample_rate, 300, 3300, 200, gr.firdes.WIN_HAMMING) self.bandpass_filt = gr.fir_filter_ccf (1,bandpass_taps) self.split1 = gr.complex_to_float() self.sum = gr.add_ff() self.volume_control = gr.multiply_const_ff(0) self.out = audio.sink(self.af_sample_rate) self.fg.connect(self.src,self.xlate_filt) self.fg.connect(self.xlate_filt,self.split) self.fg.connect((self.split,0),(self.hilb_filt,0)) self.fg.connect((self.split,1),(self.hilb_filt,1)) self.fg.connect(self.hilb_filt,self.bandpass_filt) self.fg.connect(self.bandpass_filt,self.split1) self.fg.connect((self.split1,0),(self.sum,0)) self.fg.connect((self.split1,1),(self.sum,1)) self.fg.connect(self.sum,self.volume_control) self.fg.connect(self.volume_control,self.out) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] TVRX tests in narrowband applications
It just happens I've got some MGA62563 from Avago (former Agilent) - those are MMIC on steroids: 0.8dB noise figure from 50 to 1300 MHz, 22db gain - 5v supply, very simple polarization circuit. Let's see how it performs. Given the very low intermod characteristic of the MMIC, i'll try without filtering to start with, eventually adding some notches on broacast FM and TV bands. > I strongly recommend buying an external LNA (HEMT or GaAsFET) and placing > it right at your antenna. Such LNAs have gains of around 15-25dB, > and noise > figures usually around 0.5-0.8dB. Cable losses for a 100ft run will > be around > 3-4dB. There's no point putting a low-noise amplifier on the front > of your > TV-RX, unless the feedline run to the antenna is very short (less than > 1ft or so). > > > > > -- > Marcus LeechMail: Dept 1A12, M/S: 04352P16 > Security Standards AdvisorPhone: (ESN) 393-9145 +1 613 763 9145 > Strategic Standards > Nortel Networks [EMAIL PROTECTED] > > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] am reception examples
I digged into the usrp c code, and I have found the following code, that
basically says we could use 32 bits for tuning on the fpga, but we truncate
it to 14 - unless there's a good reason for that, we could be much more
precise in tuning the NCO... again, unless Matt has a good reason for that.
ciao
Matteo
// The FPGA NCOs use a signed 32-bit frequency tuning word,
// but we keep only the most significant 14 bits.
static unsigned int
compute_freq_control_word_fpga (double master_freq, double target_freq,
double *actual_freq, bool verbose)
{
static const int NBITS = 14;
int v = (int) rint (target_freq / master_freq * pow (2.0, 32.0));
// v += 1 << (32 - NBITS - 1);// add 1/2
v = (v >> (32 - NBITS)) << (32 - NBITS); // keep only top NBITS
*actual_freq = v * master_freq / pow (2.0, 32.0);
if (verbose)
fprintf (stderr,
"compute_freq_control_word_fpga: target = %g actual = %g
delta = %g\n",
target_freq, *actual_freq, *actual_freq - target_freq);
return (unsigned int) v;
}
- Original Message -
From: "Eric Blossom" <[EMAIL PROTECTED]>
To: "Matteo Campanella" <[EMAIL PROTECTED]>
Cc:
Sent: Sunday, March 05, 2006 3:22 AM
Subject: Re: [Discuss-gnuradio] am reception examples
On Fri, Mar 03, 2006 at 12:06:01AM +0100, Matteo Campanella wrote:
In another script, usrp_wfm_rcv.pl, another method has been used, the
usrp.tune, that, according to the tests, does not need any successive
adjustment - is there any reason why the am receiver is not written using
this method?
usrp_wfm_rcv was written later in the game, and uses the prefered
method (works with all daughterboards). Whether or not you need to
the final software DDS depends on how precisely you need to be on
frequency. The WFM signal is > 100 kHz wide, thus an offset of a few
kHz makes no difference. For narrow band FM, or AM, etc, you probably
want to be closer. Take a look at usrp_nbfm_rcv.py, it uses the
preferred technique. Note that if you really are trying to handle AM
properly you're probably better off building a synchronous receiver or
some other method that tracks the carrier.
Another doubt is about optfir.low_pass versus gr.firdes.low_pass - from
the
tests I have run, the first one is much faster of the second - is there
any
reason to use the second instead of the faster optfir?
optfir uses the Remez / Parks-McClellan design method.
gr.firdes.low_pass designs filters using the window method. It all
depends on what you want. See any DSP book for details.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] virtual sound card driver
As there is alot of software that takes the soundcard as default source for doing digital processing, do you think it would be possible to build a virtual sound card device driver to be used as sink from gnuradio and as signal source from one of these softwares? I mean, a virtual sound card driver that has a line in with the real part on left channel and complex part on the right channel. Same thing could be true for the output... As far as you know is there anything like these already around? regards MAtteo iz2eeq ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Need help installing GNU Radio
Hello, FC4 is the very same system i am runing right now... the error you're ecountering could depend on the fact that your architecture is AMD based and not Pentium (is that true) - for AMD platforms you should indicate 3dnow and not sse in the buildbaseline from kd7lmo - he defaults to sse indeed, and that could be your case. Try reading the tutorial from dawei shen http://www.nd.edu/~dshen/GNU/Tutorial/1.html cheers Matteo iz2eeq > Message: 4 > Date: Mon, 6 Mar 2006 07:54:48 -0800 (PST) > From: jjw <[EMAIL PROTECTED]> > Subject: [Discuss-gnuradio] Need help installing GNU Radio > To: Discuss-gnuradio@gnu.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > > Hello all, > > I am trying to install GNURadio on a Fedora Core 4 system following the > instructions at http://www.kd7lmo.net/ground_gnuradio_install.html. I > completed the baseline install process (skipping the two octave installs > because I don't need them) and proceeded onto the gnu radio portion of the > install. When I go to install gnuradio-core I get an error duirng the > make > check (error below). I tried removing the enable-sse command from my FFTW > install per http://www.nd.edu/~dshen/GNU/Tutorial/1.html this site's > instructions for installing GNU radio but have not had any success. > If anybody has any idea what could be causing this and how to get past it, > I > would really appreciate it. Thanks for all the help! > > > > OK gr_fir_fff: using SSE > ../run_tests: line 15: 13414 Segmentation fault $file > > -- > Ran 4 tests in 0.020s > > OK > ... > -- > Ran 3 tests in 0.015s > > OK > ... > -- > Ran 3 tests in 0.018s > > OK > FAIL: run_tests > === > 1 of 1 tests failed > === > make[5]: *** [check-TESTS] Error 1 > make[5]: Leaving directory > `/home/jjw27370/Desktop/gnuradio/gnuradio-core/src/python/gnuradio/gr' > make[4]: *** [check-am] Error 2 > make[4]: Leaving directory > `/home/jjw27370/Desktop/gnuradio/gnuradio-core/src/python/gnuradio/gr' > make[3]: *** [check-recursive] Error 1 > make[3]: Leaving directory > `/home/jjw27370/Desktop/gnuradio/gnuradio-core/src/python/gnuradio' > make[2]: *** [check-recursive] Error 1 > make[2]: Leaving directory > `/home/jjw27370/Desktop/gnuradio/gnuradio-core/src/python' > make[1]: *** [check-recursive] Error 1 > make[1]: Leaving directory > `/home/jjw27370/Desktop/gnuradio/gnuradio-core/src' > make: *** [check-recursive] Error 1 > -- > View this message in context: > http://www.nabble.com/Need-help-installing-GNU-Radio-t1234009.html#a3264114 > Sent from the GnuRadio forum at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] TVRX tests in narrowband applications
Hello, I started my testing evening (after ARRL worldwide phone contest, where I was desperately looking for Vermont to close WAS - are there hams in Vermont??? :-)) taking care of TVRX. First thing I did was to attach the TVRX to the tribander collinear I use for V/UHF local traffic and use the nbfm receiver to listen. Actually, most of the signals, easily heard on the ic706mkiig were not audible on the usrp, even at the maximum gain. Only 9+ signals were indeed demodulated and therefore audible (at the maximum gain). After all the sensitivity of 706 is 0.18uV, while the datasheet of the microtune unit says 40dbuV - so at least 40db gain are missing in the tuner - the worst thing is that the noise figure is 10dB, so the internal amplifier isn't quite based on GaAs ;-) Going to the workbench, I injected a 145MHz, 400Hz, 5KHz deviation FM modulated signal in the ic706 and the [EMAIL PROTECTED] gain, looking for the point where the signal was audible - it turned out to be -100dBm for the tvrx and -112dBm for the ic706 - so we're missing at least 12dBm power gain. These measurements are indicative and quite empyrical - "audible" is not very scientific as definition and the tuner is a 75ohm device, quite mismatched when connected to 50ohms gear. My final evaluation is that, since I want to use the equipment also for experimenting in the UHF FSK G3RUH-like field, I will need to add a serious low noise front end to the tuner - something for example built around the MGA62563. Is there anyone that already dealt with the subject and has already realized and tested some circuitry? Any suggestions? Matteo iz2eeq ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
