Hallo Michael,


First of all, Vielen Dank for your reply and your offer.

That's one of the great things about the net, you ask a question in a 
mailing-list and a couple of hours later, there is somebody offering to 
help. :-)


(inline comments below)



On 11-02-13 18:33, Michael Hartje wrote:
> Dear Kristoff,
>
> I refer to your mailing on the codec2 list
>
>>> BTW.
> One of the things I have in the back of my head is to convert the modem
> it to a GNU radio module. I currently have no idea how to get started
> with that. Does anybody think if this would be usefull or not?
> I image it would make sence to simulate new versions of a protocol.
> Does anybody have any experience with this? How easy / difficult is this?
> <<
> I will offer to you to do it together since I am working with Gnuradio
> more than 3 years holding some speaches and "work shops" on ham
> conventions like the IPRT (Darmstadt) the last 3 years and in
> Friedrichshafen 2012
Well, first of all; my knowledge of GNU radio is very very basic. I got 
it to install and run on my ubuntu laptop and have been trying out of 
the examples that I found in youtube so I have some idea from what it 
can do.
Based on this, my place here would probably be in one of your classes, 
not as a developer :-(


Anycase, based on that I have seen, GNUradio seams to be very very 
powerfull tool; especially for doing simulations.


The reason I have been looking at GNUradio (appart from the fact that 
some people in our local club have been playing around with SDR radios), 
is related to how the c2gmsk project has evolved.

The first c2gmsk modem (the one as shown in the video) was designed to 
be a "quick hack", to provide a proof-of-concept that codec2 over 
VHF/UHF works and get some publicity. For that reason, its based on the 
code I had for the 4800 bps modem (for D-STAR) and a very basic FEC-system.

After that, I started to work on making the modem "more then just a 
cheap copy of D-STAR", so that's why I started work on the 2400 bps 
modem, which is a bit more complex, implements scrambling, a bit more 
complex FEC, etc.
There was some work done by some people on what bits are more important 
than others (important for develop FEC), etc.
That modem is now in the "alpha" folder on github.


At that point, some people asked my if I could do a write-up of how to 
use the modem, but then I kind-of came to a strange conclussion: it's 
not that easy. There are all kind of issues with all kind of stuff. (see 
my previous message)

But based on the discussions here and some other lists, it did became 
clear that "ease of use" is an important element in the success of a 
codec so I have the intention to do that first.
Later on, with the success of FreeDV, the idea came along to get the 
c2gmsk modem into that platform too. This means, to convert it into an API.


Anycase, the result of this all I have been mainly working on 
"secundairy" issues, and that the developement of the modem itself has 
kind of been left behind. There is quite a lot of work to do:
- implementation of the FEC in the 2400 bps modem
- to do a very descent test of the 2400 bps modem (the FIR filters are 
-I think- not 100 % correct)
- implementation of the header
- creating a good UDP streaming-protocol between different parts of the 
application: e.g. between the audiotool (voice input/output) and the 
modem; but also -looking into the future- between a modem and a 
"repeater" or "reflector" service, or between a freeDV receiving station 
(acting as "webreceiver") and a remote listener.


So, back to GNUradio.

Correct me if I am wrong, but based on what I have seen about GNUradio; 
it looks to be a good tool so do simulations of new designs for the 
modem and the protocol. And this is important for me; so that people who 
want to do work on the protocol itself (and I know some people are) 
could do so without them having to wait for me to actually write the 
modem for it.





> Hopefully I can give you some help to start.
> We can
> 1. mail about concept an realisation but e should take very quick the
> opportunity to
Well, as this is an open list, I'll first reply here. That would give 
some other people the option to join the discussion if they want or -at 
least- follow the discussion and learn a bit about GNUradio (which seams 
to be a very good tool that -sadly enough- relative few people know, 
including myself)


So, correct me if I am wrong:
- gnuradio is based on "modules", i.e. certain blocks that perform a 
certain function: signal sources, signal sinks, mixers, filters,.. what 
have you. They can operate both on analog signals and digital signals. I 
have seen blocks for such things as GMSK modulators and demodulators, 
FEC systems (some of them writting by people following this list) and I 
remember seeing also a codec2 encoder/decoder?

- Using GNUradio (and the GUItool GRC), you design a system but coupling 
these blocks together. Correct?


Now, can I conclude from this that -in fact- the main issue here would 
be to write a module that takes a codec2 stream (from whatever source, 
e.g. an audio-input + a codec2 encoder), transform it to the correct 
c2gmsk format, and then just output it. The output would then be send 
the GMSKmodulator (which is an existing block).
So, in fact, the actual code would be not that large and would really 
focus on the just the protocol and nothing else.

In the other direction, there is a simular process for decoding: take a 
bitstream standard in (e.g. from the output of the GMSK demodulator 
module), trying to extract the c2gmsk stream from it and then output it 
(so it can be send to a codec2 demodulator and audio output).

Am I correct?




> 2. get a echolink / skype session an in parallel with an teamviewer
> session to get the bird flying
> what do you think about that?
Well, as said. I am currently working on the API.

Yesterday-evening, I got "first light" for the encoding process chain: 
sending a "stream start" to the API and getting the audio-frames of the 
start-silence + the sync frame in return.


The advantage of writing an API is that it makes you really think of the 
how the modem is structured and how the different steps in the modulate 
and demodulation process all fit together.
I think, once I have finished the API, I think I should be able to 
really describe the different steps of how the modem actually works.

Would this be a good basis for a c2gmsk  GNUradio module?





BTW. I did notice the GNUradio modules are written in python. Another 
language to learn. :-)



> you can reach me at echolink DB0HFT (#528276) mainly during the evening
> times
Sure. No issue.


I'll give you a shout when I can.

My home repeater is ON0OST, here in Ostend, Belgium.


Hmm. That was another idea I had: build a echolink "link" from a 
raspberry pi + USB audio-dongle + HT ... hmm .. nope ... no time for 
that. I'll put that on my "todo" list . :-)


> vy 73
> Michael, DK5HH
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

Reply via email to