> 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. > 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 I think the FreeType project sets a pretty decent example. > - 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. > BTW. I did notice the GNUradio modules are written in python. Another > language to learn. :-) GNUradio is therefore in deep trouble. Python has terrible threading problems and a roughly 100x performance hit. I would be surprised if it doesn't also have real-time issues involving garbage collection. ------------------------------------------------------------------------------ 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
