Waveform documentation

I usually build a document that describes the hardware,
nominal voltages, waveforms, timing relationships, etc.
Plus, captured waveforms under different operating conditions
(along with those expected during specific diagnostics)

I'm getting some pushback to move these onto the schematics,
directly, instead of in a supplementary document.

I'm not keen on this as it means schematics have to make room
to accommodate these annotations.  And, I can't see how to
maintain such a document if light of potential changes to
diagnostics (which may be numerous for a given circuit).

Any folks preparing comparable documentation have suggestions?

On Sun, 26 Jun 2022 11:11:28 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>I usually build a document that describes the hardware,
>nominal voltages, waveforms, timing relationships, etc.
>Plus, captured waveforms under different operating conditions
>(along with those expected during specific diagnostics)
>
>I'm getting some pushback to move these onto the schematics,
>directly, instead of in a supplementary document.
>
>I'm not keen on this as it means schematics have to make room
>to accommodate these annotations.  And, I can't see how to
>maintain such a document if light of potential changes to
>diagnostics (which may be numerous for a given circuit).
>
>Any folks preparing comparable documentation have suggestions?

We keep a separate design notes folder, that has a lot more than could
fit on a schamatic. Personally, I don't like to clutter a schematic
with notes. Maybe a very few strategic ones.

If I have a rail named +60V, but it is typically 57 or something, I
might add a small note so test people don't get upset. Maybe note a
clock frequency in discreet small text.

We do have a block diagram and a table of contents on sheet 1, and
assign a name to each sheet.

Before we release a schematic, we do a cosmetic cleanup and delete any
layout notes or such.

https://www.dropbox.com/s/sd73vlfs7bzen2o/23S901A.pdf?dl=0

Don Y wrote:
> I usually build a document that describes the hardware,
> nominal voltages, waveforms, timing relationships, etc.
> Plus, captured waveforms under different operating conditions
> (along with those expected during specific diagnostics)
>
> I'm getting some pushback to move these onto the schematics,
> directly, instead of in a supplementary document.
>
> I'm not keen on this as it means schematics have to make room
> to accommodate these annotations.  And, I can't see how to
> maintain such a document if light of potential changes to
> diagnostics (which may be numerous for a given circuit).
>
> Any folks preparing comparable documentation have suggestions?

Here's how Sams did it back in the day:

https://crcomp.net/misc/sams.pdf

Each of the black rectangles is an oscilloscope trace. The dimensional
captions on the right side of each rectangle are easier to read off the
original document. The captions say things such as 1.2 V over HORIZ.

Sams' obvious motivation to include traces was to enable servicemen to 
fix TVs as fast as possible.

kicad enables users to insert images into a schematic. kicad, in other
words, can create Sams styled schematics.

Danke,

-- 
Don, KB7RPU, https://www.qsl.net/kb7rpu
There was a young lady named Bright Whose speed was far faster than light;
She set out one day In a relative way And returned on the previous night.

On 6/26/2022 12:35 PM, Don wrote:
> Don Y wrote:
>> I usually build a document that describes the hardware,
>> nominal voltages, waveforms, timing relationships, etc.
>> Plus, captured waveforms under different operating conditions
>> (along with those expected during specific diagnostics)
>>
>> I'm getting some pushback to move these onto the schematics,
>> directly, instead of in a supplementary document.
>>
>> I'm not keen on this as it means schematics have to make room
>> to accommodate these annotations.  And, I can't see how to
>> maintain such a document if light of potential changes to
>> diagnostics (which may be numerous for a given circuit).
>>
>> Any folks preparing comparable documentation have suggestions?
> 
> Here's how Sams did it back in the day:
> 
> https://crcomp.net/misc/sams.pdf
> 
> Each of the black rectangles is an oscilloscope trace. The dimensional
> captions on the right side of each rectangle are easier to read off the
> original document. The captions say things such as 1.2 V over HORIZ.
> 
> Sams' obvious motivation to include traces was to enable servicemen to
> fix TVs as fast as possible.
> 
> kicad enables users to insert images into a schematic. kicad, in other
> words, can create Sams styled schematics.

But, TV's have dedicated functionality; you can say "hook color bar generator
to input and these are the waveforms you will see".  There's nothing comparable
to hardware-software codesign, involved (where the waveform is largely
controlled by the software and, thus, can be revised without altering the
board artwork/PL).

And, TV's don't tend to have any "sequencing" involved in their operation
(do you show the waveforms AS channels are being changed?).  By contrast,
the sorts of things I (and many others) design inherently involve time
dependencies for their proper operation (e.g., my power supplies use
a combination of hardware signalling and out-of-band control messages
to determine current limits, overload, sleep, etc.)

I don't see the appeal of tying the two types of information together
in one document -- it just saves (and RESTRICTS) having another document(s)
on hand during test.  If you had several different test procedures that
could be invoked, you'd have to clutter the schematic with screenshots of
the waveforms of *each* (or, here's a thought:  move them into another
document!  :> )

[I've seen schematics in which snippets of every previous revision were
included in the document (in some "unused" whitespace).  What does this
afford anyone -- save the need to pull the schematic revision applicable
to the board revision in front of you?!  This sort of thing seems more
associated with one-man shops that grew up into businesses; wanting to
economize on documentation costs while small and never "maturing"!]

Don Y wrote:
> Don wrote:
>> Don Y wrote:
>>> I usually build a document that describes the hardware,
>>> nominal voltages, waveforms, timing relationships, etc.
>>> Plus, captured waveforms under different operating conditions
>>> (along with those expected during specific diagnostics)
>>>
>>> I'm getting some pushback to move these onto the schematics,
>>> directly, instead of in a supplementary document.
>>>
>>> I'm not keen on this as it means schematics have to make room
>>> to accommodate these annotations.  And, I can't see how to
>>> maintain such a document if light of potential changes to
>>> diagnostics (which may be numerous for a given circuit).
>>>
>>> Any folks preparing comparable documentation have suggestions?
>>
>> Here's how Sams did it back in the day:
>>
>> https://crcomp.net/misc/sams.pdf
>>
>> Each of the black rectangles is an oscilloscope trace. The dimensional
>> captions on the right side of each rectangle are easier to read off the
>> original document. The captions say things such as 1.2 V over HORIZ.
>>
>> Sams' obvious motivation to include traces was to enable servicemen to
>> fix TVs as fast as possible.
>>
>> kicad enables users to insert images into a schematic. kicad, in other
>> words, can create Sams styled schematics.
>
> But, TV's have dedicated functionality; you can say "hook color bar generator
> to input and these are the waveforms you will see".  There's nothing comparable
> to hardware-software codesign, involved (where the waveform is largely
> controlled by the software and, thus, can be revised without altering the
> board artwork/PL).
>
> And, TV's don't tend to have any "sequencing" involved in their operation
> (do you show the waveforms AS channels are being changed?).  By contrast,
> the sorts of things I (and many others) design inherently involve time
> dependencies for their proper operation (e.g., my power supplies use
> a combination of hardware signalling and out-of-band control messages
> to determine current limits, overload, sleep, etc.)
>
> I don't see the appeal of tying the two types of information together
> in one document -- it just saves (and RESTRICTS) having another document(s)
> on hand during test.  If you had several different test procedures that
> could be invoked, you'd have to clutter the schematic with screenshots of
> the waveforms of *each* (or, here's a thought:  move them into another
> document!  :> )
>
> [I've seen schematics in which snippets of every previous revision were
> included in the document (in some "unused" whitespace).  What does this
> afford anyone -- save the need to pull the schematic revision applicable
> to the board revision in front of you?!  This sort of thing seems more
> associated with one-man shops that grew up into businesses; wanting to
> economize on documentation costs while small and never "maturing"!]

You find pack rats everywhere - even at too big organizations. And, as 
always, people believe whatever they choose to believe and act 
accordingly.

Anyhow, the old Sams schematic linked above fired up /my/ imagination.
My mind now cogitates on a circuit challenge. How to seamlessly combine
this code:

  iicWrite(iiccmd);     /* RS=Instruction; RW=Write; */
  nSleep (40L);         /* Wait 40 ns */
  iicWrite(0x24);       /* E; DB5=Function Set; DB4=4-bit */
  nSleep (230L);        /* Wait 230 ns */
  iicWrite(0x20);       /* !E; DB5=Function Set; DB4=4-bit */
  nSleep (270L);        /* Wait 270 ns */
 
with this timing diagram:

  https://crcomp.net/iic44780/timing.png


Danke,

-- 
Don, KB7RPU, https://www.qsl.net/kb7rpu
There was a young lady named Bright Whose speed was far faster than light;
She set out one day In a relative way And returned on the previous night.

Don Y <blockedofcourse@foo.invalid> Wrote in message:r
> I usually build a document that describes the hardware,nominal voltages, waveforms, timing relationships, etc.Plus, captured waveforms under different operating conditions(along with those expected during specific diagnostics)I'm getting some pushback to move these onto the schematics,directly, instead of in a supplementary document.I'm not keen on this as it means schematics have to make roomto accommodate these annotations.  And, I can't see how tomaintain such a document if light of potential changes todiagnostics (which may be numerous for a given circuit).Any folks preparing comparable documentation have suggestions?

I would imagine a separate service manual would apply.

Cheers
-- 


----Android NewsGroup Reader----
https://piaohong.s3-us-west-2.amazonaws.com/usenet/index.html

On Mon, 27 Jun 2022 14:27:07 -0400 (EDT), Martin Rid
<martin_riddle@verison.net> wrote:

>Don Y <blockedofcourse@foo.invalid> Wrote in message:r
>> I usually build a document that describes the hardware,nominal voltages, waveforms, timing relationships, etc.Plus, captured waveforms under different operating conditions(along with those expected during specific diagnostics)I'm getting some pushback to move these onto the schematics,directly, instead of in a supplementary document.I'm not keen on this as it means schematics have to make roomto accommodate these annotations.  And, I can't see how tomaintain such a document if light of potential changes todiagnostics (which may be numerous for a given circuit).Any folks preparing comparable documentation have suggestions?
>
>I would imagine a separate service manual would apply.
>
>Cheers

Does anyone still do that?

-- 

If a man will begin with certainties, he shall end with doubts, 
but if he will be content to begin with doubts he shall end in certainties.
Francis Bacon

On 6/27/2022 10:05 AM, Don wrote:
> Don Y wrote:

>> [I've seen schematics in which snippets of every previous revision were
>> included in the document (in some "unused" whitespace).  What does this
>> afford anyone -- save the need to pull the schematic revision applicable
>> to the board revision in front of you?!  This sort of thing seems more
>> associated with one-man shops that grew up into businesses; wanting to
>> economize on documentation costs while small and never "maturing"!]
> 
> You find pack rats everywhere - even at too big organizations. And, as
> always, people believe whatever they choose to believe and act
> accordingly.

Larger organizations suffer from inertial.. But, also have more opportunities
for "smarter eyes" to look at the way things are being done.  Small firms
often use "re$ource$" as an excuse to convince themselves that there is no
need to change... NOW (maybe later -- yeah, sure!)

> Anyhow, the old Sams schematic linked above fired up /my/ imagination.
> My mind now cogitates on a circuit challenge. How to seamlessly combine
> this code:
> 
>    iicWrite(iiccmd);     /* RS=Instruction; RW=Write; */
>    nSleep (40L);         /* Wait 40 ns */
>    iicWrite(0x24);       /* E; DB5=Function Set; DB4=4-bit */
>    nSleep (230L);        /* Wait 230 ns */
>    iicWrite(0x20);       /* !E; DB5=Function Set; DB4=4-bit */
>    nSleep (270L);        /* Wait 270 ns */
>   
> with this timing diagram:
> 
>    https://crcomp.net/iic44780/timing.png

First, I'd express the code in more symbolic form.  E.g., without
investing much time to understand the unnamed component referenced,
here (just guessing at the binding of value to symbols in diagram):

// times in ns
#define Tac (40)            // setup
#define PWeh (230)          // width of E high
#define Tah (270)           // address hold

#define E_CYCLE (0x20)      // assert E
#define BITS_4  (0x04)      // 4 bit datum
#define E_CYCLE_4_BIT (E_CYCLE | BITS_4)

    // send instruction opcode ("address")
    iicWrite(iiccmd);
    nSleep ((long) Tac);

    iicWrite(E_CYCLE_4_BIT);    // assert E for 4 bit cycle
    nSleep ((long) PWeh);
    iicWrite(E_CYCLE_4_BIT & ~E_CYCLE);  // release E

    nSleep ((long) Tah);

I would pull this into a prose document that can exploit multimedia
in its explanation of "why" things are done this way.

N.B. You might be interested in "WaveDrom"

On 6/27/2022 11:27 AM, Martin Rid wrote:
> Don Y <blockedofcourse@foo.invalid> Wrote in message:r
>> I usually build a document that describes the hardware,nominal voltages,
>> waveforms, timing relationships, etc.Plus, captured waveforms under
>> different operating conditions(along with those expected during specific
>> diagnostics)I'm getting some pushback to move these onto the
>> schematics,directly, instead of in a supplementary document.I'm not keen
>> on this as it means schematics have to make roomto accommodate these
>> annotations.  And, I can't see how tomaintain such a document if light of
>> potential changes todiagnostics (which may be numerous for a given
>> circuit).Any folks preparing comparable documentation have suggestions?
> 
> I would imagine a separate service manual would apply.

In my case, these are "manufacturing documents"; information that
the folks in final test (or depot repair) would consult to verify
proper operation and/or isolate faults.

But, that would inevitably have lots of "accompanying text" that
would be essential to put the "drawings" in context:  "Do *this*
and expect to see *that* on some particular circuit node"

John Larkin <jlarkin@highland_atwork_technology.com> Wrote in message:r
> On Mon, 27 Jun 2022 14:27:07 -0400 (EDT), Martin Rid<martin_riddle@verison.net> wrote:>Don Y <blockedofcourse@foo.invalid> Wrote in message:r>> I usually build a document that describes the hardware,nominal voltages, waveforms, timing relationships, etc.Plus, captured waveforms under different operating conditions(along with those expected during specific diagnostics)I'm getting some pushback to move these onto the schematics,directly, instead of in a supplementary document.I'm not keen on this as it means schematics have to make roomto accommodate these annotations.  And, I can't see how tomaintain such a document if light of potential changes todiagnostics (which may be numerous for a given circuit).Any folks preparing comparable documentation have suggestions?>>I would imagine a separate service manual would apply.>>CheersDoes anyone still do that?-- If a man will begin with certainties, he shall end with doubts, but if he will be content to begin with doubts he shall end in certainties.Francis Bacon

Medical  equipment. 

Cheers
-- 


----Android NewsGroup Reader----
https://piaohong.s3-us-west-2.amazonaws.com/usenet/index.html