My PC died on me on friday, so no C-development or mailing list discussions this weekend. Well, it can’t all be about D-STAR and digital voice, and it gives me a little time to play with this: a sparkfun si4735 FM/AM receiver arduino shield.

Stereo FM from 76 to 108 Mhz (so including the Japanese FM broadcasting frequencies), RDS and AM continues reception from the longwave band (153 – 279 Khz) all the way up to the 11 meter broadcasting band (25.67 to 26.1 Mhz), all in one IC!

The idea is to build a remote-controlled receiver for shortwave broadcasting stations, placed in a box at the back of the garden; as far away as possible from interference from the house.

After a quick test, expected difficulties are:

• FM works great, but shortwave reception has interference of the arduino
• AM longwave and mediumwave use a different antenna (coil) then shortwave and FM (wire antenna). Switching between the antennes is via a hardware switch on the shield; which -of course- cannot be done remotely.
• Getting the audio back from the remote receiver into the house. The IC has both an analog and digital output, so some experimenting will be needed to find out what works best.

73

Kristoff – ON1ARF

Hi,

I’ve pushed an updated of the gmsk software on github. It can be found on its usual address: http://github.com/on1arf. The GMSK sender is now  version alpha2. The last release of the receiver is version beta2.

Overall, four things where added:

1. The GMSK sender now has the ability to play out audio directly to an alsa audio device instead of just creating an audio file. This reduces the number of steps needed to send a GMSK stream.
2. The GMSK sender also added a “PTT lockfile” feature. This allows an external application to actually switch the PTT switch of the transceiver.
3. Both the sender and the receiver now support “raw” format files. This enabled the tools to receive or transmit GMSK streams that are not in D-STAR format. (like 4.8 Kbps Digital Data or codec2-based Digital Voice).
4. The gmsk sender now also accepts input from standard-in. The gmsk receiver now can output the received gmsk stream to standard-out. This makes it easier to use the gmsk tools distributed over seveal devices.

Next step:

• Write the applications that switch the PTT, controlled by the gmsk sender module
• Write the tools needed to start experimenting with codec2-based gmsk Digital Voice.

As usual, discussion about this software prefered on the yahoo gmsk_dv_modem list.

73

Kristoff – ON1ARF

With the codec2 vocoder becoming more and powerfull, the possibility of a ham-radio VHF/UHF Digital Voice system using that voice codec is an issue that pops up on different mailing-lists from time to time.

On the codec2 mailing-list on sourceforge, an interesting question emerged: if a new GMSK-based ham digital-voice system would be introduced on VHF or UHF, there is a big change that some day, both systems would be used on the same frequency. As codec2 and AMBE -the vocoder used by D-STAR- are completely incompatible, would this not lead to fellow hams getting lots of R2D2 on their D-STAR radio.

Concidering that D-STAR radios have fixed firmware that cannot be changed, how do we make sure that the two systems do not interfere with eachother?

Or, … how does a D-STAR radio react when receiving a non-D-STAR GMSK stream?

Using the new “gmsk-sender” application (see earlier blog message) which is able to generate any kind of GMSK-stream, I descided to give this a try.

Test setup:

Introducing,

• In the red corner, yaesu FT-857D analog FM radio, interfacing breadboard and a friendlyarm mini2440 running the “gmsk-sender” software.
• In the blue corner, our “victim”, an icom IC-E80D D-STAR handheld radio
• Referee: Kenwood TH-F7 analog FM radio, used to detect the presence of a FM carrier.
• Place: 430.950 Mhz. Frequency allocated for “experimenting with DV” in IARU Region 1.

The test was pretty simple:

1. Take a file containing a valid D-STAR stream, containing AMBE-encoded audio and a copy of its D-STAR configuration header in the slow-data part. (icom slowspeed data extension)
2. Modify the stream according some test criteria.
3. GMSK-encode the stream, resulting in a PCM audio-file
4. Play out that audio file using the yaesu FT-857D radio on 430.950 Mhz
5. Check if the i-com D-STAR plays out the D-STAR conversation; indicating if the radio is able to receive, syncronise and decode the GMSK stream.

Four test-parameters, two senarios.

To be able to analyse the behaviour of our victim when being bombarded with all these “non-standard” GMSK-streams, in total 4 elements where to be examined. The goal is to emulate two different senarios.

The four elements that are modified in a D-STAR GMSK stream befor transmitting are as follows:

1. The GMSK “frame syncronisation” pattern. This pattern is a fixed 15-bit pattern that is located between the “bit syncronisation” pattern (in the beginning of the gmsk stream) and the D-STAR configuration frame. It is used to indicate the beginning of the D-STAR information in the GMSK bitpattern.
2. The D-STAR configuration frame: a 41 octet structure located at the beginning of every D-STAR stream. It contains information like the “MY” and “YOUR” callsign, repeater callsigns and 3 flags. It also contains a checksum.
3. The 3-octet syncronisation pattern located in the slow-speed data part of every consequative 21 D-STAR frame.
4. The copy of the D-STAR configuration frame, as found in the slow-speed data part of a D-STAR stream. This information is only generated by i-com equipement as this is an i-com extension of the D-STAR slow-speed data protocol.

For more information on the first three elements, check out the “what does a D-STAR stream really look like?” document here.

Information about the i-com extensions for slow-speed data can be found here

The two senarios that where emulated are:

1. The i-com radio receiving a GMSK stream from the beginning of the stream.
2. The i-com radio receiving a GMSK stream NOT from the beginning of the stream.

The difference in these senarios is related to the fact that -as mentioned above- two of these test-parameters (“frame syncronisation” and “D-STAR configuration frame”) are only present in the beginning of the stream. If a radio does not receive (or is unable to decode) these fields, this results in a different outcome of the test.

In fact, tests shown that if a D-STAR radio DOES receive the beginning of a GMSK stream, but that stream does NOT containing a D-STAR complient frame-syncronisation pattern, is functionally equivalent to having it tune to an frequency with an ongoing D-STAR conversation. The radio needs to try to syncronise itself to the GMSK stream based on the elements in the D-STAR format that are repeated continuesly in the stream: the 3-octet “resync” pattern or the slow-speed data part.

D-STAR configuration frame

After some quick first tests, a first conclussion was quickly made: rewriting information in the D-STAR configuration header has absolutely no effect on wether or not the i-com radio plays out a received stream.

No matter what was placed in the “YOUR”, “MY” or “REPEATER” fields, in the flag or if the checksum of the header-field is correct or not, the i-com IC-E80D always played out any stream it receives and can syncronise on.

One could even ask if this particular firmware in the IC-E80D is actually complient to the JARL D-STAR specification. During one test, the radio was send a stream with these parameters:

• all syncronisation patterns valid
• D-STAR configuration frame modified, setting bit 7 (MSB) of flag 1 to “1″
• checksum of config frame corrected
• no D-STAR configuration information in the slow-data part of the stream

According to page 3 of the the “shogen” document of the JARL, bit 7 (MSB) of flag 1 “Distinguishes between voice and data communications. 1 indicates data, 0 indicates voice“.

If this is supposted to be a “data” stream, a voice D-STAR radio should not try to decode it. Apparently it does as the IC-E80D does play it out. As the checksum of the configuration-frame IS correct, there is no reason why the firmware of the radio should question the validity of the flag and behave accordently.

The results:

In the end, there where three parameters to test:

1. A valid frame syncronisation pattern at the beginning of the stream.
2. Valid syncronsation octets every 21 digital-voice frames
3. A copy of the D-STAR configuration frame in the slow-data part of the stream

The results of the tests are as follows:

So, what can we conclude from this?

• If the radio receives a stream from the beginning, it needs either the valid 21-frame sync pattern or a copy of the D-STAR configuration frame in the slow data to syncronise itself. If not, it will stop after about 2 seconds.
• If the radio does NOT receive the beginning of a stream, it is able to syncronise to the received stream anyway if it receives a valid copy of the D-STAR configuration of the slow-data. This takes about 2 seconds.
• if the radio does NOT receive the beginning of a stream, only receives the 21-frame sync but NO D-STAR-config-in-slowdata, it does NOT play out the stream. This is a bit surprising, concidering the results of the same test in the “radio is able to receive the beginning of the stream” senario. Perhaps the radio DOES is able to syncronise itself to the stream but descides not to play it out because it does not have valid D-STAR routing information.

Of course, these test are only valid for this particular radio with this particular firmware. More tests would need to be done with other D-STAR radios.

D-STAR and non-D-STAR GMSK on the same frequency?

To go back to the original question, what would be the effects of running a GMSK-based codec2-based digital voice on VHF or UHF? Could this be done without producing a lot of R2D2 on D-STAR radios which happen to be tuned to the same frequency?

Based on these test with this radio, the conclussion is that it IS possible, providing the following conditions are met:

• codec2 based GMSK DV does NOT use the same frame-syncronisation pattern in the beginning of the stream
• codec2 based GMSK DV does NOT use the same 3-octet syncronisation pattern every 21 frames
• codec2 based GMSK DV does NOT use the i-com extension of the slow-data service where the D-STAR header is repeated in slow-speed data part of the stream.

73

Kristoff – ON1ARF

GMSK receiver (beta 1), GMSK sender (alpha 1) and dstarsms

The last weeks and days, I have pushed three software updates on github. As usual, the source-code can be found on https://github.com/on1ARF

GMSK receiver Beta 1.

The GSM receiver has moved up from “alpha” to “beta” phase as it has achieved a certain level of stability.

Changes compaired to “alpha3″ are:

1. Better code to deal with unexpected-end-of-stream situations. The program now used the average audio-level of the incoming signal to detect when a stream has ended without sending a proper termination pattern.
2. Do not do gmskdemodation when no signal is being received. Again, using the average audio-level, the program detects when a stream is being received or not. When no stream is being received, no gmsk decoding is done which largely reduces the CPU usage of the application. On a mini2440, the CPU load has gone down from more then 20 % to less then 2 % when no signal is being received.
3. Some small bugfixes.
4. The option to output of the incoming stream to UDP packets on a network.

The ability to stream out a received GMSK stream to UDP packets on the local network has two main applications:

• To communicate the received data to one or multiple INTERNAL applications on the same board (e.g. AMBE decoder, voip client, …)
• To send the received data to an EXTERNAL application somewhere else on the network. One particular example is setting up a D-STAR repeater with multiple receptions sites; thereby allowing people with handheld radios to transmit at lower power.

GMSK sender alpha 1

A new application is the “gmsksender”.

As its name implies, this application does the opposite of the gmsk receiver: it reads a file from a local media and does gmsk modulation, generating a PCM audio-file. That file can then be send to the 9k6 port of a FM-radio, resulting in a GMSK or D-STAR stream that is transmitted.

This is still “alpha1″ code, so it does have its limitations:

• The generated GMSK audio-file is in RAW PCM format. It needs to be converted to a more usefull .WAV file using an external application (sox)
• The resulting .wav file needs to be played out to the 9k6 port of the tranceiver using an external application (e.g. aplay, mplayer, …)
• There is currently no way to automatially drive the PTT of the radio. That needs to be done by manually grounding the PTT pin of the 9k6 port of the radio.

Althou this tool is still alpha code, it does have some nice features:

• Rewrite the D-STAR header (MY, YOUR, RPT, … flags)
• Recreate syncronisation patterns in the D-STAR stream
• Erase the slowspeed data (which also deletes the copy of the D-STAR header found in the slowspeed data part)

D-STAR repeater SMS tool

This is a tool I wrote about a year ago. It is an perl script that allows communication from and to a D-STAR repeater server using SMS text messaging.

This is a proof of concept of a “backup communication path” for D-STAR repeaters when the main internet connection is unavailable. For that, it uses a 3G dongle, althou the SMS texting-service can work both on 2G or 3G networks.

It provides examples for two possible senarions:

• Communication from the sysop to the repeater. In this case, the ability to send a Dplus message from the repeater, triggered by a SMS from the sysop.
• Communication from the repeater to the sysop, in casu a text-message send by the repeater to the sysop when it notices the repeater controller server has rebooted.

The code is designed to be as open as possible so to allow anybody to work with it. It is also designed to work on any linux or unix based device, including ARM developement board like the mini2440. One application for this is to execute a hardware power-cycle of a repeater, triggered via SMS.

73

Kristoff – ON1ARF

• Capture audio from the radio via the audio-device of the computer
• GMSK demodulate the audio and turn it into a train of bits
• Extract the raw D-STAR stream from that unordered stream of bits
• Process some parts of this D-STAR stream for error-correction, descrambling, deinterleaving

The end result: a .dvtool file containing a D-STAR stream.

Easy no?

The reason I wrote “these days” in the sentence above has to do with an evolution on the radio-amateur world that has changed it quite dramatically the last couple of years: open source software. Up to -say- one or two years ago, if you where interested in writing this kind of software (for an end-user application or just to learn more about it) you had to write everything herself. You had to understand everything about all these different aspects, including some quite complicated things, like low-level DSP code for GMSK modulation and demodulation, Forward error correction algorithms). These days, that is not the case anymore.

The importance of open source software

There are currently at least two different open-source software projects that implement at least part of a GMSK modem: the PC based pcrepeatercontroler project of Jonathan, G4KLX and the DVPRTR project around Jan, DO1FJN, Torsten, DG1HT and DH2YBE who target a “controller-board” based solution. The interesting part about open source software is its license: the so-called “GPL v2″ license. That software license is specifically designed, not only to allow people to reuse programming code written by somebody else in their own projects, but also to learn from it and even to modify it to ones own use.

What does this mean? Well, it means that you do not have to know everything about everything anymore. You can just use existing code, as written by somebody else, and start from there on.

Open source is much more then “free” software. By using open source, software and hardware designs become a way to learn. You can just take some project that already works, look how it works, learn from it, think about it, modify it to try out some ideas and even merge your code back into the original project.

Of course, it requires a bit of programmaing skills, but more then half of the work has already been done. This code provides a very solid based to get started and experiment with this or work out your own ideas. This is what this project is about: allow people to learn what a gmsk modem actually does and to allow people to experiment with it.

The Basics of GMSK and D-STAR streams

Now, before starting to program anything, the first step is to understand it. For D-STAR, this turns out one of the more difficult hurdles to take. Information about D-STAR is scattered over multiple documents, from different sources, written by different people. Its very easy for somebody new to D-STAR to get overwelmed by all these texts, especially as most of these documents about D-STAR on the internet are not even relevent to building a GMSK receiver.

In this mountain of information, there is one single “D-STAR specification” (the “shogen” document, a mere 11 pages) that described the radio level interface of D-STAR. The problem is that it written for people already experienced with this kind of technology. For somebody who is new to this matter, it looks -from one side- quite overwelming and -on the other size- not containing that much usefull information. We will try to provide this information in a more structured way.

Now, there are multiple ways one can describe a D-STAR radio stream: using pure dry specifications, as maths, what is looks like as a radio-frequency signal. The appoach taken in this article is by asking a simple question: “what does a D-STAR stream look like for a computer program that needs to decode it“. The goal of this exercise it to give some  insight into what a GMSK audio-stream actually is, how it is structured and -based on that- how does one go about writing software to decode it. It does this by reducing certain “magical” parts of the programming code (especially the DSP code to do GMSK demodulation, error-correction and scrambling) to a “magical box”. We will gracefully skip over this code in this article.

The programming code for this GMSK receiver application can be found here.

In the end, believe it or not, it actually turns out that understanding a D-STAR stream isn’t so difficult to all.

10 basic facts

If you search the internet for specifications about D-STAR, you will come across some words and terms that -for people who know digital communication- are common knowledge. These words provide certain basic information that one should be aware of. So, if you bare with me, here are the “10 basic facts about GMSK and D-STAR you should know and understand“:

1. Digital: D-STAR is a digital communication system. This means that speech is not transmitted as a varying analog signal (like FM, AM or SSB) but converted to and transmitted as a serie of 0s and 1s (“bits”).
2. GMSK: Althou we want to transmit speech as a serie of digital 0s and 1s, we still need to do this using analog radio-equipement. For that reason, the bits are converted into “tones” so it can be transmitted over an analog radio. This is the reason why, if you tune a analog FM radio to the frequency of a D-STAR repeater, a D-STAR signal will sound like “buzzing noises”. There exist a number of such “modulation” systems: FSK, PSK, ASK. The system used by D-STAR is GMSK, a system related to PSK.
3. FM modulated: as all HAMs should know, transporting a analog signal with a radio can be done using a number of different modulation technologies: AM, SSB or FM. Just like certain other digital technologies (notebly packetradio and APRS), GMSK uses FM modulation. This explains why it is possible to use a normal FM-transceiver to send and receive GMSK signals.
4. 9k6 data port: One of the things where a GMSK modem differs from a normal FM voice communication (and from packet-radio and APRS), is that it uses the “9k6″ dataport to the radio, instead of the normal “microphone/speaker” ports. That port is different from the other ports on a FM transceiver that is bypassed the “emphasis/deemphasis” circuit of a FM radio. These circuits modify the audio in a way which would change the gmsk “tones” and therefore also change the bits they carry. Hence, to avoid this, a gmsk modem is connected to the 9k6 port of a FM transceiver.
5. 4800: that is the number of bits per second that are send by a D-STAR radio. These bits can be divided into 3 groups: 2400 bits/second “voice” information, 1200 bits/second “forward error correction” bits, used to protect the voice-information from transmission-errors and correct them if possible, and 1200 bits/second “slow data”.
6. structured: althou when listening to a gmsk stream one wouldn’t say it, the bits in a gmsk stream do have a fixed predefined structure. In short, it consists of a header-frame of 328 bits that contain such information like the callsign of the sender and any number of data-frames of 12 octets each that containing digital voice and slow-data.
7. Syncronisation: in addition to the structure mentioned above, a D-STAR GMSK stream also contains some special bitsequences that are needed for syncronisation. These are needed so that the receiver listens for bits at exactly the exact time that the transmitter has sended them. Syncronisation bits are used to mark the beginning of the stream (hence located in front of the D-STAR configuration frame), to mark that a stream has ended and also every 21 frames (i.e. every 420 milliseconds) to keep the receiver “in tempo” with the sender.
8. 20ms: A voice communication -which can take up to minutes- cannot be processed at one go by a digital voice system. It is cut into pieces of 20 milliseconds each. This allows the voice to be processed by the “vocoder” (see one below) and converted into 9 octets (6 octets voice data + 3 octets error-correction). These 9 octets, plus 3 octets of “slow-data” make up the 12 octets that go into every dataframe (see one above).
9. AMBE: 20 ms of unprocessed voice information normally takes up 160 octets. To fit it into the 6 octets of voice-data that D-STAR can carry, it needed to converted by a so-called “codec” (coder/decoder) or  ”vocoder” (short for “voice coder”). The vocoder used by D-STAR is called “AMBE”.
10. DVdongle: The GMSK receiver software does not deal with the AMBE vocoder. It just dumps the received stream onto a local file and does not process the voice stream in any way. Software that DO want to encode or decode audio uses an external device for this (called the “DVdongle”) as the software that does the conversion from or to the AMBE format is not public and can only be bought in the form of a IC.

Hardware setup

Software is all nice but, in the end, hardware is always needed to get the received audio into the computer board running the GMSK modem. In this example, the setup is very limited:

(click on photo for more details)

These are the hardware components that are used:

• A FM tranceiver with a 9k6 data-port (in this case, a Yaesu FT-857D)
• Any kind of computing-device, either a “PC” class computer or developement board (in this photo, I used the pandaboard, but this can also run on less powerfull like the mini2440 also visible in the photo)
• Any audio input device, either the native audio-in port of the computer / developement board, or an external USB fob. In this case, this device was used as these are known to work well. They have been tested quite thoughtly by the people of the freestar D-STAR network in Canada.
• A cable connection the audio input device with the radio. In some cases, a capacitor is needed between the transceiver and the dongle to block the DC component. However, on the Yaesu FT-857D, there already is a capacitor located on the 9k6 port of the radio so there is no capacitor on the connection cable.

Note that in this setup, the connection between the radio and the USB audiofob are just two wired that are soldered together and hang freely in the air. This would -of course- not be something you would do in a operational enviroment as this would pick up all kind of RF interference from all kind of sources (like the two development boards and a laptop located closeby).

From an software-development point of view, as programs have to be able to deal with interference and biterrors, this “bad” interface actually helps to make the code more robust. A more complete interface circuit can be here, as provided by Ramesh, VA3UV.

Step 1: capturing and analysing an audio-stream

As mentioned above, this article looks at a GMSK D-STAR stream, as seen by an computer application that needs to decode it.

Sample 1:

So, the first step is … to do the same thing and listen what the gmsk decoder receives from the radio. Click below to listen to audio sample 1 (6 seconds):

So what do we hear? … Nothing? … Not really. We DO hear someting: noise!

This is a first interesting fact. When receiving audio from the 9k6 audio receive port of a radio, there is no “squelch” function. The reason for that is very simple: the 9k6 “port of a tranceiver is position BEFORE the FM discriminator while the audio “squelch” function is located completely at the end of the audio reception circuit.

Sample 2:

Next, audio sample 2 (16 seconds). Click below:

As one can hear, this audio-sample contains two gmsk burst, surrounded by noise. As the saying goes “a picture shows more then a thousand words”, this is the actual visual dump of this audio-file, as generated by the audio editor Audicity.

(click for a bigger image)  

So, again, we have the same things:

• Two “bulb” of GMSK streams
• Surrounded by noise when nothing is being received.

Another interesting fact is the audio-level of the received noise, when no FM signal is being received, is actually higher then there is a valid signal entering the FM receiver circuit.

A close-up of the beginning of the stream

Let’s make a close ups of one of the gmsk bursts in the stream. As shown on the timescale, this is the beginning of the 2nd gmsk burst. See image below:  

Visually, it is very easy to distinguish three different parts.

1. Up to marker 7.985, no signal is being received, so the radio is picking up noise.
2. Between 7.990 and 8.105, we see a very regular pattern
3. From 8.195 onwards, this pattern becomes much more varied.

The explanation for this can be found in the 6th and 7th “basic fact” mentioned above. A D-STAR stream is not just a random stream of bits, it has a fixed structure. In particular, in front of the D-STAR stream itself, there is a fixed “syncronisation pattern” which marks the start of the stream. This patterns is not only fixed, it’s also very regular.

Another nice element in this audio-sample is the small “hick up” just at the beginning of the syncronisation pattern (around timestamp 7.990). The reason for it is currently not completely clear and discussions in our local radio-club center around either the behaviour of the VFO PLL circuit of the FM receiver and the effect of capacitors in the audio-ports of the receiver and the USB audiofob.

Demodulated signal of the beginning of a stream

Now, as a good journalist, one needs to have at least two independant sources to trust a story. So what does it actually look like when we GMSK demodulate this audio-stream? As the “gmsk receiver” has an option “-dd” (dump more), it is possible to see what the program actually sees coming in.

The process that creates this bittrain goes like this:

1. The application captures an audio sample every 1/48000 second
2. The value of that sample is send to the “gmsk demodulate function” (one of the “magical” pieces of code) which turns this into a “0″ or a “1″
3. As we are sampling 48,000 samples per second but the gmsk signal only runs at 4,800 bits per second (one tenth of the sampling rate), some additional code is needed to take care of this. Again, we will concider this code is a “magic box” that we will accept “as it”.

So, back to the audio-sample. Let’s GMSK demodulate it and see what we get. First up, demodulation of the noise. This is the result:

00111000 10011100 00000010 00001000 00110111 11011111
00000000 10000001 00000000 00101101 10011111 10111111
11000001 11010010 01111010 01100001 00101000 00110100
00000000 01110100 10011010 00110000 00011000 10011011
00011101 10000111 10000111 11100111 10100011 11110101
11100000 11110000 11100110 11000001 01111101 10100001
(...)

(Note that the grouping of the bits in groups of 8 is just to make things a bit more readable, it has no special meaning).

Conclussion: as noise is in fact nothing else then a bunch or random voltage levels, turning this into a bitstream of 0s and 1s just produces a random string of 0s and 1s. OK, so far, nothing world shocking.

But then, a bit further, things do get more interesting.

(...)
10000110 00010000 00000001 00010111 11010110 10010100
00111111 10100111 00100011 00111101 00111100 10111111
11101000 10000001 11111101 11101010 11101101 10111111
00010000 11101011 11110000 00000000 11111110 10000000
00001000 11000001 01111100 11111000 10111101 11111111
11111100 00011111 11111111 11111111 11111111 11111111
11111111 11111111 11111111 11111111 11111111 11111111
11111111 11011101 01111101 01010101 01010101 01010101
01010101 01010101 01010101 01010101 01010101 01010101
01010101 01010101 01010101 01010101 01010101 01010101
01010101 01010101 01010101 01010101 01010101 01010101
01010101 01010101 01010101 01010101 01010101 01010101
01010101 01010101 01010101 01010101 01010101 01010101
01010101 01010101 01010101 01010101 01010101 01010101
01010101 01010101 01010101 01010101 01010101 01010101
01010101 01010101 01010101 01010101 01010101 01010101
01010101 01010101 01010101 01010101 01010101 010
... 11101 10010100 00

As we can see, at a certain moment, a fixed patterns starts to emerge: first all “1″ and then a repetitions of “1010″. Let’s look in the specification what this means. See page 3 of the “shogen” document:

2.1 Wireless Communication Packet
2.1.1 Frame structure of a packet: The explanation of the data frame structure the Radio Header follows.
(1) Bit Syn. (Bit synchronization): Repeated standard 64-bit synchronization pattern (for GMSK 1010). (...)

So, what we are seeing here, is the beginning of a D-STAR stream: at first, the receiver and the gmsk needed some time to syncronise themselfs, but after about 20 ms, the fixed “1010″ appears.

This is not only exactly as the specifications say how it should be, it also corresponds nicely with the audio-sample. As every line in the bitdump above corresponds to 20 ms, the whole process of syncronisation takes about 120 ms (6 lines) which is also shown in the dump of the audio file. Additional proof found!

So, what’s next? Well, let’s again have a look at the specification:

2.1 Wireless Communication Packet
2.1.1 Frame structure of a packet: The explanation of the data frame structure the Radio Header follows.
(...)
(2) Frame Syn. (Frame synchronization) : 15bit pattern (111011001010000).
(...)

Looking again at the bitdump, this 15 bit “frame sync” patterhn is exactly what we see at the end!!!

This “frame sync” bitpattern is nothing else then a marker in the frame-structure saying “here stops the bit syncronisation and starts the next part: the D-STAR header frame”.

The D-STAR header

As the specification says, the parts following the frame syn pattern is the D-STAR header frame. Let’s have a look at the output of the GMSK demodulator. It returns this information:

HEADER DUMP:
FLAG1: 00 - FLAG2: 00 - FLAG3: 00
RPT 2: DIRECT
RPT 1: DIRECT
YOUR : CQCQCQ
MY : ON1ARF /KRIS
Check sum = E441 (OK)

As one might see, this is just the same information that one has to fill in into a D-STAR transceiver, plus 3 “flag” octets and a 2 octet checksum.

Based on this, one would say that the header would have a length of 328 bits (41 octets * 8), however that is not the case. The header is no less then 660 bits. To understand the reason for this, we will have a look at the (simplified) source-code of the gmsk decoder.

In the programming code processing the 660 bits received after the frame-sync sequence, we find this:

scramble(radioheaderbuffer_in,radioheaderbuffer_temp1);
deinterleave(radioheaderbuffer_temp1,radioheaderbuffer_temp2);
length=FECdecoder(radioheaderbuffer_temp3,radioheaderbuffer_out);

The received header bits are processed by 3 different functions: scrambling, deinterleaving and FECdecoding. Explaining the reason for this is however more easy if we look at what happens at the opposite side, at the transmitter. Overthere, we see the same processes, but in reverse order: first FECencoding, then interleaving and finally scrambling.

As is explained below, these three processes are there to make the transmission of the header more robust, i.e. to make them better capable to deal with packet loss.

Step 0: adding two bits

The very first step in this process is a bit strange. Before processing, two bits (containing 0) are added at the end of the 328 bits of the header. These bits do actually not have any particalur use (hence “step 0″), They do increase the header-size from 328 to 330 bits.

Step 1: FEC

The first real step in processing the header on the sender side is “FECencoding”. FEC means “Forward Error Correction” and it does just as its name implies. It makes a stream better able to deal with errors, even BEFORE transmitting it.

The idea is very simple. By adding bits to the stream that is being send,  when bits get corrupted during the transmission, the receiver (actually the FECdecoding algorithm in the receiver software) can use these additional “error correction” bits to correct the faulty ones. How FEC really works internally is something will we gracefull pass over in this article.

What is interesting to know is that the particular system used in the D-STAR header creates one additional bit for every data bit; hence doubling the size of the header from 330 to 660 bits.

Step 2: interleaving

The second step is a process called “interleaving”, which is just a fancy word for “juggling bits around”. This means that you complety change the order in which the bits are transmitted. If the header would be only 4 bits, instead of sending the bits as “1 – 2 – 3 – 4″, they would be send as “1 – 3 – 2 – 4″. This may look like a very odd thing to do, but there actually is a very good reason for this. It is related to the Forward Error Correction mechanism described above.

As mentioned above, the FEC algorith tries to make a stream more robust by adding error-correction bits to the stream. However, these error-correction bits are located just next the data-bit. In our 4-bit header example, bits 1 and 2 form one FEC pair and so would bits 3 and 4.

Now, all these 4 bits are send sequencially. image that, during transmission, there is a interference pulse that not only wipes out bit 1 but also bit 2, both bits of the FEC pair will be corrupted and the FEC system will not able to correct this. This is where the “interleaving” system comes it. By spreading out the 660 bits of the header, this makes it less vulnerable to these kind of “impulse noise” interference. The bits of the FEC pair are located much more appart.

Programming-wize, interleaving is very easy to implement with just a plain lookup table.

Step 3: scrambling

Althou the name might indicate otherwize, scrambling has nothing to do with encryption. This process -also known as randomizing- is related to how datacommunications systems keep themselfs syncronised.

GMSK demodulation use the timing of the transitions from 0 to 1 and from 1 to 0 to keep the receiving GMSK demodulation process in sync with the sender. These exact timestamps are used as markers to avoid the GMSK receiver losing sync. For that reason, long sequences of all-0 or all-1 are something that need to be avoided.

What the scrambling-process does is convert a bit-sequence into another (predetermined) sequence, making these all-0′s and all-1′s less lickely. Luckely, there are open source software-modules to implement scrambling so we do not need to worry to much about it.

Note the the scrambling-process on the server side is exactly the same in the receiver. There does not exist a seperate “unscrambling” function.

So, to summarize:

1. The D-STAR header frame contains the information like callsigns, that are needed for routing a D-STAR stream.
2. To make it less prone to transmission errors, three processes are applied to it, resulting in a structure that is twice its original size
3. Luckely, there exist open source software for these functions, so we can just concider this as a “magical black box”
4. At 4800 bits per second, ransmitting the header takes 137.5 ms.

Finally, voice

Let’s look at the specification what is next. Page 5 provides the answer: a sequence of the voice and slow-data information.

The structure of this part of the stream is very simple. Every 20 ms, there 96 bits (12 octets) are send:

• 72 bits (9 octets) of AMBE encoded voice
• 24 bits (3 octets) of slow-data

Looking at the bitstream dump, there is not that much to see at first sight:

11011111 11010000 00011000 00011001 11100110 10010100
10110111 11111111 10011101 10101010 10110100 01101000

01111101 01010000 01100000 00011111 10100100 11011100
10001001 01100010 10100111 00001100 00100000 10000011

01011111 10010001 01010000 00000011 10100100 11111100
10011111 11100000 10100101 10011100 00111000 11100011

(...)

Every line (containing 12 octets) represents 20 ms. The left 9 octets contain the digital voice + FEC. The right 3 octets contain slow-data.

Concerning slow data, two things need to be noted:

• The 3 octets of slow data of the first frame and every 21 consequative frame do not contain slow-data. Instead, they contain a fixed pattern (10101010 10110100 01101000), as seen in the example above. This pattern is an additional syncronisation pattern that is used to keep the receiver in sync with the sender. This will be explained more in detail in a later article.
• The slow-data found in the other frames are processed by the same scrambling process as used on the header frame. Again, the goal is to avoid long all-1 and all-0 sequences that would risk upsetting the syncronisation of the GMSK demodulator.

The end

After the header of the voice stream and the actual voice and slow-data frames, we arrive at the last part of the stream: the end.

One of the advantages of a digital telecommunication stream is that you can actually mark the end of a stream INSIDE the stream. You do not have to depend on some carrier dropping away. By saying “the stream stops here”, this allows the stream to be terminated much more correct.

Again, let’s look at the specification and see what it says. At page 6 of the document, we read this:

"The last data frame, which requires a means of terminating the transmission, is a unique synchronizing signal (32 bit + 15bit “000100110101111” + “0”, making 48 bits) as defined by the modulation type.".

Hum!  Interesting wording!

Looking at the simplified source-code, we see that this “unique syncronisation signal”  is equivalent to the following bitpattern:

• The last 3 octets of a frame contain the pattern “10101010 10101010 10101010″
• The first 3 octets of the next frame contain the pattern 10101010 00010011 01011110″

Again, we look at the output of the gmsk receiver program, and we see this:

11011001 10110000 00101101 00001101 11000011 11000110
00111111 01100110 01010110 10000100 00110000 01000011

00111011 10010011 00000101 10001000 01101011 01111111
11110001 11001100 10010111 11111110 10101010 10101010

10101010 00010011 01011110 END.

Now, if you look at this carefully, you see that the pattern does not completly match. The 10th octet of the last full frame should contain “10101010″ but it contains something else. However, that pattern is still correctly seen as a valid “END” marker by the functions that have to detect an end of a stream.

The reason is that these functions are coded in such a way that it can deal with small errors. In this case, it allows up to 3 bit errors. If this would not be done, a single biterror in the transmission of the “end” marker would risk the receiver completely missing the end of the stream.

The picture below shows this pattern, as it was received by the board:

The end-sequence pattern can be found between timestamp 11.844 and 11.850 (with the 16-times “01″ nicely showing up). And it even shows why the beginning of this patterns was incorrectly decoded: there seams to be some drift on the signal.

This shows one of main difficulties with programming a GMSK receiver: making it work correctly, even if the stream contains biterrors. But that is a subject that will discussed in a later article.

This finished this article on the structure of a D-STAR stream. I hope that it has been a little bit instructive.

If you have any questions or remarks, discussions about this subject can be best done on the gmsk_dv_modem group on yahoo. Feel free to drop by!

73

Kristoff – ON1ARF

After a discussion on HF digital voice and the AOR ARD9000 modem in the “digitalradio” group on googlegroups I descided to do a little bit of research on this mode.

According this information on hamuniverse, this modem is based on a “open” standard, developed by Charles, G4GUO, but the specification itself turned out to be more difficult to locate. So I contacted him for more information.

This is the information that emerged from the following email conversation:

• In contrast to what is found on the hamuniverse website, the AOR ARD9000 modem is only “vagely based” on the work of Charles
• The original specification of the DV system designed by Charles has been lost, but after some work, he did manage to recuperate a part of it. (be it in text-form)

As Charles is now mainly working on ATV (check out his blog) and has no time anymore to work on this, I got permission from him to republish the original specification.

You can find it the document here.

Charles as has also provided source-code of a modem to implement this protocol (assembler code for the motorolla 56K DSP CPU), which may be redistributed as open source.

However, a small part of the code is covered by a copyright of a 3th party. To be sure that no Intellectual Property issues will arrize in a later stage, this issue needs to be “cleared up” beforehand. If needed, that small part of code (Fast Fourier Transform) will be excluded.

73

Kristoff – ON1ARF

At this time of writing, there is “alpha” code running that turns these boards into a D-STAR receiver and write the received data to a file. (see photo below):


This article is the first in a series that describes the software and hardware developements in this project.

About Development Boards

In the last years, two new kinds of technology have made their way into our life, one quite openly and one allmost unnoticed.

First, smartphones, tablet computers and all kind of “mobile computing devices” have become a common view at home, in the office, in schools and everywhere inbetween. At the same time, all kind of “smart networking devices” have appeared in our homes: digital media players and television set-top-boxed connected to our TV, internet streaming-radio in our living-room, a Network Attached Storage holding all our photos or used as “backup” for all our computers, intelligent routers, firewalls and wifi basestation, etc. etc.

Althou these two classes of devices pay look quite different, they have two elements on common:

- all of them are in fact small computers in their own right

- all of them have started their life as a so-called “development board”. small standalone computers that act as systems to .. well .. as its name implies .. develop and create new devices.

As a side-product of this evolution, a number of these development boards have now become available as standalone products by themselfs. Examples are the beagleboard, the pandaboard, the hawkboard, the friendlyarm, the foxboard and others.

These boards not only provide quite a lot of CPU power for a very low price; their ability to run free and powerfull kernels and Operating Systems, the myriad of free software tools and their opensource hardware license have made these boards an ideal platform for anybody interested in creating computer-driven project.

This blog is about how to use these boards for HAM-related projects, in the first face, as a GMSK modem. The goal is be use this later as the basis for a standalone D-STAR terminal.

The FriendlyARM mini2440 and the pandaboard:

The idea to use a ARM developement board for a ham project emerged from a brainstorming session in our local radio club here in Ostend. We where planning our new 6 meter repeater which would consis of two sites: one where the receiver would be located and one for the transmittor. Where looking at possible ways to transport voice from the receiver site to the sender site.

One of the ideas was “why not send it over some kind of ethernet or IP connection”. Looking at this, we needed a device that, on one side, captures audio and encapsulates it in a ethernet or UDP frame. On the other side, we needed a second box to do the inverse process: receive a IP packet, extract the audio packet and play it out.

Of course, we could do this with a cheap 2nd hand computer, but because PCs have mechanical components that have the tendency to break (read: disks) and to avoid heating issues in one of the sites; this is something we wanted to avoid.

In short, we where looking for some kind of device, more powerfull the “controller” like processor-boards (PIC, arduino, MBED) but cheaper and smaller then a “low-end PCs” (plugcomputers or ALIX computer). It turned out that the these ARM developement boards do just that.

Finaly, two boards where chosen: the friendlyarm mini2440 and a pandaboard. (see picture 1: the Friendlyarm mini2440 (left) and the pandaboard (right) brotherly next to eachother in my shack):

The specification of these boards is as follows:

Friendlyarm mini2440:

• 400 Mhz Samsung 3S2440 CPU, based on a ARM920T core
• 64 MByte RAM, 1 GB onboard flash
• SD slot
• 3 serial ports (1 * RS232, 2 * TTL)
• 1 USB host port
• GPIO port
• JTAG inline debug port
• Wired ethernet port
• I²C port and SPI port to interface with external ICs
• Audio in, Audio out and build in microphone
• 3.5 inch colour touch-screen LCD display
• Camera port (Camera not provided)
• Consumes very little power: less then 1 Watt without LCD display; less then 2 Watt with LCD display active.
• Runs different versions of linux, android and WinCE
• Fully hardware documented

This boars is on the low end of the scale what is currently available as ARM-based developement board. It can be purchased via ebay from a number of source (most of them in Asia) for less then 100 euro, including all cables and powersupply. It is marketed as a “development platform for mobile phones”.

More information about this board can be found via this link

The pandaboard

The pandaboard is a quite a different beast. It specifications are as follows:

• TI OMAP4430 processor, containing a 1 Ghz dual-core ARM Cortex A9 + additional onboard DSP-processor to offload audio and video encoding / decoding from the main CPU + 3D video processor
• 1 GB RAM, no onboard flash
• SD slot for external flashcard
• 2 USB host interfaces + 1 USB-on-the-go interface
• wired ethernet
• wifi + Bluetooth onboard
• analog audio in / audio out
• HDMI and DVI interface + HDMI audio out
• JTAG inline debugging port
• I²C connectivity
• LCD port (LCD display not provided)
• Camera port (camera not provided)
• Runs different kinds of linux or android
• open source hardware licensed

As seen, this board is more geared towards video and heavy CPU and DSP-oriented operations. It is even able to do full HD video-playback at 1080i. It’s current price is 174 USD. Note that this does not included cables or powersupply.

More information can be found it the pandaboard.org website

In the mean time, a new generation of pandaboard has been announced: the pandaboard ES. For more info, click here

Using Development boards for a HAM related project

Looking at the technical specifcation of these boards, it became pretty obvious that using them for just sampling an audio-sample from an analog port and sending it over an IP connection -the original reason we started looking at these boards- would be a great … euh .. suboptimal usage of their capacity.

Based on their specifications and information found about other projects on the internet, these boards can be used for quite a number of HAM related projects:

• packet radio and APRS node
• D-STAR gmsk modem, including for D-RATS and D-APRS
• Repeater controller
• Voip (echolink, IRLP) controller
• parrot controller
• As “calculation backend” for DSP intensive projects (like a SDR radio)
• APRS node to distribute weather information

Especially the fact that these boards are easily expandable provide a number of interesting options:

• The ethernet interfaces (wired and wireless) allow these boards to become part of a network. E.g. for D-RATS functionality, it allows computers on the network to “drop off” files on the board and have to transmitted over a D-STAR network using D-RATS automatically by the board.
• The bluetooth interfaces provide interfacing with external devices, like GPS devices (usefull for APRS and D-APRS)
• The USB interfaces give these boards options to add other interfaces not yet present (e.g. GPRS/UMTS, Zigbee, …)
• The serial ports are a cheap and easy option to communicate with devices like the arduino.
• That same serial port can also be used to communicate with a transceiver via its CAT-interface
• The LCD touch-screen of the mini2440 provide an easy interface for user intaction
• The low power consumption mean that this boards can run on batteries for a very long time.

In addition to these hardware interfaces, the fact that these boards run a powerfull linux kernel and Operating System also provides a number of software advantages:

• As expected, the linux kernel provides standard support for all devices found on this boards
• In addition to this, almost all external devices that can be used on the USB ports are also supported by the kernel or can be included in the kernel
• The linux Operationg System provide all kinds of tools to manage and control the hardware interfaces of the system
• As linux is also used on all kinds of other embedded devices, there are a large number of free and open source developement tools for this platform
• As these boards are source-code compatible with their big PC counterparts, opensource software for these platforms can be ported to the ARM boards with very little or no modification.

Using a ARM development board as GMSK modem

As a first ham related project on a ARM developement board, I’ve started a software project to create a GMSK modem. This program is designed to work on any board from the mini2440 upwards. In the photo above, you can see it operational on the pandaboard as GMSK receiver.

Some information about it:

• The hardware requirements are as follows:
  1. A development board, as mentioned above, or any PC running linux.
  2. A USB “audio” fob
  3. A FM tranceiver with a “9k6″ dataport.
• The technical setup for the interconnection to the tranceiver can be found at the website of the freestar project.
• In my case, the connection is just a simple wire which have been soldered together. This is not what one would use in an “operational” setup as this will is very prune to interference. However, from a “developement” point of view, this is usefull to emulate bad quality radio-connections; something software needs to deal with.
• The current application is a GMSK D-STAR receiver. This means it receives a incoming D-STAR stream from the radio, demodulates and decodes it and stores in as a file on the development board.
• Parts of the code used in this project (especially “low-level” code for GMSK demodulation and decoding) comes from the “pcrepeatercontroller” project of Jonathan G4KLX. Some code did need to be adapted to make it work fast enough on the “mini2440″ board, as the CPU of this board does not have a FPU (Floating Point Unit).
• The code is open source and is currently in “alpha” stage. It is posted on github and can be downloaded via can be downloaded this link.

As mentioned, this is the first article in a series about this project. Other articles will be added soon.

73s

Kristoff – ON1ARF

16 November 2011

Ken, KE2N, has rapported that the URLs for the audio-files of the NOAA US weather rapports have been changed without notice.

They can now be found here: http://www.erh.noaa.gov/lwx/podcasts/mp3/

An example of a script that plays out the WX-rapport for the Washington DC metro areas is:

date >> /root/voice/wx1log
/usr/bin/./mplayer -really-quiet -vc null -vo null -srate 8000 -af channels=1 -ao pcm:file=/dev/stdout http://www.erh.noaa.gov/lwx/podcasts/mp3/WBCSAFNW1.mp3  | ./wavstream -t “WX RPT” -v -i 192.168.1.111 -p 40000 W4BRM b /dev/stdin id.wav 2>&1 | head -1000 >> wx1log

Thanks to Ken for the new links.

73

Kristoff ON1ARF

We have started a experimental internet-stream of module B of the D-STAR repeater in Oostende, ON0OS. This is a first test of the “D-STAR Audio Export Toolkit” (tempory name). The URL are:

• http://on0os.mine.nu/streams/on0os.m3u (windows/mac: use VLC, realplayer or winamp, linux: use anything you want  )
• http://on0os.mine.nu/livestream (javabased webstream, works on any browser)
• http://new.ophidian.be:8000/on0os (direct, works inside HTML5-complient webbrowsers like firefox, opera or chrome/chromium)

This stream is created inside the repeater using a DVdongle connected to the repeater. No D-STAR “radio” is involved.

The process uses a number of different tools:

• “cap2mc” intercepts the traffic between the repeater-gateway server (linux PC) and the repeater-controller (RPC2C) and rebroadcasts it as a local multicast-stream on the repeater. This is the only tool that needs to run as root.
• “ambedecode” subscribes to this multicast stream, select the AMBE digital-voice stream of one particular repeater-module, sends it to the DVdongle for decoding and rebroadcasts the resulting PCM audio stream as a second multicast stream.
• “pcm2out” subscribes to the PCM multicast stream and writes it to “standard out”, adding some comfort noise when no audio is being send.
• This PCM-stream is send to “ices”, the standard internet-streaming broadcasting client for the “icecast” internet-streaming server.

Other tools of this toolkit allow things like locally saving the AMBE or PCM-streams, or playing them out on the audio-card of the repeater (which can be linked to a local FM-transmittor using VOX control).

The internet-stream runs at around 32 Kbps VBR, using the vorbis audio-codec. Almost any unix or linux-based media-player (totem, xmmp, mplayer, vlc, …) is able to play this. For other platforms (windows, mac, …) use the cross-platform VLC media-player or natively inside the firefox or google chrome webbrowsers.

ON0OS/B is usually linked to either the dutch language REF028A (Belgium) or REF017A (the Netherlands) reflectors, or -at certain times- XRF017 (dutch language X-reflector), REF005A (UK) or REF001C (US) reflectors.

The program-code for this is still “alpha” code, but I hope to be able to make them public in about two weeks time. For questions or remarks, or are interested in co-developement of these applications, do drop me a message.

With thanks to Pieter ON3GPS to provide the server for the icecast streaming-server.

I have just posted version 0.2.1 of the voice-announcement software for Icom-based D-STAR repeaters.

As usual, it can be found here:
http://villazeebries.krbonne.net/dstar/voice-announce/

This version has been designed with one application in mind: streaming long audio-broadcasts to repeaters. Here are the details:

What is new?

• A new application: ambestream. This application allows a pre-encoded AMBE file (in the .dvtool or .ambe format) to be streamed out to a repeater or a reflector.
  It has been specific designed for streaming long audio-messages, using a 20 ms “heartbeat” generated by the linux-kernel for stability. This is needed because some soundcard-based repeater-platforms seams to have syncronisation-problems when playing out audio-messages of over 10 minutes.
• Both wavstream and ambestream have a number of new features:
  • DNS-lookup: this allows wavstream and ambestream to stream a digital voice message to both the local repeater or a remote repeater. This allows a audio-message to be streamed from any place on the internet (like a PC in your shack), so there is no need to actually have a DVdongle on the repeater to send broadcast streams on it
  • Streaming to a remote repeater can be done using the “callsign routing” protocol (UDP port 40000) and the “dextra” protocol (UDP port 30001)
  • Dextra linking: Send a voice message to a XRF reflector
  • The “mycall” setting. When streaming to remote repeaters, this allows the originator of the voice-message to identify himself/herself
  • “auto-break”: this is an option that is designed to deal with the fact that i-com repeater break of an voice-stream after -by default- 3 minutes. (see the “icom 3 minute” remarks below). Using the feature:
    • An ongoing transmission will automatically interrupt after a fixed interval (say 9.5 minutes)
    • The transmission will pause for a number of seconds
    • The transmission will restart, first repeating (up to) 4 seconds of the previous audio-segment
    • After that, the transmission will go on as before
  • Ipv6 support
• The two applications that deal with reading PCM .wav files (wav2ambe and wavstream) are now able to read PCM-streams from standard in, allowing unix “command piping”.
• Because of the new features, some cli-options have changed:
  • -i (ip-address) has become -d (destination). The -i option is still supported in this version but will dissapear in the future.
  • -d (dongle device) has become -dng
  • -h (help) now gives some (hopefully) interesting information

So what can we do with it?

Some examples:

• wavstream -v -my ON1ARF -t “very interesting” ON0ABC C shortmessage.wav
  Stream out a PCM .wav-file “shortmessage.wav” to module C of our local (i-com based) repeater (ON0ABC). This command needs to be run locally on the repeater.
  • the “verbose” option is set which will give more output
  • the message will be streamed with the “mycall” set to ON1ARF (which happens to be … my callsign. )
  • the text-message “very interesting” will be added in the audio-message
• wavstream  … -d 192.168.100.11 …
  The same as above, but for a soundcard-based repeater system (which listens to IP-address 192.168.100.11)
• wavstream -my ON1ARF -t “remote message” -d on0xyz.on.ircddb.net ON0XYZ B id.wav message.wav end.wav
  • Send a message to a remote repeater, found on IP-address “on0xyz.on.ircddb.net
  • The message will consist of three different wav-files: id.wav, message.wav and end.wav, played out in sequence
• wavstream -my ON1ARF -d xrf017.reflector.ircddb.net -p 30001 XRF017 B message.wav
• wavstream -dxl -my ON1ARF -d xrf017.reflector.ircddb.net XRF017 B message.wav
  Two variations of the same application: send a audio-message to the dextra reflector XRF017, module B
  • In the first example, NO dextra linking will be set up between the host where the streaming in initiated and the X-reflector. This can be the case where there already is a dextra link active between these two hosts; like when streaming from a repeater that is already linked to that particular reflector.
    Also note that the destination port has been set to port UDP 30001, which is the port used by the dextra protocol
  • In the latter example, a dextra linking setting is set up. This is needed when streaming from a host that is not already linked (like your PC in your shack) to a dextra reflector. In this case, the “-p 30001″ option is not necessairy as it implicitely set by the “-dxl” option
• wavstream -bi 28500 -bl 250 -br 200 ON0ABC C longmessage.wav
  • This will play out the audio-message “longmessage.wav”.
  • After 9 minute and 30 seconds, the transmission will be interrupted (9 min and 30 second = 570 second. 570 second * 50 frames / second = 28500)
  • The transmission will stop for 5 seconds (5 sec * 50 frames/sec = 250 frames)
  • After that, the last 4 seconds of the previous audio-segment will be repeated (4 sec * 50 frames/sec = 200 frames)
  • Finally, the transmission will continue
• date ‘+ the time is, %l, %M, %p ‘ | text2wave -F 8000 -o /dev/stdout | ./wavstream -t “speaking clock”  ON0ABC C -
  This is an example of a typical unix technique of stringing unix-commands one of the after and “pipe” the results of one command to the next on in line.
  • date ‘+ the time is, %I, %M, %p’ will give this result: (say) “the time is, 8, 30, pm”
  • this result is then fed to “text2wave” which will turn this into a spoken audio-message (inside a pcm-stream, sampled at 8000 bits per second)
  • Finaly, this audio-message is send to “wavstream”, which will send it out to the local D-STAR repeater (in this case, module C on repeater ON0ABC)
• mplayer -really-quiet -vc null -vo null -srate 8000 -af channels=1 -ao pcm:file=/dev/stdout http://www.erh.noaa.gov/nwr/lwx/WBCSAFNW1.mp3  | wavstream -t “Weather” ON0ABC “-” id.wav
  This is a very interesting one (with thanks to the person who provided this) . I’ll leave it to you to find out what it does.

Concerning Dextra linking

As you might have noticed, the option to enable dextra linking is “-dxl”, not “dx”. The reason is to stress what this option does: it sets up a parallel thread in the program that sets up a dextra link between the application that initiates the streaming and the remote gateway or reflector.
It is important to stress this word LINK, as one has to be aware of this for a very simple reason: you can not have more then one dextra link active between two hosts.
What does this mean?

• There have also been rapport of hams that have reversed engineered the protocol used between the IDRP2C.exe application and the RP2C repeater-controller. It has been rapported that, by using “nc -u” on the repeater gateway-server, it is possible send direct specially crafted UDP packets to the RP2C, which will change this time-out value for values of over 30 minutes.
• The “auto-break” feature of wavstream and ambestream can also be used to automatically break up the audio-messages in segments of (say) 9.5 minutes.
• Of course, it is also possible to break up the audio-broadcast manually in segments of less then 10 minutes.

THANK YOU

This application is the result of help I have received by a number of people: beta-testers and people who provided certain pieces of information needed for this.
For reasons of privacy, I will not publish the name and/or callsign for everybody but … I think that the people who have helped me are aware of that, so .. my “thank you” to you!
Have fun!!!

73

kristoff ON1ARF

monday 28/03/2011