PDA

View Full Version : DReaM - latest Improvements


Pages : [1] 2

DigiBC
17-07-2004, 21:46
Hi,

it's very interesting to follow the development of the Open-Source software DReaM.

If compiled from the latest CVS sources (http://cvs.sourceforge.net/viewcvs.py/drm/drm/?sortby=date#dirlist) (published at SourceForge.net) you will notice some exciting improvements:
There's a new option in the Evaluation Dialogue: Audio Spectrum
If the button is activated the graphic display will show the frequency spectrum of the decoded audio. It's not very detailed but you get a good impression about the audio bandwidth of the transmitted DRM signal (see attached screenshot).
DReaM scans the entire frequency range of the soundcard to find a DRM signal and that can take some time. If your receiver supplies a stable IF signal (e.g. 12 kHz) you can narrow the search window for the frequency acquisition by starting the program with command line arguments -E and -S.
Example: "dream -E 12000 -S 100" would mean, that the search window is centered around 12 kHz and the width is 100 Hz.
In transmitter mode (command line argument -t) DReaM is now not only able to generate a picture (MOT) slide show but to encode AAC audio!
The sound quality is still rather poor (AAC Mono without SBR) as the used FAAC library isn't optimized for DRM (yet). Nevertheless you can do some interesting experiments.
(How to get the DReaM transmitter AAC capable is explained here (http://sourceforge.net/forum/forum.php?thread_id=1103756&forum_id=242204).)There's only one really important feature still missing: Stereo decoding.
I wouldn't be surprised if that would be achieved within the next few month... :)

Regards - DigiBC

PaulButler
23-07-2004, 23:28
I'm using a WinRadio G303i with its own DRM demodulator, or with the DRM Software Radio, or with DREAM (1.07 - is this the latest?).

DREAM gives me lots of graphical displa but I don't know what I'm looking at. W get so few usable DRM signals in Melbourne that I'm not sure what the graphs should look like for a good signal.

Does anyone have screenshots of these displays under strong signal conditions? And an explanation of what they show?

Paul VK3DBP Melbourne

PS I'm waiting for the G313, preferably the USB version, for which WinRadio promises an even better demodulator!

ka2hzo
24-07-2004, 00:58
PS I'm waiting for the G313, preferably the USB version, for which WinRadio promises an even better demodulator!


Me too.

DigiBC
24-07-2004, 10:00
Hi,

the latest source code of DReaM (1.0.8cvs) is provided in the CVS Repository at SourceForge.net (http://cvs.sourceforge.net/viewcvs.py/drm/drm/).

There's an online documentation (http://www.tu-darmstadt.de/fb/et/uet/fguet/mitarbeiter/vf/DRM/documentation.html) available but it's a bit outdated.
If you want to know more about the functions and displays of the "Evaluation Dialog" compile the latest version and use the help button (?).

Nevertheless I'm going to take a few screenshots and publish them to the web...

Regards - DigiBC


PS:
I'd rather prefer an USB version of the WR-G303, because the new WR-G313 USB will be based on the WR-G313i (PCI card) which is mainly DSP based so that there's no 12 kHz IF output for other decoder software like the DRM Software Radio and DReaM. :(

PaulButler
24-07-2004, 10:57
Agreed. But the G303 DRM demodulator will not be developed further, while the G313 will have a notch filter and other features. It will be WinRadio flagship, not the G303.

As I've said before, those of us for whom DRM is DX need every feature we can get.

Having said that, we also need the flexibilty to use DRM Software Radio and DREAM as well as the WinRadio demodulator.

We want everything, don't we?

Paul VK3DBP Melbourne

DRM-Fan
24-07-2004, 14:06
Originally posted by DigiBC
Hi,

the latest source code of DReaM (1.0.8cvs) is provided in the CVS Repository at SourceForge.net (http://cvs.sourceforge.net/viewcvs.py/drm/drm/).

There's an online documentation (http://www.tu-darmstadt.de/fb/et/uet/fguet/mitarbeiter/vf/DRM/documentation.html) available but it's a bit outdated.
If you want to know more about the functions and displays of the "Evaluation Dialog" compile the latest version and use the help button (?).

Nevertheless I'm going to take a few screenshots and publish them to the web...

Regards - DigiBC


PS:
I'd rather prefer an USB version of the WR-G303, because the new WR-G313 USB will be based on the WR-G313i (PCI card) which is mainly DSP based so that there's no 12 kHz IF output for other decoder software like the DRM Software Radio and DReaM. :(


Could the update include stereo decoding ?

carknue
24-07-2004, 15:41
Originally posted by DRM-Fan



Could the update include stereo decoding ?

No.

DigiBC
24-07-2004, 19:24
As Carsten said, Stereo decoding is still not possible (but maybe later this year...).

@Paul:
I've just published a few screenshots of the different plots with descriptions taken from Dream here (http://www.digibc.mynetcologne.de/drm/dreamedp.htm).

Regards - DigiBC

tacitus-ms
24-07-2004, 22:54
Today I compiled the newest dream from the cvs and I detected a new button I had never seen before. But it seems to have no effect. What does it do? See screenshot.

The new improved transmitter function and the audio spectrum analyser are very nice features, thanks a lot to all who were involved :-).

best regards
tacitus-ms

carknue
24-07-2004, 23:15
Originally posted by tacitus-ms
I detected a new button I had never seen before. But it seems to have no effect. What does it do? See screenshot.



They only effect that I discovered is, that it uses a lot more CPU power when you enable it. It should be a bandpass, but I also don't see a real effect.

DigiBC
24-07-2004, 23:55
So far I haven't realized any improvement in reception too.
Besides the effect that DReaM seems to need double CPU power, I've only noticed a slight difference in the "Shifted PSD" plot: If the "BP" filter is activated, the estimated power spectrum density gets a cleaner shape.

Regards - DigiBC

ka2hzo
25-07-2004, 15:23
Hi Folks,

I would like to run some tests with heavy qrm above and below with the passband filter active to see how well it works.

I think a sharp mechanical filter rather than a software dsp filter would work much better.
Also maybe instead of using a bandpass filter.
2 or 3 DSP adjustable notch (band stop) filters could be added.

If I could notch out AM carriers on 9805 and 9795 kHz. I think I could then decode sackville just fine.

Thanks.

cesco
26-07-2004, 03:22
the difference i note is:

first: picture of drm signal with analog signal just below, filter off:

cesco
26-07-2004, 03:27
second: same signal, filter on.

the difference is 8db snr here.

what i am not happy with is the cpu load the filter causes,
and sometimes the synchronization seems to have trouble with the filter switched on.


but:
if you do not have a drm converter, but use an unmodified radio, and are always very low with the IF, you will love it !

G8JQW
27-07-2004, 14:57
Hi

I may have missed something but I don’t see how having a notch or bandpass filter improves DRM reception. :confused:

Removing an interfering AM signal might make a difference for agc but the DRM OFDM carriers on the same frequency as an AM carrier interferer can’t be decoded and filtering it out makes no difference, and as already been stated a software filter requires substantial cpu processing.

73, Roger

dk8cb
27-07-2004, 15:34
Originally posted by G8JQW
I may have missed something but I don’t see how having a notch or bandpass filter improves DRM reception.

Removing an interfering AM signal might make a difference for agc but the DRM OFDM carriers on the same frequency as an AM carrier interferer can’t be decoded and filtering it out makes no difference ...


Hi Roger,

I totally agree. I think a lot of people are mislead because they get better results with IF notch filters that have no other effect than to prevent the AGC from turning gain down.

But still, one question remains: Not being able to decode certain carriers because of interference or filtering them out and not decoding them makes no difference, but could it perhaps make a difference in channel estimation?

dk8cb

ka2hzo
27-07-2004, 16:00
Well something is going on with notch filters that makes the DRM reception better
It may not make sense on paper. But if I am only receiving a DRM signal on 6140 with QRM n 6145 at a SNR at 13 DB and then I add a notch 5 Hz notch filter at 6145 and the signal jumps to 18 db and starts to decode. This filter is doing something.
It may have to do with the AGC. But it works.
So why not use it? Unless something can be done to make the agc work better this is one method to improve reception.

dk8cb
27-07-2004, 16:11
So why not use it? Unless something can be done to make the agc work better this is one method to improve reception.

It is not a question of using it or not.
Of course one should use it, if it improves reception.

But the question is: Could the same result be achieved by a notch filter in software?
If better reception with the notch filter is only a result of the AGC not turning gain down, then using a software notch filter behind the IF chain (or more correctly: at the last stage of the IF chain) makes no sense as the AGC has then turned down the IF gain anyway. In such a case, a software notch in the DRM decoding software makes no sense and is not worth the effort.

dk8cb

dk8cb
27-07-2004, 16:40
Hi,

another thought:

Could reception with the notch filter be so much better, because some IF chains (including soundcards) are not very linear and thus produce intermodulation products in the presence of interfering carriers?

However, if the soundcard input circuit is responsible, turning sensitivity down at the operating system's audio input mixer should help.

dk8cb

carknue
27-07-2004, 18:29
So this bandpass filter is only usefull with unmodified reveivers ?!?

corrados
28-07-2004, 07:50
Hi all,

let me try to explain the benefit of the additional bandpass filter. In the previous versions of Dream, the unfiltered signal of 20 kHz bandwidth was fed to the OFDM demodulator (which is basically a FFT operation). If only a DRM signal of 10 kHz is present in that bandwidth, the filter cannot improve anything in this case. But if, e.g., a strong signal is close to the border of the actual DRM signal, under some conditions this signal will produce interference in the useful bandwidth of the DRM signal although it not at the same frequency as the DRM signal at all. The reason for that strange behaviour lies in the way the OFDM demodulation is done. Since OFDM demodulation is a block-wise operation, a windowing has to be applied (which is rectangular in case of OFDM). As a result, the spectrum of a signal is convoluted with a sinc function in the frequency domain. Consider now a sinusoidal signal close to the border of the DRM signal, its spectrum will not be a distinct peak but a shifted sinc function -> spectrum is broadened caused by the windowing. Thus, it will reach in the DRM spectrum and acts as an in-band interferer.

There is a special case if the sinusoidal signal is in a distance of a multiple of the carrier spacing of the DRM signal. Since the sinc-function has zeros at certain positions it happens, that in this case the zeros are exactly at the sub-carrier frequencies of the DRM signal. In this case, no interference happens. But this is a special case. If the sinusoidal signal is in a distance of a multiple of the carrier spacing plus half of the carrier spacing away from the DRM signal, the interference reaches its maximum.


Conclusions:

- If only one DRM signal is present in the 20 kHz bandwidth, filtering has no effect at all

- If the neighbor channel signal is far away from the DRM signal, filtering will not give much improvement since the squared magnitude of the spectrum of the sinc-function is approx -15 dB down at 1 1/2 carrier spacing (approx 70 Hz with DRM mode B) and goes down to approx -30 dB at 10 times the carrier spacing plus 1 / 2 of the carrier spacing (approx 525 Hz with DRM mode B).
-> the improvement of using the filter will be quite small

- special case: a carrier of an in-band AM station (no modulation considered now) lies exactly at the DC frequency of the DRM signal (which is usually the case since the oscillators at regular transmitters are usually very good), no interference to the DRM signal takes place! Only the modulation signal causes the interference -> notch filter might help

- the bandpass filter must have very sharp edges otherwise it is useless -> high CPU power (BTW: the current filter used in the CVS version of Dream is far away from beeing optimized in any way, it is still a test-stadium)



Best Regards,
Volker

dk8cb
28-07-2004, 09:25
Originally posted by corrados
special case: a carrier of an in-band AM station (no modulation considered now) lies exactly at the DC frequency of the DRM signal (which is usually the case since the oscillators at regular transmitters are usually very good), no interference to the DRM signal takes place! Only the modulation signal causes the interference -> notch filter might help

Hi Volker,

how can a notch filter help with the wideband modulation sidebands, when it is only on a single frequency?

DF9RB just wrote in a PM (in german) that he usually gets improved DRM demodulation when the interfering carrier is notched out on 1296 kHz.
Why? AGC effects? Intermodulation in IF stage?

Shouldn't an experiment be carried out with a notch filter that is built into Dream? This would answer a lot of questions.

Roland, dk8cb

cesco
28-07-2004, 13:54
> how can a notch filter help with the wideband modulation
> sidebands, when it is only on a single frequency?

just an idea:

if the disturbing carrier is not orthogonal to the drm signal it does affect the surrounding drm-carriers in the way corrados describes.
this means that a bunch of maybe 20 carriers will be corrupted.

with a sharp notch filter the number of corrupted carriers is reduced to the notch filter width.

df9rb
28-07-2004, 19:09
I analyzed the DRM signal of BBC on 1296 with speclab (see picture). The lower part shows the waterfall diagramm with notch OFF, in the upper part notch of the receiver is ON. The red line is the strong interfering carrierer. I think it is interesting that it is shown in the lower part that the DRM signal is getting weaker at the right and left side of the DRM signal, with the notch ON the DRM signal has a quite uniform strength up and down 4.5 kHz from the center.
I interprete this as a dynamic problem of the sound card (at least the sound card I use) because reducing the input signal does not
improve anything with notch OFF.
With notch ON reception of BBC is ok, with notch OFF no decoding!
If it is a dynamic problem of the sound card a software notch will not help I presume.

Bernd, DF9RB

dk8cb
28-07-2004, 19:16
Hi,

let me suggest an experiment using a notch filter.

1. Record an off the air sample of a DRM signal with an interfering centre carrier at 48 kHz samplerate as a wav-file.
In Europe, a BBC WS transmission on 1296 kHz would be a good candidate.

2. Transfer the file to another PC and play it there. Feed the output into your PC with the DRM decoder and log SNR and dropouts.

3. Use a wave-editing software that has got a built-in notch filter to notch out the carrier on the PC where the file is played and either save the new file or play it directly after filtering (depends on the capabilities of the software).

4. Play the modified file or the direct output and feed it into your PC with the DRM decoder and log SNR and dropouts.

Any differences?

Is anyone around who has got all the necessary tools available?

dk8cb

dk8cb
28-07-2004, 19:31
Originally posted by df9rb
I think it is interesting that it is shown in the lower part that the DRM signal is getting weaker at the right and left side of the DRM signal, with the notch ON the DRM signal has a quite uniform strength up and down 4.5 kHz from the center.
I interprete this as a dynamic problem of the sound card (at least the sound card I use) because reducing the input signal does not
improve anything with notch OFF.

I think the more constant shape (i.e. flat top) of the DRM signal with the Notch on is just a result of the filter's gain characteristics, with the gain increasing still a little towards the edges of the DRM signal.

But it is also clearly visible, when looking at frequencies far off the DRM signal, that overall gain is much higher with the Notch filter on.
This is exactly, what I always suspected: The carrier forces the AGC to turn down overall gain!

BTW: If it were a problem of the insufficient dynamic range of your soundcard, reducing the input level should improve reception.

I think, with the carrier not filtered out, the DRM to noise ratio is already too low at the receiver's first or second IF.

dk8cb

simone
28-07-2004, 20:25
Originally posted by dk8cb



This is exactly, what I always suspected: The carrier forces the AGC to turn down overall gain!


Hi Roland,
thatīs the problem with my configuration too, I mentioned that a long time ago.

btw, interesting experiment that you suggested! but I donīt have the chance to do it the next days.

73, Simone

ka2hzo
29-07-2004, 01:14
Originally posted by simone


Hi Roland,
thatīs the problem with my configuration too, I mentioned that a long time ago.

btw, interesting experiment that you suggested! but I donīt have the chance to do it the next days.

73, Simone


Yes I agee.

This I have posted many many times in the past.
If you go back and look at some of my many Sackville results you can see. I have great copy as long as there are no AM carrier's above and below 9800 khz ie. 9795 and 9805 kHz.

How can we fix this problem without using a notch filter?

dk8cb
29-07-2004, 07:23
Originally posted by ka2hzo
How can we fix this problem without using a notch filter?

By using a receiver that satisfies the following two conditions:

(1) It has a large dynamic range (a lot of headroom) in the IF chain, i.e. it is not easily overdriven by a carrier inside or next to the bandwidth of the DRM signal
(2) It uses an AGC, that derives its control voltage from a part of the spectrum that is not affected by the carrier.

Condition (2) requires, that the AGC voltage is either derived by the demodulating software itself (intelligent AGC) or by an envelope detector and by filtering the IF signal ahead of this detector, such that it is not affected by a carrier.
This could be accomplished by using an already existing built-in narrow filter to derive the AGC envelope and by adjusting the receiver in such a way, that an interfering carrier does not fall into the bandwidth of this narrow filter.
The DRM signal itself would have to be run through a separate IF chain, but this is already often the case, when a receiver is modified by tapping the IF signal ahead of the too narrow second IF filter and feeding it to an external mixer circuit such as an SE612 or NE612 mixer.

Of course, you could as well just use manual gain control. ;-)

dk8cb

G8JQW
29-07-2004, 07:47
Hi All

A DRM signal is just wideband noise to the receiver. It is the amplitude of the AM interferer that will influence the agc more than the DRM signal and this can have a detrimental effect on DRM reception.


73s, Roger

carknue
29-07-2004, 22:07
That's why I use the 8 khz Filter of the AOR7030 when there are strong AM signals +/5 khz. It helps a lot, but if these AM signal have a strong modulation as well, you have no chance

PaulButler
29-07-2004, 23:41
Here's my two-penn'orth on the filter discussion.

Those getting a strong DRM signal probably need no filtering, as the DRM component is strong enough to win through.

Those getting a weaker signal, however, are prone to losing the lot because of both in-channel interference (another carrier, usually AM, within the DRM signal) and co-channel interference (another carrier at one or both edges of the DRM signal).

I often see a good DRM signal with a whopping great carrier soomewhere within it. The rogue carrier prevents some of the DRM carriers from being resolved and also, I suggest, causes the AGC to turn down the gain. Result - no DRM audio.

Solution - a sliding notch filter which can be placed over the rogue carrier, with variable width so it can be tweaked to kill it without also killing too many DRM carriers.

Conversely, I often see one or two carriers at the edges, 5kHz up or 5 kHz down from the centre frequency of the DRM signal. This is where the bandpass filter in DREAM may help - my initial tests suggest that it does in some cases.

But given the most common co-channel interferer is 5 kHZ away, reducing the bandwidth to 8 kHz would help enormously (except for strong interferers which intrude further into the DRM signal). Someone above has mentioned that using the receiver's 8kHz filer helps in this situation.

Here's another thought - why not reduce the transmitted DRM signal to 8 kHz? This would mean fewer carriers and therefore lower bit-rate or reduced resilience (fewer carriers means you can afford to lose less before decoding is unavailable). But it would enable us to use an 8kHz window at the receiver and get rid of a lot of the energy from the carriers 5 kHz above and below.

Another way to approach it is to leave the transmitted DRM as it stands but establish a DRM DX decoding specification which will allow decoding to take place on fewer carriers? The transmtter could send the full-specification DRM signal but we could adjust the decoding to get a reduced quality signal if interference prevents full decoding, by reducing the bandwidth to 8kHZ, or accepting fewer carriers, or both of these.

For those of us for whom DRM is DX, a DX DRM decoding algorithm would work wonders. I would rather receive slightly reduced quality audio (but still significantly better than analogue AM or SSB) than no audio at all, which is what we get for a lot of the time here. And after all, aren't we talking about long-haul options for shortwave broadcasters?

OK, everyone, what do you think?

Paul VK3DBP Melbourne

DigiBC
01-08-2004, 07:48
Sorry to interrupt your filter discussion, but there are some new features added to the CVS version of Dream I'd like to post here:

Now Dream writes an INI file and saves configuration and window placement data.
If you open the Dream.ini in an editor you can add your coordinates (in degrees and minutes). Then Dream will insert these coordinates into your logs. Now the resulting DreamLog.txt file is compatible with the log file created by the DRM Software Radio (though the CRC entry is still missing) and it works with Carsten's reception analyser tool "DRMcalc" perfectly.

That's how the Dream.ini looks like:
[Logfile]
frequency=9800
latitude=51°00'N
longitude=6°49'E
startlog=0

[Receiver]
filter=0
flipspectrum=0
mlciter=2
muteaudio=0
snddevin=-1
snddevout=-1

[Window geometry]
analdemhsize=419
analdemvis=0
analdemwsize=704
analdemxpos=316
analdemypos=316
mainhsize=490
...
BTW: Yesterday new FAAD libraries have been released so I hope we can expect Dream to decode parametric stereo soon... :)

Regards - DigiBC

Garf
01-08-2004, 15:19
I can confirm that the FAAD2 update included complete parametric stereo capabilty, as well as improved handling of signals with bit errors.

Overall DRM performance should be much improved now.

dk8cb
01-08-2004, 23:21
Hi,

also, if one defines USE_SSE, decoder.c uses the undeclared functions "apply_scalefactors" and "apply_scalefactors_sse" which used to be defined in specrec.c but now aren't defined anymore.

volker.dsp is also not found.

dk8cb

Garf
02-08-2004, 01:44
I never tried the CVS version.

Some minor edits will be needed because the API of FAAD2 changed, but they are pretty simple.

'DRMCH_SBR_LC_STEREO' -> DRMCH_SBR_PS_STEREO

faacDecInitDRM( -> faacDecInitDRM(&

You can do without USE_SEE and volker.dsp...

G8JQW
02-08-2004, 12:51
@ tactis-ms

I’m also getting the same first block of errors as you. I guess that the “update faad2 include filename and function” errors was caused by you copying both faad.h and neaacdec.h from the include directory, only neaacdec.h is required as there is already a faad.h in the drm/libs.

73s, Roger

Garf
02-08-2004, 15:37
There are some bugs remaining that may cause faad2 to crash with bad reception. They'll be fixed very soon.

DigiBC
02-08-2004, 16:49
First many thanks to Garf and the rest of the Nero team! :) :) :)

I haven't compiled the new FAAD2 code yet, but Volker (corrados) has just released modified versions of AudioSourceDecoder.cpp and AudioSourceDecoder.h (which won't work with the old FAAD library now!).
For more information visit the following thread of the Dream forum at SourceForge.net: http://sourceforge.net/forum/forum.php?thread_id=1120221&forum_id=242204

@ tacitus-ms
The first block of compiler warnings is resulting from the Settings.cpp which was added 5 day ago. According to Volker they are normal but not displayed usually...

Regards - DigiBC

tacitus-ms
03-08-2004, 22:43
Originally posted by Garf
There are some bugs remaining that may cause faad2 to crash with bad reception. They'll be fixed very soon.

Here is another bug, obviously caused by the new stereo feature, perhaps this description may help someone to analyse it. Therefore I posted this bug already on the forum of sourceforge.net

I am using the last version of Dream including the last faad2, which is able to decode p-stereo. (downloaded from the cvs of sourceforge.net on 03.08.04 about 12:00 ) (libfaad was compiled in debug mode).
Listening to DW world from Sines (on 5980 kHz, about 21:30 GMT) today I realized that three times the right audio channel fell silent. DW did not use stereo but 17,46 kbit/s AAC with SBR in mono. The S/N was very good (about 23 dB). Every time the right audio channel had fallen silent the audio signal of the right channel did not return until I tuned to another station (RTL 5990 kHz) or I restarted the software. After tuning to the other channel the signal returned and I could tune back to DW world. But a few minutes later the same happened again.

DigiBC
04-08-2004, 06:11
Maybe this bug is solved now.

There's a new version of hcr.c available!
Download from CVS: http://cvs.sourceforge.net/viewcvs.py/*checkout*/faac/faad2/libfaad/hcr.c

Regards - DigiBC

DF1PAW
04-08-2004, 06:33
Do I need to compile Debug code? Or does the release code work now?

Do you know when (if ever) SSE support will be re-enabled?


Regards,
Andreas Weller

Garf
04-08-2004, 11:14
Release mode will work.

There's still a small bug that one channel may disappear with mono transmissions. I'm gathering a few more testcases to be sure the fixes work.

My first worry now is making sure everything works well, and improving performance with bad receptions even further. After that I may have a look at SSE support but it is certainly not a priority right now.

PY2PLL
22-08-2004, 00:20
Hi ...

Yesterday I place a 10KHz FIR filter between my product detector and sound card. My PC is an 800MHz one so I can't use built in software BPF.

Hard to say if any improvment. The filter is running on a DSP56002EVM (Motorola), 48KHz sampling, etc etc ...

OK, the spectrum is much clear now ... but most of the problems still receiver's AGC trigger. Next step: I'll derive the AGC control voltage from this filter output (or use one channel as 10KHz BW filter and the other one as 4.5KHz BW AGC sampler.

Another thing I want to do: add 3 fixed notches, may be 20Hz wide each at F0-5KHz, F0 and F0+5KHz.

Does anybody know how to do it on such platform? I'm nil on DSPs and programming and untill now I can't belive that I make this 10KHz BW filter work :o)

dk8cb
22-08-2004, 14:58
Hi,

you can do an "off-the-air" experiment to test the effectiveness of such a filter combination.

1. Record a 12 kHz IF signal with interference as a wav-file with 48 kHz sampling rate.

2. Run this wav-file through DL4YHF's Spectrum Lab program (freeware) and apply the filter function that you want to test. Let it write the output to a new file. Spectrum Lab may be found here
http://homepages.compuserve.de/WoBuescher/DL4YHF/spectra1.html

3. Run Dream using the commandline parameter -f <filename> once for the original file and once for the new file and compare results.

I have done so using the latest Dream CVS version and a notch filter on the centre frequency, but it did not improve decoding. The result may however depend on the kind of interference encountered. (It did improve reception with the last version of Dream, but not with the current one, which has a better channel estimation.)

On a sufficiently fast system, it might even be possible to do this all in real time by cascading both Spectrum Lab and Dream by means of a program named 'Virtual Audio Cable' which can be found at
http://www.ntonyx.com/vac.htm but so far, I have not tested this.

Edit: I am still searching for a freeware program that allows to cascade audio applications like 'Virtual Audio Cable' does, but I haven't found one yet. If anybody knows of one then please tell me.

73, Roland, dk8cb

dk8cb
22-08-2004, 15:33
Hi,

one of the purposes of the AGC is to prevent distortion in the IF amplifier by decreasing IF levels in the amplifier to a safe value.
If you have a strong interfering carrier that triggers the AGC to turn down gain then distortion in the IF amplifier is prevented. If however, the AGC voltage is derived in such a way that the carrier will not turn down gain, distortion may happen and the quality of the DRM signal will suffer.

Thus it is of prime importance to have an IF amplifier that exhibits enough headroom (> 30 dB) when using this kind of AGC approach.
Also, if done properly, the AGC voltage derived from the DRM signal should not be derived from the average but rather from the peak level of the signal.

dk8cb

PY2PLL
22-08-2004, 15:46
Hi Roland et al.

> 2. Run this wav-file through DL4YHF's Spectrum Lab programm ...

It's a good idea. I'm already assembling another setup:

Since my filter is an external unit, I want to loopback Dream (audio muted) in TX module => RX module trhu this filter and measure:

1)S/N with / without filter. OK, probabily lots of dBs S/N

2) Mix at the filter input a 12KHz center freq spectrum, tuning my HF receiver to any crowded SW-AM band sort of have 3 stations 5KHz appart.

So this will reproduce a DRM signal co-chanelized with an AM transmition and another two on the 10KHz BW edges Then I'll test the notches, etc

3) Using the same config, I'll change to MW-AM band and place 2 stations 10KHz appart (here ITU reg 2) at the 10KHz edges. Test the notches etc ...

On this way, the SW signals will be fading in and out but the DRM will be stable in amplitude. This can reproduce the behaviour of a modified receiver where AGC os driven by the DRM signal only (and amplifiers have room enough to handle all this signals).

Yesterday I took a snapshot of DW signal on 3995 and another from CBC on 11955 I guess.

May be I got why Dream doesn't lock on 3995 but it does on 11955, where the CBC signal was S0 (zero) and DW was S9+20: looking at the signals with Spectran, with resolution enough to "see" the OFMD carriers (and the missing one at the center) I could observe that CBC was much more consistent and DW have a vy fast selective fading, seems multipath with several signal arrival time on a "rate" that keeps the software crazy.

The only way to make it lock on DW was choose Time Interpolation = linear and Time sync tracking = First Peak.

But anyway, no audio at all.

I'm trying to modify the external DSP filter code to have left channel as DRM 10KHz bandpass + notches and the right channel a 2KHz wide filter, at 9.5KHz. This energy will be then rectified and used to control receiver AGC.

dk8cb
22-08-2004, 16:54
> I could observe that CBC was much more consistent and DW have a vy fast selective fading, seems multipath with several signal arrival time on a "rate" that keeps the software crazy.

Have you inspected the estimated impulse response? It should give an indication on the number of paths. Is the guard interval violated?

Interesting to read that DW's signal is so strong in Brazil, I still think they are using an antenna with a mostly vertical radiation angle in order to be able to serve Europe well. But still, quite a considerable amount of power seems to be radiated at such a low angle that it can reach you.

Perhaps time constants for the channel estimation are set a bit too high so that the estimation cannot track the real channel fast enough. I wonder if there is a way to adapt the various time constants of the channel estimation to the kind of channel encountered or to provide a few sets of constants for special types of channels.

dk8cb

PY2PLL
22-08-2004, 18:51
Hi ...

>Have you inspected the estimated impulse response?

nop ... I'll do it tonight ...

I'm setting up another DSP card to run Chirp (from G3PLX). There's a chirp sounder in Svalbard and may be the path trhu here can be considered almost the same to DW.

I'll left it running on 3992KHz, measuring the propagation delay from Europe to PY2LAND. There's a spectrogram too, which shows me the main chirp signal and , if any, the delayed signals (even can show RTW one, delayed by 138ms).

BTW, Peter (G3PLX => PSK31) probabily will implement a DRM decoder on such DSP cards.

I use an helix vertical antenna (40m of wire) with some buried radials in a lake margin. With this setup was easy to listen to DW on 3995 (when in AM some weeks ago) or Sondergrese 3320 (S.Africa).

DigiBC
31-08-2004, 20:24
A week ago the "Dream Team" has officially released Dream version 1.1.

Compared to previous CVS versions there are no major changes, but Hamlib is fully integrated now (e.g. a S-Meter was added to the "Stations Dialog"). So Dream is able to control a wide range of communication receivers (see: http://hamlib.sourceforge.net/support.html).

Unfortunately the new Dream version won't start anymore if there's no "libhamlib-1-2-2-2.dll" installed. That's a bit annoying if you want to use Dream simply as a DRM decoder.

Now Dream offers 3 color "themes" for the "Main Plot" display. They can be chosen by the following start parameters:
-y 0 Blue-White (default)
-y 1 Green-Black (looks familiar somehow...)
-y 2 Black-Grey

After first start the color setting is written to the "Dream.ini" file.

If you compile the latest CVS source you will already get version 1.1.1cvs.

Regards - DigiBC

dk8cb
31-08-2004, 23:57
Hi,

but it is very easy to inhibit the hamlib functionality if you don't need it. Just edit \common\GlobalDefinitions.h by removing the comment (//) in front of
# undef HAVE_LIBHAMLIB
and adding a comment (//) in front of
# define HAVE_RIG_PARSE_MODE 1
if you do not need the library because you don't have a suitable rig. I did so without any problems.

Of course, you won't need the libhamlib dll then.

Roland

DigiBC
01-09-2004, 17:34
Hi Roland,

you're right of course, but I'd prefer a universal and more elegant solution: The standard Dream version should work even without that DLL and simply disable all Hamlib features if the required DLL isn't found.

According to Volker (corrados) that's not a matter of Dream but of Hamlib because the DLL is demanded by the "libhamlib.lib". So maybe I should contact the Hamlib developers...

Regards - DigiBC

corrados
01-09-2004, 19:11
Hi,

what's the problem with having hamlib included? The only dll you really need is the main one which is not very big. If the default setting in Dream is used (which is "none"), hamlib is not used (not even initialized at all). Maybe sometime we get it managed that hamlib is compiled in a static library so no dll is needed at all. I guess this would be a resonable solution for you :-)

Best Regards,
Volker

GuidoS
15-09-2004, 09:02
1.11 supports P-Stereo now.

DRM-Fan
15-09-2004, 10:01
Originally posted by GuidoS
1.11 supports P-Stereo now.

It sure does! I find I'm getting a good 1 or 2 db more than using the DRM s/w radio also. Both can be run at the same time of course

midre
15-09-2004, 20:29
ups,

annother >>forbidden<< post got lost...........

Michael

VE3MEO
23-09-2004, 22:35
Attached is a screen shot showing an earlier version of 1.1.1cvs on the left and a current one on the right (numbered the same but different!). The one on the right shows the new group delay plot in the Transfer Function screen - it's the black line while the blue line is the amplitude response. Notably, this version reports the SNR to be about 0.6dB higher than the earlier one and it's my impression that it uses 5-10% lower average CPU on a 2 GHz. The SNR difference with a 1.0.8cvs is more variable, from 0.7 to 1.2 dB higher.

I'll post some more shots about the Group Delay plot and refer you to SourceForge forum (https://sourceforge.net/forum/forum.php?thread_id=1138694&forum_id=242204) for more review.

73, Tom

VE3MEO
24-09-2004, 00:53
Originally posted by VE3MEO
I'll post some more shots about the Group Delay plot and refer you to SourceForge forum (https://sourceforge.net/forum/forum.php?thread_id=1138694&forum_id=242204) for more review.


In the attached zip file are 4 screen shots of reception of CBC Sackville 9800 kHz:

9800GD-1.png - shallow fade around carrier 60 with corresponding bump in group delay.

9800GD-2.png - almost exactly the receiver response with no selective fading.

9800GD-4.png - severe selective fading, like a comb filter, showing corresponding spikes in group delay, sometimes erroneously negative, as Volker advised.

9800GD-5.png - rapid ripple on both amplitude and group delay.

73, Tom

VE3MEO
24-09-2004, 02:19
Originally posted by VE3MEO
SourceForge forum (https://sourceforge.net/forum/forum.php?thread_id=1138694&forum_id=242204) for more review.

Attached are plots from the latest DReaM 1.1.1cvs of the estimated transfer characteristics for amplitude and group delay versus carrier index for a loopback test from a DReaM transmitter to the DReaM receiver through my protoboard upconverter and 'dead-bug ugly' downconverter:

455GD-10kHz.png - 10kHz bandwidth DRM signal centred at 14550 Hz results in a centre of 455kHz with my converter; I captured the group delay plot at a moment when it was flat and average at -19ms. It is typically bouncing around between -12 and -24 ms with +/-1 pixel 'noise' - I don't know why nor what the meaning of negative delay is (relative to what?).

455GD-10kHz-2.png - 10kHz bandwidth DRM signal centred at 12000 Hz results in a centre of 457.45 kHz with my converter and seems to fit the filter better, yielding a little higher reported SNR. The little step in the group delay plot is the transient 'noise' in the display.

455GD-20kHz.png - 20kHz bandwidth DRM signal with DC frequency of 8000 Hz is actually centred at 13000 Hz and just fits within the sound card Nyquist limit of 24kHz, i.e., from 3kHz to 23kHz. At the output of the upconverter, the centre frequency is 456.45kHz, close to the filter's optimum (8500Hz is a 1/2 dB better in reported SNR). As the DRM signal is wider than the filter's 6dB bandwidth, the extreme carriers are severely attenuated. One would expect to see significant group delay distortion at these extremes - it is just evident with the coarse resolution of this scale near the carrier index of 10.

455GD-20kHz-2.png - the DC frequency was shifted down to 7000 Hz from 8000 Hz, thus shifting the spectrum to 2-22kHz and the upconverted centre frequency to 457.45 kHz. There is more severe attenuation of the low index carriers and the screenshot was grabbed when the time-varying group delay plot showed the spike near carrier 30. At other times the GD plot was less severely distorted. Note also the difference in average GD between these two shots, -10 ms for this one vs -24 ms for the previous - both jumping around over time; this is unexpected and unexplained behaviour - they should be static and some carrier should be at reference 0 ms.

73, Tom

VE3MEO
25-09-2004, 21:36
The latest 1.1.1cvs now has a command line parameter with which you can select the input channel to be decoded:
-c <n>, where <n> = 0, left channel
1, right channel
2, mix of both channels (the default).

You can run two instances of DReaM, one on the left channel, the other on the right channel and feed each input with a different DRM stream or the same stream from two different receivers. With just a two-channel sound card, it is now possible to:

- listen to one program while logging another
- record two different programs simultaneously (the WAV outputs are direct from the streams, not via the sound card, and are kept separate)
- compare the performance of two different receivers with the same DRM signal (take advantage of DRMCalc's compare feature)

With Windows, I installed the application software in one folder and created two sub-folders: \left and \right. I then created 3 shortcuts to the application:

1. Normal shortcut with the "Start in" parameter set to the same folder as the application.

2. A shortcut for left channel decoding:
Target = "C:\Program Files\DReaM\DReaM1.1.1dual\Dream.exe" -c 0
Start in = "C:\Program Files\DReaM\DReaM1.1.1dual\left"

3. A shortcut for right channel decoding:
Target = "C:\Program Files\DReaM\DReaM1.1.1dual\Dream.exe" -c 1
Start in = "C:\Program Files\DReaM\DReaM1.1.1dual\right"

The "Start in" parameter sets where the ini, schedule, log and wav files are written. With a unique "Start in" folder for each, you can run two instances of DReaM completely independently. Unfortunately, the audio output from each is fed to both output channels so you cannot use cocktail party effect to discriminate between their respective programs. It would be nice to have control over output routing, too.

73, Tom

VE3MEO
25-09-2004, 22:18
Originally posted by VE3MEO
The latest 1.1.1cvs now has a command line parameter with which you can select the input channel to be decoded:
-c <n>, where <n> = 0, left channel
1, right channel
2, mix of both channels (the default).



Should read:
-c (n), where (n) = 0, left channel
1, right channel
2, mix of both channels (the default).

In the prev post, the n was enclosed in greater than/less than symbols that were interpreted as html tags and undisplayed.

Tom

dk8cb
25-09-2004, 22:33
Originally posted by VE3MEO
Unfortunately, the audio output from each is fed to both output channels so you cannot use cocktail party effect to discriminate between their respective programs. It would be nice to have control over output routing, too.

Hi Tom,

this could easily be done, but how about stereo transmissions?


Roland

VE3MEO
26-09-2004, 03:26
Originally posted by dk8cb


Hi Tom,

this could easily be done, but how about stereo transmissions?


Roland

Hi Roland,

The ideal output routing solution would allow the following:

Input Mode Output
dual mono equal left/right
dual stereo stereo left/right
single mono equal left/right
single mono same output chan as input (left-left, right-right)
single stereo stereo left/right
single stereo mono sum to same output chan as input

That would allow a stereo program to be monitored in stereo while another program is being logged and it would permit two stereo or mono programs to be monitored in mono with the spatial separation of the speakers to aid discrimination.

Another idea would be a diversity switch so that only one audio is output, whichever one is not muted due to MSC error, remaining on it until the combination requires a change. Thus with two receivers and antennas, one could achieve some overall improvement in the %audio decoded.

What do you think? Is any of this do-able?

73, Tom

dk8cb
26-09-2004, 15:16
Originally posted by VE3MEO
What do you think? Is any of this do-able?


Hi Tom,

it could certainly be done. It would require a few more command line switches and perhaps a new audio output class.
The only question is, whether someone who has got the time to do it will consider it worth doing.

Roland

df9rb
26-09-2004, 18:00
Moved to Receiver modification

dk8cb
27-09-2004, 20:17
Originally posted by VE3MEO
What do you think? Is any of this do-able?

I just found out that Volker has already done it. It's in the CVS.

As fast as lightning! :)

Roland

VE3MEO
28-09-2004, 03:14
Originally posted by dk8cb


I just found out that Volker has already done it. It's in the CVS.

As fast as lightning! :)

Roland

You're kidding! I have got to get Visual C++ 6 and get into this compiling and customising. But there's so much to learn - to start I have yet to figure out what to look for in CVS!

Tom

dk8cb
28-09-2004, 08:24
Originally posted by VE3MEO
You're kidding! ... to start I have yet to figure out what to look for in CVS!
Hi Tom,

if you look at eg .../common/Data.cpp you will find:

-------------------
switch (eOutChanSel)
...
case CS_BOTH_BOTH:
/* left -> left, right -> right */
...
case CS_LEFT_LEFT:
/* left muted, right -> right */
...
case CS_RIGHT_RIGHT:
/* left muted, right -> right */
...
case CS_LEFT_MIX:
/* left -> mix, right muted */
...
case CS_RIGHT_MIX:
/* left muted, right -> mix */
-------------------

This is a little different from what you wanted, but it will do the same job, ie "/* left muted, right -> right */" would mean that the left channel from the demodulated audio signal is muted (no problem with mono signals) and that the right audio channel is sent out to the right output.

73, Roland

DigiBC
28-09-2004, 08:50
... and here are the appropriate command line arguments to start Dream with:-u 0 or --outchansel 0 L -> L, R -> R (default)
-u 1 or --outchansel 1 L -> L, R muted
-u 2 or --outchansel 2 L muted, R -> R
-u 3 or --outchansel 3 mix -> L, R muted
-u 4 or --outchansel 4 L muted, mix -> RRegards - DigiBC

VE3MEO
28-09-2004, 18:12
Originally posted by DigiBC
... and here are the appropriate command line arguments to start Dream with:
{snip}
Regards - DigiBC

You guys (Roland & DigiBC) are most helpful. It was only a few days ago that my helpful compiler included a help.bat file from which I learned that the list of command line prompts could be seen using a command line prompt, i.e., "dream.exe -h". Amazing! Why didn't I think of that?

73, Tom

VE3MEO
30-09-2004, 02:25
Thanks to my friendly compiler, I am now running the latest (well maybe 72 hours old) 1.1.1cvs with my two DX-394's and their down converters. One is tuned to CRI on CBC 6140 coming out the left speaker (is that appropriate?) and the other tuned to DW Wertachtal 3995, waiting for a blip of decoding to break through on the right speaker. A little earlier, they were both on 6140; the time delay echo between the two decoders is a little more tolerable when they come out of separate speakers than out of the same speakers. And a slight shift of the Volume balance control favours one or the other.

Volker, it works great!:p

Next, I need to get a second antenna working, oriented orthogonally to my G5RV so that a crude diversity receiving system could be tried.

Then it would be neat to come up with an audio process to pass only one channel when both are outputting audio and switch away from the muted one to the active one when only one is decoding. Could be done in hardware but it's probably a piece of cake in software.

A hurdle to overcome is the timing difference of the two decoders. The decoder delay seems to vary depending on when decoding begins. Perhaps it's related to where it starts in the MPEG frame or something to do with interleaving.

I am so impressed with how rapidly the DReaM developers adopt suggestions, especially mine!;) I think I have triggered 3 now - group delay plot, dual inputs to one sound card, selectable output routing from 1 sound card. And in the brief period I have been a user, there have been so many more improvements. Awesome.

73, Tom

GuidoS
30-09-2004, 13:51
[i]I am so impressed with how rapidly the DReaM developers adopt suggestions
73, Tom [/B]

Some months ago there was a discussion going on about the advantages of Dream compared to the FhG software. The conclusion was that you need both.

I am wondering if this is still the case ?

rad
25-10-2004, 11:42
I know what you mean, for features DREAM is better, but actually the FHG software is just nice and simple and has a better designed GUI. Dream requires too many windows. The green oscilloscope thing on the FHG software looks better too. Perhaps DREAM should become "skinnable".


The initial DREAM window is a waste of space. Who needs a whole window to tell you what station you are listening to. It could be much more compact.

dk8cb
25-10-2004, 13:37
Hi,

if you want a green spectrum scope on Dream, you can have it. There is already a start parameter for it. Just start "dream.exe -h" and you will find it.

However, I really prefer the blue spectrum plot.

Roland

cesco
25-10-2004, 14:27
I think its not aout blue or green in the spectrum scope.

Those unfiltered values in log sacale jump around a lot,
that is the problem.

I think a linear scale, filtered display looks much better
and makes it easy to identify the freq pilots.

with "filter" i mean to display the sum of the last 5
measurements, and, a linear display may need a sort
of AGC.

cesco
25-10-2004, 14:30
here is an example of linear filtered drm spectrum:

http://www.qslnet.de/member/hb9tlk/windrm/windrm.gif

you see the freq pilots, even the boosted scattered pilots
at the edges.

VE3MEO
25-10-2004, 14:42
Originally posted by GuidoS


Some months ago there was a discussion going on about the advantages of Dream compared to the FhG software. The conclusion was that you need both.

I am wondering if this is still the case ?

I have used only DReaM and have succeeded in setting set up so I can do the compiling of the lastest versions (no mean feat and not for the average computer user).

Others have both and provide comparative reports of logs taken from both DReaM and DRMSWR decoding the same input stream. Since DReaM 1.1 came out and until chemclouds (Carl) recently posted some opposite experience, it seemed that DReaM had a slight advantage in reported SNR (not so important) and in % success in audio decoding (the key measure). Provided that the arithmetic used is identical, then it suggested that DReaM was the superior decoder. However, Carl's recent posts indicate the opposite and he has gone so far as to abandon DReaM.

Whether there is something inconsistent in his or other people's setups that biases the comparison one way or the other is undetermined. I wondered if DReaM is the more susceptible to computer overload when both are running - it could be suffering interrupts and loss of frames that would affect success rate and possibly SNR on a marginal computer.

I like the analytical feature set of DReaM - the estimated channel impulse response is very instructive and helpful in selecting the best antenna for a station. The transfer response has been very useful in optimally tuning the receiver and seeing the effects of filter selection. And the new selectable input and output modes are very useful for comparisons of receivers, antennas, downconverters, filters, etc.

I have had no signal sources to compare the non-audio features of the two softwares.

At this stage, I have no compelling motivation to invest over $100CDN in DRMSWR - if I were to spend that on receiving equipment or software, I can think of many other things that would take precedence and have greater benefit, even for DRM.

73, Tom

VE3MEO
25-10-2004, 14:51
Originally posted by cesco
http://www.qslnet.de/member/hb9tlk/windrm/windrm.gif


Gives an Errooor! message when I click on the link from the Forum message. Copy the URL and paste it into your browser - works.

dk8cb
25-10-2004, 16:25
Originally posted by cesco
Those unfiltered values in log sacale jump around a lot,
that is the problem.

I think a linear scale, filtered display looks much better
and makes it easy to identify the freq pilots.

I do agree, that the filtered spectrum may look better, but nevertheless it doesn't provide as much information as one that is updated more often.

Take the currrent problems on 1296 kHz as an example:
With the current spectrum plot, I can see that sometimes there is a problem with the complete DRM spectrum disappearing for fractions of a second. I would not get this information from a spectrum that is averaged over a longer period of time.
With a very slowly changing spectrum, tuning of my medium wave loop antenna would also be more difficult. Also, the effects of propagation induced rapid fading would be less visible.

In my opinion, the fact that I would be able to see the pilots a little better, does not outweigh the disadvantages of an averaged spectrum plot.
Besides, it does not help in any way, if I can see the frequency pilots.
It may be different, if one experiments a lot with different pilots and self defined new DRM-standards as you seem to be doing as far as I can tell from your postings on the sourceforge forum, but it doesn't hold any useful information for the normal listener.

Roland

dk8cb
25-10-2004, 16:31
Originally posted by VE3MEO
Copy the URL and paste it into your browser - works.

No, that doesn't work either. (Why should it, it is still the same link)

Roland

cesco
25-10-2004, 17:01
Lets try it this way...

VE3MEO
25-10-2004, 17:47
Originally posted by dk8cb


No, that doesn't work either. (Why should it, it is still the same link)

Roland

It did and does for me. I can't tell you why or why it did not for you. And CESCO's new link works fine, too, but the original still does not. Inspection of the HTML source reveals no difference between the way the URL was expressed originally and the URL you get by copying and pasting or using the new link. Perhaps the problem may have something to do with the Forum server software not issuing the correct Mime Type on a GIF file type.

73, Tom

simone
25-10-2004, 18:00
Hi,
no problem with the links, either the old or the new one, using Opera.
73, Simone

dk8cb
25-10-2004, 18:34
Hi Simone,

I'm also using Opera, it didn't work for me. The server always switched to http://www.qslnet.de/system/bilder/error.gif

Edit: it worked after I switched Opera to identify itself as Mozilla 5.0.
So it seems to be a server problem.


Roland

df9rb
25-10-2004, 19:28
Hello,

I just compiled Dream, version 1.1.3cvs. A lot of new buttons are
available in evaluation dialog and the display is much faster.
I just try to understand the additional informations given now

Bernd, DF9RB

VE3MEO
25-10-2004, 19:48
Originally posted by df9rb
I just compiled Dream, version 1.1.3cvs.

Bernd, how do you know when there is an update worth compiling?

Thanks for the post - my CPU is busily working on the new build.

73, Tom

dk8cb
25-10-2004, 21:26
... how do you know when there is an update worth compiling?

I hope, Bernd will not mind me answering this...

If you use WinCVS, once you have learned how to do it, it is very easy.
Just let it get the updated files and, in case there is something new available, start the compiler.
It's only a matter of a few minutes, then you have the new version.

Running WinCVS daily is a process that only takes a few seconds and after doing so, you will know, if some files have been changed, because they are highlighted in different colors, depending on your own changes being merged into the respective file or not.
If you are interested in knowing what has been changed in one of these files, you may either use the built-in functions or use the http-CVS-Server that is accessible via Dream's sourceforge page to show the changes with respect to the last version of this file.

There is one problem, however: WinCVS is not easy to understand and it's nothing for the faint-hearted. It takes some time to get accustomed to it. Besides, its documentation is much outdated and not very clear.

But even after using WinCVS for a while, I always find new features in it.

Roland

DRM-Fan
25-10-2004, 22:37
I have downloaded WINCVS. How do you do it then ?!

df9rb
26-10-2004, 15:24
Hi,

I do daily how Roland described. Checking e-mail and checkout
cvs is daily procedure.....
Roland how do you get the actual changes on sourceforge net?
I only can find changes on this page which are several months old....

vy 73 de Bernd, DF9RB

dk8cb
26-10-2004, 15:52
Originally posted by df9rb
Roland how do you get the actual changes on sourceforge net?

Just click CVS from the Dream forum page on Sourceforge, then click on 'Browse CVS', then on 'drm'. If you click on Age, the file list will be sorted such that the latest files are on top of the list. You can then browse through the various folders of the project.
Click on a file which you are interested in, then click on 'Diff to previous ...', it will then display the lines that underwent changes since the previous version.
I do not download from there, I use WinCVS to download.

The sourceforge CVS page is a quick and easy means to see what has been changed, however one has to browse through all the directories of a project to find changed files. So I usually use WinCVS to checkout to know what was changed and I then browse to the respective file.
WinCVS itself also includes this 'Diff' function, but it requires a few more clicks plus keyboard interaction to do it. ;-)

Roland

VE3MEO
26-10-2004, 18:13
Originally posted by dk8cb

The sourceforge CVS page is a quick and easy means to see what has been changed, however one has to browse through all the directories of a project to find changed files. So I usually use WinCVS to checkout to know what was changed and I then browse to the respective file.

Roland

That's what I mean - there's no automatic rollup of most recent changes for the whole project by which you can readily see if they are of significance.

I use Tortoise CVS - purportedly easier to use than WinCVS but I have not tried the latter. Once installed and with the project imported, updating the files is as easy as right-clicking on the root folder and selecting CVS Update. Of course, there may be complications and you have to rebuild with Visual C++ 6.0.

My current complication is that the system environment variable for the QT directory has disappeared and autoexec.bat (win98) is automatically erased every time I boot. Sounds like a virus!

73, Tom

dk8cb
26-10-2004, 21:19
Hi,

an even newer version of Dream is available today. The GUI has changed, here is a screenshot.

I really miss the SNR level meter, I think, although it is a very nice feature, the SNR plot is no substitute.

Roland

midre
30-10-2004, 21:17
Hi DRMs,

after a long time of comparison, this software becomes more and more perfect,
and in my opinion, - this software is much better than the offical one.....

Congratulation to the people of TU Darmstadt for this enthusiastic work!

Btw, ..is there a possibility to make a change in the >history time< ?
A variable time setting would be nice ;-)

regards, Michael

GuidoS
31-10-2004, 11:25
I'm sorry to say but I still don't know how to compile DreaM. Once somebody here mentioned he was writing a manual, but I haven't seen anything about that anymore. I'm am wondering if it is possible to do it without programming skills.

Tnx !

VE3MEO
31-10-2004, 13:09
Originally posted by GuidoS
I'm am wondering if it is possible to do it without programming skills.

Guido, I described how I did it in Windows in the DReaM Help Forum (https://sourceforge.net/forum/forum.php?thread_id=1156978&forum_id=242205). That may help but the biggest stumbling block is the price of Visual C++ which you won't have any other use for if you're not into programming.

73, Tom

dk8cb
31-10-2004, 13:20
Originally posted by VE3MEO
but the biggest stumbling block is the price of Visual C++ which you won't have any other use for if you're not into programming.

There is a way to avoid that. I have to sit down later today and finish the manual on how to do it. Promised!

Sorry that I have not finished it yet, it was almost finished when a few things in Dream were changed, making part of the text that I had already written obsolete. This discouraged me a bit in finishing it. :-)

Roland

VE3MEO
05-11-2004, 02:35
Attached is a sample of one of the four graphs created by Norbert Schall's Excel macro from data in the DreamLogLong.csv file.

The download link for the macro is found under the Auxiliaries heading at http://drm.sourceforge.net/ . Read the instructions there and mine at the DReaM Discussion Forum (https://sourceforge.net/forum/forum.php?thread_id=1164811&forum_id=242204)

73, Tom

VE3MEO
05-11-2004, 15:16
Made my own graph, combining SNR, MSC, Doppler and Delay. Nothing fancy, no macros or calculations, but puts more parameters on the one page than Norbert's Macro does. See attached.

Now, if we could get the S-meter reading on there, too!

73, Tom

dk8cb
05-11-2004, 22:42
Hi,

the last few days have brought substantial improvements in Dream's decoding performance.
These improvements are especially significant in the case of long transmission channel impulse responses such as they do occur in the case of NVIS (near vertical incidence skywave) reception or during propagation conditions involving a large number of ionospheric paths.

My thanks go to Volker for the good work.

Roland

dk8cb
06-11-2004, 10:01
Originally posted by dk8cb
The last few days have brought substantial improvements in Dream's decoding performance.

And here is a screenshot illustrating what I wrote.
I am living only 61 kms from the Wertachtal transmitter and at some time during the evening, I suffer from a very long impulse response with many peaks ie reception via many ionospheric paths and a large amount of delay.
Under these conditions, the improved decoding performance achieved with the latest version is quite striking.

Roland

carknue
06-11-2004, 11:52
I'm not quite sure if there is really an improvement in reception, but I noticed an up to 5 dB higher SNR with newest Dream Version when normally the guard intervall is violated on 3995 khz this morning. Unfortunately the Bitrate was too low to see a difference in audio decoding. But it looks promissing. It shows a delay of more than 10 ms what normally cannot be handled by any DRM Mode?!?. The dropout was caused by a bitrate change.

VE3MEO
06-11-2004, 13:13
Originally posted by dk8cb

Under these conditions, the improved decoding performance achieved with the latest version is quite striking.

Roland

Very impressive comparison! Is everything up to the output of the sound card common to both DRMSWR and DReaM? What is your CPU utilisation when both are running (just to be sure there is not a CPU hog interfering with DRMSWR)?

73, Tom

ka2hzo
06-11-2004, 14:02
Removing an interfering AM signal might make a difference for agc.


Yes it does.
So in a in a round about way a filter does help.

dk8cb
06-11-2004, 15:14
Is everything up to the output of the sound card common to both DRMSWR and DReaM? What is your CPU utilisation when both are running (just to be sure there is not a CPU hog interfering with DRMSWR)?

Hi Tom,

yes, everything is common. Both softwares use the same onboard sound and the same input channel (I have configured Dream to use the same channel as the DRMSWR, the other channel is unconnected). One of the sound outputs was either muted (Dream) or set to zero (DRMSWR).

Actually, at that moment, I was running two instances of Dream, one modified version plus the regular one plus the DRMSWR simultaneously. Both Dreams were set at two iterations. CPU load on my AMD XP3000+, Asrock K7S8XE, WinXP system peaked 69%, with about 50% average. No problem in this regard.
I have also done this during perfect reception, then all three decoders produced 100% audio without problems. In addition, I can browse the forum while reception is running without any problems for DRM reception.
The only thing I can't do with any number of software decoders running is to connect my USB memory stick and call the password dialog. If I do so, decoding is interrupted for a few seconds. Don't know why. No performance problems otherwise.

Roland

df9rb
06-11-2004, 17:11
Hello,

real super job done by the software developers from the TU Darmstadt. I started the "old" DREAM and the latest version simultaneous. (Configuration the same as descibed by Roland)The few drop outs with the latest version were only "yellow", in the older version several times the "red" LED switched on.

Bernd, DF9RB

dk8cb
06-11-2004, 17:53
Hi Bernd,

if you select "cut first and last minute", the result will even be better!
The reception result with the new version is only 99.9% and not 100%, because the last minute is included in your analysis, during which the new version was obviously switched off somewhat earlier than the old one.

Roland

VE3MEO
06-11-2004, 17:56
Originally posted by df9rb
I started the "old" DREAM and the latest version simultaneous.
Bernd, DF9RB

Excellent comparison, Bernd. How does the CPU utilisation compare between the two? And the sizes of the dream.exe files?

73, Tom

df9rb
06-11-2004, 19:26
Hello,

the average CPU load is 40 % with both DREAM versions running.
My CPU is an Athlon XP2400+

All my selfcompiled Dream files are 2584 kB +- 5 kB

But the impossilbe oes not become possible with the new Dream version. The distance to the transmitter is only 190 km, the signal 9+40 but the impuls response looks like noise

Bernd, DF9RB

VE3MEO
06-11-2004, 19:54
Originally posted by df9rb

the average CPU load is 40 % with both DREAM versions running.
My CPU is an Athlon XP2400+

All my selfcompiled Dream files are 2584 kB +- 5 kB

Bernd, DF9RB

Hi Bernd,

I must be doing something wrong with my compile. My Dream file come out at 3172kB and its CPU consumption hits over 45% with MLC=1 and over 90% with the BPF on. I can't run MLC=4 and BPF on and two instances of Dream with MLC=1 is liable to have problems with other apps running.

My computer is a notebook running XP Pro on a Pentium 4-M at 2GHz with 256MB RAM. If all else were equal, I would expect that two instances would have average CPU utilisation about 1/6 higher than yours - under 50%.

Are you doing anything to modify what is incorporated in your build? Are there Visual C++ settings that I should be using? I did learn to set it to Release mode, rather than Debug.

73, Tom

dk8cb
06-11-2004, 20:20
Originally posted by VE3MEO
... and its CPU consumption hits over 45% with MLC=1 and over 90% with the BPF on. I can't run MLC=4 and BPF on and two instances of Dream with MLC=1 is liable to have problems with other apps running.
My computer is a notebook running XP Pro on a Pentium 4-M at 2GHz with 256MB RAM.

Hi Tom,

does your CPU load go to almost zero when you close Dream? Perhaps there is something still running that uses a bit of CPU.

Have you compiled the libraries (FAAC, FAAD) in Release mode as well? If not, this might explain the larger file size.

When you asked me about the proper file size a few days ago, I thought, yours might be ok because of hamlib which I do not use. But now, when I see the file size of Bernd's version (supposedly with hamlib included), your's seems to be too large.

Roland

df9rb
06-11-2004, 21:06
Hello,

I think hamlib does not influence the size of DREAM exe.
I have the feeling that only a lot of dlls are added to the DREAM directory.

Bernd

VE3MEO
06-11-2004, 21:26
Originally posted by dk8cb


Hi Tom,

1. does your CPU load go to almost zero when you close Dream?

2. Have you compiled the libraries (FAAC, FAAD) in Release mode as well? If not, this might explain the larger file size.

Roland

Hi Roland,

1. I look at the process list in Task Manager to see what each instance of dream.exe applies to CPU load.

2. I think I extracted these from the pre-compiled files on the DReaM web page. I'll look into this further.

I just received a 1.1.4c compiled on Nov 5 from my Friendly Compiler - size 2585kB and CPU utilisation back down to levels I had seen before with his and others' versions of 1.1 and 1.1.1c.

73, Tom

dk8cb
06-11-2004, 21:43
Originally posted by VE3MEO
I think I extracted these from the pre-compiled files on the DReaM web page.

FAAC and FAAD2 libraries always have to be compiled by yourself. There are no precompiled versions of those files on the Dream webpage.

Roland

VE3MEO
07-11-2004, 00:15
Originally posted by dk8cb


FAAC and FAAD2 libraries always have to be compiled by yourself. There are no precompiled versions of those files on the Dream webpage.

Roland

Hi Roland,

You're right. I had compiled them with Debug configurations and the resulting files in Release are now smaller. Copeid them over to the right folders and rebuilt all in Release mode. Unexpectedly, my dream.exe has now grown from 3172 kB to 3208 kB. That's heading in the wrong direction! I get 4 warnings each time I compile - is that typical of what you get?

73, Tom

dk8cb
07-11-2004, 13:13
Hi Tom,

I also get exactly 4 warnings, that's absolutely normal.

It may well be, that your compiler still uses the old .obj-files from previous compilation attempts.
I recommend that you try to do a cleanup (call it from the Build menu) and let everything recompile anew.
This may also apply to the libraries.
Better call the MOCGui.bat again as well before starting any Dream compilation attempts.

Roland

simone
07-11-2004, 17:58
Hi all,
in my opinion the new version is only an improvement for very special conditions, which I do not meet, so I do not benefit at all from it.
I have done some comparisons today on 17800 kHz where I have an excellent impule response, when the IR got a bit longer but still far away from the limits DReaM indicated a higher SNR, no improvement concerning audio decoding.
On 3995 kHz similar results, at the beginning better SNR with the DRM SWR, later with a longer IR slight advantages for the SNR calculated by DReaM, no big differences in audio decoding, see results in the corresponding threads.
Overall I think everyone needs both softwareradios.
73, Simone

VE3MEO
07-11-2004, 18:21
Originally posted by dk8cb
Hi Tom,

I also get exactly 4 warnings, that's absolutely normal.

It may well be, that your compiler still uses the old .obj-files from previous compilation attempts.
I recommend that you try to do a cleanup (call it from the Build menu) and let everything recompile anew.
This may also apply to the libraries.
Better call the MOCGui.bat again as well before starting any Dream compilation attempts.

Roland

Thanks for the suggestions, Roland. I had done the Cleanup and the MOCgui.bat, although admittedly I had not done Cleanup on the FAAC and FAAD libraries. Having just downloaded the FFTW source files and compiling them, I get a fatter libfftw.lib (741kB) than the pre-compiled one provided by Volker and Andrew (606kB). That's from a clean start. So it seems that there is something peculiar to my compiler or the way I do things. Hopefully it's not a virus - but my virus scanner is up-to-date.

73, Tom

dk8cb
07-11-2004, 18:55
I get a fatter libfftw.lib (741kB) than the pre-compiled one provided by Volker and Andrew (606kB)

I always use the precompiled version of the FFTW library.

My FAAC and FAAD2 library file sizes (as displayed in the properties dialogue):
libfaac.lib: 102 KB (104.596 Bytes)
libfaad.lib: 412 KB (422.400 Bytes)
The values shown in Windows Explorer seem to be rounded.

Roland

carknue
07-11-2004, 21:30
Originally posted by simone
impule response, when the IR got a bit longer but still far away from the limits DReaM indicated a higher SNR, no improvement concerning audio decoding.


I totally agree with Simone. I carefully compared the audio decoding of both Dream 1.1.4 and DRMSWR. It is true that Dream displayes an up to 4 dB higher SNR when the Impulse response is very wide, but there is absolutely no difference in audio decoding. Although Dream calculates a higher SNR it has dropouts at the same time, as you can see in my screenshot. 14dB should be enough for 11.6 kbps but Dream also fails to decode it. Dream always showed optically better results in the log file, but in real it is the same.

Of course you still need both software radios. I use 99 percent of the time the DRM software Radio. Exclusively you need Dream for 18 or 20 khz transmissions and you need the DRM Software Radio for HVCX transmissions.

VE3MEO
07-11-2004, 21:47
Originally posted by dk8cb


I always use the precompiled version of the FFTW library.

My FAAC and FAAD2 library file sizes (as displayed in the properties dialogue):
libfaac.lib: 102 KB (104.596 Bytes)
libfaad.lib: 412 KB (422.400 Bytes)
The values shown in Windows Explorer seem to be rounded.

Roland

And mine are:
libfaac.lib: 114 KB (117.710 Bytes)
libfaad.lib: 495 KB (507,812 Bytes)

Windows Explorer shows the disk space occupied. File Properties shows both the file size and the disk space used. Both show to the nearest kB.

Again, the difference between your compiled sizes and mine indicate something fishy here. Is it possible there are default settings in Visual C++ that I have to change because they are not overrriden by the workspace/project definition?

73, Tom

dk8cb
07-11-2004, 22:40
Originally posted by VE3MEO
Is it possible there are default settings in Visual C++ that I have to change because they are not overrriden by the workspace/project definition?

Apart from Debug/Release, I am not aware of any. Unless you have changed some settings and saved them, such that they are now used instead of those from the the original project files, there should be no problem.
But if you have done so, CVS will always try to merge your changes into the files you have checked out, so you will not get rid of your changes unless you instruct CVS to "get a clean copy".

Have you updated your compiler with the processor pack vcpp5.exe?

Roland

VE3MEO
08-11-2004, 00:15
Originally posted by dk8cb

Have you updated your compiler with the processor pack vcpp5.exe?

Roland

No. I just tried and it errored out saying that I needed Visual Studio 6.0, either Enterprise or Professional edition. I have Visual C++ 6.0 - I guess that's the Standard edition - with SP5, precisely what the DReaM installation instructions call for.

73, Tom

VE3MEO
09-11-2004, 01:53
With the help of a much more knowledgable and experienced VC6++ user (who will remain nameless until he wishes to reveal it) than I am, my fat, hungry dream.exe is as lean and fit as anyone else's. It's now down to 2520 kB.

The key was the vcpp5 upgrade which is not mentioned in the Dream Installation instructions as a requirement. It was described way back, 11 months ago, in the Dream Help Forum in this posting (https://sourceforge.net/forum/message.php?msg_id=2339406) by Andreas Weller.

73, Tom

VE3MEO
11-11-2004, 19:21
I see from the CVS notes that user interface files are being modified to support multiple languages, especially those in the path cvs: drm/drm/common/GUI-QT. Looks to be using the Qt tr() translation function (I can't tell you any more but see Stephane Fillerod's posting (https://sourceforge.net/forum/message.php?msg_id=2846026).

73, Tom

VE3MEO
12-11-2004, 20:32
Two more improvements out today from Volker and Alexander:

1. Support for I-Q outputs from the downconverter
2. Filter selection for any AM mode is remembered for the Dream session when you return to the selected mode. The defaults of 10kHz AM and 5kHz for LSB and USB are the starting point for a new Dream session.

73, Tom

VE3MEO
13-11-2004, 20:16
Volker has changed the bandwidth selection from radiobuttons to a sliding control. Also changed the display of bandwidth from the red bar to a grey background. The attached screen capture shows Dream in USB mode to discriminate against the stronger lower adjacent channel and set to 4802 Hz to reduce heterodyning from the upper adjacent.

Moving the slider causes a ripping noise - see Volker's posting at the SourceForge Open Discussion (https://sourceforge.net/forum/message.php?msg_id=2850743).

73, Tom

DigiBC
14-11-2004, 14:26
Hi!

This morning the new CVS version 1.1.5cvs has been released.
It features the already mentioned changes to the Evaluation Dialog for AM mode and some bug fixes (like the ripping noise).

A few days ago a first adaptation of a MDI (Multiplexed Distribution Interface) function has been integrated. It allows streaming of a DRM multiplex signal over a network. It works in DRM receiver mode but not in transmitter mode (yet).

The appropriate command line arguments to start Dream with:
--mdioutadr <> MDI out network address
format [IP]:[port]
--mdiinport <> set MDI in port numberRegards - DigiBC


PS: Tom, I've been faster this time... ;)

VE3MEO
15-11-2004, 02:31
Originally posted by DigiBC
PS: Tom, I've been faster this time... ;)
So you have, Jens. But I'm continually impressed that Volker and Alexander keep giving us something new to talk about and try. Now we have to build a quadrature tuner to try out this I-Q stuff!

73, Tom

dk8cb
15-11-2004, 08:21
Originally posted by VE3MEO
Now we have to build a quadrature tuner to try out this I-Q stuff!

Hi Tom,

but to achieve really good results with such a tuner, it still lacks some means to correct phase errors introduced by soundcard, mixers etc.


Roland

df9rb
15-11-2004, 15:28
Hi,

today I searched for informations of the advantages of quadrature demodulators. I only found one advantage which is the suppresson of image frequencies. I think my radio has no problem with image frequencies (1st IF 70 MHz). Does anybody know other advantages for DRM reception? If yes please let me know before I start to build such a mixer.

Bernd, DF9RB

dk8cb
15-11-2004, 15:48
Hi Bernd,

Dream could now be used together with direct-conversion receivers in which the RF signal is converted directly to 12 kHz. Then, image rejection is very important.

One example of such a receiver, albeit a very sophisticated one, is the SDR-1000, see http://www.flex-radio.com for more information.
However, much simpler and thus cheaper receivers may also be used.

Roland

DigiBC
15-11-2004, 20:09
Hi!

Volker takes no rest and has just released new code again: Now the analogue section includes a (narrow) FM demodulator. There's also a new "Station Dialog" for AM stations (but the necessary "AMSchedule.ini" file still contains dummy data).

Regards - DigiBC

cesco
16-11-2004, 07:25
>Does anybody know other advantages for DRM reception?

-The bandwidth. 2*24 khz on a normal soundcard. Reception of 20khz DRM would be possible.

-There are no distorsions caused by filter skirts.

-The lack of AGC. DRM copes better with no agc than with a pumping agc.

-The extreme simplicity of such a direct conversion quadrature rx.

>If yes please let me know before I start to build such a mixer.

There are several disadvantages of the concept.
Mirror image suppression will be smaller than 40db on "normal" 1% tolerance hardware. This can be a problem in the presence of strong AM carrieres.

I did never run the normal RX and the IQ-RX in parallel, but i think performance is about the same.

dk8cb
17-11-2004, 09:58
Hi,

in version 1.1.6cvs, the evaluation window now defaults to the Input PSD.

But I don't consider this being an improvement in the sense of this thread.

Roland

carknue
17-11-2004, 18:19
Originally posted by cesco
>
-The bandwidth. 2*24 khz on a normal soundcard. Reception of 20khz DRM would be possible.


Why should the reception of a 20khz signal not be possible with a normal soundcard? I already received 20 khz DRM signals with a quite normal soundblastercard.

cesco
17-11-2004, 18:47
Originally posted by carknue


Why should the reception of a 20khz signal not be possible with a normal soundcard? I already received 20 khz DRM signals with a quite normal soundblastercard.


Because most probably your receiver will have a +-6khz filter. Byebye 20 khz.....

dk8cb
17-11-2004, 21:33
Hi,

in AM mode, Dream's new 1.1.6cvs version now employs new filters that are implemented as windowed FFT filters.

The result is a much better stop band attenuation. Heterodynes originating from stations 10 kHz up or down are no longer audible when receiving AM with a wide IF filter in the signal path.

Roland

VE3MEO
19-11-2004, 01:21
Originally posted by dk8cb
in AM mode, Dream's new 1.1.6cvs version now employs new filters

They sound very good, have steep skirts, no growling or buzzing artefacts when the skirt is on a carrier the way SDRadio does, and now the clicking noise as you slide the bandwidth control is eliminated. Nice!

73, Tom

DigiBC
20-11-2004, 11:05
Hi!

A new version of the hamlib library (1.2.3) is available.

There are no problems compiling Dream 1.1.6cvs with the updated library.
Don't forget to use the new hamlib DLL's too.

For more information visit: http://www.tu-darmstadt.de/fb/et/uet/fguet/mitarbeiter/vf/DRM/installation.html

Regards - DigiBC

dk8cb
26-11-2004, 19:08
Hi,

the new CVS version of Dream features a Weighted Modulation Error Ratio (WMER) plot, that shows the weighted MER as a function of the carrier index.

There used to be some information about the significance of the MER in this paper (http://www.ist-qosam.com/events/2003%20Events/Bath-OJS%20HF%20Conf-0603.pdf) but unfortunately, the document is currently unavailable as I am writing this.
Some information can also be found in this ETSI standard (http://webapp.etsi.org/action%5CPE/PE20040910/en_30224501v010101c.pdf).

Attached is a screenshot of the new plot.

dk8cb
27-11-2004, 09:56
Hi,

let's assume, there is interference from a signal that is weaker than the DRM signal. You would not normally be able to see this interfering signal in the spectrum plot, because it is buried somewhere under the DRM signal.
However, in case the interference is not of a wideband type but more of a narrowband type, certain carriers will nevertheless be affected more than others by the interfering signal. The new plot will reveal which carrier or which range of carriers is affected by the interference signal.
One might even calculate the frequency on which this interference occurs.

Roland

dk8cb
27-11-2004, 14:18
Hi,

here is an example of such a WMER plot taken under special conditions. It was taken while receiving VT-Digital on 9875 kHz with another DRM signal from Kuwait on 9880 kHz.
It can be clearly seen that half of the 9875 kHz carriers are affected by the interference and that there is substantial "noise" on them, degrading the overall decoding result.

Roland

carknue
28-11-2004, 07:39
The snr spectrum is really a nice feature! This shot was taken from a vor transmission on 15780 khz. There was a fat data carrier on 15777 khz that could not always been seen in the normal spectrum, but clearly in the snr spectrum.

dk8cb
28-11-2004, 16:52
Originally posted by carknue
The snr spectrum is really a nice feature! This shot was taken from a vor transmission on 15780 khz. There was a fat data carrier on 15777 khz that could not always been seen in the normal spectrum, but clearly in the snr spectrum.

Here (http://www.drmrx.org/forum/attachment.php?postid=12661) is a similar screenshot, taken while receiving 7320 kHz today. The cause of the interference was a station using frequency shift keying (FSK) with 800 Hz shift. This FSK signal was completely invisible on the spectrum plot. The averaged SNR should have been good enough for perfect reception, however there were dropouts as a result of the interference from the FSK signal.

Roland

tacitus-ms
28-11-2004, 20:01
Thanks for the new WMER plot. I think this is the most useful feature to find cochannel interferences. Recently I have got the Wellbrook ALA 1530 and I've mouted it on an antenna rotor. Now I can use the WMER plot to turn this magnetic loop to find the minimum of the interferer. Now here in Münster I can receive BBC 1296 kHz as stabile as local FM stations without any dropouts.

tacitus-ms
28-11-2004, 22:39
Strange results of the WMER plot in case of DW 3995 kHz. Normally if all carriers have the same WMER SNR the total SNR of the whole signal is nearly the same too. I saw this in case of BBC World, in case of several Sines transmissions. But now I saw this: All carriers neary about 17 dB, but the SNR of the whole signal was about 23 dB. See screenshot. Can that be true?

tacitus-ms

corrados
29-11-2004, 08:45
The WMER for the "SNR spectrum" is a decision-based algorithm on the MSC cells. Since the MSC cells are usually 64-QAM modulated, the decisions might be incorrect quite often (especially at low SNRs). So the SNR value based on the FAC cells (which are modulated with a QPSK) will always be better. That explains the difference.

The "SNR spectrum" should only be used for determining if interferers are present or not.

Volker

tacitus-ms
29-11-2004, 19:06
When I observed the WMER SNR spectrum I got an idea, but I do not know if it could work. Is the WMER measurement algorithm good enough to control an automatic filter, which removes the carriers with low SNR which cannot be used in case of interferences? Would that make sense and could that be possible? Or is it better to have carriers with low SNR than a gap with nothing? If this needs to much processor power for a software solution, could that be useful for hardware based solutions in the future? Does anyone have an idea?

regards tacitus-ms.

corrados
30-11-2004, 07:31
See

https://sourceforge.net/forum/forum.php?thread_id=1181976&forum_id=242204

Volker

dk8cb
03-12-2004, 23:43
Hi,

the latest CVS version of Dream contains a new Modified Metric switch, see attachment.

If activated, the channel estimates are weighted with the SNR estimate of the respective carrier to take into account the higher noise variance of the respective carrier that results from an interfering signal. This is supposed to increase resistance against interference.

So far, when running both old and new versions in parallel, I have not noticed any improvement in interference situations, but I still have to do a few more tests.

Roland

arniek
04-12-2004, 13:51
Hi,

i just compiled the new CVS today and didn't notice any difference with the new feature enabled either.

However right now i'm listening to RTL on 6095kHz and there is a weak carrier on 6100kHz. With Mod. Metric enabled the SNR seems to be a very little bit higher. But maybe the feature only affects SNR calculation in this case, not the stability of reception...

73
Arne

dk8cb
04-12-2004, 15:24
Hi,

today, I conducted a few tests with the penultimate and the latest version of Dream 1.1.6cvs with "Mod Metric" enabled on the latter.

There seems to be a very small gain on the new version. Here are my comparison plots:

VoR, 15780 kHz (http://www.drmrx.org/forum/attachment.php?postid=12827), Bouquet Flevo NL, 7240 kHz (http://www.drmrx.org/forum/attachment.php?postid=12824) and VT Digital, 9875 kHz (http://www.drmrx.org/forum/attachment.php?postid=12826), on which there was the strongest interference (from MOI Kuwait's DRM signal on 9880 kHz) encountered in my test series.

Only a slightly better performance with the new feature enabled.

Roland

df9rb
04-12-2004, 16:29
Hello,

today I did the following test to find out the possible improvements of Mod. Metric in the latest Dream version 1.1.6.
I started Dream two times on my computer one time with Mod. Metric SET, not SET in the second started Dream, and observed the SNRs and the MSC CRC LEDs.
Results:
no differenece on strong DW from Sines
up to 0.4 dB better with Mod. Metric set at RTL in the afternoon
no decoding of any DRM station in the 49 m band in the evening
no difference on BBC on 1296 (with interfering carrier!)

The little improvement on RTL in the afternoon was reproducible by
changing the Mod. Metric setting.

I think these results should encourage us to support the developers to go on analyzing this method and find a better algorithm.

Bernd, DF9RB

simone
04-12-2004, 16:51
Hi all,
I just did a 30 min test the same way as Bernd did it (running the latest version twice, one with the new Mod. Metric feature and the other one not using it) on 1296 kHz with the interferences present, SNR was exactly the same on both, but 0.3 % less decoded audio when using the new feature, I would say there is not really a difference that I could hear.
73, Simone

dk8cb
04-12-2004, 18:39
Hi,

here (http://www.drmrx.org/forum/attachment.php?&postid=12836) is another comparison report (mode A, 1296 kHz), in which the result with "Mod Metric" is slightly worse.

Roland

dk8cb
05-12-2004, 14:02
Hi,

here is an about 11 minutes long comparison plot of the result with respect to correctly decoded audio with "Mod. Metric" switched on and off in two instances of Dream running in parallel.
I have cut off the part of the plot during which only the left instance of Dream was running.

This was recorded during reception of 7320 kHz, it stops at the end of transmission. The sudden drop in SNR at the end was caused by someone else starting AM transmissions on 7325 kHz about a minute before DRM on 7320 kHz ended.

Roland

dk8cb
30-12-2004, 16:38
Hi all,

the current CVS version of Dream has a nice new feature:
All the evaluation plots that are selectable from the evaluation window may now be opened as individual windows and may be displayed simultaneously which allows to monitor different parameters at the same time.
See attached screenshot for an example.

There is also a new noise reduction feature available for AM demodulation.

Very nice. Thanks, Volker!

Roland

VE3MEO
03-01-2005, 20:49
Hear, Hear! and here's my sample from RNWB at 12MHz today.

Tom

Originally posted by dk8cb
Hi all,

the current CVS version of Dream has a nice new feature:
All the evaluation plots that are selectable from the evaluation window may now be opened as individual windows and may be displayed simultaneously which allows to monitor different parameters at the same time.
See attached screenshot for an example.

There is also a new noise reduction feature available for AM demodulation.

Very nice. Thanks, Volker!

Roland

dk8cb
03-01-2005, 21:45
Originally posted by VE3MEO
Hear, Hear! and here's my sample from RNWB at 12MHz today.

Hi Tom,

so many windows but where is the input spectrum - in my view the most important of them all?
I wanted to check why your WMER plot shows low values at the edges, but for that, the input spectrum is required.
Is there interference or is your IF filter a bit too narrow? From the Input PSD it rather looks like the latter.

Roland

VE3MEO
03-01-2005, 22:02
Originally posted by dk8cb


Hi Tom,

but where is the input spectrum - in my view the most important of them all?
I wanted to check why your WMER plot shows low values at the edges, but for that, the input spectrum is required.
Is there interference or is your IF filter a bit too narrow? From the Input PSD it rather looks like the latter.

Roland

Hi Roland,

I find the Input Power Spectral Density plot to be more useful than the Input Spectrum - it shows the essentials without the visual 'noise'. Maybe that's why Volker put it first.

Yes, I am using a nominal 10kHz bw filter with steep skirts - it's a LF-D6 15-element ceramic, and not especially flat across the passband, also affected by the loading of the subsequent, stock 7kHz IF filter.

One of the problems with a steep-skirted 10 kHz filter is that noise looks like a DRM signal in the spectral plots! A 20kHz filter is better - a real DRM signal then jumps out of the noise.

73, Tom

dk8cb
03-01-2005, 22:17
Originally posted by VE3MEO
Yes, I am using a nominal 10kHz bw filter with steep skirts - it's a LF-D6 15-element ceramic, and not especially flat across the passband, also affected by the loading of the subsequent, stock 7kHz IF filter.

It looks more like an 8 kHz wide filter, the outer carriers seem to be strongly attenuated, especially at the upper end. I think that you could obtain better reception with a wider filter in some cases.

Roland

dk8cb
06-01-2005, 12:47
Hi,

in case of UEP (unequal error protection) transmissions, Dream's latest CVS now also displays the percentage of the data stream's part that has a higher degree of protection with respect to the total data block length.
See attached screenshot for an example.

Roland

VE3MEO
08-01-2005, 02:02
And now the extra windows are saved on closing so that they re-appear in the next session. That's nice - saves a lot of keystrokes and resizing. I was going to suggest that :p

73, Tom

FritzWue
09-01-2005, 17:06
My main problem when listening to drm on mediumave at daytime are switches: Light switches, the burner of the heating system, refrigerator, etc..

Everytime a switch is actuated the snr drops for several seconds sometimes causing audio dropouts, see attached screenshot.
In my case I need a proper grounding system for my outdoor antenna, but what will happen when we want to listen to drm in the car etc. where electrical noise is a common problem?

As the crackling of a switch is a very short event I wonder if it is possible to include something like a software noise blanker into the decoding software.

simone
09-01-2005, 18:16
Hi Fritz,
Originally posted by FritzWue
My main problem when listening to drm on mediumave at daytime are switches: Light switches, the burner of the heating system, refrigerator, etc..
but what will happen when we want to listen to drm in the car etc. where electrical noise is a common problem?


I would not be worried about receiving DRM on MW in the car, see these results (http://www.drmrx.org/forum/attachment.php?postid=10584) as an example, see also mobile reports (http://www.drmrx.org/forum/showthread.php?s=&threadid=599) but those are mostly results on SW, often better than at home, I think I also posted some mobile results in the 1296 kHz BBC WS thread.
73, Simone

dk8cb
10-01-2005, 21:24
Hi,

the latest CVS version of Dream does not show the dropouts in the log on RTL's 1440 kHz very low bitrate nighttime transmission anymore.

Roland

df9rb
21-01-2005, 17:22
Hi all,

today the reception of BBCWS on 1296 kHz is quite bad at my location because of a strong interfering carrier. I tried again to improve reception using the notch of my receiver. I changed between notch ON and OFF every 2 minutes and I run the radio with manual gain control to avoid an influence of the AGC.
The attached SNR History shows the influence of the notch.
(minute 15 to 14 notch ON, 14 to 12 OFF, 12 to 10 on, ....)

I think this diagramm clearly shows the positive influence of the notch on the SNR and correctly decoded audio!

Concerning this result I think a notch (or a algorithm not to process the DRM signal around the carrier) sould be implemented in DREAM.

The second picture shows PSD without/with notch

Bernd, DF9RB

dk8cb
21-01-2005, 18:40
Hi Bernd,

have you adjusted the manual AGC high enough such that there is no distortion in the IF chain because of it being overdriven by the carrier?

Roland

df9rb
22-01-2005, 07:51
Hi Roland,

I adjusted the gain to -20 dB Input Level manually and tried to hold this level during logging. This is quite easy on medium wave because the fading is much slower here. In the PSD screenshots you can see that the carrier is at -45 dB where the DRM spectrum normally is at -60 dB. I did not see this during logging therefore I checked the influence of manually adjusted gain after I had read your answer. There was nearly no influence between
-15, - 20 or -30 dB Input Level - only the notch improved the SNR and percentage of decoded audio.

The latest CVS-Version of DREAM has a button Modified Metrics.
I also tried this button. But there was no influence on BBCWS.

Bernd, DF9RB

dk8cb
23-08-2005, 08:52
Hi all,

the latest CVS development version of Dream (still 1.2.5cvs) shows a new, somewhat minimalized main window.

The attachment shows this main window in its minimum size, it can of course be made larger such that the level meter becomes better to read. The user may choose the line colour (red at first start, changed to light green in the screenshot), this personal colour setting is also stored permanently.

In addition, the colour combinations for the plot windows (blue on white, green on black or black on grey) can now be selected from the 'Settings' drop down menu in the main window.

The Dream logo has now been removed.

UPDATE: The version number has now been updated to 1.3cvs.

Roland

mitajohn
25-10-2005, 18:22
Hi all,

I downloaded the version 1.3.1cvs, and use it for testing on 3995.
It seems that it handles very well the interference. I found also a bug in recording of the log: sometimes it logs sync=299 or 300 and audio= 2339/10 or something. These figures are wrong. I have also noticed this in some of yours posted logs. Have anybody noticed this? Is there any work around to correct it?

John

carknue
25-10-2005, 18:31
Originally posted by mitajohn

I found also a bug in recording of the log: sometimes it logs sync=299 or 300 and audio= 2339/10 or something. These figures are wrong. I have also noticed this in some of yours posted logs. Have anybody noticed this? Is there any work around to correct it?

John

Yes, do not touch Dream while logging. You get these high values when you move or resize a Dream Window. Its a problem of the Qt GUI.

mitajohn
25-10-2005, 18:56
Hi Carsten,

Thanks for the explanation. I haven't noticed this in version 1.2.4.

John.

dk8cb
25-10-2005, 21:27
Originally posted by mitajohn
I haven't noticed this in version 1.2.4.


The problem has nevertheless been there for a long time. Dream fails to notice the minute change and adds up the number of received frames and logs it as belonging to the next minute.
It very much depends on the precise moment when you move or resize a window.

Roland

dk8cb
22-11-2005, 09:55
Originally posted by Digger
Is this a known issue?

Better post this question on the Dream support forum (http://drm.sourceforge.net/forums/index.php?showforum=5).

Roland

dk8cb
05-02-2006, 14:09
Hi all,

thanks to contributors from the BBC and Andrea Russo, the latest CVS-version of Dream now contains an electronic programme guide (EPG) decoder and viewer.
EPG data is already available on BBC DRM transmissions. See attached screenshot for an example of how data is displayed.

EDIT: I have replaced the screenshot with one that also shows the 'Genre' column, it was invisible in the previous screenshot.

Roland

simone
05-02-2006, 19:31
Hi Roland, all,
seems there is a lot of information missing in your example, maybe a problem with the GUI using Windows, should look like this, but thatīs a topic for the Dream forum.
Simone

dk8cb
08-02-2006, 09:27
Hi all,

after a few problems have been corrected, the new electronic programme guide (EPG) window in Dream now looks a bit different, see screenshot.

The green dot indicates the programme that is currently running.
Quite nice!

Roland

mitajohn
18-02-2006, 16:39
Hi all,

I downloaded version 1.6.1cvs. I can see the live schedule dialog with the active or all stations. The programme guide window on BBCWS is empty! no data...Why this? Any solution?

John.

dk8cb
18-02-2006, 17:02
The programme guide window on BBCWS is empty! no data...Why this? Any solution?


For how long have you waited during reception of BBCWS until you looked at the EPG window? It takes some time for the data to accumulate.
On which frequency are you listening and does Dream show that EPG data is being transmitted?
EPG data is not always transmitted, eg there is no such data when the backup stream is used.

Have a look at: http://drm.sourceforge.net/forums/index.php?showtopic=151

Roland

mitajohn
18-02-2006, 17:24
Hi all and Roland,

Actually I was waiting for only a few minutes.....I am just tuned on BBCWS 7465 kHz. I will wait for the result.

Thanks,
John.

mitajohn
18-02-2006, 17:30
......and as a miracle the window filled with information, see attachment (I am afraid in low resolution).

John.

dk8cb
18-02-2006, 17:47
......and as a miracle the window filled with information, see attachment (I am afraid in low resolution).


But the data received is still not complete, just wait a little longer and it will look like the attached screen.

Roland

mitajohn
18-02-2006, 19:32
Hi all and Roland,

The window completed after a while with the green dot...
Now, DW on 3995 kHz has a live schedule dialog with a wrong frequency 7390 kHz. I found only the presence of a carrier no DRM. Is this correct?

John.

dk8cb
18-02-2006, 20:12
I only get a strong signal from VoR in english on 7390 kHz at the moment but if there were a DRM transmission from a german TX site, I would certainly be located too close to be able to receive it at this time of the day.

Roland

tacitus-ms
18-02-2006, 20:51
Hi all,

I downloaded version 1.6.1cvs. I can see the live schedule dialog with the active or all stations. The programme guide window on BBCWS is empty! no data...Why this? Any solution?

John.

Hi, I tested CVS 1.61 from 10.02.2005, and it works nice. Today I have tested CVS 1.62 from 18.02.2005, and it causes 100 % processor load. It is nearly impossible to close the application, because my 2 GHz Pentium 4 is too slow. After clicking the close-button (the x on the right side) it takes about 30 sec that all windows of dream are closed and the PC is able to work again. After closing the last window of dream I get an error message: "Termination of sound interface thread failed."

regards tacitus-ms

dk8cb
18-02-2006, 21:39
Today I have tested CVS 1.62 from 18.02.2005, and it causes 100 % processor load. It is nearly impossible to close the application, because my 2 GHz Pentium 4 is too slow. After clicking the close-button (the x on the right side) it takes about 30 sec that all windows of dream are closed and the PC is able to work again. After closing the last window of dream I get an error message: "Termination of sound interface thread failed."



I do not have such problems with the latest version which I compiled today.
But in any case, this is a question which should be posted in the Dream support forums (http://drm.sourceforge.net/forums/index.php?act=idx).

Roland

dk8cb
19-02-2006, 13:57
Today I have tested CVS 1.62 from 18.02.2005, and it causes 100 % processor load.

I have posted my own quite different observations with this version on the Dream support forums and I have included a link to your post.

Roland

johnn
20-02-2006, 11:36
Like the programme guide very much & the work put into it!

mitajohn
18-08-2006, 14:08
Hi all,

Can anybody explain what's the purpose of "DreamLogLong.csv" file? It's like a log file in "excel" form and has reached the size 500MB. Can be disabled or not (except of deleting it).

John.

FritzWue
18-08-2006, 14:34
Hi John,

that's the long version of DreamLog.txt with one second resolution. :D
You find the titles in the first line.
You may delete, rename or move DreamLog.txt and DreamLogLong.csv when DREAM is closed.
DREAM will create new files when starting the next log.
I think DRMcalc uses some values of the long log, i.e. SNR Maximum etc..

mitajohn
18-08-2006, 15:05
Hi Fritz and all,

Thanks for the answer. I am just starting using Dream v1.6.24cvs. I noticed that in AM mode the cursor does not lock to the selected frequency unless Cntl+A or mouse click. This does not happens with v1.6.1cvs. Is this a bug?

John.

simone
18-08-2006, 15:06
Hi John,
...I think DRMcalc uses some values of the long log, i.e. SNR Maximum etc..

Hi John,
DRMcalc does not use the .csv file
Simone

dk8cb
18-08-2006, 18:30
If you want to deactivate logging to the loglong.csv file, then look here (http://drm.sourceforge.net/forums/index.php?showtopic=45).

For an Excel macro that makes use of the loglong.csv file look here (http://drm.sourceforge.net/download/DW_DREAM_macro.zip).

Roland

aru
19-08-2006, 13:26
Hi Fritz and all,

Thanks for the answer. I am just starting using Dream v1.6.24cvs. I noticed that in AM mode the cursor does not lock to the selected frequency unless Cntl+A or mouse click. This does not happens with v1.6.1cvs. Is this a bug?

John.

Post this message into the Dream's forum: http://drm.sourceforge.net/forums/

aru

mitajohn
30-08-2006, 16:08
Hi all,

I have been informed that the autotune feature in AM mode has been removed deliberately from the current versions of Dream. If this is true I think is bad.

John.

aru
30-08-2006, 17:22
Hi all,

I have been informed that the autotune feature in AM mode has been removed deliberately from the current versions of Dream. If this is true I think is bad.

John.

No. The autotune is present.
The only thing is that Dream now saves the preferences of the AM Analog Dialog, so you simply check the box "Auto Frequency Acquisition" to activate autotune.

In case of future Dream problems please post a message on the Dream forum.

bye,
aru

tedex
28-12-2006, 19:15
any idea how to turn off the "trial" audio message?

tedex
30-12-2006, 00:05
any idea how to turn off the "trial" audio message?
NM - it was VAC

mitajohn
12-03-2007, 16:54
Hi all,

This is the first time I noticed that Dream 1.6.1cvs is crashing continuously a couple of minutes after it is tuned on BBCWS 7465kHz. What is wrong ?

simone
12-03-2007, 17:49
There is a problem with the BWS since some time, the latest version of Dream runs OK and decodes the BWS, I also had 1.7.5 running since 1600 UTC with the multimedia window not open and it did not crash.
Simone

mitajohn
12-03-2007, 18:11
Thanks Simone.
My last report on that frequency, without problems, was on March 2. It seems the problem started sometime after that day. I used for a while ver. 1.8.2cvs but it has some problems in the log file as is mentioned elsewhere.

Digger
12-03-2007, 19:21
Interesting.... I tried logging BBC yesterday and 1.6.1 crashed on me 3 times. Then I gave up. Thanks for the information. Somehow I got hold of the 1.7.9, but when you start it with Scheduled Tasks in Windows, it won't record the frequency, even that I write it in Dream.ini. I'll go back to the good ol' 1.6.1 again

sveron
13-03-2007, 21:06
Hello to all,

I had the same problems with v. 1.6.1.cvs on saturday, since that I didn't listen to the BBC. Now I know I am not alone ! I will try another version then.

73, de Stephane

FritzWue
14-03-2007, 00:17
...same here.:confused:

aru
15-03-2007, 05:24
Hi all,

yes the BBCWS data channel was wrong (empty mot files, gzip files wrong, etc.).
I have contacted the bbcws techical service and they have fixed the problem.

And also Dream now has been changed with a defensive code for prevent the segmentation fault if MOT files are empty (0 byte).

bye,
aru

FritzWue
02-07-2007, 22:28
Is the DREAM DRM Stations Dialog not updated anymore or do I have a problem? :confused:

simone
03-07-2007, 14:56
Hi Fritz,
I just tried updating the schedule from the stations dialogue, seems OK to me, the schedule does include DW changes from July 1st.
Simone

FritzWue
03-07-2007, 19:46
Hi Fritz,
I just tried updating the schedule from the stations dialogue, seems OK to me, the schedule does include DW changes from July 1st.
Simone

Hi Simone,
thanks for info.
I think I updated too early to see the changes.

simone
26-10-2012, 16:43
Dream 1.15 has been released today, please see here (http://sourceforge.net/projects/drm/files/drm/1.15/) for information and download.

Simone

tpreitzel
27-10-2012, 08:09
Dream 1.15 has been released today, please see here (http://sourceforge.net/projects/drm/files/drm/1.15/) for information and download.

Simone

Although Julian is doing a fine job maintaining DReaM, it's probably time to replace the requirement for fftw2 with fftw3.

simone
27-10-2012, 21:04
Although Julian is doing a fine job maintaining DReaM, it's probably time to replace the requirement for fftw2 with fftw3.

We are working on this, you already can compile it with fftw3 but it is not running reliably yet. Actually it detects automatically if you have fftw2 or fftw3 libraries installed.

Simone

AF4MP
29-10-2012, 17:58
Dream 1.15 has been released today, please see here (http://sourceforge.net/projects/drm/files/drm/1.15/) for information and download.

Simone, thank you for the update.

The above link contains the following information in the ReadMe file:

"The binaries are compiled without support for AAC decoding or encoding. On windows, if you want to hear the audio of a DRM broadcast you will need to obtain a copy of faad_drm.dll and place it in the same directory as the dream.exe file."

To prevent hours of frustration, rename faad_drm.dll to faad2_drm.dll.

simone
31-10-2012, 17:28
Hi Zyg,

thanks for your comment, I have updated the readme.txt now to avoid confusion.

Simone

AF4MP
31-10-2012, 22:55
Hi Simone,

Thank you.

I notice that version 1.15 when used with DRM Logger 3.3 does not change the frequency on the log file.

FritzWue
01-11-2012, 05:46
Three more things with V 1.15:

1. The "minimize to task bar" knob in the main window is missing.

2. When you sort the stations by frequency in the stations window by clicking on the title bar this sorting is lost with the next start of DReaM.

3. The level meter is green/white instead of green/red.

( Win XP )

tpreitzel
03-11-2012, 06:51
We are working on this, you already can compile it with fftw3 but it is not running reliably yet. Actually it detects automatically if you have fftw2 or fftw3 libraries installed.

Simone

Thanks Simone. I've read Julian's response to my more detailed comments on Source Forge, but I haven't retried the compilation of DReaM 1.15 yet. I'll get to it along with responding to Julian.

FritzWue
04-11-2012, 07:55
DReaM V1.15:

What is the questionmark button in the Multimedia Journaline Window good for? :confused:
Seems to be there without any function.

simone
04-11-2012, 13:42
Hi Fritz,

these are minor bugs and will be (mostly have already been fixed) in v 1.16.

Simone

FritzWue
04-11-2012, 14:33
Hi Fritz,
these are minor bugs and will be (mostly have already been fixed) in v 1.16.
Simone

Hi Simone,

you are right, the missing to taskbar etc. problems are only minor bugs, but this one should be fixed first:

When you sort the stations by frequency in the stations window by clicking on the title bar this sorting is lost with the next start of DReaM.

Hope it's OK to report bugs here, only try to improve the software for us all.

Linux-DRM
04-11-2012, 17:20
Is Dream v1.15 broken on Linux? does not decode here at all, v1.13 works fine (both compiled from source). Maybe I missed something?
On Debian Squeeze (6.0.6).

Cap

simone
04-11-2012, 19:04
Hi Cap,

no itīs not broken for Linux, sounds like a problem with the AAC decoder, did you build it with faad2 or do you load the faad2 library dynamically when running Dream, that was a new option in 1.14.

Simone

Linux-DRM
04-11-2012, 22:27
It's faad2-2.7 compiled from source, I will have a look and see what I have missed.
Cheers.

Cap

Linux-DRM
15-11-2012, 20:49
It could not find libfaad_drm correctly (-lfaad_drm) so linked it manually (SVN version v1.16).

I have used the Analog Demodulation through Dream for the past year as the filtering works really well in AM/CW/SSB. I also think the speed of the processing is quicker in v1.16, compared to v1.13 anyway. :)
Thanks for all the hard work guys!

Cap

simone
18-11-2012, 19:17
Today we released Dream1.16 (https://sourceforge.net/projects/drm/files/dream/1.16/), still a few rather small bugs left, see release notes for changes.
Simone

simone
21-11-2012, 17:46
Hi,
with the Dream 1.16 release we provide binaries for a qt2 and a qt4 version, also for those who compile themselves we still support MSVC6.
I would like to get some feedback, are there people who prefer to use the qt2 version or who have to stay with the qt2 version because they can not run the qt4 version? Did anyone notice any disadvantages when running the qt4 version?

Thanks,
Simone

tpreitzel
22-11-2012, 05:45
Hi,
with the Dream 1.16 release we provide binaries for a qt2 and a qt4 version, also for those who compile themselves we still support MSVC6.
I would like to get some feedback, are there people who prefer to use the qt2 version or who have to stay with the qt2 version because they can not run the qt4 version? Did anyone notice any disadvantages when running the qt4 version?

Thanks,
Simone

Simone,

I'll make this brief until after Thanksgiving when I'll explore more.

Wow! I successfully compiled DReaM revision 365 without much problem at all on Slackware64 14.0. Since the slackbuild for QWT-5 installs the headers in /usr/include instead of /usr/include/qwt, I manually created a qwt sub-directory under /usr/include and temporarily linked the qwt headers into that sub-directory. The QWT slackbuild really should place QWT's headers in /usr/include/qwt instead of /usr/include so it's not really a problem. Just ensure the requirement for QWT's headers to be placed in /usr/include/qwt is prominently displayed, e.g. bold italics, for those people compiling DReaM.

I'll test the functionality of DReaM within the next couple of days.

Personally, I'd just eliminate support for QT3 and versions of QWT preceding version 5. Let's bring DReaM into the 21st century. DReaM now compiles flawlessly thanks to you, Simone, Julian, dflamand, and others currently working on this worthwhile project.


More later.

AF4MP
22-11-2012, 13:07
I would like to get some feedback, are there people who prefer to use the qt2 version or who have to stay with the qt2 version because they can not run the qt4 version? Did anyone notice any disadvantages when running the qt4 version?

My problem with 1.16 is that both versions do not work with DRM Logger 3.3.

qt2 does erratic logging while qt4 does not start the dreamlog.txt and dreamloglong.txt files.

Both versions appear to log correctly if DRM Logger is not used.

The qt4 rig control window is different from the usual window that shows up with qt2 (see attachments).

drmdab
25-11-2012, 10:52
Hi,

I guess this question has been asked over and over already, so I would be very glad if somebody would just point me to the page where the answer is given:

If you tune to the Voice of Russia's 9625 kHz, all you hear in DREAM is silence, although the SNR is around 30 dB and everything's fine. If you use the Fraunhofer Software Radio, audio appears and plays without any problems. So it seems some codec is missing in this setup? What solves this problem?

Thanks and best regards

FritzWue
25-11-2012, 11:25
Hi,

I guess this question has been asked over and over already, so I would be very glad if somebody would just point me to the page where the answer is given:

If you tune to the Voice of Russia's 9625 kHz, all you hear in DREAM is silence, although the SNR is around 30 dB and everything's fine. If you use the Fraunhofer Software Radio, audio appears and plays without any problems. So it seems some codec is missing in this setup? What solves this problem?

Thanks and best regards

Did you try this?
http://www.drmrx.org/forum/showpost.php?p=78228&postcount=213

drmdab
25-11-2012, 11:32
Yeah, I did. But I did now again - and it worked. No idea why it did not work on my first try, but thanks to you DREAM plays again how it should! :-)

drmdab
07-12-2012, 10:39
Next problem: To use my good old Digital World Traveller again, I created a virtual machine using Windows XP Home Edition and VM Ware. The DWT works fine, so does the DRM Software Radio. Feeling like in a time machine back to 2005 :)

But the current version of DREAM won't start. It says MSVCP100.dll cannot be found. Any hits how to solve this problem? --> Forget it, adding the missing files to system32-folder was enough already. :)

Thanks!

AF4MP
23-12-2012, 03:41
Although not DRM the DReaM software version 1.15 does a great job on analog reception.

Attached is the spectrum plot of WBCQ's Saturday late night music program in AM on 7490 kHz with very good quality audio (Jimi Hendrix at the time).

Receiver in use the Ten-Tec RX320D and a long wire antenna with a Pentium 4 (2.40GHz) computer and the Turtle Beach Santa Cruz sound card.

simone
27-12-2012, 12:22
We have released Dream 1.17 (https://sourceforge.net/projects/drm/files/dream/1.17/), please let me know of any problems. Support for DRMLogger has changed, see instructions on the wiki.
Simone

FritzWue
27-12-2012, 19:14
Three more things with V 1.15:
1. The "minimize to task bar" knob in the main window is missing.
2. When you sort the stations by frequency in the stations window by clicking on the title bar this sorting is lost with the next start of DReaM.
3. The level meter is green/white instead of green/red.
( Win XP )

All my reported problems are gone with V 1.17. :)
...and I like the shorter audio buffer. :)
In the evaluation dialog there is no frequency line any more,
but that was not working well anyway.

Still we now have the problem that if I want to report a transmission on a brandnew frequency
I first have to edit the DRMSchedule.ini or later the DreamLog.txt to get the right frequency
into my report.
...not very comfortable, perhaps something for V 1.18. :D

simone
27-12-2012, 19:30
All my reported problems are gone with V 1.17. :)
...and I like the shorter audio buffer. :)
In the evaluation dialog there is no frequency line any more,
but that was not working well anyway.

Still we now have the problem that if I want to report a transmission on a brandnew frequency
I first have to edit the DRMSchedule.ini or later the DreamLog.txt to get the right frequency
into my report.
...not very comfortable, perhaps something for V 1.18. :D

Hi Fritz,
you can set the frequency in the stations dialogue or start Dream with -r option and the frequency will be written to the logfile.

Simone

tpreitzel
27-12-2012, 19:49
We have released Dream 1.17 (https://sourceforge.net/projects/drm/files/dream/1.17/), please let me know of any problems. Support for DRMLogger has changed, see instructions on the wiki.
Simone

Simone,

Is it possible to set the DESTDIR environment variable in the generated Makefile from dream.pro? I'm unsure how qmake running dream.pro would set the variable. As it stands, DESTDIR is null in the generated Makefile. I'm trying to use the script, src2pkg, to generate a package for Slackware, but since DESTDIR isn't specified, installation of Dream.ini and the data directory simply default to my home directory.

Regardless, DReaM-1.17 compiles and runs just fine as long as I run it from the source directory and don't try to install it as a package.

AF4MP
27-12-2012, 22:50
Simone,

Thank you for the new release. I had no problems getting qt2 to work. :)


you can set the frequency in the stations dialogue or start Dream with -r option and the frequency will be written to the logfile.

Using DRMLogger it would be nice not to have to edit the Dreamlog and Dreamlonglog files to have the correct frequency but I'll try the -r option.

Thanks again!

simone
28-12-2012, 04:01
Using DRMLogger it would be nice not to have to edit the Dreamlog and Dreamlonglog files to have the correct frequency but I'll try the -r option.

Hi Zyg,

the -r is only at first start, but with DRM Logger you get the correct frequency automatically in the logfiles, no need to edit them.

Simone

AF4MP
29-12-2012, 01:04
Hi Simone,

Thanks again for your help. The DRMLogger solution works well with qt4! :)

FritzWue
30-12-2012, 11:51
Hi Fritz,
you can set the frequency in the stations dialogue or start Dream with -r option and the frequency will be written to the logfile.

Simone
Ah, that's nice and easy! :eek: Thank you! :D

tradio99
30-12-2012, 21:42
Hi Fritz,
you can set the frequency in the stations dialogue or start Dream with -r option and the frequency will be written to the logfile.

Simone


frequency of a log changes every time I change it in a station dialog during one log recording, and every time new log recording starts :confused:

simone
31-12-2012, 06:10
frequency of a log changes every time I change it in a station dialog during one log recording, and every time new log recording starts :confused:

Hi tradio99,

isnīt that what you want it to do?

Simone

tradio99
31-12-2012, 11:23
Hi tradio99,

isnīt that what you want it to do?

Simone


Hi Simone!
It was just a test. If I was software developer I would block this option.

tpreitzel
03-04-2013, 09:22
We have a newly registered developer of DReaM, Bryan Hodge.

Welcome, Bryan!

DRM has a great future!

mvs sarma
12-07-2013, 07:45
unable to decode drm signals using dream 1.17. earlier we had this issue with ver1.14 and after following a suggestion (thanks to hypervista) adding faad2drm.dll in the folder, we managed it.

this time all done, i was unable to use . it doesn't enable the last green point, without which audio wont come.

i humbly seek for some assistance to be able to use it .

thanks in advance.

oh2bfo
12-07-2013, 15:19
unable to decode drm signals using dream 1.17. earlier we had this issue with ver1.14 and after following a suggestion (thanks to hypervista) adding faad2drm.dll in the folder, we managed it.
Try renaming the DLL file: faad2_drm.dll with underscore should work.

mvs sarma
13-07-2013, 14:29
Try renaming the DLL file: faad2_drm.dll with underscore should work.
Thanks please. i shall get back soon.

mvs sarma
14-07-2013, 14:15
Thanks all
Now i am able to get the decoded voice.
In fact the file wasn't found in the directory. Instead i had a zip folder named "faad2_project_files"
which i expended and placed in the said dream 1.17 folder.
this file never contained faad2_drm.dll


thanks for the help
Is it possible to get latest "faad_drm.dll" ?

mvs sarma
17-07-2013, 14:32
stations dialog of DREAM 1.17 is not showing active stations , even after update, while 1.12b is showing well.