Hi Albert,
On 14-02-13 08:21, Albert Cahalan wrote:
>>> 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)
> Uh, country? Here in the USA a mode may be illegal due to
> not being explicitly listed, but there generally isn't a bandwidth
> limit to be concerned about. (though waste is rude)
The IARU-R1 banplan explicitally mentions 6 Khz maximum bandwidth for
the 10 meter band.
I don't know the legislation in the US, but I know that here in Belgium
(and most countries in region 1), there is perfectly legal to use GMSK
DV on 29 MHz (actually 29.2 - 29.3 Mhz here in region 1) ; especially if
you manage to keep the bandwidth down to some 3.5 to 4 Khz.
>> 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.
> This is why I wrote "given the nature of...". We aren't facing
> white noise from DC to light. IMHO, it looks like chunks of
> your signal get blown to bits while other chunks go unscathed.
Well, the thing with discussing choices for digital modes, is that is
usually goes like that:
- if we concider situation X, then solution A would clearly be much
better then solution B
- however, if you then look at situation Y, solution B is clearly the
winner and A would really suck!
- ... but, let's now look at situation Z, .. then neither A or B would
be good, so ...
- yes ... but ...
- OK ... however ...
- (etc) (etc)
In the end, there is only one correct answer to this: "Stop discussing,
get on your radio / radio-simulator, and try it out!" :-)
However, this is one small problems: for that, you need applications!
And you need code!
So, for me ... the conclussion is simple: first step, ... make sure the
code is out there!
> If you have a struct in the ABI, you can never change the layout.
> You can't change a member from int to long, you can't add a member,
> you can't remove a member that has become useless and annoying, etc.
> If you do any of these things, the apps will all crash.
Well, I have it difficult enought to create an API. At this point, I
will not even start to think about an ABI. :-)
> If you have global data, then you need locking. As a library author
> you have no idea how this might interfere with the library users.
> The users may wish to run numerous instances of your codec.
> They might run one codec per thread. They might only have a
> single thread, but want to handle multiple streams of data via
> functions like select, poll, pselect, ppoll, epoll, WaitForMultipleObjects,
> or the kqueue stuff. They may want to run 2 instances of your
> codec in a 5-thread process, with 3 threads running the codec.
> Your library should not restrict these choices.
There is no global data.
Before you want to use the API, you need to create a "session", and all
static data for that session is stored in the datastructure associated
with that session.
I've taken the example of how David has created the library for codec2.
You also need to "codec2_create" before you can use the library.
>> 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).
> It looks like you are reinventing network audio. Even if you aren't,
> this sort of thing still belongs at a higher level. It isn't fundamental
> to running the modem or codec.
True, and it isn't for the modem or the API.
On unix/posix c2gmsk has three layers:
- the API: convert codec2 from/to GMSK-modulated audio stream
- "c2gmskmodem": one application that handles codec2-over-UDP streaming,
input/output audio from/to the radio and PTT switching of the radio
- the c2gmsk package: the c2gmskmodem + the "audiotool" (voice
input/output, codec2 encoding/decoding, user "pushes PTT" detection)
On a windows, it should look like this:
- the API
- an additional wrapper around the API to include codec2
encoding/decoding. The goal is to make the API look simular to the
fdmdv2 API now used by freeDV
- FreeDV
You are correct. The UDP streaming-layer layer is only part of the 3th
layer where multiple applications need to talk to eachother. It is not
part of the modem or the codec.
>> 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 the IAX2 protocol should do, hmmm? It's just VoIP after all.
Well, as said, the protocol should work both in a WAN enviroment ... but
should also be simple enough to work on (say) an AVR/PIC based
modemboard. So ... "keep it simple" !!!!
In essence, what we need is a protocol that:
- should be able to carry all information we can expect to see on a
codec2-based DV system (voice, header, data, ongoing call statistics,
hardware-interfacing information ("PTT is pushed", "squelchs is open"), ...
- should be able to work in a "WAN" enviroment (jitter, packetloss,
out-of-order packets, ...)
- but should also be very simple when no "WAN" features are needed.
(think "microcontrollers")
Perhaps a protocol with two profiles: "local" and "WAN".
The FreeDV enviroment has already been expanded with the QSO finder John
created. This really shows the power of open source and the ham community.
If we think what is possible when we extend the codec2 DV ecosystem with
application that actually transport voice; we can expect some very nice
things. And .. for that, a codec2 UDP-streaming standard would be a good
start.
So, if you are interested, feel free to draw up a proposal and post it
so we can discuss it.
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
