correlator block in according to my needs and build the new block
the correlators are working well but the problem can be on the radio
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
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.
has an FAQ which gives some information.
One neat trick is to use gnuplot’s “splot” function on complex data.
It will actually plot a 3d phasor tip corkscrew that you can drag
around with the mouse and look at from various angles.
nice to see someone in the gnuradio world treating with the same
problems.
In my case the cc1k send 5 preamble bytes (0x6666) followed by a
synchronisation sequence of 0x9999. After this comes the header and my
data.
The synchronisation sequence of 0x9999 is the chip pattern of
transmition
what represents a bit pattern of 0x33.
Could you sent me some of your code to see how you realised the
synchronisation detection and the manchester decoding? Did you use bit
padding as in gmsk2?
Thank you in advance,
Luis
Luis Simoes
Department of Wireless Networks
RWTH Aachen
On Wednesday 22 March 2006 20:44, you wrote:
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.
nice to see someone in the gnuradio world treating with the same
problems.
In my case the cc1k send 5 preamble bytes (0x6666) followed by a
synchronisation sequence of 0x9999. After this comes the header and my
data.
The synchronisation sequence of 0x9999 is the chip pattern of
transmition what
represents a bit pattern of 0x33.
Could you sent me some of your code to see how you realised the
synchronisation detection and the manchester decoding? Did you use bit
padding as in gmsk2?
Thank you in advance,
Luis
Luis Simoes
Department of Wireless Networks
RWTH Aachen
On Wed, Mar 22, 2006 at 11:44:42AM -0800, Thomas S. wrote:
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
Thomas,
Can we get this code into the GNU Radio repository?
It’s sounds like it’s of interest to many.
Eric
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
