Kristoff, On the other hand, having a handheld system prototype or two shows people that might be skeptical (doubtful) about the possibility that what you're talking about works that it does work, without it looking like a mouse's nest of wires and boxes. Presentation is very important when talking about concepts like this.
Matthew Pitts N8OHU Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Kristoff Bonne <krist...@skypro.be> Date: Wed, 30 Nov 2011 13:07:06 To: <freetel-codec2@lists.sourceforge.net> Reply-To: freetel-codec2@lists.sourceforge.net Subject: Re: [Freetel-codec2] HF narrow band Hi Daniel, On 30-11-11 11:40, Daniel Ankers wrote:How about >>> making a general-purpose mobile/handheld SDR platform, and let the soft >>> modems, FEC, modulation, codecs, and applications develop as they will. >> Wait. >> >> For us, to start with experimenting, we do not need a SDR platform. I >> now have software that turns a ARM board (like a mini2440 or a >> pandaboard) into a GMSK receiver (if connected to a 9k6 port of a >> radio). Next step is the sender, but that is supposted to be easier. >> The kit Jan has designed allow pretty much the same thing (but is a bit >> more profesional then my stuff. :-) ) and works with any PC. > A general purpose handheld SDR platform would be great - but to be > truly general purpose will require a linear amplifier, which is > inefficient so kills battery life and is therefore a poor fit to > handheld radios. If I understand correctly, envelope tracking > amplifiers might help here though. I once saw a picture of what was supposted to the "the first GSM mobile phone". It actually turned out to be a mini-van packed with all kinds measuring equipement. :-) My point is that SDR platforms and HT are great to put some small device in the hands of the enduser, but -just for testing or developement- you don't need that. Just take any FM radio with a 9k6 port (like a yaesu FT-857D I have) and a USB audio fob and you can start experimenting with GMSK streaming. Just like using a radio with USB and and normal audio port to experiment with COFDM based modes. > G4KLX has written GPL'd D-Star software > which uses the DV-Dongle - ... That's what I did. I scrapped the low-level gmsk code from Jonathan's source code, converted it from C++ to C, modified it slightly so that the GMSK modulator and demodulator works on a CPU without FPU (like the mini2440) and wrapped some code around it that receives a stream and dumps it to a file (or spit it out at as a UDP stream). I've just finished "beta1" (I'll sync it with github later today). Next step will be the sender: just grab a file from disk, gmsk encode it and spit it out to the audio-device. Connect that audio device to the 9k6 port of a FM radio, and -if the audio-level is well set- it will transmit it as a GMSK stream. If the file has the correct format for a D-STAR frame, D-STAR radios should be able to pick it up and decode it. (e.g. D-STAR voice announcement, D-RATS file transer, D-APRS location messages, ...) If the file has some other format, well, it would be a simple way to experiment with other gmsk-based DV systems. The advantage of this is that experiments you can repeated over and over and automatically. As proposed, use one transmittor somewhere located in the middle of a town (say a repeater site) and have the receiver drive around. If you add time information to every stream that is received and you match this to information from a "logging GPS" (a GPS that keeps track where you are; say every 5 seconds) where the receiver was located at that time, this not only allows you to measure the quality of your system but you can also map that to a location. In short, this allows you to map the coverage area of a repeater. > it shouldn't be too much of a stretch to > change that to codec2 instead. > I don't believe that we are missing any components needed to start > experimenting with codec2. Not really, and this is exactly the point I wanted to make. We have codec2 as vocoder, but then you put some layers on top of that to deal with error-correction: FEC, scrambling and interleaving. Also "to be discussed" are the "syn markers" that are put inside a stream to help to keep receiver in sync or when a receiver picks up a stream somewhere in the middle of a conversation (as the i-com radios are able to do). > All it needs is people to start playing. First step would be for people to come up with ideas on what to use for these missing parts and somebody to implement them (looking at the implementation of the FEC-system used for the D-STAR header, it seams to be based on some heafty maths). Of course, we can start with just trying it out without any FEC applied. It might not be that usefull as a end-product but it would provide a "reference" for later experiment to determine how well a FEC system works. > 73, > Dan MD1CLV 73 Kristoff - ON1ARF ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2 ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
