Activity for Oliver Haffenden
-
Oliver Haffenden committed [r1418] on Code
Removed prints.
-
New rama format working
-
Updating rama tag to latest RSCI version including MIME-type defined codec
-
Adding standard AAC for RAMA tag
-
Receiver now responds to RCI cdmo (change demod mode) commands.
-
Added fmjd in AM mode
-
The source is designed to be able to build with a wide range of different configurations: e.g. it can use different audio decoding libraries, different sound devices etc. Trying to make these all work at the same time is like whacking moles, but feedback from people like yourself who have a different configuration is a great help to us, so thanks for taking the time to post. If it won't build without Soapy, that's my bad, because it should be possible to build it to use a soundcard input carrying...
-
I've just looked and I see what you mean about the #include being omitted if WIN32 is defined. If you do want to use Soapy, I think the first step would be to move that outside that #if altogether. Have you been able to install Soapy itself? It looks like there are Windows installers for it.
-
Hello Gisle and thanks for your enquiry. I haven't tried building my branch (dream-ollie or dream-ollie-deployed) on Windows so I'm not surprised there are issues. I'll try to help you later this afternoon, but to point me in the right direction: are you wanting to use Dream with an SDR front-end of some kind, using the SoapySDR library? That's the main thing that my branches offer in addition to e.g. dream-rafa.
-
Don't have multiple HTTP requests in-flight at the same time, to allow for long polling.
-
Fixes to make AM with RSCI out work:
-
In a commit on my dream-ollie branch, I came to the conclusion that the definition in DialogUtil.h was unnecessary and could be deleted altogether. I may have been mistaken in that conclusion, though! I also made some changes in that branch to deal with a change in the API of the gpsd library automatically based on its version, which is another recurrent problem.
-
I'd be interested to know how you get on with the AirSpy. I know @fineware was trying it at the time of this thread and there's some discussion there. I only have SDRPlay devices so I can't test others, so any reports from users of other SDRs are very welcome.
-
You should be able to use the "Stations Dialog" either to select a scheduled transmission or to tune manually.
-
Hi. I haven't done any work on that, and I think I started from your branch, so it's probably the same. In our monitoring receivers, I have it running as a service, so it restarts if it crashes.
-
It's likely that you won't need any of the RSCI-related features, but dream-ollie and dream-ollie-deployed are the only branches that have built-in support for SDR front-ends using the SoapySDR library, so that might be useful to you.
-
Hi. Yes, I added the ability to stream RSCI data via http, which is a more modern and secure way of doing it than the old plain TCP connection approach. I started that branch from an older version (1381) of dream-ollie, because the last few commits on the dream-ollie branch were more prone to freezing. I also did a partial fix for the case of controlling I/Q recording using RSCI commands.
-
Hi. Yes, I added the ability to stream RSCI data via http, which is a more modern and secure way of doing it than the old plain TCP connection approach. I believe i started that branch from an older version of dream-ollie, because the last few commits on that branch were more prone to freezing.
-
Added reception of RCI commands via a GET to the same URL as the PUT. (TODO make them different?)
-
Tidied up logging
-
Allow username and password in http:// scheme
-
Added HTTP/HTTPS as a protocol for RSCI
-
Hopefully calling inits for all modules (rather than just some) will stop unpredictable behaviour when starting and stopping IQ recording.
-
Fixes to RSCI-controlled I/Q recording.
-
Added missing include (don't know how this was ommitted from r1381)
-
Steve, I haven't put any attention into AM; in fact I thought it crashed instantly in AM mode, so it's apparently not as bad as I thought! We'd definitely want to get AM working before doing a new release, but I'm afraid I have several other things I need to do first. Happy new year! Ollie.
-
Branching from rev 1381 which was more stable
-
Added watchdog file. Possibly not yet tested!
-
Changes to Theseus: adding OpenStreetMap-based map.
-
Hi and many thanks both for trying out my branch and for the bug report. Don't worry about the font - actually it makes it much easier to read! In both cases, I'm a bit puzzled because the crash is happening when the receiver tries to process data from the RSCI or MDI input (line 857 of DrmReceiver.cpp). Given that you're trying to use an SDR front-end, it shouldn't be getting to that line at all. Please could you share the command-line that you're using to invoke Dream? Assuming you're not accidentally...
-
Hi. There's some information on creating and checking out branches here. I actually checked out the whole repository, but it looks like that wasn't the normal way of doing it! It looks like you want to do something like svn checkout svn://svn.code.sf.net/p/drm/code/drm-code/branches/dream-ollie or the equivalent if you want https or read-write SSH access.
-
Added some test prints
-
I came to the same conclusion - there's no need for the typedef in DialogUtil.h. This and the gps changes are in the dream-ollie branch and we would hope to include them in a release before too long.
-
Fix building with the hamlib-4
-
Fix building with gpsd-3.20
-
Fix building with gpsd-3.23
-
Thanks for this. I'd incorporated it and the one from #234 in my branch (dream-ollie) but some distros still have older versions of the gpsd package. I've just done a commit 1387 which attempts to handle the incompatible changes using #if directives based on the major version of the gpsd library. I'd be interested to know if it compiles for you.
-
Access to GPS struct depends on version number of gpsd library.
-
Corrected mechanism for switching tuner between rig and SDR.
-
You make a fair point that the default configuration generated by Dream ought to work. The problem is that the correct settings depend on the particular SDR but that is abstracted away by SoapySDR. It's analogous to the way hamlib might need specific settings for particular rig model. Dream deals with that by having some settings hard-coded in the CHamlib class and stored in a lookup-table. The SoapySDR API does include an auto/manual gain mode settings which could be exposed to Dream. So far I've...
-
OK: in rev 1385, I've tried completely removing the redefinition of rig_model_t from DialogUtil.h, and it compiles both with and without hamlib. Whatever purpose the typedef served, I don't think it's needed any more. Re my earlier post: it turns out that it's ok (in C++) to multiply define a type using typedef, as long as the types agree.
-
Remove spurious typedef that clashes with newer hamlib libraries. (Needs to be checked that it works)
-
Thanks for the update. I think that's progress. The "double free or corruption" is probably a new problem that I introduced with the Composite Sound Input. It's possibly wrong for all SDRs, but for some reason we get away with it with the RSP1A. I'll have another look. Are you running in the debugger or from the command line? Good news about the tuning phenomenon. I guess that must have been down to a Dream.ini setting. There's no AGC implemented in Dream itself - it relies on the SDR module to provide...
-
Hi. Rev 1384 has more of your fixes in: specifically the ones for GPS. I realised that my problem was that I don't have libgps, so it was the fallback definitions that needed to change to match. These changes are in your git repo but weren't in the changes that had been applied to my branch. I'm trying to understand the Hamlib issue. For some reason, rig_model_t was defined in DialogUtil.h. It feels like either this could be propagated from the hamlib headers (so it changes if they change), or should...
-
GPS fixes re-applied. It turns out that I didn't have libgps on my system and the problem was in the dummy definitions.
-
You might also like to try rev 1383, which should allow selection between SoapySDR inputs and sound inputs.
-
You might also like to try rev 1383, which should allow selection between SoapySDR inputs and sound inputs.
-
Added "composite" sound in interface, so that both Soapy SDR and audio inputs will be shown in the input device menu.
-
Hello all. I've just committed Rev 1382, which can handle switching between different SoapySDR devices. I've only been able to test it with SDRPlay RSP1As. I'd be interested to hear whether it works for others!
-
Hmm. I can't reproduce what you're seeing. Can you double-check that all the relevant settings in Dream.ini (i.e. not just the ones in the post) are the same as in the file I attached above? In other news, I committed rev 1382, which should allow switching between different SDR units. I've tested it with two RSP1As and it seems ok.
-
Moved code related to closing and reopening the device into the init function to avoid threading issues.
-
I just realised that I haven't mentioned the sampling rate. The RSP1A only goes down to 96kHz so I've added a 2:1 downsampling option to convert to 48kHz. I've attached my Dream.ini file in case there are other settings you need, but the relevant lines are: sampleratesig=96000 sigdownratio=2 sigupratio=1 I'm guessing you must have worked this out for yourself if you're able to decode DRM signals, but your description of the tuning behaviour made me think of this.
-
Adding the audio input at the same time as the SoapySDR inputs is on my list and shouldn't be too difficult now. For the hamlib changes, my understanding is that those changes break the build if you have a different version of hamlib, as Julian mentions on the thread you linked. So ideally we need something a bit cleverer - I'll try to find out what Julian had in mind for that. I've done some experiments with two RSP1As connected and trying to switch between them. It looks like a thread safety issue:...
-
Hi. Thanks for your comments and observations. The 12kHz offset is just what you say: it adds the offset to the requested frequency before tuning the SDR. So if you use tunerfreqoffset=-12 and then select I/Q Pos for the input, then choosing stations from the Stations dialog should work. I thought this might be better (for some SDRs) than tuning to the centre frequency and using "I/Q pos zero" mode because it avoids problems around DC, but you might find differently for your front-end. For the RSP1A...
-
OK I've added some more of the changes from your git repo, and committed them (basically untested). I haven't touched the GPS or Hamlib stuff this time. I hope to look at that next week. I'd prefer to use git too, but we'd want to co-ordinate any switchover with other developers.
-
Apply some of the fixes (including for PortAudio) provided by Christopher Andrews.
-
It's best to post here so that everyone can see the discussion. There's at least one other person playing with the dream-ollie branch.
-
Hi. Thanks for trying my branch and for your contributions! I've had a look at your commit and definitely need to incorporate some of the changes. The GPS-related stuff is different for different library versions - @jcable was going to have a look at that but I know he's very busy. I've already changed the #include for tuner.h; I don't know how my build environment was finding it but I guess it's something to do with the include path. I note that you changed a line to include "linux/sound.h". I've...
-
Fixed path for tuner.h (not sure how it was working before)
-
I just committed rev 1379 which fixes this compile error. In fact it's sufficient to delete the offending #include line which isn't needed any more. You might find this easier than doing an update as you have to do the other changes. My commit also adds a frequency offset parameter so that the SDR can be tuned e.g. 12kHz below the wanted centre frequency and operated in "I/Q pos" mode to avoid any LO breakthrough issues.
-
Removed superfluous #includes from DrmReceiver.cpp
-
Thanks for pointing this out. It's definitely my bad: the idea is that sound.h isn't used any more, but it looks like I haven't fully disentangled it. I'll look at it tomorrow. Ollie.
-
Replaced preprocessor+typedef-driven sound/sound.h with a factory returning base class pointer.
-
SoapySDRPlay now uses the sampling rate from the ini file / settings.
-
Added fmjd tag to RSCI output.
-
If RSCI output configured, plough on even if connection failed so that it will connect later if the server becomes available.
-
Make sure FreqSyncAcq only returns true once per frame for unlocked frame boundary.
-
Thanks for the updates Steve and pleased to hear you've had partial success at least! The gain settings are something I've been playing with. The SDRPlay implementation for SoapySDR doesn't quite conform to the API contract, in particular in that the "gains" it reports are actually gain reductions so operate in the opposite sense. There's discussion here, and you can see that I've been trying out one of the options in Franco's branch. I guess you're using the master branch of SoapySDRPlay. Either...
-
Hi I looked at this and I can see what the problem is. Currently the SoapySDR input only works if you use PulseAudio, whilst your build appears to be using ALSA. In fact if it's configured for PulseAudio, it uses Soapy as the input instead of the PulseAudio input: that's the "horrible kludge" that I referred to! I'd like to fix this all properly, but if you could use PulseAudio instead of ALSA that would make things easier in the meantime. Julian knows a lot more about the build system than I do,...
-
Hi all! Thanks for your interest in my branch. I am indeed in the process of adding native SoapySDR support to Dream, but it's work in progress and certain things are hard-coded for the particular setup I have (Raspberry Pi OS, RSP1A) , and there's a horrible kludge in the way Soapy is selected as a SoundIn device. I hope to improve this whole area soon but I have a few other things to do first. I'm pleased that this work appears to be of interest to others and will endeavour to keep you posted on...
-
Load and save settings for SoapySDR
-
Temporary fix for SDRPlay gain (should be put back if SDRPlay wrapper for SoapySDR are fixed)
-
As you've seen, I've been doing some work on Dream. We're interested in having full xHE-AAC support and I'd be willing to help if I can with any debugging.
-
Hi all! I'm afraid I'm partly responsible for both "aqua" and "theseus". They're both DRM- related but not strictly part of Dream. Arguably they shouldn't be in this project, but we wanted to contribute them to the open-source community and the overhead of making a separate project for each seemed excessive. Aqua is a method of measuring receiver performance for receivers that don't support BER measurement using a PRBS, while Theseus is a web-based monitoring system for DRM (with some support for...
-
Reconnect on TCP failure
-
Added SoapySDR as a sound input.
-
Changes to work with the GPS version on my system.
-
Solomon, The channel models are defined in the DVB-T2 Implementation Guidelines (TS 102 831 clause 14.1. However, the Rayleigh (P1) and Rice (F1) channels originally came from the Annex B of the DVB-T specification EN 300 744. Ro, Tau and Phi are the relative amplitude, delay and phase values for each path and represent the corresponding Greek symbols in the two ETSI documents, except that Phi in the CSP actually corresponds to θ (theta) in the documents. Fd is the Doppler frequency and is zero for...
-
The datagen block automatically works out how many bytes it needs to generate based on how many Interleaving Frames are being generated. See the "anatomy" section of the DVB-T2 Implementation Guidelines for an explanation of Interleaving Frames, which are only loosely related to the Time Interleaver. To generate more data you probably want to increase the number of Interleaving Frames. However, note that if you are doing this in order to do BER simulations, you might want to look at some of the other...
-
That's the correct parameter to use: just set ROTCON_BYPASS = 1 for the relevant PLP using the overriding mechanism in the "run" command. (If this doesn't mean anything to you, please read the BBC R&D White Paper 196 and consult the"Getting Started" document for examples).
-
Yes, this is a basic function that's definitely needed.
-
Yes, in principle you can change the target, but beware that at a BER of 10^-7, the simulations will take much longer. This is because you need to run the simulation for long enough to get a statistically significant number of errors. The simulator also requires a minimum number of errored LDPC blocks because error events tend to come in bursts, and you need to see enough of these bursts for an accurate result (see clause 14.2 of the DVB-T2 Implementation Guidelines TR 102 831). Unless you are able...
-
Usual first question: have you read the BBC White Paper 196? The best way to add an extra processing stage is to add it as a new module to the processing chain. The White Paper describes how the signals are passed from one module to the next and should allow you to work out how to do this. The 518400 cells are a whole number of LDPC FEC blocks. When these are mapped to the OFDM symbols there are left over OFDM cells which are filled with dummy cells. In addition, not all 8192 carriers are used in...
-
I'll assume here that you've read the BBC R&D White paper WHP196. The best way to incorporate this would be to make your processing into a proper submodule which can be called in the process of the normal simulation. Since you don't want to use TR, you could make your module an alternative "concrete implementation" of the t2_tx_paprtr module: just make your own t2_tx_dvbt2XXpaprTR.m (replace XX with something to identify your algorithm) and modify t2_tx_paprtr_wr to add your function as an option....
-
Thanks for the references. I think you might find that the CSP is too closely linked to the DVB-T2 standard and that substituting different codes might indeed be difficult. For example, there's the concept of BBFRAMEs which map directly onto LDPC codewords. If your alternative LDPC code has a different block size, it might not be straightforward to use it. On the other hand, the CSP includes things like signalling, interleaving and pilots which are needed in real life and might interfere with the...
-
There's some discussion of PAPR simulation here. I'm not aware that anyone involved in that discussion has contributed their CCDF measurement code to the project. You are of course welcome to add such code and contribute it back to the project. I don't know anything about QC-LDPC or any of the other types of code that you mention. It may be that these are supported in MATLAB or that code for them is available from other MATLAB users. There isn't a great deal of activity on this forum, and for anything...
-
There's some discussion of PAPR simulation here. I'm not aware that anyone involved in that discussion has contributed their CCDF measurement code to the project. You are of course welcome to add such code and contribute it back to the project. I don't know anything about QC-LDPC or any of the other types of code that you mention. It may be that these are supported in MATLAB or that code for them is available from other MATLAB users. From a quick Google search I haven't found any mention of QC-LDPC...
-
Hi, The important message is this one: Error using t2_tx_dvbt2blfbuild (line 164) t2_tx_dvbt2blfbuild: PLP data exceeds capacity of T2 frame Tone Reservation uses particular OFDM cells (i.e. particular carriers in each symbol) to adjust the output waveform in order to reduce the peak-to-mean ratio. These carriers cannot be used to carry data, which means that, when you enable TR, the capacity of the T2 frame is reduced. However, the amount of data being carried doesn't automatically change, because...
-
Version 3.2.4 released
-
Upped version number ready for release
-
Hi. This (and a problem with the LDPC encoder/decoder) has been fixed in the latest version in the SVN repository. See this thread. As I mentioned there, I really ought to issue a new release. In the meantime, I suggest you check out the "Head" revision of the repository. Let us know if you find any more problems in 2017a.
-
Hi. This has been fixed in the latest version in the SVN repository. See this thread. As I mentioned there, I really ought to issue a new release. In the meantime, I suggest you check out the "Head" revision of the repository.
-
I'm sorry, I didn't do these simulations so I can only be of limited help. As the editor of the TS 102 831 I did get to see some discussion of the methodology. One point that came up was that the output of the TR algorithm was upsampled by a factor of 4 before measuring the PAPR: "IFFT -> TR algorithm -> GI insertion -> upsample-by-4 -> Measure PAPR". This is very important, since peaks "grow back" when the signal is converted to analogue and the upsampling models this phenomenon. Another thing that...
-
Sorry that I wasn't able to get back to you sooner. As I mentioned above, some errors were noticed in the plots, and unfortunately the updated versions haven't yet been included in TS 102 831. I have attached the corrected version of Figure 88 - is this closer to your results?
-
UPDATE: I found a couple of other problems and have made further changes to the random...
-
Changed random number seeding to match recommen...
-
Avoids error about legacy random number generat...
-
I've now committed code to the repository that replaces the old ldpc encoder/decoder...
-
Thanks for posting. I recently came across this problem myself and have worked out...
-
Replaced LDPC functions (were removed in latest...
1 >
