Hi there,
I’m trying to use the python joulescope wrapper/driver on a JS220 to record some digital signals.
Doing so through GPI0 and GPI1 a;ready works just fine. Now since the device I’m using to generate the signal has exactly 4 pins in parallel, (using Out0 as a supply) it would be perfect if I could use GPI2 instead of GPI1 to record.
I did see in the wrapper’s parameter validation, that current_lsb and voltage_lsb are both restricted to accept GPI0 and 1 only. Can that be circumvented somehow?
Is there any reason why that is the case?
Thank you in advance
With best regards,
Peter
Hi @peter-sony and welecome to the Joulescope forum!
The joulescope package API is limited to the functions of the original JS110. We have not yet extended that API to support the newer JS220 features. The JS110 has two GPI’s that it placed into the current and voltage LSBs. The JS220 now uses dedicated channels for GPI data, but we made the joulescope package fully forwards compatible with the JS220.
The easiest way to get access to the additional general purpose inputs IN2, IN3, and Trigger is to use the pyjoulescope_driver package directly. The joulescope v1 backend uses pyjoulescope_driver to talk to the instruments.
If you are just looking to record data from the command line, you can use the record entry point. Here is an example:
python -m pyjoulescope_driver record --signals i,v,p,0,1,2,3 out.jls
You can also use the Record class directly in your script. The record entry point shows an example.
Does this make sense and do what you want?
Hi @mliberty, thank you for your swift reply.
Okay. I see, that makes sense.
I looked through the entry points of the pyjoulescope_driver package.
I see how to acquire the signal.
We are integrating joulescope quite deeply for the work we are doing atm.
So really what I tried to do is providing a wrapper to our ecosystem that can record directly into memory and also stream (i.e. my wrapper handling samples immediately as they come in).
For that, I have been using the StreamProcessApi of the joulescope package which was pretty handy and easy to use.
I saw that there is no equivalent in the /v1/ portion of joulescope and couldn’t make out an obvious way to do this with pyjoulescope_driver. I.e. /v1/stream_buffer.py doesn’t support the other GPI pins or does it?
Any hints on how I can get something similar and make GPI2+3 fit into that scheme?
Thank you,
Best
Peter
I understand that you would rather stay with the joulescope package. The existing StreamBuffer implementation is hard-coded to support only the JS110 signals: current, voltage, power, current_range, current_lsb (IN0), voltage_lsb (IN1).
The StreamBuffer.samples_get already has a fields argument which would be easy to extend for JS220 support. We could allow you to specify other JS220 fields. However, you would have to specify ahead of time which fields you want. Note that the JS220 does not have enough internal bandwidth to turn on current_range along with all of the other inputs.
The StreamBuffer.data_get and StreamBuffer.statistics_get were not designed to be flexible.
We hard-coded it to the length 6 array of current, voltage, power, current_range, current_lsb, and voltage_lsb. We would need to add a way to opt-in to a more flexible API that supports the JS220’s signals. Does your code use these methods?
The existing code configures the stream_topics with a hard-coded list. We would need to add a way to change these before calling Device.start. It would also need to change the StreamBuffer and the SampleBuffer instances that it holds.
So, I think we could make the opt-in mechanism a single method DeviceJs220.signals_set that would have to be called before Device.start. Calling this method would also make StreamBuffer.data_get and StreamBuffer.statistics_get return a map similar to StreamBuffer.samples_get. What do you think?
I see, that makes sense.
For the current_range field specifically we could even opt out as we know which currents to expect and we set the range up front to something else than auto.
Yes, that feature would work for me. We know the required fields to stream up front, so this would work perfectly for my case.
That would be awesome if you can add this to the library!
Thank you very much for the help 
Peter
1 Like