> > - Show quoted text -
>
> Question...
>
> isn't this the purpose of the metric �Eb/No?
>
> If the OP compares the Eb/No �of the two codes, the answer will be
> clear.
>
> The code with the lower Eb/No for a given BER will require less RF
> power to transmit information at a given rate. � Is that not true?
>
> - Show quoted text -
Exactly! It seems like power is the main issue in your system, not the
bandwidth. Therefore, you need to find a code that provides
significantly better performance to result in power savings (as
opposed to bandwidth). The RF guy is correct, why change the design
and take additional risk/cost unless there is anything to gain in
power? You need to consider other LDPC codes or perhaps rate 1/2 Turbo
codes with the goal of better performance at a lower Eb/N0.
Reply by Jacko●April 30, 20092009-04-30
On Apr 30, 11:54�am, Rune Allnor <all...@tele.ntnu.no> wrote:
> On 30 Apr, 02:04, Eric Jacobsen <eric.jacob...@ieee.org> wrote:
>
>
>
> > On Wed, 29 Apr 2009 03:17:36 -0700 (PDT), Rune Allnor
>
> > <all...@tele.ntnu.no> wrote:
> > >On 28 Apr, 19:21, Eric Jacobsen <eric.jacob...@ieee.org> wrote:
>
> > >> >> > I want to increase the effective bitrate and improve BER by switching
> > >> >> > to 7/8 LDPC, but wasn't successfull to persuade the RF Guy (he is also
> > >> >> > the Project Manager).
>
> > >> FWIW, if it were me I'd insist on something rigorous like a link
> > >> budget analysis comparison before reaching a conclusion.
>
> > >Eric, you or I might *insist* on such stuff, but I don't think
> > >that's an approach for everyone.
>
> > My suggestion was really that the OP do the link budget analysis and
> > use it as a tool to convince the RF guy, since they generally
> > understand such things.
>
> The absence of basic engineering craftsmanship is one of the main
> reasons why projects fail. Showing a novice, or somebody from a
> different field how to do things, is good.
>
> At the proper time in the proper context.
>
> > And, yeah, I agree that these days it seems like most people don't
> > take that approach. � Often with predictably bad results. �;)
>
> Huh? I am sure I have misunderstood something, but messing
> with the ways projects are managed will bring no good, unless
> one happens to be the project manager or an external consultant.
> Or a pathologic troublemaker.
>
> I have done that sort of thing on several occasions in the
> past (in projects where I otherwise would be headed for
> charges of gross professional misconduct, fraud, manslaughter
> and even treason), and the only outcome was that project
> management thought I claimed they were incompetent. Which
> was not my intention at the time, but not quite off the mark.
>
> Rune
Yeah money is god, skill is subcontracted by money to keep the
protection racket at bay for the skilled for a little while.
cheers jacko
Reply by Rune Allnor●April 30, 20092009-04-30
On 30 Apr, 02:04, Eric Jacobsen <eric.jacob...@ieee.org> wrote:
> On Wed, 29 Apr 2009 03:17:36 -0700 (PDT), Rune Allnor
>
> <all...@tele.ntnu.no> wrote:
> >On 28 Apr, 19:21, Eric Jacobsen <eric.jacob...@ieee.org> wrote:
>
> >> >> > I want to increase the effective bitrate and improve BER by switching
> >> >> > to 7/8 LDPC, but wasn't successfull to persuade the RF Guy (he is also
> >> >> > the Project Manager).
>
> >> FWIW, if it were me I'd insist on something rigorous like a link
> >> budget analysis comparison before reaching a conclusion.
>
> >Eric, you or I might *insist* on such stuff, but I don't think
> >that's an approach for everyone.
>
> My suggestion was really that the OP do the link budget analysis and
> use it as a tool to convince the RF guy, since they generally
> understand such things.
The absence of basic engineering craftsmanship is one of the main
reasons why projects fail. Showing a novice, or somebody from a
different field how to do things, is good.
At the proper time in the proper context.
> And, yeah, I agree that these days it seems like most people don't
> take that approach. � Often with predictably bad results. �;)
Huh? I am sure I have misunderstood something, but messing
with the ways projects are managed will bring no good, unless
one happens to be the project manager or an external consultant.
Or a pathologic troublemaker.
I have done that sort of thing on several occasions in the
past (in projects where I otherwise would be headed for
charges of gross professional misconduct, fraud, manslaughter
and even treason), and the only outcome was that project
management thought I claimed they were incompetent. Which
was not my intention at the time, but not quite off the mark.
Rune
Reply by Eric Jacobsen●April 30, 20092009-04-30
On Wed, 29 Apr 2009 06:29:41 -0700 (PDT), makolber@yahoo.com wrote:
>On Apr 28, 9:57�pm, Eric Jacobsen <eric.jacob...@ieee.org> wrote:
>> On Tue, 28 Apr 2009 10:25:38 -0700 (PDT), cincy...@gmail.com wrote:
>> >On Apr 28, 1:21�pm, Eric Jacobsen <eric.jacob...@ieee.org> wrote:
>>
>> >> You might also consider that an LDPC encoder takes a lot more power to
>> >> run than a Convolutional Encoder, which is trivial. � If you want
>> >> something that provides more gain but perhaps not as much power
>> >> consumption in the modulator as an LDPC, you may want to look at Turbo
>> >> Codes. � In that case there's just two trivial convolutional encoders
>> >> and an interleaver, which might be lower power consumption than an
>> >> LDPC encoder.
>>
>> >Eric,
>>
>> >Is this necessarily true? I'd say that there are some LDPC codes with
>> >relatively low complexity (regular repeat-accumulate codes come to
>> >mind). In that case, yes, it's slightly more complex than a
>> >convolutional encoder, but not too much more so. Wouldn't the main
>> >driver for encoder complexity (I'm thinking of an FPGA implementation
>> >here) be the block size, which drives interleaver design and such? In
>> >that case, turbo codes would be approximately on the same footing as
>> >an LDPC code.
>>
>> >Or I might be showing my ignorance.
>>
>> >Jason
>>
>> It's generally tough to find a practical code with decent coding gain
>> that has a simpler encoder than a convolutional code. � So if that's
>> the reference point, and the data rate is really 100Mbps, then I think
>> one needs to consider the effect of changing the code on power
>> consumption. � �It may or may not be an issue, but for a battery
>> operated transmitter that's the sort of stuff one may need to consider
>> if the rest of the design is efficient. � If the rest of the design is
>> wasteful (or it's just doing a lot of stuff on battery power) then the
>> incremental power consumption due to the encoder change may not even
>> show up on the radar.
>>
>> And there are some pretty decent LDPC encoders complexity-wise, but
>> it's pretty dependent on the code structure, so it's hard to make
>> assumptions.
>>
>> Eric Jacobsen
>> Minister of Algorithms
>> Abineau Communicationshttp://www.ericjacobsen.org
>>
>> Blog:http://www.dsprelated.com/blogs-1/hf/Eric_Jacobsen.php- Hide quoted text -
>>
>> - Show quoted text -
>
>Question...
>
>isn't this the purpose of the metric Eb/No?
>
>If the OP compares the Eb/No of the two codes, the answer will be
>clear.
>
>The code with the lower Eb/No for a given BER will require less RF
>power to transmit information at a given rate. Is that not true?
>
>Mark
>On 28 Apr, 19:21, Eric Jacobsen <eric.jacob...@ieee.org> wrote:
>
>> >> > I want to increase the effective bitrate and improve BER by switching
>> >> > to 7/8 LDPC, but wasn't successfull to persuade the RF Guy (he is also
>> >> > the Project Manager).
>
>> FWIW, if it were me I'd insist on something rigorous like a link
>> budget analysis comparison before reaching a conclusion.
>
>Eric, you or I might *insist* on such stuff, but I don't think
>that's an approach for everyone.
My suggestion was really that the OP do the link budget analysis and
use it as a tool to convince the RF guy, since they generally
understand such things.
And, yeah, I agree that these days it seems like most people don't
take that approach. Often with predictably bad results. ;)
Eric Jacobsen
Minister of Algorithms
Abineau Communications
http://www.ericjacobsen.org
Blog: http://www.dsprelated.com/blogs-1/hf/Eric_Jacobsen.php
Reply by ●April 29, 20092009-04-29
On Apr 28, 9:57�pm, Eric Jacobsen <eric.jacob...@ieee.org> wrote:
> On Tue, 28 Apr 2009 10:25:38 -0700 (PDT), cincy...@gmail.com wrote:
> >On Apr 28, 1:21�pm, Eric Jacobsen <eric.jacob...@ieee.org> wrote:
>
> >> You might also consider that an LDPC encoder takes a lot more power to
> >> run than a Convolutional Encoder, which is trivial. � If you want
> >> something that provides more gain but perhaps not as much power
> >> consumption in the modulator as an LDPC, you may want to look at Turbo
> >> Codes. � In that case there's just two trivial convolutional encoders
> >> and an interleaver, which might be lower power consumption than an
> >> LDPC encoder.
>
> >Eric,
>
> >Is this necessarily true? I'd say that there are some LDPC codes with
> >relatively low complexity (regular repeat-accumulate codes come to
> >mind). In that case, yes, it's slightly more complex than a
> >convolutional encoder, but not too much more so. Wouldn't the main
> >driver for encoder complexity (I'm thinking of an FPGA implementation
> >here) be the block size, which drives interleaver design and such? In
> >that case, turbo codes would be approximately on the same footing as
> >an LDPC code.
>
> >Or I might be showing my ignorance.
>
> >Jason
>
> It's generally tough to find a practical code with decent coding gain
> that has a simpler encoder than a convolutional code. � So if that's
> the reference point, and the data rate is really 100Mbps, then I think
> one needs to consider the effect of changing the code on power
> consumption. � �It may or may not be an issue, but for a battery
> operated transmitter that's the sort of stuff one may need to consider
> if the rest of the design is efficient. � If the rest of the design is
> wasteful (or it's just doing a lot of stuff on battery power) then the
> incremental power consumption due to the encoder change may not even
> show up on the radar.
>
> And there are some pretty decent LDPC encoders complexity-wise, but
> it's pretty dependent on the code structure, so it's hard to make
> assumptions.
>
> Eric Jacobsen
> Minister of Algorithms
> Abineau Communicationshttp://www.ericjacobsen.org
>
> Blog:http://www.dsprelated.com/blogs-1/hf/Eric_Jacobsen.php- Hide quoted text -
>
> - Show quoted text -
Question...
isn't this the purpose of the metric Eb/No?
If the OP compares the Eb/No of the two codes, the answer will be
clear.
The code with the lower Eb/No for a given BER will require less RF
power to transmit information at a given rate. Is that not true?
Mark
Reply by Rune Allnor●April 29, 20092009-04-29
On 28 Apr, 19:21, Eric Jacobsen <eric.jacob...@ieee.org> wrote:
> >> > I want to increase the effective bitrate and improve BER by switching
> >> > to 7/8 LDPC, but wasn't successfull to persuade the RF Guy (he is also
> >> > the Project Manager).
> FWIW, if it were me I'd insist on something rigorous like a link
> budget analysis comparison before reaching a conclusion.
Eric, you or I might *insist* on such stuff, but I don't think
that's an approach for everyone.
To the OP: Instead of insisting, *suggest*. Do the homework
as far as you can, do the numbers, set up the pros and cons
with respect to all the options. But expect to be turned down.
And do all this *before* decisions have been made and designs
have been fixed. You might not agree with things as they are
done, but unless you are the project manager, it is not your
job to decide how to do tings. If the design you are assigned
to implement can work at all, then it is your job to implement
that design. Period.
Instead of 'rocking the boat', use this experience as a learning
experience. You might learn something about the device or the
application (who knows, maybe the RF guy knows something you
don't?), about human psychology and when and how (not) to influence
people, or if you turn out to be right, then you have a backdrop
for the day when *you* are the project manager and can make
these kinds of decisions.
The only reason you have for making a mess in your project, is
if the design obviously can not perform at all. And even then,
you might want to leave quietly instead of making noises.
So just be cautious. Unless there literally are human lives at
stake [*], be quiet. But watch and learn. Both from the good
stuff and from the bad stuff.
Rune
[*] You might want to include your own reputation and carreer
(but not anybody else's!) among those humean lives.
If you think the project you work on is wasted, take the
consequences and *leave* the project. Do *not* make a fuzz,
as that would affect your abilities to find similar jobs
in the future.
Reply by Eric Jacobsen●April 28, 20092009-04-28
On Tue, 28 Apr 2009 10:25:38 -0700 (PDT), cincydsp@gmail.com wrote:
>On Apr 28, 1:21�pm, Eric Jacobsen <eric.jacob...@ieee.org> wrote:
>
>> You might also consider that an LDPC encoder takes a lot more power to
>> run than a Convolutional Encoder, which is trivial. � If you want
>> something that provides more gain but perhaps not as much power
>> consumption in the modulator as an LDPC, you may want to look at Turbo
>> Codes. � In that case there's just two trivial convolutional encoders
>> and an interleaver, which might be lower power consumption than an
>> LDPC encoder.
>
>Eric,
>
>Is this necessarily true? I'd say that there are some LDPC codes with
>relatively low complexity (regular repeat-accumulate codes come to
>mind). In that case, yes, it's slightly more complex than a
>convolutional encoder, but not too much more so. Wouldn't the main
>driver for encoder complexity (I'm thinking of an FPGA implementation
>here) be the block size, which drives interleaver design and such? In
>that case, turbo codes would be approximately on the same footing as
>an LDPC code.
>
>Or I might be showing my ignorance.
>
>Jason
It's generally tough to find a practical code with decent coding gain
that has a simpler encoder than a convolutional code. So if that's
the reference point, and the data rate is really 100Mbps, then I think
one needs to consider the effect of changing the code on power
consumption. It may or may not be an issue, but for a battery
operated transmitter that's the sort of stuff one may need to consider
if the rest of the design is efficient. If the rest of the design is
wasteful (or it's just doing a lot of stuff on battery power) then the
incremental power consumption due to the encoder change may not even
show up on the radar.
And there are some pretty decent LDPC encoders complexity-wise, but
it's pretty dependent on the code structure, so it's hard to make
assumptions.
Eric Jacobsen
Minister of Algorithms
Abineau Communications
http://www.ericjacobsen.org
Blog: http://www.dsprelated.com/blogs-1/hf/Eric_Jacobsen.php
Reply by Jacko●April 28, 20092009-04-28
Well getting a lower bandwidth may reduce power total if power
consumption of algorithm is small compared to the RF power. Also
switched mode RF is essential for efficient transmission (Class C or
D). ...
Maybe the following entropy reduction codec is of use in your
designs..
-- (C)2008 K Ring Technologies Semiconductor
-- BSD http://nibz.googlecode.com (no support)
-- Comercial licencing available
-- Tel: +44 796 797 3001 (a real space odessy)
-- Maintained by Simon Jackson, BEng.
-- E-mail: jackokring@gmail.com
-- Hardware support kodek for nibz
library ieee;
-- library altera;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
entity k is
port (
do : buffer std_Logic;
di : in std_logic;
busy : buffer std_logic;
comde : std_logic;
clk : in std_logic;
-- a rising edge signal (run)
run : in std_logic;
-- for setting the prbs
-- may be of use as a general prbs ...
load : in std_logic_vector(15 downto 0);
save : buffer std_logic_vector(15 downto 0);
rw : in std_logic;
sel : in std_logic
);
end entity;
architecture rtl of k is
signal asymproc : std_logic;
signal which : std_logic;
type s is (action,motion);
signal state : s;
-- intermediates
signal wind : std_logic_vector(4 downto 0);
signal procp : std_logic_vector(1 downto 0);
signal tapx : std_logic;
signal ends : std_logic;
-- process control flags
signal procdo : std_logic;
signal winddo : std_logic;
signal modo : std_logic;
signal runlast : std_logic;
constant tap : natural := 3;
signal pmux : std_logic_vector(15 downto 0);
begin
process(clk)
-- prbs
begin
end process;
procp <= pmux(1 downto 0);
procdo <= procp(1) and procp(0);
-- set motion velocities via probability switching
modo <= procdo xor which xor do xor '1';
-- set sampling window
wind <= pmux(7 downto 3);
winddo <= wind(4) and wind(3) and wind(2) and
wind(1) and wind(0);
process(clk)
-- k state machine
begin
if(rising_edge(clk)) then
runlast <= run;
end if;
if(rising_edge(clk) and busy = '1') then
case state is
when motion =>
asymproc <= asymproc xor modo;
state <= action;
when action =>
if(asymproc = '0') then
if(which = '0') then
-- sample
if(winddo = '1') then
busy <= '0';
-- sample do
end if;
else
-- random
do <= do xor procp(0);
end if;
else
which <= which xor procdo;
end if;
state <= motion;
end case;
-- NB. if 2nd rising edge run before busy zero
-- then ignored
elsif(rising_edge(clk) and runlast = '0' and run = '1') then
-- set busy, cleared by kodek finish bit
busy <= '1';
do <= di;
end if;
-- prbs
if(comde = '1') then
ends <= save(15);
else
ends <= save(0);
end if;
tapx <= save(tap) xor ends;
if(rising_edge(clk) and busy = '1') then
if(comde = '1') then
save <= save(14 downto 0)&tapx;
else
save <= tapx&save(15 downto 1);
end if;
end if;
if(comde = '1') then
pmux <= save;
else
pmux <= tapx&save(15 downto 1);
end if;
-- load
if(rising_edge(clk) and sel = '1' and rw = '0') then
-- NB. a load while busy can be a random number gen
-- but not much use in general operation
-- do a kind of reset
asymproc <= '0'; -- rand/samp side
which <= '0'; -- samp side
state <= motion; -- perform motion methods first
-- (begin and end on them)
-- assign essentials
save <= load;
end if;
end process;
end rtl;
Reply by Tim Wescott●April 28, 20092009-04-28
Eric Jacobsen wrote:
> On Tue, 28 Apr 2009 02:57:13 -0700 (PDT), recoder
> <kurtulmehtap@gmail.com> wrote:
>
>> On 28 Nisan, 12:38, John <sampson...@gmail.com> wrote:
>>> On Apr 28, 5:20 am, recoder <kurtulmeh...@gmail.com> wrote:
>>>
>>>> Dear All,
>>>> We have a Solar Power operated X Band qpsk transmitter in a remote
>>>> region.
>>>> The FEC used is 1/2 rate viterbi, the output bitrate is 100 Mbps.
>>>> I want to increase the effective bitrate and improve BER by switching
>>>> to 7/8 LDPC, but wasn't successfull to persuade the RF Guy (he is also
>>>> the Project Manager).
>>>> Since the device is Solar powered, the power consumption of the X
>>>> Band transmitter is critical. The RF Guy argued that there will be no
>>>> change in power consumption. I think he is too lazy to do the RF
>>>> design changes.
>>>> I am not sure but as the Bandwidth reduces to nearly the half, should
>>>> also the Microwave Transmitters power consumption drop???
>>>> Please give an argument to convince the lazy RF guy, please please
>>>> pleaaaase...
>>> If the coding gain is increased by X dB, the transmit power can be
>>> decreased by X dB.
>>>
>>> John
>> The coding gain has not changed much, but the Bandwidth nearly halved.
>> Assuming the output rf power is the same, will there be a drop in
>> power consumption?
>> Is there not a relationship with the RF Bandwidth to input power in a
>> microwave amplifier?
>
> I'd think a good way to do the analysis that'd make sense to an RF guy
> is to do a full link budget analysis for both cases. The bandwidth
> reduction will provide some power concentration and the change in
> coding will also affect margin. The net affect is hard to say
> without knowing the specifics of the code performance. As has been
> mentioned, any net gain in link margin can be traded as a transmit
> power reduction.
>
> You might also consider that an LDPC encoder takes a lot more power to
> run than a Convolutional Encoder, which is trivial. If you want
> something that provides more gain but perhaps not as much power
> consumption in the modulator as an LDPC, you may want to look at Turbo
> Codes. In that case there's just two trivial convolutional encoders
> and an interleaver, which might be lower power consumption than an
> LDPC encoder.
>
> FWIW, if it were me I'd insist on something rigorous like a link
> budget analysis comparison before reaching a conclusion.
Agreed. I would go farther, and do a link budget analysis _and_ a power
consumption analysis for each (i.e. the LDPC encoder may use more power,
but if it's still less than the RF power saved, then it's better). From
a technical standpoint you either want the highest throughput for a
given power, or the lowest power for a given throughput -- all else is gas.
BUT: You should also be sensitive to schedule and cost -- if everything
that's proposed is low risk and known, and if the power budget is good
enough, and if the schedule and/or budget is tight, then the right
project decision may be to run with the current solution, even if it's
not the World's Best in a technical sense.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html