Hi Albert,
OK. With a couple of days delay. On 12-02-13 07:31, Albert Cahalan wrote: >> The first c2gmsk modem (the one as shown in the video) was designed to >> be a "quick hack", to provide a proof-of-concept that codec2 over >> VHF/UHF works and get some publicity. For that reason, its based on the >> code I had for the 4800 bps modem (for D-STAR) and a very basic FEC-system. >> >> After that, I started to work on making the modem "more then just a >> cheap copy of D-STAR", so that's why I started work on the 2400 bps >> modem, which is a bit more complex, implements scrambling, a bit more >> complex FEC, etc. > Why the change from 4800 to 2400? > > BTW, given the nature of distortion and interference, I have > to wonder if it might be good to send a wider signal with the > assumption that half of it might be destroyed. The receiver > could get just the low half, or just the high half, and be fine. Well, there where two reason: First, operating on 10 meter where a signal may not be wider then a simular AM signal (i.e. 6 Khz) (very limited bandwidth) But also the idea of "half the bandwith = half the noise". A 2400 bps signal should give us (in theory) a 3 db power gain over a 4800 bps signal. Anyway, a 4800 bps pipe for 1400 of voice is a kind of overkill. I had problems finding a good non-equal FEC system with a ratio even remotely in the region of 3.5 to 1. Most seams to be around 2/1. For the 4800 bps modem, I now use a simple 3/1 repetition code. It's pretty lame but -as explained- the goal at that point was to have something on the air. One of the ideas was to try to come up with an as good as possible FEC system for the 2400 bps modem and -for the 4800 bps modem- run a 1/2 convolutional code on top of that. If I read the theory correctly, this would give us about 2 to 2.5 db of gain, which would therefor roughly compensate for the 3 db gain loss of the double bandwidth. Anyway, the goal is to get code out there to allow people to experiment. There are a lot of people who have their own ideas about this, but the proof of the pudding is in the eating. So, I just wanted to have a tool to allow them to experiment. >> But based on the discussions here and some other lists, it did became >> clear that "ease of use" is an important element in the success of a >> codec so I have the intention to do that first. >> Later on, with the success of FreeDV, the idea came along to get the >> c2gmsk modem into that platform too. This means, to convert it into an API. > I've dealt with API and ABI issues before. It can get really awful. > If at all possible, avoid: > > structs with layout the caller can see > global data > the need for locking > non-public symbols showing up in an "nm -D foo.so" listing OK. I understand your point. However, as this is a project for the ham community; my problem will probably not be that people who want to bypass the API. It's usually more of an issue to find programmer to start with. :-) >> - creating a good UDP streaming-protocol between different parts of the >> application: e.g. between the audiotool (voice input/output) and the >> modem; but also -looking into the future- between a modem and a >> "repeater" or "reflector" service, or between a freeDV receiving station >> (acting as "webreceiver") and a remote listener. > UDP will hurt. > > You can do named pipes or shared memory, but IMHO that belongs > in higher-level code. The software modem itself ought to be purely > math, without any IO. The UDP streams are not for the modem itself, but for streaming between different applications. I use it between the "audiotool" (i.e. voice capture/playback + codec2 encoding/decoding) and the gmskmodem (gmsk modulation/demodulation + interfacing to radio). I wanted to have a design where these two elements can be done on two different devices if needed; say a RPI for voice in/out + codec2 and a AVR/PIC/cortex-M -based GMSK modem, or a RPI as add-on board for voice-encoding in combination with a Universal Digital Radio (John Hayes' project) as modem. For that purpose, I had to come up with the "c2enc" container-format for streaming codec2 over UDP because I needed some way to signal the beginning and the end of a stream. But, if we think of applications like listing to remote FreeDV receivers via the net, that format will surely not do. I like to see somebody come up with a proposal (and possible also implementation as a library :-) ) of a streaming-format for codec2 over UDP that will also work in a WAN enviroment. I think UDP-streaming is a key element if we want to make codec2 more then a "just DV on HF or VHF". 73 Kristoff - ON1ARF ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
