RE: odd behavior

[Rick Sparber]

Bruce,

Can you check the code to see if the limit function is fed directly by the
scale data or from the filter? I see no flicker in the display when I heard
the beep. At least last night it would not beep spontaneously with the case
open. I won't be able to button it up until tomorrow.

I think your theory is close. I'm guessing that the filter is used for the
display but due to a bug, the limit is fed with unfiltered scale data.
Additionally, I think there is more bad data when the wires related to the Z
axis are crammed into the box. This does create another test: if the problem
is inside the box, then the beeping problem should not follow the scale.

Should we be using the BBS for all email so all members are kept on board
plus we have a record?

Rick

-----Original Message-----
From: Bruce Fairman [mailto:b...@phlogiston.com]
Sent: Sunday, November 01, 2009 6:31 PM
To: Rick Sparber
Subject: Re: odd behavior

Rick, if you make the filter filter 1, does the beep happen more
frequently? my theory is the jitter of the value of the data received
will occasionally move thru the alert point. so if warn is set for and
the position is close to zero, the code will detect a warning needed
but the display will jitter out of the warn value before you notice it.
my scales have a lot of data jitter, even with a filter of 16.
what do the scale signals look like if they are just terminated by a
resistor (4.7k, 10k)? it looks like the traces you sent are driving a
capacitive load. i wonder is this is a cable or board issue. the
caparator cleans them up, so it may be no problem.
i have my 24bit scale code working again, so i will be sending you
a .bin soon, just need to put the code in to start/stop the serial
port trace. i was going to send the values used for updating the
display. i can send the count value from the scale or the number
displayed, which would you prefer?
bruce

On 2009 Nov, 01, at 16:45, Rick Sparber wrote:

> I have the DRO-550 out of the case and was about to test if the limit
> beeping problem follows the Z scale or stays with the channel. I
> couldn't
> get the problem to occur. Now, maybe I was just not waiting long
> enough but
> it is more likely that the problem only occurs with the case on. This
> implies to me that wires are pushed closer together which increases
> cross
> talk. I'll need to do more testing. I do think that the new software
> may
> help with this problem.
>
> Rick
>

Bruce Fairman
275 Martinez Road
Woodside, CA 94062
650-851-2654

[Bruce Fairman]

Rick, the warning test is done on the reading that is being displayed.
the filter is applied to the last n readings, n is set by user.
the filter is simple, it takes the last n scale readings and averages
them. the filter assumes that the sample buffer is always full. this
is not a real problem.
bruce

[Bruce Fairman]

Rick, i just uploaded to the opendro ug. there are 2 new files: full
and lite. i tested the lite.
here's the details
new config func - dbg
has capt and frm
frm is the missing frame count - i have only seen 0
capt allows input of the scale to send capture for (stdout)
the raw count coming form the scale as seen by the isr is sent with
the following format
scltrc 0 2fa8
scltrc 0 2fa8
scltrc 0 2fa0
scltrc 0 2fa8
scltrc 0 2fa2
scltrc 0 2fa8
scltrc 0 2fa4
scltrc 0 2fa8
the first number is the scale the second is the count used to display
position
i have run 2 scale at once and the traces are interleaved.
the trace runs continuously since the scales are always sending and
with theh data jitter, a look for change would not make much difference.
the output is done in the main loop, so when in func, there is no trace.
bruce

On 2009 Nov, 02, at 05:10, Rick Sparber wrote:

[Rick Sparber]

Bruce,

I went to

http://sourceforge.net/projects/opendro/files/

but could not find the new .bin file.

As mentioned in one of the feature proposals, I would like to see new names
for the daughtercard. IMHO, it will ultimately reduce confusion although I
admit initially it may make things worse.

I would like to see DPU-550 Lite called DPU-05 and DPU-550 called DPU-10.

I would also like the DRO-550 Lite called a DRO-355 and the DRO-550 called
DRO-360.

Note that the DPU number added to 350 gives us the new DRO name. The logic
here is that we are taking the DRO-350 and adding the DPU. When the DRO is
recast into a new design, we should bump the first digit and can call it a
member of the DRO-4xx series.

Also note that if I talk about, say, a 355 there can't be any ambiguity
since only the DRO has this number. If I talk about the 550 it could be the
DPU Lite, Full, or DRO.

I think I follow what you have done in monitoring for scale data errors plus
how you tested it.

I have new data on my limit/beeper problem: [my conclusion: the problem
is in the Z scale and not the DRO channel]

1. with the board separate from the case so cables are not compressed, I was
not able to get the beeper problem to surface after waiting about 10 minutes

2. with X and Y > limit, Z at 0, and the board mounted in the case (but the
shell of the case off), I was able to get a beep within 3 minutes. The
shortest I waited was 30 seconds

3. swapped the Y and Z cables but kept X and Y > limit and Z at 0. Did not
hear beeper go off after waiting about 10 minutes

4. changed to X and Z > limit but Y at 0 (remember that the Z scale is now
feeding the Y channel) and got beeps within 3 minutes

5. recall that all scale signals at the board connectors looked the same so
I do not think this is primarily a signal integrity matter although maybe
item #1 above says it is contributing. I think this slider is just sending
out some bad data periodically. It does not cause the display to noticeably
change so the burst must be short.

I have not yet changed the filter value but hope to do that tomorrow.

[Bruce Fairman]

Rick, i meant this group (http://groups.google.com/group/opendro-users-group/files?hl=en
) in the files section.
sorry if i was not clear.
bruce

KE6OKC