Error correction in short packet.

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.

Reply to
David Eather
Loading thread data ...

archived

Reply to
marty
<snip>

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.

Reply to
Clive Arthur

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

Sounds like you haven't brainstormed a lot.

Reply to
jlarkin

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

Reply to
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.

Reply to
jlarkin

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.

Reply to
whit3rd

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.

Reply to
whit3rd

fredag den 20. maj 2022 kl. 18.46.50 UTC+2 skrev snipped-for-privacy@highlandsniptechnology.com:

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

Reply to
Lasse Langwadt Christensen

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:

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

Reply to
John Larkin

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.

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

Reply to
Phil Hobbs

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

Reply to
jlarkin

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.

Reply to
jlarkin

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?

Reply to
whit3rd

I vote for Golay codes. Here is a short writeup:

formatting link

Reply to
Flyguy

And here is the actual code to implement it:

formatting link

Reply to
Flyguy

That's the classical problem with conglomerates.

Cheers

Phil Hobbs

Reply to
Phil Hobbs

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

Reply to
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.

Reply to
jlarkin

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.

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.

formatting link
Reply to
whit3rd

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.