<d1b2>
<fredzo_72653> Hi @azonenberg , yeah I asked myself the same but after checking, I don't think it would affect other devices negatively (and I could confirm that with 3 other devices that I have) since that value for this parameter only statically activates the DTR line vs. DTR_CONTROL_HANDSHAKE that is for actual DTR handshaking. Anyway, let me know what you think: adding a DTR parameter to the connection string is not a problem, it's just that it may
<d1b2>
lead to "My NanoVNA doesn't connect" questions if the user doesn't RTFM to see that he needs to add a DTR parameter when connecting his NanoVNA.
<d1b2>
<azonenberg> Yeah I think we should still add a connection string, there might be devices that use dtr for other stuff
<d1b2>
<azonenberg> and then add a corresponding line to the manual
<d1b2>
<azonenberg> later on i want to work on ways to make transports pick defaults based on the device you'r talking to
<d1b2>
<genialeprutser> I was wondering: is ngcs capable of capturing for a very long time? Does the captured data has to fit inside of the computer's memory, or can it be streamed out to disk? What happens when ngcs crashes (or the computer decides to reboot)? Is the captured data then gone, or was it auto saved somewhere? The limit for analog signals is 2^30 samples. Is there also such a limit for digital samples? Can ngsc start a new capture after the
<d1b2>
previous one has grown too big?
<d1b2>
<azonenberg> A single waveform is limited to 4GB or whatever your Vulkan implementation's upper limit is, if less
<d1b2>
<azonenberg> This translates to 2^30 analog or 2^32 digital samples
<d1b2>
<azonenberg> There is no auto saving, if you want waveform data save the session to a file
<d1b2>
<azonenberg> if you run in normal-trigger mode, you can continually re arm the trigger as soon as a previous waveform ends
<d1b2>
<azonenberg> there may or may not be a small gap between the two waveforms depending on the specific scope in question
<d1b2>
<azonenberg> As of now, the total of all waveforms in history has to fit in RAM but the architecture allows for paging older waveforms out to disk eventually
<d1b2>
<azonenberg> it's just not currently supported
<d1b2>
<azonenberg> The other thing to keep in mind is that the duration of a single waveform is limited to +/- 2^63 x axis units, regardless of how many samples long it is
<d1b2>
<azonenberg> right now, the standard x axis unit for time domain waveforms is femtoseconds
<d1b2>
<azonenberg> So this comes out to something like five hours, i think, centered at T=0
<d1b2>
<azonenberg> there are open wishlist items for more flexible units for low resolution captures that don't need such precise timing (and for other reasons), but it's architecturally nontrivial to do
<d1b2>
<azonenberg> These are limits we're aware of, and would like to remove eventually, but it's not easy