Hello!
At this moment, Moku:Go supports 8 software-defined instruments: Oscilloscope / Voltmeter, Waveform Generator, Logic Analyzer / Pattern Generator, Frequency Response Analyzer, PID Controller, Data Logger, Arbitrary Waveform Generator, Spectrum Analyzer.
Any other requests for new instrumentation for Moku:Go?
Your feedback is welcome and much appreciated!
Hello out there!
We are considering adding a Protocol Analyzer and the Digital Filter Box from Moku:Lab to our Moku:Go instrumentation lineup!
Let us know your thoughts and feedback on this, and other instruments/features youâd like to see in our Moku:Go products! Thanks!
Port the lockin from the :Lab. (I think this is already in the works)
I would be convenient to float the DAC output to a reference voltage defined by one of the programmable power supplies or some external source. This is common in many benchtop power supplies, so I wonder why it is not a feature of the waveform generator.
Hi @brucat, interesting; Iâve not seen exactly this feature on a benchtop PSU (or havenât noticed it, rather!), can you perhaps provide a link to a product that does what youâre describing? Am I right that youâre asking for the WG instrument to lock the DAC output to the same voltage as a PPSU channel, or some fraction of it? Whatâs a common use for that?
Dr Nizette,
I am sure that I have been unclear, and I probably am barking up the wrong tree anyway. Here is my thinking:
The PPSU on your device provides a bias voltage and has two outputs (+,-), neither of which is ground unless defined that way. This is what I think of as âfloatedâ. Most control voltages are generated in such a way since the system ground may not be the same as the detector ground and you probably wouldnât want to jump them as that would create a ground loop. The instrument ground should be defined by the detector, unless it is isolated somehow, either optically or otherwise. I see the waveform generator as a control voltage, so I thought it would be more flexible to also have a three conductor output, +, - , gnd.
It is unlikely that such a change is consistent with your present design, so please ignore the request.
Nonetheless, thank you for the consideration, and have a great day.
Stay safe and keep smiling.
/pjb
Ah got you, that makes sense, thanks @brucat. In fact, the PPSUs are not isolated, either from each other or from the system power. Youâre right that this makes it less flexible than mid-range and above benchtop power supplies as you canât, for example, daisy-chain our +16V and +5V channels to reach 21V.
Having fully isolated I/O (analogue, digital and power) is indeed incompatible with our current design (and, for the time being, this price point 
) but weâre always developing new things and weâll keep it in mind. Thanks for your input!
Plus one vote on the protocol analyzer!
I donât know if my desire is common or not, but I have would like to use the two outputs to drive X/Y stepper motors. The reason I would like to use the Moku:Go to control my motors is that the existing controllers are so hard to program. On the other hand I donât know if using the Moku to control my motors would help or not.
My stepper motors controller use one frequency regulated (the number of pulses is proportional to steps taken by motor) input per motor to control the velocity and one DC input (0 or 5 V) per motor to define the direction. Some motors also have positions encoders that emit a number of pulses proportional to the actual distance traveled that could be sent to the analog input to keep track of the position.
hope you will consider developing something like this.
A couple more things that would be nice to have:
Thank you for posting to the forum Timothy!
We are currently working to add the Protocol Analyzer to our API stack, however, protocol generation is a bit of a ways off. We will be posting updates to the forum on when this feature is released!
A power analyzer would not be possible with our current hardware, since as you pointed out we can only sample voltage at this time. Would you consider using an external shunt that you source or would your prefer we provide an attachable module that allows current measurements?
Look forward to hearing your thoughts so we can improve our products for the future!
Hi Sam. Thanks for the update. Neither of these items are critical for me right now, just nice to have.
I usually use an external shunt for current measurement, but that ties up an oscilloscope channel. Iâd also consider adding an external filter to smooth the current for measurement if I needed to free the scope channel. You might want to consider publishing the power supply bandwidth or equivalent circuit for this.
Protocol generation is a really handy feature for evaluating sensors, but there are plenty of options out there for it.
I would be interested in seeing an adaptive filter on the Moku:Go.
Such an instrument block would be incredibly flexible and useful for signal denoising, echo cancellation, system identification, adaptive control, etc.
The least-mean-square algorithm is straightforward, so shouldnât take much in the way of resources, although much of that depends on how well matched the sampling rate is to the bandwidth of the problem at hand.
A user interface layout with pickoff points for an oscilloscope (such as in the lock in amplifier) would also be very useful.
The Moku:Go has just the right amount of inputs and outputs for an adaptive filter, and I would love to see an instrument with as nice a user interface as the lock in amplifier.
Thanks!
Hi @jskallman Jeff,
Thank you very much for proposing this update to us!
I understand that we currently donât have the LMS filter available. We had a customer who used the Moku Cloud Compile to implement LMS filter.
The MATLAB/Simulink could be a possible solution for this LMS filter.
Thank you very much for your patience and understanding!
Best regards,
Hank
The Multi-insturment mode limits the abilities of the instrument used, especially on Moku GO. I suggest there be a single instrument âadvancedâ mode where the same logic of dictating where the input and output go, and the use of the DIO port is in a GUI format but for a single instrument. Currently in single instrument mode the input and output are locked. Having an âadvancedâ mode. would allow me to test out ideas before giving it to my programming team that often barely understands what they are writing for me.