Hi,
On 17-04-12 13:37, Peter wrote: > Hi all, > > I've seen on ON1ARF's page that his MSK code seems to be leaning > toward the possibility of use with codec2. I'd just like to put the > feelers out to find out if he/someone else is already working on an > implementation using codec2. I've had some ideas myself, but find it > pointless me moving forward with an implementation if someone else is > already doing so. It'd just lead to confusing competing standards. > Ideally it'd be nice if there was a single "open" standard along side > the D-Star standard already in existence. Not a fragmented number of > implementations. O! There are actually people reading my website. Cool! :-) 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 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. > The other point of interest is, in order to implement on VHF/UHF I'd > suggest the use of FEC in a similar way to D-Star today. By my (maybe > shoddy) calculations. If we use 4800 MSK (as per D-Star) and 1200 of > that for data/control. We're left with 3600, again just like D-Star. > The difference being that the bitrate of the actual codec is a bit > different. I don't think this is a problem though. > I think the layout could be similar to D-star in fact. With 2500 bps, > we work on 50 bits per frame. If we group blocks of 24 bits, into 4 > blocks (again like D-star) we get 96 bits. Minus 24 for data. Leaves > 72 (or 3 blocks of 24 bits). > This actually works quite well for FEC purposes. We have 2x23 bits (46 > bits) creating 2x12 bits of corrected data (24 bits) using golay2312. > Plus one block of unprotected 24 bits (48 bits) and 2 remaining > unprotected bits left over. 50 bits total. That's a nice perfect > matching for 72 bits in, 50 bits out (I like to think you guys were > aiming for this with the perfect block size/data rate for this outcome). All makes a lot of sence. > As for the MSK/C4FM argument. To me, it came down to the fact that > there is a software implementation of an MSK modem already. I think it > would really promote codec2 DV, if people could hook up their sound > card into their packet socket and "plug and play" so to speak with > maybe a simple circuit they can easily build. Sure hardware MSK modems > could also be used. But the home brew is where it matters. So I think > MSK is a good start. Also since we're using the same modem as D-star > does. It'd make it fairly easy to make a multimode system (using the > USB dongle for decoding/encoding D-star as an optional extra). Agree on the GMSK argument. Let's start with what we have and know. We can latter still add other modulation scemes. 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. Concerning the USB-dongle question. That would depend on the amound of CPU to burn in the microcontroller. > So, back to my original question really. Is someone else already > working on this? 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. 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. > Best regards, > Peter. Chééééério! Kr. Bonne ------------------------------------------------------------------------------ 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
