I have a question on discretizing the channel specification.
In channel.cpp
00773 no_taps = j+1; // number of taps found
00774 if (no_taps != N_taps) {
00775 for (int i = 0; i < N_taps; i++) {
00776 it_assert(tap_doppler_spectrum(i) == Jakes,
00777 "Channel_Specification::discretize(): Too low sampling frequecy. The discretised PDP does not match the Doppler Spectrum profile.");
00778 }
00779 power.set_size(no_taps, true);
00780 delay_prof.set_size(no_taps, true);
00781 tap_doppler_spectrum.set_size(no_taps, true);
00782 N_taps = no_taps;
00783 }
00784
This seems to mean that all the taps have to be Jakes if no_taps != N_taps. Why this is necessary? Especially it does not take the sampling frequency into account, it seems to me.
To see this is a problem, I have tried the example code you provided at
It seems that you have found a bug or at least an inconsistency in the IT++ channel modelling. :-)
The problem here is that the delay profile of COST259_RAx is given in 1ns (1e-9s) resolution. This means, that the discretization of this channel with a sampling frequency lower than 1e9 Hz will result in some shifts of the channel taps. And in an extreme case, when sampling frequency is much lower, some of the neighbouring taps will be merged into a new tap. This is detected in this if statement in line 744.
Since, some of the channel models can use various spectra on various taps, e.g. Jakes, Gauss I, Gauss II, they can not be merged into a new tap. Therefore, this artificial check: it_assert(tap_doppler_spectrum(i) == Jakes) was added recently. However, in the case of COST259_RAx, the only different spectrum is on the zeroth tap (Rice), and it should not throw this exception.
I guess this problem does not exist any more in the development version of the IT++ library (from the SVN trunk), since the channel classes were recently redesigned and updated...
I will look into this problem and try to prepare a workaround in the stable branch.
For the time being, you can comment this assertion, if you need to simulate this particular case.
BR,
/ediap
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for so prompt response. I guess it wouldn't be so confusing if it warns agains merging taps of different spectra.
Another thought, it can be a problem if simply comment this out. Since in RA channel, if the sampling time is larger than the tap spacing, the taps power accumulated into the 0-tap will raise the effective K factor?
Lookingforward to your next release with redesigned channel model.
Best regards,
Oriver
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The fix for this issue has been committed to the IT++ SVN repository (revision 790). It will be included in the next stable release 3.10.8. In the meantime, you can obtain the patch from the repository.
Thanks for your well-described report of this problem!
BR,
/ediap
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I have a question on discretizing the channel specification.
In channel.cpp
00773 no_taps = j+1; // number of taps found
00774 if (no_taps != N_taps) {
00775 for (int i = 0; i < N_taps; i++) {
00776 it_assert(tap_doppler_spectrum(i) == Jakes,
00777 "Channel_Specification::discretize(): Too low sampling frequecy. The discretised PDP does not match the Doppler Spectrum profile.");
00778 }
00779 power.set_size(no_taps, true);
00780 delay_prof.set_size(no_taps, true);
00781 tap_doppler_spectrum.set_size(no_taps, true);
00782 N_taps = no_taps;
00783 }
00784
This seems to mean that all the taps have to be Jakes if no_taps != N_taps. Why this is necessary? Especially it does not take the sampling frequency into account, it seems to me.
To see this is a problem, I have tried the example code you provided at
http://itpp.sourceforge.net/stable/classitpp_1_1TDL__Channel.html
Which gives exactly the error message here on line 00777. Would you kindly explain?
Regards,
Oriver
Hi Oliver,
It seems that you have found a bug or at least an inconsistency in the IT++ channel modelling. :-)
The problem here is that the delay profile of COST259_RAx is given in 1ns (1e-9s) resolution. This means, that the discretization of this channel with a sampling frequency lower than 1e9 Hz will result in some shifts of the channel taps. And in an extreme case, when sampling frequency is much lower, some of the neighbouring taps will be merged into a new tap. This is detected in this if statement in line 744.
Since, some of the channel models can use various spectra on various taps, e.g. Jakes, Gauss I, Gauss II, they can not be merged into a new tap. Therefore, this artificial check: it_assert(tap_doppler_spectrum(i) == Jakes) was added recently. However, in the case of COST259_RAx, the only different spectrum is on the zeroth tap (Rice), and it should not throw this exception.
I guess this problem does not exist any more in the development version of the IT++ library (from the SVN trunk), since the channel classes were recently redesigned and updated...
I will look into this problem and try to prepare a workaround in the stable branch.
For the time being, you can comment this assertion, if you need to simulate this particular case.
BR,
/ediap
Thanks for so prompt response. I guess it wouldn't be so confusing if it warns agains merging taps of different spectra.
Another thought, it can be a problem if simply comment this out. Since in RA channel, if the sampling time is larger than the tap spacing, the taps power accumulated into the 0-tap will raise the effective K factor?
Lookingforward to your next release with redesigned channel model.
Best regards,
Oriver
The fix for this issue has been committed to the IT++ SVN repository (revision 790). It will be included in the next stable release 3.10.8. In the meantime, you can obtain the patch from the repository.
Thanks for your well-described report of this problem!
BR,
/ediap