On Tuesday 21 March 2006 19:15, you wrote:
> On Tue, Mar 21, 2006 at 02:53:05PM +0100, Luis Simoes wrote:
> > Hi all,
> >
> > I am a novice in gnuradio and after searching in a lot of forums I put my
> > USRP working and my Gnuradio running. Some FM and AM reception with and
> > without GUI are working fine. Now I have some problems in FSK. I try to
> > receive in ISM 433 MHZ some data packets with a data rate of 38.4 kbaud.
> > The data is manchester encoded. To do this I followed the way in the
> > gnuradio examples (fsk_rx.py) with a channel filter and the simple
> > correlator. To do the correct manchester decoding I changed the
> > correlator block in according to my needs and build the new block
> > howto_manchester_correlator. The difference between my
> > manchester_correlator and the simple correlator is the packit function
> > and the sync bytes (instead of using GRSF_SYNC I use MAN_SYNC=
> > 0x66669999, these are the preamble and syncronization bits).
> > Now when I start my application gnuradio starts receiving some data that
> > is written to a file, but my transmitting module is switched off and the
> > data is complete nonsense. When I switch on the transmitter the result is
> > the same. This occurs also when I ran the application with the simple
> > correlator. The seqno where in random order, but there should be nothing
> > because I didn't send anything in the simple_framer format. Now I think
> > the correlators are working well but the problem can be on the radio
> > part.
> > My system is working on Linux-kernel 2.6 (Linux 9.3) and the CPU is AMD
> > Athlon XP 2400+
> > I have tried to adjust all parameters with no result.
> >
> > I am very grateful for any kind of help or advice.
> >
> > Luis
>
> Hi Luis,
>
> The examples in gnuradio-examples/python/gmsk2, and the guts in
> gnuradio-core/src/python/gnuradio/blksimpl/{gmsk2,gmsk2_pkt}.py are
> much better starting points than the "simple correlator" code. They
> implement proper symbol timing tracking algorithms, instead of just
> locking up at the header and then drifting from there.
>
> When trying to get a mod/demod working, we usually start with a
> simulation into and out of of files, or other sinks and sources.
> That way we can look at the output of the transmitter and confirm that
> it looks like what we expect. Then we can sort out the receiver using
> known input data.
>
> Hope that helps,
> Eric
Hi Eric,
thanks a lot. Now I am looking a bit at the code of gmsk2 and gmsk2_pkt. What
do you think about building the graph this way (without radio part):
gmsk2_demod ----- keep one in N ----- packing ------- file_sink
^^^ ^^^
manchester decoding pack symbols to bytes
Is oversampling rate (spb) of 2 enough? What is the result of gr.packe_sink?
Where is the data? I have to implement a preamble detection, is this possible
with the packet_utils?
The problem is I try to design a receiver for the data format of a MICA2 mote
module and there is no access_code in the packet nor the payload length is
512 bytes.
Thanks again,
Luis
-------------------------------------------------------
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
