ESP32 Oscilloscope Skips Screen For The Browser

An oscilloscope can be an expensive piece of equipment, but not every measurement needs four channels and gigahertz sampling rates. For plenty of home labs, old oscilloscopes with CRTs can be found on the used marketplace for a song that are still more than capable of getting the job done, but even these can be overpowered (not to mention extremely bulky). If you’re looking for something even cheaper, and quite a bit smaller, this ESP32 scope from [BojanJurca] might fit the bill.

The resulting device manages to keep costs extremely low, but not without a trade-off. For this piece of test equipment, sampling is done over the I2C bus on the ESP32, which can manage a little over 700 samples per second with support for two channels. With the ESP32 connected to a wireless network, the data it captures can be viewed from a browser in lieu of an attached screen, which also keeps the size of the device exceptionally small. While it’s not a speed demon, that’s more than fast enough to capture waveforms from plenty of devices or our own circuit prototypes in a form factor that can fit even the smallest spaces.

Of course for work on devices with faster switching times, it’s always good to keep a benchtop oscilloscope around. But as far as we can tell this one is the least expensive, smallest, and most capable we’ve come across that would work for plenty of troubleshooting or testing scenarios in a pinch. We’ve seen others based on slightly more powerful microcontrollers like this one based on the STM32 and this other built around the Wio Terminal with a SAMD51, both of which also include built-in screens.

29 thoughts on “ESP32 Oscilloscope Skips Screen For The Browser

  1. Genuinely one of the best ideas I’ve seen in a long while. Especially with the triggering I don’t think I’d often need anything else.

    All it needs is a JavaScript based asteroids implementation.

        1. And there’s a DMA engine, so you wouldn’t have to load down the processor. But not all of us are systems programmers, so perhaps this project could profit from some collaboration.

      1. The article actually seems incorrect about that, there is no mention of an external ADC in the project and if you look at the screenshot it shows that the UI is based around direct reading of GPIO pins, not setting I2C SDA/SCL pins.

  2. I call this a “fast voltmeter”. Does the author have any examples of signals that would be useful to observe at 700 samples per second? Even the slowest UART would be too fast…

    1. For some folks this would be quite useful. Things I have seen in this range: PWM, diagnosing 60 cycle hum on analog cercuits, motion detectir pulses, flashing light signals, and signals on consumer appliances (latching pulses on my washer were too fast for my DMM for instance).

      1. At 700 sps aliasing becomes a big problem, creating spurious readings for any frequency component over 350 Hz. You need a “brick wall” filter at that frequency, and it’s rather difficult to make one. It would read the common Arduino Uno 450/1000 Hz PWM signal incorrectly.

        Someone might check whether they’re using supersampling to avoid that; with a naive implementation that just takes 700 samples a second, you won’t get much useful measurements out of just about anything.

    2. This looks super handy in motorsports for data logging. My bike’s 12k rpm engine being the highest frequency “thing” should be comfortably within this sample rate no? The light weight and small packaging is a huge bonus.

      And if it doesn’t hold up for years to the heat and vibrations, who cares it’s cheap to replace.

  3. From the project page:
    “ESP32 oscilloscope was first meant to be just a demonstration of the Multitasking-Esp32-HTTP-FTP-Telnet-servers-for-Arduino ( capabilities and is still fully included there, but it seems to be better off on its own. Only functionalities necessary for an oscilloscope to work are used here.”

    It isn’t intended to be a useful oscilloscope. It is only intended to show how to use a specific threadind/multitasking library on the ESP32.

  4. Something like this on a Raspberry Pi Pico RP2040 with its faster ADC and ability to do USB bulk transport to the computer should be able to stream continuously at 1 MSPS. That sort of data capture is really difficult to do on existant (mostly screen based) microcontroller oscilloscopes, classic ociliscopes, and even sub $500 modern ones. It would be great for many digital signals, IR, some radio, audio and even ultrasound! On such a cheap chip this would be really empowering. I have seen some similar projects, does anyone know of one that would be good for 1 MSPS to disk or for signal processing on a computer (python or GNUradio)?

    1. Gabotronics has a quite nice overview on their website:

      But on the “hobby level” (<EUR50) price range it is very rare to see anything which has any sort of front end. The DSO Shell ( yjetech, partially open sourced) is an exception. If it had better software it would even be a nice gadget, Especially if you could chain multiple devices into a multi channel thing. But if you want a usable scope, then the Owon Handhelds (starting form around EUR150 are probably the best option. I would avoid anything from Fnirsi. That brand lies through their teeth, and beginners are likely not able to recognize in which ways the gadgets from that brand are flawed. Don't fall in their trap.

      And overall. I bought a Siglen SDS1104X-E myself recently for around EUR450. I find it completely astonishing how much scope you get for such a modest stack of paper.

  5. HTTP blocked by browsers: increasingly browsers are insisting on HTTPS and reporting “This site can’t be reached” if it only supports HTTP. Since most microcontrollers are never going to have the horsepower to do fully encrypted traffic (plus certificate management) this is a major problem for IoT web based applications. (Yeah the chips will get faster but there will always be newer small chips that won’t work).

    Does anyone have a good browser for HTTP only sites? Chrome, Firefox, Edge are all becoming unreliable for IoT and home automation applications. There may be settings that nerf them down up but it appears updates remove those settings so you will be forever tinkering with the settings.

    1. It’s becoming a bit of a PITA, to be honest. I’ve had an analogous problem configuring my ‘old’ Netgear routers in the home network because I can’t run javascript elements any more; and now, I can’t find a browser that doesn’t cause a cipher mismatch.

      I do have an old G3 iMac in a closet, that runs a 20 year old version of Yellowdog Linux that does work, or I can usually use the command line from a telnet session. (suitably locked down to a local subnet) I wonder how long I will be permitted to use that.

  6. This article is a bit misleading/useless imo – first off, there is no I2C involved. It clearly shows in the article headline image that the GPIOs are being read directly with the onboard ADC.

    The repo also states that it is only intended as a demo of the author’s multithreading library. 700 sps is too low to be useful for much of anything. The fact that it uses WiFi (which renders ADC2 useless and slows down sampling) is icing on the turd cake.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.