On Thu, Nov 17, 2005 at 04:16:55PM -0500, [EMAIL PROTECTED] wrote: > I am also in the process of studying this part of the software to see if I > can use it to recreate my data from the demodulated signal.
Let me start by saying that you'd be *much* better off studying the packet framing / deframing and clock recovery code that is used in the new gmsk2.py and gmsk2_pkt.py files in gnuradio-core/src/python/gnuradio/blksimpl and the corresponding examples in gnuradio-examples/python/gmsk2 The new code is much cleaner and faster, and since it tracks symbol timing, works for long packets. As Bob pointed out, the so called GMSK receiver will receive pretty much any kind of FSK data. > Can anyone provide information on what are sync field, seq number and > command field that are added to the payload? The sync code is a 64-bit pattern that is used to establish bit and frame alignment. gr_simple_correlator contains a state machine that looks for the sync code in the 8x oversampled input stream, and when it finds it, it knows that it has found the beginning of a packet. [In reality, it's a bit more complicated than this, since the input data is 8x oversampled, and it's looking for the best symbol-alignment at the same time.] > I need to recreate this in my transmitter which is not usrp/gnuradio > based. It's just a simple micro controller. So far I have not been > able to understand what the gr_simple_framer does. Don't use it. Look at the new code. > Does the framer convert digital data stream to self-synchronizing code? The framer adds the sync pattern to the beginning so that the receiver can establish frame and bit synchronization. You need some way to figure out how your data is aligned. We used one technique; there are others... > My transmitter clock rate is not a multiple of 64 MS/s and therefore so is > my data rate. Will this cause difficulty? I am using very low data rate > and with short retransmission time. Not with the new code ;) With the new code you specify the nominal samples/baud (spb), which needn't be an integer, and it recovers the clock, resamples the incoming data so that we're sampling in the middle of a bit, and then passes the properly timed data off to the packet sink. The packet sink correlates for the sync pattern in a similar fashion to gr_simple_correlator, but is simpler, since it's not dealing with oversampled data. The clock recovery code take a parameter that specifies the maximum relative frequency error that it will track out. The default value is 200 parts per million (ppm), which should be plenty loose for anything with a xtal oscillator in it. Trust me, you really want to be studying the new code... Eric _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
