On 6/20/06, Eric Blossom <[EMAIL PROTECTED]> wrote:
On Tue, Jun 20, 2006 at 10:44:05AM -0700, Eric Blossom wrote: > On Tue, Jun 20, 2006 at 10:29:33AM -0700, Thomas Schmid wrote: > > Hi Everyone, > > > > - Right now, we need to send an additional 100 byte at the end of each > > message or else, the other side can not decode them. Still figuring > > out why that is. > > Probably not padded out to a USB boundary. See the kludge in packet_utils.py
I thought so, but searching in packet_utils.py I figured out that this can not be the case. Here my reasoning: - IEEE 802.15.4 does spreading, i.e., each data byte gets spread to 64 bit - I then upsample by 2 to get nyquist rate - Each sample is 16 bit (i.e. 2 byte), thus we get the 512 byte for the usb packet In short, each data byte will yield one usb packet. I experimented a little bit further and found that when I don't pad at the end of the message, then the bytes received at the receiver are not correctly synchronized and thus, at some point, I get an error in despreading. The 100 bytes I mentioned before are from an earlier experiment where my packets were smaller. I now use a packet with 28 bytes and need to pad it with 50x 0 bytes and the packets get received correctly by a CC2420 radio chip and my GnuRadio code. If I don't zero pad, or if I zero pad with a smaller amount (like 5x 0 bytes) then, the packet gets received by my GNURadio code, though the bytes are wrong (so, there is stuff sent out), but the CC2420 fails since the CRC at the end is wrong. This shows me, that the problem must be on the sending side, not the receiving... Any ideas why that could happen? Are there any other buffers in the FPGA I have to take care of, i.e., needs to be flushed? Cheers, Thomas
This will be properly fixed when the mblocks are ready. Eric
_______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
