Re: R6k and Ethernet current

Digi tech support has relayed another idea from the software dept. 
They referred me to the following paragraph in the DC 10.70 release 
notes as a possible solution:

- The DMAETH100_AUTO_NEG_TIMEOUT macro is deprecated. Rabbit 5000
  or 6000 built-in Ethernet applications which use a custom
  definition for this macro should instead define one or both of
  the DMAETH100_LINKFAIL_TIMEOUT or DMAETH100_LINKDOWN_TIMEOUT
  macros. The *LINKFAIL* macro value determines the PHY powered-
  up time out for link-failed detection. The *LINKDOWN* macro 
  value determines the PHY powered-down idle time-out for no-
  connect Ethernet current reduction. The default value for each
  of the *LINK* macros is 4000 milliseconds, which results in a
  50% powered-up vs. powered-down duty cycle when e.g. Ethernet
  is not connected.

Tech Support Comment:
  "If it does need Ethernet, but must ensure ADC and / or DAC 
   readings / settings are as precise as possible, then they may have 
   to check pd_havelink() and call pd_powerdown() or maybe just 
   ifdown() to ensure analog readings / settings accuracy."


I've read the release note paragraph over and over, and I've been 
looking at the source code in DAMETH100.lib and I'm not sure how to use these macros solve my problem. It seems like the two macros 
control two timeouts. One timeout for how long the PHY is to wait for 
a LAN connection before powering down. The other timeout, how long to 
stay power-down before powering back up to check for a link again. Am 
I understanding that right?

The Tech Support comment seems to be suggesting that I power down
the Ethernet interface for analog accuracy. That is not an option.

Steve



--- In [email protected], "seecwriter" <seecwriter@...> wrote:
>
> Paul,
> 
> Thank you for that information. 
> 
> I contacted Digi tech support and told them the problem. They replied,
> "I checked with engineering and was told this is normal operation for
> rabbit 6000 products."
> 
> I then told them that a former Rabbit employee said it was a known 
> bug and was supposed to be fixed with the release of the RCM6600W.
> They replied with, "I checked with software and they don't know of a
> library that fixes this issue. They did suggest that the re-spin of
> the 6000 chip addresses this issue."
> 
> I then asked they thought the re-spin would take place. I'm waiting
> for an answer.
> 
> Hopefully the battery-killer clock on the R6k will be fixed with the
> re-spin too.
> 
> 
> Steve
> 
> --- In [email protected], "Paul " <lackofbrilliance@> wrote:
> >
> > Hi Steve,
> > 
> > I was a long time Z-World/Rabbit software engineer and the engineering manager responsible for Rabbit development for the last three years prior to Digi's last round of layoffs.  This is a known problem that, if memory serves, was scheduled to be fixed with the Dynamic C release to support the RCM6600W.  You should contact Digi technical support to see if you can get a copy of the library that fixes this problem.  
> > 
> > - Paul
> > 
> > 
> > --- In [email protected], "seecwriter" <seecwriter@> wrote:
> > >
> > > For the RCM67XX module, we've noticed an anomaly with current draw
> > > when using Ethernet.
> > > 
> > > When the Ethernet port is connected to a LAN, the total current draw
> > > for the computer section (motherboard + RCM67XX) is a steady 350ma.
> > > However, if the Ethernet port is not connected, the current fluctuates
> > > between 350ma and 500ma. We've traced the increase in current to the
> > > call of pd_havelink() that occurs at about a 500ms rate. That 150ma of 
> > > extra current seems like a huge increase just to check for a LAN 
> > > connection. This pulsing current is affecting our ADC and DAC readings 
> > > and settings.
> > > 
> > > This occurs on all of our modules. Anyone else notice this and/or have
> > > any ideas on what to do about it? Adding extra bypass caps hasn't 
> > > helped. 
> > > 
> > > Steve
> > >
> >
>