[Discuss-gnuradio] Packet Transfer was: config woes

[Lee & Chris studley]

Guys, I ran across the message thread "Packet Transfer" and it looked like 
it may be related to my stalled thread issue. Could it be a USB issue of a 
small USB packet less than 512 bytes?

-Lee
Quoted".......
15. Re: [Discuss-gnuradio] Packet Transfer? (score: 3)
Author: Eric Blossom <address@hidden>
Date: Thu, 9 Feb 2006 11:06:25 -0800
Because with "the usual way" you can't see the (variable length) packet 
boundaries. If you're worried about the threads, you've got your eye on the 
wrong problem. (Premature optimization...) Specific
/archive/html/discuss-gnuradio/2006-02/msg00038.html (7,652 bytes)
"""On Thu, Feb 09, 2006 at 08:46:53AM -0500, Michael Dickens wrote: > After 
reading through the GMSK2 code, I wonder why packets are not > transferred 
in the "usual" way: via the graph "connect()" method? > They are instead 
transferred via "callforward" ["send_pkt()"] and > "callback" 
["rx_callback()"] methods, which requires extra threads to > "automate" any 
data transfer. Because with "the usual way" you can't see the (variable 
length) packet boundaries. If you're worried about the threads, you've got 
your eye on the wrong problem. (Premature optimization...) Specifically wrt 
send_pkt, you've got to solve the problem of getting the data from python 
to C++. The message/msg_queue solves it nicely. In the past we've also used 
pipes and/or sockets. FWIW the message/msg_queue is also used to transfer 
data from C++ to python in fftsink & scopesink. Seems to work fine, and the 
implementation is portable across operating systems. > What I'd really like 
is to send packets as structured chunks of data, > using "connect()" in a 
graph. OK. Are you dealing with fixed length or variable length packets? If 
variable length, how are you going to communicate the length? It is 
possible to pass fixed length structures around. We did this with the ATSC 
receiver. I'm interested in your ideas in how to represent variable length 
packets within the (modified?) framework. This would definitely be useful. 
Another (possibly) related things I'd like to do, is to be able to run a 
packet through the graph, then, say append 8 zeros, or some such. That 
particular operation is very hard to do with the current data flow 
approach. Others have suggested a "two level scheduler". The bottom one 
would be the existing one (or something close) and the top level one would 
know about packet boundaries, etc. For example, imagine you've receive an 
annotated packet from "outside" (typically a MAC). The annotations could 
include things like "transmit power", "channel coding", etc. You want this 
high level packet processed in one logical chunk through the graph. But 
then may want to change things around before or after the next bunch of 
data. E.g., trailing padding. Still other have suggested a "functional" 
approach, with generators/streams wired together and a way to read from / 
write to abstract streams. Another approach would be the "push" / "pull" 
distinction used in the "Click Modular Router". Yet another intersecting 
issue is the ability to "stall" a piece of the graph. The gmsk2_pkt stuff 
implicitly takes advantage of this, and only runs the transmit part of the 
graph when there's data to sent. The trick is making sure everything gets 
flushed out of the pipeline before you stall. For example, you don't want a 
partially full USB packet (512 bytes / 128 samples) lying around. The 
existing code kludges around the problem. Good ideas & concerns! Lets 
figure out a way to solve it! Eric


>    1. reconfiguration woes (Lee)
>
>
> Hi,
> I've been trying to do a reconfigurable  setup that switches between a ssb
> mode and then gmsk.
> I can reconfigure to ssb multiple times successfully, the flowgraph starts
> and stops correctly.
> When I go to reconfig for gmsk mode, it works again, once. Then If I try to
> return to ssb mode, the gmsk flowgraph will not stop. It hangs forever in
> the scheduler.  I do the fg.stop()   fg.dissconnect_all() and reconnect the
> new paths and fg.start() as needed.
>
>
> I found a verbose mode that was built into the scheduler ( since the class
> inherits from a useful Verbose object ) that enables the listing of the
> _notes about the active threads. This has narrowed it down to a thread that
> was spawned during the gmsk flowgraph start(), but wont stop() when asked. 
> Just
> waits forever. Wow, being new to python and run into a thread issue right
> off :-)
>
> I've been banging my head for weeks on this( I hate to ask for help when
> the process involves the learning curve. I consider it a right of passage
> task :-) but at this point I could use the help.
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio