Tim,
I think there are two parts in your question:
- how to detect an incoming packet and do something with it.
- 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
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
Achilleas,
Could the Viterbi block be implemented in such a fashion that the
algorithm was a streaming implementation as opposed to a fixed block
size?
That way, you could just send in a vector of deinterleaved soft
decisions, and (with a little bit of overhead) the Viterbi block could
take in any variable length block with zero padding at the end.
Moreover, it would retain its generic nature but would increase
computation by adding a slight overhead.
Brian
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
- put a block before it that appends 0’s (or something else)
in packets that are smaller than K and
- 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
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
Brian,
Yes it can!
You need to set a decision delay D and then it would operate in a
fixed-delay mode, ie, it would spit out a decision at every time
instance
with a delay of D compared to the input sample.
The survivor matrix (of size DxS) will need to be updated at every
time instance in order to make a decision (thus the additional
overhead).
I am not sure I have the time to code this though… 
but it shouldn’t be that hard.
Achilleas