Bug 1655 - Cannot connect to R&S RTC1002
Summary: Cannot connect to R&S RTC1002
Status: CONFIRMED
Alias: None
Product: libsigrok
Classification: Unclassified
Component: Driver: hameg-hmo (show other bugs)
Version: unreleased development snapshot
Hardware: x86 Windows
: Normal major
Target Milestone: ---
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-01-07 15:18 CET by juha_tk
Modified: 2021-10-11 20:59 CEST (History)
3 users (show)



Attachments
Log file (13.64 KB, text/plain)
2021-01-07 15:18 CET, juha_tk
Details
Log of data acquisition (26.57 KB, text/plain)
2021-01-08 08:29 CET, juha_tk
Details
Log of acquisition attempt RTB2004 TCP/IP (13.97 KB, text/plain)
2021-01-31 02:09 CET, Brad Ackerman
Details
Crash log (33.56 KB, text/plain)
2021-10-11 17:27 CEST, Raphaël Doursenaud
Details

Note You need to log in before you can comment on or make changes to this bug.
Description juha_tk 2021-01-07 15:18:07 CET
Created attachment 710 [details]
Log file

I have tried to connect RTC1002 several ways without success. Tested also with latest release version and both x86 and x64 versions.

LAN connection finds the device, but after clicking Connect in PulseView, UI freeze (Not responding). Cannot get log out of this in PulseView.

USB mode (serial emulation) finds the device and starts communication but then communication crashes. See attached log file.
Comment 1 Ralf 2021-01-07 19:38:53 CET
I have no hameg-hmo to test and I don't know the driver, but would like to give it a try.

The log you provided shows, that failing CHAN2 is set to 50V:

sr: scpi_serial: Successfully sent SCPI command: ':CHAN2:SCAL? '.
sr: scpi: Got response: '5.00E+01', length 8

CHAN1 is set to 5V:
sr: scpi_serial: Successfully sent SCPI command: ':CHAN1:SCAL? '.
sr: scpi: Got response: '5.00E+00', length 8.


In the driver source code I can see, that the vdivs-table only supports up to 10V.
Could you please try with CHAN2 limited to 10V (or below) to see, whether it works?
Comment 2 juha_tk 2021-01-08 08:29:47 CET
Created attachment 711 [details]
Log of data acquisition
Comment 3 juha_tk 2021-01-08 08:33:29 CET
After changing scaling to 10V/div I was able to connect RTC1002 using USB VCP.

LAN connection finds the device but when I click OK in "Add new device" dialog, UI goes to Not responding state and nothing happens.

I can acquire POD data, but CH1 and CH2 does not show any data. Log attached.

PulseView crashes also very easily. Program just shutdowns without warning. Is there way to get log on these crashes somehow?
Comment 4 Ralf 2021-01-08 11:40:06 CET
In the log files I can see, that driver hameg-hmo does not send actual data to PV, although there seems to come some data from serial:
sr: serial: Read 3344/12295 bytes.
sr: session: bus: Received SR_DF_ANALOG packet (0 samples).

As said before, I am not familiar with the driver and can't see what goes wrong here


To get crash reports on Windows the wiki may help:
https://sigrok.org/wiki/Windows#How_do_I_see_debug_output_from_PulseView_on_Windows.3F
Comment 5 juha_tk 2021-01-08 12:12:14 CET
Thank you for the support!

I also tried debug build with separate log console, but also the log console crashes when PulseView crashes.
Comment 6 Brad Ackerman 2021-01-31 02:09:17 CET
Created attachment 720 [details]
Log of acquisition attempt RTB2004 TCP/IP

Attempt at connecting to RTB2004 w/ 0.5.0-git-89b7b94
Comment 7 Brad Ackerman 2021-01-31 02:11:01 CET
Confirmed with current nightly Windows x64 (0.5.0-git-89b7b94) and RTB2004. IDs scope, reopens device instance, sends ':CHAN1:STAT?', then nothing.
Comment 8 Raphaël Doursenaud 2021-10-11 17:27:32 CEST
Created attachment 754 [details]
Crash log

I also own a RTC1002 and hoped using it with Sigrok.
I’ve started hacking at the source to add the device’s idiosyncrasies with some good results yet I’m also bitten by the random crashing and am still unable to confirm any capture working because of that.

I managed to capture the crash which seems to be related to some internal types conversion. I’m not familiar enough with the codebase to trace where it may come from. See attachment.
Comment 9 Raphaël Doursenaud 2021-10-11 20:59:12 CEST
FWIW I’ve been able to keep the debug console open by launching pulseview from a CLI (Powershell in Windows Terminal in my case but the standard Windows cmd.exe should work just fine).