we don´t even know the block schematics yet and you start thinking about the end of the rope?
Measurement devices don´t ineviteably require computers, scripts
I see your point, but the OP already indicated that his instrument will be controlled by a PC. My experience with such devices is that the software that comes with the I instrument is great for what it does, but it usually does not do things the way I need/want them to be, although the hardware would easily allow it. That's why I started to ask for full documentation of the computer interface, which allows me to write my own software the way I need/want it.
I will release the full protocol and how to talk to the unit via the USB port etc.. on release of the CT. It's not super easy to talk with as it's designed for fast communication with the host PC over USB (we use EPIC to do some of the heavy lifting), but happy to assist anyone who wants to write their own interface.
We don't charge for our software BTW. My business model is to make money from hardware (mainly).
Also, if there are a set of tests etc.. that someone feels they'd like implemented with our system, then just shout - there's a likelyhood that others will want it to.
We don't charge for our software BTW. My business model is to make money from hardware (mainly).
Also, if there are a set of tests etc.. that someone feels they'd like implemented with our system, then just shout - there's a likelyhood that others will want it to.
Last edited:
Hi Calvin, I'm not a huge fan of 'design by commitee' - more a kind of prototype it and see where it goes.Hi,
we don´t even know the block schematics yet and you start thinking about the end of the rope?
Measurement devices don´t ineviteably require computers, scripts etc .... its just an add on for convinience.
I suggest we concentrate on defining a concept and the important building blocks first.
jauuu
Calvin
oh, bztw. I´d like it to have voice recognition instead of weird ´snake stuff´
It's true that measurement devices don't invariably require computers, if you look at our other products you'll see that our business model is mainly about USB connected niche instruments - and i'm not about to start designing a CRT
Feature request- This is a long shot but create a spice model from the curve. I'm sure it would be less than complete but for odd devices with questionable data it would be a great help. There used to be tools for doing that however I have not seen any recently.
FWIW I have used curve tracers for Zener diodes, MOV's and similar as well as other nonlinear devices. Conceivably you could plot a light bulb V vs I curve but I'm not sure how to get the time constants.
FWIW I have used curve tracers for Zener diodes, MOV's and similar as well as other nonlinear devices. Conceivably you could plot a light bulb V vs I curve but I'm not sure how to get the time constants.
Who wants the support headache for that kind of undertaking?
Customers who don't understand the transistor physics OR the modeling equations, badly misusing your tool and then whining about the Garbage Out it produces?
There's a reason why nobody sells (or gives away) device model fitting software: it's a money losing hellhole of misery and hopelessness.
In practice, these problems are attacked as one-off consulting jobs: you give me the device and $2000 and ten days, I give you a fitted model.
Customers who don't understand the transistor physics OR the modeling equations, badly misusing your tool and then whining about the Garbage Out it produces?
There's a reason why nobody sells (or gives away) device model fitting software: it's a money losing hellhole of misery and hopelessness.
In practice, these problems are attacked as one-off consulting jobs: you give me the device and $2000 and ten days, I give you a fitted model.
Last edited:
I don't think this is something a curve tracer instrument should do.
This is something that can be done in a separate software tool that takes curves data (from whatever source / tracer) and fits a model to this.
1audio, the CT will give you steady state conditions or at best some low frequency AC parameters (you could probably calculate Miller capacitance). Reversing out a SPICE model is for someone far brighter than me.
Examining zeners, MOVs, etc.. will be right up its street, that’s part of the history of the project. I was using the breadboard prototype today to look at reverse leakage on UF diodes.
Examining zeners, MOVs, etc.. will be right up its street, that’s part of the history of the project. I was using the breadboard prototype today to look at reverse leakage on UF diodes.
If the curve tracer dumps to Excel (see my post on Microsoft's Data Streamer) you can utilize the data with Solver to derive models quite readily.
Microsoft Data Streamer Add-In -- makes life simpler
Not yet. We are using the FTDI FT230X to act as USB<>SERIAL converter inside the DPA - we don't use it in VCP mode but in D2XX mode.
We store calibration data in the FT230X's EEPROM and this is fairly easy to extract (it's essentially plain text). A big packet (64bytes) of raw and averaged ADC (24bit) values are sent up at 'timebase' intervals (e.g. 50ms) along with other data and a checksum. Control of the unit is through a documented register structure. So this isn't SCPI (MEASure:VOLTageC?) - we use the PC to do all the floating point stuff and much of the sequencing. The DSP inside the unit does the fast sequencing and most of the protection functions.
We store calibration data in the FT230X's EEPROM and this is fairly easy to extract (it's essentially plain text). A big packet (64bytes) of raw and averaged ADC (24bit) values are sent up at 'timebase' intervals (e.g. 50ms) along with other data and a checksum. Control of the unit is through a documented register structure. So this isn't SCPI (MEASure:VOLTage
C?) - we use the PC to do all the floating point stuff and much of the sequencing. The DSP inside the unit does the fast sequencing and most of the protection functions.