Re: [Discuss-gnuradio] questions about syncing to an input bit stream that has a header

[Marcus Müller]

Hi Tom,

first of all: welcome to GNU Radio! Great to have you around!

> I am aware of the gr-dsd OOT, but I want to decode/encode using a
> method that won't violate patents. 
I am not a lawyer, and I have no intention of sparking a legal and
political discussion on this topic here: but for most U.N. member
states, non-commercial/research usage of patented technology is covered
by exceptions on the definition of "patent infringement". Actual
practice might differ.

Of course, if someone plans to build a commercial unit containing
mbelib, than you're inherently doing exactly what should be inhibited by
patent law (by the spirit of the patent law). If you can avoid
infringing a patent in that case totally depends on the patent and your
local jurisdiction. If decoding a specific digital thing is patented, no
matter /how/ you do that, you probably will be infringing the patent,
unless a court says you aren't, because your technical implementation a)
substantially differs from the claims made in the patent, or b) the
claims you're infringing are invalid. Having a) or b) might both be
impossible, depending on the patent (if rolling a stone down a hill is
patented, then it doesn't matter how you're actually rolling that stone,
you're still rolling the stone down that hill).

> My dstar_encode_sb block seems more straightforward: When the flow is
> started, just like a delay block, dstar_encode_sb will insert the
> overall sync and header at the beginning of the transmission, then the
> voice frames will be generated from an audio source. I'm unsure how to
> properly terminate the end. Is there another block function that I can
> override to add a final termination frame to the output stream as the
> flow is shutting dow
Wait, wouldn't you want to slice up your audio to payload packets of
defined size, and add header and end to each? That would be relatively
easy, and solve the "I need to do something when all else shuts

> My dstar_decode_bs is quite a bit more complicated. I would like my
> dstar_decode_bs block to print some values from the header and only
> output audio when it is receiving voice frames. Is that possible? Can
> work() return zero when my block is not processing voice frames? Is
> forecast() a hard rule, or is it just a suggestion to the gnuradio
> scheduler? 
No, the scheduler uses forecast ask your block if it will be able to
produce output. If it claims it can't produce output, work() won't be
called.

However, it's perfectly legal to let forecast tell the scheduler it'll
be able to produce some values based on the hypothesis the next packet
will contain voice – GNU Radio won't complain when your general_work()
doesn't do exactly what forecast() forecast.

Best regards,
Marcus

[1] http://www.wipo.int/meetings/en/doc_details.jsp?doc_id=256317
On 06/26/2016 03:19 PM, Tom Early wrote:
> You can tell from my questions below that I am very new at this. If
> there is some other approach to my OOT that make more sense, please
> tell me...
>
> I am aware of the gr-dsd OOT, but I want to decode/encode using a
> method that won't violate patents.
>
> I'm working on a OOT that will have various blocks to encode/decode
> using an AMBE3000 device.
>
> For decoding, incoming data will have an overall sync of 64+15 bits
> followed by a 660 bit header and then 20 millisecond voice frames with
> the encoded data (72 bits) and a "slow data" (24 bits). Starting with
> the first voice frame, every 21st frame will have a 24 bit frame sync
> instead of slow data. (It's the DStar protocol, see
> http://www.qsl.net/kb9mwr/projects/dv/dstar/dstar_dv_frame3_en.pdf ,
> and it uses GMSK to convert between rf and digital.) The AMBE3000 will
> decode the 9 bytes of voice data in the 12 byte frame into 160 audio
> samples (short ints at 8000 per sec). The final voice frame should not
> have any "slow data" but instead have a 48 bit termination pattern).
>
> My dstar_encode_sb block seems more straightforward: When the flow is
> started, just like a delay block, dstar_encode_sb will insert the
> overall sync and header at the beginning of the transmission, then the
> voice frames will be generated from an audio source. I'm unsure how to
> properly terminate the end. Is there another block function that I can
> override to add a final termination frame to the output stream as the
> flow is shutting down?
>
> My dstar_decode_bs is quite a bit more complicated. I would like my
> dstar_decode_bs block to print some values from the header and only
> output audio when it is receiving voice frames. Is that possible? Can
> work() return zero when my block is not processing voice frames? Is
> forecast() a hard rule, or is it just a suggestion to the gnuradio
> scheduler?
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio