Achilleas, I agree, I do not think that anything in gr-trellis needs to be modified to get my desired effect. I think the m-block stuff may provide the hooks to make this a lot easier to code up. In the short term, I will probably write up something quick and dirty just to get my desired results.
Tim On 2/21/07, Anastasopoulos Achilleas <[EMAIL PROTECTED]> wrote:
Tim, If the number of additional bits is not significantly bigger than the fixed packet length (in your example 200), then you can instantiate the VA with the MAXIMUM expected length (eg, K=200+10). For this to work you have to 1) put a block before it that appends 0's (or something else) in packets that are smaller than K and 2) at the output of the VA you have to put a block that discards the unwanted bits The question still remains: how do these blocks (before and after the VA) know in real time what the size of your packet is? I have no clue! Essentially you want to create a block that knows what is the size of the packet it needs to process from the packet itself... if you find out how to do that, I would be happy to incorporate it in the viterbi block. However my feeling is that this will be application dependent and the purpose of all these blocks are to be generic... Achilleas On Wed, 21 Feb 2007, Tim Meehan wrote: > Hi Achilleas, > > I was interested in various length packets. I am taking a fixed > length packet ( say 200 symbols ) and then bitstuffing it, resulting > in a packet >= 200 symbols. I then receive this with the viterbi > algorithm and then finally unbitstuff. So in this, case K = 200 + > number of stuffed bits. I guess I could run N viterbi algorithms in > parallel for the N possible different number of stuffed bits. I > guess I could also have the block that bitstuffs the data pad out to a > fixed block size. > > > Thanks again for you suggestions and help. > > Tim > > > > On 2/21/07, Achilleas Anastasopoulos <[EMAIL PROTECTED]> wrote: >> Tim, >> >> I think there are two parts in your question: >> 1) how to detect an incoming packet and do something with it. >> 2) how to operate the viterbi algorithm block in a packet to packet >> basis without generating the flow graph again. >> >> I only know how to answer the latter question: >> >> The viterbi algorithm (see all examples in >> gnuradio-examples/python/channel-coding/) >> processes the incoming stream in PACKETS by design. >> When you instantiate the block, ie using >> >> va = trellis.viterbi_s(f,K,s0,sK) >> >> then "K" is the block size to be processed (measured in trellis steps), >> with initial state fixed at "s0" and final state fixed at "sK" >> (or put -1 in the corresponding positions if you dont want to fix them). >> >> Thus is we send a stream of n x K symbols then the va block will run the >> algorithm n times with the set initial/final states. >> If you send a continuous stream of data to the input of the VA it will >> break it into blocks of K symbols and process each block separately. >> >> Hope this helped clarify the use of the viterbi block. >> Achilleas >> >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio