• Error correction in short packet.

    From Clive Arthur@21:1/5 to All on Wed May 18 16:54:32 2022
    Hi all

    I have serial data in 14 byte packets on which I'd like to detect and
    correct errors. Two bit errors would be nice. I can put 2 extra EDC
    bytes on the end to make a 16 byte packet.

    I don't have the resources for Reed-Solomon. I could use a 16 bit CRC,
    these are easy to generate with a small/moderate LUT.

    In the past, I've used a CRC16 for single bit error detection and
    correction on a longer packet, but I didn't do the error detection part.
    Errors were very rare, time was not critical, and I understand that
    this was simply done by changing each message bit in turn then
    recalculating the CRC till it all worked out. That's far to slow for my current needs.

    If I'm lucky, a 16 bit CRC might be able to detect and correct 2 bit
    errors in 14 bytes (112 * 111 possibilities?), but is there a way of
    quickly finding out which bits are wrong?

    Or maybe a completely different approach? This has to be done on the
    fly, and multi-kilobyte LUTs or thousands of clock cycles are out of the question.

    --
    Cheers
    Clive

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Wed May 18 09:40:14 2022
    onsdag den 18. maj 2022 kl. 18.32.15 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Wed, 18 May 2022 16:54:32 +0100, Clive Arthur
    <cl...@nowaytoday.co.uk> wrote:

    Hi all

    I have serial data in 14 byte packets on which I'd like to detect and >correct errors. Two bit errors would be nice. I can put 2 extra EDC
    bytes on the end to make a 16 byte packet.

    I don't have the resources for Reed-Solomon. I could use a 16 bit CRC, >these are easy to generate with a small/moderate LUT.

    In the past, I've used a CRC16 for single bit error detection and >correction on a longer packet, but I didn't do the error detection part.
    Errors were very rare, time was not critical, and I understand that
    this was simply done by changing each message bit in turn then >recalculating the CRC till it all worked out. That's far to slow for my >current needs.

    If I'm lucky, a 16 bit CRC might be able to detect and correct 2 bit
    errors in 14 bytes (112 * 111 possibilities?), but is there a way of >quickly finding out which bits are wrong?

    Or maybe a completely different approach? This has to be done on the
    fly, and multi-kilobyte LUTs or thousands of clock cycles are out of the >question.
    Send it three times and compare.
    but then you need three times the bandwidth which may not be an option

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to clive@nowaytoday.co.uk on Wed May 18 09:32:05 2022
    On Wed, 18 May 2022 16:54:32 +0100, Clive Arthur
    <clive@nowaytoday.co.uk> wrote:

    Hi all

    I have serial data in 14 byte packets on which I'd like to detect and
    correct errors. Two bit errors would be nice. I can put 2 extra EDC
    bytes on the end to make a 16 byte packet.

    I don't have the resources for Reed-Solomon. I could use a 16 bit CRC,
    these are easy to generate with a small/moderate LUT.

    In the past, I've used a CRC16 for single bit error detection and
    correction on a longer packet, but I didn't do the error detection part.
    Errors were very rare, time was not critical, and I understand that
    this was simply done by changing each message bit in turn then
    recalculating the CRC till it all worked out. That's far to slow for my >current needs.

    If I'm lucky, a 16 bit CRC might be able to detect and correct 2 bit
    errors in 14 bytes (112 * 111 possibilities?), but is there a way of
    quickly finding out which bits are wrong?

    Or maybe a completely different approach? This has to be done on the
    fly, and multi-kilobyte LUTs or thousands of clock cycles are out of the >question.


    Send it three times and compare.



    --

    Anybody can count to one.

    - Robert Widlar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to jrwalliker@gmail.com on Wed May 18 12:07:30 2022
    On Wed, 18 May 2022 11:20:33 -0700 (PDT), John Walliker
    <jrwalliker@gmail.com> wrote:

    On Wednesday, 18 May 2022 at 17:40:22 UTC+1, lang...@fonz.dk wrote:
    onsdag den 18. maj 2022 kl. 18.32.15 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Wed, 18 May 2022 16:54:32 +0100, Clive Arthur
    <cl...@nowaytoday.co.uk> wrote:

    Hi all

    I have serial data in 14 byte packets on which I'd like to detect and
    correct errors. Two bit errors would be nice. I can put 2 extra EDC
    bytes on the end to make a 16 byte packet.

    I don't have the resources for Reed-Solomon. I could use a 16 bit CRC,
    these are easy to generate with a small/moderate LUT.

    In the past, I've used a CRC16 for single bit error detection and
    correction on a longer packet, but I didn't do the error detection part. >> > > Errors were very rare, time was not critical, and I understand that
    this was simply done by changing each message bit in turn then
    recalculating the CRC till it all worked out. That's far to slow for my >> > >current needs.

    If I'm lucky, a 16 bit CRC might be able to detect and correct 2 bit
    errors in 14 bytes (112 * 111 possibilities?), but is there a way of
    quickly finding out which bits are wrong?

    Or maybe a completely different approach? This has to be done on the
    fly, and multi-kilobyte LUTs or thousands of clock cycles are out of the >> > >question.
    Send it three times and compare.
    but then you need three times the bandwidth which may not be an option

    It may not be, but bandwidth is much cheaper than it used to be. I have some >international VPN links subject to fairly severe packet loss. Every packet >is sent four times by different routes and the first one to arrive intact gets >passed on and the others are discarded (if they ever arrive). This all works >very nicely at tens of Mbit/s. The improvement in performance is much
    more than a factor of four when packet loss is severe and the waste is only a >factor of four when there is no packet loss.

    One could send three copies of the packet and majority-vote each bit.

    --

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Walliker@21:1/5 to lang...@fonz.dk on Wed May 18 11:20:33 2022
    On Wednesday, 18 May 2022 at 17:40:22 UTC+1, lang...@fonz.dk wrote:
    onsdag den 18. maj 2022 kl. 18.32.15 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Wed, 18 May 2022 16:54:32 +0100, Clive Arthur
    <cl...@nowaytoday.co.uk> wrote:

    Hi all

    I have serial data in 14 byte packets on which I'd like to detect and >correct errors. Two bit errors would be nice. I can put 2 extra EDC
    bytes on the end to make a 16 byte packet.

    I don't have the resources for Reed-Solomon. I could use a 16 bit CRC, >these are easy to generate with a small/moderate LUT.

    In the past, I've used a CRC16 for single bit error detection and >correction on a longer packet, but I didn't do the error detection part.
    Errors were very rare, time was not critical, and I understand that
    this was simply done by changing each message bit in turn then >recalculating the CRC till it all worked out. That's far to slow for my >current needs.

    If I'm lucky, a 16 bit CRC might be able to detect and correct 2 bit >errors in 14 bytes (112 * 111 possibilities?), but is there a way of >quickly finding out which bits are wrong?

    Or maybe a completely different approach? This has to be done on the
    fly, and multi-kilobyte LUTs or thousands of clock cycles are out of the >question.
    Send it three times and compare.
    but then you need three times the bandwidth which may not be an option

    It may not be, but bandwidth is much cheaper than it used to be. I have some international VPN links subject to fairly severe packet loss. Every packet
    is sent four times by different routes and the first one to arrive intact gets passed on and the others are discarded (if they ever arrive). This all works very nicely at tens of Mbit/s. The improvement in performance is much
    more than a factor of four when packet loss is severe and the waste is only a factor of four when there is no packet loss.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Rid@21:1/5 to Clive Arthur on Wed May 18 14:29:57 2022
    Clive Arthur <clive@nowaytoday.co.uk> Wrote in message:r
    Hi allI have serial data in 14 byte packets on which I'd like to detect and correct errors. Two bit errors would be nice. I can put 2 extra EDC bytes on the end to make a 16 byte packet.I don't have the resources for Reed-Solomon. I could use a 16
    bit CRC, these are easy to generate with a small/moderate LUT.In the past, I've used a CRC16 for single bit error detection and correction on a longer packet, but I didn't do the error detection part. Errors were very rare, time was not critical, and I
    understand that this was simply done by changing each message bit in turn then recalculating the CRC till it all worked out. That's far to slow for my current needs.If I'm lucky, a 16 bit CRC might be able to detect and correct 2 bit errors in 14 bytes (
    112 * 111 possibilities?), but is there a way of quickly finding out which bits are wrong?Or maybe a completely different approach? This has to be done on the fly, and multi-kilobyte LUTs or thousands of clock cycles are out of the question.-- CheersClive

    Well Reed-Solomon would do what you want. Problem is the crc can
    not fix the errors.

    Cheers
    --


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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gerhard Hoffmann@21:1/5 to All on Wed May 18 22:02:23 2022
    Am 18.05.22 um 20:20 schrieb John Walliker:

    It may not be, but bandwidth is much cheaper than it used to be. I have some international VPN links subject to fairly severe packet loss. Every packet is sent four times by different routes and the first one to arrive intact gets
    passed on and the others are discarded (if they ever arrive). This all works very nicely at tens of Mbit/s. The improvement in performance is much
    more than a factor of four when packet loss is severe and the waste is only a factor of four when there is no packet loss.

    That works as long as there is a lot of channel capacity and as
    long as at least some packets get though without error.

    When barely a packet gets through without error, then it's time
    for forward error correction. That is, sending it once with
    enough redundancy.

    cheers, Gerhard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Clive Arthur on Wed May 18 14:17:26 2022
    On 5/18/2022 8:54 AM, Clive Arthur wrote:
    I have serial data in 14 byte packets on which I'd like to detect and correct errors. Two bit errors would be nice. I can put 2 extra EDC bytes on the end
    to make a 16 byte packet.

    Do you know the *nature* of the interference that is (potentially) corrupting your transmission? Is it periodic? Burst-y? Or, does each bit-time have
    an equal AND INDEPENDANT probability of encountering an error?

    E.g., does one error event have any effect on the next bit datum?

    (Wombats!)

    I don't have the resources for Reed-Solomon. I could use a 16 bit CRC, these are easy to generate with a small/moderate LUT.

    As you are receiving the bit STREAM serially, compute the checksum/syndrome similarly. Presumably you have enough storage (14 bytes) to hold an entire completed message; a "correction cycle" (some number of clocks) can then
    toggle the appropriate bits in the accumulator.

    In the past, I've used a CRC16 for single bit error detection and correction on
    a longer packet, but I didn't do the error detection part. Errors were very rare, time was not critical, and I understand that this was simply done by changing each message bit in turn then recalculating the CRC till it all worked
    out. That's far to slow for my current needs.

    If I'm lucky, a 16 bit CRC might be able to detect and correct 2 bit errors in
    14 bytes (112 * 111 possibilities?), but is there a way of quickly finding out
    which bits are wrong?

    Or maybe a completely different approach? This has to be done on the fly, and multi-kilobyte LUTs or thousands of clock cycles are out of the question.

    I worked on a project where the previous developer naively tried to improve data integrity by storing three copies of a 16-byte quantity -- and hoping to "compare them" to determine what the CORRECT value should be.

    Of course, this only works as good as simple bit-wise parity (in general)
    as two errors can conspire to convince you that THEY reflect the correct
    value:
    xxxxxxx1xxxxxxxx
    yyyyyyy1yyyyyyyy
    zzzzzzz0zzzzzzzz
    in which each of the x, y and z represent correct values, in agreement with
    the redundant copies. The third value being correct, the previous two reflecting single bit errors in each.

    Conclusion:
    -------1--------
    I.e., you can't correct *any* errors (of a certain type). You've wasted lots of "check digits" (in this case, 256 bits of check digits on a 128 bit value!) with little to show for it!

    I'm wondering if you could just compute two *different* syndromes (i.e., two different polynomials) over the same data and treat it as two single-bit correcting codes. In which case, about 2 bytes of check digit overhead.
    (112 bits is ~7b, +1 for parity yields 8 -- for each possible check digit)

    But, I've not yet had my breakfast...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to Lasse Langwadt Christensen on Wed May 18 22:42:28 2022
    On 18/05/2022 17:40, Lasse Langwadt Christensen wrote:
    onsdag den 18. maj 2022 kl. 18.32.15 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Wed, 18 May 2022 16:54:32 +0100, Clive Arthur
    <cl...@nowaytoday.co.uk> wrote:

    Hi all

    I have serial data in 14 byte packets on which I'd like to detect and
    correct errors. Two bit errors would be nice. I can put 2 extra EDC
    bytes on the end to make a 16 byte packet.

    You don't have space to even reliably detect single bit errors without
    making assumptions about the error rate (or hoping that it is only ever
    a single bit error and enumerating every possibility).

    Sending 256 bits of data with 16 of them for error checking in a perfect
    world would allow you to decode the location of that single bit error.

    I don't have the resources for Reed-Solomon. I could use a 16 bit CRC,
    these are easy to generate with a small/moderate LUT.

    In the past, I've used a CRC16 for single bit error detection and
    correction on a longer packet, but I didn't do the error detection part. >>> Errors were very rare, time was not critical, and I understand that
    this was simply done by changing each message bit in turn then
    recalculating the CRC till it all worked out. That's far to slow for my
    current needs.

    If I'm lucky, a 16 bit CRC might be able to detect and correct 2 bit
    errors in 14 bytes (112 * 111 possibilities?), but is there a way of
    quickly finding out which bits are wrong?

    Or maybe a completely different approach? This has to be done on the
    fly, and multi-kilobyte LUTs or thousands of clock cycles are out of the >>> question.
    Send it three times and compare.
    but then you need three times the bandwidth which may not be an option

    When I have needed to do that (and a very long time ago) we used a
    Hamming code 7,4 to deal with a somewhat unreliable punchtape machine
    and a single chance to grab the raw data. Correct any single bit error,
    detect any two bit error. Overhead for the simplest useful one is 100%.

    https://en.wikipedia.org/wiki/Hamming_code#[7,4]_Hamming_code

    The error rate turned out to be low enough that it never actually saw a
    2 bit error in what was about 32kb of data (64k chars on tape). But we
    only discovered that later when it was decoded on the mainframe.

    Hadamard convolutional codes might be a better choice now but the
    overheads are going to be significant in time and code space.

    Space probes use Golay codes these days but you may not have enough
    horsepower for that either. The lookup tables for Hamming might be OK...

    --
    Regards,
    Martin Brown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Eather@21:1/5 to jlarkin@highlandsniptechnology.com on Thu May 19 08:06:25 2022
    On 19/05/2022 2:32 am, jlarkin@highlandsniptechnology.com wrote:
    On Wed, 18 May 2022 16:54:32 +0100, Clive Arthur
    <clive@nowaytoday.co.uk> wrote:

    Hi all

    I have serial data in 14 byte packets on which I'd like to detect and
    correct errors. Two bit errors would be nice. I can put 2 extra EDC
    bytes on the end to make a 16 byte packet.

    I don't have the resources for Reed-Solomon. I could use a 16 bit CRC,
    these are easy to generate with a small/moderate LUT.

    In the past, I've used a CRC16 for single bit error detection and
    correction on a longer packet, but I didn't do the error detection part.
    Errors were very rare, time was not critical, and I understand that
    this was simply done by changing each message bit in turn then
    recalculating the CRC till it all worked out. That's far to slow for my
    current needs.

    If I'm lucky, a 16 bit CRC might be able to detect and correct 2 bit
    errors in 14 bytes (112 * 111 possibilities?), but is there a way of
    quickly finding out which bits are wrong?

    Or maybe a completely different approach? This has to be done on the
    fly, and multi-kilobyte LUTs or thousands of clock cycles are out of the
    question.


    Send it three times and compare.





    you didn't read the 2 byte limit he said he had? The answer is it can't
    be done with the constraints he has specified.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to eatREMOVEher@tpg.com.au on Wed May 18 15:46:23 2022
    On Thu, 19 May 2022 08:06:25 +1000, David Eather
    <eatREMOVEher@tpg.com.au> wrote:

    On 19/05/2022 2:32 am, jlarkin@highlandsniptechnology.com wrote:
    On Wed, 18 May 2022 16:54:32 +0100, Clive Arthur
    <clive@nowaytoday.co.uk> wrote:

    Hi all

    I have serial data in 14 byte packets on which I'd like to detect and
    correct errors. Two bit errors would be nice. I can put 2 extra EDC
    bytes on the end to make a 16 byte packet.

    I don't have the resources for Reed-Solomon. I could use a 16 bit CRC,
    these are easy to generate with a small/moderate LUT.

    In the past, I've used a CRC16 for single bit error detection and
    correction on a longer packet, but I didn't do the error detection part. >>> Errors were very rare, time was not critical, and I understand that
    this was simply done by changing each message bit in turn then
    recalculating the CRC till it all worked out. That's far to slow for my >>> current needs.

    If I'm lucky, a 16 bit CRC might be able to detect and correct 2 bit
    errors in 14 bytes (112 * 111 possibilities?), but is there a way of
    quickly finding out which bits are wrong?

    Or maybe a completely different approach? This has to be done on the
    fly, and multi-kilobyte LUTs or thousands of clock cycles are out of the >>> question.


    Send it three times and compare.





    you didn't read the 2 byte limit he said he had? The answer is it can't
    be done with the constraints he has specified.

    He specified a packet length limit, but didn't say he couldn't send it
    multiple times.

    I'm trying to be helpful, you are trying to be obnoxious. Do whatever
    you are best at.

    --

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sylvia Else@21:1/5 to Clive Arthur on Thu May 19 13:27:33 2022
    On 19-May-22 1:54 am, Clive Arthur wrote:
    Hi all

    I have serial data in 14 byte packets on which I'd like to detect and
    correct errors.  Two bit errors would be nice.  I can put 2 extra EDC
    bytes on the end to make a 16 byte packet.

    I don't have the resources for Reed-Solomon.  I could use a 16 bit CRC, these are easy to generate with a small/moderate LUT.

    In the past, I've used a CRC16 for single bit error detection and
    correction on a longer packet, but I didn't do the error detection part.
     Errors were very rare, time was not critical, and I understand that
    this was simply done by changing each message bit in turn then
    recalculating the CRC till it all worked out.  That's far to slow for my current needs.

    If I'm lucky, a 16 bit CRC might be able to detect and correct 2 bit
    errors in 14 bytes (112 * 111 possibilities?), but is there a way of
    quickly finding out which bits are wrong?

    Or maybe a completely different approach? This has to be done on the
    fly, and multi-kilobyte LUTs or thousands of clock cycles are out of the question.


    Even if you had a 16 bit value that told you which two bits were wrong,
    you'd then have to make use of that information to flip the incorrect
    bits. That doesn't sound like small number of LUTs.

    Is your channel really that noisy that you cannot just discard bad packets?

    Sylvia.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From whit3rd@21:1/5 to John Larkin on Wed May 18 22:10:08 2022
    On Wednesday, May 18, 2022 at 12:07:43 PM UTC-7, John Larkin wrote:
    On Wed, 18 May 2022 11:20:33 -0700 (PDT), John Walliker
    <jrwal...@gmail.com> wrote:

    On Wednesday, 18 May 2022 at 17:40:22 UTC+1, lang...@fonz.dk wrote:
    onsdag den 18. maj 2022 kl. 18.32.15 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Wed, 18 May 2022 16:54:32 +0100, Clive Arthur

    I have serial data in 14 byte packets on which I'd like to detect and >> > >correct errors. Two bit errors would be nice.

    Send it three times and compare.

    One could send three copies of the packet and majority-vote each bit.

    Or, send one copy with checksum, then a second copy with checksum, then
    a third copy. Take the first one that has a correct checksum, or... just stick
    with copy 3, you're out of time.

    Majority-vote takes (on average) longer because it always waits for three copies.
    Checksum, one hopes, is more reassuring per extra bit than voting.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to John Larkin on Thu May 19 09:52:10 2022
    On 18/05/2022 23:46, John Larkin wrote:
    On Thu, 19 May 2022 08:06:25 +1000, David Eather
    <eatREMOVEher@tpg.com.au> wrote:

    On 19/05/2022 2:32 am, jlarkin@highlandsniptechnology.com wrote:
    On Wed, 18 May 2022 16:54:32 +0100, Clive Arthur
    <clive@nowaytoday.co.uk> wrote:

    Hi all

    I have serial data in 14 byte packets on which I'd like to detect and
    correct errors. Two bit errors would be nice. I can put 2 extra EDC
    bytes on the end to make a 16 byte packet.

    I don't have the resources for Reed-Solomon. I could use a 16 bit CRC, >>>> these are easy to generate with a small/moderate LUT.

    In the past, I've used a CRC16 for single bit error detection and
    correction on a longer packet, but I didn't do the error detection part. >>>> Errors were very rare, time was not critical, and I understand that >>>> this was simply done by changing each message bit in turn then
    recalculating the CRC till it all worked out. That's far to slow for my >>>> current needs.

    If I'm lucky, a 16 bit CRC might be able to detect and correct 2 bit
    errors in 14 bytes (112 * 111 possibilities?), but is there a way of
    quickly finding out which bits are wrong?

    Or maybe a completely different approach? This has to be done on the
    fly, and multi-kilobyte LUTs or thousands of clock cycles are out of the >>>> question.


    Send it three times and compare.

    What do you do when all three are different?

    you didn't read the 2 byte limit he said he had? The answer is it can't
    be done with the constraints he has specified.

    He specified a packet length limit, but didn't say he couldn't send it multiple times.

    The best bet under his specified constraints is send it with a crc in
    the extra 2 bytes and keep on sending it until you get an ack back from
    the other end that one has decoded OK. Or if you insist on a simple
    voting algorithm until you get two the same. It all depends on the bit
    error rate. If it is low enough then detecting a fail by quick crc and
    sending a "say again" msg back to the sender would be least invasive.

    If the channel is noisy in both directions then it requires a bit more
    thought since the conversation could go on forever at very bad SNR.

    It should be possible to correct any single bit error and detect any
    double bit error in the data stream with just 75% overhead even with a
    simple Hamming code - just under double the size of the raw data.

    Better EC encodings exist but they require more horsepower.

    --
    Regards,
    Martin Brown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Clive Arthur@21:1/5 to Sylvia Else on Thu May 19 09:58:21 2022
    On 19/05/2022 04:27, Sylvia Else wrote:
    On 19-May-22 1:54 am, Clive Arthur wrote:
    Hi all

    I have serial data in 14 byte packets on which I'd like to detect and
    correct errors.  Two bit errors would be nice.  I can put 2 extra EDC
    bytes on the end to make a 16 byte packet.

    I don't have the resources for Reed-Solomon.  I could use a 16 bit
    CRC, these are easy to generate with a small/moderate LUT.

    In the past, I've used a CRC16 for single bit error detection and
    correction on a longer packet, but I didn't do the error detection
    part.   Errors were very rare, time was not critical, and I understand
    that this was simply done by changing each message bit in turn then
    recalculating the CRC till it all worked out.  That's far to slow for
    my current needs.

    If I'm lucky, a 16 bit CRC might be able to detect and correct 2 bit
    errors in 14 bytes (112 * 111 possibilities?), but is there a way of
    quickly finding out which bits are wrong?

    Or maybe a completely different approach? This has to be done on the
    fly, and multi-kilobyte LUTs or thousands of clock cycles are out of
    the question.


    Even if you had a 16 bit value that told you which two bits were wrong,
    you'd then have to make use of that information to flip the incorrect
    bits. That doesn't sound like small number of LUTs.

    Is your channel really that noisy that you cannot just discard bad packets?

    Sylvia.

    I don't have control over the transmission path, it may be noisy, it may
    not - it's not a fixed installation. I want to get the best shot at
    correcting errors within my fixed constraints, even a single bit EDC
    would be useful. I can't request a resend, and sending multiple copies restricts bandwidth too much.

    Of course, there comes a point when it just won't/can't work.

    I do know that a CRC approach is easy to implement from the POV of error detection. I also know that this could detect and correct at least a
    single bit error, but I don't know if there's a quick and easy way of
    finding the bad bit.

    And to be honest, much of the maths associated with EDC is beyond me at
    the moment.

    --
    Cheers
    Clive

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Clive Arthur@21:1/5 to Martin Brown on Thu May 19 10:13:38 2022
    On 19/05/2022 09:52, Martin Brown wrote:

    <snip>

    The best bet under his specified constraints is send it with a crc in
    the extra 2 bytes and keep on sending it until you get an ack back from
    the other end that one has decoded OK. Or if you insist on a simple
    voting algorithm until you get two the same. It all depends on the bit
    error rate. If it is low enough then detecting a fail by quick crc and sending a "say again" msg back to the sender would be least invasive.

    If the channel is noisy in both directions then it requires a bit more thought since the conversation could go on forever at very bad SNR.

    It should be possible to correct any single bit error and detect any
    double bit error in the data stream with just 75% overhead even with a
    simple Hamming code - just under double the size of the raw data.

    I can't resend packets.

    I've looked at 8,4 Hamming codes, easy to implement (and understand!) to correct a single bit error in a data nibble and detect two bit errors.
    It may be the way to go, but it's quite an overhead. Still, with the
    ability to switch it in only when needed it might be an answer if
    nothing better shows up.

    Better EC encodings exist but they require more horsepower.

    Yes 255,223 Reed-Solomon is used elsewhere, but too 'expensive' here.

    --
    Cheers
    Clive

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to Clive Arthur on Thu May 19 10:19:46 2022
    On 19/05/2022 10:13, Clive Arthur wrote:
    On 19/05/2022 09:52, Martin Brown wrote:

    <snip>

    The best bet under his specified constraints is send it with a crc in
    the extra 2 bytes and keep on sending it until you get an ack back
    from the other end that one has decoded OK. Or if you insist on a
    simple voting algorithm until you get two the same. It all depends on
    the bit error rate. If it is low enough then detecting a fail by quick
    crc and sending a "say again" msg back to the sender would be least
    invasive.

    If the channel is noisy in both directions then it requires a bit more
    thought since the conversation could go on forever at very bad SNR.

    It should be possible to correct any single bit error and detect any
    double bit error in the data stream with just 75% overhead even with a
    simple Hamming code - just under double the size of the raw data.

    I can't resend packets.

    What do you do then if you receive a packet with a detected 2 bit error?

    I've looked at 8,4 Hamming codes, easy to implement (and understand!) to correct a single bit error in a data nibble and detect two bit errors.
    It may be the way to go, but it's quite an overhead.  Still, with the ability to switch it in only when needed it might be an answer if
    nothing better shows up.

    I think it is probably your best bet. Hadamard might be another one to
    look at but harder to understand and implement efficiently.

    It will really hinge on how noisy the data channel is. Can you not
    subvert a V90 modem chip at each end and send the data that way?

    --
    Regards,
    Martin Brown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to Clive Arthur on Thu May 19 10:43:54 2022
    On 19/05/2022 09:58, Clive Arthur wrote:
    On 19/05/2022 04:27, Sylvia Else wrote:
    On 19-May-22 1:54 am, Clive Arthur wrote:
    Hi all

    I have serial data in 14 byte packets on which I'd like to detect and
    correct errors.  Two bit errors would be nice.  I can put 2 extra EDC
    bytes on the end to make a 16 byte packet.

    I don't have the resources for Reed-Solomon.  I could use a 16 bit
    CRC, these are easy to generate with a small/moderate LUT.

    In the past, I've used a CRC16 for single bit error detection and
    correction on a longer packet, but I didn't do the error detection
    part.   Errors were very rare, time was not critical, and I
    understand that this was simply done by changing each message bit in
    turn then recalculating the CRC till it all worked out.  That's far
    to slow for my current needs.

    If I'm lucky, a 16 bit CRC might be able to detect and correct 2 bit
    errors in 14 bytes (112 * 111 possibilities?), but is there a way of
    quickly finding out which bits are wrong?

    Or maybe a completely different approach? This has to be done on the
    fly, and multi-kilobyte LUTs or thousands of clock cycles are out of
    the question.


    Even if you had a 16 bit value that told you which two bits were
    wrong, you'd then have to make use of that information to flip the
    incorrect bits. That doesn't sound like small number of LUTs.

    Is your channel really that noisy that you cannot just discard bad
    packets?

    Sylvia.

    I don't have control over the transmission path, it may be noisy, it may
    not - it's not a fixed installation.  I want to get the best shot at correcting errors within my fixed constraints, even a single bit EDC
    would be useful.  I can't request a resend, and sending multiple copies restricts bandwidth too much.

    Of course, there comes a point when it just won't/can't work.

    I do know that a CRC approach is easy to implement from the POV of error detection.  I also know that this could detect and correct at least a
    single bit error, but I don't know if there's a quick and easy way of
    finding the bad bit.

    And to be honest, much of the maths associated with EDC is beyond me at
    the moment.

    I vaguely recall a trick using parity over an orthogonal basis set of
    Walsh functions (much like Hadamard) that could be designed so that the computed signature of the data received gave you the index of the bad
    bit. Described in more detail here.

    https://en.wikipedia.org/wiki/Hamming_code#General_algorithm

    It seems Hamming(127,120) is what you want. Now just a SMOP!
    Or 2x Hamming(63,57) applied to 64 bits (one bit left hanging).

    --
    Regards,
    Martin Brown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Martin Brown on Thu May 19 02:58:00 2022
    On 5/19/2022 1:52 AM, Martin Brown wrote:

    It should be possible to correct any single bit error and detect any double bit
    error in the data stream with just 75% overhead even with a simple Hamming code
    - just under double the size of the raw data.

    It would be wasteful to encode each byte individually -- though it gives greater detection/correction "at the byte level" -- due to the excess overhead it introduces.

    Instead, treat the entire 14-byte message as a 112 bit datum. Add 7 parity bits and you can correct a single bit error in the resulting 119 bit "augmented message". Use the remaining (8th) bit -- assuming the underlying protocol
    is byte-based and not bit-oriented -- and you can detect two errors.

    Better EC encodings exist but they require more horsepower.

    Hamming can be decoded with a polynomial-per-parity-bit (i.e., 8 in this case) all "watching" the same deserializer. The syndrome then "points" to the bit that is in error (if only one) and, as bits are only bivalued, you just have
    to toggle that bit to fix it.

    Detecting a *second* error is where it gets a bit trickier...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Keegan Major@21:1/5 to Clive Arthur on Thu May 19 12:58:33 2022
    Clive Arthur <clive@nowaytoday.co.uk> wrote:
    On 19/05/2022 04:27, Sylvia Else wrote:

    Is your channel really that noisy that you cannot just discard bad
    packets?

    I don't have control over the transmission path, it may be noisy, it
    may not - it's not a fixed installation. [snip...] I can't request a
    resend, and sending multiple copies restricts bandwidth too much.

    Hmm, 17 messages in to the thread, and the group finally is told some
    of the critical unstated requirements that *should* have been part of
    the initial message, and would have avoided about 14 "can't you resend"
    or "can't you send multiple" messages.

    Don't you think this above should have been in your initial post so
    that the rest of us, who can't read your mind to divine unstated
    limitations, were appraised of some rather critical limitations?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Clive Arthur@21:1/5 to Martin Rid on Thu May 19 14:24:40 2022
    On 18/05/2022 19:29, Martin Rid wrote:

    <snip>

    Well Reed-Solomon would do what you want. Problem is the crc can
    not fix the errors.

    Cheers

    CRCs can be used to correct one error provided there's not too much
    data. The brute force method involves changing one bit at a time until
    the CRC is correct; I don't know if there's a quicker way or if more
    errors could be corrected using a suitable CRC.

    --
    Cheers
    Clive

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Thu May 19 07:40:45 2022
    torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major <keegan...@hotmail.com> wrote:

    Clive Arthur <cl...@nowaytoday.co.uk> wrote:
    On 19/05/2022 04:27, Sylvia Else wrote:

    Is your channel really that noisy that you cannot just discard bad
    packets?

    I don't have control over the transmission path, it may be noisy, it
    may not - it's not a fixed installation. [snip...] I can't request a
    resend, and sending multiple copies restricts bandwidth too much.

    Hmm, 17 messages in to the thread, and the group finally is told some
    of the critical unstated requirements that *should* have been part of
    the initial message, and would have avoided about 14 "can't you resend"
    or "can't you send multiple" messages.

    Don't you think this above should have been in your initial post so
    that the rest of us, who can't read your mind to divine unstated >limitations, were appraised of some rather critical limitations?


    It's normal here to get underspecified problems. Details usually
    emerge, but some people do refuse to explain their top-secret
    projects.

    https://xyproblem.info/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to langwadt@fonz.dk on Thu May 19 08:03:46 2022
    On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major
    <keegan...@hotmail.com> wrote:

    Clive Arthur <cl...@nowaytoday.co.uk> wrote:
    On 19/05/2022 04:27, Sylvia Else wrote:

    Is your channel really that noisy that you cannot just discard bad
    packets?

    I don't have control over the transmission path, it may be noisy, it
    may not - it's not a fixed installation. [snip...] I can't request a
    resend, and sending multiple copies restricts bandwidth too much.

    Hmm, 17 messages in to the thread, and the group finally is told some
    of the critical unstated requirements that *should* have been part of
    the initial message, and would have avoided about 14 "can't you resend"
    or "can't you send multiple" messages.

    Don't you think this above should have been in your initial post so
    that the rest of us, who can't read your mind to divine unstated
    limitations, were appraised of some rather critical limitations?


    It's normal here to get underspecified problems. Details usually
    emerge, but some people do refuse to explain their top-secret
    projects.

    https://xyproblem.info/

    Underspecified problems do encourage lots of lateral/goofy thinking.

    Of course, some people are hostile to ideas. Their career path is more McDonalds than electronic design.



    --

    Anybody can count to one.

    - Robert Widlar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to keegan.major@hotmail.com on Thu May 19 07:36:14 2022
    On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major <keegan.major@hotmail.com> wrote:

    Clive Arthur <clive@nowaytoday.co.uk> wrote:
    On 19/05/2022 04:27, Sylvia Else wrote:

    Is your channel really that noisy that you cannot just discard bad
    packets?

    I don't have control over the transmission path, it may be noisy, it
    may not - it's not a fixed installation. [snip...] I can't request a
    resend, and sending multiple copies restricts bandwidth too much.

    Hmm, 17 messages in to the thread, and the group finally is told some
    of the critical unstated requirements that *should* have been part of
    the initial message, and would have avoided about 14 "can't you resend"
    or "can't you send multiple" messages.

    Don't you think this above should have been in your initial post so
    that the rest of us, who can't read your mind to divine unstated
    limitations, were appraised of some rather critical limitations?



    It's normal here to get underspecified problems. Details usually
    emerge, but some people do refuse to explain their top-secret
    projects.



    --

    Anybody can count to one.

    - Robert Widlar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeroen Belleman@21:1/5 to jlarkin@highlandsniptechnology.com on Thu May 19 17:14:02 2022
    On 2022-05-19 17:03, jlarkin@highlandsniptechnology.com wrote:
    On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major
    <keegan...@hotmail.com> wrote:

    Clive Arthur <cl...@nowaytoday.co.uk> wrote:
    On 19/05/2022 04:27, Sylvia Else wrote:

    Is your channel really that noisy that you cannot just discard bad >>>>>> packets?

    I don't have control over the transmission path, it may be noisy, it >>>>> may not - it's not a fixed installation. [snip...] I can't request a >>>>> resend, and sending multiple copies restricts bandwidth too much.

    Hmm, 17 messages in to the thread, and the group finally is told some
    of the critical unstated requirements that *should* have been part of
    the initial message, and would have avoided about 14 "can't you resend" >>>> or "can't you send multiple" messages.

    Don't you think this above should have been in your initial post so
    that the rest of us, who can't read your mind to divine unstated
    limitations, were appraised of some rather critical limitations?


    It's normal here to get underspecified problems. Details usually
    emerge, but some people do refuse to explain their top-secret
    projects.

    https://xyproblem.info/

    Underspecified problems do encourage lots of lateral/goofy thinking.

    Of course, some people are hostile to ideas. Their career path is more McDonalds than electronic design.


    Goofy ideas aren't really welcome if they upset a sizable fraction
    of effort already invested. Ideas are cheap. Realizing them is costly.
    You'll want to be selective.

    Jeroen Belleman

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to jlarkin@highlandsniptechnology.com on Thu May 19 11:48:39 2022
    jlarkin@highlandsniptechnology.com wrote:
    On Thu, 19 May 2022 17:14:02 +0200, Jeroen Belleman
    <jeroen@nospam.please> wrote:

    On 2022-05-19 17:03, jlarkin@highlandsniptechnology.com wrote:
    On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen
    <langwadt@fonz.dk> wrote:

    torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major
    <keegan...@hotmail.com> wrote:

    Clive Arthur <cl...@nowaytoday.co.uk> wrote:
    On 19/05/2022 04:27, Sylvia Else wrote:

    Is your channel really that noisy that you cannot just discard bad >>>>>>>> packets?

    I don't have control over the transmission path, it may be noisy, it >>>>>>> may not - it's not a fixed installation. [snip...] I can't request a >>>>>>> resend, and sending multiple copies restricts bandwidth too much. >>>>>>
    Hmm, 17 messages in to the thread, and the group finally is told some >>>>>> of the critical unstated requirements that *should* have been part of >>>>>> the initial message, and would have avoided about 14 "can't you resend" >>>>>> or "can't you send multiple" messages.

    Don't you think this above should have been in your initial post so >>>>>> that the rest of us, who can't read your mind to divine unstated
    limitations, were appraised of some rather critical limitations?


    It's normal here to get underspecified problems. Details usually
    emerge, but some people do refuse to explain their top-secret
    projects.

    https://xyproblem.info/

    Underspecified problems do encourage lots of lateral/goofy thinking.

    Of course, some people are hostile to ideas. Their career path is more
    McDonalds than electronic design.


    Goofy ideas aren't really welcome if they upset a sizable fraction
    of effort already invested.

    Economists call that the Sunk Cost Fallacy.

    Ideas are cheap. Realizing them is costly.
    You'll want to be selective.

    Sometimes an idea can wipe out a million dollar investment but have a
    shorter path to done. Managers don't like that situation.

    Good ones will laugh and take the short cut (after checking it
    carefully, of course). They'll also listen more carefully to the person
    that came up with it. ;)

    Since the budget will already have been approved, they might continue
    along both paths for a bit, to build confidence in the new approach
    before committing fully to it.

    Cheers

    Phil Hobbs


    --
    Dr Philip C D Hobbs
    Principal Consultant
    ElectroOptical Innovations LLC / Hobbs ElectroOptics
    Optics, Electro-optics, Photonics, Analog Electronics
    Briarcliff Manor NY 10510

    http://electrooptical.net
    http://hobbs-eo.com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to jeroen@nospam.please on Thu May 19 08:17:18 2022
    On Thu, 19 May 2022 17:14:02 +0200, Jeroen Belleman
    <jeroen@nospam.please> wrote:

    On 2022-05-19 17:03, jlarkin@highlandsniptechnology.com wrote:
    On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen
    <langwadt@fonz.dk> wrote:

    torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major
    <keegan...@hotmail.com> wrote:

    Clive Arthur <cl...@nowaytoday.co.uk> wrote:
    On 19/05/2022 04:27, Sylvia Else wrote:

    Is your channel really that noisy that you cannot just discard bad >>>>>>> packets?

    I don't have control over the transmission path, it may be noisy, it >>>>>> may not - it's not a fixed installation. [snip...] I can't request a >>>>>> resend, and sending multiple copies restricts bandwidth too much.

    Hmm, 17 messages in to the thread, and the group finally is told some >>>>> of the critical unstated requirements that *should* have been part of >>>>> the initial message, and would have avoided about 14 "can't you resend" >>>>> or "can't you send multiple" messages.

    Don't you think this above should have been in your initial post so
    that the rest of us, who can't read your mind to divine unstated
    limitations, were appraised of some rather critical limitations?


    It's normal here to get underspecified problems. Details usually
    emerge, but some people do refuse to explain their top-secret
    projects.

    https://xyproblem.info/

    Underspecified problems do encourage lots of lateral/goofy thinking.

    Of course, some people are hostile to ideas. Their career path is more
    McDonalds than electronic design.


    Goofy ideas aren't really welcome if they upset a sizable fraction
    of effort already invested.

    Economists call that the Sunk Cost Fallacy.

    Ideas are cheap. Realizing them is costly.
    You'll want to be selective.

    Sometimes an idea can wipe out a million dollar investment but have a
    shorter path to done. Managers don't like that situation.



    --

    Anybody can count to one.

    - Robert Widlar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeroen Belleman@21:1/5 to jlarkin@highlandsniptechnology.com on Thu May 19 18:51:48 2022
    On 2022-05-19 17:17, jlarkin@highlandsniptechnology.com wrote:
    On Thu, 19 May 2022 17:14:02 +0200, Jeroen Belleman
    <jeroen@nospam.please> wrote:

    On 2022-05-19 17:03, jlarkin@highlandsniptechnology.com wrote:
    On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen
    <langwadt@fonz.dk> wrote:

    torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major
    <keegan...@hotmail.com> wrote:

    Clive Arthur <cl...@nowaytoday.co.uk> wrote:
    On 19/05/2022 04:27, Sylvia Else wrote:

    Is your channel really that noisy that you cannot just discard bad >>>>>>>> packets?

    I don't have control over the transmission path, it may be noisy, it >>>>>>> may not - it's not a fixed installation. [snip...] I can't request a >>>>>>> resend, and sending multiple copies restricts bandwidth too much. >>>>>>
    Hmm, 17 messages in to the thread, and the group finally is told some >>>>>> of the critical unstated requirements that *should* have been part of >>>>>> the initial message, and would have avoided about 14 "can't you resend" >>>>>> or "can't you send multiple" messages.

    Don't you think this above should have been in your initial post so >>>>>> that the rest of us, who can't read your mind to divine unstated
    limitations, were appraised of some rather critical limitations?


    It's normal here to get underspecified problems. Details usually
    emerge, but some people do refuse to explain their top-secret
    projects.

    https://xyproblem.info/

    Underspecified problems do encourage lots of lateral/goofy thinking.

    Of course, some people are hostile to ideas. Their career path is more
    McDonalds than electronic design.


    Goofy ideas aren't really welcome if they upset a sizable fraction
    of effort already invested.

    Economists call that the Sunk Cost Fallacy.

    Ideas are cheap. Realizing them is costly.
    You'll want to be selective.

    Sometimes an idea can wipe out a million dollar investment but have a
    shorter path to done. Managers don't like that situation.


    Everything is easy for those who don't have to do the work
    themselves. I certainly include economists in that lot. The
    sunk costs are needed to get intimate with the problem to be
    solved.

    I think it's the guy who has to do the work who should get
    to choose which idea is best.

    Jeroen Belleman

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Cydrome Leader@21:1/5 to Keegan Major on Thu May 19 18:15:35 2022
    Keegan Major <keegan.major@hotmail.com> wrote:
    Clive Arthur <clive@nowaytoday.co.uk> wrote:
    On 19/05/2022 04:27, Sylvia Else wrote:

    Is your channel really that noisy that you cannot just discard bad
    packets?

    I don't have control over the transmission path, it may be noisy, it
    may not - it's not a fixed installation. [snip...] I can't request a
    resend, and sending multiple copies restricts bandwidth too much.

    Hmm, 17 messages in to the thread, and the group finally is told some
    of the critical unstated requirements that *should* have been part of
    the initial message, and would have avoided about 14 "can't you resend"
    or "can't you send multiple" messages.

    Don't you think this above should have been in your initial post so
    that the rest of us, who can't read your mind to divine unstated
    limitations, were appraised of some rather critical limitations?

    The original post listed the constraints, but they were lost over the
    serial link, and there was no error correction.

    I agreed though it didn't seem like any real question was being asked in
    the first place.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From whit3rd@21:1/5 to jla...@highlandsniptechnology.com on Thu May 19 12:24:46 2022
    On Thursday, May 19, 2022 at 8:03:55 AM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:

    torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major

    Of course, some people are hostile to ideas. Their career path is more McDonalds than electronic design.

    Again with the goofy personality theories! Everyone is hostile to ideas
    for a few minutes in the evening, when it's time to sleep.

    That's normal, and has nothing to do with a career path.

    No sane conscious mind is 'hostile to ideas' in any more general sense; that would be pathological, like being hostile to one's own body parts.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to Jeroen Belleman on Thu May 19 20:57:51 2022
    On 19/05/2022 16:14, Jeroen Belleman wrote:
    On 2022-05-19 17:03, jlarkin@highlandsniptechnology.com wrote:
    On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen
    <langwadt@fonz.dk> wrote:

    torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev
    jla...@highlandsniptechnology.com:
    On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major
    <keegan...@hotmail.com> wrote:

    Clive Arthur <cl...@nowaytoday.co.uk> wrote:
    On 19/05/2022 04:27, Sylvia Else wrote:

    Is your channel really that noisy that you cannot just discard bad >>>>>>> packets?

    I don't have control over the transmission path, it may be noisy, it >>>>>> may not - it's not a fixed installation. [snip...] I can't request a >>>>>> resend, and sending multiple copies restricts bandwidth too much.

    Hmm, 17 messages in to the thread, and the group finally is told some >>>>> of the critical unstated requirements that *should* have been part of >>>>> the initial message, and would have avoided about 14 "can't you
    resend"
    or "can't you send multiple" messages.

    Don't you think this above should have been in your initial post so
    that the rest of us, who can't read your mind to divine unstated
    limitations, were appraised of some rather critical limitations?


    It's normal here to get underspecified problems. Details usually
    emerge, but some people do refuse to explain their top-secret
    projects.

    https://xyproblem.info/

    Underspecified problems do encourage lots of lateral/goofy thinking.

    Almost all of which is completely wasted. Your proposal of send it three
    times and vote best out of three being amongst them.

    There is just about enough space to do what the OP wants but whether or
    not they have the mathematical sophistication and programming skills to implement it quickly enough to be useful is still an open question.

    Of course, some people are hostile to ideas. Their career path is more
    McDonalds than electronic design.

    You have that *EXACTLY* backwards.

    If you cannot adequately describe the exact problem that you are trying
    to solve then you will spend vast amounts of effort solving the wrong problem(s) again and again. I have seen it happen many times.

    Goofy ideas aren't really welcome if they upset a sizable fraction
    of effort already invested. Ideas are cheap. Realizing them is costly.
    You'll want to be selective.

    +1

    Half the battle is specifying the problem and any hard constraints so
    that proposed solutions will actually stand a chance of working on the available hardware and quickly enough to be useful.

    --
    Regards,
    Martin Brown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to '''newspam'''@nonad.co.uk on Thu May 19 13:56:23 2022
    On Thu, 19 May 2022 20:57:51 +0100, Martin Brown
    <'''newspam'''@nonad.co.uk> wrote:

    On 19/05/2022 16:14, Jeroen Belleman wrote:
    On 2022-05-19 17:03, jlarkin@highlandsniptechnology.com wrote:
    On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen
    <langwadt@fonz.dk> wrote:

    torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev
    jla...@highlandsniptechnology.com:
    On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major
    <keegan...@hotmail.com> wrote:

    Clive Arthur <cl...@nowaytoday.co.uk> wrote:
    On 19/05/2022 04:27, Sylvia Else wrote:

    Is your channel really that noisy that you cannot just discard bad >>>>>>>> packets?

    I don't have control over the transmission path, it may be noisy, it >>>>>>> may not - it's not a fixed installation. [snip...] I can't request a >>>>>>> resend, and sending multiple copies restricts bandwidth too much. >>>>>>
    Hmm, 17 messages in to the thread, and the group finally is told some >>>>>> of the critical unstated requirements that *should* have been part of >>>>>> the initial message, and would have avoided about 14 "can't you
    resend"
    or "can't you send multiple" messages.

    Don't you think this above should have been in your initial post so >>>>>> that the rest of us, who can't read your mind to divine unstated
    limitations, were appraised of some rather critical limitations?


    It's normal here to get underspecified problems. Details usually
    emerge, but some people do refuse to explain their top-secret
    projects.

    https://xyproblem.info/

    Underspecified problems do encourage lots of lateral/goofy thinking.

    Almost all of which is completely wasted.

    If you have a lot of ideas, one will be the one you use now and the
    rest are exercizes in thinking, but not wasted. Unless you think that
    thinking is always painful hence should be minimized.

    Your proposal of send it three
    times and vote best out of three being amongst them.

    It's not a bad suggestion to a poorly defined problem with,
    apparently, limited logic resources.




    There is just about enough space to do what the OP wants but whether or
    not they have the mathematical sophistication and programming skills to >implement it quickly enough to be useful is still an open question.

    Of course, some people are hostile to ideas. Their career path is more
    McDonalds than electronic design.

    You have that *EXACTLY* backwards.

    Well, I don't hire (or keep) people who are hostile to ideas. Maybe
    you prefer them.


    If you cannot adequately describe the exact problem that you are trying
    to solve then you will spend vast amounts of effort solving the wrong >problem(s) again and again. I have seen it happen many times.

    You have that *EXACTLY* backwards. A reasonable period of confusion
    and reconsideration is greatly beneficial to design.

    Wedge-heads hate uncertainty so latch on to the first, usually
    textbook conventional, architecture they can find, and implement
    klunkiness.

    I have seen it happen many times.


    Goofy ideas aren't really welcome if they upset a sizable fraction
    of effort already invested. Ideas are cheap. Realizing them is costly.
    You'll want to be selective.

    +1

    Half the battle is specifying the problem and any hard constraints so
    that proposed solutions will actually stand a chance of working on the >available hardware and quickly enough to be useful.

    Half the value is inventing something original that the competitors
    haven't already made unprofitable. No, 5x the value.

    Good engineers routinely implement a specified idea with constraints,
    first pass if they are really good. Implementing dumb ideas is, well,
    dumb.

    --

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to All on Thu May 19 13:58:56 2022
    On Thu, 19 May 2022 12:24:46 -0700 (PDT), whit3rd <whit3rd@gmail.com>
    wrote:

    On Thursday, May 19, 2022 at 8:03:55 AM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major

    Of course, some people are hostile to ideas. Their career path is more
    McDonalds than electronic design.

    Again with the goofy personality theories! Everyone is hostile to ideas
    for a few minutes in the evening, when it's time to sleep.

    Really? I never noticed that.


    That's normal, and has nothing to do with a career path.

    No sane conscious mind is 'hostile to ideas' in any more general sense; that >would be pathological, like being hostile to one's own body parts.

    Oh, lots of people are reflexively hostile to new or unconventional
    ideas. Those personalities poison brainstorming sessions.

    --

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to Martin Brown on Thu May 19 17:10:04 2022
    Martin Brown wrote:
    On 19/05/2022 16:14, Jeroen Belleman wrote:
    On 2022-05-19 17:03, jlarkin@highlandsniptechnology.com wrote:
    On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen
    <langwadt@fonz.dk> wrote:

    torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev
    jla...@highlandsniptechnology.com:
    On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major
    <keegan...@hotmail.com> wrote:

    Clive Arthur <cl...@nowaytoday.co.uk> wrote:
    On 19/05/2022 04:27, Sylvia Else wrote:

    Is your channel really that noisy that you cannot just discard bad >>>>>>>> packets?

    I don't have control over the transmission path, it may be noisy, it >>>>>>> may not - it's not a fixed installation. [snip...] I can't request a >>>>>>> resend, and sending multiple copies restricts bandwidth too much. >>>>>>
    Hmm, 17 messages in to the thread, and the group finally is told some >>>>>> of the critical unstated requirements that *should* have been part of >>>>>> the initial message, and would have avoided about 14 "can't you
    resend"
    or "can't you send multiple" messages.

    Don't you think this above should have been in your initial post so >>>>>> that the rest of us, who can't read your mind to divine unstated
    limitations, were appraised of some rather critical limitations?


    It's normal here to get underspecified problems. Details usually
    emerge, but some people do refuse to explain their top-secret
    projects.

    https://xyproblem.info/

    Underspecified problems do encourage lots of lateral/goofy thinking.

    Almost all of which is completely wasted. Your proposal of send it three times and vote best out of three being amongst them.

    There is just about enough space to do what the OP wants but whether or
    not they have the mathematical sophistication and programming skills to implement it quickly enough to be useful is still an open question.

    Of course, some people are hostile to ideas. Their career path is more
    McDonalds than electronic design.

    You have that *EXACTLY* backwards.

    If you cannot adequately describe the exact problem that you are trying
    to solve then you will spend vast amounts of effort solving the wrong problem(s) again and again. I have seen it happen many times.

    Goofy ideas aren't really welcome if they upset a sizable fraction
    of effort already invested. Ideas are cheap. Realizing them is costly.
    You'll want to be selective.

    +1

    Half the battle is specifying the problem and any hard constraints so
    that proposed solutions will actually stand a chance of working on the available hardware and quickly enough to be useful.


    I'm way more in JL's camp, although not 100%. (I do more math than he
    does.)

    Of course you don't want to take the first thing that comes into your
    head and build that--nobody's advocating that here AFAICT. I've seen it
    a lot in the wild, though. In fact, one outfit I had to deal with (a CE
    in Orange County CA) kept ignoring advice that was backed up with
    detailed mathematical analysis and a _working_prototype_ of what they
    were supposed to build. (That transcutaneous blood glucose thing again.)

    They just trying things randomly until they ran through the client's
    money and then quit. One time when I pinged them about it, a bright lad
    smiled and said, "That's engineering!"

    Riiighhhtt.

    But a lot, a lot of people seem to have very little emotional tolerance
    for being in a state of uncertainty. I can't prove that, but over and
    over I've seen folks spend far too little time turning the problem over
    in their minds, talking at the white board, and so on, and just charging
    in and doing the first thing that seemed plausible.

    That's super dumb. At the beginning of the process, you have to
    cultivate offbeat ideas, because (at least in the sort of gizmos I
    build) there's usually some way to do the task much better and/or
    cheaper than what's out there.

    In general you should spend something like 10% of the time figuring out
    what you should build, and the rest designing and building it. Skimping
    on the one very often leads to poor results on the other.

    Cheers

    Phil Hobbs

    --
    Dr Philip C D Hobbs
    Principal Consultant
    ElectroOptical Innovations LLC / Hobbs ElectroOptics
    Optics, Electro-optics, Photonics, Analog Electronics
    Briarcliff Manor NY 10510

    http://electrooptical.net
    http://hobbs-eo.com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Martin Brown on Thu May 19 14:58:41 2022
    On 5/19/2022 12:57 PM, Martin Brown wrote:
    Underspecified problems do encourage lots of lateral/goofy thinking.

    Almost all of which is completely wasted. Your proposal of send it three times
    and vote best out of three being amongst them.

    There is just about enough space to do what the OP wants but whether or not they have the mathematical sophistication and programming skills to implement it quickly enough to be useful is still an open question.

    The problem is that folks don't want to answer the question posed. They
    all seem to think the person posing it doesn't understand HIS OWN PROBLEM
    SPACE and must rely on *them* to explore it on his behalf.

    Or, they are incredibly under-challenged in their own work and rely on
    others for mental stimulation.

    Assume the person is competent as an engineer, but may lack "experience"
    in a technology that he has an inkling MAY help him with his problem.

    No one bothered to ask the NATURE of the 14 byte messages! Maybe the OP
    is a total idiot and has been sending "DATUM_RECEIVED" and encountering
    DATuM_RECEIVED (1 bit error)
    DBTUM_RECEIVED (2 bit error)
    Maybe there is no "NOT RECEIVED" message and that condition is indicated
    by the *absence* of a message in a particular timeframe. etc.

    Not very likely, so why bother to inquire? Yet, there may be changes
    that *could* be made to the message content (or frequency) that would
    benefit the OP. Shouldn't the OP be asked to provide further details,
    there? (rolls eyes)

    Or, maybe suggest a different transmission medium!

    Or...

    Ans: Assume the OP has the skillset (or constraints) to know what he
    can/can't get away with in his application. And, is EXPLORING the idea
    of using an ECC to reduce his susceptibility to errors corrupting the transmission.

    "Valid" (IMO) comments and questions would then pertain to *qualifying*
    any solution you might want to suggest. E.g., "What is the nature of
    the noise source". Or, indicating some minimum set of requirements
    that must be met for your suggestion (or the OPs query) to be feasible.

    E.g., had the OP only had room for a single byte addition to the
    message, then correcting two errors is not possible WITHIN THAT
    SINGLE MESSAGE FRAME (because you can only indicate 2^8 "conditions"
    with a single additional byte and there are 1+112+(112*111)/2 possible "conditions" in which a message can be received with 2 or fewer errors (assuming exactly 112 bits are actually received -- what if he only gets
    110? Or, 104?)

    OTOH, a 2-byte ECC can easily cover that number so *suggests* a code MAY
    exist (whether or not it is practical to the OP is a different issue).

    The exact distribution of errors (and how errors manifest) *in* the
    data stream is then the important issue.

    Of course, some people are hostile to ideas. Their career path is more
    McDonalds than electronic design.

    You have that *EXACTLY* backwards.

    If you cannot adequately describe the exact problem that you are trying to solve then you will spend vast amounts of effort solving the wrong problem(s) again and again. I have seen it happen many times.

    But the OP has specified a SPECIFIC problem. Whether that will solve HIS "greater" problem is, presumably, something that HE can sort out.

    Or, can pose additional queries to gather the information he needs to
    make that resolution.

    Why do folks think they need to know the whole problem in order to
    contribute to a specific request? Gotta wonder what life was like
    for these people growing up:

    "Mary has 6 apples. She gives two to Francine. How many apples does
    Mary now have?"

    "Why apples and not bananas? Why only two? Why not split them
    evenly? Why Francine? What about Bruce, Francine's brother? And,
    are you sure Francine can eat apples? Or, that she actually wants
    them? Maybe she'd rather have that nice pink ribbon that Mary is
    wearing in her hair? Are you sure the apples are ripe? I thought
    Mary and Francine weren't on speaking terms after that incident in
    the playground..."

    <rolls eyes>

    Must be dreadful engineers.

    Goofy ideas aren't really welcome if they upset a sizable fraction
    of effort already invested. Ideas are cheap. Realizing them is costly.
    You'll want to be selective.

    +1

    Half the battle is specifying the problem and any hard constraints so that proposed solutions will actually stand a chance of working on the available hardware and quickly enough to be useful.

    Competence usually weeds out "goofy" ideas. Only fools would entertain
    them (and, they'd only "entertain" them "for ENTERTAINMENT value". And,
    you wouldn't want to employ folks who can't sort these ideas out before
    passing from grey matter to vocal tract!

    An idea that is outside the box isn't goofy, it's just unconventional.
    THOSE ideas can cause people to think in different directions towards
    a *possibly* practical solution.

    But, goofy is just plain goofy.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Thu May 19 15:31:10 2022
    On Thu, 19 May 2022 17:10:04 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    Martin Brown wrote:
    On 19/05/2022 16:14, Jeroen Belleman wrote:
    On 2022-05-19 17:03, jlarkin@highlandsniptechnology.com wrote:
    On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen
    <langwadt@fonz.dk> wrote:

    torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev
    jla...@highlandsniptechnology.com:
    On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major
    <keegan...@hotmail.com> wrote:

    Clive Arthur <cl...@nowaytoday.co.uk> wrote:
    On 19/05/2022 04:27, Sylvia Else wrote:

    Is your channel really that noisy that you cannot just discard bad >>>>>>>>> packets?

    I don't have control over the transmission path, it may be noisy, it >>>>>>>> may not - it's not a fixed installation. [snip...] I can't request a >>>>>>>> resend, and sending multiple copies restricts bandwidth too much. >>>>>>>
    Hmm, 17 messages in to the thread, and the group finally is told some >>>>>>> of the critical unstated requirements that *should* have been part of >>>>>>> the initial message, and would have avoided about 14 "can't you
    resend"
    or "can't you send multiple" messages.

    Don't you think this above should have been in your initial post so >>>>>>> that the rest of us, who can't read your mind to divine unstated >>>>>>> limitations, were appraised of some rather critical limitations? >>>>>>>

    It's normal here to get underspecified problems. Details usually
    emerge, but some people do refuse to explain their top-secret
    projects.

    https://xyproblem.info/

    Underspecified problems do encourage lots of lateral/goofy thinking.

    Almost all of which is completely wasted. Your proposal of send it three
    times and vote best out of three being amongst them.

    There is just about enough space to do what the OP wants but whether or
    not they have the mathematical sophistication and programming skills to
    implement it quickly enough to be useful is still an open question.

    Of course, some people are hostile to ideas. Their career path is more >>>> McDonalds than electronic design.

    You have that *EXACTLY* backwards.

    If you cannot adequately describe the exact problem that you are trying
    to solve then you will spend vast amounts of effort solving the wrong
    problem(s) again and again. I have seen it happen many times.

    Goofy ideas aren't really welcome if they upset a sizable fraction
    of effort already invested. Ideas are cheap. Realizing them is costly.
    You'll want to be selective.

    +1

    Half the battle is specifying the problem and any hard constraints so
    that proposed solutions will actually stand a chance of working on the
    available hardware and quickly enough to be useful.


    I'm way more in JL's camp, although not 100%. (I do more math than he
    does.)

    Yes, I work more by instinct and simulation. But my world is largely
    nonlinear, where the math is basically impossible.


    Of course you don't want to take the first thing that comes into your
    head and build that--nobody's advocating that here AFAICT. I've seen it
    a lot in the wild, though. In fact, one outfit I had to deal with (a CE
    in Orange County CA) kept ignoring advice that was backed up with
    detailed mathematical analysis and a _working_prototype_ of what they
    were supposed to build. (That transcutaneous blood glucose thing again.)

    They just trying things randomly until they ran through the client's
    money and then quit. One time when I pinged them about it, a bright lad >smiled and said, "That's engineering!"

    Riiighhhtt.

    But a lot, a lot of people seem to have very little emotional tolerance
    for being in a state of uncertainty. I can't prove that, but over and
    over I've seen folks spend far too little time turning the problem over
    in their minds, talking at the white board, and so on, and just charging
    in and doing the first thing that seemed plausible.

    Yes. Uncertainty makes many people uncomfortable, so they lock down an architecture as soon as they can. I've seen horrors.


    That's super dumb. At the beginning of the process, you have to
    cultivate offbeat ideas, because (at least in the sort of gizmos I
    build) there's usually some way to do the task much better and/or
    cheaper than what's out there.

    In general you should spend something like 10% of the time figuring out
    what you should build, and the rest designing and building it. Skimping
    on the one very often leads to poor results on the other.

    Brainstorming and a period of confusion can often greatly simplify the
    design, or add nifty features. It's well worth the tradeoff.

    Design is a partly emotional process, which lots of engineers don't
    want to admit either.

    --

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to blockedofcourse@foo.invalid on Thu May 19 15:39:12 2022
    On Thu, 19 May 2022 14:58:41 -0700, Don Y
    <blockedofcourse@foo.invalid> wrote:

    On 5/19/2022 12:57 PM, Martin Brown wrote:
    Underspecified problems do encourage lots of lateral/goofy thinking.

    Almost all of which is completely wasted. Your proposal of send it three times
    and vote best out of three being amongst them.

    There is just about enough space to do what the OP wants but whether or not >> they have the mathematical sophistication and programming skills to implement
    it quickly enough to be useful is still an open question.

    The problem is that folks don't want to answer the question posed. They
    all seem to think the person posing it doesn't understand HIS OWN PROBLEM >SPACE and must rely on *them* to explore it on his behalf.

    My customers often don't know what they actually need... but they
    think they do.


    Or, they are incredibly under-challenged in their own work and rely on
    others for mental stimulation.

    Sometimes customers don't know what electronics and signal processing
    can do for them.



    Assume the person is competent as an engineer, but may lack "experience"
    in a technology that he has an inkling MAY help him with his problem.

    Sometimes experience is the worst teacher.




    No one bothered to ask the NATURE of the 14 byte messages! Maybe the OP
    is a total idiot and has been sending "DATUM_RECEIVED" and encountering
    DATuM_RECEIVED (1 bit error)
    DBTUM_RECEIVED (2 bit error)
    Maybe there is no "NOT RECEIVED" message and that condition is indicated
    by the *absence* of a message in a particular timeframe. etc.

    Not very likely, so why bother to inquire? Yet, there may be changes
    that *could* be made to the message content (or frequency) that would
    benefit the OP. Shouldn't the OP be asked to provide further details,
    there? (rolls eyes)

    Or, maybe suggest a different transmission medium!

    Or...

    Ans: Assume the OP has the skillset (or constraints) to know what he >can/can't get away with in his application. And, is EXPLORING the idea
    of using an ECC to reduce his susceptibility to errors corrupting the >transmission.

    "Valid" (IMO) comments and questions would then pertain to *qualifying*
    any solution you might want to suggest. E.g., "What is the nature of
    the noise source". Or, indicating some minimum set of requirements
    that must be met for your suggestion (or the OPs query) to be feasible.

    E.g., had the OP only had room for a single byte addition to the
    message, then correcting two errors is not possible WITHIN THAT
    SINGLE MESSAGE FRAME (because you can only indicate 2^8 "conditions"
    with a single additional byte and there are 1+112+(112*111)/2 possible >"conditions" in which a message can be received with 2 or fewer errors >(assuming exactly 112 bits are actually received -- what if he only gets
    110? Or, 104?)

    OTOH, a 2-byte ECC can easily cover that number so *suggests* a code MAY >exist (whether or not it is practical to the OP is a different issue).

    The exact distribution of errors (and how errors manifest) *in* the
    data stream is then the important issue.

    Of course, some people are hostile to ideas. Their career path is more >>>> McDonalds than electronic design.

    You have that *EXACTLY* backwards.

    If you cannot adequately describe the exact problem that you are trying to >> solve then you will spend vast amounts of effort solving the wrong problem(s)
    again and again. I have seen it happen many times.

    But the OP has specified a SPECIFIC problem. Whether that will solve HIS >"greater" problem is, presumably, something that HE can sort out.

    Or, can pose additional queries to gather the information he needs to
    make that resolution.

    Why do folks think they need to know the whole problem in order to
    contribute to a specific request? Gotta wonder what life was like
    for these people growing up:

    "Mary has 6 apples. She gives two to Francine. How many apples does
    Mary now have?"

    "Why apples and not bananas? Why only two? Why not split them
    evenly? Why Francine? What about Bruce, Francine's brother? And,
    are you sure Francine can eat apples? Or, that she actually wants
    them? Maybe she'd rather have that nice pink ribbon that Mary is
    wearing in her hair? Are you sure the apples are ripe? I thought
    Mary and Francine weren't on speaking terms after that incident in
    the playground..."

    <rolls eyes>

    Must be dreadful engineers.

    Goofy ideas aren't really welcome if they upset a sizable fraction
    of effort already invested. Ideas are cheap. Realizing them is costly.
    You'll want to be selective.

    +1

    Half the battle is specifying the problem and any hard constraints so that >> proposed solutions will actually stand a chance of working on the available >> hardware and quickly enough to be useful.

    Competence usually weeds out "goofy" ideas. Only fools would entertain
    them (and, they'd only "entertain" them "for ENTERTAINMENT value". And,
    you wouldn't want to employ folks who can't sort these ideas out before >passing from grey matter to vocal tract!

    All wrong. I prefer to employ people who don't censor themselves, who
    aren't afraid of possibilities.


    An idea that is outside the box isn't goofy, it's just unconventional.
    THOSE ideas can cause people to think in different directions towards
    a *possibly* practical solution.

    But, goofy is just plain goofy.

    One of the guidelines to good brainstorming is to not separate serious
    from goofy from outright jokes. It works.

    The solution space is huge, and good ideas might be hiding behind
    silly ones.

    --

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to John Larkin on Thu May 19 19:12:20 2022
    John Larkin wrote:
    On Thu, 19 May 2022 17:10:04 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    Martin Brown wrote:
    On 19/05/2022 16:14, Jeroen Belleman wrote:
    On 2022-05-19 17:03, jlarkin@highlandsniptechnology.com wrote:
    On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen >>>>> <langwadt@fonz.dk> wrote:

    torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev
    jla...@highlandsniptechnology.com:
    On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major
    <keegan...@hotmail.com> wrote:

    Clive Arthur <cl...@nowaytoday.co.uk> wrote:
    On 19/05/2022 04:27, Sylvia Else wrote:

    Is your channel really that noisy that you cannot just discard bad >>>>>>>>>> packets?

    I don't have control over the transmission path, it may be noisy, it >>>>>>>>> may not - it's not a fixed installation. [snip...] I can't request a >>>>>>>>> resend, and sending multiple copies restricts bandwidth too much. >>>>>>>>
    Hmm, 17 messages in to the thread, and the group finally is told some >>>>>>>> of the critical unstated requirements that *should* have been part of >>>>>>>> the initial message, and would have avoided about 14 "can't you >>>>>>>> resend"
    or "can't you send multiple" messages.

    Don't you think this above should have been in your initial post so >>>>>>>> that the rest of us, who can't read your mind to divine unstated >>>>>>>> limitations, were appraised of some rather critical limitations? >>>>>>>>

    It's normal here to get underspecified problems. Details usually >>>>>>> emerge, but some people do refuse to explain their top-secret
    projects.

    https://xyproblem.info/

    Underspecified problems do encourage lots of lateral/goofy thinking.

    Almost all of which is completely wasted. Your proposal of send it three >>> times and vote best out of three being amongst them.

    There is just about enough space to do what the OP wants but whether or
    not they have the mathematical sophistication and programming skills to
    implement it quickly enough to be useful is still an open question.

    Of course, some people are hostile to ideas. Their career path is more >>>>> McDonalds than electronic design.

    You have that *EXACTLY* backwards.

    If you cannot adequately describe the exact problem that you are trying
    to solve then you will spend vast amounts of effort solving the wrong
    problem(s) again and again. I have seen it happen many times.

    Goofy ideas aren't really welcome if they upset a sizable fraction
    of effort already invested. Ideas are cheap. Realizing them is costly. >>>> You'll want to be selective.

    +1

    Half the battle is specifying the problem and any hard constraints so
    that proposed solutions will actually stand a chance of working on the
    available hardware and quickly enough to be useful.


    I'm way more in JL's camp, although not 100%. (I do more math than he
    does.)

    Yes, I work more by instinct and simulation. But my world is largely nonlinear, where the math is basically impossible.


    Of course you don't want to take the first thing that comes into your
    head and build that--nobody's advocating that here AFAICT. I've seen it
    a lot in the wild, though. In fact, one outfit I had to deal with (a CE
    in Orange County CA) kept ignoring advice that was backed up with
    detailed mathematical analysis and a _working_prototype_ of what they
    were supposed to build. (That transcutaneous blood glucose thing again.)

    They just trying things randomly until they ran through the client's
    money and then quit. One time when I pinged them about it, a bright lad
    smiled and said, "That's engineering!"

    Riiighhhtt.

    But a lot, a lot of people seem to have very little emotional tolerance
    for being in a state of uncertainty. I can't prove that, but over and
    over I've seen folks spend far too little time turning the problem over
    in their minds, talking at the white board, and so on, and just charging
    in and doing the first thing that seemed plausible.

    Yes. Uncertainty makes many people uncomfortable, so they lock down an architecture as soon as they can. I've seen horrors.


    That's super dumb. At the beginning of the process, you have to
    cultivate offbeat ideas, because (at least in the sort of gizmos I
    build) there's usually some way to do the task much better and/or
    cheaper than what's out there.

    In general you should spend something like 10% of the time figuring out
    what you should build, and the rest designing and building it. Skimping
    on the one very often leads to poor results on the other.

    Brainstorming and a period of confusion can often greatly simplify the design, or add nifty features. It's well worth the tradeoff.

    Design is a partly emotional process, which lots of engineers don't
    want to admit either.


    One time long ago, I was in a two-day class for OS/2 Presentation
    Manager programming. (I did say it was long ago.) ;)

    At one point, the presenter (who was actually very good) asked us two questions: Is design an art or a science? What about debugging?

    Just about everyone said that design was a science and debugging was an
    art. That's backwards.

    A design is done when the designer says it's done, generally including a
    good long list of checks for performance, DRC, EMI, ROHS, MIL HDBK 217,
    ad nauseam. There are nearly always a ridiculously large number of
    different ways to do the job, if you count all the combinations. That
    makes it an art.

    On the other hand, troubleshooting is definitely a science. There's a
    problem someplace, because this item doesn't behave like the N previous
    ones that worked. You find it by applying critical tests and reasoning
    about them, and when the problem is found and fixed, everyone can agree
    that it's gone.

    Debugging first articles is a bit of both, because you often find design screwups (hopefully minor). In my world that often includes
    layout-dependent stuff such as how high a current can you run through
    your 12 GHz pHEMT or 45-GHz SiGe BJT before it becomes unstable.
    Swapping out jumpers for beads, tweaking current sources, that sort of
    stuff.

    In rare instances it's something really stupid such as upside-down power supplies on an op amp, but normally the first articles are shippable
    with maybe a roach wire or two.

    We have had the occasional disaster, such as a small module with three
    SMPSes on it to make several rails from a +24V wall wart. The negative
    rails were made by an AOZ1282 async buck running off the output of an
    LMR23630 sync buck (+13 -> -12 and +24 ->+13, respectively).

    The A-O part is generally super well behaved, but the two together
    produced a _ridiculous_ selection of high harmonics of the LMR23630's
    2.15 MHz switching frequency. It was the stuff of nightmares--measuring
    one node produced a big peak at 182 MHz, and another one nearby had
    another peak at 121 MHz, selected by various incidental resonances.

    With that one, we just cut our losses. ;(

    Cheers

    Phil Hobbs

    --
    Dr Philip C D Hobbs
    Principal Consultant
    ElectroOptical Innovations LLC / Hobbs ElectroOptics
    Optics, Electro-optics, Photonics, Analog Electronics
    Briarcliff Manor NY 10510

    http://electrooptical.net
    http://hobbs-eo.com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Thu May 19 17:05:42 2022
    On Thu, 19 May 2022 19:12:20 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    John Larkin wrote:
    On Thu, 19 May 2022 17:10:04 -0400, Phil Hobbs
    <pcdhSpamMeSenseless@electrooptical.net> wrote:

    Martin Brown wrote:
    On 19/05/2022 16:14, Jeroen Belleman wrote:
    On 2022-05-19 17:03, jlarkin@highlandsniptechnology.com wrote:
    On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen >>>>>> <langwadt@fonz.dk> wrote:

    torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev
    jla...@highlandsniptechnology.com:
    On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major
    <keegan...@hotmail.com> wrote:

    Clive Arthur <cl...@nowaytoday.co.uk> wrote:
    On 19/05/2022 04:27, Sylvia Else wrote:

    Is your channel really that noisy that you cannot just discard bad >>>>>>>>>>> packets?

    I don't have control over the transmission path, it may be noisy, it >>>>>>>>>> may not - it's not a fixed installation. [snip...] I can't request a >>>>>>>>>> resend, and sending multiple copies restricts bandwidth too much. >>>>>>>>>
    Hmm, 17 messages in to the thread, and the group finally is told some >>>>>>>>> of the critical unstated requirements that *should* have been part of >>>>>>>>> the initial message, and would have avoided about 14 "can't you >>>>>>>>> resend"
    or "can't you send multiple" messages.

    Don't you think this above should have been in your initial post so >>>>>>>>> that the rest of us, who can't read your mind to divine unstated >>>>>>>>> limitations, were appraised of some rather critical limitations? >>>>>>>>>

    It's normal here to get underspecified problems. Details usually >>>>>>>> emerge, but some people do refuse to explain their top-secret
    projects.

    https://xyproblem.info/

    Underspecified problems do encourage lots of lateral/goofy thinking. >>>>
    Almost all of which is completely wasted. Your proposal of send it three >>>> times and vote best out of three being amongst them.

    There is just about enough space to do what the OP wants but whether or >>>> not they have the mathematical sophistication and programming skills to >>>> implement it quickly enough to be useful is still an open question.

    Of course, some people are hostile to ideas. Their career path is more >>>>>> McDonalds than electronic design.

    You have that *EXACTLY* backwards.

    If you cannot adequately describe the exact problem that you are trying >>>> to solve then you will spend vast amounts of effort solving the wrong
    problem(s) again and again. I have seen it happen many times.

    Goofy ideas aren't really welcome if they upset a sizable fraction
    of effort already invested. Ideas are cheap. Realizing them is costly. >>>>> You'll want to be selective.

    +1

    Half the battle is specifying the problem and any hard constraints so
    that proposed solutions will actually stand a chance of working on the >>>> available hardware and quickly enough to be useful.


    I'm way more in JL's camp, although not 100%. (I do more math than he
    does.)

    Yes, I work more by instinct and simulation. But my world is largely
    nonlinear, where the math is basically impossible.


    Of course you don't want to take the first thing that comes into your
    head and build that--nobody's advocating that here AFAICT. I've seen it >>> a lot in the wild, though. In fact, one outfit I had to deal with (a CE >>> in Orange County CA) kept ignoring advice that was backed up with
    detailed mathematical analysis and a _working_prototype_ of what they
    were supposed to build. (That transcutaneous blood glucose thing again.) >>>
    They just trying things randomly until they ran through the client's
    money and then quit. One time when I pinged them about it, a bright lad >>> smiled and said, "That's engineering!"

    Riiighhhtt.

    But a lot, a lot of people seem to have very little emotional tolerance
    for being in a state of uncertainty. I can't prove that, but over and
    over I've seen folks spend far too little time turning the problem over
    in their minds, talking at the white board, and so on, and just charging >>> in and doing the first thing that seemed plausible.

    Yes. Uncertainty makes many people uncomfortable, so they lock down an
    architecture as soon as they can. I've seen horrors.


    That's super dumb. At the beginning of the process, you have to
    cultivate offbeat ideas, because (at least in the sort of gizmos I
    build) there's usually some way to do the task much better and/or
    cheaper than what's out there.

    In general you should spend something like 10% of the time figuring out
    what you should build, and the rest designing and building it. Skimping >>> on the one very often leads to poor results on the other.

    Brainstorming and a period of confusion can often greatly simplify the
    design, or add nifty features. It's well worth the tradeoff.

    Design is a partly emotional process, which lots of engineers don't
    want to admit either.


    One time long ago, I was in a two-day class for OS/2 Presentation
    Manager programming. (I did say it was long ago.) ;)

    At one point, the presenter (who was actually very good) asked us two >questions: Is design an art or a science? What about debugging?

    Just about everyone said that design was a science and debugging was an
    art. That's backwards.

    A design is done when the designer says it's done, generally including a
    good long list of checks for performance, DRC, EMI, ROHS, MIL HDBK 217,
    ad nauseam. There are nearly always a ridiculously large number of
    different ways to do the job, if you count all the combinations. That
    makes it an art.

    On the other hand, troubleshooting is definitely a science. There's a >problem someplace, because this item doesn't behave like the N previous
    ones that worked. You find it by applying critical tests and reasoning
    about them, and when the problem is found and fixed, everyone can agree
    that it's gone.

    Debugging first articles is a bit of both, because you often find design >screwups (hopefully minor). In my world that often includes
    layout-dependent stuff such as how high a current can you run through
    your 12 GHz pHEMT or 45-GHz SiGe BJT before it becomes unstable.
    Swapping out jumpers for beads, tweaking current sources, that sort of
    stuff.

    In rare instances it's something really stupid such as upside-down power >supplies on an op amp, but normally the first articles are shippable
    with maybe a roach wire or two.

    After some years, we have evolved procedures that mostly prevent
    getting V+ and V- swapped on opamps.


    We have had the occasional disaster, such as a small module with three
    SMPSes on it to make several rails from a +24V wall wart. The negative
    rails were made by an AOZ1282 async buck running off the output of an >LMR23630 sync buck (+13 -> -12 and +24 ->+13, respectively).

    The A-O part is generally super well behaved, but the two together
    produced a _ridiculous_ selection of high harmonics of the LMR23630's
    2.15 MHz switching frequency. It was the stuff of nightmares--measuring
    one node produced a big peak at 182 MHz, and another one nearby had
    another peak at 121 MHz, selected by various incidental resonances.

    With that one, we just cut our losses. ;(

    Cheers

    Phil Hobbs

    We recently had an LTM8078 "Silent Switcher" screaming at us in 400
    MHz bursts at 2.5 MHz. The embarassing part was that the customer
    discovered it. Oops.

    A nice ancient National 50 KHz Simple Switcher fixed that, with a
    board spin of course. And gigantic inductors.

    https://www.dropbox.com/s/ah90qsi0007ymjv/Mon_Noise_2.jpg?raw=1

    https://www.dropbox.com/s/9grk3iqwzifmw6w/Mon_Noise_LTM8078.jpg?raw=1

    --

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to John Larkin on Thu May 19 22:01:59 2022
    John Larkin wrote:
    On Thu, 19 May 2022 19:12:20 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    John Larkin wrote:
    On Thu, 19 May 2022 17:10:04 -0400, Phil Hobbs
    <pcdhSpamMeSenseless@electrooptical.net> wrote:

    Martin Brown wrote:
    On 19/05/2022 16:14, Jeroen Belleman wrote:
    On 2022-05-19 17:03, jlarkin@highlandsniptechnology.com wrote:
    On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen >>>>>>> <langwadt@fonz.dk> wrote:

    torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev
    jla...@highlandsniptechnology.com:
    On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major
    <keegan...@hotmail.com> wrote:

    Clive Arthur <cl...@nowaytoday.co.uk> wrote:
    On 19/05/2022 04:27, Sylvia Else wrote:

    Is your channel really that noisy that you cannot just discard bad >>>>>>>>>>>> packets?

    I don't have control over the transmission path, it may be noisy, it
    may not - it's not a fixed installation. [snip...] I can't request a
    resend, and sending multiple copies restricts bandwidth too much. >>>>>>>>>>
    Hmm, 17 messages in to the thread, and the group finally is told some
    of the critical unstated requirements that *should* have been part of
    the initial message, and would have avoided about 14 "can't you >>>>>>>>>> resend"
    or "can't you send multiple" messages.

    Don't you think this above should have been in your initial post so >>>>>>>>>> that the rest of us, who can't read your mind to divine unstated >>>>>>>>>> limitations, were appraised of some rather critical limitations? >>>>>>>>>>

    It's normal here to get underspecified problems. Details usually >>>>>>>>> emerge, but some people do refuse to explain their top-secret >>>>>>>>> projects.

    https://xyproblem.info/

    Underspecified problems do encourage lots of lateral/goofy thinking. >>>>>
    Almost all of which is completely wasted. Your proposal of send it three >>>>> times and vote best out of three being amongst them.

    There is just about enough space to do what the OP wants but whether or >>>>> not they have the mathematical sophistication and programming skills to >>>>> implement it quickly enough to be useful is still an open question.

    Of course, some people are hostile to ideas. Their career path is more >>>>>>> McDonalds than electronic design.

    You have that *EXACTLY* backwards.

    If you cannot adequately describe the exact problem that you are trying >>>>> to solve then you will spend vast amounts of effort solving the wrong >>>>> problem(s) again and again. I have seen it happen many times.

    Goofy ideas aren't really welcome if they upset a sizable fraction >>>>>> of effort already invested. Ideas are cheap. Realizing them is costly. >>>>>> You'll want to be selective.

    +1

    Half the battle is specifying the problem and any hard constraints so >>>>> that proposed solutions will actually stand a chance of working on the >>>>> available hardware and quickly enough to be useful.


    I'm way more in JL's camp, although not 100%. (I do more math than he >>>> does.)

    Yes, I work more by instinct and simulation. But my world is largely
    nonlinear, where the math is basically impossible.


    Of course you don't want to take the first thing that comes into your
    head and build that--nobody's advocating that here AFAICT. I've seen it >>>> a lot in the wild, though. In fact, one outfit I had to deal with (a CE >>>> in Orange County CA) kept ignoring advice that was backed up with
    detailed mathematical analysis and a _working_prototype_ of what they
    were supposed to build. (That transcutaneous blood glucose thing again.) >>>>
    They just trying things randomly until they ran through the client's
    money and then quit. One time when I pinged them about it, a bright lad >>>> smiled and said, "That's engineering!"

    Riiighhhtt.

    But a lot, a lot of people seem to have very little emotional tolerance >>>> for being in a state of uncertainty. I can't prove that, but over and >>>> over I've seen folks spend far too little time turning the problem over >>>> in their minds, talking at the white board, and so on, and just charging >>>> in and doing the first thing that seemed plausible.

    Yes. Uncertainty makes many people uncomfortable, so they lock down an
    architecture as soon as they can. I've seen horrors.


    That's super dumb. At the beginning of the process, you have to
    cultivate offbeat ideas, because (at least in the sort of gizmos I
    build) there's usually some way to do the task much better and/or
    cheaper than what's out there.

    In general you should spend something like 10% of the time figuring out >>>> what you should build, and the rest designing and building it. Skimping >>>> on the one very often leads to poor results on the other.

    Brainstorming and a period of confusion can often greatly simplify the
    design, or add nifty features. It's well worth the tradeoff.

    Design is a partly emotional process, which lots of engineers don't
    want to admit either.


    One time long ago, I was in a two-day class for OS/2 Presentation
    Manager programming. (I did say it was long ago.) ;)

    At one point, the presenter (who was actually very good) asked us two
    questions: Is design an art or a science? What about debugging?

    Just about everyone said that design was a science and debugging was an
    art. That's backwards.

    A design is done when the designer says it's done, generally including a
    good long list of checks for performance, DRC, EMI, ROHS, MIL HDBK 217,
    ad nauseam. There are nearly always a ridiculously large number of
    different ways to do the job, if you count all the combinations. That
    makes it an art.

    On the other hand, troubleshooting is definitely a science. There's a
    problem someplace, because this item doesn't behave like the N previous
    ones that worked. You find it by applying critical tests and reasoning
    about them, and when the problem is found and fixed, everyone can agree
    that it's gone.

    Debugging first articles is a bit of both, because you often find design
    screwups (hopefully minor). In my world that often includes
    layout-dependent stuff such as how high a current can you run through
    your 12 GHz pHEMT or 45-GHz SiGe BJT before it becomes unstable.
    Swapping out jumpers for beads, tweaking current sources, that sort of
    stuff.

    In rare instances it's something really stupid such as upside-down power
    supplies on an op amp, but normally the first articles are shippable
    with maybe a roach wire or two.

    After some years, we have evolved procedures that mostly prevent
    getting V+ and V- swapped on opamps.


    We have had the occasional disaster, such as a small module with three
    SMPSes on it to make several rails from a +24V wall wart. The negative
    rails were made by an AOZ1282 async buck running off the output of an
    LMR23630 sync buck (+13 -> -12 and +24 ->+13, respectively).

    The A-O part is generally super well behaved, but the two together
    produced a _ridiculous_ selection of high harmonics of the LMR23630's
    2.15 MHz switching frequency. It was the stuff of nightmares--measuring
    one node produced a big peak at 182 MHz, and another one nearby had
    another peak at 121 MHz, selected by various incidental resonances.

    With that one, we just cut our losses. ;(


    We recently had an LTM8078 "Silent Switcher" screaming at us in 400
    MHz bursts at 2.5 MHz. The embarassing part was that the customer
    discovered it. Oops.

    A nice ancient National 50 KHz Simple Switcher fixed that, with a
    board spin of course. And gigantic inductors.

    https://www.dropbox.com/s/ah90qsi0007ymjv/Mon_Noise_2.jpg?raw=1

    https://www.dropbox.com/s/9grk3iqwzifmw6w/Mon_Noise_LTM8078.jpg?raw=1

    I've had good luck with the 150 kHz ones too, with Schottky catch diodes
    to prevent current spikes from PN diode recovery. They do tend to need
    chunky inductors to handle all those voltseconds.

    Cheers

    Phil Hobbs

    --
    Dr Philip C D Hobbs
    Principal Consultant
    ElectroOptical Innovations LLC / Hobbs ElectroOptics
    Optics, Electro-optics, Photonics, Analog Electronics
    Briarcliff Manor NY 10510

    http://electrooptical.net
    http://hobbs-eo.com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From whit3rd@21:1/5 to John Larkin on Thu May 19 20:38:24 2022
    On Thursday, May 19, 2022 at 1:59:08 PM UTC-7, John Larkin wrote:
    On Thu, 19 May 2022 12:24:46 -0700 (PDT), whit3rd <whi...@gmail.com>
    wrote:
    On Thursday, May 19, 2022 at 8:03:55 AM UTC-7, jla...@highlandsniptechnology.com wrote:


    Of course, some people are hostile to ideas.

    No sane conscious mind is 'hostile to ideas' in any more general sense; that >would be pathological, like being hostile to one's own body parts.

    Oh, lots of people are reflexively hostile to new or unconventional
    ideas. Those personalities poison brainstorming sessions.

    For those of us who haven't experienced poisoned brainstorming sessions, describe the 'hostility'. I have grey hair, but cannot recall ever meeting someone who was 'hostile to ideas' in general.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Eather@21:1/5 to John Larkin on Fri May 20 16:48:06 2022
    On 19/05/2022 8:46 am, John Larkin wrote:
    On Thu, 19 May 2022 08:06:25 +1000, David Eather
    <eatREMOVEher@tpg.com.au> wrote:

    On 19/05/2022 2:32 am, jlarkin@highlandsniptechnology.com wrote:
    On Wed, 18 May 2022 16:54:32 +0100, Clive Arthur
    <clive@nowaytoday.co.uk> wrote:

    Hi all

    I have serial data in 14 byte packets on which I'd like to detect and
    correct errors. Two bit errors would be nice. I can put 2 extra EDC
    bytes on the end to make a 16 byte packet.

    I don't have the resources for Reed-Solomon. I could use a 16 bit CRC, >>>> these are easy to generate with a small/moderate LUT.

    In the past, I've used a CRC16 for single bit error detection and
    correction on a longer packet, but I didn't do the error detection part. >>>> Errors were very rare, time was not critical, and I understand that >>>> this was simply done by changing each message bit in turn then
    recalculating the CRC till it all worked out. That's far to slow for my >>>> current needs.

    If I'm lucky, a 16 bit CRC might be able to detect and correct 2 bit
    errors in 14 bytes (112 * 111 possibilities?), but is there a way of
    quickly finding out which bits are wrong?

    Or maybe a completely different approach? This has to be done on the
    fly, and multi-kilobyte LUTs or thousands of clock cycles are out of the >>>> question.


    Send it three times and compare.





    you didn't read the 2 byte limit he said he had? The answer is it can't
    be done with the constraints he has specified.

    He specified a packet length limit, but didn't say he couldn't send it multiple times.

    I'm trying to be helpful, you are trying to be obnoxious. Do whatever
    you are best at.


    I'm being helpful - if he had such a limit on packet size he probably
    has a limit on how much he can send. What he wants is not possible with
    the limits he has described. It is helpful to let him know he has to
    reassess his limits rather than just assume he can do what you want -
    and there are more efficient ways than just send it three times.

    you were just being noise.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jasen Betts@21:1/5 to Clive Arthur on Fri May 20 06:35:03 2022
    On 2022-05-18, Clive Arthur <clive@nowaytoday.co.uk> wrote:
    Hi all

    I have serial data in 14 byte packets on which I'd like to detect and
    correct errors. Two bit errors would be nice. I can put 2 extra EDC
    bytes on the end to make a 16 byte packet.

    I don't have the resources for Reed-Solomon. I could use a 16 bit CRC,
    these are easy to generate with a small/moderate LUT.

    In the past, I've used a CRC16 for single bit error detection and
    correction on a longer packet, but I didn't do the error detection part.
    Errors were very rare, time was not critical, and I understand that
    this was simply done by changing each message bit in turn then
    recalculating the CRC till it all worked out. That's far to slow for my current needs.

    If I'm lucky, a 16 bit CRC might be able to detect and correct 2 bit
    errors in 14 bytes (112 * 111 possibilities?), but is there a way of
    quickly finding out which bits are wrong?

    a look-up table. how much resources do you have?


    --
    Jasen.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Eather@21:1/5 to Clive Arthur on Fri May 20 17:45:55 2022
    On 19/05/2022 1:54 am, Clive Arthur wrote:
    Hi all

    I have serial data in 14 byte packets on which I'd like to detect and
    correct errors.  Two bit errors would be nice.  I can put 2 extra EDC
    bytes on the end to make a 16 byte packet.

    I don't have the resources for Reed-Solomon.  I could use a 16 bit CRC, these are easy to generate with a small/moderate LUT.

    In the past, I've used a CRC16 for single bit error detection and
    correction on a longer packet, but I didn't do the error detection part.
     Errors were very rare, time was not critical, and I understand that
    this was simply done by changing each message bit in turn then
    recalculating the CRC till it all worked out.  That's far to slow for my current needs.

    If I'm lucky, a 16 bit CRC might be able to detect and correct 2 bit
    errors in 14 bytes (112 * 111 possibilities?), but is there a way of
    quickly finding out which bits are wrong?

    Or maybe a completely different approach? This has to be done on the
    fly, and multi-kilobyte LUTs or thousands of clock cycles are out of the question.

    this one shouldn't be thousands of compute cycles and only a small look
    up table or maybe even none.

    This one is out of the box: take the 14 bytes and append to bytes of a
    known pattern 0x00 or 0xFF will work as well as anything else. Use a
    128-bit (16 bytes) encryption algorithm and send that. On the receiving
    end, decrypt. If the last two bytes are the same as the two you added
    then all good.

    if not then you have to brute force the data. All possible single bit
    errors, all 2 bit errors etc until you get the answer or run out of
    time. The good news is that this will pick up multiple bit errors

    99.8% of all possible 1 bit errors - 128 in total
    87.6% of all possible 2 bit errors - 8128 in total

    each and every bit error has a ((2^16)-1)/2^16 chance to be detected.
    that is a 99.999% chance.

    Since you are not using the encryption algorithm as a cryptographic
    device but just a randomizing device you can probably chop it length
    down in half to double its speed.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From marty@21:1/5 to Phil Hobbs on Fri May 20 18:34:24 2022
    On 20/5/22 07:10, Phil Hobbs wrote:
    Martin Brown wrote:
    On 19/05/2022 16:14, Jeroen Belleman wrote:
    On 2022-05-19 17:03, jlarkin@highlandsniptechnology.com wrote:
    On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen
    <langwadt@fonz.dk> wrote:

    torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev
    jla...@highlandsniptechnology.com:
    On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major
    <keegan...@hotmail.com> wrote:

    Clive Arthur <cl...@nowaytoday.co.uk> wrote:
    On 19/05/2022 04:27, Sylvia Else wrote:

    Is your channel really that noisy that you cannot just discard bad >>>>>>>>> packets?

    I don't have control over the transmission path, it may be
    noisy, it
    may not - it's not a fixed installation. [snip...] I can't
    request a
    resend, and sending multiple copies restricts bandwidth too much. >>>>>>>
    Hmm, 17 messages in to the thread, and the group finally is told >>>>>>> some
    of the critical unstated requirements that *should* have been
    part of
    the initial message, and would have avoided about 14 "can't you
    resend"
    or "can't you send multiple" messages.

    Don't you think this above should have been in your initial post so >>>>>>> that the rest of us, who can't read your mind to divine unstated >>>>>>> limitations, were appraised of some rather critical limitations? >>>>>>>

    It's normal here to get underspecified problems. Details usually
    emerge, but some people do refuse to explain their top-secret
    projects.

    https://xyproblem.info/

    Underspecified problems do encourage lots of lateral/goofy thinking.

    Almost all of which is completely wasted. Your proposal of send it
    three times and vote best out of three being amongst them.

    There is just about enough space to do what the OP wants but whether
    or not they have the mathematical sophistication and programming
    skills to implement it quickly enough to be useful is still an open
    question.

    Of course, some people are hostile to ideas. Their career path is more >>>> McDonalds than electronic design.

    You have that *EXACTLY* backwards.

    If you cannot adequately describe the exact problem that you are
    trying to solve then you will spend vast amounts of effort solving the
    wrong problem(s) again and again. I have seen it happen many times.

    Goofy ideas aren't really welcome if they upset a sizable fraction
    of effort already invested. Ideas are cheap. Realizing them is costly.
    You'll want to be selective.

    +1

    Half the battle is specifying the problem and any hard constraints so
    that proposed solutions will actually stand a chance of working on the
    available hardware and quickly enough to be useful.


    I'm way more in JL's camp, although not 100%.  (I do more math than he does.)

    Of course you don't want to take the first thing that comes into your
    head and build that--nobody's advocating that here AFAICT.  I've seen it
    a lot in the wild, though.  In fact, one outfit I had to deal with (a CE
    in Orange County CA) kept ignoring advice that was backed up with
    detailed mathematical analysis and a _working_prototype_ of what they
    were supposed to build. (That transcutaneous blood glucose thing again.)

    They just trying things randomly until they ran through the client's
    money and then quit.  One time when I pinged them about it, a bright lad smiled and said, "That's engineering!"

    Riiighhhtt.

    But a lot, a lot of people seem to have very little emotional tolerance
    for being in a state of uncertainty.  I can't prove that, but over and
    over I've seen folks spend far too little time turning the problem over
    in their minds, talking at the white board, and so on, and just charging
    in and doing the first thing that seemed plausible.

    That's super dumb. At the beginning of the process, you have to
    cultivate offbeat ideas, because (at least in the sort of gizmos I
    build) there's usually some way to do the task much better and/or
    cheaper than what's out there.

    In general you should spend something like 10% of the time figuring out
    what you should build, and the rest designing and building it.  Skimping
    on the one very often leads to poor results on the other.

    Cheers

    Phil Hobbs

    archived

    --
    Marty

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jasen Betts@21:1/5 to Jasen Betts on Fri May 20 11:10:06 2022
    On 2022-05-20, Jasen Betts <usenet@revmaps.no-ip.org> wrote:
    On 2022-05-18, Clive Arthur <clive@nowaytoday.co.uk> wrote:
    Hi all

    I have serial data in 14 byte packets on which I'd like to detect and
    correct errors. Two bit errors would be nice. I can put 2 extra EDC
    bytes on the end to make a 16 byte packet.

    I don't have the resources for Reed-Solomon. I could use a 16 bit CRC,
    these are easy to generate with a small/moderate LUT.

    In the past, I've used a CRC16 for single bit error detection and
    correction on a longer packet, but I didn't do the error detection part.
    Errors were very rare, time was not critical, and I understand that
    this was simply done by changing each message bit in turn then
    recalculating the CRC till it all worked out. That's far to slow for my
    current needs.

    If I'm lucky, a 16 bit CRC might be able to detect and correct 2 bit
    errors in 14 bytes (112 * 111 possibilities?), but is there a way of
    quickly finding out which bits are wrong?

    Actually no there's 128 bits so there's 128 single bit errors and
    127*128/2 two bit errors, and one zero-bit error possibility that all
    need to be dealt with.

    total 8257 cases

    a look-up table. how much resources do you have?

    You say in another message less than several kilobytes.

    create a CRC to single-bit error table (use a hash table, because it's
    O(1) for lookups)

    Now you can explit the fact that CRC is a linear code, so the CRC for
    bits m and n wrong is the XOR of the crcs for bit m wrong and the crc
    of bit n wrong, (the CRC for all bits correct is of course zero after
    feeding the data and CRC into the CRC algorithm.)

    If you get a non-zero CRC on a packet look it up in the table

    If you don't find a match speculativly xor it with the first CRC in
    the table then look up the result, if it's not found, try xoring the
    next instead.

    CRC might not be the best hash to use for this task, you want
    something that gives distinct codes for all 1 and 2 bit errors, I
    haven't checked if CRC-16 has that property.

    there's 341376 three bit errors, so it's probably not going to be
    possible to even detect them using CRC-16.

    Using a 15 bit CRC code (or other linear hash code) in combination
    with a parity bit should make 3 bit errors detectable however.

    This should be do-able in 4000 or so instuction steps - not vastly worse
    than the CRC computation itself - especially if you can get perfect
    hashing in your LUT.

    --
    Jasen.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Clive Arthur@21:1/5 to Jasen Betts on Fri May 20 14:05:17 2022
    On 20/05/2022 12:10, Jasen Betts wrote:

    <snip>

    Actually no there's 128 bits so there's 128 single bit errors and
    127*128/2 two bit errors, and one zero-bit error possibility that all
    need to be dealt with.

    total 8257 cases

    a look-up table. how much resources do you have?

    You say in another message less than several kilobytes.

    create a CRC to single-bit error table (use a hash table, because it's
    O(1) for lookups)

    Now you can explit the fact that CRC is a linear code, so the CRC for
    bits m and n wrong is the XOR of the crcs for bit m wrong and the crc
    of bit n wrong, (the CRC for all bits correct is of course zero after
    feeding the data and CRC into the CRC algorithm.)

    If you get a non-zero CRC on a packet look it up in the table

    If you don't find a match speculativly xor it with the first CRC in
    the table then look up the result, if it's not found, try xoring the
    next instead.

    CRC might not be the best hash to use for this task, you want
    something that gives distinct codes for all 1 and 2 bit errors, I
    haven't checked if CRC-16 has that property.

    there's 341376 three bit errors, so it's probably not going to be
    possible to even detect them using CRC-16.

    Using a 15 bit CRC code (or other linear hash code) in combination
    with a parity bit should make 3 bit errors detectable however.

    This should be do-able in 4000 or so instuction steps - not vastly worse than the CRC computation itself - especially if you can get perfect
    hashing in your LUT.

    Thank you, that's very useful. Just one point - my CRC calculation uses
    a 512 byte LUT and is done on-the-fly taking only a few instructions for
    each byte.

    --
    Cheers
    Clive

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to All on Fri May 20 07:28:44 2022
    On Thu, 19 May 2022 20:38:24 -0700 (PDT), whit3rd <whit3rd@gmail.com>
    wrote:

    On Thursday, May 19, 2022 at 1:59:08 PM UTC-7, John Larkin wrote:
    On Thu, 19 May 2022 12:24:46 -0700 (PDT), whit3rd <whi...@gmail.com>
    wrote:
    On Thursday, May 19, 2022 at 8:03:55 AM UTC-7, jla...@highlandsniptechnology.com wrote:


    Of course, some people are hostile to ideas.

    No sane conscious mind is 'hostile to ideas' in any more general sense; that
    would be pathological, like being hostile to one's own body parts.

    Oh, lots of people are reflexively hostile to new or unconventional
    ideas. Those personalities poison brainstorming sessions.

    For those of us who haven't experienced poisoned brainstorming sessions, >describe the 'hostility'.

    Some people, especially ones with grey hair, immediately find fault
    with ideas instead of riffing on them. That intimidates some
    contributors, especially young ones. Sometimes they have sufficient
    gravity that they kill a promising discussion.

    I have to be careful that my status doesn't make people assume that
    I'm right; I don't want to be the poison.

    I have grey hair, but cannot recall ever meeting
    someone who was 'hostile to ideas' in general.

    Sounds like you haven't brainstormed a lot.




    --

    Anybody can count to one.

    - Robert Widlar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to All on Fri May 20 12:11:23 2022
    whit3rd wrote:
    On Thursday, May 19, 2022 at 1:59:08 PM UTC-7, John Larkin wrote:
    On Thu, 19 May 2022 12:24:46 -0700 (PDT), whit3rd <whi...@gmail.com>
    wrote:
    On Thursday, May 19, 2022 at 8:03:55 AM UTC-7, jla...@highlandsniptechnology.com wrote:


    Of course, some people are hostile to ideas.

    No sane conscious mind is 'hostile to ideas' in any more general sense; that
    would be pathological, like being hostile to one's own body parts.

    Oh, lots of people are reflexively hostile to new or unconventional
    ideas. Those personalities poison brainstorming sessions.

    For those of us who haven't experienced poisoned brainstorming sessions, describe the 'hostility'. I have grey hair, but cannot recall ever meeting someone who was 'hostile to ideas' in general.


    You've lived a sheltered life. Back in my early days at IBM Research, I
    was in the Manufacturing Research department. It was pretty much a gizmo-builder's paradise--an apparently endless series of hard,
    interesting, and economically important problems that needed custom
    instruments to solve, pleasant and very smart colleagues, smart and
    patient management, and very few budget constraints. A pal of mine from
    back then, the estimable Clayton Williams (now flourishing at BYU)
    needed a new lock-in amplifier. He was thinking out loud one day, "It's
    stupid to buy just one. I probably don't need five, so let's order
    two." Two shiny new lock-ins arrived in a few days. If he had needed
    five, five would have come instead.

    We were entirely self-governed--our budget came out of a big pot at
    Corporate, so the folks we were nominally serving couldn't really tell
    us what to do. Not that doing stuff randomly was encouraged, you
    understand, but we didn't have the product divisions cracking any whips
    that we had to care about. As I said, a great place to build gizmos.

    While the customers couldn't tell us what to do, there was a certain
    contingent of folks who seemed to resent this--apparently they were
    happier being able to make vendors dance to their tune. Thus they chose
    to throw rocks and tell the folks trying to do stuff that it would never
    work, that progress was unacceptable, that the instrument concept was
    all wrong, and so on and so forth. Those folks, you absolutely had to
    keep out of the planning stage of the project, or they'd trash you to
    their management and often succeed in killing the effort.

    There were also folks who wanted to swoop in once the project was on
    rails and steal the credit. There was even a select demographic that habitually did both.

    When IBM had its near-death experience in 1992, all those folks were
    gone, which was great, but so of course were the lush budgets, which
    wasn't that great. My time at IBM was like the perfect 21-year
    vacation--I was excited to start and excited to leave (as well as scared).

    Cheers

    Phil Hobbs

    --
    Dr Philip C D Hobbs
    Principal Consultant
    ElectroOptical Innovations LLC / Hobbs ElectroOptics
    Optics, Electro-optics, Photonics, Analog Electronics
    Briarcliff Manor NY 10510

    http://electrooptical.net
    http://hobbs-eo.com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Fri May 20 09:46:41 2022
    On Fri, 20 May 2022 12:11:23 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    whit3rd wrote:
    On Thursday, May 19, 2022 at 1:59:08 PM UTC-7, John Larkin wrote:
    On Thu, 19 May 2022 12:24:46 -0700 (PDT), whit3rd <whi...@gmail.com>
    wrote:
    On Thursday, May 19, 2022 at 8:03:55 AM UTC-7, jla...@highlandsniptechnology.com wrote:


    Of course, some people are hostile to ideas.

    No sane conscious mind is 'hostile to ideas' in any more general sense; that
    would be pathological, like being hostile to one's own body parts.

    Oh, lots of people are reflexively hostile to new or unconventional
    ideas. Those personalities poison brainstorming sessions.

    For those of us who haven't experienced poisoned brainstorming sessions,
    describe the 'hostility'. I have grey hair, but cannot recall ever meeting >> someone who was 'hostile to ideas' in general.


    You've lived a sheltered life. Back in my early days at IBM Research, I
    was in the Manufacturing Research department. It was pretty much a >gizmo-builder's paradise--an apparently endless series of hard,
    interesting, and economically important problems that needed custom >instruments to solve, pleasant and very smart colleagues, smart and
    patient management, and very few budget constraints. A pal of mine from
    back then, the estimable Clayton Williams (now flourishing at BYU)
    needed a new lock-in amplifier. He was thinking out loud one day, "It's >stupid to buy just one. I probably don't need five, so let's order
    two." Two shiny new lock-ins arrived in a few days. If he had needed
    five, five would have come instead.

    We were entirely self-governed--our budget came out of a big pot at >Corporate, so the folks we were nominally serving couldn't really tell
    us what to do. Not that doing stuff randomly was encouraged, you
    understand, but we didn't have the product divisions cracking any whips
    that we had to care about. As I said, a great place to build gizmos.

    While the customers couldn't tell us what to do, there was a certain >contingent of folks who seemed to resent this--apparently they were
    happier being able to make vendors dance to their tune. Thus they chose
    to throw rocks and tell the folks trying to do stuff that it would never >work, that progress was unacceptable, that the instrument concept was
    all wrong, and so on and so forth. Those folks, you absolutely had to
    keep out of the planning stage of the project, or they'd trash you to
    their management and often succeed in killing the effort.

    There were also folks who wanted to swoop in once the project was on
    rails and steal the credit. There was even a select demographic that >habitually did both.

    When IBM had its near-death experience in 1992, all those folks were
    gone, which was great, but so of course were the lush budgets, which
    wasn't that great. My time at IBM was like the perfect 21-year
    vacation--I was excited to start and excited to leave (as well as scared).

    Cheers

    Phil Hobbs

    It's interesting that none of the giant tube companies were long-term successful in semiconductors. Garage shops killed GE, RCA, Motorola,
    Sylvania, and many others.

    Efinix will be interesting to watch, against Xilinx and Altera.



    --

    Anybody can count to one.

    - Robert Widlar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From whit3rd@21:1/5 to John Larkin on Fri May 20 10:46:25 2022
    On Thursday, May 19, 2022 at 3:31:23 PM UTC-7, John Larkin wrote:

    Yes, I work more by instinct and simulation. But my world is largely nonlinear, where the math is basically impossible.

    Identifying a problem as nonlinear IS math; it's obviously useful info,
    and the only deficiency is in the non-utility of common approximations.
    The math is not impossible, just... more difficult.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From whit3rd@21:1/5 to jla...@highlandsniptechnology.com on Fri May 20 10:58:45 2022
    On Friday, May 20, 2022 at 7:28:54 AM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Thu, 19 May 2022 20:38:24 -0700 (PDT), whit3rd <whi...@gmail.com>
    wrote:

    On Thursday, May 19, 2022 at 1:59:08 PM UTC-7, John Larkin wrote:

    Oh, lots of people are reflexively hostile to new or unconventional
    ideas. Those personalities poison brainstorming sessions.

    For those of us who haven't experienced poisoned brainstorming sessions, >describe the 'hostility'.

    Some people, especially ones with grey hair, immediately find fault
    with ideas instead of riffing on them. That intimidates some
    contributors, especially young ones. Sometimes they have sufficient
    gravity that they kill a promising discussion.

    Swift fault analysis isn't hostility, it is effective argument.
    Brainstorming is a formal procedure that eliminates the scenario you describe; there are no immediate judgments.

    Competent individuals will foresee problems, and avoid them,
    but that is NOT hostility in any sense of the word. Ideas aren't opponents.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Fri May 20 11:41:10 2022
    fredag den 20. maj 2022 kl. 18.46.50 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Fri, 20 May 2022 12:11:23 -0400, Phil Hobbs <pcdhSpamM...@electrooptical.net> wrote:

    whit3rd wrote:
    On Thursday, May 19, 2022 at 1:59:08 PM UTC-7, John Larkin wrote:
    On Thu, 19 May 2022 12:24:46 -0700 (PDT), whit3rd <whi...@gmail.com>
    wrote:
    On Thursday, May 19, 2022 at 8:03:55 AM UTC-7, jla...@highlandsniptechnology.com wrote:


    Of course, some people are hostile to ideas.

    No sane conscious mind is 'hostile to ideas' in any more general sense; that
    would be pathological, like being hostile to one's own body parts.

    Oh, lots of people are reflexively hostile to new or unconventional
    ideas. Those personalities poison brainstorming sessions.

    For those of us who haven't experienced poisoned brainstorming sessions, >> describe the 'hostility'. I have grey hair, but cannot recall ever meeting >> someone who was 'hostile to ideas' in general.


    You've lived a sheltered life. Back in my early days at IBM Research, I
    was in the Manufacturing Research department. It was pretty much a >gizmo-builder's paradise--an apparently endless series of hard, >interesting, and economically important problems that needed custom >instruments to solve, pleasant and very smart colleagues, smart and
    patient management, and very few budget constraints. A pal of mine from >back then, the estimable Clayton Williams (now flourishing at BYU)
    needed a new lock-in amplifier. He was thinking out loud one day, "It's >stupid to buy just one. I probably don't need five, so let's order
    two." Two shiny new lock-ins arrived in a few days. If he had needed
    five, five would have come instead.

    We were entirely self-governed--our budget came out of a big pot at >Corporate, so the folks we were nominally serving couldn't really tell
    us what to do. Not that doing stuff randomly was encouraged, you >understand, but we didn't have the product divisions cracking any whips >that we had to care about. As I said, a great place to build gizmos.

    While the customers couldn't tell us what to do, there was a certain >contingent of folks who seemed to resent this--apparently they were
    happier being able to make vendors dance to their tune. Thus they chose
    to throw rocks and tell the folks trying to do stuff that it would never >work, that progress was unacceptable, that the instrument concept was
    all wrong, and so on and so forth. Those folks, you absolutely had to
    keep out of the planning stage of the project, or they'd trash you to
    their management and often succeed in killing the effort.

    There were also folks who wanted to swoop in once the project was on
    rails and steal the credit. There was even a select demographic that >habitually did both.

    When IBM had its near-death experience in 1992, all those folks were
    gone, which was great, but so of course were the lush budgets, which
    wasn't that great. My time at IBM was like the perfect 21-year
    vacation--I was excited to start and excited to leave (as well as scared).

    Cheers

    Phil Hobbs
    It's interesting that none of the giant tube companies were long-term successful in semiconductors. Garage shops killed GE, RCA, Motorola, Sylvania, and many others.

    the semiconductor division of Motorola became ON semiconductor in 1999, they are still a 30000 employee company ...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Fri May 20 12:36:28 2022
    On Thu, 19 May 2022 22:01:59 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    John Larkin wrote:
    On Thu, 19 May 2022 19:12:20 -0400, Phil Hobbs
    <pcdhSpamMeSenseless@electrooptical.net> wrote:

    John Larkin wrote:
    On Thu, 19 May 2022 17:10:04 -0400, Phil Hobbs
    <pcdhSpamMeSenseless@electrooptical.net> wrote:

    Martin Brown wrote:
    On 19/05/2022 16:14, Jeroen Belleman wrote:
    On 2022-05-19 17:03, jlarkin@highlandsniptechnology.com wrote:
    On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen >>>>>>>> <langwadt@fonz.dk> wrote:

    torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev
    jla...@highlandsniptechnology.com:
    On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major
    <keegan...@hotmail.com> wrote:

    Clive Arthur <cl...@nowaytoday.co.uk> wrote:
    On 19/05/2022 04:27, Sylvia Else wrote:

    Is your channel really that noisy that you cannot just discard bad
    packets?

    I don't have control over the transmission path, it may be noisy, it
    may not - it's not a fixed installation. [snip...] I can't request a
    resend, and sending multiple copies restricts bandwidth too much. >>>>>>>>>>>
    Hmm, 17 messages in to the thread, and the group finally is told some
    of the critical unstated requirements that *should* have been part of
    the initial message, and would have avoided about 14 "can't you >>>>>>>>>>> resend"
    or "can't you send multiple" messages.

    Don't you think this above should have been in your initial post so >>>>>>>>>>> that the rest of us, who can't read your mind to divine unstated >>>>>>>>>>> limitations, were appraised of some rather critical limitations? >>>>>>>>>>>

    It's normal here to get underspecified problems. Details usually >>>>>>>>>> emerge, but some people do refuse to explain their top-secret >>>>>>>>>> projects.

    https://xyproblem.info/

    Underspecified problems do encourage lots of lateral/goofy thinking. >>>>>>
    Almost all of which is completely wasted. Your proposal of send it three >>>>>> times and vote best out of three being amongst them.

    There is just about enough space to do what the OP wants but whether or >>>>>> not they have the mathematical sophistication and programming skills to >>>>>> implement it quickly enough to be useful is still an open question. >>>>>>
    Of course, some people are hostile to ideas. Their career path is more >>>>>>>> McDonalds than electronic design.

    You have that *EXACTLY* backwards.

    If you cannot adequately describe the exact problem that you are trying >>>>>> to solve then you will spend vast amounts of effort solving the wrong >>>>>> problem(s) again and again. I have seen it happen many times.

    Goofy ideas aren't really welcome if they upset a sizable fraction >>>>>>> of effort already invested. Ideas are cheap. Realizing them is costly. >>>>>>> You'll want to be selective.

    +1

    Half the battle is specifying the problem and any hard constraints so >>>>>> that proposed solutions will actually stand a chance of working on the >>>>>> available hardware and quickly enough to be useful.


    I'm way more in JL's camp, although not 100%. (I do more math than he >>>>> does.)

    Yes, I work more by instinct and simulation. But my world is largely
    nonlinear, where the math is basically impossible.


    Of course you don't want to take the first thing that comes into your >>>>> head and build that--nobody's advocating that here AFAICT. I've seen it >>>>> a lot in the wild, though. In fact, one outfit I had to deal with (a CE >>>>> in Orange County CA) kept ignoring advice that was backed up with
    detailed mathematical analysis and a _working_prototype_ of what they >>>>> were supposed to build. (That transcutaneous blood glucose thing again.) >>>>>
    They just trying things randomly until they ran through the client's >>>>> money and then quit. One time when I pinged them about it, a bright lad >>>>> smiled and said, "That's engineering!"

    Riiighhhtt.

    But a lot, a lot of people seem to have very little emotional tolerance >>>>> for being in a state of uncertainty. I can't prove that, but over and >>>>> over I've seen folks spend far too little time turning the problem over >>>>> in their minds, talking at the white board, and so on, and just charging >>>>> in and doing the first thing that seemed plausible.

    Yes. Uncertainty makes many people uncomfortable, so they lock down an >>>> architecture as soon as they can. I've seen horrors.


    That's super dumb. At the beginning of the process, you have to
    cultivate offbeat ideas, because (at least in the sort of gizmos I
    build) there's usually some way to do the task much better and/or
    cheaper than what's out there.

    In general you should spend something like 10% of the time figuring out >>>>> what you should build, and the rest designing and building it. Skimping >>>>> on the one very often leads to poor results on the other.

    Brainstorming and a period of confusion can often greatly simplify the >>>> design, or add nifty features. It's well worth the tradeoff.

    Design is a partly emotional process, which lots of engineers don't
    want to admit either.


    One time long ago, I was in a two-day class for OS/2 Presentation
    Manager programming. (I did say it was long ago.) ;)

    At one point, the presenter (who was actually very good) asked us two
    questions: Is design an art or a science? What about debugging?

    Just about everyone said that design was a science and debugging was an
    art. That's backwards.

    A design is done when the designer says it's done, generally including a >>> good long list of checks for performance, DRC, EMI, ROHS, MIL HDBK 217,
    ad nauseam. There are nearly always a ridiculously large number of
    different ways to do the job, if you count all the combinations. That
    makes it an art.

    On the other hand, troubleshooting is definitely a science. There's a
    problem someplace, because this item doesn't behave like the N previous
    ones that worked. You find it by applying critical tests and reasoning
    about them, and when the problem is found and fixed, everyone can agree
    that it's gone.

    Debugging first articles is a bit of both, because you often find design >>> screwups (hopefully minor). In my world that often includes
    layout-dependent stuff such as how high a current can you run through
    your 12 GHz pHEMT or 45-GHz SiGe BJT before it becomes unstable.
    Swapping out jumpers for beads, tweaking current sources, that sort of
    stuff.

    In rare instances it's something really stupid such as upside-down power >>> supplies on an op amp, but normally the first articles are shippable
    with maybe a roach wire or two.

    After some years, we have evolved procedures that mostly prevent
    getting V+ and V- swapped on opamps.


    We have had the occasional disaster, such as a small module with three
    SMPSes on it to make several rails from a +24V wall wart. The negative
    rails were made by an AOZ1282 async buck running off the output of an
    LMR23630 sync buck (+13 -> -12 and +24 ->+13, respectively).

    The A-O part is generally super well behaved, but the two together
    produced a _ridiculous_ selection of high harmonics of the LMR23630's
    2.15 MHz switching frequency. It was the stuff of nightmares--measuring >>> one node produced a big peak at 182 MHz, and another one nearby had
    another peak at 121 MHz, selected by various incidental resonances.

    With that one, we just cut our losses. ;(


    We recently had an LTM8078 "Silent Switcher" screaming at us in 400
    MHz bursts at 2.5 MHz. The embarassing part was that the customer
    discovered it. Oops.

    A nice ancient National 50 KHz Simple Switcher fixed that, with a
    board spin of course. And gigantic inductors.

    https://www.dropbox.com/s/ah90qsi0007ymjv/Mon_Noise_2.jpg?raw=1

    https://www.dropbox.com/s/9grk3iqwzifmw6w/Mon_Noise_LTM8078.jpg?raw=1

    I've had good luck with the 150 kHz ones too, with Schottky catch diodes
    to prevent current spikes from PN diode recovery. They do tend to need >chunky inductors to handle all those voltseconds.

    Cheers

    Phil Hobbs

    When people make mosfet substrate diodes, they tend to make them
    step-recovery diodes. There must be some semi fab reason for that.

    Adding an external schottky catch diode to a spikey synchronous
    switcher doesn't seem to help.

    This is textbook:

    https://www.dropbox.com/s/jfqojg9pvrlz7xu/SwitcherRise.JPG?raw=1

    Bottom fet turns off, reverse conducts, and then snaps.



    --

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to John Larkin on Fri May 20 16:37:41 2022
    John Larkin wrote:
    On Thu, 19 May 2022 22:01:59 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    John Larkin wrote:
    On Thu, 19 May 2022 19:12:20 -0400, Phil Hobbs
    <pcdhSpamMeSenseless@electrooptical.net> wrote:

    John Larkin wrote:
    On Thu, 19 May 2022 17:10:04 -0400, Phil Hobbs
    <pcdhSpamMeSenseless@electrooptical.net> wrote:

    Martin Brown wrote:
    On 19/05/2022 16:14, Jeroen Belleman wrote:
    On 2022-05-19 17:03, jlarkin@highlandsniptechnology.com wrote: >>>>>>>>> On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen >>>>>>>>> <langwadt@fonz.dk> wrote:

    torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev
    jla...@highlandsniptechnology.com:
    On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major
    <keegan...@hotmail.com> wrote:

    Clive Arthur <cl...@nowaytoday.co.uk> wrote:
    On 19/05/2022 04:27, Sylvia Else wrote:

    Is your channel really that noisy that you cannot just discard bad
    packets?

    I don't have control over the transmission path, it may be noisy, it
    may not - it's not a fixed installation. [snip...] I can't request a
    resend, and sending multiple copies restricts bandwidth too much. >>>>>>>>>>>>
    Hmm, 17 messages in to the thread, and the group finally is told some
    of the critical unstated requirements that *should* have been part of
    the initial message, and would have avoided about 14 "can't you >>>>>>>>>>>> resend"
    or "can't you send multiple" messages.

    Don't you think this above should have been in your initial post so
    that the rest of us, who can't read your mind to divine unstated >>>>>>>>>>>> limitations, were appraised of some rather critical limitations? >>>>>>>>>>>>

    It's normal here to get underspecified problems. Details usually >>>>>>>>>>> emerge, but some people do refuse to explain their top-secret >>>>>>>>>>> projects.

    https://xyproblem.info/

    Underspecified problems do encourage lots of lateral/goofy thinking. >>>>>>>
    Almost all of which is completely wasted. Your proposal of send it three
    times and vote best out of three being amongst them.

    There is just about enough space to do what the OP wants but whether or >>>>>>> not they have the mathematical sophistication and programming skills to >>>>>>> implement it quickly enough to be useful is still an open question. >>>>>>>
    Of course, some people are hostile to ideas. Their career path is more
    McDonalds than electronic design.

    You have that *EXACTLY* backwards.

    If you cannot adequately describe the exact problem that you are trying >>>>>>> to solve then you will spend vast amounts of effort solving the wrong >>>>>>> problem(s) again and again. I have seen it happen many times.

    Goofy ideas aren't really welcome if they upset a sizable fraction >>>>>>>> of effort already invested. Ideas are cheap. Realizing them is costly. >>>>>>>> You'll want to be selective.

    +1

    Half the battle is specifying the problem and any hard constraints so >>>>>>> that proposed solutions will actually stand a chance of working on the >>>>>>> available hardware and quickly enough to be useful.


    I'm way more in JL's camp, although not 100%. (I do more math than he >>>>>> does.)

    Yes, I work more by instinct and simulation. But my world is largely >>>>> nonlinear, where the math is basically impossible.


    Of course you don't want to take the first thing that comes into your >>>>>> head and build that--nobody's advocating that here AFAICT. I've seen it >>>>>> a lot in the wild, though. In fact, one outfit I had to deal with (a CE >>>>>> in Orange County CA) kept ignoring advice that was backed up with
    detailed mathematical analysis and a _working_prototype_ of what they >>>>>> were supposed to build. (That transcutaneous blood glucose thing again.) >>>>>>
    They just trying things randomly until they ran through the client's >>>>>> money and then quit. One time when I pinged them about it, a bright lad >>>>>> smiled and said, "That's engineering!"

    Riiighhhtt.

    But a lot, a lot of people seem to have very little emotional tolerance >>>>>> for being in a state of uncertainty. I can't prove that, but over and >>>>>> over I've seen folks spend far too little time turning the problem over >>>>>> in their minds, talking at the white board, and so on, and just charging >>>>>> in and doing the first thing that seemed plausible.

    Yes. Uncertainty makes many people uncomfortable, so they lock down an >>>>> architecture as soon as they can. I've seen horrors.


    That's super dumb. At the beginning of the process, you have to
    cultivate offbeat ideas, because (at least in the sort of gizmos I >>>>>> build) there's usually some way to do the task much better and/or
    cheaper than what's out there.

    In general you should spend something like 10% of the time figuring out >>>>>> what you should build, and the rest designing and building it. Skimping >>>>>> on the one very often leads to poor results on the other.

    Brainstorming and a period of confusion can often greatly simplify the >>>>> design, or add nifty features. It's well worth the tradeoff.

    Design is a partly emotional process, which lots of engineers don't
    want to admit either.


    One time long ago, I was in a two-day class for OS/2 Presentation
    Manager programming. (I did say it was long ago.) ;)

    At one point, the presenter (who was actually very good) asked us two
    questions: Is design an art or a science? What about debugging?

    Just about everyone said that design was a science and debugging was an >>>> art. That's backwards.

    A design is done when the designer says it's done, generally including a >>>> good long list of checks for performance, DRC, EMI, ROHS, MIL HDBK 217, >>>> ad nauseam. There are nearly always a ridiculously large number of
    different ways to do the job, if you count all the combinations. That >>>> makes it an art.

    On the other hand, troubleshooting is definitely a science. There's a >>>> problem someplace, because this item doesn't behave like the N previous >>>> ones that worked. You find it by applying critical tests and reasoning >>>> about them, and when the problem is found and fixed, everyone can agree >>>> that it's gone.

    Debugging first articles is a bit of both, because you often find design >>>> screwups (hopefully minor). In my world that often includes
    layout-dependent stuff such as how high a current can you run through
    your 12 GHz pHEMT or 45-GHz SiGe BJT before it becomes unstable.
    Swapping out jumpers for beads, tweaking current sources, that sort of >>>> stuff.

    In rare instances it's something really stupid such as upside-down power >>>> supplies on an op amp, but normally the first articles are shippable
    with maybe a roach wire or two.

    After some years, we have evolved procedures that mostly prevent
    getting V+ and V- swapped on opamps.


    We have had the occasional disaster, such as a small module with three >>>> SMPSes on it to make several rails from a +24V wall wart. The negative >>>> rails were made by an AOZ1282 async buck running off the output of an
    LMR23630 sync buck (+13 -> -12 and +24 ->+13, respectively).

    The A-O part is generally super well behaved, but the two together
    produced a _ridiculous_ selection of high harmonics of the LMR23630's
    2.15 MHz switching frequency. It was the stuff of nightmares--measuring >>>> one node produced a big peak at 182 MHz, and another one nearby had
    another peak at 121 MHz, selected by various incidental resonances.

    With that one, we just cut our losses. ;(


    We recently had an LTM8078 "Silent Switcher" screaming at us in 400
    MHz bursts at 2.5 MHz. The embarassing part was that the customer
    discovered it. Oops.

    A nice ancient National 50 KHz Simple Switcher fixed that, with a
    board spin of course. And gigantic inductors.

    https://www.dropbox.com/s/ah90qsi0007ymjv/Mon_Noise_2.jpg?raw=1

    https://www.dropbox.com/s/9grk3iqwzifmw6w/Mon_Noise_LTM8078.jpg?raw=1

    I've had good luck with the 150 kHz ones too, with Schottky catch diodes
    to prevent current spikes from PN diode recovery. They do tend to need
    chunky inductors to handle all those voltseconds.

    Cheers

    Phil Hobbs

    When people make mosfet substrate diodes, they tend to make them step-recovery diodes. There must be some semi fab reason for that.

    Adding an external schottky catch diode to a spikey synchronous
    switcher doesn't seem to help.

    The extra 5 nH in series with it isn't a bad RF choke when you've got subpicosecond edges. It might be interesting to try a small amount of inductance in the ground lead (returning all the voltage dividers and
    sync pins and so on to that point so as not to dump spikies into the
    chip). With the output reservoir cap and catch diode returned to real
    ground, one might be able to give the diode time to work.


    This is textbook:

    https://www.dropbox.com/s/jfqojg9pvrlz7xu/SwitcherRise.JPG?raw=1

    Bottom fet turns off, reverse conducts, and then snaps.

    Yeah, the LMR23630 has, like, 600 ps edges. It didn't cause problems
    until I ran the +13 -> -12 inverting buck off its output. (Going
    straight from +24 to -12 is asking a lot of a cute little SOT23
    integrated buck switcher.)

    Cheers

    Phil Hobbs


    --
    Dr Philip C D Hobbs
    Principal Consultant
    ElectroOptical Innovations LLC / Hobbs ElectroOptics
    Optics, Electro-optics, Photonics, Analog Electronics
    Briarcliff Manor NY 10510

    http://electrooptical.net
    http://hobbs-eo.com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to All on Fri May 20 18:14:00 2022
    On Fri, 20 May 2022 10:58:45 -0700 (PDT), whit3rd <whit3rd@gmail.com>
    wrote:

    On Friday, May 20, 2022 at 7:28:54 AM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Thu, 19 May 2022 20:38:24 -0700 (PDT), whit3rd <whi...@gmail.com>
    wrote:

    On Thursday, May 19, 2022 at 1:59:08 PM UTC-7, John Larkin wrote:

    Oh, lots of people are reflexively hostile to new or unconventional
    ideas. Those personalities poison brainstorming sessions.

    For those of us who haven't experienced poisoned brainstorming sessions,
    describe the 'hostility'.

    Some people, especially ones with grey hair, immediately find fault
    with ideas instead of riffing on them. That intimidates some
    contributors, especially young ones. Sometimes they have sufficient
    gravity that they kill a promising discussion.

    Swift fault analysis isn't hostility, it is effective argument.

    It is hostility and it kills ideas in their infancy. "Argument" says
    it all. Right and wrong is a zero-sum game, or usually less than zero.





    --

    Anybody can count to one.

    - Robert Widlar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to langwadt@fonz.dk on Fri May 20 18:10:41 2022
    On Fri, 20 May 2022 11:41:10 -0700 (PDT), Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    fredag den 20. maj 2022 kl. 18.46.50 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Fri, 20 May 2022 12:11:23 -0400, Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    whit3rd wrote:
    On Thursday, May 19, 2022 at 1:59:08 PM UTC-7, John Larkin wrote:
    On Thu, 19 May 2022 12:24:46 -0700 (PDT), whit3rd <whi...@gmail.com>
    wrote:
    On Thursday, May 19, 2022 at 8:03:55 AM UTC-7, jla...@highlandsniptechnology.com wrote:


    Of course, some people are hostile to ideas.

    No sane conscious mind is 'hostile to ideas' in any more general sense; that
    would be pathological, like being hostile to one's own body parts.

    Oh, lots of people are reflexively hostile to new or unconventional
    ideas. Those personalities poison brainstorming sessions.

    For those of us who haven't experienced poisoned brainstorming sessions, >> >> describe the 'hostility'. I have grey hair, but cannot recall ever meeting
    someone who was 'hostile to ideas' in general.


    You've lived a sheltered life. Back in my early days at IBM Research, I
    was in the Manufacturing Research department. It was pretty much a
    gizmo-builder's paradise--an apparently endless series of hard,
    interesting, and economically important problems that needed custom
    instruments to solve, pleasant and very smart colleagues, smart and
    patient management, and very few budget constraints. A pal of mine from
    back then, the estimable Clayton Williams (now flourishing at BYU)
    needed a new lock-in amplifier. He was thinking out loud one day, "It's
    stupid to buy just one. I probably don't need five, so let's order
    two." Two shiny new lock-ins arrived in a few days. If he had needed
    five, five would have come instead.

    We were entirely self-governed--our budget came out of a big pot at
    Corporate, so the folks we were nominally serving couldn't really tell
    us what to do. Not that doing stuff randomly was encouraged, you
    understand, but we didn't have the product divisions cracking any whips
    that we had to care about. As I said, a great place to build gizmos.

    While the customers couldn't tell us what to do, there was a certain
    contingent of folks who seemed to resent this--apparently they were
    happier being able to make vendors dance to their tune. Thus they chose
    to throw rocks and tell the folks trying to do stuff that it would never
    work, that progress was unacceptable, that the instrument concept was
    all wrong, and so on and so forth. Those folks, you absolutely had to
    keep out of the planning stage of the project, or they'd trash you to
    their management and often succeed in killing the effort.

    There were also folks who wanted to swoop in once the project was on
    rails and steal the credit. There was even a select demographic that
    habitually did both.

    When IBM had its near-death experience in 1992, all those folks were
    gone, which was great, but so of course were the lush budgets, which
    wasn't that great. My time at IBM was like the perfect 21-year
    vacation--I was excited to start and excited to leave (as well as scared). >> >
    Cheers

    Phil Hobbs
    It's interesting that none of the giant tube companies were long-term
    successful in semiconductors. Garage shops killed GE, RCA, Motorola,
    Sylvania, and many others.

    the semiconductor division of Motorola became ON semiconductor in 1999, they are still a 30000 employee company ...

    Sort of like HP spinning off Agilent spinning off Keysight. Management
    couldn't keep too many things in their heads at once.



    --

    Anybody can count to one.

    - Robert Widlar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Flyguy@21:1/5 to Flyguy on Fri May 20 21:09:17 2022
    On Friday, May 20, 2022 at 9:01:12 PM UTC-7, Flyguy wrote:
    On Friday, May 20, 2022 at 8:17:35 PM UTC-7, whit3rd wrote:
    On Friday, May 20, 2022 at 6:14:08 PM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Fri, 20 May 2022 10:58:45 -0700 (PDT), whit3rd <whi...@gmail.com> wrote:

    On Friday, May 20, 2022 at 7:28:54 AM UTC-7, jla...@highlandsniptechnology.com wrote:

    Some people, especially ones with grey hair, immediately find fault
    with ideas instead of riffing on them. That intimidates some
    contributors, especially young ones. Sometimes they have sufficient
    gravity that they kill a promising discussion.

    Swift fault analysis isn't hostility, it is effective argument.

    It is hostility and it kills ideas in their infancy. "Argument" says
    it all. Right and wrong is a zero-sum game, or usually less than zero.
    No, the term for a negative-sum argument is 'sophistry'.
    Sophistries are not valid arguments.
    Valid arguments are VALUABLE contributions.

    Some folk are timid, will prefer small incremental changes (that's
    a good strategy against uncerainty).

    Some folk are conservative, will reject novel, untried approaches (that's useful if you have a time or material budget).

    Some folk are insightful, will foresee an awkward or impossible step
    in advance.

    So, an immediate finding of fault can have lots of causes, none of which are 'hostile to ideas' in nature. And, occasionally (Boeing's 737Max comes to mind)
    a NO is the right design answer; why delay putting it on the table?
    I vote for Golay codes. Here is a short writeup: https://en.wikipedia.org/wiki/Binary_Golay_code

    And here is the actual code to implement it: https://github.com/pkdoshinji/Golay/blob/master/Golay.py

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Flyguy@21:1/5 to All on Fri May 20 21:01:07 2022
    On Friday, May 20, 2022 at 8:17:35 PM UTC-7, whit3rd wrote:
    On Friday, May 20, 2022 at 6:14:08 PM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Fri, 20 May 2022 10:58:45 -0700 (PDT), whit3rd <whi...@gmail.com>
    wrote:

    On Friday, May 20, 2022 at 7:28:54 AM UTC-7, jla...@highlandsniptechnology.com wrote:

    Some people, especially ones with grey hair, immediately find fault
    with ideas instead of riffing on them. That intimidates some
    contributors, especially young ones. Sometimes they have sufficient
    gravity that they kill a promising discussion.

    Swift fault analysis isn't hostility, it is effective argument.

    It is hostility and it kills ideas in their infancy. "Argument" says
    it all. Right and wrong is a zero-sum game, or usually less than zero.
    No, the term for a negative-sum argument is 'sophistry'.
    Sophistries are not valid arguments.
    Valid arguments are VALUABLE contributions.

    Some folk are timid, will prefer small incremental changes (that's
    a good strategy against uncerainty).

    Some folk are conservative, will reject novel, untried approaches (that's useful if you have a time or material budget).

    Some folk are insightful, will foresee an awkward or impossible step
    in advance.

    So, an immediate finding of fault can have lots of causes, none of which
    are 'hostile to ideas' in nature. And, occasionally (Boeing's 737Max comes to mind)
    a NO is the right design answer; why delay putting it on the table?

    I vote for Golay codes. Here is a short writeup: https://en.wikipedia.org/wiki/Binary_Golay_code

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From whit3rd@21:1/5 to jla...@highlandsniptechnology.com on Fri May 20 20:17:31 2022
    On Friday, May 20, 2022 at 6:14:08 PM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Fri, 20 May 2022 10:58:45 -0700 (PDT), whit3rd <whi...@gmail.com>
    wrote:

    On Friday, May 20, 2022 at 7:28:54 AM UTC-7, jla...@highlandsniptechnology.com wrote:

    Some people, especially ones with grey hair, immediately find fault
    with ideas instead of riffing on them. That intimidates some
    contributors, especially young ones. Sometimes they have sufficient
    gravity that they kill a promising discussion.

    Swift fault analysis isn't hostility, it is effective argument.

    It is hostility and it kills ideas in their infancy. "Argument" says
    it all. Right and wrong is a zero-sum game, or usually less than zero.

    No, the term for a negative-sum argument is 'sophistry'.
    Sophistries are not valid arguments.
    Valid arguments are VALUABLE contributions.

    Some folk are timid, will prefer small incremental changes (that's
    a good strategy against uncerainty).

    Some folk are conservative, will reject novel, untried approaches (that's useful if you have a time or material budget).

    Some folk are insightful, will foresee an awkward or impossible step
    in advance.

    So, an immediate finding of fault can have lots of causes, none of which
    are 'hostile to ideas' in nature. And, occasionally (Boeing's 737Max comes to mind)
    a NO is the right design answer; why delay putting it on the table?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to jlarkin@highlandsniptechnology.com on Sat May 21 21:39:52 2022
    jlarkin@highlandsniptechnology.com wrote:
    On Fri, 20 May 2022 11:41:10 -0700 (PDT), Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    fredag den 20. maj 2022 kl. 18.46.50 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Fri, 20 May 2022 12:11:23 -0400, Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    whit3rd wrote:
    On Thursday, May 19, 2022 at 1:59:08 PM UTC-7, John Larkin wrote:
    On Thu, 19 May 2022 12:24:46 -0700 (PDT), whit3rd <whi...@gmail.com> >>>>>> wrote:
    On Thursday, May 19, 2022 at 8:03:55 AM UTC-7, jla...@highlandsniptechnology.com wrote:


    Of course, some people are hostile to ideas.

    No sane conscious mind is 'hostile to ideas' in any more general sense; that
    would be pathological, like being hostile to one's own body parts. >>>>>
    Oh, lots of people are reflexively hostile to new or unconventional >>>>>> ideas. Those personalities poison brainstorming sessions.

    For those of us who haven't experienced poisoned brainstorming sessions, >>>>> describe the 'hostility'. I have grey hair, but cannot recall ever meeting
    someone who was 'hostile to ideas' in general.


    You've lived a sheltered life. Back in my early days at IBM Research, I >>>> was in the Manufacturing Research department. It was pretty much a
    gizmo-builder's paradise--an apparently endless series of hard,
    interesting, and economically important problems that needed custom
    instruments to solve, pleasant and very smart colleagues, smart and
    patient management, and very few budget constraints. A pal of mine from >>>> back then, the estimable Clayton Williams (now flourishing at BYU)
    needed a new lock-in amplifier. He was thinking out loud one day, "It's >>>> stupid to buy just one. I probably don't need five, so let's order
    two." Two shiny new lock-ins arrived in a few days. If he had needed
    five, five would have come instead.

    We were entirely self-governed--our budget came out of a big pot at
    Corporate, so the folks we were nominally serving couldn't really tell >>>> us what to do. Not that doing stuff randomly was encouraged, you
    understand, but we didn't have the product divisions cracking any whips >>>> that we had to care about. As I said, a great place to build gizmos.

    While the customers couldn't tell us what to do, there was a certain
    contingent of folks who seemed to resent this--apparently they were
    happier being able to make vendors dance to their tune. Thus they chose >>>> to throw rocks and tell the folks trying to do stuff that it would never >>>> work, that progress was unacceptable, that the instrument concept was
    all wrong, and so on and so forth. Those folks, you absolutely had to
    keep out of the planning stage of the project, or they'd trash you to
    their management and often succeed in killing the effort.

    There were also folks who wanted to swoop in once the project was on
    rails and steal the credit. There was even a select demographic that
    habitually did both.

    When IBM had its near-death experience in 1992, all those folks were
    gone, which was great, but so of course were the lush budgets, which
    wasn't that great. My time at IBM was like the perfect 21-year
    vacation--I was excited to start and excited to leave (as well as scared). >>>>
    Cheers

    Phil Hobbs
    It's interesting that none of the giant tube companies were long-term
    successful in semiconductors. Garage shops killed GE, RCA, Motorola,
    Sylvania, and many others.

    the semiconductor division of Motorola became ON semiconductor in 1999, they are still a 30000 employee company ...

    Sort of like HP spinning off Agilent spinning off Keysight. Management couldn't keep too many things in their heads at once.



    That's the classical problem with conglomerates.

    Cheers

    Phil Hobbs

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to jlarkin@highlandsniptechnology.com on Sun May 22 15:35:05 2022
    jlarkin@highlandsniptechnology.com wrote:
    On Fri, 20 May 2022 10:58:45 -0700 (PDT), whit3rd <whit3rd@gmail.com>
    wrote:

    On Friday, May 20, 2022 at 7:28:54 AM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Thu, 19 May 2022 20:38:24 -0700 (PDT), whit3rd <whi...@gmail.com>
    wrote:

    On Thursday, May 19, 2022 at 1:59:08 PM UTC-7, John Larkin wrote:

    Oh, lots of people are reflexively hostile to new or unconventional
    ideas. Those personalities poison brainstorming sessions.

    For those of us who haven't experienced poisoned brainstorming sessions, >>>> describe the 'hostility'.

    Some people, especially ones with grey hair, immediately find fault
    with ideas instead of riffing on them. That intimidates some
    contributors, especially young ones. Sometimes they have sufficient
    gravity that they kill a promising discussion.

    Swift fault analysis isn't hostility, it is effective argument.

    It is hostility and it kills ideas in their infancy. "Argument" says
    it all. Right and wrong is a zero-sum game, or usually less than zero.

    There's a bit of a semantic thicket here. I don't expect to agree with
    w3 about much of anything, but here's a possibly-useful point:
    unfortunately, popular discourse has lost the distinction between an
    argument and a quarrel.

    Properly speaking, an argument is a connected line of reasoning, by
    intention valid, that attempts to establish some proposition.

    It has to be able to withstand challenges to its validity and its
    premises, delivered without animosity.

    Arguing in that sense is great fun and leads to improved understanding
    on everybody's part--maybe you get convinced, or maybe you don't, but in
    any case it challenges you to clarify your ideas and articulate them
    better. It's a win either way, and oh, by the way, it's terrific fun
    when done well.

    Quarrelling, on the other hand, is a lose--it convinces no one, it
    isn't fun, it hardens attitudes, and it leaves bad feelings.

    W3 overlooks the key idea-generating process ahead of the rational
    arguments, but the eventual winnowing-out process does need to occur at
    some point.

    Cheers

    Phil Hobbs

    --
    Dr Philip C D Hobbs
    Principal Consultant
    ElectroOptical Innovations LLC / Hobbs ElectroOptics
    Optics, Electro-optics, Photonics, Analog Electronics
    Briarcliff Manor NY 10510

    http://electrooptical.net
    http://hobbs-eo.com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Sun May 22 16:49:16 2022
    On Sun, 22 May 2022 15:35:05 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    jlarkin@highlandsniptechnology.com wrote:
    On Fri, 20 May 2022 10:58:45 -0700 (PDT), whit3rd <whit3rd@gmail.com>
    wrote:

    On Friday, May 20, 2022 at 7:28:54 AM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Thu, 19 May 2022 20:38:24 -0700 (PDT), whit3rd <whi...@gmail.com>
    wrote:

    On Thursday, May 19, 2022 at 1:59:08 PM UTC-7, John Larkin wrote:

    Oh, lots of people are reflexively hostile to new or unconventional >>>>>> ideas. Those personalities poison brainstorming sessions.

    For those of us who haven't experienced poisoned brainstorming sessions, >>>>> describe the 'hostility'.

    Some people, especially ones with grey hair, immediately find fault
    with ideas instead of riffing on them. That intimidates some
    contributors, especially young ones. Sometimes they have sufficient
    gravity that they kill a promising discussion.

    Swift fault analysis isn't hostility, it is effective argument.

    It is hostility and it kills ideas in their infancy. "Argument" says
    it all. Right and wrong is a zero-sum game, or usually less than zero.

    There's a bit of a semantic thicket here. I don't expect to agree with
    w3 about much of anything, but here's a possibly-useful point:
    unfortunately, popular discourse has lost the distinction between an
    argument and a quarrel.

    Properly speaking, an argument is a connected line of reasoning, by
    intention valid, that attempts to establish some proposition.

    It has to be able to withstand challenges to its validity and its
    premises, delivered without animosity.

    Arguing in that sense is great fun and leads to improved understanding
    on everybody's part--maybe you get convinced, or maybe you don't, but in
    any case it challenges you to clarify your ideas and articulate them
    better. It's a win either way, and oh, by the way, it's terrific fun
    when done well.

    Quarrelling, on the other hand, is a lose--it convinces no one, it
    isn't fun, it hardens attitudes, and it leaves bad feelings.

    W3 overlooks the key idea-generating process ahead of the rational
    arguments, but the eventual winnowing-out process does need to occur at
    some point.

    Cheers

    Phil Hobbs

    Arguing, to me, implies a classic debate style, where the objective of
    every player is to be right and to prove their opponents wrong. It's
    not quarreling but is still emotional competition... the goal being to
    win.

    Brainstorming is a team-less sport played for fun, where the objective
    is to invent ideas together.

    Later on, when a few cool ideas have evolved, is the time for
    winnowing and serious engineering design.

    Not many people are comfortable or competant doing both.



    --

    Anybody can count to one.

    - Robert Widlar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From whit3rd@21:1/5 to jla...@highlandsniptechnology.com on Sun May 22 17:14:22 2022
    On Sunday, May 22, 2022 at 4:49:27 PM UTC-7, jla...@highlandsniptechnology.com wrote:

    Arguing, to me, implies a classic debate style, where the objective of
    every player is to be right and to prove their opponents wrong. It's
    not quarreling but is still emotional competition... the goal being to
    win.

    The Plato-era 'classic' works on argument call that 'gotta-win' variant sophistry, and refuted the validity of sophistical arguments while supporting logical arguments. Debate is contrivance, a game lawyers play in
    their effort to become better advocates; it isn't a productive
    exercise, nor does it attempt truth-seeking.

    Brainstorming is a team-less sport played for fun, where the objective
    is to invent ideas together.

    The psychology faculty taught me otherwise; the domination of group thinking by loud voices was hurting productivity, and they built, and tested,
    formal rules for brainstorming as a technical fix for that flaw.

    <https://en.wikipedia.org/wiki/Brainstorming>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to All on Sun May 22 19:28:39 2022
    On 5/19/2022 12:24 PM, whit3rd wrote:
    On Thursday, May 19, 2022 at 8:03:55 AM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major

    Of course, some people are hostile to ideas. Their career path is more
    McDonalds than electronic design.

    Again with the goofy personality theories! Everyone is hostile to ideas
    for a few minutes in the evening, when it's time to sleep.

    That's normal, and has nothing to do with a career path.

    That's *cranky*. I have little patience for distractions (of any kind)
    when I'm over tired (and focused on getting things in order so I can
    *rest*) or "overloaded" -- and need to get things off my plate so I can concentrate on something "new".

    No sane conscious mind is 'hostile to ideas' in any more general sense; that
    would be pathological, like being hostile to one's own body parts.

    People aren't hostile to ideas (JL sees *everything* as some aspect of hostility; an entirely passive-aggressive outlook on life).

    But, people can be resistant to the *consequences* of ideas. Direct or otherwise.

    NIH figures big in engineering. Folks always want to think their PAST accomplishment is somehow the epitome of thinking on that subject.
    This is likely some reflection on their own ego as well as a
    manifestation of "laziness" -- they aren't really interested in solving
    a problem again, even if *better*!

    And, engineering is a field where one is quickly obsolete. Especially
    if too narrow a focus in your endeavors.

    I had a stick-in-the-mud fight tooth-and-nail against replacing
    HIS decade-old analog control system with a digital one. Despite
    the fact that customers weren't buying it anymore AND sales of
    the "controlled equipment" (7 figures) were being lost because of
    this "antiquated offering".

    Another old-timer fought to preserve a part numbering system that,
    ages ago (when fewer parts were in inventory) would allow him to
    fabricate a "close approximation" to a desired part number
    using a paper cheat sheet he kept in his wallet. ("And what do we
    do when you're on vacation? Or, RETIRE??!")

    Another *principal* argued that developers should use octal
    notation to specify *opcodes* (!) using a similar "pocket assembler".
    ("Um, you know, there are tools that eliminate the need for doing
    this sort of thing. Just like there are tools that allow us to
    travel great distances without wearing out our SHOES!")

    Or, clinging to old ideas because they were patent worthy -- ten
    years ago! <rolls eyes> Despite the fact that your competitors have
    all found BETTER ways to do the same thing!

    All examples of the "that's how we USED to do it" mindset.
    ("I *built* this company using that technique!" "Yeah,
    and it hasn't *grown* in years!")

    All examples of people keeping their companies tied to the
    past and closing off opportunities to advance.

    I find email to be the single most effective tool in the design
    process:
    - It is self-documenting.
    - It supports participants at widely different locations/timezones
    - It allows the recipients time to digest the material presented.
    - It allows them time to formulate and revise their response.
    I know many folks who are lousy "thinking on their feet".
    But, given time, have tremendously valuable insights.
    - It is non-confrontational. Face to face *meetings* (not a
    one-on-one by the water cooler) have undercurrents, especially
    in small companies where folks may have agendas or jockey
    to get in the boss's good favor or risk "bucking the system".
    - It inherently dampens any "unbridled enthusiasm" that may
    be based in emotion and not reason.
    - No "voice" can overpower a conversation.
    - There's no "audience"; come as you are!
    - There's no implied (polite society) need to respond to every
    utterance. You can just let an idea die, "gracefully".
    - There's no issue of "face"
    - The Cc: list can change from one message to the next. To
    bring someone into the conversation, you just have to add
    their name to the Cc/Bcc line.
    - Participants can drop out of the conversation at will
    (imagine getting up and excusing yourself from a meeting
    and NOT being noticed for doing so!)
    - You can adjust your recipients to subsets of the group
    without offending those not involved *or* distracting
    from their ongoing conversations.
    - You can cut-and-paste bits of the conversation into your
    design specification/requirements document/manual using
    words that others have already chosen

    The biggest downside to email is a consequence of all of
    these features: the elapsed time involved. But, if you
    think you can "create on demand" or "within a specific
    timeframe", you are likely going to get only incremental
    changes to ideas. It takes time to stew on issues before
    you can formulate GOOD solutions.

    [I find the shower to be the best "facilitator"; no visual
    or audible distractions, comfortable warmth, etc. I'm
    free to "just imagine" solutions without having to
    deal with other people, pen&paper, etc.]

    But, if you're just working on small/simple problems,
    you can likely hammer out *a* solution in short order.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to blockedofcourse@foo.invalid on Sun May 22 20:49:08 2022
    On Sun, 22 May 2022 19:28:39 -0700, Don Y
    <blockedofcourse@foo.invalid> wrote:

    On 5/19/2022 12:24 PM, whit3rd wrote:
    On Thursday, May 19, 2022 at 8:03:55 AM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major

    Of course, some people are hostile to ideas. Their career path is more
    McDonalds than electronic design.

    Again with the goofy personality theories! Everyone is hostile to ideas
    for a few minutes in the evening, when it's time to sleep.

    That's normal, and has nothing to do with a career path.

    That's *cranky*. I have little patience for distractions (of any kind)
    when I'm over tired (and focused on getting things in order so I can
    *rest*) or "overloaded" -- and need to get things off my plate so I can >concentrate on something "new".

    No sane conscious mind is 'hostile to ideas' in any more general sense; that
    would be pathological, like being hostile to one's own body parts.

    People aren't hostile to ideas (JL sees *everything* as some aspect of >hostility; an entirely passive-aggressive outlook on life).

    Not at all. I'm cheerful and helpful. But there are a lot of nasty
    people here who don't design electronics.



    --

    Anybody can count to one.

    - Robert Widlar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From boB@21:1/5 to All on Sun May 22 22:54:04 2022
    On Sun, 22 May 2022 20:49:08 -0700, jlarkin@highlandsniptechnology.com
    wrote:

    On Sun, 22 May 2022 19:28:39 -0700, Don Y
    <blockedofcourse@foo.invalid> wrote:

    On 5/19/2022 12:24 PM, whit3rd wrote:
    On Thursday, May 19, 2022 at 8:03:55 AM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major

    Of course, some people are hostile to ideas. Their career path is more >>>> McDonalds than electronic design.

    Again with the goofy personality theories! Everyone is hostile to ideas >>> for a few minutes in the evening, when it's time to sleep.

    That's normal, and has nothing to do with a career path.

    That's *cranky*. I have little patience for distractions (of any kind) >>when I'm over tired (and focused on getting things in order so I can >>*rest*) or "overloaded" -- and need to get things off my plate so I can >>concentrate on something "new".

    No sane conscious mind is 'hostile to ideas' in any more general sense; that
    would be pathological, like being hostile to one's own body parts.

    People aren't hostile to ideas (JL sees *everything* as some aspect of >>hostility; an entirely passive-aggressive outlook on life).

    Not at all. I'm cheerful and helpful. But there are a lot of nasty
    people here who don't design electronics.

    You sure got that right !

    boB

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to boB on Mon May 23 06:49:39 2022
    On Sun, 22 May 2022 22:54:04 -0700, boB <boB@K7IQ.com> wrote:

    On Sun, 22 May 2022 20:49:08 -0700, jlarkin@highlandsniptechnology.com
    wrote:

    On Sun, 22 May 2022 19:28:39 -0700, Don Y
    <blockedofcourse@foo.invalid> wrote:

    On 5/19/2022 12:24 PM, whit3rd wrote:
    On Thursday, May 19, 2022 at 8:03:55 AM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen >>>>> <lang...@fonz.dk> wrote:

    torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major

    Of course, some people are hostile to ideas. Their career path is more >>>>> McDonalds than electronic design.

    Again with the goofy personality theories! Everyone is hostile to ideas >>>> for a few minutes in the evening, when it's time to sleep.

    That's normal, and has nothing to do with a career path.

    That's *cranky*. I have little patience for distractions (of any kind) >>>when I'm over tired (and focused on getting things in order so I can >>>*rest*) or "overloaded" -- and need to get things off my plate so I can >>>concentrate on something "new".

    No sane conscious mind is 'hostile to ideas' in any more general sense; that
    would be pathological, like being hostile to one's own body parts.

    People aren't hostile to ideas (JL sees *everything* as some aspect of >>>hostility; an entirely passive-aggressive outlook on life).

    Not at all. I'm cheerful and helpful. But there are a lot of nasty
    people here who don't design electronics.

    You sure got that right !

    boB




    Playing with circuits is fun. Endless ritual squabbling is boring and
    bad for you. So why do they do it here?



    --

    Anybody can count to one.

    - Robert Widlar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From boB@21:1/5 to All on Mon May 23 21:00:41 2022
    On Mon, 23 May 2022 06:49:39 -0700, jlarkin@highlandsniptechnology.com
    wrote:

    On Sun, 22 May 2022 22:54:04 -0700, boB <boB@K7IQ.com> wrote:

    On Sun, 22 May 2022 20:49:08 -0700, jlarkin@highlandsniptechnology.com >>wrote:

    On Sun, 22 May 2022 19:28:39 -0700, Don Y
    <blockedofcourse@foo.invalid> wrote:

    On 5/19/2022 12:24 PM, whit3rd wrote:
    On Thursday, May 19, 2022 at 8:03:55 AM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen >>>>>> <lang...@fonz.dk> wrote:

    torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major

    Of course, some people are hostile to ideas. Their career path is more >>>>>> McDonalds than electronic design.

    Again with the goofy personality theories! Everyone is hostile to ideas >>>>> for a few minutes in the evening, when it's time to sleep.

    That's normal, and has nothing to do with a career path.

    That's *cranky*. I have little patience for distractions (of any kind) >>>>when I'm over tired (and focused on getting things in order so I can >>>>*rest*) or "overloaded" -- and need to get things off my plate so I can >>>>concentrate on something "new".

    No sane conscious mind is 'hostile to ideas' in any more general sense; that
    would be pathological, like being hostile to one's own body parts.

    People aren't hostile to ideas (JL sees *everything* as some aspect of >>>>hostility; an entirely passive-aggressive outlook on life).

    Not at all. I'm cheerful and helpful. But there are a lot of nasty
    people here who don't design electronics.

    You sure got that right !

    boB




    Playing with circuits is fun. Endless ritual squabbling is boring and
    bad for you. So why do they do it here?

    Not sure ?

    This may be a place where they can "identify" somehow. Kind of like
    flat earthers and those who follow an alternative existence.

    They feel that they "belong" somehow.

    If I were a psychologist, I might be able to find a name for SED.

    boB

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to boB on Tue May 24 07:08:20 2022
    On Mon, 23 May 2022 21:00:41 -0700, boB <boB@K7IQ.com> wrote:

    On Mon, 23 May 2022 06:49:39 -0700, jlarkin@highlandsniptechnology.com
    wrote:

    On Sun, 22 May 2022 22:54:04 -0700, boB <boB@K7IQ.com> wrote:

    On Sun, 22 May 2022 20:49:08 -0700, jlarkin@highlandsniptechnology.com >>>wrote:

    On Sun, 22 May 2022 19:28:39 -0700, Don Y
    <blockedofcourse@foo.invalid> wrote:

    On 5/19/2022 12:24 PM, whit3rd wrote:
    On Thursday, May 19, 2022 at 8:03:55 AM UTC-7, jla...@highlandsniptechnology.com wrote:
    On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen >>>>>>> <lang...@fonz.dk> wrote:

    torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev jla...@highlandsniptechnology.com:
    On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major

    Of course, some people are hostile to ideas. Their career path is more >>>>>>> McDonalds than electronic design.

    Again with the goofy personality theories! Everyone is hostile to ideas
    for a few minutes in the evening, when it's time to sleep.

    That's normal, and has nothing to do with a career path.

    That's *cranky*. I have little patience for distractions (of any kind) >>>>>when I'm over tired (and focused on getting things in order so I can >>>>>*rest*) or "overloaded" -- and need to get things off my plate so I can >>>>>concentrate on something "new".

    No sane conscious mind is 'hostile to ideas' in any more general sense; that
    would be pathological, like being hostile to one's own body parts.

    People aren't hostile to ideas (JL sees *everything* as some aspect of >>>>>hostility; an entirely passive-aggressive outlook on life).

    Not at all. I'm cheerful and helpful. But there are a lot of nasty >>>>people here who don't design electronics.

    You sure got that right !

    boB




    Playing with circuits is fun. Endless ritual squabbling is boring and
    bad for you. So why do they do it here?

    Not sure ?

    This may be a place where they can "identify" somehow. Kind of like
    flat earthers and those who follow an alternative existence.

    They feel that they "belong" somehow.

    The subject here is electronics. The old hens don't belong.


    If I were a psychologist, I might be able to find a name for SED.

    boB



    If people want to discuss their feelings, they should go to Facebook
    or Grindr.



    --

    Anybody can count to one.

    - Robert Widlar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John S@21:1/5 to David Eather on Thu May 26 20:20:21 2022
    On 5/20/2022 1:48 AM, David Eather wrote:
    On 19/05/2022 8:46 am, John Larkin wrote:
    On Thu, 19 May 2022 08:06:25 +1000, David Eather
    <eatREMOVEher@tpg.com.au> wrote:

    On 19/05/2022 2:32 am, jlarkin@highlandsniptechnology.com wrote:
    On Wed, 18 May 2022 16:54:32 +0100, Clive Arthur
    <clive@nowaytoday.co.uk> wrote:

    Hi all

    I have serial data in 14 byte packets on which I'd like to detect and >>>>> correct errors.  Two bit errors would be nice.  I can put 2 extra EDC >>>>> bytes on the end to make a 16 byte packet.

    I don't have the resources for Reed-Solomon.  I could use a 16 bit
    CRC,
    these are easy to generate with a small/moderate LUT.

    In the past, I've used a CRC16 for single bit error detection and
    correction on a longer packet, but I didn't do the error detection
    part.
       Errors were very rare, time was not critical, and I understand that >>>>> this was simply done by changing each message bit in turn then
    recalculating the CRC till it all worked out.  That's far to slow
    for my
    current needs.

    If I'm lucky, a 16 bit CRC might be able to detect and correct 2 bit >>>>> errors in 14 bytes (112 * 111 possibilities?), but is there a way of >>>>> quickly finding out which bits are wrong?

    Or maybe a completely different approach? This has to be done on the >>>>> fly, and multi-kilobyte LUTs or thousands of clock cycles are out
    of the
    question.


    Send it three times and compare.





    you didn't read the 2 byte limit he said he had? The answer is it can't
    be done with the constraints he has specified.

    He specified a packet length limit, but didn't say he couldn't send it
    multiple times.

    I'm trying to be helpful, you are trying to be obnoxious. Do whatever
    you are best at.


    I'm being helpful - if he had such a limit on packet size he probably
    has a limit on how much he can send. What he wants is not possible with
    the limits he has described. It is helpful to let him know he has to
    reassess his limits rather than just assume he can do what you want -
    and there are more efficient ways than just send it three times.

    you were just being noise.

    And you left your filter at home, eh?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Eather@21:1/5 to John S on Fri May 27 21:22:48 2022
    On 27/05/2022 11:20 am, John S wrote:
    On 5/20/2022 1:48 AM, David Eather wrote:
    On 19/05/2022 8:46 am, John Larkin wrote:
    On Thu, 19 May 2022 08:06:25 +1000, David Eather
    <eatREMOVEher@tpg.com.au> wrote:

    On 19/05/2022 2:32 am, jlarkin@highlandsniptechnology.com wrote:
    On Wed, 18 May 2022 16:54:32 +0100, Clive Arthur
    <clive@nowaytoday.co.uk> wrote:

    Hi all

    I have serial data in 14 byte packets on which I'd like to detect and >>>>>> correct errors.  Two bit errors would be nice.  I can put 2 extra EDC >>>>>> bytes on the end to make a 16 byte packet.

    I don't have the resources for Reed-Solomon.  I could use a 16 bit >>>>>> CRC,
    these are easy to generate with a small/moderate LUT.

    In the past, I've used a CRC16 for single bit error detection and
    correction on a longer packet, but I didn't do the error detection >>>>>> part.
       Errors were very rare, time was not critical, and I understand >>>>>> that
    this was simply done by changing each message bit in turn then
    recalculating the CRC till it all worked out.  That's far to slow >>>>>> for my
    current needs.

    If I'm lucky, a 16 bit CRC might be able to detect and correct 2 bit >>>>>> errors in 14 bytes (112 * 111 possibilities?), but is there a way of >>>>>> quickly finding out which bits are wrong?

    Or maybe a completely different approach? This has to be done on the >>>>>> fly, and multi-kilobyte LUTs or thousands of clock cycles are out
    of the
    question.


    Send it three times and compare.





    you didn't read the 2 byte limit he said he had? The answer is it can't >>>> be done with the constraints he has specified.

    He specified a packet length limit, but didn't say he couldn't send it
    multiple times.

    I'm trying to be helpful, you are trying to be obnoxious. Do whatever
    you are best at.


    I'm being helpful - if he had such a limit on packet size he probably
    has a limit on how much he can send. What he wants is not possible
    with the limits he has described. It is helpful to let him know he has
    to reassess his limits rather than just assume he can do what you want
    - and there are more efficient ways than just send it three times.

    you were just being noise.

    And you left your filter at home, eh?

    the same as JL did

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to All on Sun May 29 17:28:51 2022
    On 20/05/2022 18:46, whit3rd wrote:
    On Thursday, May 19, 2022 at 3:31:23 PM UTC-7, John Larkin wrote:

    Yes, I work more by instinct and simulation. But my world is largely
    nonlinear, where the math is basically impossible.

    Identifying a problem as nonlinear IS math; it's obviously useful info,
    and the only deficiency is in the non-utility of common approximations.
    The math is not impossible, just... more difficult.

    Quadratics are non-linear and taught as high school algebra. Cubics and
    their closed form solutions are seldom taught even at degree level.

    A few other non-linear closed form solutions are known up to quartics.
    After that it is what Pade approximations are designed for.

    They cause pure mathematicians to cross themselves and run out of the
    room. That aside on a good day you can get a workable and insightful approximations for real problems that are good enough for engineering.

    Their first serious use was in taming highly divergent and hard won
    series expansions for high Mach number turbulent flow in aerospace.

    The crucial point is that they are neither provably right nor exact but
    over some moderate range of your choosing can be made good enough for
    all practical purposes (or used as a guess for NR/Halley refinement).

    --
    Regards,
    Martin Brown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)