AVR-Chat

Hi,

Sorry - a little off topic but...

I've got a Dell 1702FP LCD display, but unfortunately to not have the
power supply for it.

Standard power supply is a 14V @ 3A switch mode brick supply - similar
to most laptops etc.

I have a Toshiba laptop supply that is 15V @ 3A, and want to drop the
voltage down and use it for the LCD display. I measured this without
load at 15.2V

So, I placed a pair of 1N5404 diodes in series for a resultant drop of
around 1.4V (to be on the safe side).

The screen appears to run fine, but the diodes get rather toasty, and I
would ultimately like to be able to heatshrink them to hide them away
(they are about 50mm from the DC plug that goes into the monitor).

So, I thought about putting another pair in parallel to reduce the
current through each device with the hope of reducing the temperature. I
could place maybe 4 pairs in parallel if that will reduce the heat.

Am I on the right track? Is there a better way to approach this?

The power supply is sealed (glued), and I'm not sure what they are like
inside - whether they are potted in resin etc or whether they can be
adjusted a little?

Had anyone tried a similar thing?

I'm sure the diodes are ok at this running temp - just that I'm not
happy about how hot they are, and I'm not sure if I could heatshrink
them at current temps (with 2 parallel pairs each device is running at
surface temp of around 70C. With only 1 pair in series they were 100C!)

Any help would be greatly appreciated.

Of course I could always buy a replacement psu, but I can't find one
here in Australia at a reasonable price, and the ones on eBay USA are
about US$19 + the same again for shipping.

Many thanks in advance
Dean

Can you open it up and look for a regulator?

Most power supplies only deliver a ballpark voltage.  The device then 
has a regulator to get it where it needs to be, probably 12V.  In 
which case you wouldn't have to drop the 15V at all.

Few devices expect a well-regulated input voltage.

Mike



--- In AVR-Chat@yahoogroups.com, "Claxton, Dean J" 
<dean.j.claxton@t...> wrote:
> Hi,
> 
> Sorry - a little off topic but...
> 
> I've got a Dell 1702FP LCD display, but unfortunately to not have 
the
> power supply for it.
> 
> Standard power supply is a 14V @ 3A switch mode brick supply - 
similar
> to most laptops etc.
> 
> I have a Toshiba laptop supply that is 15V @ 3A, and want to drop 
the
> voltage down and use it for the LCD display. I measured this without
> load at 15.2V
> 
> So, I placed a pair of 1N5404 diodes in series for a resultant drop 
of
> around 1.4V (to be on the safe side).
> 
> The screen appears to run fine, but the diodes get rather toasty, 
and I
> would ultimately like to be able to heatshrink them to hide them 
away
> (they are about 50mm from the DC plug that goes into the monitor).
> 
> So, I thought about putting another pair in parallel to reduce the
> current through each device with the hope of reducing the 
temperature. I
> could place maybe 4 pairs in parallel if that will reduce the heat.
> 
> Am I on the right track? Is there a better way to approach this?
> 
> The power supply is sealed (glued), and I'm not sure what they are 
like
> inside - whether they are potted in resin etc or whether they can be
> adjusted a little?
> 
> Had anyone tried a similar thing?
> 
> I'm sure the diodes are ok at this running temp - just that I'm not
> happy about how hot they are, and I'm not sure if I could heatshrink
> them at current temps (with 2 parallel pairs each device is running 
at
> surface temp of around 70C. With only 1 pair in series they were 
100C!)
> 
> Any help would be greatly appreciated.
> 
> Of course I could always buy a replacement psu, but I can't find one
> here in Australia at a reasonable price, and the ones on eBay USA 
are

> about US$19 + the same again for shipping.
> 
> Many thanks in advance
> Dean

--- In AVR-Chat@yahoogroups.com, "Claxton, Dean J" 
<dean.j.claxton@t...> wrote:

> ... I placed a pair of 1N5404
> diodes in series for ... drop
> of around 1.4V (to be on the
> safe side ... the diodes get
> rather toasty ...

This seems to be a reasonable solution to me, assuming you can't find 
an obvious way to turn down the voltage.

The problem with putting diodes in parallel is that they may not 
share the current particularly equally. You can get around that by 
just using more than are strictly necessary, say five instead of 
three.

Another approach would be to use a resistor and a diode in series 
instead of two diodes. Suppose, for example, the current really is 
three amps and you decide to put one amp through each of three 
diodes. If you measure the voltage and it is still high by, say, 0.3 
volts, then just put a 0.3 ohm resistor in series with each diode. 
This will drop the additional voltage and ensure you get even sharing 
of the current.

One thing to remember, though, is that when you heatshrink the whole 
lot together, there's the same amount of heat coming out of your 
bumdle whether you have two or six diodes in there. Things may run 
cooler while you have the diodes separated, but when you mash them 
together they could be almost as hot once again.

Graham.

Just when I am starting to make headway problems set in. 

I am using WINAVR 3.4.1 with AVRDude

I have a MAVRIC II board. 

I have a bsd parallel port programmer cable. I have verified the
continuity of the cable (the 1st thing I do when I have trouble) and it
is fine. I also was able to use this cable to connect in interactive
mode to another Mavric II board using the command below I get the
following error message. 


D:\Robot\Projects\MinGrand>d:\robot\winavr\bin\avrdude -p atmega128
-Plpt1 -c  bsd -t

avrdude: AVR device not responding
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.



This all started when I tried to program the problem board with an
updated program. It did its usually reading ### 100% and device
signature messages and started on the writing #### part when wheels on
my robot started turning. It finished writing and reading again and then
it failed verification. 

Then I have not been able to connect back to the board. I have tried to
use the -F which sometimes has worked to no avail. 

The fact that the wheels started to move during the programming tells me
somehow it overwrote port registers. Who knows what else it overwrote. 

I know that the board is getting power because I have 5v on the board's
vcc pin. 

I am fairly sure it is not running any of my code because my init code
flashes leds all during the init process and I do not get any flashing
leds. 

Any suggestions?

--- In AVR-Chat@yahoogroups.com, Brian Dean <bsd@b...> wrote:

> ... setting the fuse bits to
> use an external clock ...
> When set to use an external
> clock, then the chip won't
> run and will refuse to be
> programmed until an external
> clock is provided.

Let's not forget that you don't need the clock running to program the 
MCU, or even to correct problems with the fuses, if you have a JTAG 
interface. The MAVRIC boards have JTAG headers. The OP could pick up an 
inexpensive JTAG interface, see if fuses are indeed his problem and 
maybe even return the JTAG interface afterwards if they are not.

Graham.

On Thu, May 19, 2005 at 11:14:16PM -0400, wbounce wrote:

> This all started when I tried to program the problem board with an
> updated program. It did its usually reading ### 100% and device
> signature messages and started on the writing #### part when wheels
> on my robot started turning. It finished writing and reading again
> and then it failed verification.

I wonder if there could have perhaps been a power supply brown-out
during programming which corrupted the fuse bits?

One of the most common fuse bit problems is setting the fuse bits to
use an external clock as opposed to the external crystal or internal
oscillator.  When set to use an external clock, then the chip won't
run and will refuse to be programmed until an external clock is
provided.

Try supplying around a 1 MHz TTL square wave into the XTAL1 input (pin
24).  You can easily access this pin by the right hand pad of the
external crystal.  You can supply this with most any function
generator (just be sure you limit the voltage to 5V), or even a second
AVR board simply programmed to toggle one of its I/O pins.

With the signal applied, retry entering programming mode.  If you get
into programming mode, then you can reset the fuses back to their
defaults and you should run normally after that.  The default fuses on
your MAVRIC-II board are: efuse=0xff, hfuse=0x89, lfuse=0x3f.

-Brian
-- 
Brian Dean
BDMICRO - ATmega128 Based MAVRIC Controllers
http://www.bdmicro.com/

Okay I remember you mentioning this before. 

Now for some details.

I assume I will need to connect both boards to the same power 
source. ie so they will have common ground. 

I can figure out how to get the good board to generate the on off 
pulse (It is just a matter of doing the math but I do not have the 
data sheet with me now.) Does it have to be exactly 1MHZ?

Now for hooking up the boards, I as long as the both run to the same 
ground, I just run a wire from my output pin on the good board to 
the "right hand" pad. Right? 

By right hand pad I assume you mean if you hold the board so the 
MAVRIC II label is at the top and correct side up. In other words on 
the same side as the voltage regulator. 

By pad I am guessing this is a surface mount piece. which means 
temporarily attaching a wire is going to be real fun (NOT) 


Looks like I have a fun night ahead.

Is this all correct.

 

--- In AVR-Chat@yahoogroups.com, Brian Dean <bsd@b...> wrote:
> On Thu, May 19, 2005 at 11:14:16PM -0400, wbounce wrote:
> 
> > This all started when I tried to program the problem board with 
an
> > updated program. It did its usually reading ### 100% and device
> > signature messages and started on the writing #### part when 
wheels
> > on my robot started turning. It finished writing and reading 
again
> > and then it failed verification.
> 
> I wonder if there could have perhaps been a power supply brown-out
> during programming which corrupted the fuse bits?
> 
> One of the most common fuse bit problems is setting the fuse bits 
to
> use an external clock as opposed to the external crystal or 
internal
> oscillator.  When set to use an external clock, then the chip won't
> run and will refuse to be programmed until an external clock is
> provided.
> 
> Try supplying around a 1 MHz TTL square wave into the XTAL1 input 
(pin
> 24).  You can easily access this pin by the right hand pad of the
> external crystal.  You can supply this with most any function
> generator (just be sure you limit the voltage to 5V), or even a 
second
> AVR board simply programmed to toggle one of its I/O pins.
> 
> With the signal applied, retry entering programming mode.  If you 
get
> into programming mode, then you can reset the fuses back to their
> defaults and you should run normally after that.  The default 
fuses on

> your MAVRIC-II board are: efuse=0xff, hfuse=0x89, lfuse=0x3f.
> 
> -Brian
> -- 
> Brian Dean
> BDMICRO - ATmega128 Based MAVRIC Controllers
> http://www.bdmicro.com/

Oh yeah Should I put a current limiting resistor in series on the 
wire?


--- In AVR-Chat@yahoogroups.com, Brian Dean <bsd@b...> wrote:
> On Thu, May 19, 2005 at 11:14:16PM -0400, wbounce wrote:
> 
> > This all started when I tried to program the problem board with 
an
> > updated program. It did its usually reading ### 100% and device
> > signature messages and started on the writing #### part when 
wheels
> > on my robot started turning. It finished writing and reading 
again
> > and then it failed verification.
> 
> I wonder if there could have perhaps been a power supply brown-out
> during programming which corrupted the fuse bits?
> 
> One of the most common fuse bit problems is setting the fuse bits 
to
> use an external clock as opposed to the external crystal or 
internal
> oscillator.  When set to use an external clock, then the chip won't
> run and will refuse to be programmed until an external clock is
> provided.
> 
> Try supplying around a 1 MHz TTL square wave into the XTAL1 input 
(pin
> 24).  You can easily access this pin by the right hand pad of the
> external crystal.  You can supply this with most any function
> generator (just be sure you limit the voltage to 5V), or even a 
second
> AVR board simply programmed to toggle one of its I/O pins.
> 
> With the signal applied, retry entering programming mode.  If you 
get
> into programming mode, then you can reset the fuses back to their
> defaults and you should run normally after that.  The default 
fuses on

> your MAVRIC-II board are: efuse=0xff, hfuse=0x89, lfuse=0x3f.
> 
> -Brian
> -- 
> Brian Dean
> BDMICRO - ATmega128 Based MAVRIC Controllers
> http://www.bdmicro.com/

On Fri, May 20, 2005 at 05:46:24PM -0000, Graham Davies wrote:

> Let's not forget that you don't need the clock running to program
> the MCU, or even to correct problems with the fuses, if you have a
> JTAG interface. The MAVRIC boards have JTAG headers. The OP could
> pick up an inexpensive JTAG interface, see if fuses are indeed his
> problem and maybe even return the JTAG interface afterwards if they
> are not.

Yes, this is true, as long as the JTAGEN fuse was not inadvertantly
disabled as well :-) I guess the same holds for the SPIEN fuse, though
it is not supposed to be able to be changed when programming using the
SPI interface, but then again, strange things can happen during
brown-out.

If he wanted to try an inexpensive JTAG device, I would certainly
recommend yours at:

   http://www.ecrostech.com/Products/AvrJtagIce/Intro.htm

BTW, do you plan to do one that supports the JTAGICE MkII protocol?
I'm just curious because AVRDUDE now supports the JTAGICE MkII
protocol, but does not yet support the original JTAGICE protocol.

-Brian
-- 
Brian Dean
BDMICRO - ATmega128 Based MAVRIC Controllers
http://www.bdmicro.com/

On Fri, May 20, 2005 at 06:32:03PM -0000, Ed wrote:

> I can figure out how to get the good board to generate the on off
> pulse (It is just a matter of doing the math but I do not have the
> data sheet with me now.) Does it have to be exactly 1MHZ?

No.  If you just set your second board to toggle the I/O pin as fast
as it can, then that will probably be fine.

> Now for hooking up the boards, I as long as the both run to the same
> ground, I just run a wire from my output pin on the good board to
> the "right hand" pad. Right?
> 
> By right hand pad I assume you mean if you hold the board so the
> MAVRIC II label is at the top and correct side up. In other words on
> the same side as the voltage regulator.

Yep.

> By pad I am guessing this is a surface mount piece. which means
> temporarily attaching a wire is going to be real fun (NOT)

Yes - it shouldn't be hard.

Regarding a series resistor - you shouldn't need one.

If you can't recover your fuse settings, you can send the board back
to me and I'll take a crack at it.  Worst case, I replace your
ATmega128.

-Brian
-- 
Brian Dean
BDMICRO - ATmega128 Based MAVRIC Controllers
http://www.bdmicro.com/

This worked. Now I need to figure out why it happened to prevent it from
happening again. I have to go now but want o run some ideas by you when
I get back.

-----Original Message-----
From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On
Behalf Of Brian Dean
Sent: Friday, May 20, 2005 4:37 PM
To: AVR-Chat@yahoogroups.com
Subject: Re: [AVR-Chat] Re: Avrdude problems.


On Fri, May 20, 2005 at 06:32:03PM -0000, Ed wrote:

> I can figure out how to get the good board to generate the on off 
> pulse (It is just a matter of doing the math but I do not have the 
> data sheet with me now.) Does it have to be exactly 1MHZ?

No.  If you just set your second board to toggle the I/O pin as fast as
it can, then that will probably be fine.

> Now for hooking up the boards, I as long as the both run to the same 
> ground, I just run a wire from my output pin on the good board to the 
> "right hand" pad. Right?
> 
> By right hand pad I assume you mean if you hold the board so the 
> MAVRIC II label is at the top and correct side up. In other words on 
> the same side as the voltage regulator.

Yep.

> By pad I am guessing this is a surface mount piece. which means 
> temporarily attaching a wire is going to be real fun (NOT)

Yes - it shouldn't be hard.

Regarding a series resistor - you shouldn't need one.

If you can't recover your fuse settings, you can send the board back to
me and I'll take a crack at it.  Worst case, I replace your ATmega128.

-Brian
-- 
Brian Dean
BDMICRO - ATmega128 Based MAVRIC Controllers http://www.bdmicro.com/


 
Yahoo! Groups Links

On Sat, May 21, 2005 at 01:18:32PM -0400, wbounce wrote:

> This worked.

Excellent!

> Now I need to figure out why it happened to prevent it from
> happening again. I have to go now but want o run some ideas by you
> when I get back.

I've heard reports of this type of thing happening with the AVR, and
not limited to any particular AVR part.  I suspect they may be caused
by brown-out which can result in unpredictable behavior.  I suspect
that during programming, some type of power supply glitch occured, but
I don't know of any way to tell for sure.  I did ask my Atmel field
rep about reports of this problem, and he basically alluded to the
same conclusion - a power supply problem during programming might be
the cause, but he had nothing definitive.  He was not aware of any
errata or anything else that could cause fuses to be unpredictably
modified.

-Brian
-- 
Brian Dean
BDMICRO - ATmega128 Based MAVRIC Controllers
http://www.bdmicro.com/

--- In AVR-Chat@yahoogroups.com, Brian Dean <bsd@b...> wrote:

> ... do you plan to do [an inexpensive
> JTAG device] that supports the JTAGICE
> MkII protocol?

No, I'm afraid I don't. There are several reasons. One is that my 
personal circumstances have changed and I no longer have time for new 
product development. Also, I can't see any way to do this without 
buying the Atmel unit and reverse engineering it. Maybe someone who is 
less squeamish about intellectual rights will do this.

Graham.

--- In AVR-Chat@yahoogroups.com, "Graham Davies" <YahooGroups@e...> 
wrote:
> --- In AVR-Chat@yahoogroups.com, Brian Dean <bsd@b...> wrote:
> 
> > ... do you plan to do [an inexpensive
> > JTAG device] that supports the JTAGICE
> > MkII protocol?
> 
> No, I'm afraid I don't. There are several reasons. One is that my 
> personal circumstances have changed and I no longer have time for 
new 
> product development. Also, I can't see any way to do this without 
> buying the Atmel unit and reverse engineering it. Maybe someone 
who is 
> less squeamish about intellectual rights will do this.
> 
> Graham.

Hmmm, well, I would think that "reverse engineering"  would be 
reproducing the output for each possible input, treating the 
original device as a "black box".  

But when you open the box and examine the contents and reproduce 
them, then that is "copying".  

I think "reverse engineering" without cheating and looking at the 
working parts inside is fair and legal.  "Copying" is not.

You could get into hot water if you accidentally create a device 
that is so good that it looks copied.

Sometimes there is really only one way to skin the cat, and when you 
end up with the same solution, then it is just good engineering.  No 
one owns good engineering.  But you might have to prove it in court.

Keeping notes in a dated notebook would be very useful in court.  
Also useful to record your thoughts and sketches/diagrams along the 
way.  I always loved those lab books with horizontal and vertical 
lines.  I have to get me some more of those.

Right now I am reverse engineering a rally computer.  Copying is not 
at all an issue here because the basic hardware is so different.  
The original is Z-80 and mine is AVR.  The original was programmed 
in ASM, and I am doing it in C.

So all I am really reproducing is the look and feel.  This is hard 
to pursue legally.   Not that it would ever come to that.  I do not 
plan on selling these things, and I already spoke with the 
designer/manufacturer of the original and he had no problems with my 
project.  Especially since I told him I would give him anything I 
developed if he wanted it.

-Tony

-Tony

Over the weekend I reviewing my PWM setting on the bot I am working on.
And I saw in the data sheet that you need to be sure that the new OCR3A
or OCR3B need to be higher TCNT. How you you handle this? I seem to have
a problem with 1 motor erratically reving to full speed. Could this be
my problem?

On Mon, May 23, 2005 at 08:26:26PM -0400, wbounce wrote:

> Over the weekend I reviewing my PWM setting on the bot I am working
> on.  And I saw in the data sheet that you need to be sure that the
> new OCR3A or OCR3B need to be higher TCNT. How you you handle this?
> I seem to have a problem with 1 motor erratically reving to full
> speed. Could this be my problem?

Not sure if that is your problem or not, but one way to do it would be
to "schedule" the assignment and then actually do it on timer overlow
since you know the timer starts out as zero at that time.  I.e.,
something like this:

    ...
    new_ocr3a = new_pwm;
    ...


SIGNAL(SIG_OVERFLOW3)
{
  if (OCR3A != new_ocr3a) {
    OCR3A = new_ocr3a;
  }
}


... or something like that.

Something else you might look at - have you tried using "glitch free"
phase correct PWM mode, like waveform generation modes 1, 2, and 3
(I'm assuming you are using your ATmega128) which are dual slope PWM
modes?  This mode is somewhat more tolerant to changing the OCRx
registers with regard to their output waveform.  Note that with
everything else being equal, the PWM frequency will be 1/2 of that of
one of the single-slope modes (fast PWM).  But with three modes to
choose from, 1, 2, and 3, you can trade off resolution for frequency
as needed.

-Brian
-- 
Brian Dean
BDMICRO - ATmega128 Based MAVRIC Controllers
http://www.bdmicro.com/

The STK500 schematics are available for anyone to review.  The MKII 
looks pretty complicated.  I looked it over just yesterday. For the 
price I would not bother to try and make my own.

Al


--- In AVR-Chat@yahoogroups.com, "arhodes19044" <spamiam@c...> wrote:
> --- In AVR-Chat@yahoogroups.com, "Graham Davies" <YahooGroups@e...> 
> wrote:
> > --- In AVR-Chat@yahoogroups.com, Brian Dean <bsd@b...> wrote:
> > 
> > > ... do you plan to do [an inexpensive
> > > JTAG device] that supports the JTAGICE
> > > MkII protocol?
> > 
> > No, I'm afraid I don't. There are several reasons. One is that my 
> > personal circumstances have changed and I no longer have time for 
> new 
> > product development. Also, I can't see any way to do this without 
> > buying the Atmel unit and reverse engineering it. Maybe someone 
> who is 
> > less squeamish about intellectual rights will do this.
> > 
> > Graham.
> 
> Hmmm, well, I would think that "reverse engineering"  would be 
> reproducing the output for each possible input, treating the 
> original device as a "black box".  
> 
> But when you open the box and examine the contents and reproduce 
> them, then that is "copying".  
> 
> I think "reverse engineering" without cheating and looking at the 
> working parts inside is fair and legal.  "Copying" is not.
> 
> You could get into hot water if you accidentally create a device 
> that is so good that it looks copied.
> 
> Sometimes there is really only one way to skin the cat, and when 
you 
> end up with the same solution, then it is just good engineering.  
No 
> one owns good engineering.  But you might have to prove it in court.
> 
> Keeping notes in a dated notebook would be very useful in court.  
> Also useful to record your thoughts and sketches/diagrams along the 
> way.  I always loved those lab books with horizontal and vertical 
> lines.  I have to get me some more of those.
> 
> Right now I am reverse engineering a rally computer.  Copying is 
not 
> at all an issue here because the basic hardware is so different.  
> The original is Z-80 and mine is AVR.  The original was programmed 
> in ASM, and I am doing it in C.
> 
> So all I am really reproducing is the look and feel.  This is hard 
> to pursue legally.   Not that it would ever come to that.  I do not 
> plan on selling these things, and I already spoke with the 
> designer/manufacturer of the original and he had no problems with 
my 

> project.  Especially since I told him I would give him anything I 
> developed if he wanted it.
> 
> -Tony
> 
> -Tony

On Thu, May 26, 2005 at 01:33:14PM -0000, alwelch93021 wrote:
> The STK500 schematics are available for anyone to review.  The MKII 
> looks pretty complicated.  I looked it over just yesterday. For the 
> price I would not bother to try and make my own.

Yeah, what I don't understand is what all that complexity is all about.
Non-Atmel "serial emulation" USB chips appear to be much simpler than
whatever Atmel did on the mk-II.

I have a mk-II and mostly use an ICE-cube because my LP2950CN-3-3 isn't
stout enough to drive the mk-II. Was a bit surprised the mk-II is
externally powered yet apparently draws more from the circuit than the
vampire ICE-cube. No time to investigate as long as I have something
working.

-- 
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

Atmel says it needs a min of 600ma to power the MKII.  It has two 
ATMEG128 chips onboard plus other parts.

I was pleased to find the STK500 allows the target VCC to be set in 
software from AVRStudio. I measured it with a meter to be sure and 
it does what is says!  This is real handy for powering up sensors 
and other items you want to aval along with the AVR.


Al Welch

--- In AVR-Chat@yahoogroups.com, David Kelly <dkelly@h...> wrote:
> On Thu, May 26, 2005 at 01:33:14PM -0000, alwelch93021 wrote:
> > The STK500 schematics are available for anyone to review.  The 
MKII 
> > looks pretty complicated.  I looked it over just yesterday. For 
the 
> > price I would not bother to try and make my own.
> 
> Yeah, what I don't understand is what all that complexity is all 
about.
> Non-Atmel "serial emulation" USB chips appear to be much simpler 
than
> whatever Atmel did on the mk-II.
> 
> I have a mk-II and mostly use an ICE-cube because my LP2950CN-3-3 
isn't
> stout enough to drive the mk-II. Was a bit surprised the mk-II is
> externally powered yet apparently draws more from the circuit than 
the
> vampire ICE-cube. No time to investigate as long as I have 
something
> working.
> 
> -- 
> David Kelly N4HHE, dkelly@H...
> 
=====================================================================
===
> Whom computers would destroy, they must first drive mad.

David Kelly wrote:
> Yeah, what I don't understand is what all that complexity is all about.

IP protection?















peter.