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 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). The main issue with using data over a radio is sync. Hence you see in DSTAR that there is a sync pattern every 11 frame groups, and that the scrambler is used to ensure there aren't too many groups of 0 or 1's together which would lead to sync loss. So, not having seen your issue, I can't tell if that's the problem. 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. > I would greatly appriciate a discussion about a "container-format" > description for a codec2-based VHF/UHF system. > > I have been experimenting with a D-STAR "parrot" using the code, and I > must say that processing a stream with a known format (in the case of my > existing code, D-STAR) does have a number of big advantages over > processing "raw" streams. > > If the code knows knows what format to expect, this can really help to > make the receiver more robust; especially the parts dealing with > detecting the beginning of the stream and the end of the stream and > handeling "false-positives" of these. > > > So, yes, I would be greatly interested in this discussion. > > 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. As such, the header would in effect consist of the codec2 sync + 0000 (all data). Then a series of blocks (I'll call the 4x24 bit groups blocks) making up the header, with the same level of FEC/scrambling/interleave as a d-star header). After this has been sent, the codec2 sync + 0111 (1xdata 3xvoice) is sent. Then the voice will be sent, as I described + there is the option of sending slow speed data (like D-star does). If there is no data to send, the entire header data would be reproduced gradually in the data channel over a series of blocks (depending on the end decision of what goes in a header, as to how many). This will solve an issue which happens now with d-star. A radio right now can pick up the signal in the middle and start relaying it. I think repeaters do not recover if they miss the actual header. I've seen this happen a few times locally if I switch to input I hear the QSO, but the repeater just doesn't pick it up. But next time it's fine. So after a second or two since the whole header would have been recovered (in the absence of slow speed data) a repeater could actually recover from the missing header. It does pose an issue if slow speed data IS being sent too though, constantly. Maybe some kind of interleaving options are possible (1 series of blocks data, 1 series repeated header). I don't know. It's something to play with later I think. 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. The other flexibility allowing data only frames allows is, more protected repeater controls. By allowing within the standard full data and no voice transmissions, repeater operators/trustees could be given some form of encryption key to sign commands and so on, to the repeater over the air. They repeater could then also respond with data only with the status. > It would be pretty easy to have a different syncronisation-pattern for > GMSK based or C4FM based streams so that the receiver know beforehand > what to exact and how to demodulate the signal. This is also true. But the first implementation will often stick. D-star has a sync pattern for some form of PSK if I remember rightly. But, I've never seen it used in the wild. I'm also not convinced my Icom would know quite what to do with it, if it saw it. > Concerning the USB-dongle question. That would depend on the amound of > CPU to burn in the microcontroller. My thoughts for this was mainly for use in a purely software implementation. That is, people already using the d-star dongle in their PC online. They could plug into their radio and the same software for codec2 would be able to tx/rx codec2 and d-star. Provided the dongle was plugged in. If we're talking about hardware projects later. Well, it could get very complex. But, I wasn't thinking that far ahead just yet. > Well, the goal of the gmsk modem software was to allow experimenting > with this. > The goal is to split of the "modem" part from the voice/data encoding > part and to allow maximum flexibility. I think splitting it is still a good idea. Even more-so while codec2 is still evolving. It'd be better to have everything modular so things could be worked on separately and (while closing eyes and crossing fingers) all work when plugged in together. > But, in the end, a product like the DV-RPTR would be a better > end-product. The gmskmodem is -for me- an experimenting-tool and a way > to learn more about this and about DSP. I think that, and various other home-brew hardware options would take over. But, I think it'd all begin (and I think a lot of people would just actually use it too) with a software implementation, that pretty much anyone could use (that is able to wire up a cable to hook up their sound card, to their packet socket). I think, you can see I've thought a fair bit about this subject in the last month or so. ------------------------------------------------------------------------------ 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
