Re: Re: [Discuss-gnuradio] FSK with TX-RX in ISM-band 433 Mhz

[Thomas Schmid]

Hi Luis,

I have the code to decode mica2 motes. It is not perfect yet since I
still use the correlator and I would like to move over to the gmsk way
with proper synchronisation. But it works ;)

In my case, the cc1k sends a synchronisation sequence of 0x999999 to
which I synchronize the correlator. Then, I feed the found softsymbols
into the sos_packet_sink. You have to note that I use SOS as an
operating system on the mica2s. SOS adds a sync sequence just before
the message starts (tinyos does the same). The sos_packet_sink then
finds that sequence in the soft symbols which allows us to get byte
synchronisation. Then, we can look at the packet header and read the
whole message. Once parsed, the messages get added to a msg_queue.
>From the message queue, they get to the registered callback.

Thomas

On 3/22/06, Luis Simoes <address@hidden> wrote:
> 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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>