Hi David,
On 01-11-11 20:42, David Rowe wrote: > OK - so you are suggesting we could test a Codec 2 Digital Voice mode > over using DSTAR in data mode? Hmmm, interesting. First of all, this is just an idea. It's just that, while I am working on building a D-STAR node on this mini2440 board (based on open source software), this would allow people to experiment with Digital Voice, even for modes that are not D-STAR. (I know this is a bit dangerous discussion as there are some people who think that other (non-D-STAR compatible) DV modes would hinder the further growth of D-STAR. I understand their concerning, but I do like people to be able to experiment). Anycase, for the record. Running on D-STAR is -as far as I see it- not possible; for two reason: - Using codec2 in the "DV" (digital voice) mode is incompatible with the D-STAR specification. These explicitally say "D-STAR uses AMBE". - Using codec2 on the DD (Digital data) part of D-STAR would be possible; but is difficult. D-STAR DD are actually data-frames encapsulated in an ethernet-frames (up to 1500 octets in size). So, either you encapsulate relative few codec2 frames in an ethernet-frame; but then the overhead would be quite large Either you encapsulate multiple sequencial codec2 in an ethernet-frame; but then you have issues with delay and dealing with packetloss. So what I want to experiment is creating a DV-mode (NOT D-STAR and called D-STAR), using roughly the frame-structure of DV D-STAR; but on purpose NOT compatible with it. (e.g. by inverting all the bits in the field-check error part of the header or using a different scrambling system or something like that) The goal is to make sure that D-STAR radios do ignore these streams and not try to decode it (I do not want to have angry D-STAR people tell me I crashed their radio because the firmware tried to decode the stream and crashed on it. :-) ) > Couple of possibilities. I guess people with DSTAR radios already have > an interest in DV. So I guess anyone with a DSTAR radio and a laptop > could then start using Codec 2 over the air. Everybody with a radio that has a 9K6 data-port and some kind of "computer" should be able to use this. (just like you can use a PC with a sound-card modem or a gmsk modem now already be used to make a D-STAR compatible radio). > Then there is the approach you are using to run the "open" parts of > DSTAR on a PC, integrated with Codec 2 and possibly on a low cost > embedded board. Nice. Correct. In my case, I want to experiment with the different kinds of boards (usually ARM-based boards) that exist out there (friendlyarm, beagleboard, pandaboard, foxboard, hawkboard, ...). These are small, use little power, are quite powerfull and have a lot of expansion ports (USB, ethernet, wifi, bluetooth). I guess these could be usefull for all kind of ham applications. In my case, I'm now using a friendlyarm mini2440 board (which has a ARM920T) for this. This CPU does not have a FPU but I did manage to convert the gmsk encoder/decoder DSP routines to have it run on integers. I now have mine (at this very own moment) running now as a "D-STAR" receiver, using just a USB sound-dongle, on the 9K6 port of my yaesu857. (this is still "alpha" code). (It's the dutch D-STAR net on reflecter REF017A, so it's a good testbed for this. :-) ) As I am now writing the code for this (as open source), it would be possible to use this board for -say- non-audio D-STAR applications (a D-RATS terminal, D-PRS, ...); ... or to use it to experiment with other "non-standard" modes. (like DD on 2 m or 70 cm "DV" channels, or ... codec2) > A good start for adding FEC to Codec 2 is to test the effect of bit > errors on each bit. Not all bits need protection. So strong codes can > be used to protect the most sensitive bits, leaving some bits > unprotected. Are there drawings or scematics of the exact bitformat of a codec2 stream, explaining the meaning and importance of all parts? > Or if we have a big enough overhead, just use a rate 1/2 > code but we will perhaps need to watch delay with some codes. For DV over radio, delay is not the main issue. It's half-duplex anyway. :-) So, what FEC protocol do you propose? Are there 1/2 FEC protocols out there that are not patented? > A way to test bit-error sensitivity is to apply bit errors to each bit > and evaluate the results, either subjectively (listening) or objectively > (e.g. look at the SNR measure with errors in the LSP bits). True. That's probably also where these small board come in handy: easy to install in a car and do real tests in more difficult enviroments. > Re fixed point port - a first step is to profile Codec 2 on a fixed > point CPU. On a modern (500MHz) CPU we might find that just a few > chunks of Codec 2 need to be ported to fixed point to get it running in > real time. Well, to give you an idea. The mini2440 has a ARM920T. The gmsk demodulation does 103 multiply-and-add per audio-sample (sampling at 48000 Khz). This eats about 20 to 25 % of the total amount of CPU-power. On this kind of processor, a 16 * 32 bit integer operations uses 2 clock-cycles. > Cheers, > David 73 Kristoff - ON1ARF ------------------------------------------------------------------------------ RSA® Conference 2012 Save $700 by Nov 18 Register now! http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
