Hardware experiment

Archiver

Hi Stampers,

has anyone ever cut off the little chip that is on the stamp to reset it
whenever the voltage goes lower than 4.0 volts?
I did so as the last chance to prevent my stamp to reset whenever my pumps
and valves move and send lots of noise through the air and the wires...

Does anyone know about the disadvantages? Works fine up to now though :-)

Thanks, Uli


[noparse][[/noparse]Non-text portions of this message have been removed]

Archiver

There is no way for someone to "modify" your code, as once it is encoded on
the chip, it can't be donloaded to be edited. However it is possible, if
someone knows what they are doing, to upload an entirely new program onto
the basic stamp. I don't know of any way of preventing that.

-D

---

Original Message

---

From: "ulibasic" <ulibasic@r...>
To: <basicstamps@yahoogroups.com>
Sent: Wednesday, October 10, 2001 11:22 AM
Subject: AW: [noparse][[/noparse]basicstamps] Hardware experiment


um....did I ask something wrong? this is the first time I get no answer at
all though its the second time I ask. Am I hurting the hidden hardware-codex
or sumthin' ? :-)

have a nice day, uli

---

Urspr

Archiver

Hi Uli:

The 8054HN is there to ensure reliability of the stamp process, if not to
reduce liability.
All it does is to provide a distinct point of minimum Vdd, or a threshold
that the Stamp should always function above. If you can live with the
consequences of it's elimination in your application you'll do just fine.
You could be getting some bit-scrambling that is inconsequential during the
noisy periods you are mentioning, and you may see these have negative
consequences as you log more hours on this particular stamp. On the other
hand, you may be getting away with this one. I seem to recall that the 8054
has a detect tolerance of +/- .2 V or so. As long as your hi In's stay above
1.5 and the stamp otherwise functions, (The regulator is going to be having
fits!) It will work until it crashes (OK, it can't really crash - it'll just
run afoul). With the Stamp being deterministic, you wouldn't know if
something failed unless/until it manifested in an output. In other words,
just because you can't see a problem, it doesn't mean there isn't one. It
was good design practice to include the 8054 for that reason alone. One neat
idea might be to use it's output on another input that you might use to goto
(oh, sorry, if then..)a diagnostic loop to ensure that the outside world
conditions are what you expect.
Personally, I wouldn't remove the 8054 unless I had absolutely no way to get
the time needed to filter or de-couple the noise problem away properly.

What's the noise source anyway?

Chris

>

---

Original Message

---

> From: ulibasic [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=nBrANLmldrVVFZ_vB8IFaqr_F7wYTT2T8SNwb7MV_Eb4qp5wK9ATxFAaQwcPAK10lCM3Owc4xv1jPxmxyzBymgayJ0kjsojMolHe]ulibasic@r...[/url
> Sent: Wednesday, October 10, 2001 1:23 PM
> To: basicstamps@yahoogroups.com
> Subject: AW: [noparse][[/noparse]basicstamps] Hardware experiment
>
>
> um....did I ask something wrong? this is the first time I get
> no answer at
> all though its the second time I ask. Am I hurting the hidden
> hardware-codex
> or sumthin' ? :-)
>
> have a nice day, uli
>
>
>
>

---

Urspr

Archiver

Oops - left out a thought:
Uli, the debug should show you if something has gone awry in your 8054'less
project, so you can get a glimpse beyond the outputs.....
But I'm sure you inserted 'debug' statements and watched it run for hours by
now....
CL

Archiver

> But does this mean that IF there are some scrambled bits I
> could fix them by
> restarting the stamp?
>
I believe so. Here's my understanding of why:

The stamp2 has EEPROM off-PIC and the data in it should be safe, except in
the case where your basic program may be writing to or reading the EEPROM. I
suppose that an instruction could be garbled into the ML equivalent of a
Basic "Write" instruction. The data being moved into EEPROM from a Write
instruction could also lose 1's (see them as 0's) and be written over your
program memory. Chances are good that if this hasn't happened yet, it likely
will not. A reset will not fix these errors if they do occur. There are just
too many semi devices in these things to be predictive here without much too
much analysis.

The PIC's TRIS registers could also get fouled up, conceivably turning an
output into an input. I can't see it happening the other way around... A
reset-restart will set all these to input and they will be reconfigured
according to your initializing pin assignments at the top of your basic
program listing.
>
>
> It
> was good design practice to include the 8054 for that reason
> alone. One neat
> idea might be to use it's output on another input that you
> might use to goto
> (oh, sorry, if then..)a diagnostic loop to ensure that the
> outside world
> conditions are what you expect.
>
> Sorry, didn't quite get this one. Does that mean I use the
> output of the
> 8054 on a normal stamp-input and whenever it goes high I use
> a routine to
> check if everything is right? HOW would I check if WHAT is wrong?

If for example, you determine the most likely error will be in a TRIS
register, you could output the 8054 to another pin set as an input which
your main program loop would use do direct to a routine that reads something
like current sensors on outputs to see if they are high, or perhaps more
easily auxiliary contacts, the state of which would also tell you if the
output was high or low. If any of the conditions you describe in that loop
is not met, you can at best signal the error with another output through
some kind of indicating means. Since this loop would only execute in the
case of a brownout, you'd have some level of diagnostics working in your
favor. If you were to really work at it, you could get that routine to reset
the stamp if all diagnostic conditions are not met (with a little more
hardware.)
>
>
> Personally, I wouldn't remove the 8054 unless I had
> absolutely no way to get
> the time needed to filter or de-couple the noise problem away
> properly.
>
> Do you have any complete list of anti-noise-measures one can
> use? I tried
> everything I could think of, including (oops, I am missing
> some english
> words here,) those ferrit-things you wrap your wire around,
> zener-diodes,
> caps over the power-supply, small caps against peaks,
> batteries as stamp
> supply, grounded metal-case around the stamp....
>

There are a couple of links on this subject that I have shared in the past
and if I can find them, I'll post 'em.
>
> What's the noise source anyway?
>
>
> It is two valves driven by coils (220V~) and two aquarium air
> pumps (big
> ones). The whole thing is a game called 'MINDBLOW' in which
> you hold up a
> kind of hood over your head and ty to stay very calm
> (concentrate!). The
> player who stays the calmest has his baloon inflated whereas
> the other one
> loses air. (sounds VERY silly but is great fun... :-)
>
Are your AC loads optically isolated?
Have you tried running them on a different AC line?
What kind of diodes do you have across the coils? how fast are they?
It sounds like a big snubber across each of the coils would work also. You
could try a cap, say from .1 to .47 uF (rated for well above the line
voltage) and a 10 ohm resistor in series.
If that doesn't do the trick, I'd opto-isolate. I always do when controlling
AC loads and motors.


>
> And one more question: how could I debug the possible
> invisible mistakes you
> were thinking of? Just debug the variables and see if they
> behave right or
> what do you suggest?

Without knowing your program, all I can add is that I would look for the
most logical variable values that would demonstrate whether or not a data
error has occurred and insert debug's to show them. Then I would watch the
thing run and look for errors. There is no way to see all the data. You
might additionally check your memory map to see if something shows up where
it doesn't when all is well, and vice-versa.
>
> SSSSooooo many questions.....
>
> Thanks a lot, chris
>
> Uli
>
>
>
>