On 04/06/2020 18:14, jlarkin@highlandsniptechnology.com wrote:> On Thu, 4 Jun 2020 16:10:35 +0100, Tom Gardner > <spamjunk@blueyonder.co.uk> wrote: > >> On 04/06/20 15:26, David Brown wrote: >>> On 04/06/2020 01:59, John Larkin wrote: >>>> >>>> My kids are pretty good with Python for test software. I ask, can you >>>> do a 5th order polynomial to calibrate that DAC? They say, sure. >>>> >>> >>> If someone asked me to make a 5th order polynomial for calibration, I'd say >>> "No. Let's look at the system and see how to handle it /properly/". Any >>> polynomial above 3rd order is likely (not guaranteed, but likely) to be wrong - >>> over-fitted, unstable, or both. >> >> Yes, good point! >> >> And any instability could be inherent in the polynomial >> and/or correction, or over time as something physically >> changes. >> >> But I wouldn't take John's "5th order" too literally; >> he was just making a quick point. >> >> But you realise that, of course. > > The official ITS thermocouple voltage-temperature equations range from > 8th order to 14th order for various thermocouples. We make both > thermocouple acquisition and simulation products. If anyone refused to > implement the ITS equations, of course I'd fire them, for stupidity if > nothing else. > > 5th is perfectly reasonable for calibrating a precision timing > instrument. I'd explain why but our best circuits are proprietary. >It is a silly way to do it. I'd explain why, but it would take too long to cover the maths. And if the "official equations" are 8th to 14th order, they too are silly. And even if they are given in that form, using a 5th order polynomial in the software is a silly way to implement it. High order polynomials have their uses - handling calibration is not one of them.
KiCad Spice, Anyone Tried It?
Started by ●June 2, 2020
Reply by ●June 4, 20202020-06-04
Reply by ●June 4, 20202020-06-04
On Thursday, June 4, 2020 at 2:33:15 PM UTC-4, David Brown wrote:> On 04/06/2020 17:10, Tom Gardner wrote: > > On 04/06/20 15:26, David Brown wrote: > >> On 04/06/2020 01:59, John Larkin wrote: > >>> > >>> My kids are pretty good with Python for test software. I ask, can you > >>> do a 5th order polynomial to calibrate that DAC? They say, sure. > >>> > >> > >> If someone asked me to make a 5th order polynomial for calibration, > >> I'd say "No. Let's look at the system and see how to handle it > >> /properly/". Any polynomial above 3rd order is likely (not > >> guaranteed, but likely) to be wrong - over-fitted, unstable, or both. > > > > Yes, good point! > > > > And any instability could be inherent in the polynomial > > and/or correction, or over time as something physically > > changes. > > > > But I wouldn't take John's "5th order" too literally; > > he was just making a quick point. > > > > But you realise that, of course. > > Yes, I assume so. > > It does happen that people think that fitting a high-order polynomial to > their data is a good idea because they can make a "perfect" fit for > their sample points, and then are surprised when interpolated (and > especially extrapolated) points are a complete mess. > > But I would not expect John to make that mistake in practice.There is a difference between analyzing some effect and calibrating a sensor. A good example is a thermistor. The equations are not complex, but most sources seem to make a hash of explaining how to use them. A simple solution is to use data and fit a polynomial to it with whatever order is required to meet your accuracy needs. The higher order terms will all have small coefficients and the resulting curve will be very well behaved. Besides, if you use enough data the result will pass through all the data points you will ever see. lol -- Rick C. ---- Get 1,000 miles of free Supercharging ---- Tesla referral code - https://ts.la/richard11209
Reply by ●June 4, 20202020-06-04
On 04/06/20 18:14, John Larkin wrote:> On Thu, 4 Jun 2020 17:42:22 +0100, Tom Gardner > <spamjunk@blueyonder.co.uk> wrote: > >> On 04/06/20 17:22, jlarkin@highlandsniptechnology.com wrote: >>> On Thu, 4 Jun 2020 16:10:06 +0100, Tom Gardner >>> <spamjunk@blueyonder.co.uk> wrote: >>> >>>> On 04/06/20 00:59, John Larkin wrote: >>>>> On Thu, 4 Jun 2020 00:25:35 +0100, Tom Gardner >>>>> <spamjunk@blueyonder.co.uk> wrote: >>>>> >>>>>> On 03/06/20 21:21, John Larkin wrote: >>>>>>> On Wed, 3 Jun 2020 17:33:30 +0100, Tom Gardner >>>>>>> <spamjunk@blueyonder.co.uk> wrote: >>>>>>>> >>>>>>>> The similarities outweigh the differences. >>>>>>> >>>>>>> The similarities of that statement, six times, are tedious. >>>>>> >>>>>> Your misapprehensions on this topic are legion >>>>>> and repetitive. >>>>>> >>>>>> >>>>>>> Do you design electronics? >>>>>> >>>>>> I did, for decades. >>>>>> >>>>>> I also designed and implemented server-side software >>>>>> for decades. >>>>>> >>>>>> Do you implement such software? >>>>>> >>>>>> (I believe you have said you leave that to others.) >>>>> >>>>> I wrote two compilers and three pre-emptive RTOSs and maybe a hundred >>>>> embedded programs, >>>> It is worth pointing out that all of those examples are >>>> (almost certainly) very different to general purpose software >>>> and, especially, to application servers and the applications >>>> that run within them. >>> >>> What's not general about an RTOS? Thousands of units were sold. >> >> It is a single specialised program than can be used in >> different end equipment. >> >> There's far more to software and software development >> than that. >> >> >> >>>> Ditto your organisation and the organisations that write/maintain >>>> such codebases. >>>> >>>> Thus it is unsurprising that you do not understand modern >>>> medium/large scale software and software practices. Especially >>>> the congruences with medium/large scale hardware. >>> >>> This is an electronic design group. I deal with the software that >>> makes electronic instruments work. My relationship to servers is that >>> I have to talk to them, feed them javascript and UDP packets and such. >> >> No doubt. >> >> But it confirms that you have no experience of creating >> large-scale software systems using modern techniques. > > Good grief, this is an electronic design forum. I'm an electrical > engineer.Software and electronic have been completely entwined for almost half a century. As a competent electronic engineer you are unwise to make strong statements in spheres where you have limited experience. Large scale software, for example. Ditto other spheres, of course.>> It is therefore unsurprising that you haven't understood >> the congruences with hardware. >> >> Back in the 90s, when the "modern" technologies were moving >>from academia to industry, many softies had "hardware envy". >> Consequently they tried to mimic the perceived beneficial >> aspects of hardware. > > Try washing your dishes, or driving to the beach, with software.Try eating hardware!> Two resulting technologies that have >> become very important are OOD/OOP and application servers. >> They aren't relevant to RTOSs, and aren't necessary for >> network-level programming. >> >> Hence it is unsurprising that you aren't familiar with them. >> >> But they do exist and do have certain characteristics, even >> if you aren't familiar with them. > > I'm not familiar with knitting either.Do you make sweeping statements about knitting? If not, then no problems will arise.
Reply by ●June 4, 20202020-06-04
On 04/06/2020 17:15, Jeroen Belleman wrote:> David Brown wrote: >> On 04/06/2020 01:59, John Larkin wrote: >>> >>> My kids are pretty good with Python for test software. I ask, can you >>> do a 5th order polynomial to calibrate that DAC? They say, sure. >>> >> >> If someone asked me to make a 5th order polynomial for calibration, >> I'd say "No. Let's look at the system and see how to handle it >> /properly/". Any polynomial above 3rd order is likely (not >> guaranteed, but likely) to be wrong - over-fitted, unstable, or both. > > Bof. The polynomial would have a big linear term and a few > tiny higher order terms, and only used within its domain. > Should be safe enough. I do wonder if it's worth the trouble. > DAC non-linearities tend to be jumpy, with sharp discontinuities > at major bit transitions. > > How would you handle it? >It would depend on the accuracy needed, the quality of the source data (there's no point in closely fitting to inaccurate data), the non-linearities, and type of processor hardware you have, the speed you need, and other factors. A cubic spline is typically a good balance - you get a smooth function (with a Hermite spline, you get a continuous derivative - no jumps), no unexpected oscillations or large errors between points, simple and stable numerical analysis to figure out the coefficients, easy scalability to balance table size against detail, and very simple and efficient calculations at run-time. For many applications, a linear interpolation table is good enough. If the original data supports it, there might be other types of curves that fit better. I don't know of any physical phenomenon where a high degree polynomial would be the natural fit for an effect - this sounds like it is empirical data from measurements and someone has incorrectly thought that a formula is better than a table.
Reply by ●June 4, 20202020-06-04
On Thu, 4 Jun 2020 20:38:51 +0200, David Brown <david.brown@hesbynett.no> wrote:>On 04/06/2020 18:14, jlarkin@highlandsniptechnology.com wrote: >> On Thu, 4 Jun 2020 16:10:35 +0100, Tom Gardner >> <spamjunk@blueyonder.co.uk> wrote: >> >>> On 04/06/20 15:26, David Brown wrote: >>>> On 04/06/2020 01:59, John Larkin wrote: >>>>> >>>>> My kids are pretty good with Python for test software. I ask, can you >>>>> do a 5th order polynomial to calibrate that DAC? They say, sure. >>>>> >>>> >>>> If someone asked me to make a 5th order polynomial for calibration, I'd say >>>> "No.� Let's look at the system and see how to handle it /properly/". �Any >>>> polynomial above 3rd order is likely (not guaranteed, but likely) to be wrong - >>>> over-fitted, unstable, or both. >>> >>> Yes, good point! >>> >>> And any instability could be inherent in the polynomial >>> and/or correction, or over time as something physically >>> changes. >>> >>> But I wouldn't take John's "5th order" too literally; >>> he was just making a quick point. >>> >>> But you realise that, of course. >> >> The official ITS thermocouple voltage-temperature equations range from >> 8th order to 14th order for various thermocouples. We make both >> thermocouple acquisition and simulation products. If anyone refused to >> implement the ITS equations, of course I'd fire them, for stupidity if >> nothing else. >> >> 5th is perfectly reasonable for calibrating a precision timing >> instrument. I'd explain why but our best circuits are proprietary. >> > >It is a silly way to do it. I'd explain why, but it would take too long >to cover the maths. And if the "official equations" are 8th to 14th >order, they too are silly. And even if they are given in that form, >using a 5th order polynomial in the software is a silly way to implement it. > >High order polynomials have their uses - handling calibration is not one >of them.Hang on to that resume for a while, OK? -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
Reply by ●June 4, 20202020-06-04
On 04/06/2020 17:31, jlarkin@highlandsniptechnology.com wrote:> On Thu, 4 Jun 2020 16:26:12 +0200, David Brown > <david.brown@hesbynett.no> wrote: > >> On 04/06/2020 01:59, John Larkin wrote: >>> >>> My kids are pretty good with Python for test software. I ask, can you >>> do a 5th order polynomial to calibrate that DAC? They say, sure. >>> >> >> If someone asked me to make a 5th order polynomial for calibration, I'd >> say "No. > > And I'd fire you, and we'd both be happy.What a telling reaction. Norway invariably beats the USA on all "happiness" comparisons. And the two biggest differences I see between how people work in the USA and how people work in Norway is that over here, if the boss tells you to do something stupid, you question him or her. The other is that we have job security - you need a very good reason, and a sensible time frame, in order to fire someone. This all gives a health, cooperative and supportive working relationship instead of employees who spend their lives terrified of irritating their boss and ending up on the street (and simultaneously losing their health care).> > Let's look at the system and see how to handle it /properly/". >> Any polynomial above 3rd order is likely (not guaranteed, but likely) >> to be wrong - over-fitted, unstable, or both. >> >>>> >>>> Nowadays most systems/products are a combination of hardware >>>> and software. Choosing the appropriate boundary between the two >>>> is often critical, and distressingly few people can do it >>>> effectively. >>> >>> It's great fun to design a product where you can do stuff analog or >>> digital, in hardware or FPGA or uP code. Brainstorming with the FPGA >>> and c people helps a lot. >>> >>> I do have a hard time pinning the c people down to times. Can you run >>> that IRQ at 200 KHz for me? >>> >> >> Sure - /if/ you've got the right hardware, and proper specifications for >> the task. > > I knew he could run my filter/control algorithm at 200K, and in fact > crank down the CPU clock to save power. But it's hard to get classic c > programmers to push the realtime limits, or to even estimate runtimes. >I don't know what the phrase "classic C programmer" might mean.> I wrote a couple of cross-assemblers that added instruction execution > times to the listing so I could see runtimes directly. Caches and such > make that less precise nowadays. >All sorts of things make it difficult to calculate accurately the run time of non-trivial code. You might be able to make some rough estimates, but generally measurement is better.
Reply by ●June 4, 20202020-06-04
On Thu, 4 Jun 2020 20:09:03 +0100, Tom Gardner <spamjunk@blueyonder.co.uk> wrote:>On 04/06/20 18:14, John Larkin wrote: >> On Thu, 4 Jun 2020 17:42:22 +0100, Tom Gardner >> <spamjunk@blueyonder.co.uk> wrote: >> >>> On 04/06/20 17:22, jlarkin@highlandsniptechnology.com wrote: >>>> On Thu, 4 Jun 2020 16:10:06 +0100, Tom Gardner >>>> <spamjunk@blueyonder.co.uk> wrote: >>>> >>>>> On 04/06/20 00:59, John Larkin wrote: >>>>>> On Thu, 4 Jun 2020 00:25:35 +0100, Tom Gardner >>>>>> <spamjunk@blueyonder.co.uk> wrote: >>>>>> >>>>>>> On 03/06/20 21:21, John Larkin wrote: >>>>>>>> On Wed, 3 Jun 2020 17:33:30 +0100, Tom Gardner >>>>>>>> <spamjunk@blueyonder.co.uk> wrote: >>>>>>>>> >>>>>>>>> The similarities outweigh the differences. >>>>>>>> >>>>>>>> The similarities of that statement, six times, are tedious. >>>>>>> >>>>>>> Your misapprehensions on this topic are legion >>>>>>> and repetitive. >>>>>>> >>>>>>> >>>>>>>> Do you design electronics? >>>>>>> >>>>>>> I did, for decades. >>>>>>> >>>>>>> I also designed and implemented server-side software >>>>>>> for decades. >>>>>>> >>>>>>> Do you implement such software? >>>>>>> >>>>>>> (I believe you have said you leave that to others.) >>>>>> >>>>>> I wrote two compilers and three pre-emptive RTOSs and maybe a hundred >>>>>> embedded programs, >>>>> It is worth pointing out that all of those examples are >>>>> (almost certainly) very different to general purpose software >>>>> and, especially, to application servers and the applications >>>>> that run within them. >>>> >>>> What's not general about an RTOS? Thousands of units were sold. >>> >>> It is a single specialised program than can be used in >>> different end equipment. >>> >>> There's far more to software and software development >>> than that. >>> >>> >>> >>>>> Ditto your organisation and the organisations that write/maintain >>>>> such codebases. >>>>> >>>>> Thus it is unsurprising that you do not understand modern >>>>> medium/large scale software and software practices. Especially >>>>> the congruences with medium/large scale hardware. >>>> >>>> This is an electronic design group. I deal with the software that >>>> makes electronic instruments work. My relationship to servers is that >>>> I have to talk to them, feed them javascript and UDP packets and such. >>> >>> No doubt. >>> >>> But it confirms that you have no experience of creating >>> large-scale software systems using modern techniques. >> >> Good grief, this is an electronic design forum. I'm an electrical >> engineer. > >Software and electronic have been completely entwined for >almost half a century. > >As a competent electronic engineer you are unwise to make >strong statements in spheres where you have limited experience.Unwise? Because I don't meet your expectations? Because I use ITC thermocouple equations? We get purchase orders for electronics things, from people that you have heard of, and they are happy with what we make for them. Given that, or being some google coder droid, I like the hardware. Post some electronics now and then and we'll discuss it. -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
Reply by ●June 4, 20202020-06-04
On Thursday, June 4, 2020 at 3:39:27 PM UTC-4, John Larkin wrote:> On Thu, 4 Jun 2020 20:38:51 +0200, David Brown > <david.brown@hesbynett.no> wrote: > > >On 04/06/2020 18:14, jlarkin@highlandsniptechnology.com wrote: > >> On Thu, 4 Jun 2020 16:10:35 +0100, Tom Gardner > >> <spamjunk@blueyonder.co.uk> wrote: > >> > >>> On 04/06/20 15:26, David Brown wrote: > >>>> On 04/06/2020 01:59, John Larkin wrote: > >>>>> > >>>>> My kids are pretty good with Python for test software. I ask, can you > >>>>> do a 5th order polynomial to calibrate that DAC? They say, sure. > >>>>> > >>>> > >>>> If someone asked me to make a 5th order polynomial for calibration, I'd say > >>>> "No. Let's look at the system and see how to handle it /properly/". Any > >>>> polynomial above 3rd order is likely (not guaranteed, but likely) to be wrong - > >>>> over-fitted, unstable, or both. > >>> > >>> Yes, good point! > >>> > >>> And any instability could be inherent in the polynomial > >>> and/or correction, or over time as something physically > >>> changes. > >>> > >>> But I wouldn't take John's "5th order" too literally; > >>> he was just making a quick point. > >>> > >>> But you realise that, of course. > >> > >> The official ITS thermocouple voltage-temperature equations range from > >> 8th order to 14th order for various thermocouples. We make both > >> thermocouple acquisition and simulation products. If anyone refused to > >> implement the ITS equations, of course I'd fire them, for stupidity if > >> nothing else. > >> > >> 5th is perfectly reasonable for calibrating a precision timing > >> instrument. I'd explain why but our best circuits are proprietary. > >> > > > >It is a silly way to do it. I'd explain why, but it would take too long > >to cover the maths. And if the "official equations" are 8th to 14th > >order, they too are silly. And even if they are given in that form, > >using a 5th order polynomial in the software is a silly way to implement it. > > > >High order polynomials have their uses - handling calibration is not one > >of them. > > Hang on to that resume for a while, OK?How can anyone say this guy is not a troll? It's not about the electronics for him. It's about the drama. -- Rick C. ---+ Get 1,000 miles of free Supercharging ---+ Tesla referral code - https://ts.la/richard11209
Reply by ●June 4, 20202020-06-04
On Thu, 4 Jun 2020 21:43:14 +0200, David Brown <david.brown@hesbynett.no> wrote:>On 04/06/2020 17:31, jlarkin@highlandsniptechnology.com wrote: >> On Thu, 4 Jun 2020 16:26:12 +0200, David Brown >> <david.brown@hesbynett.no> wrote: >> >>> On 04/06/2020 01:59, John Larkin wrote: >>>> >>>> My kids are pretty good with Python for test software. I ask, can you >>>> do a 5th order polynomial to calibrate that DAC? They say, sure. >>>> >>> >>> If someone asked me to make a 5th order polynomial for calibration, I'd >>> say "No. >> >> And I'd fire you, and we'd both be happy. > >What a telling reaction. > >Norway invariably beats the USA on all "happiness" comparisons. And the >two biggest differences I see between how people work in the USA and how >people work in Norway is that over here, if the boss tells you to do >something stupid, you question him or her.You didn't say you would question, you said that you'd refuse. I was kinda surprised when one of my engineers told me that a 5th order poly was best to calibrate a timing system. But since he was right, I didn't say "No" or anything obtuse like that. We can easily take a couple hundred data points to picosecond, sometimes femtosecond, accuracy. Lots of points smooths out the jitter. The other is that we have>job security - you need a very good reason, and a sensible time frame, >in order to fire someone. This all gives a health, cooperative and >supportive working relationship instead of employees who spend their >lives terrified of irritating their boss and ending up on the street >(and simultaneously losing their health care).California is an "at will" state; we can lay off or fire anyone, any time, for any reason or none. Similarly, they can quit any time they want, walk right out the door, no matter how much it might damage the company. That's symmetric. No boss has ever terrified me; quite the opposite.> >> >> Let's look at the system and see how to handle it /properly/". >>> Any polynomial above 3rd order is likely (not guaranteed, but likely) >>> to be wrong - over-fitted, unstable, or both. >>> >>>>> >>>>> Nowadays most systems/products are a combination of hardware >>>>> and software. Choosing the appropriate boundary between the two >>>>> is often critical, and distressingly few people can do it >>>>> effectively. >>>> >>>> It's great fun to design a product where you can do stuff analog or >>>> digital, in hardware or FPGA or uP code. Brainstorming with the FPGA >>>> and c people helps a lot. >>>> >>>> I do have a hard time pinning the c people down to times. Can you run >>>> that IRQ at 200 KHz for me? >>>> >>> >>> Sure - /if/ you've got the right hardware, and proper specifications for >>> the task. >> >> I knew he could run my filter/control algorithm at 200K, and in fact >> crank down the CPU clock to save power. But it's hard to get classic c >> programmers to push the realtime limits, or to even estimate runtimes. >> > >I don't know what the phrase "classic C programmer" might mean. > >> I wrote a couple of cross-assemblers that added instruction execution >> times to the listing so I could see runtimes directly. Caches and such >> make that less precise nowadays. >> > >All sorts of things make it difficult to calculate accurately the run >time of non-trivial code. You might be able to make some rough >estimates, but generally measurement is better.That's what I have to do, use an oscilloscope to show programmers what their code does. You can often relate the pulse widths to paths through the code. -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
Reply by ●June 4, 20202020-06-04
On 04/06/2020 22:08, John Larkin wrote:> On Thu, 4 Jun 2020 21:43:14 +0200, David Brown > <david.brown@hesbynett.no> wrote: > >> On 04/06/2020 17:31, jlarkin@highlandsniptechnology.com wrote: >>> On Thu, 4 Jun 2020 16:26:12 +0200, David Brown >>> <david.brown@hesbynett.no> wrote: >>> >>>> On 04/06/2020 01:59, John Larkin wrote: >>>>> >>>>> My kids are pretty good with Python for test software. I ask, can you >>>>> do a 5th order polynomial to calibrate that DAC? They say, sure. >>>>> >>>> >>>> If someone asked me to make a 5th order polynomial for calibration, I'd >>>> say "No. >>> >>> And I'd fire you, and we'd both be happy. >> >> What a telling reaction. >> >> Norway invariably beats the USA on all "happiness" comparisons. And the >> two biggest differences I see between how people work in the USA and how >> people work in Norway is that over here, if the boss tells you to do >> something stupid, you question him or her. > > You didn't say you would question, you said that you'd refuse.That's just a matter of emphasis and initial reaction.> > I was kinda surprised when one of my engineers told me that a 5th > order poly was best to calibrate a timing system. But since he was > right, I didn't say "No" or anything obtuse like that. We can easily > take a couple hundred data points to picosecond, sometimes > femtosecond, accuracy. Lots of points smooths out the jitter. >I'd take a lot of convincing to believe that a 5th order polynomial is the right choice here.> > > > The other is that we have >> job security - you need a very good reason, and a sensible time frame, >> in order to fire someone. This all gives a health, cooperative and >> supportive working relationship instead of employees who spend their >> lives terrified of irritating their boss and ending up on the street >> (and simultaneously losing their health care). > > California is an "at will" state; we can lay off or fire anyone, any > time, for any reason or none. Similarly, they can quit any time they > want, walk right out the door, no matter how much it might damage the > company. > > That's symmetric. >That's stupid. (It is by no means your fault - don't imagine it is an insult. And you can be sure I can find some stupid things about the way things work in Norway too.)> No boss has ever terrified me; quite the opposite. >With the Norwegian system, no one gets terrified. (Just as you can't fire someone immediately without exceptional reason - such as criminal activity, endangering the health or lives of others, etc. - you can't leave a job immediately. It is also symmetric - but safe for both sides.)> > >> >>> I wrote a couple of cross-assemblers that added instruction execution >>> times to the listing so I could see runtimes directly. Caches and such >>> make that less precise nowadays. >>> >> >> All sorts of things make it difficult to calculate accurately the run >> time of non-trivial code. You might be able to make some rough >> estimates, but generally measurement is better. > > That's what I have to do, use an oscilloscope to show programmers what > their code does. You can often relate the pulse widths to paths > through the code. >A scope can be a fine tool for measuring code performance. I like to make sure there are a few test pins on our boards that can be connected to an oscilloscope precisely for measuring critical code. Not all programmers understand how to instrument code for such measurements, unfortunately.
