Re: [digitalradio] Re: Mode of the Day? RS ID on SdR bandwidth
I've just looked at Vojtech's code, it seems reasonable *and* he's resampling from 8kHz up to 11.025kHz. If I can get this working (and why not!) then I suggest we attempt to for a standard for the RSID codes similar to the SSTV VIS codes, maybe even storing the standard in this forum. This will really help when not using a 'standard' mode such as PSK31, 63 or RTTY. Simon Brown, HB9DRV www.ham-radio-deluxe.com - Original Message - From: Vojtech Bubnik bubn...@seznam.cz My code is derived from Patrick's, only I heavily optimized it to be executed on a less powerful fixed point arithmetics CPU. I am obsessed with optimization to increase battery life of the Pocket PC device.
Re: [digitalradio] Re: Mode of the Day? RS ID on SdR bandwidth
Well done Simon, this would be a good collaboration. Andy K3UK On Sat, May 2, 2009 at 10:49 AM, Simon (HB9DRV) simon.br...@kns.ch wrote: I've just looked at Vojtech's code, it seems reasonable *and* he's resampling from 8kHz up to 11.025kHz. If I can get this working (and why not!) then I suggest we attempt to for a standard for the RSID codes similar to the SSTV VIS codes, maybe even storing the standard in this forum. This will really help when not using a 'standard' mode such as PSK31, 63 or RTTY. Simon Brown, HB9DRV www.ham-radio-deluxe.com
Re: [digitalradio] Re: Mode of the Day? RS ID on SdR bandwidth
No - it's sent in the center frequency and indicates the mode being used. For robustness it could be sent a few times maybe... If you can't decode the RS ID then you'll probably not decode the mode being used anyway. Simon Brown, HB9DRV www.ham-radio-deluxe.com - Original Message - From: Rud Merriam k5...@arrl.net The RSID is good but is it overly complicated?
Re: [digitalradio] Re: Mode of the Day? RS ID on SdR bandwidth
THEN MODE:='RTTYM-8-250' ELSE
IF NUMBER=62 THEN MODE:='RTTYM-16-500' ELSE
IF NUMBER=63 THEN MODE:='RTTYM-32-1000' ELSE
IF NUMBER=65 THEN MODE:='RTTYM-8-500' ELSE
IF NUMBER=66 THEN MODE:='RTTYM-16-1000' ELSE
IF NUMBER=67 THEN MODE:='RTTYM-4-500' ELSE
IF NUMBER=68 THEN MODE:='RTTYM-4-250' ELSE
{OLIVIA parameter 1 parameter 2 (parameter 1: 4 (4 tones), 8 (8
tones), 16 (16 tones), 32 (32 tones), parameter 2: 250 (B=250 Hz),
500 (B=500 Hz) or 1000 (B=1000 Hz))
Examples: OLIVIA-32-1000 or OLIVIA-8-500
Note: the following are the main Olivia modes: OLIVIA-4-250, OLIVIA-4-500,
OLIVIA-8-250, OLIVIA-8-500, OLIVIA-16-500, OLIVIA-16-1000, OLIVIA-32-1000}
IF NUMBER=69 THEN MODE:='OLIVIA-8-250' ELSE
IF NUMBER=70 THEN MODE:='OLIVIA-16-500' ELSE
IF NUMBER=71 THEN MODE:='OLIVIA-32-1000' ELSE
IF NUMBER=72 THEN MODE:='OLIVIA-8-500' ELSE
IF NUMBER=73 THEN MODE:='OLIVIA-16-1000' ELSE
IF NUMBER=74 THEN MODE:='OLIVIA-4-500' ELSE
IF NUMBER=75 THEN MODE:='OLIVIA-4-250' ELSE
IF NUMBER=76 THEN MODE:='PAX' ELSE
IF NUMBER=77 THEN MODE:='PAX2' ELSE
IF NUMBER=78 THEN MODE:='DOMINOF' ELSE
IF NUMBER=79 THEN MODE:='FAX' ELSE
{the sub-modes SSTV are automatically recognized in SSTV so no parameters
are needed for SSTV}
IF NUMBER=81 THEN MODE:='SSTV' ELSE
{DOMINOEX parameter 1 and optionally parameter 2 (parameter 1: 4 (4
baud) , 5 (5 bauds),
8 (8 bauds), 11 (11 bauds), 16 (16 bauds), 22 (22 bauds),
parameter 2 (no parameter 2 for non-FEC) or FEC (for FEC correction))
Example: DOMINOEX-11 or DOMINOEX-16-FEC (parameter 2 is optional)}
IF NUMBER=84 THEN MODE:='DOMINOEX-4' ELSE
IF NUMBER=85 THEN MODE:='DOMINOEX-5' ELSE
IF NUMBER=86 THEN MODE:='DOMINOEX-8' ELSE
IF NUMBER=87 THEN MODE:='DOMINOEX-11' ELSE
IF NUMBER=88 THEN MODE:='DOMINOEX-16' ELSE
IF NUMBER=90 THEN MODE:='DOMINOEX-22' ELSE
IF NUMBER=92 THEN MODE:='DOMINOEX-4-FEC' ELSE
IF NUMBER=93 THEN MODE:='DOMINOEX-5-FEC' ELSE
IF NUMBER=97 THEN MODE:='DOMINOEX-8-FEC' ELSE
IF NUMBER=98 THEN MODE:='DOMINOEX-11-FEC' ELSE
IF NUMBER=99 THEN MODE:='DOMINOEX-16-FEC' ELSE
IF NUMBER=101 THEN MODE:='DOMINOEX-22-FEC' ELSE
IF NUMBER=104 THEN MODE:='FELD HELL' ELSE
IF NUMBER=105 THEN MODE:='PSK HELL' ELSE
IF NUMBER=106 THEN MODE:='HELL 80' ELSE
{FMHELL parameter 1 (parameter 1: 105 (105 bauds) or 245 (245
bauds)),
Example: FMHELL-245}
IF NUMBER=107 THEN MODE:='FM HELL-105' ELSE
IF NUMBER=108 THEN MODE:='FM HELL-245' ELSE
IF NUMBER=110 THEN MODE:='QPSK31' ELSE
{PACKET parameter 1 (parameter 1: 110 (bauds),Example: PACKET-110}
IF NUMBER=113 THEN MODE:='PACKET-110' ELSE
IF NUMBER=114 THEN MODE:='141A' ELSE
IF NUMBER=116 THEN MODE:='OLIVIA-8-1000' ELSE
IF NUMBER=117 THEN MODE:='CONTESTIA-8-1000' ELSE
IF NUMBER=119 THEN MODE:='RTTYM-8-1000' ELSE
IF NUMBER=123 THEN MODE:='DTMF' ELSE
IF NUMBER=125 THEN MODE:='ALE400' ELSE
IF NUMBER=126 THEN MODE:='BPSK250' ELSE
IF NUMBER=127 THEN MODE:='QPSK250' ELSE
IF NUMBER=131 THEN MODE:='FDMDV' ELSE
IF NUMBER=132 THEN MODE:='JT65-A' ELSE
IF NUMBER=134 THEN MODE:='JT65-B' ELSE
IF NUMBER=135 THEN MODE:='JT65-C' ELSE
IF NUMBER=136 THEN MODE:='THOR-4' ELSE
IF NUMBER=137 THEN MODE:='THOR-8' ELSE
IF NUMBER=138 THEN MODE:='THOR-16' ELSE
IF NUMBER=139 THEN MODE:='THOR-5' ELSE
IF NUMBER=143 THEN MODE:='THOR-11' ELSE
IF NUMBER=145 THEN MODE:='THOR-22' ELSE
IF NUMBER=146 THEN MODE:='THROBX-4' ELSE
IF NUMBER=147 THEN MODE:='MFSK32' ELSE
IF NUMBER=148 THEN MODE:='MFSK11' ELSE
IF NUMBER=152 THEN MODE:='MFSK22' ELSE
IF NUMBER=153 THEN MODE:='CALL ID' ELSE
{PACKET parameter 1 (parameter 1: PSKbauds)}
IF NUMBER=155 THEN MODE:='PACKET-PSK1200' ELSE
IF NUMBER=156 THEN MODE:='PACKET-PSK250' ELSE
IF NUMBER=159 THEN MODE:='PACKET-PSK63';
- Original Message -
From: Simon (HB9DRV) simon.br...@kns.ch
To: digitalradio@yahoogroups.com
Sent: Saturday, May 02, 2009 4:49 PM
Subject: Re: [digitalradio] Re: Mode of the Day? RS ID on SdR bandwidth
I've just looked at Vojtech's code, it seems reasonable *and* he's
resampling from 8kHz up to 11.025kHz.
If I can get this working (and why not!) then I suggest we attempt to for
a
standard for the RSID codes similar to the SSTV VIS codes, maybe even
storing the standard in this forum.
This will really help when not using a 'standard' mode such as PSK31, 63
or
RTTY.
Simon Brown, HB9DRV
www.ham-radio-deluxe.com
- Original Message -
From: Vojtech Bubnik bubn...@seznam.cz
My code is derived from Patrick's, only I heavily optimized it to be
executed on a less powerful fixed point arithmetics CPU. I am obsessed
with optimization to increase battery life of the Pocket PC device.
Announce your digital presence via our Interactive Sked Pages at
http://www.obriensweb.com/sked
Recommended digital mode software: Winwarbler, FLDIGI, DM780, or Multipsk
Logging Software: DXKeeper or Ham Radio Deluxe.
Yahoo! Groups Links
Re: [digitalradio] Re: Mode of the Day? RS ID on SdR bandwidth
What do other developers think about the Definitive List of RS-ID codes being maintained here? I suggest all programs should display this list if requested by the user together with the version number. I'll be away on holiday for two weeks and will try to get the code working while I'm away. I wonder whether the RS ID idea could be / should be extended to optionally include a callsign? Once I get the code integrated into DM780 I'll be able to make more sensible suggestions. Simon Brown, HB9DRV www.ham-radio-deluxe.com - Original Message - From: Andy obrien k3uka...@gmail.com Well done Simon, this would be a good collaboration.
Re: [digitalradio] Re: Mode of the Day? RS ID on SdR bandwidth
- Original Message - From: Patrick Lindecker f6...@free.fr The best way would be that some digital association manages this (as for the SSTV codes, however I don't know who manages this SSTV list...) . No-one, as far as I know I'm the only person writing / maintaining SSTV code. Call ID: I have created an extension of a specific RS ID, called Call ID (the code in Pascal will be available with the 4.14 version as I have added a Prop ID). OK - I suggest we (you) send Mode ID then sender Callsign (optional). XML file?: it's surely very powerful but I don't know this technic, in fact. However, it's just a list with an identifier for a mode string, so a serie of IF is sufficient. XML is for professionals like yourself :) Simon Brown, HB9DRV www.ham-radio-deluxe.com
[digitalradio] Re: Mode of the Day? RS ID on SdR bandwidth
Hi Patrick and Simon. My code is derived from Patrick's, only I heavily optimized it to be executed on a less powerful fixed point arithmetics CPU. I am obsessed with optimization to increase battery life of the Pocket PC device. I am refering to PocketDigi source code, misc/rsid.c. I believe fldigi used my source code as a starting point. rsid_search function receives samples @ 11025 and calculates 1024 point real FFT each time 1024 new samples are received. Therefore the FFT intervals overlap by one half. The sound card runs at 8 kSamples per second, but I have a resampler running outside of the rsid code to resample to 11025. Also the resampler takes care of the sound card clock correction. I have another resampler running for clock correction from 8ksamples to 8ksamples, but this one is only executed if clock adjustment is different from zero to save some battery time. Also resampling with fixed point arithmetics add some error. The main speed up of Patrick's search routine is done by hashing. In case of RSID we are happy enough that it is possible to setup reverse lookup tables, which have no duplicate hits. The tables are setup in rsid_init. Encoded RSID code consists of 15 nibbles. Patrick decided to only accept a code as valid if it has zero or one error. I therefore prepared two reverse lookup tables from encoded RSID code consisting from 15 nibbles to the mode identifier index, which fits into single byte. Each of the reverse lookup tables have 256 entries, some of them may be empty - they lead to invalid RSID code. The first table is indexed by first and second nibble of encoded RSID, the other table with third and fourth nibble of encoded RSID. The idea behind it is that if there is a single bit error in the first two nibbles, there will be no error in the third and fourth nibble. After the two tables are resolved, the received code hamming distance is verified as in Patrick's original source code. My optimization consists therefore mainly in saving some 100 calls of Hamming distance calculation by using two table lookups, gaining probably speedup of about 50x. Another optimization is in CalculateBuckets(), which calculates maximum of 16 successive tones. It uses result of previous sweep in most cases. This probably speeds up the function about 4x. Not that significant if compared to the hashing trick, but after the hashing was implemented, even this little optimization becomes useful. I believe now the RSID decoding time depends mostly on the real FFT routine. My encoder generates phase coherent MFSK signal @ 8000, no resampling to 11025 is necessary. TX is done in main/trx.c, mainly in trx_txstate(), see case with TRX_STATE_TXRSID_TONE0 to 14. 73, Vojtech --- In digitalradio@yahoogroups.com, Patrick Lindecker f6...@... wrote: Simon, Why must the sampling frequency be 11025? because the Fourier is done with 2048 samples at 11025 samples/sec. At 8000, the number of samples would not be a power of 2 and this Fourier could not be a FFT but a standard digital Fourier (DFT) which takes times to do. So the simplest way is to base all on 11025. For more details, read the RS_ID_English.doc file in http://f6cte.free.fr/PAPERS.ZIP 73 Patrick - Original Message - From: Simon (HB9DRV) To: digitalradio@yahoogroups.com Sent: Thursday, April 16, 2009 10:54 PM Subject: Re: [digitalradio] Mode of the Day? RS ID on SdR bandwidth Hi, Why must the sampling frequency be 11025? Simon Brown, HB9DRV www.ham-radio-deluxe.com - Original Message - From: Patrick Lindecker No problem, but I program in Pascal not in C...(Votjech did a C source). The sampling frequency must be 11025, but it is not a problem to work at 8000.
Fw: [digitalradio] Re: Mode of the Day? RS ID on SdR bandwidth
Sure, What's the actual interface? I don't see a simple description anywhere on the website :( Simon Brown, HB9DRV www.ham-radio-deluxe.com - Original Message - From: Vojtech Bubnik bubn...@seznam.cz To: digitalradio@yahoogroups.com Sent: Sunday, April 19, 2009 3:02 PM Subject: [digitalradio] Re: Mode of the Day? RS ID on SdR bandwidth Hi Simon. I have one pledge. Would you please integrate the ATS-3b interface into your digital modes software? ATS-3b is a transceiver fitting into Altoids tin, which supports generating of BPSK and MFSK signals with its DDS. TX is controlled with special protocol over sound card. It should not be difficult to integrate it into your software, it would only make your TX code a bit less readable. The code is available in PocketDigi. http://www.kufr.cz/~ok1iak/HAM/ATS3a-digital/index.php3 I am asking for it because right now only PocketDigi supports this interface. Although PocketDigi runs on desktop, it was developed primarily for Pocket PC and it is very rudimentary. Also I hope (maybe blindly) that the concept of DDS generated digital modes will be adapted by other QRP kits one day. With the class-D PA and circuit simplicity it should be tempting to design a digital modes transceiver for battery operation, for example for the EMCOM folks.
