Yes, the i_range value should support both JSON integers from 0 to 6 and JSON strings "0" to "6". You do need to be careful to provide valid JSON with the ASCII codes 48 (0) to 54 (6) surrounded by normal double quotes ASCII 34. I wonder if you are stumbling upon a UNICODE / language issue? Regardless, integers are much easier to get right.
Yes I think also to a UNICODE kind of problem.
I’ll use integers when it will be possible, so I hope that hence forth I’ll disturb you less 
1 Like
Hi Matt,
all seems now to be OK except when I wan’t to close the connection. as I am unable to solve this problem, I allow myself to submit it to you : I’m sure you’ll find easily the reason
INFO:2021-09-29 14:48:24,387:server.py:259:joulescope_server.server:_statistics_fn Joulescope:001747
INFO:2021-09-29 14:48:24,887:server.py:259:joulescope_server.server:_statistics_fn Joulescope:001747
INFO:2021-09-29 14:48:24,897:server.py:355:joulescope_server.server:recv: {“type”: “stop”, “phase”: “req”, “id”: 10, “status”: 0, “status_msg”: “”, “device”: “Joulescope:001747”, “data”: []}
INFO:2021-09-29 14:48:24,898:driver.py:880:joulescope.driver:stop : streaming=True
INFO:2021-09-29 14:48:24,898:device.py:789:joulescope.usb.winusb.device:read_stream_stop 2
INFO:2021-09-29 14:48:24,898:device.py:415:joulescope.usb.winusb.device:endpoint stop
INFO:2021-09-29 14:48:24,898:driver.py:810:joulescope.driver:streaming done(0, )
INFO:2021-09-29 14:48:24,899:server.py:315:joulescope_server.server:_stop_fn Joulescope:001747
INFO:2021-09-29 14:48:24,910:server.py:374:joulescope_server.server:send: {“type”: “stop”, “phase”: “rsp”, “id”: 10, “status”: 200, “status_msg”: “Success”, “device”: “Joulescope:001747”, “data”: true}
INFO:2021-09-29 14:48:25,216:server.py:355:joulescope_server.server:recv: {“type”: “close”, “phase”: “req”, “id”: 11, “status”: 0, “status_msg”: “”, “device”: “Joulescope:001747”, “data”: []}
INFO:2021-09-29 14:48:25,217:driver.py:880:joulescope.driver:stop : streaming=False
INFO:2021-09-29 14:48:25,217:device_thread.py:208:joulescope.usb.device_thread:close
INFO:2021-09-29 14:48:25,217:device.py:697:joulescope.usb.winusb.device:WinUsbDevice.close
INFO:2021-09-29 14:48:25,217:device_thread.py:102:joulescope.usb.device_thread:DeviceThread._cmd_process_all close
INFO:2021-09-29 14:48:25,217:device_thread.py:132:joulescope.usb.device_thread:DeviceThread.run flush
INFO:2021-09-29 14:48:25,217:device_thread.py:134:joulescope.usb.device_thread:DeviceThread.run done
INFO:2021-09-29 14:48:25,217:server.py:374:joulescope_server.server:send: {“type”: "close", “phase”: “rsp”, “id”: 11, “status”: 200, “status_msg”: “Success”, “device”: “Joulescope:001747”, “data”: []}
ERROR:2021-09-29 14:48:25,217:server.py:380:joulescope_server.server:handle_client error
Traceback (most recent call last):
File “C:\Users\Thierry\AppData\Local\Programs\Python\Python39\lib\site-packages\joulescope_server\server.py”, line 354, in run msg = await framer.treceive(self._reader)
File" C:\Users\Thierry\AppData\Local\Programs\Python\Python39\lib\sitepackages\joulescope_server
\framer.py", line 109, in treceive raise ValueError(‘unsupported tag’)
ValueError: unsupported tag
INFO:2021-09-29 14:48:25,218:server.py:250:joulescope_server.server:_async_task done
INFO:2021-09-29 14:48:25,218:server.py:386:joulescope_server.server:ClientManager.run done
I send “close” command only after I have received “stop” answer from server.
Concerning “unsupported tag” I really don’t understand : it’s the same “AJS” tag I send for every command.
Thank you !
Hi @Tverc2
Based on the log, the server received the “close” command, processed it, and returned a response to the client. The server then goes to get more data from the socket, which the client should close after receiving the response to the “close” command. However, in the log above, the server received more data from the client. It attempts to process this data, but the tag is not valid.
When your new client receives the response to the “close” command, it should immediately close the socket without writing any more data.
The server’s behavior to a closed socket and to invalid data is actually the same. The server’s ClientManager.run() loop exits which causes the server to close the socket. The only difference with writing invalid data is the error indication from the log above.
Does this make sense?
“When your new client receives the response to the “close” command, it should immediately close the socket without writing any more data.”
Yes, it’s exactly what I do : at the end, the only command I send is “close” (after receiving the response to “stop” command).
I just tried to shorten time between the response to “close” command and close the socket but result is similar : the problem remains …
I just suppressed “Start” and “Stop” command to see if problem was linked to raw data flux : the same problem remains …
I just updated the server on GitHub to display more information about the tag and payload on this error. Could you get the latest and see what it says? Is it possible that LabView is sending data on close?
Here is what I see with the demonstration client & server when the socket closes:
INFO:2021-09-29 11:09:55,006:server.py:374:joulescope_server.server:send: {"id": 8, "type": "stop", "phase": "rsp", "device": "Joulescope:000147", "status": 200, "status_msg": "Success", "data": true}
INFO:2021-09-29 11:09:55,007:server.py:355:joulescope_server.server:recv: {"id": 9, "type": "close", "phase": "req", "device": "Joulescope:000147"}
INFO:2021-09-29 11:09:55,008:driver.py:880:joulescope.driver:stop : streaming=False
INFO:2021-09-29 11:09:55,008:device_thread.py:208:joulescope.usb.device_thread:close
INFO:2021-09-29 11:09:55,008:device.py:697:joulescope.usb.winusb.device:WinUsbDevice.close
INFO:2021-09-29 11:09:55,008:device_thread.py:102:joulescope.usb.device_thread:DeviceThread._cmd_process_all close
INFO:2021-09-29 11:09:55,009:device_thread.py:132:joulescope.usb.device_thread:DeviceThread.run flush
INFO:2021-09-29 11:09:55,009:device_thread.py:134:joulescope.usb.device_thread:DeviceThread.run done
INFO:2021-09-29 11:09:55,009:server.py:374:joulescope_server.server:send: {"id": 9, "type": "close", "phase": "rsp", "device": "Joulescope:000147", "status": 200, "status_msg": "Success"}
INFO:2021-09-29 11:09:55,010:server.py:377:joulescope_server.server:Client closed socket
INFO:2021-09-29 11:09:55,010:server.py:250:joulescope_server.server:_async_task done
INFO:2021-09-29 11:09:55,010:server.py:392:joulescope_server.server:ClientManager.run done
INFO:2021-09-29 11:09:57,293:win32_device_notify.py:86:joulescope.usb.winusb.win32_device_notify:close
I can then type CTRL-C into the server and exit the server.
I tried with the new server software but comments seems to be exactly the same : no more details on tag error …
Concerning data sent by Labview when I close the socket I don’t think it’s the case (but all is always possible …). The best should certainly be to use Wireshark or similar to “sniff”, but I’m not a specialist of this and I’m not sure it’s really possible (Labview and Server are on the same PC).
I have to go but today I’ll try anyway to sniff what happens on link between Labview and Server.
Hopefully, the ValueError: unsupported tag should have additional detail ValueError: unsupported tag: tag={something}, payload={something}. Do you see this?
Have a good evening. I should be online around noon UTC tomorrow.
I have solved the problem !!! 
-
I’m really not a Python & Github user so when I thought I have updated your modified Server software, it was not the case… I continued to run with old version : it explain why I didn’t see modifications.
-
This morning I downloaded the last version (certainly not in the simplest way …
) and I obtained :
INFO:2021-09-30 11:04:48,054:server.py:374:joulescope_server.server:send: {“type”: “close”, “phase”: “rsp”, “id”: 11, “status”: 200, “status_msg”: “Success”, “device”: “Joulescope:001747”, "
data": []}
ERROR:2021-09-30 11:04:48,057:server.py:380:joulescope_server.server:handle_client error
Traceback (most recent call last):
File “C:\Users\Thierry\AppData\Local\Programs\Python\Python39\lib\site-packages\joulescope_server\server.py”, line 354, in run
msg = await framer.treceive(self._reader)
File “C:\Users\Thierry\AppData\Local\Programs\Python\Python39\lib\site-packages\joulescope_server\framer.py”, line 109, in treceive
raise ValueError(‘unsupported tag: tag=%s, payload=%s’ % (tag, payload))
ValueError: unsupported tag: tag=b’\x00\x00\x00’, payload=b’'
INFO:2021-09-30 11:04:48,062:server.py:250:joulescope_server.server:_async_task done
-
Thanks to these info, I quickly understood problem was due to Pads \x00 at the end of the “close” message : in case the message’s length was a multiple of 8 bytes, I had added 8 \x00 pad bytes instead zero ( it was more simple when I wrote first Labview code 1 week ago, but finaly not a so good idea …).
-
After correction, all is now OK in the “close” phase.
-
And it explains also why “180 mA” and “1.8 mA” didn’t work : corresponding message lenght is an exact multiple of 8 bytes. So, I can now not only close the connection without any problem but I can even parameterize an “i_range” = "180 mA " or "180 µA " with succes !
Thank you again fot all the precious help you gave me to solve all the problems I have encountered. As soon I’ll have cleaned up this Labview software prototype, I’ll post it. It’s the least I can do to thank you !
1 Like
Excellent! Great to hear that this same fix also addresses the strange behavior with some other messages, too. Let me know if you want any more help, and I look forward to sharing your code with other LabVIEW + Joulescope users!
1 Like
Hi Matt,
here is the code :
Lab_Joulescope_Server.zip (2.4 MB)
I suppose it’s possible to put it on Github but I don’t know how to do → I let you do it if you think it’s necessary.
Procedure :
- Connect Joulescope on PC
- Launch Joulescope Server (prompt)
- Launch Lab_Joulescope.vi
Warning : it’s just a prototype (no errors gestion/ no signal treatment )
If Labview+ Joulescope users want to improve it, they can ! And if they want to share their improved code and/or send comments, they are welcome !
1 Like
Hi @Tverc2 - Thank you! I will definitely want to post this on GitHub. May I have your permission to release this under the Apache 2 license? How would you like your copyright line to appear? For example, the Joulescope server uses:
# Copyright 2020 Jetperch LLC
I should update this to be 2020-2021!
1 Like
No problem : you have my permission to post it under Apache 2 !
Concerning copyright, I don’t know. I can’t use the name of my firm because work was done outside.
Is it possible to symbolically use Tverc2 ?
1 Like
Here is the front view with a signal’s example :
I have omitted : software has been developed on Labview 2015
1 Like
Hi @Tverc2
I created a new joulescope_labview_client repository on GitHub. I added a readme and published the code. Thank you!
Regarding using Tverc2, I think that falls under the use of a pseudonym which is acceptable under US law. Since it’s Apache 2.0 licensed, people can pretty much do what they want with this code, anyways. The copyright and license are positive assurances that they have the right to use this code.
If you take a look and want me to update anything, let me know! You can comment more here or create a GitHub issue.
1 Like
Thank you Matt !
Very happy with our collaboration on this topic and proud to contribute to Joulescope communittee
I hope Labview+ Joulescope users will be interested by this code , will improve it, and also share their improvement.
Let it me know !
1 Like
Hello,
I’m using Joulescope in an AC electrolysis experiment using two identical inert graphite electrodes. I want to process a single cycle of the JS stream in LabView to obtain a plot of current vs. voltage (cyclic voltammetry without reference to a standard electrode). Will the LabView client work with a saved .jls file as well as with the live stream?
Tracy Hall Jr, Hall Labs, Provo, Utah
Hi @hthalljr - The Joulescope LabView client connects to the pyjoulescope_server. The existing version of the pyjoulescope_server only provides access to connected Joulescopes. It does not have any support to:
- Replay previously captured JLS files.
- Capture JLS files
I am not familiar with cyclic voltammetry, but this article is a nice introduction. The Joulescope JS220 sounds like a great instrument for capturing this data!
I would like to ask a few questions to help find an appropriate solution for your measurement challenge:
- LabVIEW is often used to automate processes, but I am not sure that is what you are requesting with respect to your Joulescope. Does it matter if you always capture the Joulescope data to a file and analyze after collection? One possible approach would be to capture statistics data to a CSV file and then analyze that CSV file in LabVIEW.
- What is the duration of a single cycle (the data you want to capture and process)?
- What sample rate do you need? I am guessing that the full 1 Msps is more than you need.
- Are you using a JS110 or JS220?
Thanks for your prompt and helpful response.
- LabVIEW is often used to automate processes, but I am not sure that is what you are requesting with respect to your Joulescope. Does it matter if you always capture the Joulescope data to a file and analyze after collection? One possible approach would be to capture statistics data to a CSV file and then analyze that CSV file in LabVIEW.
I have about a hundred JLS files saved from about a dozen experiments, and I’ll need to extract waveform data from several of them. I haven’t yet used the feature of capturing statistics data: I’ll look into that. I don’t necessarily have to use LabView for my analysis, as long as I can extract the time, current, and voltage into a spreadsheet.- What is the duration of a single cycle (the data you want to capture and process)?
I’m investigating a frequency range from about 300 Hz down to about 3 Hz. I typically sample until I have about 20 cycles on the screen, which gives me good statistics, and save that to a JLS file. But I’ll typically only be analyzing a single representative cycle.- What sample rate do you need? I am guessing that the full 1 Msps is more than you need.
Indeed, I don’t need the full 1 Msps. I’ll only need to divide a single cycle into about 200 points, so for 300 Hz: 60 ksps; for 3 Hz: 600 sps.- I have the JS220. Wonderful instrument!
- Tracy