could this project interface with pulseview in any way?

[bojanjurca]

could this project interface with pulseview in any way?

[BojanJurca]

I'm sorry, I'm not familiar with PulseView. As far as I know it is open-source signal analysis software, but I've never looked into its code. I'd be glad if someone is willing to do so and find new ways of using it.

[kamocat]

Yes, it's possible. You would need to implement a SCPI interface over TCP, and a libsigrok driver for it.
Alternately, you could do it over USB like the rpi-pico does.

[BojanJurca]

Well, I can participate from my side to write a TCP SCPI interface. But, honestly, I don't think I have time to dig into SCPI and PulseView. So, if you are willing to do this job, I can do my part.

[kamocat]

Yes, I'm happy to handle the Pulseview side.

[BojanJurca]

So, how shall we start? Will you suggest what the communication protocol should look like?

[kamocat]

The communication is essentially a Telnet connection on port 5025 with human readable commands and responses. Each command ends with an "enter" or "return". A command with a question mark is a request.
Here's what I think we should implement.

• *IDN? - What the device is, firmware version, serial number
• SARA - Set the sampling rate
• NS - number of samples to capture
• CHAN - which channels to capture
• TRSE - Trigger type, channel, slope, value
• SET50 - Sets the trigger level to the center of the trigger source waveform
• ARM - Start a new acquisition
• STOP - Stops an acquisition
• SAST? - Gets the acquisition status
• DATA? - Gets the acquired data

[BojanJurca]

Telnet is not a problem. Could you also write an example of commands vit values? And what should a reply look like? Maybe something simple for the start?

[BojanJurca]

... "with" ..

[kamocat]

I've been loosely basing it off the SCPI implementation on my Siglent oscope, but I added some things they seem to have forgotten and left out a bunch of things that don't apply.
That said, if you want to rename any mnemonics or break up the complex TRSE into smaller simpler commands, it's perfectly ok.
Here's some examples:

Command: *IDN?
Response: *IDN Esp32 Oscilliscope v2.1, SN: ABC123ABC

Command: SARA 1e3
Response: Parameter out of range

Command SARA?
Response: SARA 733

Command: CHAN 31,32
Response: OK

Command: CHAN 31,32,34
Response: Too many parameters

Command: HELLO?
Response: Unknown command

Command: SAST?
Response: SAST Ready or SAST Trig'd or SAST Stopped

[BojanJurca]

Thank you.

Since there are all 3 servers involved I suggest we start with a complete package ( https://github.com/BojanJurca/Multitasking-Esp32-HTTP-FTP-Telnet-servers-for-Arduino ) and only deal with Pulseview specialities.

I'm not very familiar with Github. Could you create a fork or something? We need some space for the development files ...

[kamocat]

Ok. I made a scpi branch. https://github.com/BojanJurca/Esp32_oscilloscope/tree/scpi

[BojanJurca]

Great. Please give me a few days so I can compose the latest versions of the files into something that is working within existing functionalities and add the Telnet server as well. <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free.www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> V V tor., 30. apr. 2024 ob 16:39 je oseba Marshal Horn < ***@***.***> napisala:

…

Sure. I'll make a branch. — Reply to this email directly, view it on GitHub <#29 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKF3FLONJ2G323LKQULEH4DY76UIRAVCNFSM6AAAAABGLCF2XOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBVGUZDONZYGQ> . You are receiving this because you commented.Message ID: ***@***.***>

[BojanJurca]

I have uploaded the latest version of files and added a Telnet server running on port 5025 as well. I also implemented a simulation of SCPI command interpreter. Could you, please, check if this is how it is meant to be before we continue?

I would also need information when to start sampling and how to send samples back to the client?

Thank you. B.

[kamocat]

Thanks for the quick work! I will try it out tonight.
The sampling should begin according to the trigger settings (TRSE or whatever we decide to break that into), after the ARM command is sent.
I am still considering how the data should be sent back - it could be human-readable like comma separated values, or it could be something else.

[BojanJurca]

I can already see some problems. PulseView probably expects samples to be coming in at a fixed rate which may be a problem for ESP32.

If I2S interface is used everything would be OK, but I2S can only sampe one channel at a time. When two channel sampling is used there may be interruptions during samples, for the processor has also to do some other things, like WiFi, ... especially with the boards with only one core. I suppose this would cause some difficulties for Pulseview.

So, a quality signal can be obtained only through single channel I2S sampling or when sampling rate is relatively low.

[kamocat]

I believe you are correct that Pulseview expects a constant sample interval. I haven't dug into that part of the code yet.
On the other hand, ESP32-IDF does support DMA transfer from the ADC. I am not sure if this is possible within the Arduino framework. It looks like there was discussion of this in issue #21

[BojanJurca]

It is. With I2C. Single channel only, if the board supports it. It is not so bad. But not perfect either. V sre., 1. maj 2024, 23:05 je oseba Marshal Horn ***@***.***> napisala:

…

I believe you are correct that Pulseview expects a constant sample interval. I haven't dug into that part of the code yet. On the other hand, ESP32-IDF does support DMA transfer from the ADC. I am not sure if this is possible within the Arduino framework. https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/peripherals/adc_continuous.html — Reply to this email directly, view it on GitHub <#29 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKF3FLNX2Z3J77QRVVB6WYDZAFKJZAVCNFSM6AAAAABGLCF2XOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBZGEZTSMBQHE> . You are receiving this because you commented.Message ID: ***@***.***>

[kamocat]

I have uploaded the latest version of files and added a Telnet server running on port 5025 as well. I also implemented a simulation of SCPI command interpreter. Could you, please, check if this is how it is meant to be before we continue?

I have logged on to the telnet server, but could not get it to respond to any commands, even help.

[BojanJurca]

It was close only to the (simulation of) commands you provided. Now I opened it for other implemented Telnet commands as well. They are implemented in telnetCommandHandlerCallback function. Are you getting any reply or nothing at all? This is how it should look like:

C:\Users\uporabnik>telnet 10.18.1.56 5025

ESP32_oscilloscope says hello to 10.18.1.49.
Welcome root, use "help" to display available commands.

# *IDN?
*IDNESP32_oscilloscope SRV32-2.07-development, SN: C8:F0:9E:2D:F7:40
#

[kamocat]

The issue is on my end. It works fine with Putty in Windows, but not with the inetutils telnet client in Linux. I will look for a different client.
As for your question about "What must happen before ARM", I don't think there are any requirements. You already have good defaults. Sending ARM is just like pressing START in the UI, except that it would only run once instead of continuous. Likewise, the other settings (trigger, sample rate, channels) should be reflected in the UI.

Speaking of trigger settings, it looks like there's only two settings: rising threshold and falling threshold. This means the command can be as simple as TRSE <RISING> <FALLING>, where the values can be between 1 and 4095, or - for disabled

[kamocat]

Oh. There's Putty for Linux too. That's an easy solution.

[kamocat]

I'm going to make a dummy SCPI server in Python to test against Pulseview, which should both clarify the SCPI command behavior for Esp32_oscilloscope and help me develop the driver within libsigrok. I will link it here when it's ready.

[kamocat]

https://github.com/kamocat/fake_scpi
I haven't finalized the DATA command yet, but this should work for the rest.
I also removed all of the "OK" responses, as these didn't seem to be needed.

Now to dig into Pulseview...

[BojanJurca]

Thank you. I'll try to do something tomorrow.

[kamocat]

No hurry. I'm still trying to compile a new version of Pulseview.
I probably won't complete the driver for a couple weeks.

[BojanJurca]

Hello, I just wanted to let you know that I', still working on this. Besides being busy the last few days it turned out that the PulseView interface is more complicated than I anticipated. It may take a little longer to develop.

[BojanJurca]

I have uploaded the new code that is roughly working. There is still a lot to do yet but perhaps you could test if the protocol is OK and perhaps correct pulseViewCommandHandlerCallback function?

[kamocat]

Nice work! It looks mostly complete.
I will review and test it out next week.

I see you simplified the trigger options to be only rising OR falling. This was probably a good choice.

[kamocat]

I'm having trouble with the trigger settings command.

# TRSE 1 2
Parameter invalid
# TRSE FALLING 200
Command is not supported

I don't see that response in the Arduino code

    else if (argv0is ("TRSE")) { 
        if (argc == 3) {

            if (!pOscSharedMemory)    
                return "Out of memory";

            int value = atoi (argv [2]);
            if (value <= 0 || value >= 4055) {
                return "Parameter out of range";
            }
            if (!strcmp (argv [1], "RISING")) {
                pOscSharedMemory->positiveTrigger = true;
                pOscSharedMemory->positiveTriggerTreshold = value;
            } else if (!strcmp (argv [1], "FALLING")) {
                pOscSharedMemory->negativeTrigger = true;
                pOscSharedMemory->negativeTriggerTreshold = value;
            } else {
                return "Parameter invalid";
            }

        } else {
            return "Wrong number of parameters";
        }
    }

The other features seem to work, although my data is all zeros at the moment. I guess I should actually hook this up to a function generator instead of the LED I've been using as an analog source.

[BojanJurca]

Hi,
I'm currently away now and will get back to this project as soon as I come back.

You are right, I wanted TRSE FALLING 200 to work. 
"Command not supported" is a reply from the underlying Telnet server itself. If the callback function returns "" then the Telnet server tries to process the built-in commands itself (like ls, vi, etc...). Taking a look at the code, 2 returns are missing and it should look like this:

        if (!strcmp (argv [1], "RISING")) {
            pOscSharedMemory->positiveTrigger = true;
            pOscSharedMemory->positiveTriggerTreshold = value;
            return "OK";
        } else if (!strcmp (argv [1], "FALLING")) {
            pOscSharedMemory->negativeTrigger = true;
            pOscSharedMemory->negativeTriggerTreshold = value;
            return "OK";
        } else {
            return "Parameter invalid";
        }

As for the builtin LED pin, there are many different ESP32 boards and you can probably not analog-read builtin LED pin with all of them. If you just leave some ADC pin unconnected you should at least read some noise. You can also generate a PWM signal on one pin and connect it with a wire to some ADC pin:

    ledcSetup (0, 1000, 10);
    ledcAttachPin (16, 0);
    ledcWrite (0, 307);

Oscilloscope can perform both digital-read (0, 1) and analog-read (0 - 4095). I assumed that Pulse View would use only analog values, but I can easily change the code so that digital-reads would work as well. Just tell me what the command would look like in this case.

[kamocat]

Thanks for the quick reply. Adding return "OK" worked great.
I am still working on the libsigrok code. I am sorry for the slow progress.
The LED I have is wire-wrapped to GPIO 35, for measuring sunlight. It works well for direct measurement of sunlight or lightbulbs, but gives weird results in low-light conditions. I verified with my oscope - it's the LED, not the ESP32.