> The former technique appears more general, less reliant on prior
> filtering, and immune to long strings of 1s or 0s. On the other hand,
> the latter technique is simpler, requires fewer calculations and less
> memory.
>
> So if the sample stream is known to have sufficient zero crossings and
> has been properly filtered, do you see any hazards to going with the
> latter technique?
Having both techniques available to GNU Radio users seems like a nice
thing. And a zero-crossing block would also be useful for receiving
"async" as opposed to "sync" serial transmissions (that have no frame
sync code, just a start bit on each byte).
But since we already have a block that does this function reliably for
synchronous communications, adding a second way seems like premature
optimization, unless you have a specific application on a specific PC
that is failing to keep up with realtime.
Right now I would put my effort into something else -- like a block
that we don't have a good implementation of, or a higher level
function like an easy to use and flexible "scanner-like" GUI.
John
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
