Hi folks,
just to let you know. I’ve just started writing an alternative software for the PCSGU250 which will:
What works so far:
Hi Kay
Thanks for doing all this great work on Linux code for the scope. I have just got one off a friend and have tested it on an old PC running W10. I would like to make a permanent installation of it at The National Museum of Computing to collect some diagnostic waveforms from our EDSAC replica project. We already have some wireless connected Picos collecting digital data which talk to a Raspberry Pi, so being able to connect the scope to the Pi will be a great solution. I’ll be looking closely at the device handler you have on github, to see how we can write our own software to capture signals, and send results over the network. I will need to add some drivers for a Pico which will be used to send control signals to relay boards to select which signals to monitor.
Tony
I’ve got the code running on a Raspberry Pi 5. The scope runs OK and the current consumption is around 360mA. However, when I click on anything on the generator panel, the code crashes and reports a floating point error. I can’t see if this is due to extra power being taken as it dies instantly. I tried a powered hub, but the code reports that there is a null return - possibly too old a hub.
Has anyone else on this forum been using the scope with a Raspberry Pi?
Tony
Hi Tony,
although it has been sometime now, I recall having a stable and sufficiently beefed-up power supply to be absolutely critical for the PCSGU250. The software working fine when just the scope operates and crashing when the generator engages is most likely due to receiving garbage data as a result of the firmware crashing from a under-voltage condition.
If I remember correctly, the generator is capable of outputting something like 15 V rms into a 50 Ohm load - that means 30 V pp. Those 30 V are being generated by a boost converter directly of the 5V USB power that powers the controller/fpga of the scope. I belive to have seen an inrush spike up to 1A on the USB power line at the moment the boost converter engages, leading to a significant voltage drop which crashes the firmware.
I remember to have been using a desktop machine with usb ports known to be capable of delivering way more current that what the USB 2.0 spec requires. And even then you need to use short-length good quality USB cables with minimal resistance.
I also remember vaguely to have been running into similar issues you are seeing with your PI. Its ports are simply not powerful enough to sustain that kind of inrush current. I also remember pondering about cutting a trace on the pcb and to add a separate and powerful 5V source which only supplies that pesky boost converter.
Kay
Hi Kay
Thanks for your advice. I have now done some current measurements with my old laptop, and the scope is taking around 360mA, and this doesn’t change when the generator is switched on with just the scope input as a load. It’s the same with the Pi, but as soon as I try to change anything on the generator window, I get the Floating point exception message. The same thing happens if I ‘upset’ the software by restarting it on the Pi so that it hasn’t enabled the scope and only around 8mA is being taken. When I change a value on the generator screen, I get the FP exception message, even though the current is 8mA. I went through a full compilation on the Pi to install the software, and it was quite complex finding the correct libraries,getting qmake etc to work, so perhaps there is a library problem. There is another problem on the Pi - the generator window is fixed on the screen, unless I press ‘command’ plus mouse click, whereas the scope window is normal. Another problem on the scope Init Device button is that I get this message:
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
A second click correctly claims the interface. Other messages that come up are:
7 devices have been found
Vendor ID and Product ID 1d6b:0003
Vendor ID and Product ID 05ac:0256
Vendor ID and Product ID 1d6b:0002
Vendor ID and Product ID 1d6b:0003
Vendor ID and Product ID 10cf:2501 ← This is the one… Index is 4.
Vendor ID and Product ID 05fe:0011
Vendor ID and Product ID 1d6b:0002
Device open succeded…
No Kernel Driver Active found…
Manufacturer:
Product:
Serial:
Interface claimed…
vor readfrdev…
nach readfrdev…
devinit(): bytes read from interr: 64
1.01 - 31 2e 30 31 d 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
device init complete
I shall try and understand your generator code and try to find where the FP problem is.
Tony
Well, to me this still looks like a power supply/condition problem. I know for sure that there are short lived current spikes being generated by the scope and they can cause trouble. Depending on how you are going about measuring the current draw, those spikes tend to be difficult to detect - a normal dmm most likely wont tell you the whole story…
However, it’s been a couple years since I looked into this for the last time. I is possible that in the mean time some kind of software/library incompatibility has crept up and is causing issues.
Kay
Hi Kay
I’ve managed to open the project in QT Creator on the Pi, and run it from there.
I’ve proved it isn’t excess current, because it crashes even when using the simulator. The message in the QT Application output window is:
18:14:57: Starting /home/pi/freeoszi/FreeOszi…
18:15:14: /home/pi/freeoszi/FreeOszi crashed.
I need to turn debug on, but I’m not yet familiar with these tools.
Editing this post, as I’m not allowed many replies as a newcomer to the forum:
Getting a bit closer - I get this message when debugging and it crashes (no scope attached):
‘Signal Received - QT Creator’
The inferior stopped because it received a signal from the operating system.
Signal name: SIGFPE
Signal meaning: Arithmetic exception
Later…
Fixed the crash - in genOperator.cpp
line 30 - powsOf2[8] has to be a long long variable.
The scope and generator now work well off my R Pi 5, taking 350mA.
Now need to understand your code to get sensible scaling for the time or frequency axes. I’m also not convinced that the frequency from the generator matches the time/frequency shown on the scope. I used a scope probe on the scope’s 12MHz clock and that definitely showed a peak at 12MHz, so I know that is correct.
Tony
I’m not arguing that, it might be. I remember it used to work - some four years, probably several qt and libusb versions ago. I have not looked into it since then and things might have changed…
great. Keep on pushin… 
