412 replies to this topic

[waterpas]

Thanks a lot!!

[Matrix10]

Thanks a lot!!

 

If you look a little bit better, this antenna has several resonant points inside the DAB frequency range, which naturally gives a better result than a simple vertical telescopic antenna.

Of course you can go with more dipoles

and have greater frequency bandwidth on which you can use antenna.

[Matrix10]

I have a question if someone knows ???

 

Does any of the existing images have a good driver for DVB-T / T2 and RTL SDR/ R820T2 RTL2832U

 

[Tech]

It is not available (yet) for OpenPLi, so you need to install the needed packages by hand.

[Matrix10]

It is not available (yet) for OpenPLi, so you need to install the needed packages by hand.

 

Which packages?

I do not have them.

[jpuigs]

Today dab-cmdline-sdgradio packages have been updated, and PCM doesn't work at all (DAB).

 

I have downgraded dab-cmdline-sdgradio-pcm from 1.2+git198+beaa71d-r0 to 1.2+git186+5b3f8e6-r0 (the last one attached several pages before this one) and it works again

[athoik]

Most probably that commit causes the issues: https://github.com/J...2ebca704e1f14e5

If somebody has time to step on it and fix it would be nice, or at least provide some debug on dab-cmdline author in order to fix the bug.

[jpuigs]

dab-cmdline-sdgradio-pcm - 1.2+git199+edb7514-r0 seems to gix it.

[athoik]

Hi,

Here is a benchmark of viterbi algorithm (available from spiral.net http://www.spiral.ne.../viterbi.html).

The MIPS doesn't have enough power, that's why it doesn't work (yet?).

During the test I stopped enigma2 (init 4) in order to ensure that program was using full power of receiver.

The Os / O2 / O4 is the optimization flag used to compile viterbi test program. Next to program also there is the unstripped size and stripped size.

osninoplus: MIPS BCM73625

vusolo4k: ARM BCM7376
 

root@osninoplus:~# ./viterbi.mips.Os (30K / 20K)
Code specifications:
         rate = 1/4
         K = 7 (thus 64 states)
         frame size = 2048 (thus padded frame size = 2054)
         polynomials = { 109, 79, 83, 109 }

Computing error rates over 10000 frames, ebn0 = 3.00 dB, gain = 32
BER 3063/20480000 (   0.00015) FER 761/10000 (    0.0761)

Verification: Error rates of a generic decoder
BER 3063/20480000 (   0.00015) FER 761/10000 (    0.0761)

Execution time for 10000 2054-bit frames: 31.58 sec
decoder speed: 648.43 kbits/s


root@osninoplus:~# ./viterbi.mips.O2 (30K / 20K)
Code specifications:
         rate = 1/4
         K = 7 (thus 64 states)
         frame size = 2048 (thus padded frame size = 2054)
         polynomials = { 109, 79, 83, 109 }

Computing error rates over 10000 frames, ebn0 = 3.00 dB, gain = 32
BER 3063/20480000 (   0.00015) FER 761/10000 (    0.0761)

Verification: Error rates of a generic decoder
BER 3063/20480000 (   0.00015) FER 761/10000 (    0.0761)

Execution time for 10000 2054-bit frames: 28.06 sec
decoder speed: 729.891 kbits/s

root@osninoplus:~# ./viterbi.mips.O4 (32K / 22K)
Code specifications:
         rate = 1/4
         K = 7 (thus 64 states)
         frame size = 2048 (thus padded frame size = 2054)
         polynomials = { 109, 79, 83, 109 }

Computing error rates over 10000 frames, ebn0 = 3.00 dB, gain = 32
BER 3063/20480000 (   0.00015) FER 761/10000 (    0.0761)

Verification: Error rates of a generic decoder
BER 3063/20480000 (   0.00015) FER 761/10000 (    0.0761)

Execution time for 10000 2054-bit frames: 28.09 sec
decoder speed: 729.085 kbits/s

=====================================================


root@vusolo4k:~# ./viterbi.arm.Os (28K / 19K)
Code specifications:
         rate = 1/4
         K = 7 (thus 64 states)
         frame size = 2048 (thus padded frame size = 2054)
         polynomials = { 109, 79, 83, 109 }

Computing error rates over 10000 frames, ebn0 = 3.00 dB, gain = 32
BER 3063/20480000 (   0.00015) FER 761/10000 (    0.0761)

Verification: Error rates of a generic decoder
BER 3063/20480000 (   0.00015) FER 761/10000 (    0.0761)

Execution time for 10000 2054-bit frames: 9.57 sec
decoder speed: 2140.02 kbits/s


root@vusolo4k:~# ./viterbi.arm.O2 (28K / 19K)
Code specifications:
         rate = 1/4
         K = 7 (thus 64 states)
         frame size = 2048 (thus padded frame size = 2054)
         polynomials = { 109, 79, 83, 109 }

Computing error rates over 10000 frames, ebn0 = 3.00 dB, gain = 32
BER 3063/20480000 (   0.00015) FER 761/10000 (    0.0761)

Verification: Error rates of a generic decoder
BER 3063/20480000 (   0.00015) FER 761/10000 (    0.0761)

Execution time for 10000 2054-bit frames: 7.54 sec
decoder speed: 2716.18 kbits/s


root@vusolo4k:~# ./viterbi.arm.O4 (32K / 23K)
Code specifications:
         rate = 1/4
         K = 7 (thus 64 states)
         frame size = 2048 (thus padded frame size = 2054)
         polynomials = { 109, 79, 83, 109 }

Computing error rates over 10000 frames, ebn0 = 3.00 dB, gain = 32
BER 3063/20480000 (   0.00015) FER 761/10000 (    0.0761)

Verification: Error rates of a generic decoder
BER 3063/20480000 (   0.00015) FER 761/10000 (    0.0761)

Execution time for 10000 2054-bit frames: 7.53 sec
decoder speed: 2719.79 kbits/s

The O2 produce nice results, without increasing the size a lot.

(We compile by default all images using Os flag, in order to reduce binary size, but today's boxes have plenty of flash. Maybe we need to switch back to default O2.)


The ARM binary is more than 3x faster than MIPS!


The x64 binary on Intel® Xeon® CPU E3-1245 V2 @ 3.40GHz and on Intel® Core™ i7-4980HQ CPU @ 2.80GHz is almost 3x faster than ARM, and of course there also an SSE version.

Execution time for 10000 2054-bit frames: 2.32 sec
decoder speed: 8827.59 kbits/s
Execution time for 10000 2054-bit frames: 2.46 sec
decoder speed: 8311.69 kbits/s

The SSE 4-way version is much faster...

Execution time for 10000 2054-bit frames: 0.70 sec
decoder speed: 29257.1 kbits/s

The SSE 16-way version is screaming...

Execution time for 10000 2054-bit frames: 0.28 sec
decoder speed: 73142.9 kbits/s

Somebody to create a SIMD version for NEON please?

Attached Files

•  verify_viterbi.zip   70.53KB   5 downloads

[Erik Slagter]

Maybe it could split to be make use of the second thread of the processor.

[athoik]

Maybe it could split to be make use of the second thread of the processor.

I think dab-cmdline already uses several threads to spread the load. Not sure if multi-threading is used when performing viterbi decoding.

Anyway I was able to use the 4 way SSE with NEON instructions thanks to SSE2NEON (https://github.com/j...ster/SSE2NEON.h)

I compiled using default "OE" values and using cortex-a7 mcpu, cortex-a7 produces slightly better results.
 

root@vusolo4k:~# ./viterbi.arm.neon
Code specifications:
         rate = 1/4
         K = 7 (thus 64 states)
         frame size = 2048 (thus padded frame size = 2054)
         polynomials = { 109, 79, 83, 109 }

Computing error rates over 10000 frames, ebn0 = 3.00 dB, gain = 32
BER 3063/20480000 (   0.00015) FER 761/10000 (    0.0761)

Verification: Error rates of a generic decoder
BER 3063/20480000 (   0.00015) FER 761/10000 (    0.0761)

Execution time for 10000 2054-bit frames: 6.14 sec
decoder speed: 3335.5 kbits/s


root@vusolo4k:~# ./viterbi.arm.cortex-a7.neon-vfpv4
Code specifications:
         rate = 1/4
         K = 7 (thus 64 states)
         frame size = 2048 (thus padded frame size = 2054)
         polynomials = { 109, 79, 83, 109 }

Computing error rates over 10000 frames, ebn0 = 3.00 dB, gain = 32
BER 3063/20480000 (   0.00015) FER 761/10000 (    0.0761)

Verification: Error rates of a generic decoder
BER 3063/20480000 (   0.00015) FER 761/10000 (    0.0761)

Execution time for 10000 2054-bit frames: 5.94 sec
decoder speed: 3447.81 kbits/s

I am sure that NEON instructions can produce better results, once used right.

As I said before (I think I mention it) there is a NEON (and SSE)viterbi decoder available here:

https://github.com/t...src/conv_neon.h
https://github.com/t.../src/conv_dec.c

Most probably we need something like the following.. (But I have no idea how to integrate it to dab-cmdline).
 

int conv_decode_p4(const int8_t *in, uint8_t *out)
{
	const struct lte_conv_code code = {
		.n = 4,
		.k = 7,
		.len = 2048,
		.gen = { 109, 73, 83, 109 },
		.term = CONV_TERM_TAIL_BITING,
	};
	int rc;

	struct vdecoder *vdec = alloc_vdec(&code);
	if (!vdec)
		return -EFAULT;

	reset_decoder(vdec, code.term);

	/* Propagate through the trellis with interval normalization */
	_conv_decode(vdec, in, code.len);

	if (code.term == CONV_TERM_TAIL_BITING)
		_conv_decode(vdec, in, code.len);

	rc = traceback(vdec, out, code.term, code.len);

	free_vdec(vdec);
	return rc;
}

Edited by athoik, 24 February 2018 - 13:02.

[Loui (PD1LOI)]

 

Thanks @Tech

 

for Open BH i have already made the package ready for installation

(info and files on BH forum)

I hope for even greater interest for RTL SDR

 

Just offtopic

Isn't this a site https://www.welle.io/ where you can borrow some examples hi?

This works perfectly.

[athoik]

The latest version of dab-cmdline works really good.

I guess will be available with 7.3.

[littlesat]

Would be nice when someone make a kind of interface so we can add them to the userbouquets ..
I use such a stick to listen to ham radio... in direct sampling mode...
But here the stick is also working in an vuultimo 4K...
For dab+

Edited by littlesat, 19 May 2020 - 19:54.

[Tech]

I use the stick in a VuDuo4k and it works like a charm, but indeed, a proper way to insert the Dab+ channels into a channellist, would be nice.

[littlesat]

It requires some cpp knowledge

[Frenske]

Hadn’t someone ever come up with a plan that HRO would be relieved by launching an automated process involving some of our members where the monthly channelupdate from HRO would be updated automatically. If I recall right this plan was made somewhere around the 10th anniversary of the transponder, the satelliteclub in Apeldoorn. I’m afraid that those who were supposed to participate in this project, HRO and Littlesat, never ever heard from the initiators again. If that scenario actually had worked then it would have been nice if a DAB + list was added. Although I only listen to DAB+ in my bedroom it would have been nice when this was possible on for instance the Ultimo 4K.

[Pr2]

Sorry but not everybody is using pre-defined list (I personally prefer to handle my channel list myself), so to have a user friendly way to include DAB+ radio into the Radio userbouquet list is welcome.

[athoik]

I added the possibility to "stream" the data returned by dab-cmdline using dabstreamer.

 

https://github.com/s...3f7b87ea9cdd454

    Add dab-cmdline utility that accepts channel, gain and program (in hex).
    Eg http://localhost:5237/dab/12C/50/1001

Here I am starting dabstreamer manually (using channel 12C, gain 50 and program 1001) and I am listening dab+ from VLC

root@osmio4kplus:~# /etc/init.d/dabstreamer manualstart
Fri May 22 20:08:59 2020 Server Starts - :5237
192.168.0.2 - - [22/May/2020 20:09:05] "GET /dab/12C/50/1001 HTTP/1.1" 200 -
192.168.0.2 - - [22/May/2020 20:09:05] Parameters: /dab/12C/50/1001
192.168.0.2 - - [22/May/2020 20:09:05] Using command dab-rtlsdr-sdgradio-pcm -C 12C -G 50 -S 1001 | ffmpeg -f s16le -channels 2 -r 48000 -i pipe:0 -f wav pipe:1
192.168.0.2 - - [22/May/2020 20:10:42] Got Socket Exception [Errno 32] Broken pipe
192.168.0.2 - - [22/May/2020 20:10:42] "GET /dab/12C/50/1001 HTTP/1.1" 200 -
192.168.0.2 - - [22/May/2020 20:10:42] Parameters: /dab/12C/50/1001
192.168.0.2 - - [22/May/2020 20:10:42] Using command dab-rtlsdr-sdgradio-pcm -C 12C -G 50 -S 1001 | ffmpeg -f s16le -channels 2 -r 48000 -i pipe:0 -f wav pipe:1

PS. I used ffmpeg to "mux" raw pcm into wav, because VLC cannot understand raw pcm, produced from dab-rtlsdr-sdgradio-pcm.

 

 

Adding the following on a bouquet works as well (you need dabstreamer starting automatically from init.d)

#SERVICE http://localhost:5237/dab/12C/50/1001

Of course dab-cmdline still is using lot of cpu, a proper NEON optimizer is missing to reduce load from viterbi decoding, but it works

 

Attached Files

•  4097_0_0_0_0_0_0_0_0_0_20200522204823.jpg   110.01KB   6 downloads

[littlesat]