OpenDRO is not very open
opendroUG
see the following email from sourceforge for your amusement.
since i am not really on the shumatech group, i thought that the
opendro project would be a public place to bring up issues with the
software. so, i added an artifact in tracker pointing out that the
current scale auto detect using timestamps captured at the isr level
was a problem and i even proposed a fix. Shumate replied with his
usual attitude, and closed the request. so, i did another request,
pointing out further items. no reply, then the tracker access is made
private and all of my input deleted. the poor suckers who are going to
try and work with Shumate on the opendro are in for some bumpy times.
so, only the anointed few can send in bugs and problems, not the
general users. not very open.
--Thanks,
bruce
KE6OKC
Support Requests item #2981848, was opened at 2010-04-04 12:32
Message generated for change (Settings changed) made by shumatech
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=941595&aid=2981848&group_id=192488
Please note that this message will contain a full copy of the comment
thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Deleted
Priority: 5
Private: No
Submitted By: bruce fairman (brucefairman)
Assigned to: Nobody/Anonymous (nobody)
Summary: scale time stamp problem
Initial Comment:
the scale incoming data time stamp is set by the scale isr. the scale
isr is fed by a FIFO that is loaded by the FQ interrupt handler. this
method of timestamping is not correct since the FIFO may accumulate
samples during times that the scale isr is unable to run. so, the
scale isr timestamp will reflect the time that the isr sees the
sample, not the time the sample was received (the transmitter's timing
is more accurately reflected at the FIQ).
proposal: the FIQ handler sets the timestamp in the FIFO for each
sample. the scale ISR uses this timestamp to determine the scale's
timing and thus the scale's type.
----------------------------------------------------------------------
Comment By: ShumaTech (shumatech)
Date: 2010-04-04 13:38
Message:
The timestamp is only used for error detection while decoding the
Chinese
scales and its necessary accuracy is on the order of a few
milliseconds,
which is an eternity with respect to the scale task's priority in the
interrupt controller. Worst-case observed jitter in the timestamp is
on
the order of a few microseconds. For arguments sake, even if the
timestamp
is violated based on high FIFO latency, the worst thing that will
happen is
that a Chinese scale reading is discarded which is a non-issue since
it is
an absolute scale and the reading will be sent again later. This
actually
is a good thing since if the FIFO has high latency, then the system
has
gotten very busy for some unusual reason and discarding a Chinese
scale
reading helps alleviate the congested condition by lessening the work
load,
Putting additional logic in the FIQ interrupt is a very bad idea
because it
is designed to operate as fast as possible to avoid missing quadrature
signals which, if missed, do mean an incorrect reading is permanently
shown. The software was designed very specifically for this
condition.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=941595&aid=2981848&group_id=192488
========================================================================
Support Requests item #2982152, was opened at 2010-04-05 11:40
Message generated for change (Settings changed) made by shumatech
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=941595&aid=2982152&group_id=192488
Please note that this message will contain a full copy of the comment
thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Priority: 5
Private: No
Submitted By: bruce fairman (brucefairman)
Assigned to: Nobody/Anonymous (nobody)
Summary: scale time stamp problem, continued
Initial Comment:
the previous request was closed without resolution. your response was
that the problem identified was addressed by the scales which use the
timestamp as a scale type detection mechanism would simply discard a
received frame and that this is not a problem for absolute devices
since a subsequent frame would be successfully received. in looking at
the scale_24bit routine, the frame error counter is incremented when a
timestamp delta exceeds SCALE_BIT_TIMEOUT (10000usec) and the current
sample is not in the frame (bit 49 or 50). this count is only reset
when it exceeds AUTO_FAIL_THRESH and set_scale_active() has switched
the scale's type autonomously.
this implies that a busy period can cause a valid scale type to change
without the user doing anything. this is not a good behavior.
further, is the bit to bit time test really an adequate test for a
scale type? the frame decoder does not verify the received bit timing
for the bits in a frame. it counts clock transitions from a bit
timeout. the 48th bit causes the received value to be latched in the
scale's data structure. of course, one could argue that the absolute
nature of the chinese scales means that erroneous data will not
persist on the display long enough to matter. however, the use of
scale data from the dro for CNC purposes means this argument is
problematic.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=941595&aid=2982152&group_id=192488