<d1b2>
<intricatebot> Sorry for my late response, and thank you for your time. I’m really excited to hear that ngscopeclient should work! I’d be happy for my team to be the first to get a device with all of those functions implemented at once. I will be meeting with them this Thursday, and I think it is highly likely we will end up using this. The project is still very young, so much hasn’t been decided. For interfacing to the PC, the current idea
<d1b2>
is to use USB-C because it would allow more power to be pulled from the user’s laptop if desired. For the MCU, we are looking into mixed signal MCUs and 32bit MCUs like an STM32. We will likely be starting with a dev board and a daughter board, and then make our own main board for the added benefits of the power system, but there is much more to be decided and researched. We haven’t decided if we were going to send a constant stream of data or do
<d1b2>
the conventional scope capturing. With that being said, I am trying to consider the performance for student’s laptops and what bandwidth can be achieved. Like you said, we are looking at probably a minimum of 1Msps with 2 channels. If constant data is streamed, students could see a lot of a signal which may be cool. I am wondering if the conventional scope style would be easier to implement on the mcu, and be a lighter work load on student laptops.
<d1b2>
What do you think about the real-time streaming vs conventional scope style? Scpi would be great if it is easier to implement. I will discuss it to my team. What kind of data rate would the scpi be able to achieve with the mcu? My understanding is that scpi would be used over the USB-C cable, and the USB protocol would not be used. Would this be correct? Thank you again for your assistance!
<d1b2>
<azonenberg> Single digit Msps is not pushing limits at all
<d1b2>
<azonenberg> at least on the software side
<d1b2>
<azonenberg> the ThunderScope, if you have a decent GPU, can push 1 Gsps of 8-bit ADC samples in real time
<d1b2>
<azonenberg> Your bottleneck will be firmware and the PC interface
<d1b2>
<azonenberg> SCPI is a text command protocol that can run over any transport you want
<d1b2>
<azonenberg> there's three obvious options
<d1b2>
<azonenberg> 1) use a UART on the MCU, external USB-serial bridge chip - least work, worst performance
<d1b2>
<azonenberg> 2) implement USB on the MCU as a serial port device class (CDC-ACM) - more work, performs better, probably doesn't need drivers on most OSes (likely the best option)
<d1b2>
<azonenberg> 3) implement USB on the MCU as a test and measurement device class (USBTMC) - more "standard" but will probably need someone to write a kernel driver on windows, probably will work fine on linux but tmc is annoying
<d1b2>
<azonenberg> my recommendation is to design your firmware so you can easily swap in one or the other, start with the UART and external bridge chip on a dev board
<d1b2>
<azonenberg> and if you have the time, stretch goal is CDC-ACM in firmware
<d1b2>
<azonenberg> ideally, design the PCB with a usb-serial chip and some components or jumpers you can move around - or just two usb ports - so that you can use the bridge or usb direct to the mcu without needing a hardware spin
<d1b2>
<azonenberg> from the ngscopeclient side, these are all the same
<d1b2>
<azonenberg> we have a layered driver model where the "driver" object just passes text commands and responses to/from a "transport" object which takes care of the actual hardware interfacing
<d1b2>
<azonenberg> the transport can be usbtmc, a uart, a tcp socket, or something more exotic. no other part of the stack cares
<d1b2>
<azonenberg> you just specify the transport and path when connecting to the instment
<d1b2>
<sigstoat> can ngscopeclient (easily) just hook straight up to a tcp socket if the other end does scpi?
<d1b2>
<azonenberg> Yes. that's the "lan" transport
<d1b2>
<azonenberg> just specify hostname and port and go to town
<d1b2>
<sigstoat> neat. thanks. need to get back around to the project where that's relevant.
<d1b2>
<azonenberg> implementing tcp/ip in your firmware is likely to be a fair bit of work, but it may be beneficial during e.g. driver development
<d1b2>
<azonenberg> you could make a pc based simulator for your instrument
<d1b2>
<azonenberg> connect to it with the lan transport to bring up the driver
<d1b2>
<azonenberg> try to share as much of the scpi protocol logic as possible between the simulator and your firmware
<d1b2>
<azonenberg> then just have modules you swap in at some point in the software to either go to mocks for testing or to actual hardware
<d1b2>
<azonenberg> The other transports we support are "null" (placeholder for test cases and simulators that don't actually talk to a scope), GPIB (trust me, you don't want to build GPIB into a new instrument in 2025, it's not 1985), VICP (Teledyne LeCroy proprietary transport layer for SCPI over a TCP socket, it's basically GPIB tunneled over TCP), LXI VXI-11 (clunky and awkward, you don't want to use this either)
<d1b2>
<azonenberg> and "twinlan" which is a high performance network interface that uses two TCP sockets, one for SCPI control plane and a second for raw binary waveform data
<d1b2>
<azonenberg> this makes it easier to multithread and separate control and data, but this is the kind of thing you think about when you're pushing orders of magnitude more waveform samples than your hardware will be capable of
<d1b2>
<azonenberg> so would just be unnecessary extra work for you
<d1b2>
<azonenberg> the "lan" transport is just scpi commands in plain text separated by newline characters with no other framing inside the TCP stream
<d1b2>
<intricatebot> This is very cool and is great information. Thank you for taking your time to message with me. I will look into these options.