(re-sending as I think original might have gotten lost during sourceforge
outage a couple of days ago — apologies if it shows up as a duplicate)
Hi,
I just started playing with Sigrok & am pretty excited about it :)
I've been trying to get data from my Rigol DS1204b over ethernet. (The DS1204B
is a 4- channel, 200Mhz scope in the DS1000 line with LXI support), from an OSX
10.9 machine.
Seems like there are a few places that need some help in order to make this
work. I just started poking at the code last night, so still pretty green on a
lot of the ways things are organized & done, but think I've got at least
initial stabs at some of the issues...
Getting DS1204b recognized by ligsigrok (easy part):
diff --git a/src/hardware/rigol-ds/api.c b/src/hardware/rigol-ds/api.c
index 1c2a2ba..8ef3583 100644
--- a/src/hardware/rigol-ds/api.c
+++ b/src/hardware/rigol-ds/api.c
@@ -215,6 +215,7 @@ static const struct rigol_ds_model supported_models[] = {
{SERIES(DS1000), "DS1052D", {5, 1000000000}, 2, true},
{SERIES(DS1000), "DS1102D", {2, 1000000000}, 2, true},
{SERIES(DS1000), "DS1152D", {2, 1000000000}, 2, true},
+ {SERIES(DS1000), "DS1204B", {1, 1000000000}, 4, false},
{SERIES(DS2000), "DS2072", {5, 1000000000}, 2, false},
{SERIES(DS2000), "DS2102", {5, 1000000000}, 2, false},
{SERIES(DS2000), "DS2202", {2, 1000000000}, 2, false},
Getting the SCPI VXI stuff to work seems to have a couple bigger issues...
First one I ran into is that scpi_vxi_send() appends a CR/NL to the command.
The DS1204b doesn't like that -- I haven't been able to tell whether (like with
some other transports) there are assorted types of message terminators ( CR,
CR/NL, NL, hardware EOI ) that different hardware supports, or whether CR is
not allowed by spec but some hardware will just ignore it, or whether it's
actually not ok...
Removing the CR gets things to work for this unit:
diff --git a/src/scpi/scpi_vxi.c b/src/scpi/scpi_vxi.c
index 62bf8c6..d7c34f0 100644
--- a/src/scpi/scpi_vxi.c
+++ b/src/scpi/scpi_vxi.c
@@ -120,7 +123,7 @@ static int scpi_vxi_send(void *priv, const char *command)
char *terminated_command;
unsigned int len;
- terminated_command = g_strdup_printf("%s\r\n", command);
+ terminated_command = g_strdup_printf("%s\n", command);
len = strlen(terminated_command);
write_parms.lid = vxi->link;
Whether that is broadly fine or whether it's necessary to have a configurable
message termination for different hardware, I'm not sure.
Next piece is that sigrok-cli's run_session() will leave open the RPC
connection used to find instruments by sr_driver_scan(), and then try to open
another connection with sr_dev_open(); this second connection will fail since
the first is still open.
I've hacked around this by having ligsigrok's scpi_vxi_open() just return SR_OK
if there's already an open client connection from the scan:
diff --git a/src/scpi/scpi_vxi.c b/src/scpi/scpi_vxi.c
index 62bf8c6..60b42c4 100644
--- a/src/scpi/scpi_vxi.c
+++ b/src/scpi/scpi_vxi.c
@@ -65,7 +65,10 @@ static int scpi_vxi_open(void *priv)
Create_LinkParms link_parms;
Create_LinkResp *link_resp;
+ if (vxi->client != NULL) {
+ return SR_OK;
+ }
vxi->client = clnt_create(vxi->address, DEVICE_CORE, DEVICE_CORE_VERSION
if (vxi->client == NULL) {
sr_err("Client creation failed for %s", vxi->address);
return SR_ERR;
but this seems a bit... ugly; wondering if someone familiar with the code might
have some better thoughts?
At this point things seem to work. Am definitely in a place of steep learning
curve on the interface (spent a while trying to track down an issue with comms
failing; had scope in auto trigger so didn't realize the issue was that it
wasn't sending data because it didn't see an actual trigger).
Thanks,
-Tymm
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
vanity: www.gigenet.com
_______________________________________________
sigrok-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
