Hi Bruce,
On 29-11-11 19:28, Bruce Perens wrote: >> But let's be honest. Most of the points above are still open. >> Somebody will have to take the lead in this; somebody with experience >> with organising such things. (perhaps somebody not to technical, so he >> or she can focus on the organisation aspects!) >> > It's important not to do all the work. The most successful smartphones > are the open platforms where the apps come from third parties. True, however key to having good application is to have a good foundation to start from. Currently, for codec2, there is the codec (which is very good quality), we have demo code and we have the -since a couple of days- an API. A good DV system needs much more then that. It needs shared knowledge on the individuel elements of a DV system, it needs people who provide ideas, people who do experimenting to test these ideas and it needs people to implement these ideas. The development of the FEC system requires knowledge of codec2 to know what bits are very important and what are less important. The format description then to be adapted to allow the people who write the software for the receivers better deal with syncronisation issues. Quite a number of parts of a DV system are actually dependent on eachother. > How about > making a general-purpose mobile/handheld SDR platform, and let the soft > modems, FEC, modulation, codecs, and applications develop as they will. Wait. For us, to start with experimenting, we do not need a SDR platform. I now have software that turns a ARM board (like a mini2440 or a pandaboard) into a GMSK receiver (if connected to a 9k6 port of a radio). Next step is the sender, but that is supposted to be easier. The kit Jan has designed allow pretty much the same thing (but is a bit more profesional then my stuff. :-) ) and works with any PC. It is not really difficult to start playing around new: make one radio stream transmit a GMSK stream continuesly and use a 2nd radio in a car to receive: drive around town, connect the radio to (say) a pandaboard or a PC, dump the received stream to a flashcard and analysis its BER and MOS afterwards. So we already have a good basis for tools to start experimenting. The question now is "what do we want to experiment with?" I think everything related to error (FEC, scrambling, interleaving, but also syncronisation) would be a nice thing to try out. But I'm still waiting for somebody to take the first step in this. > Thanks > Bruce 73 Kristoff - ON1ARF ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
