Hello Albert,
On 14-04-13 05:48, Albert Cahalan wrote:
> Both signals are mono, so they can fit on a single stereo device. One
> gets the left, and the other gets the right. This means you don't need
> to power two devices and have room for two devices.
The goal first is to have something that works. In the end, it would be
more interesting to build this all into a addon board for the RPi /
beaglebone / pcduino / whatever-board-may-exist-in-the-future.
But, first create something that works so that real life tests can be
done with it in real enviroments, next to testing new versions of the
protocol via simulations.
> Uh, shift the signal upward?
Increasing the frequency of the signal would also increase its
bandwidth, which is the opposite we want to do.
> Make an approved hardware list?
That's something for the community to do, not for me. :-)
>
>>> The comment about the modem output itself driving the circuit
>>> is interesting.
>> True, as said, feel free to implement it and upload the code to github.
>>
>>> That would seem to take away any ability to
>>> adjust relative timing, but maybe there could be a preamble.
>> I don't understand this. What exactly do you mean by this?
> The radio will not switch instantly. You may want to trigger it
> some amount of time (configurable) before sending any data.
Something like this?
--- cut here --- cut here --- cut here --- cut here ---
if (*c2encap_type == C2ENCAP_MARK_BEGIN)
(...)
{
// received start
// queue silence
bufferfill_silence(pglobal->silencebegin,pglobal);
// API call to initiate C2GMSK stream, return one or more audio blocks
ret=c2gmsk_mod_start(pglobal->c2gmsksessid,c2gmsk_pchain);
(...)
--- cut here --- cut here --- cut here --- cut here ---
(see "netin_mod_audioout.h" in the gmskmodem package. This is part of
the function that receives the c2encap stream (codec2 stream
encapsulated in UDP) and processes is. This is (part of) the code
executed when a "start of stream" is received.
The trick is pretty simple.
- You queue audio into a ringbuffer (in this case, first silence, then
the modulated GMSK stream of the preemble) to be used by the portaudio
"callback" function (this is a function that is called automatically
every 40 ms by the audio layer).
- The callback function sees there is audio in the queue, and -if there
is sufficient of it- it starts sending it to the audio-device (in
packages of 40 ms). At the same time, it sets a global variable called
"transmitptt"
- This "transmitptt" flag is picked up by the "ptt_gpio" thread, a piece
of code that runs parallel to the main application. That code will
switch the GPIO-pin that drives the PTT of the radio.
> Triggering too early means garbage on the air, while triggering
> too late means that parts of the transmission go missing.
There is no "garbage" on the air as even before the PTT is switched, the
audio-device is fed with "silence" frames. Now, even if there was,
that's not an issue as the demodulator on the other side with ignore
everything that comes in that does not look like a valid syncronisation
pattern.
> Triggering via the same audio device used for transmit will
> at least get you close. This is because the transmitted data
> and the triggering signal are affected by the same sound
> card (USB device) latency.
Concidering 99 % of the VHF/UHF DV traffic runs over repeaters and
repeater-networks, "delay" is not an issue. On repeater-networks, delays
over several seconds are normal.
The tests I did today arrived at a delay between the audio entering one
side (the mic of the 1st raspi) and that exiting the other side (the
loudspeaker on the 2nd RPi) as 1.2 seconds.
I think I might get the delay to around 1 second, but that will be the
minimum.
Anycase, for me, this is a secundairy issue. I have other priorities
first (like the 2400 bps modem and a new version for the 4800 modem with
better FEC).
73
Kristoff - ON1ARF
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
