P2LAB as a P2 based multiscope instrument project
Peter Jakacki
Posts: 10,193
I've always wanted to design my own MSO so that I could customize it. Now that we have the P2 we can use it as a super-fast real-time multiprocessor. I am going to modify my incomplete P2LAB design to accommodate instrumentation modules. Initially I will just use P2 A/D modes but allow for external A/D converters and maybe even A/D in each probe. But I want this to work as a graphing multimeter too and be able to measure frequency and measure caps and resistors and diodes etc. In auto mode if it detects a voltage it will try to measure the source impedance and display the results so that they are more meaningful. If there is no effective voltage then it will try to measure diode voltage drops bidirectionally and resistance/capacitance/inductance. Just connect the probes and let it tell you all about it.
I'd have VGA/HDMI output available as well as a built-in LCD of course but I would also allow for BT/WiFi connection for phones and tablets.
For LA the P2 is ideal as well and although I haven't tried it yet, I think we can set the pin input thresholds too so there is no need for external comparators. We can also generate all kinds of signals and functions too.
The A/D probes also simplify the design and I don't need coax or BNC either. Add as many probes as you need and they can even incorporate their own isolation. Of course the P2 scope modes can also be used for lower frequencies. Then there are "decoders" but we have a secret weapon with the P2 in some modes because any pin can be setup for asynch for instance, plus we have many cogs and streamer modes etc.
I will think about what goes into this while I finish off my P2D2 orders before I get too sidetracked.
What do I call it? Maybe just P2LAB or CheckMate perhaps?
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
PLEASE IGNORE THIS BIT
High speed A/D is really really expensive but I designed what I would now term an 8-bit hybrid flash A/D when in my teens that only required 8 comparators and rippled offsets down the chain so each stage saw a signal that was always in its range. This was in the era of TTL logic and relatively slow analog but now I have this really crazy idea for a very cheap super high-speed A/D converter.
If I wanted to sample every 1ns for instance, then normally that's all the time it would have but in reality that wave is propagating at close to the speed of light at 0.3m/ns and 10ns later that same signal is still available 3m away so over that distance we really have 10ns to convert that signal using a tapped chain and terminated transmission line (spiral perhaps) and likewise delaying each comparator output accordingly for zero skew every 1ns. Combine time and space to have more time with a signal propagation chain. I'm going to think more about the physics though and how it is "impossible" or impractical and just use some P2 A/D modes first and then some conventional A/D converters with a view to tackling this high-speed stuff in a cost effective way later.
Comments
Peter, your ADC idea sounds really interesting. How did you prep each signal for its comparator?
Yes, why not use a P2. Could be a cheap instrument with a nice market
Let's just say it could be, perhaps, competitively priced.
Cheap often means cutting as many corners as only possible to get the target price. We need a real instrument and not yet another gadget so it needs to be built to specifications and the price will result from these. But of course, careful design can keep the price under control.
This will not be an instrument for the crowd. Only for those who can appreciate what it has to offer and understand the effort that must go into designing and manufacturing a quality tool. But yes, I can see a market for such a tool.
In its basic form it will be inexpensive, but you can add active analog probes and other plug-in modules. So it will be expandable.
Every square will be covered with CheckMate
Let's start with guesstimating what kind of specifications can we REASONABLY expect that are thought to be achievable in its basic form and how far can we get with all the additions in terms of specs, not money.
That should help to trim or expand the design.
Let's find out what's possible first and then how much would it have to cost to get there but the bean counting should not be a priority until it is known what can and can't be achieved.
My efforts to fully understand SED are based on the idea, that Peters way to structure a project is very effective and will show results in a short period of time. The problem is, that this way chips a problem and all the chips need names and have to be used automatically, so you have to learn them like a vocabulary. That again takes some time. And I have to have a data logger that can acquire data at high rate over long time and that uses multi scale realtime filtering to detect and identify special events. With a P2D2 as a core (or more of them), some SD-Cards, a base board, I/O conditioning and a touch screen I will have, what I need. Such a toy has to be present on the desktop, will show the date and time, will beep to flush the air to reduce Covid, etc, will be you little helper. There will be a 3d-printed housing that carries you phone... Maybe you need a couple of them in different places..
So, yes, as I finish my SED analysis, I'll start documenting this logger in a very simple form..
With the Goertzel you can do spectrum analysis, DDS, and resonance detection.
Sounds to me like an awesome multi purpose tool for an EE and a serious hobbyist.
Did someone already have a look into sigrok? https://sigrok.org/
That's an open source signal analysis software suite. That might reduce the effort for writing GUI code and code for protocol analyzers.
To look what already exist makes sense. There should be a lot of input about things to care and ways to go, even pitfalls. This project was mentioned some time ago, but I forgot about it.
I will probably go against many folks here with this but here is what I think would be of great value:
And that would be pretty much it.
I want to expose the P2 I/O in groups of 8 with some protection and I can use this as logic analyzer inputs or low-speed A/D.
One thing I will do is use active analog probes with their own A/D and a high speed serial link back to the P2 and so they would just plug into the normal P2 I/O connectors. For really high-speed stuff later on I might have smarter probes or if I have to, resort to BNC probes into a module. But I prefer active probes.
The P2LAB has been designed for a standard enclosure and remember I use the lid for the bottom on which the pcb rests. That way I only need to cut notches into the top edge of the box for the connectors so that when it is flipped over onto the "bottom" lid it fits perfectly. So now the bottom of the box is the top and it is just large enough to take up to a 7" LCD or else a smaller screen and a keypad.
This will be powered by 5V or 12V input with the advantage of the 5V in that I can use common USB battery packs and I can even fit a small one internally perhaps.
I will post some renderings when I get them done.
@cgracey - I'm counting on all those cool functions, don't you worry about that
Post deleted - see ErNa's cleaned up version below
Just to improve readability:
** bob_g4bby Posts: 147
2021-03-14 12:43 Flag
Based on my ham radio experiences:-
**
A list of potential Propeller 2 based test and measurement applications:-
** Useful technology for 'budget' test instrumentation
Radio Hams and other hobbyists have ingeniously re-purposed many mass-produced ICs in pursuit of cheaper test instruments or radio equipment. Some very popular examples are:- **
The nanoVNA and Tiny Spectrum Analyser mentioned above have greatly benefitted from having a companion PC application to control the instrument. Both these credit card sized instruments are powerful but fiddly to use, especially if your eyesight and finger tips are less than gimlet / fairy-like. Both instruments use USB for battery charging and as comms link. The 'TAQOZ command line interface' would seem to be a very useful basis for instrument control, for passing commands and data.
If it was me writing the PC application, I'd go for the test and measurement language LabView. Programming in that language is maybe 5-10 times quicker to get a result than in any other language. It's free as a community edition, for non-commercial purposes, although that is 32 bit Windows only, isn't crippled in any way and executes very quickly even so. I used the paid-for version (32 or 64 bit Windows or Linux) for the last twenty years of my career, mostly where a simple piece of bespoke test gear was needed in a tearing hurry. We had a lot of test instruments that were controllable by GPIB from a PC.
Such a 'P2 multimeter' might consist of a base unit comprising P2, display, controls, USB port, battery + a number of plug-ins that identify themselves to the base unit and provide the extra circuitry for their specialism. The weak link in that is the multi-way connector, which would have to be robust and capable of many thousands of insertions. On power up, the plug-in is identified and the P2 then downloads the program to run the instrument from the SD card. If more than one application exists, the user is prompted for his choice. This is remembered for next time as a convenience.
The ability to run very low power from a battery, log data to SD card and pass that data wirelessly to a PC is often useful for measurement in dangerous or inaccessible locations. So some kind of wireless network would allow a local group of P2 based instruments be contacted by a PC. E.g. This multimeter used a cellphone as its front panel, linked by bluetooth. The 2 AA batteries could be made to last many months, depending how often a measurement was taken.
Bluetooth LE is aimed at prolonging battery life.
Just thought of another application I used a lot for enviromental test - multichannel thermometer. We used to sprinkle thermometers all over a product in the environmental test chamber to check the thermal management was within spec.
Another simple instrument we had to make for product compliance test was a voltmeter or ammeter with a latched alarm. If the measured value went outside the acceptable range, then an audible alarm sounded until it was cancelled by the user. It could also have been a wireless message of course. This meant that extended tests could be made without a test operator present all the time.
While having such a rich set of fetures certainly is possible I'm courious, why would you want to have them implemented in a single device ?
What are the real benefits to gain ?
What are the real benefits to gain ? - It has to be lower cost in providing a 'multimeter++' like tool that might appeal to hobbyists.
A P2 based test instrument with a fixed set of i/o circuits would be more straightforward.
It has to be your companion on the table, something you don't like to miss and still doesn't give you good advice all the day. That's all. All technical aspects come in the second place
Just some more brainstorming:-
So the P2D2 is a completely general purpose controller module that can be reused over and over again. Likewise the P2LAB is another slightly more specific module that can be used over and over in test and measurement products. It provides these (they don't all have to populated):-
So the I/O modules and the software stored in flash or sd card determine what type of test instrument it is and a large product range can reuse the P2LAB module. We like reuse?
Please don't let us have this projekt overloaded with features. In a first step we just should have a P2, some TAQOZ code, a display type touchscreen and one or more digital inputs. The HMI alone will need discussion.
I think I understand now. My problem is that I much too often see the flip side of the coin too and try to balance the gain with the effort.
The other thing is I'm not a big fan of the "do-it-all" devices that, while having many features to offer, often compromise on performance.
Also, I like tools that are simple to use. If a tool is difficult to use it sees less and less use over time and in the end becomes useless and the more features the tool has the more costly it is to design it and more difficult to use it.
In the 1st post Peter mentions techniques for creating a high speed d/a for oscilloscope application at lower cost. I remembered reading my chinese oscilloscope obtains it's high sampling rate by using multiple a/ds multiplexed in time. I found an article on that here
@bob_g4bby
Thanks Bob, that's quite a list there though. I reckon you got your ten bob's worth in there
There are a few things there that are easy enough implement early on but I'm sure with your "kind assistance" we will be able to implement these features as we go. One thing I want to be careful of is begin trapped because something is a bit difficult to implement because it hadn't been allowed for in the early stages. With a modular design this shouldn't really happen though.
The reason behind the delay line idea was simply to effectively cancel my Splash converter's offset ripple. I call it a Splash converter because it works as if it were a Flash A/D but rippling through delayed wave signals. I'm busy running sims on this btw.
I had thought about having multiple lower-speed converters multiplexed in parallel as well of course, since this is an ots solution. I just had a look at the AD9283BRSZ-100, a 100MSPS chip that is easy to use and low-cost at around $12, so something like this may form the basis for high-speed A/D. But if I throw some ideas and some part numbers out there, then sure as eggs somebody will chip in with some other ideas and parts etc.
We have a dream, let's break that dream down to small achievable goals and make it happen!
Please, we all should slow down to proceed! We need something very simple that can be done with on board tools. To me the core function is:
Acquire a Data stream to a flash file and stream the flash file to a touch screen. Then we should be able (have to learn) how to filter the stream data, e.g. find the max values in a sector. There are different file formats available that can do this job, like in the EDF browser https://teuniz.net/edfbrowser/ . The file format it open and can be implemented in a light version
Flash will be limited for capture but I do have the option of 8MB PSRAM on-board or on P2PAL which also supports 16MB HyperRAM for captures.
I will get some intiial LA and scope captures onto my VGA screen and then I will take it from there.
Thanks for those links for the EDFbrowser as I will check them out later.
OK, FLASH to me is a synomym for all types of external memory. It doesn't change the principle. The EDF format is quite simple as it has a header section that defines the structure of the data streams. So in one file you will have blocks of different data with different data rate. https://edfplus.info/ There is a first generation format EDF and later EDF+. The point is, as we are not starting from scratch, there is a browser already available. This browser doesn't care about the meaning of the streams.