Forum: GNU Radio setting fields in the USB packet

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
George N. (Guest)
on 2007-04-05 07:01
(Received via mailing list)
Heyo,

Eric, I think you started to mention something about this last night.
But do we
want a separate method for setting each field in the USB packet?  There
are
several fields that we won't ever need to set on our end, only need to
read.
For instance, the dropped packets field.

So heres what i'm thinking:

// Create the payload
//   'packet_ptr' is a pointer to a USB packet in memory
//   'samples'    is a vector of unsigned char
//
//   the payload can be inferred from the samples and inserted in to the
packet
//
//   the method should also pad the payload

usb_set_payload(packet_ptr, samples)


// Set the timestamp
//
// 'packet_ptr' is a pointer to a USB packet in memory
// 'timestamp' is a 32 bit int

usb_set_timestamp(packet_ptr, timestamp)


// Set the channel
//
// 'packet_ptr' is a pointer to a USB packet in memory
// 'channel'    is an integer
//
// Should this also error check on the channel number? (5-bit limit)

usb_set_channel(packet_ptr, channel)


// Set the start of burst flag
//
// 'packet_ptr' is a pointer to a USB packet in memory
//
// This just needs to flip a bit

usb_set_start_of_burst(packet_ptr)


// Set the end of burst flag
//
// 'packet_ptr' is a pointer to a USB packet in memory
//
// This just needs to flip a bit

usb_set_end_of_burst(packet_ptr)


Discussion:
-----------

Do we need methods to unset burst flags?  I don't see a need for them.

Should we have a method to zero out the packet?  Or are we just going to
just
use low level memory clearing methods?

- George
George N. (Guest)
on 2007-04-06 20:18
(Received via mailing list)
actually some of this is changing to pmt related stuff, now that I'm
reading more in to
the pmt class.  I'm going to check in some high level stuff in my branch
tonight probably
that you can look over instead.

- George
Eric B. (Guest)
on 2007-04-06 22:18
(Received via mailing list)
On Fri, Apr 06, 2007 at 12:17:40PM -0400, George N. wrote:
> actually some of this is changing to pmt related stuff, now that I'm
> reading more in to the pmt class.  I'm going to check in some high level
> stuff in my branch tonight probably that you can look over instead.

George, I don't think any pmt stuff should enter into these functions.
This shouldn't take that long to implement.  Here's 75% of the answer:



#include <usrp_bytesex.h>

static const int USB_PKT_SIZE = 512;   // bytes

class usrp_inband_usb_packet {
  //
  // keep raw packet in USRP-endian order
  //
  uint32_t    d_word0;
  uint32_t    d_timestamp;
  unsigned char    d_payload[USB_PKT_SIZE-2*sizeof(uint32_t)];

public:

  enum flags {
    FL_OVERRUN        = 0x80000000,
    FL_UNDERRUN       = 0x40000000,
    FL_DROPPED        = 0x20000000,
    FL_END_OF_BURST   = 0x10000000,
    FL_START_OF_BURST = 0x08000000,

    FL_ALL_FLAGS      = 0xf8000000
  };

  ...

  static const int CHAN_MASK = 0x1f;
  static const int CHAN_SHIFT = 16;

  ...


public:

  void set_timestamp(uint32_t timestamp){
    d_timestamp = host_to_usrp_u32(timestamp);
  }

  uint32_t timestamp() const {
    return usrp_to_host_u32(d_timestamp);
  }

  void set_header(int flags, int chan, int tag, int payload_len){
    uint32_t word0 =  ((flags & FL_ALL_FLAGS)
                       | ((chan & CHAN_MASK) << CHAN_SHIFT)
                       | ((tag & TAG_MASK) << TAG_SHIFT)
                       | ((payload_len & PAYLOAD_LEN_MASK) <<
PAYLOAD_LEN_SHIFT));
    d_word0 = host_to_usrp_u32(word0);
  }

  int flags() const {
    return usrp_to_host_u32(d_word0) & FL_ALL_FLAGS;
  }

  int rssi() const {
    ...
  }

  int chan() const {
    uint32_t word0 = usrp_to_host_u32(d_word0);
    return (word0 >> CHAN_SHIFT) & CHAN_MASK;
  }

  int tag() const {
    ...
  }

  int payload_len() const {
    ...
  }

  ...

  //! return pointer to byte 0 of payload area
  unsigned char *payload(){ return d_payload; }

};
George N. (Guest)
on 2007-04-08 00:36
(Received via mailing list)
Eric B. wrote:
> On Fri, Apr 06, 2007 at 12:17:40PM -0400, George N. wrote:
>> actually some of this is changing to pmt related stuff, now that I'm
>> reading more in to the pmt class.  I'm going to check in some high level
>> stuff in my branch tonight probably that you can look over instead.
>
> George, I don't think any pmt stuff should enter into these functions.
> This shouldn't take that long to implement.  Here's 75% of the answer:

Checked in some code in to my branch which compiles successfully and has
most of
the packet functionality.  I need a function to set the payload and pad
it, but
I'm literally putting on my shoes and running out the door to visit my
fam for a
bit.  Will finish it tonight.  Just kicking it out for some feedback and
checks
in the meantime.

:)

- George
Eric B. (Guest)
on 2007-04-08 01:20
(Received via mailing list)
On Sat, Apr 07, 2007 at 04:35:28PM -0400, George N. wrote:
>
> Checked in some code in to my branch which compiles successfully and has
> most of the packet functionality.  I need a function to set the payload and
> pad it, but I'm literally putting on my shoes and running out the door to
> visit my fam for a bit.  Will finish it tonight.  Just kicking it out for
> some feedback and checks in the meantime.
>
> :)
>

Thanks.

There's already a method that returns a pointer to the payload
section.  Just use memcpy to put what you want there.  Also, note that
nobody looks at the pad (that's why it's called pad and not MBZ), so
there's no reason to initialize it.

Eric
George N. (Guest)
on 2007-04-08 02:29
(Received via mailing list)
>
> Thanks.
>
> There's already a method that returns a pointer to the payload
> section.  Just use memcpy to put what you want there.
yep yep, done.

Also, note that
> nobody looks at the pad (that's why it's called pad and not MBZ), so
> there's no reason to initialize it.
Ahh true, was going to zero it out but you're right, doesn't matter.

- George
This topic is locked and can not be replied to.