azonenberg changed the topic of #scopehal to: ngscopeclient, libscopehal, and libscopeprotocols development and testing | https://github.com/ngscopeclient/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
Degi has quit [Ping timeout: 252 seconds]
Degi has joined #scopehal
<_whitenotifier-4> [scopehal] azonenberg opened issue #949: PRBS checker filter: add scalar outputs for number samples integrated, number errors seen, BER - https://github.com/ngscopeclient/scopehal/issues/949
<d1b2> <fredzo_72653> Yes that's how it works on Sigrok too: you need to install Zadig and remap your device driver to Zadig. There is no generic USB-TMC diver, each manufacturer has its own proprietary Windows driver 😕
roos has joined #scopehal
<roos> Hello! I noticed ngscopeclient can now talk to the tinySA. I plugged my tinySA via USB-C, but didn't manage to get it working on Linux. Is there some config to do on the tinySA to get it working?
<roos> I took a look at the code in libscopehal and noticed it sends newline-terminated commands (e.g. `info`). However, it seems the device (or the ACM driver at least) expects `\r\n`-termination. So I tried some stty wizardry (onlcr, ...) to try and get it working without much success :(
<d1b2> <fredzo_72653> Hi @roos , I'm the one who committed the tinySA driver 😉 It was developed and tested on Windows with my tinySA Ultra. The driver is supposed to send \r\n terminated commands (see CommandLineDriver l.107 : m_transport->SendCommand(commandString+"\r\n");) Anything in ngscopeclient logs ? Does the uart connection complete ?
<roos> d1b2: It does not. (At least not without manually printf '\r\n' > /dev/ttyACM0.)
<roos> (I'll get you logs in a min.)
<roos> So, this is the line I found in the code where a newline is appended: https://github.com/ngscopeclient/scopehal/blob/master/scopehal/SCPIUARTTransport.cpp#L108
<roos> Which is a bit odd since the TinySA driver calls ConverseSingle (https://github.com/ngscopeclient/scopehal/blob/bb6d777866a12a5a6776a0d31ed15f14c3fbfe22/scopehal/TinySA.cpp#L62), which then calls ConverseString, who adds a `\r\n` before calling SendCommand in the UART transport (https://github.com/ngscopeclient/scopehal/blob/66657380a458a60758e24f658d6d1c0f127f0108/scopehal/CommandLineDriver.cpp#L107).
<roos> So I ran ngscopeclient --debug. In the add Oscilloscope menu, after I click "Add", the following line is printed: "Connecting to SCPI oscilloscope at /dev/ttyACM0:115200 with dtrEnable=false" and nothing else. It is now stuck.
<roos> If I then run `printf '\r\n' > /dev/ttyACM0`. I can make it progress (a bit), but then it's full of warnings. Here's the log: https://pastebin.com/HivtraSK
ALTracer has joined #scopehal
<d1b2> <fredzo_72653> Yeah tinySA driver doesn't use SendSCPICommand() that's not the problem. The ^M in the log seem to indicate that the \r somehow got converted to String which is odd... Can you try and communicate with your tinySA outside of ngscopeclient to confirm what data you get on the uart line ? Uppon connecting tu uart you should get a prompt in the form of "ch>\r\n" Then if you send "version\r\n" you shoud get "<versionstring>\r\nch>\r\n"
<azonenberg> roos: (btw d1b2 is the discord bridge bot, fredzo is the one you're talking to)
<azonenberg> anyway sounds like you two are making progress debugging, let me know if you need anything on my end
<azonenberg> if you want to see the LogTrace output you can run ngscopeclient with --debug --trace SCPIUARTTransport (or whatever the class name you want trace logging from is)
<roos> fredzo: I can confirm the specified behaviour if I set `stty -F /dev/ttyACM0 115200 -echo -icanon -onlcr -icrnl`. Then talk to the tinySA using `cat /dev/ttyACM0 | xxd` and `printf 'version\r\n' > /dev/ttyACM0` without issues.
<roos> So, I can see that the config set by scopehal is `115200 ignbrk -brkint -icrnl -imaxbel -opost -onlcr`.
<roos> Running `stty -F /dev/ttyACM0 -echo -icanon` unfreezes the init \o/
<roos> I can configure the sweep values without errors!
<roos> So, when I "arm the trigger in one-shot mode, I can download all the way to 90%, then it stops.
<roos> There's a lot of `[SCPIUARTTransport::ReadRawData] Got 3 bytes.` in the command output (using `--trace SCPIUARTTransport`, as azonenberg suggested).
<roos> Huh, actually it's still not quite successful... I can see some Warning messages in the logs still: `Warning: Unexpected response "" to command string "sweep".` and `Warning: Error while sending sweep stop value 332500000: "?".`.
<roos> So, by abusing `printf '\r\n' > /dev/ttyACM0`, I managed to get it to 100%, but the data is corrupted: https://ctrl.vi/i/y7BLVMhFh sigh...
<roos> I have to go now, but hopefully I'll be able to continue tomorrow (similar time). Thanks for the help!
<roos> Here are the full tty configurations - "default", "known working" and as configured by scopehal: https://pastebin.com/5vNGpeaF
roos has quit [Quit: leaving]
<d1b2> <fredzo_72653> OK great progress, well done !
ALTracer has quit [Remote host closed the connection]
ALTracer has joined #scopehal
ALTracer has quit [Remote host closed the connection]
ALTracer has joined #scopehal
<d1b2> <fredzo_72653> From the stty man page, I would say -icrnl is to be blamed: "icrnl translate carriage return to newline"