A Sunday evening project.
The python AWG project allows a PC to work as an intermediary for the non Siglent AWG for producing Bode plots: GitHub - 4x1md/sds1004x_bode: Bode plot with Siglent SDS1004X-E oscilloscopes and a non-siglent AWG.
Now there's a couple of other options - including AS9850 etc but the most simple example would be to have python create a wave file and play it.
So I'm making a software 'driver' for the git hub software that simply acts as if it was a AWG using the headphone output as the audio output.
The above is the basic structure as an example from the web. It shouldn't be too difficult to change the AWG to use this. Naturally this has all the mac mini filters in the way.. but the same could be done using a PI etc.
After much gnashing of teeth - I managed to get the Ubuntu VM inside VirtualBox running on my Mac mini connected by ethernet to allow the connection from the SDS1104-E. The bode plot is random output as I've not actually got the probes connected to anything!

The python AWG project allows a PC to work as an intermediary for the non Siglent AWG for producing Bode plots: GitHub - 4x1md/sds1004x_bode: Bode plot with Siglent SDS1004X-E oscilloscopes and a non-siglent AWG.
Now there's a couple of other options - including AS9850 etc but the most simple example would be to have python create a wave file and play it.
So I'm making a software 'driver' for the git hub software that simply acts as if it was a AWG using the headphone output as the audio output.
Code:
import numpy as np
import simpleaudio as sa
frequency = 440 # Our played note will be 440 Hz
fs = 44100 # 44100 samples per second
seconds = 3 # Note duration of 3 seconds
# Generate array with seconds*sample_rate steps, ranging between 0 and seconds
t = np.linspace(0, seconds, seconds * fs, False)
# Generate a 440 Hz sine wave
note = np.sin(frequency * t * 2 * np.pi)
# Ensure that highest value is in 16-bit range
audio = note * (2**15 - 1) / np.max(np.abs(note))
# Convert to 16-bit data
audio = audio.astype(np.int16)
# Start playback
play_obj = sa.play_buffer(audio, 1, 2, fs)
# Wait for playback to finish before exiting
play_obj.wait_done()
The above is the basic structure as an example from the web. It shouldn't be too difficult to change the AWG to use this. Naturally this has all the mac mini filters in the way.. but the same could be done using a PI etc.
After much gnashing of teeth - I managed to get the Ubuntu VM inside VirtualBox running on my Mac mini connected by ethernet to allow the connection from the SDS1104-E. The bode plot is random output as I've not actually got the probes connected to anything!

So with a BSc in software engineering and 20+ years of experience. Python is the worst language I have ever seen. I've not coded in Python before and I've been learning..
The original code is Python2.7, and that worked, however python2.7 is end of life so I'm trying to port to python3 but there's massive differences in the basic maths operations - and I can see why, they're attempting to solve some fundamental problems with the language that simply causes all the standard interpretive problems - it doesn't want to support the concept of casting but then doesn't support the tools to support it properly.
Python - COBOL for hipsters. Python is a liability for real life live services and security. I think in any job I have I will ban the use of python in production systems.
I'm now considering dumping python and recoding given this and that the Mac native doesn't support Python2.7 properly let alone python3 (don't even get me started on Mac ports as you end up installing linux on your mac).
The option here is possibly to code up using some basic libraries in Java or c++.
The original code is Python2.7, and that worked, however python2.7 is end of life so I'm trying to port to python3 but there's massive differences in the basic maths operations - and I can see why, they're attempting to solve some fundamental problems with the language that simply causes all the standard interpretive problems - it doesn't want to support the concept of casting but then doesn't support the tools to support it properly.
Python - COBOL for hipsters. Python is a liability for real life live services and security. I think in any job I have I will ban the use of python in production systems.
I'm now considering dumping python and recoding given this and that the Mac native doesn't support Python2.7 properly let alone python3 (don't even get me started on Mac ports as you end up installing linux on your mac).
The option here is possibly to code up using some basic libraries in Java or c++.
Python has been around longer than you've had your degree. I've used it off and on since the mid 1990s.
Most of the heavy(er) math in your program is done using numpy. Numpy has its own way of thinking. It works in terms of doing things to entire arrays and matrices all at once.
I really don't see where your examples are complicated or difficult or where you would have any real trouble converting to Python3.
Most of the heavy(er) math in your program is done using numpy. Numpy has its own way of thinking. It works in terms of doing things to entire arrays and matrices all at once.
I really don't see where your examples are complicated or difficult or where you would have any real trouble converting to Python3.
Python has been around longer than you've had your degree. I've used it off and on since the mid 1990s.
True. I was programming BASIC at primary school and then assembler at secondary/high school. The concept if 2.7 and 3.0 seems to be correcting the lax paradigm towards C++/MATLAB with a little nod to LISP. It can't decide if it wants to be typed or not.
Most of the heavy(er) math in your program is done using numpy. Numpy has its own way of thinking. It works in terms of doing things to entire arrays and matrices all at once.
Numpy really replicates the maths based paradigm popularised by MATLAB and available for free with Octave. That I'm happy with. Last couple of years numpy came up during the quantum work.
I really don't see where your examples are complicated or difficult or where you would have any real trouble converting to Python3.
The existing library code not the numpy example given. The existing library code made use of some of the less-strict implied type conversation. Even using 2to3 doesn't solve the issues - the existing code uses string concatenation to concat multiple types using +=, with lots of byte and int implied conversations. Even trying struct.pack() makes it just as hard to nail the types.
@NickKUK, could you not do this in Matlab/Octave?
Jan
That would be an option. I'd need to read up on socket connectivity but Octave seems easier.
Last edited:
The whole point of Python is to be pragmatic and for integrating other stuff at a high level. Its certainly used heavily in many areas - and I've seen it used in production systems with solid reliability - frankly anything is better than C or C++ (or other forms of high level assembler) for business logic. And yes Python is anything but a clean design, its a magpie collecting lots of useful stuff, but the core is small and comprehensible at least. And that's why its so useful.
In 5 years time you'll be loving it because how simple some stuff becomes - there is a Python module out there for almost anything, its great for prototyping - its the ecosystem that matters most in the real world I suggest. Time to simply add it to the toolbox (without drama!).
Anyway most/all coding is the same stuff at heart, you should be able to use any tool to get the job done if necessary! If you are lucky you can choose the tool...
Talking of tools not to use in production:
I remember using the IBM Java compiler "jikes" (written in C or C++ from what I recall), back in the day - no single version would work on all of our large body of Java source without crashing, you had to pick and choose different versions to try and find one that didn't buserror or SegV for each case - and I talking 10 or more versions in a row were released like this IIRC! Yes it was fast, but it wasted more human time than the machine time it saved.
In 5 years time you'll be loving it because how simple some stuff becomes - there is a Python module out there for almost anything, its great for prototyping - its the ecosystem that matters most in the real world I suggest. Time to simply add it to the toolbox (without drama!).
Anyway most/all coding is the same stuff at heart, you should be able to use any tool to get the job done if necessary! If you are lucky you can choose the tool...
Talking of tools not to use in production:
I remember using the IBM Java compiler "jikes" (written in C or C++ from what I recall), back in the day - no single version would work on all of our large body of Java source without crashing, you had to pick and choose different versions to try and find one that didn't buserror or SegV for each case - and I talking 10 or more versions in a row were released like this IIRC! Yes it was fast, but it wasted more human time than the machine time it saved.
Sorry to be off-topic but I'm about to get an sds1104x-e (I believe that's the model you wanted to write on the title) and I was wondering how the bode plot behaves in the lower frequencies like 5Hz to 5kHZ. Is it accurate enough for the audio bandwidth?
Many thanks
Many thanks
Sorry to be off-topic but I'm about to get an sds1104x-e (I believe that's the model you wanted to write on the title) and I was wondering how the bode plot behaves in the lower frequencies like 5Hz to 5kHZ. Is it accurate enough for the audio bandwidth?
Many thanks
Well you can set a 20khz bandwith, however I suspect it’s more illustrative compared to an analyser.
It does take the input and output but I’ve not had a chance to play with it at the moment.
The whole point of Python is to be pragmatic and for integrating other stuff at a high level. Its certainly used heavily in many areas - and I've seen it used in production systems with solid reliability - frankly anything is better than C or C++ (or other forms of high level assembler) for business logic. And yes Python is anything but a clean design, its a magpie collecting lots of useful stuff, but the core is small and comprehensible at least. And that's why its so useful.
In 5 years time you'll be loving it because how simple some stuff becomes - there is a Python module out there for almost anything, its great for prototyping - its the ecosystem that matters most in the real world I suggest. Time to simply add it to the toolbox (without drama!).
Anyway most/all coding is the same stuff at heart, you should be able to use any tool to get the job done if necessary! If you are lucky you can choose the tool...
Talking of tools not to use in production:
I remember using the IBM Java compiler "jikes" (written in C or C++ from what I recall), back in the day - no single version would work on all of our large body of Java source without crashing, you had to pick and choose different versions to try and find one that didn't buserror or SegV for each case - and I talking 10 or more versions in a row were released like this IIRC! Yes it was fast, but it wasted more human time than the machine time it saved.
I’d be all up for a language to be meta in it’s approach, freeing the development from the bits and bytes.
WebSphere and it’s Java compiler was discontinued by IBM. One of the services I’d inherited had all the fun with past EOL websphere and an out of date SSL..
NickKUK: Not having a compiler to strictly check the types is the "beauty" and "horror" of python and of other non-checked languages like PHP, JS, etc. I have worked in java for 20 years and appreciate the ease of making changes and asserting command over a huge project of many thousands of classes, some 20 years old, some from last week. Any renaming done in a decent IDE (e.g. IntelliJ) is basically guaranteed to work afterwards, every extracting a method, changing method interface etc. No way to keep control of a python code like this (unless every single passing variable is checked by unit tests which is extremely unproductive). Often python methods end up starting with explicit checks for input parameter types which is the exact contrary to the presumed brevity of python.
Yet I would not pick java for a quick and dirty project, python is way simplier to start a project with.
Octave/Matlab is a horrible language in terms of programming, you really do not want to use it unless you need some advanced math libraries. It's many light years worse than python, no types whatsoever. I have spent countless hours finding stupid bugs in octave nonlinear-compensation/octave at master * pavhofman/nonlinear-compensation * GitHub . If your project is not strictly math-based and you want some programming structure, you will be much better off with python 🙂
From the types POW, python3 is uncomparably better than python2 because type annotations were "hacked" into the language. They are not compulsory and most projects by people who started with non-typed languages do not use them. But the Pycharm IDE (again IntelliJ-based) helps A LOT to maintain command over your python3 project if you use the type hints consistently. Unfortunately since it's a hacked-on feature they cannot be used everywhere or are clumsy sometimes. Still you want to keep your method names as self-describing as possible because sometimes even the advanced IDE must resort to plain text search in renames or call finding which is guaranteed to be unreliable. So using single-word names like "copy", "control", etc. in many classes is a call for problems. Never a problem in java, but in python I would always name it copyBlock, controlPin, etc. I hate when listing all places where method A.control is called lists also methods B.control, especially should the variables be named identically. Never a problem in strictly typed languages like Java, C#, etc.
That's just my experience and hints.
For performance while strict type control with advanced generics, functional features, well researched error handling, etc. the new kid on the block Rust is probably the future.
Yet I would not pick java for a quick and dirty project, python is way simplier to start a project with.
Octave/Matlab is a horrible language in terms of programming, you really do not want to use it unless you need some advanced math libraries. It's many light years worse than python, no types whatsoever. I have spent countless hours finding stupid bugs in octave nonlinear-compensation/octave at master * pavhofman/nonlinear-compensation * GitHub . If your project is not strictly math-based and you want some programming structure, you will be much better off with python 🙂
From the types POW, python3 is uncomparably better than python2 because type annotations were "hacked" into the language. They are not compulsory and most projects by people who started with non-typed languages do not use them. But the Pycharm IDE (again IntelliJ-based) helps A LOT to maintain command over your python3 project if you use the type hints consistently. Unfortunately since it's a hacked-on feature they cannot be used everywhere or are clumsy sometimes. Still you want to keep your method names as self-describing as possible because sometimes even the advanced IDE must resort to plain text search in renames or call finding which is guaranteed to be unreliable. So using single-word names like "copy", "control", etc. in many classes is a call for problems. Never a problem in java, but in python I would always name it copyBlock, controlPin, etc. I hate when listing all places where method A.control is called lists also methods B.control, especially should the variables be named identically. Never a problem in strictly typed languages like Java, C#, etc.
That's just my experience and hints.
For performance while strict type control with advanced generics, functional features, well researched error handling, etc. the new kid on the block Rust is probably the future.
Last edited:
The main issue in the codebase is the author has taken bytes but used the 2.7isms to simply implicit casting between bytes and string. 3 enforces explicit type conversion.
I’m slowly walking through making some changes.
Matlab/octave isn’t bad - maths vs programming. Matrix, vector spaces etc allow a far better parallelisation of processing. The bsc specialised in distributes, parallel and numerical computation.
Octave suffers in that it’s single threaded.
I’m slowly walking through making some changes.
Matlab/octave isn’t bad - maths vs programming. Matrix, vector spaces etc allow a far better parallelisation of processing. The bsc specialised in distributes, parallel and numerical computation.
Octave suffers in that it’s single threaded.
That's python as is 🙂
The simpleaudio alsa library outputs to alsa "default" device, hardcoded py-simple-audio/simpleaudio_alsa.c at master * hamiltron/py-simple-audio * GitHub . You may have to redefine it in your .asoundrc in the virtualized ubuntu.
The simpleaudio alsa library outputs to alsa "default" device, hardcoded py-simple-audio/simpleaudio_alsa.c at master * hamiltron/py-simple-audio * GitHub . You may have to redefine it in your .asoundrc in the virtualized ubuntu.
That's python as is 🙂
The simpleaudio alsa library outputs to alsa "default" device, hardcoded py-simple-audio/simpleaudio_alsa.c at master * hamiltron/py-simple-audio * GitHub . You may have to redefine it in your .asoundrc in the virtualized ubuntu.
Just upgrading the virtual box and guest additions...
The VBox IntelHDA virtual soundcard should work OK. My linux host/Win10 guest combo supports redirecting USB soundcards to virtualized windows correctly, but sometimes highspeed packets get lost in the long chain between the USB port and the windows guest, causing glitches. OK for testing, subpar for operation. Depends a lot on CPU performance. I have not tested on Mac.
Currently I can "aplay /usr/share/sounds/alsa/Noise.wav" and hear noise audio played but simple audio isn't working, so there's something needs fixing.
Typically these audio python packages require compilation which requires having audio lib headers installed - apt-get install libasound2-dev
- Home
- Design & Build
- Equipment & Tools
- Python Software AWG for SDS1404X-E