Afonso Teles

Hi,<br> <br> I would strongly suggest staying away from raw sockets as much as possible.<br> <br> Some people do seem to have been able to get pyvisa working on apple silicon: <a href="https://github.com/pyusb/pyusb/issues/355">https://github.com/pyusb/pyusb/issues/355</a><br> You will probably need to use PyVISA-py as the backend: <a href="https://pypi.org/project/PyVISA-py/">https://pypi.org/project/PyVISA-py/</a>

Transition bits are those which go from one digital state to the other and then back in the least amount of clock cycles possible (2 clock cycles).<br> <br> As an example, for rise time, the transition bits would be those that meet a 1 0 1 pattern.<br> A 1 0 0 1 pattern would not meet this definition and so would be excluded from the measurements. 1 0 1 1 would as that meets the 1 0 1 pattern (what comes after does not matter).<br> <br> These transition bits are often the most testing (aka worst case) of a system and so there's particular interest in measuring them.

<p>I wouldn't say it works fine on the MSO5. Yes, I can get it to decode somewhat closer to what you expected but it still throws a sync error at the end.</p> <p>This leads me to believe the waveform itself is somehow misshapen (I don't know enough about 1553 to say how exactly) and the MSO5 simply has a slightly different decoding procedure which I have abused to force it to decode something else. I have attached screenshots with the bus decode table to show that.</p> <p></p> <p>It would be useful to know the minimum and maximum RT of the measured system.</p>

Hi Michael,<br> <br> This is becoming a rather complex question, it would be best to have your field applications engineer help you directly.<br> You should have gotten an email from him on this matter.

Hi Matthew,<br> I apologize for the delay.<br> <br> I tried the waveform on one of our MSO4000B's and got the same decoding. Next I tried it on an MSO5 and I got it to decode properly, but only with maximum response time (RT) set to 4.1 us or lower (screenshot attached).<br> I tried setting the maximum RT to below 4.1 us on the MSO4000B but was not able to successfully decode the bus. Further work is needed to understand this issue.<br> <br> I would suggest changing changing the time/div and RT maximum and minimum and seeing how that affects the decoding, it might be possible to make progress that way.

Hi Penny,<br> <br> Yes, the USB device port on the back of the instrument can be used for remote control.<br> <br> That example you posted uses NI-VISA libraries, which I do not use or support.<br> <br> And yes, you have to use two commands to transfers an image to your PC.<br> <br> I have written an example Python3 program to transfer images from MSO2/4/5/6, please find it attached with this post.

Hi Herman,<br> <br> The DC differential impedance is 100 kOhm. The AC differential impedance is frequency dependent and given on page 28 of the <a href="https://www.tek.com/en/p7513-manual/p7500-series-rev">technical reference</a>.<br> <br> As you can see, the AC impedance is more than 50 Ohms (in the rated bandwidth) but not as high as the DC impedance, but it is high enough that the tip can be used mid-bus and is, therefore, a &quot;high impedance&quot; probe tip in a relative term.

Hi Sachin,<br> <br> No, the programming interfaces for those machines are not completely identical, some commands will differ.

Hi Penny,<br> &#160; <div class="linenums prettyprint">First of all, if all you wish to do is get a screen capture, I would suggest the free community-made <a href="https://forum.tek.com/viewtopic.php?t=140451">TekScope Utility.</a><br> <br> If you wish to write your own program, then you can start with the following examples: <a href="https://forum.tek.com/viewtopic.php?f=580&amp;t=133570">https://forum.tek.com/viewtopic.php?f=580&amp;t=133570</a><br> For the MSO6, the <code>hardcopy</code> command has indeed been deprecated, the new way to do it is to use&#160; <code>save:image</code> followed by <code>filesystem:readfile </code>to transfer that file.</div>

<p>Hi Howard,</p> <p>Thank you for following up and posting your conclusions in the thread for others to enjoy.</p> <p></p> <p>To summarize what I see as the root cause of the issue:</p> <p>The AFG31k does not have a strict restriction between basic/AFG mode and advanced/sequence mode. This means sequence commands can be used even when the instrument is in basic mode and vice-versa. And these commands can have unforeseen consequences, in this case <code>SEQC:RUN:IMM</code>, which would be used to start outputting in sequence mode, actually leads to stopping the output in basic mode while keeping the output lights on.</p> <p></p> <p>Since the AFG31k doesn't separate strictly between basic and advanced mode, it is up to the remote control program to keep track of that state and to avoid using commands from the wrong mode, or else confusing behavior like this can arise.</p>