Hi Matthew,
On 29-11-11 15:58, n8...@yahoo.com wrote: > I agree and disagree; I agree that it's not our responsibility to modify the > equipment of end users that are "locked" into a specific mode, but I disagree > that we should ignore them entirely, based on a preference for an open DV > system. I would much rather see a piece of hardware that was able to support > the existing system as well as be upgradable in software to support new > ideas, which is why I brought up working with the protocol developers and one > existing hardware manufacturer to begin with. Is it me, but aren't we going a but fast here? I do have the impression that some people are taking the step from "having codec2" to "replacing D-STAR with something new" quite fast. Do do have a number of things missing: - choice of additional radio-technology elements (FEC, scrambling, interleaving, sync-recuperation, headerframe construction, futur options, ...) - a formal description of the protocols - test code and test hardware - analysis of actual results of people test-driving the software and hardware.: Has everbody even made tests codec2 responds to packetloss? How well does the FEC system work? Does the interleaving-system work well and can it be made better? - interoperability testing with other DV-users (read: "does it not crash D-STAR radios) - infrastructure software implementation (repeaters, reflectors, PC clients, ...) - tests of actual "production ready" hardware for this (how much CPU power does a board need? Do we forsee additional CPUâ»power in be able to add new features later) - programming APIs - and -most importantly- how do make sure the hardware sollution for this can be manufactored and sold in tens or hunders of thousands, not just a couple of hunderd now and then. We have now come to a point where it becomes possible to actually "play around" and experiment with GMSK streams quite easily on open hardware platforms or just any PC. This allows us to gain experience on radio-communication, learn from existing systems, and -from there on- determine how to implement a codec2-based solution. 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!) > Matthew Pitts > N8OHU 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
