<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel about="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic">
    <title>gmane.comp.hardware.microcontrollers.pic</title>
    <link>http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147147"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147146"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147145"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147144"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147143"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147142"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147141"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147140"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147139"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147138"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147137"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147136"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147135"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147134"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147133"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147132"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147131"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147130"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147129"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147128"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147147">
    <title>[EE]:: Cree standards for LED testing</title>
    <link>http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147147</link>
    <description>Cree LED testing procedures.
24 categories for LED testing.
Standards used and conditions.


        http://www.cree.com/Products/pdf/LED_Lamp_Reliability_Test_Standard.pdf
</description>
    <dc:creator>Apptech</dc:creator>
    <dc:date>2008-07-25T08:18:26</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147146">
    <title>[PIC] Staapl</title>
    <link>http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147146</link>
    <description>Hello folks,

The Staapl project has come to a point where it is ready for public
scrutiny.

http://zwizwa.be/staapl

Staapl is a collection of abstractions for (meta)programming
microcontrollers from within PLT Scheme. The core of the system is a
programmable code generator structured around a functional
concatenative macro language. On top of this it includes a syntax
frontend for creating Forth-style languages, a backend code generator
for Microchip's PIC18 microcontroller architecture, and interaction
tools for shortening the edit-compile-test cycle.

Enjoy!
Tom

</description>
    <dc:creator>Tom Schouten</dc:creator>
    <dc:date>2008-07-25T07:47:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147145">
    <title>Re: [PIC] Remote network sensors</title>
    <link>http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147145</link>
    <description>
If dimensions are not a concern, it should be possible to use an 
off-the-shelf $20 wireless router connected to a UART/Ethernet module 
without hacking anything. Might be a good hack for some quick-and-dirty 
one-off applications.

Vitaliy 

</description>
    <dc:creator>Vitaliy</dc:creator>
    <dc:date>2008-07-25T06:13:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147144">
    <title>Re: [PIC] Remote network sensors</title>
    <link>http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147144</link>
    <description>
On Jul 24, 2008, at 2:44 PM, Alex Harford wrote:


Hmm.   Or any of the other wireless router platforms that has enough  
info out there to run DDWRT or similar, many way cheaper than the  
WRT54GL.  (hackability at the HW level is likely to be variable,  
though.  One of these days a clever HW verndor will stick some  
x2.54mm headers on the unused pins to target the (small but vocal)  
hacker market.)  How ... sad.

It's also sad that something like the lantronix WIPort contains an  
x86 class machine with significant memory, enough so that putting a  
PIC on the side is ... almost silly.
You could consider using something like a Rabbitcore (http:// 
www.rabbit.com/products/CoreModules/index.shtml) where at least you  
get to USE the same CPU that runs the tcp stack.  (less than $50 for  
ethernet, less than $100 for 802.11.  Also a zigebee version.)

You might also want to look at things like PDAs with wireless network  
connectivity.  Some of those have significant free development  
environments, subst</description>
    <dc:creator>William "Chops" Westfield</dc:creator>
    <dc:date>2008-07-25T05:27:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147143">
    <title>[OT]:: Al Gore - A Generational Challenge to Repower America</title>
    <link>http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147143</link>
    <description>Some whacko has to post on this sooner or later.
May as well be me :-).

This belongs in TECH *BUT* I'm posting it in OT as we don't 
have the maturity to handle it in TECH at a noise level that 
is appropriate. If it gets out of hand here we'll have to 
trash the thread. If it gets ignored here, that's fine.

This is a very recent 'speech' by Al Gore challenging the US 
(the title says America) to convert all US electricity 
generation to non-hydrocarbon dependent sources within 10 
years. It covers more than that, but that's the core.

There is the inevitably unavoidable rubbish content and some 
good ideas and thoughts. The ideas are not without merit but 
will probably meet with mindless scathing putdowns from his 
opponents &amp; detractors and mindless adulation from his fans. 
In between the two it would be good if there could here be 
some useful sage and reasoned comments. One can hope :-).

You can find the speech on zillions of sites by Gargoyling

    A Generational Challenge to Repower America

or i</description>
    <dc:creator>Apptech</dc:creator>
    <dc:date>2008-07-25T05:15:44</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147142">
    <title>Re: [PIC] Remote network sensors</title>
    <link>http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147142</link>
    <description>
Marcel, I'm glad you made the mistake. I have a feeling that the module you 
recommended will find its way into one of our products. So, thanks! :-)

Vitaliy 

</description>
    <dc:creator>Vitaliy</dc:creator>
    <dc:date>2008-07-25T04:25:17</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147141">
    <title>Re: [PIC] Shopping at MASTERS 2008 -- pricelist</title>
    <link>http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147141</link>
    <description>Most likely too late to be useful, but here it is anyway:

http://maksimov.org/masters_pricelist.pdf
</description>
    <dc:creator>Vitaliy</dc:creator>
    <dc:date>2008-07-25T04:17:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147140">
    <title>[EE] question on a fall edge trigger</title>
    <link>http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147140</link>
    <description> 
Hi:
 
 
  I'm designing a battery charger with a power factor correction pre-converter. This critical conduction mode PFC chip (L6562 from ST), has a so-called compensation network, so that when load changes abruptly, it will slowly modify the output power to realize a high power factor. 
 
  But since mine is a charger, there is almost a constant load, thus this function is not really useful. My worry is: when the load is suddenly removed, the chip might be unable to respond fast enough.
 
 
  I wonder is there such a transistor circuit, which does nothing at no load or full load, but only outputs high when load is removed (fall edge)? This may involve some power, so I think simple flip-flops might not be useful.
 
 
  Thank you for any opinions.
_________________________________________________________________
使用 MSN 有问题怎么办？客服机器人来帮忙！
http://help.msn.cn/-- 
http://www.piclist.com PIC/SX FAQ &amp; list archive
View/change your membership options at
http://mailman.mit.edu/mai</description>
    <dc:creator>gardenyu</dc:creator>
    <dc:date>2008-07-25T03:40:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147139">
    <title>Re: [EE] FET question</title>
    <link>http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147139</link>
    <description>

Listas de Correo wrote:

I'm ready to suggest that when using the FET the voltage rises too
slowly for the Rabbit to start.

Can you test again using the FET but driving the gate manually, first
with a jumper wire, and if that works, then with a resistor? Because if
it starts with the jumper driving the FET but not the resistor, that is
a risetime problem.

Cheerful regards,

Bob
</description>
    <dc:creator>Bob Blick</dc:creator>
    <dc:date>2008-07-25T03:29:23</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147138">
    <title>Re: [EE] FET question</title>
    <link>http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147138</link>
    <description>
Looks OK enough from the spec sheet curves.

Looking at V across module with a scope at turn on may give 
some clues.

An easy enough test is to try a high side driver.

Disconnect FET drain from model gnd.
Ground module gnd.
Small pnp transistor with at least 500 mA rating (BC327 or 
similar)
Beta of 100 at least at 500 mA.

Emitter to V+
Collector to module V+
Base via say 470 ohms to FET drain.

You now have a high side switch with good drive

If that works it gives you a clue.
If not then the clue is different but not so clear.

I assume that you have the MOSFET gds connected OK :-).


        Russell



</description>
    <dc:creator>Apptech</dc:creator>
    <dc:date>2008-07-25T03:26:20</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147137">
    <title>Re: [EE] FET question</title>
    <link>http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147137</link>
    <description>
This d/s says 0.2R &lt; at &gt; 4.5V, 0.3R &lt; at &gt; 2.5V

http://www.fairchildsemi.com/ds/FD/FDV305N.pdf

Take a look at Figures 2 and 4, you might find that Ron is higher than
you planned for

If I'm asssuming correctly, quick look, and the normalised Ron is *1.1
&lt; at &gt; 3.5V and 0.5A, then that would mean actual Ron in circuit is 0.33R,
so you'd be losing 0.450A * 0.33R = 0.15V. If so, that puts the voltage
available for the Rabbit at 3.15V

Can you bump up the regulator output a little ?

</description>
    <dc:creator>Jinx</dc:creator>
    <dc:date>2008-07-25T03:15:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147136">
    <title>Re: [OT]:: Why most published research findings are false.</title>
    <link>http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147136</link>
    <description>


Yes.o problem if that was the level of response.
However, what does happen is that people get results which 
show with statistical significance that there is/isn't 
(choose one) something happening. People can/can't replicate 
their results (or can't/can) and people publish papers 
drawing all available conclusions (not necessarily in the 
same paper).

At the very large scale there are correlations present 
between increased disease risks for workers in some 
industries that suggest that EM fields may have causal roles 
in such things. Some cell-phone/cancer studies show a clear 
linkage and others show none.

All adds grist for the subject line of this email.



            Russell

</description>
    <dc:creator>Apptech</dc:creator>
    <dc:date>2008-07-25T03:09:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147135">
    <title>Re: [EE] FET question</title>
    <link>http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147135</link>
    <description>

Just curious - how did you come to be in this position ?

</description>
    <dc:creator>Jinx</dc:creator>
    <dc:date>2008-07-25T02:55:33</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147134">
    <title>Re: [EE] FET question</title>
    <link>http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147134</link>
    <description>The Fet itself might be ok with a 0 ohm drive but the PIC probably wont 
be ;-&gt; you could well be asking for a few amps of drive current (for a 
very short time).
I'm wondering given the OP is using a 5.6K resistor if the miller charge 
is turning the fet off again as the rabbit comes up to power (as 
somebody else said its probably charging some caps and asking for a few 
amps of current)

To limit the initial current you want about a 170 ohm resistor and that 
should hopefully be stiff enough to handle any of that other weirdness 
that goes on with fets.
Your sure the fet is into its saturated region at 3.3V gate drive? 
that's quite low, not impossible just uncommon is all.

Don't know how it'll work with the rabit, but try sticking a 1 ohm 
resistor in line with it, might help reduce the switch on thump.



</description>
    <dc:creator>Jake Anderson</dc:creator>
    <dc:date>2008-07-25T02:56:35</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147133">
    <title>Re: [EE] FET question</title>
    <link>http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147133</link>
    <description>I have tried connecting and disconnecting the ground wire of the rabbit,
directly, to GND and it successfully starts every time.

The 450 mA at 0.15 ohm represent a voltage drop of 0.0225 V, that is 0.68%
of 3.3V, so the Rabbit should work with that voltage, shouldn't?

I'm trying not to consider RF yet...

On Thu, Jul 24, 2008 at 11:00 PM, Apptech &lt;apptech&lt; at &gt;paradise.net.nz&gt; wrote:

</description>
    <dc:creator>Listas de Correo</dc:creator>
    <dc:date>2008-07-25T02:51:48</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147132">
    <title>Re: [OT] Dual SIM mobile phone</title>
    <link>http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147132</link>
    <description>In that scenario Tomás I suggest you wait until you get here.  AIS is the
only carrier (thank you Mr. Thaksin) license for dual SIM, and you have to
set it up through them on their equipment.  It's still technically unlawful
to import any communications device to Thailand without a special permit and
license.  That's not often enforced, but the penalties are too high and the
work arounds too easy to ignore with any wisdom.  You will find that most
people simply carry 2 or more cell phones rather than draw attention to
themselves and raise unnecessary questions:-)

Regards/Roger, in Bangkok

On Fri, Jul 25, 2008 at 6:21 AM, Tomás Ó hÉilidhe &lt;toe&lt; at &gt;lavabit.com&gt; wrote:

</description>
    <dc:creator>Roger, in Bangkok</dc:creator>
    <dc:date>2008-07-25T02:36:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147131">
    <title>Re: [OT]:: Why most published research findings are false.</title>
    <link>http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147131</link>
    <description>

Apptech wrote:


Well if the guinea pigs grow an extra head, or if they start walking 
into walls, then I think it's fair to speculate that it's caused by the 
mobile phones. (Assuming of course, in the absence of mobile phones, 
they don't grow extra heads or walk into walls).

</description>
    <dc:creator>Tomás Ó hÉilidhe</dc:creator>
    <dc:date>2008-07-25T01:04:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147130">
    <title>Re: [EE] FET question</title>
    <link>http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147130</link>
    <description>
FET should tolerate a zero ohm connection from PIC.

Try this.
- Set up system as described.
- Add switch across FET drain-source.
- Open switch
- Enable system via FET.
- Close switch.

IF it works under that condition the FET is suspect as an on 
switch.
FET should have about 0.15 ohm on resistance as described. 
Should be OKish although the module spec is 3V3 +/- 5% so 
you are outside that range at 450 mA.

If it fails to work then the system is probably being 
disabled in some manner by the load side open switch.
eg having the module connected to Vdd and stray paths from 
I/O to ground may do funny things to it.

Also: RF may be getting into FET. All bets off if that 
happens :-).



        Russell 

</description>
    <dc:creator>Apptech</dc:creator>
    <dc:date>2008-07-25T02:00:55</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147129">
    <title>Re: [EE] FET question</title>
    <link>http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147129</link>
    <description>Unfortunally, we already have 100 boards made. We can make small changes,
like putting a FET on the high side of the rabbit, but making big changes
will be difficult.

I will see tomorrow, while I'm at the office, if it is possible to change
the layout easily from low side switch to High side switch.

by the way, if I connect the rabbit directly to ground (or with a switch or
a relay) it works just fine. So, the problem is with the MOSFET...

Regards

On Thu, Jul 24, 2008 at 10:43 PM, Spehro Pefhany &lt;speff&lt; at &gt;interlog.com&gt; wrote:

</description>
    <dc:creator>Listas de Correo</dc:creator>
    <dc:date>2008-07-25T02:10:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147128">
    <title>RE: [EE] FET question</title>
    <link>http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147128</link>
    <description>
That's not weird, it's expected. The module probably has a bunch of
bypass capacitors and you're momentarily killing the supply charging them.

I suggest a separate regulator with shutdown input is probably the best
way to handle this (effectively a high-side switch with current limiting)

The problem with switching the low side is that any logic pins that
connect to the PIC or whatever could get pulled way below
"ground" from the perspective of the the Rabbit module (eg. the PIC
is "low", a great deal of current will flow through the protection
diodes on the Rabbit module, possibly damaging it or causing latchup
which would result very quickly in damage due to high currents.





Spehro Pefhany --"it's the network..."            "The Journey is the reward"
speff&lt; at &gt;interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com



</description>
    <dc:creator>Spehro Pefhany</dc:creator>
    <dc:date>2008-07-25T01:43:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147127">
    <title>Re: [EE] FET question</title>
    <link>http://permalink.gmane.org/gmane.comp.hardware.microcontrollers.pic/147127</link>
    <description>2008/7/25 Jinx &lt;joecolquitt&lt; at &gt;clear.net.nz&gt;:

Or even a toggle switch?

RP
</description>
    <dc:creator>Richard Prosser</dc:creator>
    <dc:date>2008-07-25T01:09:58</dc:date>
  </item>
  <textinput about="http://search.gmane.org/?group=$group=gmane.comp.hardware.microcontrollers.pic">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.hardware.microcontrollers.pic</link>
  </textinput>
</rdf:RDF>
