Hi David,
On 24-05-12 16:32, David Rowe wrote: > 3/ Re a side data channel I like the idea of dropping voice data frames > when we need to send some data. We tell codec2_dec() that the frame is > dropped and it just interpolates. On silence, background noise or > unvoiced frames I doubt anyone would notice. We would effectively get > enough bandwidth for call signs, routing, and even protocol information > for free. There is silence between each syllable when we talk. Do keep in mind that it does make sence to have a header in front. Certain information -like callsigns- are actually used to some device to make descisions on it. E.g. a repeater does routing based on information in the header. A radio can decide to open the squelch or not based on information in the header. If this information is not be in front of the stream itself, any application like that will need to implement buffering. So, I agree on the idea of using holes in the voice-stream to send -say- your GPS location, but certain information merrits to be put in front of the stream. In the end, we are talking about half duplex communication. If the listener starts hearing the decoded audio 0.5 seconds after then sender has pushed the PTT, or 0.7. I don't think this not the most critical issue here. :-) > 4/ Re protocol information, fwd and backward compatibility I think some > one a few years ago mentioned an Internet database for the many digital > data modes which seem to expand daily. Concerning backward compatibility, one of the things I like to add is the ability to automatically add a small fixed audio segment behind every transmission. This would allow people to put their callsign (in CW) in their so anybody (including the regulator) will be able to identify the source of this "weird digital transmission". This might be a legal safeguard for people who are experimenting with new (undocumented) digital modes and the legal obligation that hams must identify themselfs. > 5/ The sample rate of the sound card (say 48kHz) doesn't have to be an > integer multiple of the symbol rate. For example FDMDV already does > 1/160 symbol resolution re-sampling inside. Well, I don't know if this is an issue here, but I would like to try to make sure the modem also works on CPUs that do not have a FPU. (like the ARM9 in my mini2440). It would be nice to see that -at least- the modem part work on a board with -say- a ARM cortex M3 or a PIC32. > 6/ For FDMDV it proved possible to get fast sync without pre-ambles > (like 0101010... sequences at the start of bursts), this might be > possible with GMSK also, not sure. We did cheat with FDMDV and use a > high energy pilot tone. Well, for me, as long as the whole "pre-stream" process is finished in less then 0.5 seconds, I do not think this is a major issue for most people. > Cheers, > David Kristoff - ON1ARF ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
