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.
KiCad Spice, Anyone Tried It?
Started by ●June 2, 2020
Reply by ●June 4, 20202020-06-04
Reply by ●June 4, 20202020-06-04
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? Jeroen Belleman
Reply by ●June 4, 20202020-06-04
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. 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 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. -- John Larkin Highland Technology, Inc Science teaches us to doubt. Claude Bernard
Reply by ●June 4, 20202020-06-04
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. -- John Larkin Highland Technology, Inc Science teaches us to doubt. Claude Bernard
Reply by ●June 4, 20202020-06-04
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.> >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. There are other forums for coders, people who work so far up the abstraction stack that they know nothing about computers or timing or electricity. -- John Larkin Highland Technology, Inc Science teaches us to doubt. Claude Bernard
Reply by ●June 4, 20202020-06-04
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. 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. 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.
Reply by ●June 4, 20202020-06-04
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.> >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. 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. -- 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 Wed, 3 Jun 2020 17:56:48 -0700 (PDT), jjhudak4@gmail.com wrote:>On Wednesday, June 3, 2020 at 4:22:07 PM UTC-4, John Larkin wrote: >> On Wed, 3 Jun 2020 17:33:30 +0100, Tom Gardner >> <spamjunk@blueyonder.co.uk> wrote: >> >> >On 03/06/20 16:51, jlarkin@highlandsniptechnology.com wrote: >> >> On Wed, 3 Jun 2020 15:21:21 +0100, Tom Gardner >> >> <spamjunk@blueyonder.co.uk> wrote: >> >> >> >>> On 03/06/20 08:34, Ricketty C wrote: >> >>>> I guess I spoke too soon about KiCad being easy to pick up... well it isn't >> >>>> about picking up really. It's about issues of multiple pages. They don't >> >>>> really support a flat, multi-page schematic. It must be hierarchical. So to >> >>>> have a two page schematic, you must have a top sheet and one or more lower >> >>>> sheets. >> >>>> >> >>>> The parts can have multiple units, but schematics can't have multiple pages. >> >>>> That seems oddly inconsistent. >> >>> >> >>> Another viewpoint is to consider the analogous situation in >> >>> large-scale software systems. >> >>> >> >>> For one person developing a small piece of code, nothing much >> >>> is needed. >> >>> >> >>> But in a large system that requires modification over the years, >> >>> it has been found necessary to develop techniques that have >> >>> the same characteristics as hierarchical hardware schematics. >> >>> >> >>> Example 1: all the various UML structural component diagrams. >> >>> >> >>> Example 2: the currently fashionable "inversion of control" >> >>> techniques. If you sit down and think about what they are >> >>> attempting to rectify, and how they are doing it, then you >> >>> see they are connecting stand-alone components and sub-components >> >>> in a hierarchy. >> > >> >I don't think you are aware of what's in medium and >> >large scale software. >> >> I am aware that a big program will have thousands of bugs in its >> lifetime, and may be remotely updated every month or so. >> >> > >> > >> >> A PCB is very different from code. Multiple copies have to be >> >> assembled my manufacturing, >> > >> >The similarities outweigh the differences. >> >> We don't prototype and expect rev A to be built by production, to >> released drawings, and we expect it to work and be shipped. The first >> release that we test, we expect to ship to a paying customer. >> >> Does anyone do software that way? >> >> >> >> >> > >> >Simple examples: operating systems, servers, server >> >applications. >> > >> > >> >> from purchased or fabricated parts. >> > >> >The similarities outweigh the differences. >> > >> >Simple examples: libraries, servers. >> > >> > >> >> Each board needs to be inspected and tested. >> > >> >The similarities outweigh the differences. >> > >> >Simple examples: one application installed in different >> >servers optionally in different companies. >> > >> > >> >> If changes must be made, they >> >> will be applied, per an ECO, to every board, by manufacturing. >> > >> >The similarities outweigh the differences. >> > >> >Simple examples: each application installed in each server. >> > >> > >> >> Field changes are physical and expensive. >> > >> >The similarities outweigh the differences. >> >> The similarities of that statement, six times, are tedious. >> >> Do you design electronics? >> >> > >> >Arguably it is more difficult to correctly change software. >> >> ??? Hardware change requires releasing an ECO, getting physical access >> to the product, and doing mechanical things, then testing and >> calibrating. >> >> > >> > >> >> A computer program doesn't need many identical copies of a subroutine. >> >> A circuit board often does, but they usually wind up be not quite >> >> exactly identical. They are certainly physically distinct, even if >> >> they look alike on paper. >> > >> >The similarities outweigh the differences. >> >> Oh please. Repeating a thing N times doesn't make it true. >> >> > >> >Simple examples: objects, classes, and class hierarchies, >> >definitions of things such as "a person" or "the time". >> > >> > >> >> Computer programs don't need ground or power planes. >> > >> >Agreed, but so what! >> > >> > >> >> They should have >> >> test points and BIST, but they seldom do. >> > >> >No difference :( >> > >> > >> >> Very different. >> > >> >Nope. >> >> Do you design electronics? Schematics, pcb layouts, parts on boards? >> >> Few posters to s.e.d. actually do. Fewer are very good at it. >> >> >> >> >> >> -- >> >> John Larkin Highland Technology, Inc >> picosecond timing precision measurement >> >> jlarkin att highlandtechnology dott com >> http://www.highlandtechnology.com > >> > Does anyone do software that way? >Yes they do, or they are taught that way. The perspective of 'sw is easy to change if we don't get it right' is at least 30 year old school. Software gets 'wrong' for a lot of reasons-too many to enumerate here.Nobody can argue with that. -- 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: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.
Reply by ●June 4, 20202020-06-04
On Thursday, June 4, 2020 at 1:14:31 PM UTC-4, John Larkin wrote:> > Try washing your dishes, or driving to the beach, with software.Press button on steering wheel, "Drive to beach", select beach. Ok, where next? Yeah, I think that was software. The Tesla cars literally could not exist in any semblance of their current form without software. I'm not talking about the fancy doodads. I'm saying the only practical way to make such a vehicle practical, safe and prevent it from being harmed by misuse is the many tons of software "inside". Probably the greatest feature is that the car's software can be updated via downloads. The features on my car have continually improved with every update including performance and safety features. Try doing that purely with hardware. -- Rick C. +++ Get 1,000 miles of free Supercharging +++ Tesla referral code - https://ts.la/richard11209
