Discussion:
[Freetel-codec2] Legacy modems
Adrian Musceac
2016-03-08 19:37:18 UTC
Permalink
Hi all,

Motivated by David's work with VHF modems, I have started to
investigate various Tx-Rx chains that might work with legacy narrow FM
radios. My goal is to develop a completely portable system composed of
a development board running open-source software paired with an FM
transceiver. The Linux board could be any ARM board capable of running
a supported Linux distribution and providing a decent interface to a
7-9 inch LCD screen with touch controller. My setup is fully described
in a Youtube video I mentioned before.

At the moment I have all the hardware components available and have
run the first tests on the air. The software was first based on
Kristoff's Codec2-GMSK modem and a Qt user interface designed by me.
Although it had worked fine, it required a radio with a data port,
which meant portable ops were restricted to a very narrow list of
handheld radios.

Since then, I thought of using the huge power of the Gnuradio
ecosystem to design my own modems that could go through the audio
passband of a handheld. I have learned many things during this
process, especially that I can very quickly prototype and test a modem
without going too deep in the maths, which has never been my strong
point.

My findings are somewhat surprising: I can use any of the modems over
a narrow FM channel, but there are a few which perform well enough for
my purposes.
Considering a RF chain composed of one laptop running Gnuradio, one
Yaesu handheld, one Yaesu mobile transceiver and one Linux board with
soundcard ports also running Gnuradio, here is the performance of my
modems in descending order:
1. DBPSK (~10 dB S/N)
2. DQPSK ( ~12 dB S/N)
3. GMSK (~14 dB S/N)
4. 4FSK (~15 dB S/N)
6. AFSK (~16 dB S/N)

I am especially fond of the GMSK modem which gives me 2 kbit/sec with
a reasonable SNR.

Since I have full control over the modems, I can select the signal
width, samples per second and tone frequencies in such a way that they
provide the maximum bitrate for a bandwidth limited to 300 Hz - 3 kHz.
Now that I have some real results, I am thinking of starting to move
the modems to C++ space and integrate them with the Qt GUI application
destined to run on the Linux board. This application will be based on
qradiolink v0.2 and will have support for VOIP via the 2.4 GHz WiFi on
board, enabling the station to be quickly transformed into a portable
repeater.

You can find my test modems on Github if you want to play with them:
https://github.com/kantooon/gnuradio_audio_modems

Obviously David's modem will probably be more robust and performant,
however I am providing a huge selection of GRC graphs here :)

Cheers,
Adrian (YO8RZZ)
David Rowe
2016-03-08 21:07:18 UTC
Permalink
Hi Adrian,

Great work - you should write it up (or YouTube). What noise (channel)
bandwidth are your SNRs measured in? Are all the modems tested below
measured using the same bit rate?

That's why Eb/No is useful - it's normalized to a bandwidth of 1Hz and
bit rate of 1 bit/s. It's like the "SNR of one bit".

How does analog FM sound at the same SNR?

I also found AFSK over FM to be particularly bad:

http://www.rowetel.com/blog/?p=3799

Getting modems to work over FM analog modems is an interesting area.
Brady is getting good results from manchester encoder symbols. I guess
that's putting BPSK over analog FM, it's a pulse train of +ve and -ve.
In our simulations it's only 2dB off 2FSK which is surprising (or
suspicious!).

Looks a lot like the GMSK modem Kristoff uses, but the manchester
encoding moves the energy away from DC, so a "data mode" radio is not rqd.

Cheers,

David
Post by Adrian Musceac
Hi all,
Motivated by David's work with VHF modems, I have started to
investigate various Tx-Rx chains that might work with legacy narrow FM
radios. My goal is to develop a completely portable system composed of
a development board running open-source software paired with an FM
transceiver. The Linux board could be any ARM board capable of running
a supported Linux distribution and providing a decent interface to a
7-9 inch LCD screen with touch controller. My setup is fully described
in a Youtube video I mentioned before.
At the moment I have all the hardware components available and have
run the first tests on the air. The software was first based on
Kristoff's Codec2-GMSK modem and a Qt user interface designed by me.
Although it had worked fine, it required a radio with a data port,
which meant portable ops were restricted to a very narrow list of
handheld radios.
Since then, I thought of using the huge power of the Gnuradio
ecosystem to design my own modems that could go through the audio
passband of a handheld. I have learned many things during this
process, especially that I can very quickly prototype and test a modem
without going too deep in the maths, which has never been my strong
point.
My findings are somewhat surprising: I can use any of the modems over
a narrow FM channel, but there are a few which perform well enough for
my purposes.
Considering a RF chain composed of one laptop running Gnuradio, one
Yaesu handheld, one Yaesu mobile transceiver and one Linux board with
soundcard ports also running Gnuradio, here is the performance of my
1. DBPSK (~10 dB S/N)
2. DQPSK ( ~12 dB S/N)
3. GMSK (~14 dB S/N)
4. 4FSK (~15 dB S/N)
6. AFSK (~16 dB S/N)
I am especially fond of the GMSK modem which gives me 2 kbit/sec with
a reasonable SNR.
Since I have full control over the modems, I can select the signal
width, samples per second and tone frequencies in such a way that they
provide the maximum bitrate for a bandwidth limited to 300 Hz - 3 kHz.
Now that I have some real results, I am thinking of starting to move
the modems to C++ space and integrate them with the Qt GUI application
destined to run on the Linux board. This application will be based on
qradiolink v0.2 and will have support for VOIP via the 2.4 GHz WiFi on
board, enabling the station to be quickly transformed into a portable
repeater.
https://github.com/kantooon/gnuradio_audio_modems
Obviously David's modem will probably be more robust and performant,
however I am providing a huge selection of GRC graphs here :)
Cheers,
Adrian (YO8RZZ)
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Adrian Musceac
2016-03-08 22:12:30 UTC
Permalink
Hi David,

To answer your questions, I am measuring SNR at the same bitrate for
all modems (1200 bit/sec) using the AWGN channel model that is
available in Gnuradio. I'm afraid my math is a bit iffy, so the
figures should be taken with a grain of salt.

However, for practical purposes, I settled on the following
modem/bitrate combinations:
DBPSK 1200 - best low signal modem
GMSK 2000 - average modem
DQPSK 4000 - about the same performance as GMSK 2000

I intend to code logic to switch between them as needed, depending on
the quality of the channel and the amount of data to be transfered.

Performance is below analog FM by about 8 dB in the best case
scenario. However the data capability and the fact that we can use a
cheap handheld wins here. I believe these digital waveform might also
pass undisturbed through a repeater as well.

I will make a video and upload it to Youtube, to demonstrate my setup.
Real mobile performance data would be nice, but I have yet to finish a
suitable case for my board+LCD+battery contraption. Also the software
is still in the infancy.

Cheers,
Adrian (YO8RZZ)
Post by David Rowe
Hi Adrian,
Great work - you should write it up (or YouTube). What noise (channel)
bandwidth are your SNRs measured in? Are all the modems tested below
measured using the same bit rate?
That's why Eb/No is useful - it's normalized to a bandwidth of 1Hz and
bit rate of 1 bit/s. It's like the "SNR of one bit".
How does analog FM sound at the same SNR?
http://www.rowetel.com/blog/?p=3799
Getting modems to work over FM analog modems is an interesting area.
Brady is getting good results from manchester encoder symbols. I guess
that's putting BPSK over analog FM, it's a pulse train of +ve and -ve.
In our simulations it's only 2dB off 2FSK which is surprising (or
suspicious!).
Looks a lot like the GMSK modem Kristoff uses, but the manchester
encoding moves the energy away from DC, so a "data mode" radio is not rqd.
Cheers,
David
Post by Adrian Musceac
Hi all,
Motivated by David's work with VHF modems, I have started to
investigate various Tx-Rx chains that might work with legacy narrow FM
radios. My goal is to develop a completely portable system composed of
a development board running open-source software paired with an FM
transceiver. The Linux board could be any ARM board capable of running
a supported Linux distribution and providing a decent interface to a
7-9 inch LCD screen with touch controller. My setup is fully described
in a Youtube video I mentioned before.
At the moment I have all the hardware components available and have
run the first tests on the air. The software was first based on
Kristoff's Codec2-GMSK modem and a Qt user interface designed by me.
Although it had worked fine, it required a radio with a data port,
which meant portable ops were restricted to a very narrow list of
handheld radios.
Since then, I thought of using the huge power of the Gnuradio
ecosystem to design my own modems that could go through the audio
passband of a handheld. I have learned many things during this
process, especially that I can very quickly prototype and test a modem
without going too deep in the maths, which has never been my strong
point.
My findings are somewhat surprising: I can use any of the modems over
a narrow FM channel, but there are a few which perform well enough for
my purposes.
Considering a RF chain composed of one laptop running Gnuradio, one
Yaesu handheld, one Yaesu mobile transceiver and one Linux board with
soundcard ports also running Gnuradio, here is the performance of my
1. DBPSK (~10 dB S/N)
2. DQPSK ( ~12 dB S/N)
3. GMSK (~14 dB S/N)
4. 4FSK (~15 dB S/N)
6. AFSK (~16 dB S/N)
I am especially fond of the GMSK modem which gives me 2 kbit/sec with
a reasonable SNR.
Since I have full control over the modems, I can select the signal
width, samples per second and tone frequencies in such a way that they
provide the maximum bitrate for a bandwidth limited to 300 Hz - 3 kHz.
Now that I have some real results, I am thinking of starting to move
the modems to C++ space and integrate them with the Qt GUI application
destined to run on the Linux board. This application will be based on
qradiolink v0.2 and will have support for VOIP via the 2.4 GHz WiFi on
board, enabling the station to be quickly transformed into a portable
repeater.
https://github.com/kantooon/gnuradio_audio_modems
Obviously David's modem will probably be more robust and performant,
however I am providing a huge selection of GRC graphs here :)
Cheers,
Adrian (YO8RZZ)
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Steve
2016-03-08 22:31:52 UTC
Permalink
The thing is though, that all these modulations are on top of FM. Get
rid of FM, and now you have a real chance of bringing VHF into the
21st century.

What the hobby needs is a 2 Watt $200 AM VHF (136-150) transceiver.
The AMP makers will follow :-)

If you build a new FM radio, 99% of the hobby will just yawn.

Don't shoot the messenger :-) I'm just an old man on the way out.
David Rowe
2016-03-08 22:52:16 UTC
Permalink
I agree Steve, hence the SM2000. Plus a legacy mode as the idea of DV
over a $40 HT is too hard to resist :-)

- David
Post by Steve
The thing is though, that all these modulations are on top of FM. Get
rid of FM, and now you have a real chance of bringing VHF into the
21st century.
What the hobby needs is a 2 Watt $200 AM VHF (136-150) transceiver.
The AMP makers will follow :-)
If you build a new FM radio, 99% of the hobby will just yawn.
Don't shoot the messenger :-) I'm just an old man on the way out.
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Brady O'Brien
2016-03-08 22:42:37 UTC
Permalink
Hi Adrian,

Just for completeness, the modem we are planning on using for
FreeDV-over-analog-FM, is more like ASK+Manchester Encoding over FM. We're
calling it FMFSK or MEFSK because it ends up looking like a dirty FSK over
the air. The mod works by Manchester encoding the bits and firing them over
the radio. The demod is a bit more complex. It can be examined in
octave/fmfsk.m and src/fmfsk.c . Like the other FreeDV modems, neither of
those have been wrapped up as modules for Gnuradio, but it shouldn't be too
difficult.

Thanks,

Brady O'Brien
Post by Adrian Musceac
Hi David,
To answer your questions, I am measuring SNR at the same bitrate for
all modems (1200 bit/sec) using the AWGN channel model that is
available in Gnuradio. I'm afraid my math is a bit iffy, so the
figures should be taken with a grain of salt.
However, for practical purposes, I settled on the following
DBPSK 1200 - best low signal modem
GMSK 2000 - average modem
DQPSK 4000 - about the same performance as GMSK 2000
I intend to code logic to switch between them as needed, depending on
the quality of the channel and the amount of data to be transfered.
Performance is below analog FM by about 8 dB in the best case
scenario. However the data capability and the fact that we can use a
cheap handheld wins here. I believe these digital waveform might also
pass undisturbed through a repeater as well.
I will make a video and upload it to Youtube, to demonstrate my setup.
Real mobile performance data would be nice, but I have yet to finish a
suitable case for my board+LCD+battery contraption. Also the software
is still in the infancy.
Cheers,
Adrian (YO8RZZ)
Post by David Rowe
Hi Adrian,
Great work - you should write it up (or YouTube). What noise (channel)
bandwidth are your SNRs measured in? Are all the modems tested below
measured using the same bit rate?
That's why Eb/No is useful - it's normalized to a bandwidth of 1Hz and
bit rate of 1 bit/s. It's like the "SNR of one bit".
How does analog FM sound at the same SNR?
http://www.rowetel.com/blog/?p=3799
Getting modems to work over FM analog modems is an interesting area.
Brady is getting good results from manchester encoder symbols. I guess
that's putting BPSK over analog FM, it's a pulse train of +ve and -ve.
In our simulations it's only 2dB off 2FSK which is surprising (or
suspicious!).
Looks a lot like the GMSK modem Kristoff uses, but the manchester
encoding moves the energy away from DC, so a "data mode" radio is not
rqd.
Post by David Rowe
Cheers,
David
Post by Adrian Musceac
Hi all,
Motivated by David's work with VHF modems, I have started to
investigate various Tx-Rx chains that might work with legacy narrow FM
radios. My goal is to develop a completely portable system composed of
a development board running open-source software paired with an FM
transceiver. The Linux board could be any ARM board capable of running
a supported Linux distribution and providing a decent interface to a
7-9 inch LCD screen with touch controller. My setup is fully described
in a Youtube video I mentioned before.
At the moment I have all the hardware components available and have
run the first tests on the air. The software was first based on
Kristoff's Codec2-GMSK modem and a Qt user interface designed by me.
Although it had worked fine, it required a radio with a data port,
which meant portable ops were restricted to a very narrow list of
handheld radios.
Since then, I thought of using the huge power of the Gnuradio
ecosystem to design my own modems that could go through the audio
passband of a handheld. I have learned many things during this
process, especially that I can very quickly prototype and test a modem
without going too deep in the maths, which has never been my strong
point.
My findings are somewhat surprising: I can use any of the modems over
a narrow FM channel, but there are a few which perform well enough for
my purposes.
Considering a RF chain composed of one laptop running Gnuradio, one
Yaesu handheld, one Yaesu mobile transceiver and one Linux board with
soundcard ports also running Gnuradio, here is the performance of my
1. DBPSK (~10 dB S/N)
2. DQPSK ( ~12 dB S/N)
3. GMSK (~14 dB S/N)
4. 4FSK (~15 dB S/N)
6. AFSK (~16 dB S/N)
I am especially fond of the GMSK modem which gives me 2 kbit/sec with
a reasonable SNR.
Since I have full control over the modems, I can select the signal
width, samples per second and tone frequencies in such a way that they
provide the maximum bitrate for a bandwidth limited to 300 Hz - 3 kHz.
Now that I have some real results, I am thinking of starting to move
the modems to C++ space and integrate them with the Qt GUI application
destined to run on the Linux board. This application will be based on
qradiolink v0.2 and will have support for VOIP via the 2.4 GHz WiFi on
board, enabling the station to be quickly transformed into a portable
repeater.
https://github.com/kantooon/gnuradio_audio_modems
Obviously David's modem will probably be more robust and performant,
however I am providing a huge selection of GRC graphs here :)
Cheers,
Adrian (YO8RZZ)
------------------------------------------------------------------------------
Post by David Rowe
Post by Adrian Musceac
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
Post by David Rowe
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
glen english
2016-03-11 01:05:52 UTC
Permalink
Hi ALl
I am just putting the finishing touches on a PCB before it goes to the
fab house. I am about to seal the edges and put the tooling strips on.

The PCB is designed for linking by a codec2 , link for analog
repeaters, using standard FM radios (mic or 'packet' input). IE it
takes in audio from the repeater, turns it into codec2 3200 bps (or
higher) and sends it on the link. and vica-versa. It also turns around
the local audio for TX and functions as a basic rpt controller with ID,
TO etc

Any last requests ? Note the board is SIMPLE, and your request might not
get on there. I am sticking very tightly to a complexity limit so it can
be built for < $30.

It has currently :
Cortex M7 with USB and JTAG .

some opto I/O for obvious things like PTTs and signalling inputs.

switched mode / linear regulator + Vin monitor.

some unused ADC inputs hooked up for I dunno what in the future..

analog input for discriminator output (analog repeater ) (so it can do
things like measure SNR)
with 5 section Cauer filter.

analog input for discriminator output (analog radio for digital link)
with 5 section Cauer filter.

and two DAC outputs ( 3 section cauer filters) for the audio outs for
the repeater and the link radio.

there is a 'gang' SPI interface so that two or more boards can share
data/audio in the future.

anything else ?
Steve
2016-03-11 20:22:43 UTC
Permalink
I always like a board that has regulated 3v and 5v on either pins, or
a nice big solder point.

You always think of something later and then have to use small
wire-wrap wire and find a teensy pin somewhere.

And I always like boards with a jumper to disable all the LED's.

I have this ADS-B receiver that has 7 LED's that can light-up a whole
room! Some wire cutters solved that problem :-)

73, Steve
Post by glen english
Hi ALl
I am just putting the finishing touches on a PCB before it goes to the
fab house. I am about to seal the edges and put the tooling strips on.
The PCB is designed for linking by a codec2 , link for analog
repeaters, using standard FM radios (mic or 'packet' input). IE it
takes in audio from the repeater, turns it into codec2 3200 bps (or
higher) and sends it on the link. and vica-versa. It also turns around
the local audio for TX and functions as a basic rpt controller with ID,
TO etc
Any last requests ? Note the board is SIMPLE, and your request might not
get on there. I am sticking very tightly to a complexity limit so it can
be built for < $30.
Cortex M7 with USB and JTAG .
some opto I/O for obvious things like PTTs and signalling inputs.
switched mode / linear regulator + Vin monitor.
some unused ADC inputs hooked up for I dunno what in the future..
analog input for discriminator output (analog repeater ) (so it can do
things like measure SNR)
with 5 section Cauer filter.
analog input for discriminator output (analog radio for digital link)
with 5 section Cauer filter.
and two DAC outputs ( 3 section cauer filters) for the audio outs for
the repeater and the link radio.
there is a 'gang' SPI interface so that two or more boards can share
data/audio in the future.
anything else ?
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
glen english
2016-03-11 22:16:39 UTC
Permalink
OK I will put the volts on some 0.1" pins .

As for LEDs.. I only run my LEDS at 1mA...

I've also put on the board a jumper for some extra gain on the analog
side input (say low level FM detector output?) and a jumper for powering
an electret mic (from a headset) so it can do a SM1000 sort of job,
also. I've got 8 LEDS so the op can see what is going on, and a header
leading to those LEDS so you can get a scope probe onto th LED pins as
debug pins so you dont have to solder wire wrap wire onto the LEDs...



cheers
Post by Steve
I always like a board that has regulated 3v and 5v on either pins, or
a nice big solder point.
You always think of something later and then have to use small
wire-wrap wire and find a teensy pin somewhere.
And I always like boards with a jumper to disable all the LED's.
I have this ADS-B receiver that has 7 LED's that can light-up a whole
room! Some wire cutters solved that problem :-)
73, Steve
Post by glen english
Hi ALl
I am just putting the finishing touches on a PCB before it goes to the
fab house. I am about to seal the edges and put the tooling strips on.
The PCB is designed for linking by a codec2 , link for analog
repeaters, using standard FM radios (mic or 'packet' input). IE it
takes in audio from the repeater, turns it into codec2 3200 bps (or
higher) and sends it on the link. and vica-versa. It also turns around
the local audio for TX and functions as a basic rpt controller with ID,
TO etc
Any last requests ? Note the board is SIMPLE, and your request might not
get on there. I am sticking very tightly to a complexity limit so it can
be built for < $30.
Cortex M7 with USB and JTAG .
some opto I/O for obvious things like PTTs and signalling inputs.
switched mode / linear regulator + Vin monitor.
some unused ADC inputs hooked up for I dunno what in the future..
analog input for discriminator output (analog repeater ) (so it can do
things like measure SNR)
with 5 section Cauer filter.
analog input for discriminator output (analog radio for digital link)
with 5 section Cauer filter.
and two DAC outputs ( 3 section cauer filters) for the audio outs for
the repeater and the link radio.
there is a 'gang' SPI interface so that two or more boards can share
data/audio in the future.
anything else ?
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
--
-
Glen English
RF Communications and Electronics Engineer

CORTEX RF
&
Pacific Media Technologies Pty Ltd

ABN 40 075 532 008

PO Box 5231 Lyneham ACT 2602, Australia.
au mobile : +61 (0)418 975077
glen english
2016-03-11 22:12:10 UTC
Permalink
Hi Greg
good idea
There is no "codec2 protocol" to my knowledge, and I will be doing
something different to David , competition at least between two sources
is I think good for everybody.

The board will be able to do full duplex, with the M7 and STM specific
optimizations.

One has to be careful though with no duplexor.. can lead to significant
pollution if put at a good site.

g
Post by glen english
I am just putting the finishing touches on a PCB before it goes to the
fab house. I am about to seal the edges and put the tooling strips on.
The PCB is designed for linking by a codec2 , link for analog
repeaters, using standard FM radios (mic or 'packet' input). IE it
takes in audio from the repeater, turns it into codec2 3200 bps (or
higher) and sends it on the link. and vica-versa. It also turns around
the local audio for TX and functions as a basic rpt controller with ID,
TO etc
Any last requests ? Note the board is SIMPLE, and your request might not
get on there. I am sticking very tightly to a complexity limit so it can
be built for < $30.
Probably this is code and not a board change, but I think it would be
nice if this could function with a local simplex repeater. Maybe it can
already. What I mean is to have say a 5W UHF radio locally without a
duplexer, on some simplex/unused channel, and to put the codec2 radio
someplace as a real link. So when talking locally (at home), you would
have no repeater, but would be able to use an HT around the house, and
presumably everybody would hear everybody anyway, but also work with the
link.
That makes me wonder if there could be something that speaks the same
protocol to have a codec2 repeater (demod/remod, presumably, but not
decode/recode), and probably this works with pure analog. Then one
could have a group of people all doing this.
Longer term, if there is some transport header, smarter linking could
work with the same endpoint hardware. It would be great if the software
is updateable by the user, even if that means having a JTAG probe.
I don't think anything I said above leads to hardware requirements, but
I could well be off there.
--
-
Glen English
RF Communications and Electronics Engineer

CORTEX RF
&
Pacific Media Technologies Pty Ltd

ABN 40 075 532 008

PO Box 5231 Lyneham ACT 2602, Australia.
au mobile : +61 (0)418 975077
Continue reading on narkive:
Loading...