On 18 April 2012 22:35, Kristoff Bonne <[email protected]> wrote: Hi Kristoff,
Just one thing I wanted to follow up on. The rest I think will be covered when I have something draft enough to post here for people to take a look at. > OK, I'll let you first draw up your ideas. > > But perhaps it would also to look at this from a "repeater" point of view. > > Remember that D-STAR is designed to be send over repeaters (probably > 99.9% D-STAR QSOs use a repeater), and this has some special demands. > > > A repeater is nothing else but a voice-switch so it must take "routing > descision" on streams that come it. > The advantage of having a header in front of the stream is that you can > make this routing-descission as of receiving all information needed for > that, i.e. receiving the D-STAR header, i.e. the beginning of the stream. > You might want to avoid having to write repeater-code that first has to > take in a stream and then have to wait until the n-frame later before it > knows if it needs to forward it or ignore it. > > With the D-STAR header in front, it can take the routing-descission with > minimal buffering and latency. > > > > Do try to look at this from that side too, not just a point-to-point QSO > between two station in simplex. Just wanted to clarify here. Because I was talking about a few things at the same time. The idea is to send 64 bits of preamble (10 repeated as you mentioned). This I am calling outside of the scope of the encoding design, since it's a generally done thing when sending GMSK data. But I will make it clear it's a requirement in the documentation. After this, the SYNC pattern for data only (4 segments of 24bits data only) will be sent. At which point header data will be sent. What I meant was that the format for the data stream doesn't change for the header data. It still fits in the 4x24 container format. Once the header is sent, the SYNC signal for 1 data + 3 voice segments will be sent, and the voice stream will begin to be sent. In the absence of any other data to send, the header data will be repeated gradually over the 1 data segment in each block. Periodically (right now I am thinking every 32 blocks or so) the SYNC signal will be repeated (such that any loss of sync can be re-attained within a second or so). D-Star repeats the sync much more often, so 32 blocks may be too much. But I guess we'll see what works best. I'm also making the first usable data segment contain a data "Mode ID", which will describe how the following data segments are to be interpreted. By default, we have two modes. Header repetition data, or user data. But, there can be all kinds of mode IDs added, to include controlling repeaters and so on. My ideal plan is to work on simplex as a first draft. But including some basic info in the header for repeater access, so hopefully the header is good enough to be used with repeaters too. It can be fleshed out more again, once I have a draft out there. The ability to add extra data types, and the fact that after the initial header, it'd be possible to send further data before the voice starts. I'm trying to make it extendible ideally without breaking older implementations (they should just ignore what they don't understand). I made a bit of a dent into the documentation tonight. Pretty much tying up the design overview. The more detailed side comes next. But I think I have most of it pinned down in my head at least. As to whether it will work in practice, or someone here will see something glaring that I didn't think about, well - we'll see. When it comes to giving examples of how the bit scrambling, interleaving and forward error correction will work. I may include reference code (something woefully lacking in the D-Star documentation I found). I hope you don't mind if I use your code in there? Also, I was wondering if you'd ever compiled your GMSK modem code on a normal PC running linux? I see it uses alsa etc. I assumed it would just work. I've not tried it yet though. Ideally I'm hoping there's a way to get it working on cygwin too (so as to make a windows accessible version too). Well I think that's it for now. If anyone can spot problems with what I'm saying, do let me know :) Best regards, Peter. ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
