Lazarus oscilloscope - FPC firmware + Lazarus GUI

[ccrause]

Congratulations!

Can you add this to the wiki? https://wiki.freepascal.org/Lazarus_Application_Gallery

Thank you.  Done.

Updated wiki link: https://wiki.lazarus.freepascal.org/Projects_using_Lazarus_-_Hobby_software#LazScope

[ccrause]

A new version of the LazScope project has been released.  A few bug fixes and an 8 bit mode was added.

Attached an example trace of a middle C note played on a laptop and captured over the headphone jack.

[Thaddy]

Nyquist?
https://en.wikipedia.org/wiki/Nyquist_frequency

The graph overshoots so the sampling is not correct. Not good for your ears. Just like my Marshall 130 watt clone is not good to my ears: London City, just from 1966 1969, made in Amsterdam. The latter is less painful than sampling overshoots and more mellow, but too loud.

Anything recorded like that can be thrown away.

What it shows is ear problems and a bad mixer (human, not table)
And even if it is called "concert pitch" it is waaaaay to high. (My Piano tuned at 402, which is low, but more natural)

[Fred vS]

A new version of the LazScope project has been released.  A few bug fixes and an 8 bit mode was added.

Attached an example trace of a middle C note played on a laptop and captured over the headphone jack.

Hello Ccrase.

Out-of-the-box, brilliant, nice and fast.

Big wow + congrats.

Fre;D

[ccrause]

Nyquist?
https://en.wikipedia.org/wiki/Nyquist_frequency

The sample frequency is about 63 kHz, so should be fine for capturing a 261 Hz sine wave.

The graph overshoots so the sampling is not correct. Not good for your ears. Just like my Marshall 130 watt clone is not good to my ears: London City, just from 1966 1969, made in Amsterdam. The latter is less painful than sampling overshoots and more mellow, but too loud.

Anything recorded like that can be thrown away.

This is a "pure" sine wave sample file, played via my laptop sound chip and sampled with a simple wire via blocking capacitor and DC offset resistor divider connected to a headphone jack.  Most of the noise in the plot is probably due to either low quality onboard amplifier or ambient electromagnetic interference picked up by the unshielded probe wire.  Note that even a Rigol DS1102E oscilloscope with a proper shielded probe shows significant noise for this, so the problem is probably somewhere between the sound chip and the location of the probe.

[CM630]

Are there chances to run it on more accessible devices like Nano/BluPill/BlackPill/Esp32?

[Thaddy]

It may be helpful to hard or soft clip the output with a small and cheap in compute IIR filter in software. It can also be solved if the software is written for, say, -3 dB instead of 0 dB. That is how hardware analog mixers usually work. Since the overshoot is small, try hard clipping (which is simply min/max). All of this won't help if the real waves are distorted: Most simple devices have just ADC 12 bit resolution, that may also be an issue.

[ccrause]

Are there chances to run it on more accessible devices like Nano/BluPill/BlackPill/Esp32?

The data transfer protocol is very simple, so the display side (GUI) can be re-used.  The firmware however needs to be rewritten for the different controller types, since the ADC and USART interfaces are quite different.  The firmware logic is very basic (configure ADC channels, fill buffer with ADC data, transmit buffer over serial, wait for next serial command). With more computing power one could implement more sophisticated features such as improved triggering (slope detection, trigger delay).

Which Nano are you referring to? The Arduino Nano uses an atmega328p, which is supported.

The ESP32 ADC performance is not great, however it adds the option to transfer data over wifi.

[Thaddy]

Slope detection is not necessary, but i would advise a simple 1 pole low-pass filter.
(that is just one state) I have code for that, if required.

[CM630]

Are there chances to run it on more accessible devices like Nano/BluPill/BlackPill/Esp32?

The data transfer protocol is very simple, so the display side (GUI) can be re-used.  The firmware however needs to be rewritten for the different controller types, since the ADC and USART interfaces are quite different.  The firmware logic is very basic (configure ADC channels, fill buffer with ADC data, transmit buffer over serial, wait for next serial command). With more computing power one could implement more sophisticated features such as improved triggering (slope detection, trigger delay).

Which Nano are you referring to? The Arduino Nano uses an atmega328p, which is supported.

The ESP32 ADC performance is not great, however it adds the option to transfer data over wifi.

Yes, I meant Arduino Nano. Are there any instructions on how to build the BIN for the Nano? Could I flash it through the USB port?
IMHO, uploading BINs for the supported devices might be useful.

I think I like the Blue/Black pills more than the Nano.

[ccrause]

Yes, I meant Arduino Nano. Are there any instructions on how to build the BIN for the Nano? Could I flash it through the USB port?
IMHO, uploading BINs for the supported devices might be useful.

There are prebuilt firmware images for several controllers, including atmega328p. Note that the prebuilt images are built for specific clock frequencies, the atmega328p image is built for 16 MHz clock, which is standard for Uno and Nano boards.

To build a firmware image requires a cross compiler for AVR, and AVR binutils for your host system.  You can build your own cross compiler or (probably much easier) use fpcupdeluxe to do the heavy lifting. And a copy of avrdude to flash the firmware.

Uno/Nano boards should have the Arduino bootloader installed, so flashing over USB should be possible using e.g. avrdude on Linux:

Code: Text  [Select][+][-]

1. avrdude -c arduino -p m328p -P /dev/ttyACM0 -D flash:w: sampler-atmega328p-16MHz.hex

On Windows the serial port will be something like COM3.

I think I like the Blue/Black pills more than the Nano.

More horsepower, but also more complex.

[marcov]

I once played around with this project:

https://www.elektormagazine.com/magazine/elektor-201602/28826

though that was because of the network connectivity (with Wiznet W5500).

Note that the project went through a few revisions (in the Dutch version),  and I don't know if this is the final one. Firmware was on github iirc. So some researching required.

But no FPC doesn't support that chip (33e MU/MC series), to my big regret

In the end however I needed a logic analyser more than a scope, and I currently have a dslogic U2 basic

[CM630]

I have flashed an Arduino Nano with https://github.com/ccrause/LazScope/releases/download/v0.2/sampler-atmega328p-16MHz.hex.
Then I run the Windows executable and connected it to the USB port of the Nano.
When I press “Connect” it says Connecter to COMxxx.
Then I check “Running” or “SingleShot” or both - nothing happens, but it says “Comms timeout”.
Two or three times I got some short waveform, and again “Comms timeout”.
I connected an UART cable instead of the USB - it cannot connect.

[Thaddy]

The comm rate on your port is not correct.

[ccrause]

I have flashed an Arduino Nano with https://github.com/ccrause/LazScope/releases/download/v0.2/sampler-atmega328p-16MHz.hex.
Then I run the Windows executable and connected it to the USB port of the Nano.
When I press “Connect” it says Connecter to COMxxx.

This is encouraging, it means that the Nano received and responded to the character 'e', meaning that at least nominally the serial communication is working.

Then I check “Running” or “SingleShot” or both - nothing happens, but it says “Comms timeout”.
Two or three times I got some short waveform, and again “Comms timeout”.

Checking "Running" without checking "SingleShot" should result in updating of the displayed trace a couple of times per second.  Checking "SingleShot will only display a single trace, then stop.

The serial communication may be marginally acceptable, leading to occasional data errors. You can also test the serial communication with any regular serial communication program/terminal.  After connecting to the serial port, send the 'e' character, the firmware should echo an 'e' back.  This is the initial handshake between the GUI and firmware.  You can also send an 's' character to the Nano, this requests a data frame from the firmware.  Expect a block of binary data as a reply.

I connected an UART cable instead of the USB - it cannot connect.

This should also work, although it should not be necessary since the USB port on the Nano is also a USB-serial converter.

There may be some latent problems on Windows, I only briefly tested the GUI on Windows. Just about all the development happened on Linux.