Poor signal with activated TII

[andimik]

I tried to activate TII but then my Sticks and radios either don't lock at all or get a very poor signal (Microspot 4 squares instead of 16).

Seems the null symbol causes a gain issue on the receiver side.

[mpbraendli]

What version did you use?

[andimik]

The latest from the next. I've posted the version in the (closed) issue about edi.

[andimik]

ODR-DabMod version v2.0.0-26-g9ef3824, compiled at May 13 2018

[andimik]

Digital gain is 0.8

[mpbraendli]

Ok. I also used next to do a test, enabling/disabling TII with the remote-control. I wasn't able to see any effect on my receivers :-/ Can you post your .ini file in a github gist or on https://paste.ubuntu.com/ and send me a link?

[andimik]

Well, now I remember. When I started the issue I still had Ubuntu 16.04. Some days ago I re-installed a clean 18.04 Kubuntu. And tested it again right now. Seems we can close now.

[andimik]

btw: My ini is:

[input]
transport=file
source=/dev/stdin
loop=1

[modulator]
gainmode =1
rate=2048000
digital_gain=0.8

[output]
output=file

[fileoutput]
format=s8
filename=/dev/stdout

[tii]
enable=1
comb=4
pattern=11
old_variant=0

more foo.eti | odr-dabmod foo.ini | hackrf_transfer -t - -f 215072000 -x 25 -a 1 -s 2048000 -b 1750000

[ghost]

Hello,

I'm surprised that this can work because you are using the native sampling rate which does not push the image frequencies far enough into the stop-band of the 1.75 MHz monolithic filter inside the transceiver chip. Trust me - it looked truly awful on a spectrum analyser!.;-D

If you have sufficient cpu resources, try to operate odr-dabmod and hackrf_transfer at a higher sampling rate, ideally at least 4.096M. It will clean up your signal a lot and the image won't be there to clobber reception. Disable the FIR filter if you have too because it would still much better than the close-in image interference.

Hope this is useful!

R.

On 16 May 2018 at 19:15, andimik notifications@github.com wrote:

btw: My ini is:

[input] transport=file source=/dev/stdin loop=1

[modulator] gainmode =1 rate=2048000 digital_gain=0.8

[output] output=file

[fileoutput] format=s8 filename=/dev/stdout

[tii] enable=1 comb=4 pattern=11 old_variant=0

more foo.eti | odr-dabmod foo.ini | hackrf_transfer -t - -f 215072000 -x 25 -a 1 -s 2048000 -b 1750000

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Opendigitalradio/ODR-DabMod/issues/24#issuecomment-389615764, or mute the thread https://github.com/notifications/unsubscribe-auth/AIbPH7pf41K-ufXSFBCW1Hfu-eq5WsT7ks5tzGzbgaJpZM4Tz6_J .

[andimik]

Ok thanks, I'll try that instead.

[mpbraendli]

If you read from a file, better specify the filename in the .ini over using more. cat would be more appropriate (pun not intended) because more is a pager, it could actually mess with file contents. Thanks for reporting issues, even if this was (luckily) a false positive!

[andimik]

Ok, thanks.

I also had to change rate=2048000 in the ini-file to 4096k.

[andimik]

Well, I don't see a difference between 4M and 2M beside of higher traffic and CPU usage. Signal is the same. Both work here.

[mpbraendli]

How do you measure your signal? Do you have a spectrum analyser?

[andimik]

Qt-dab

[mpbraendli]

qt-dab doesn't show a wide enough bandwidth, so you won't see the effect Rash is talking about.

[andimik]

4096k and CPU usage 40% 2048k and CPU usage 35%

For testing (and helping FMSCAN to be updated with CSV files from Andreas Gsinn's Player) this is absolutely ok.

[mpbraendli]

Sure. It's interesting to see that the spectrum looks a bit flatter in 4096ksps. Maybe it's just an impression though. As long as you are aware of the limitations and consequences of using 2048ksps, this is fine.