towen

Thanks @attila although as I mentioned, i'm running waveforms on a Raspberry Pi - is there any chance you could compile the beta release for the Arm platform? Also - I am trying to work around the bug by defining a function in the script tab, and then calling it from the scope logger tab instead of writing a large amount of code in the logger itself. Unfortunately the logging script can't find the function that I defined in the script tab. Do you know if there's any way to call the function from the scope logging tool, or perhaps instead to add a callback to the scope trigger event from the script tab? edit: Nevermind I have found a solution, to loop on the Scope.wait function i.e. while(Scope.wait()) LogScope(); Although adding a callback would be nicer, as it frees up the script to do other stuff.

Hi, thanks. Unfortunately there is no such file in the extracted files. 😢 I also notice an error in the console: QMainWindow::saveState(): 'objectName' not set for QDockWidget 0x304d5c0 'Logging; I also couldn't produce it with a blank workspace - It seems to be a problem with the workspace I was using, so I have sent that to you by PM The logger only fails to save when it is un-docked.

Hi, I discovered a really nasty bug in WaveForms today, it caused me to lose 1.5 days of work. Version: 3.19.5 (Raspberry Pi) Bug description: The contents of a widget (such as the scope logger script editor) are NOT saved to the workspace if the widget is undocked from the main window. So I had a particularly large scope logger script, for which I needed to undock the script editor. I made sure to save my workspace often. Little did I know, when I saved the workspace with the logger un-docked, my work was erased from the save file. I should have saved the script separately, but I thought I was safe with the workspace. Steps to reproduce: Normal operation: Open a workspace, add a comment to the default logger script, close and save workspace, re-open workspace: Modified script is still there. BUGGED operation: Open a workspace, add a comment to the default logger script, UN-Dock the logger from the main-window by dragging its border, close and save workspace, re-open workspace: Modified script is GONE - it has reverted to default. I wish there was a way to get my work back, sadly not.

OK it took some coercion but I managed to get the package to install.. Unfortunately after doing that I only just discovered the issue with FTDI drivers on RPI 3 😭 I wasted a couple of hours trying to get a better AUX power supply only to find that it is a fundamental software problem 🤌 https://forum.digilent.com/topic/1713-analog-discovery-2-vs-raspberry-pi-3 I wonder if it could be something to do with FTDI's nasty habit of sending garbage data from the driver if it detects a "fake" FTDI device https://hackaday.com/2016/02/01/ftdi-drivers-break-fake-chips-again/

I found an old 'beta' of the waveforms armhf package on this forum, and I tried to install that, but I get: dpkg: error processing archive digilent.waveforms_beta_3.18.19_armhf.deb (--install): new digilent.waveforms package pre-removal script subprocess returned error exit status 2 xdg-mime: file '/usr/share/mime/packages/digilent.waveforms.xml' does not exist I also tried copying the file in question (/usr/share/mime/packages/digilent.waveforms.xml) from my Linux laptop to the raspberry pi, but I get the same error. Is the raspberry pi platform still supported by digilent?

Hi, I am trying to get my Analog Discovery 2 going on Raspberry Pi. I have tried the 'pydwf' library which works on my Linux laptop, however it seems that libdwf (the digilent waveforms library) is only distributed for Arm32 and Arm64, not armhf :( What is the best way to use the Analog Discovery 2 on Raspberry Pi?

This is the way I ended up doing it, using the scope measurements instead of the logger: FileAppendLine("~/Desktop/scope/elec_meter.csv", [ Date.now(), Scope.Channel2.measure("AC RMS"), Scope.Channel1.measure("AC RMS"), Scope.Math1.measure("Average"), Scope.Channel1.measure("AC RMS") * Scope.Channel2.measure("AC RMS"), Scope.Channel1.measure("Frequency") ]) BTW, you'll notice that my current draw is anything but sinusoidal - this is what LED lamps look like! (and why peak-sampling smart meters can over-read LED lighting by a factor of 7 - https://www.bleepingcomputer.com/news/hardware/millions-of-smart-meters-may-over-inflate-readings-by-up-to-600-percent/) If I turn off some LED lights then it looks like this: (the rest of the spikiness is probably other non-PFC DC rectifiers like cheap switching PSUs) It'd be great if there was some way to measure THD on these waveforms and log that to CSV as well! My next challenge is to do this using a raspberry pi without the GUI so that I can have a continuous logging server - I assume the best way is using the Adept python API? Or is there an easier way? (note on safety of measuring the mains: Of course, I am using a 100:1 high voltage probe, via a fuse and 1 MR resistor, to measure the voltage safely)

Hi, Is it possible to log math functions with the data logger, or how could I do this with the Python API? The logger only allows me to add C1 or C2, not M1. The closest I have got to this, is to use the logging function of the scope measurements pane, where I can use `Scope.Math1.measure("AC RMS")` for example in the logging script. However this is not ideal for me as it throws away some data (the scope can only trigger so fast) and I am trying to make a continuous datalogger on the AC Mains, using a current clamp probe. Whereas I believe that the logger uses all available samples to calculate each RMS sample. FYI I am making a kind of DIY smart meter, to see just how much the power companies are fleecing me when turn on loads such as LED lights which have a high crest factor. (I believe that they sample at the peak of the AC waveform only, and assume the current is sinusoidal, but it is not, due to the bridge rectifier on the front end of most DC-powered devices like computers and LEDs) It would be great to have RMS power (using a 100:1 voltage probe and a math multiplication) in the data log as well as a measure of the crest factor (I was thinking of using "Amplitude" / AC_RMS, but other suggestions are welcome) The other niggle I have with the logger is that the UI is not very useful for viewing the data, since it discards data when you zoom in. It also doesn't support different units or probe attenuation factors. There also seems to be a bug where the last channel cannot be removed. If you untick all channels then the last one still remains displayed, but even if you try to enable another channel instead, you cant get rid of the last one.