Hi Peter,
On 17-04-12 23:47, Peter wrote: > On 17 April 2012 20:59, Kristoff Bonne<[email protected]> wrote: >> O! There are actually people reading my website. Cool! :-) > Most definitely, in fact it was quite helpful in working out d-star's > layout. The official documentation is sketchy at best. So it was > easier for me to see a real implementation, and understand it than > look at the documentation. I try to do my part "demystifying" D-STAR and digital communication. :-) > >> I actually have code for a "gmskmodem" (which is the gmsk receiver and >> sender combined in one). I have posted it on github, but have not yet >> posted a blog article about it because it has a annoying bug processing >> "raw" streams which I have not been able to pin down. :-( >> > I actually saw that. Mode 3 as I remember seeing in the code for raw > processing. I was actually torn between using stdin/out, or using UDP > (which would allow running the modem remotely and the software > elsewhere. I'm thinking smartphone here, assuming codec2 could > eventually be implemented on a smartphone). (...) That was indeed the initial idea: the "raw" mode would accept any type of data so could be used for experimenting with a codec2-based system. (or any other system for that matter, why not a 4.8 kbps "data" mode for D-STAR); but it turned out not easy. I have a parrot for both "D-STAR" and "raw" mode, and I must say that it much more difficult to make the raw mode work correctly. That's I would prefer a version of the modem designed specially for codec2. > But, if D-Star is working fine, and another > application is not, it'd be one of those two issues, sync or too many > of the same bit, causing the problem. The bug is different. It's in the header. Using the "raw mode" parrot I do not get back a correct D-STAR header. The "D-STAR mode" parrot does work correct. The strange thing is that when I actually dump the bits I send to the gmsk modulator in a file, it indicates that the bittrain send to the modulator is 100 % the same. Really strange! :-( >> My proposal would be: >> - not to much different from D-STAR: sync, header, fixed size frames >> with DV, slow-data and a repeated "resync" pattern and a fixed "end" >> pattern >> - but different enough from D-STAR that existing D-STAR radio do not >> start spitting out R2D2 when they receive a codec2-based stream. > I will actually turn my preliminary ideas into a document and send a > link when I'm at a draft stage. Essentially I moved away from the idea > of a dedicated header format (which D-Star has) and moved to an idea > where the transmission was always broken down into 4 groups of 24 bits > (just like D-Star audio/data is). But that the first group is ALWAYS > data (rather than the last) and groups 2-4 could be data or voice. The > sync would take the place of the first (data) block. It would include > the unique sync for codec2 (20bits) plus, a bit pattern with a map of > data/voice groups. Of course we'd only every have all data or all > voice. But, I thought I'd make it open like that. 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. > In any case, so long as the sync pattern IS different from d-star, > both should ignore eachother. Of course there's always the chance (1 > in 16,777,216) that the pattern will appear in the actual > voice/otherwise sent data. But that's probably true for d-star > listening to other GMSK sources. Well, the specification say that you need first -at least- 64 times "01" and then the sync-pattern; so changes of that are much smaller. Even then, the header CRC-check will completely fail and as there is not valid sync-pattern every 21 frames; the stream will be killed of after 1 or 2 seconds. > This is also true. But the first implementation will often stick. (...) Yep. I hear somewhere that the choice of 32 bits for the IPv4 addresses went something like this: There was a discussion on the address-size to be 32, 64 or 128 bits, but somebody said "OK, we need have a demo-network really in a couple of weeks; let's first do this with 32 bit addresses and we will change the address-size later on". Only, the "later on" is taking a bit longer then expected. :-) >> I think, you can see I've thought a fair bit about this subject in the >> last month or so. No problem. take you time. Better a good spec to start with then having to change things to much later on. Write down your ideas and we can work from there on. 73 Kristoff - ON1ARF ------------------------------------------------------------------------------ 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
