sigrok - User contributions [en]

Protocol decoder HOWTO

2020-11-19T17:49:39Z

Buttim:

This page serves as a quick-start guide for people who want to write their own [[libsigrokdecode]] protocol decoders ([[Protocol decoders|PDs]]).

It is '''not''' intended to replace the [[Protocol decoder API]] page, but rather to give a short overview/tutorial and some tips.

== Introduction ==

Protocol decoders are written entirely in Python (>= 3.0).

== Files ==

Every protocol decoder is a Python module and has its own subdirectory in libsigrokdecode's '''[http://sigrok.org/gitweb/?p=libsigrokdecode.git;a=tree;f=decoders decoders]''' directory.

This is a minimalistic example of how a protocol decoder looks like, in this case the '''[[Protocol_decoder:I2c|i2c]]''' decoder (license header, comments, and some other parts omitted).

'''Note''': Do not start new protocol decoders by copying code from here. Instead, it's recommended to select an already existing decoder in the source code which is similar to the one you plan to write, and copy that as a starting point.

=== __init__.py ===


<source lang="python">
'''
I²C (Inter-Integrated Circuit) is a bidirectional, multi-master
bus using two signals (SCL = serial clock line, SDA = serial data line).

<Insert notes and hints for the user here>
'''

from .pd import Decoder
</source>


This is a standard Python file, required in every Python module. It contains a module-level docstring, which is accessible by frontends via the [http://sigrok.org/api/libsigrokdecode/unstable/index.html libsigrokdecode API]. It should contain a (very) short description of what the protocol (in this case [[Protocol_decoder:I2c|I²C]]) is about, and some notes and hints for the user of this protocol decoder (which can be shown in GUIs when the user selects/browses different PDs).

This docstring should '''not''' contain the full, extensive protocol description. Instead, the per-PD wiki page should be used for protocol description, photos of devices or photos of example acquisition setups, and so on. Each decoder has one unique wiki page at the URL '''<nowiki>http://sigrok.org/wiki/Protocol_decoder:<pd></nowiki>''', where '''<pd>''' is the Python module name of the decoder ('''i2c''' in this case). Some examples for such per-PD wiki pages: [[Protocol_decoder:Uart|UART]], [[Protocol_decoder:Pan1321|PAN1321]], [[Protocol_decoder:Mx25lxx05d|MX25Lxx05D]], [[Protocol_decoder:Dcf77|DCF77]].

The "'''from .pd import Decoder'''" line will make sure the code from '''pd.py''' gets properly imported when this module is used.

=== pd.py ===


<source lang="python">
import sigrokdecode as srd

class Decoder(srd.Decoder):
api_version = 2
id = 'i2c'
name = 'I²C'
longname = 'Inter-Integrated Circuit'
desc = 'Two-wire, multi-master, serial bus.'
license = 'gplv2+'
inputs = ['logic']
outputs = ['i2c']
channels = (
{'id': 'scl', 'name': 'SCL', 'desc': 'Serial clock line'},
{'id': 'sda', 'name': 'SDA', 'desc': 'Serial data line'},
)
optional_channels = ()
options = (
{'id': 'address_format', 'desc': 'Displayed slave address format',
'default': 'shifted', 'values': ('shifted', 'unshifted')},
)
annotations = (
('start', 'Start condition'),
('repeat-start', 'Repeat start condition'),
('stop', 'Stop condition'),
('ack', 'ACK'),
('nack', 'NACK'),
('bit', 'Data/address bit'),
('address-read', 'Address read'),
('address-write', 'Address write'),
('data-read', 'Data read'),
('data-write', 'Data write'),
('warnings', 'Human-readable warnings'),
)
annotation_rows = (
('bits', 'Bits', (5,)),
('addr-data', 'Address/Data', (0, 1, 2, 3, 4, 6, 7, 8, 9)),
('warnings', 'Warnings', (10,)),
)

def __init__(self, **kwargs):
self.state = 'FIND START'
# And various other variable initializations...

def metadata(self, key, value):
if key == srd.SRD_CONF_SAMPLERATE:
self.samplerate = value

def start(self):
self.out_ann = self.register(srd.OUTPUT_ANN)

def decode(self, ss, es, data):
for self.samplenum, (scl, sda) in data:
# Decode the samples.
</source>


The recommended name for the actual decoder file is '''pd.py'''. This file contains some meta information about the decoder, and the actual code itself, mostly in the '''decode()''' method.

If needed, large unwieldy lists or similar things can also be factored out into another *.py file (examples: [http://sigrok.org/gitweb/?p=libsigrokdecode.git;a=tree;f=decoders/midi midi], [http://sigrok.org/gitweb/?p=libsigrokdecode.git;a=tree;f=decoders/z80 z80]).

== Copyright and license ==

Every protocol decoder '''must''' come with source code in the form of '''*.py''' files. No pre-compiled code should be present, Python or otherwise. The PD must not use any helpers that are not provided as source code under the same license as the PD itself.

The '''<tt>Decoder</tt>''' class must have a license declaration (see above), stating the license under which all the contents in the decoder's directory are provided. This is usually <tt>'gplv2+'</tt> or <tt>'gplv3+'</tt>, whichever you prefer. In either case, the decoder license must be compatible with the [[libsigrokdecode]] license (which is "GPL, version 3 or later").

== <tt>channels</tt> & <tt>optional_channels</tt> ==

The following excerpt from the [[Protocol_decoder:spi|SPI]] PD shows how to use '''<tt>channels</tt>''' and '''<tt>optional_channels</tt>'''. To decode SPI, the clock signal is always needed, the chip-select signal is optional and only used when provided. To give the user the flexibility to provide only one of the MOSI/MISO signals, they are both also defined as optional:


<source lang="python">
class Decoder(srd.Decoder):
...
id = 'spi'
...
channels = (
{'id': 'clk', 'name': 'CLK', 'desc': 'Clock'},
)
optional_channels = (
{'id': 'miso', 'name': 'MISO', 'desc': 'Master in, slave out'},
{'id': 'mosi', 'name': 'MOSI', 'desc': 'Master out, slave in'},
{'id': 'cs', 'name': 'CS#', 'desc': 'Chip-select'},
)
</source>


'''<tt>data</tt>''', the argument of the decoder's [[Protocol decoder API#decode-function|'''<tt>decode()</tt>''']] function that contains the data to decode, is a list of tuples. These tuples contain the (absolute) number of the sample and the data at that sample. To process all samples, the SPI decoder loops over '''<tt>data</tt>''' like this:


<source lang="python">
def decode(self, ss, es, data):
...
for (self.samplenum, pins) in data:
</source>


'''<tt>channels</tt>''' and '''<tt>optional_channels</tt>''' contain in total four channels, therefore the second member of the tuple is an object of Python's [https://docs.python.org/3/library/stdtypes.html#typebytes '''<tt>bytes</tt>'''] class containing 4 bytes, one for each channel. The decoder unpacks the bytes into the variables '''<tt>clk</tt>''', '''<tt>miso</tt>''', '''<tt>mosi</tt>''', and '''<tt>cs</tt>''' as shown below.

Then, it checks for the optional channels, if their value is either 0 or 1. If it is not, that optional channel is not provided to the decoder. In the case that neither of them is supplied, an exception is raised:


<source lang="python">
(clk, miso, mosi, cs) = pins
self.have_miso = (miso in (0, 1))
self.have_mosi = (mosi in (0, 1))
self.have_cs = (cs in (0, 1))

# Either MISO or MOSI (but not both) can be omitted.
if not (self.have_miso or self.have_mosi):
raise ChannelError('Either MISO or MOSI (or both) pins required.')
</source>


== <tt>annotations</tt> & <tt>annotation_rows</tt> ==

To make the relation between the '''<tt>annotations</tt>''' and the '''<tt>annotation_rows</tt>''' members of a decoder object more clear, take a look at how the [[Protocol_decoder:Ir_nec|ir_nec]] PD uses them:


<source lang="python">
class Decoder(srd.Decoder):
...
id = 'ir_nec'
...
annotations = ( # Implicitly assigned annotation type ID
('bit', 'Bit'), # 0
('agc-pulse', 'AGC pulse'), # 1
('longpause', 'Long pause'), # 2
('shortpause', 'Short pause'), # 3
('stop-bit', 'Stop bit'), # 4
('leader-code', 'Leader code'), # 5
('addr', 'Address'), # 6
('addr-inv', 'Address#'), # 7
('cmd', 'Command'), # 8
('cmd-inv', 'Command#'), # 9
('repeat-code', 'Repeat code'), # 10
('remote', 'Remote'), # 11
('warnings', 'Warnings'), # 12
)
annotation_rows = (
('bits', 'Bits', (0, 1, 2, 3, 4)),
('fields', 'Fields', (5, 6, 7, 8, 9, 10)),
('remote', 'Remote', (11,)),
('warnings', 'Warnings', (12,)),
)
</source>


It groups the first five annotation types together into the '''<tt>bits</tt>''' row and the next six into the '''<tt>fields</tt>''' row. The rows '''<tt>remote</tt>''' and '''<tt>warnings</tt>''' both only contain one annotation type.

Without '''<tt>annotation_rows</tt>''', [[PulseView]] would have to put each annotation type in its own row (which is unhandy if the decoder has many annotations) or it would have to put them all on the same row (which would result in unreadable output due to overlaps). But because of the '''<tt>annotation_rows</tt>''', the output of the [[Protocol_decoder:Ir_nec|ir_nec]] decoder is grouped together as shown in the following picture (note how different annotation types, distinguishable by their different colors, share the same row):

[[File:Pv example ir nec cropped.png]]

However, as you can imagine, handling numeric IDs is quite bothersome - especially if they change and all affected IDs have to be changed throughout the PD. To avoid this, you can use a pseudo-enum:


<source lang="python">
ann_bit, ann_agc_pulse, ann_long_pause, ann_short_pause, ann_stop_bit, ann_leader_code, ann_addr, ann_addr_inv, ann_cmd, ann_cmd_inv, ann_repeat_code, ann_remote, ann_warning = range(13)

class Decoder(srd.Decoder):
...
id = 'ir_nec'
...
annotations = ( # Implicitly assigned annotation type ID
('bit', 'Bit'), # 0 = ann_bit
('agc-pulse', 'AGC pulse'), # 1 = ann_agc_pulse
('longpause', 'Long pause'), # 2 = ann_long_pause
('shortpause', 'Short pause'), # 3 = ann_short_pause
('stop-bit', 'Stop bit'), # 4 = ann_stop_bit
('leader-code', 'Leader code'), # 5 = ann_leader_code
('addr', 'Address'), # 6 = ann_addr
('addr-inv', 'Address#'), # 7 = ann_addr_inv
('cmd', 'Command'), # 8 = ann_cmd
('cmd-inv', 'Command#'), # 9 = ann_cmd_inv
('repeat-code', 'Repeat code'), # 10 = ann_repeat_code
('remote', 'Remote'), # 11 = ann_remote
('warnings', 'Warnings'), # 12 = ann_warning
)
annotation_rows = (
('bits', 'Bits', (ann_bit, ann_agc_pulse, ann_long_pause, ann_short_pause, ann_stop_bit)),
('fields', 'Fields', (ann_leader_code, ann_addr, ann_addr_inv, ann_cmd, ann_cmd_inv, ann_repeat_code)),
('remote', 'Remote', (ann_remote,)),
('warnings', 'Warnings', (ann_warning,)),
)
</source>


This way, all you need to ensure is that the order of the enum entries is the same as in the annotations array and you're set. There is one downside, though, as always: pseudo-enums are pitifully slow in python, so if you use them and you use them in a lot of places, your protocol decoder may be significantly slower (up to 4x has been observed), so choose wisely. You can use the PD test facility to compare, using e.g. 'time ./pdtest -r $YOUR_PD'

== Random notes, tips and tricks ==

* You should usually only use '''raise''' in a protocol decoder to raise exceptions in cases which are a clear bug in how the protocol decoder is invoked (e.g. if no samplerate was provided for a PD which needs the samplerate, or if some of the required channels were not provided by the user, and so on).
* Use the has_channel() method to check whether an optional channel has been provided or not.
* A simple and fast way to calculate a parity (i.e., count the number of 1 bits) over a number (0x55 in this example) is:<source lang="python">
ones = bin(0x55).count('1')
</source>
* A simple function to convert a BCD number (max. 8 bits) to an integer is:<source lang="python">
def bcd2int(b):
return (b & 0x0f) + ((b >> 4) * 10)
</source>
* An elegant way to convert a sequence of bus pins to a numeric value:<source lang="python">
from functools import reduce

def reduce_bus(bus):
if 0xFF in bus:
return None # unassigned bus channels
else:
return reduce(lambda a, b: (a << 1) | b, reversed(bus))
</source>
* A nice way to construct method names according to e.g. protocol commands is (assuming '''cmd''' is 8, this would call the function '''self.handle_cmd_0x08'''):<source lang="python">
fn = getattr(self, 'handle_cmd_0x%02x' % cmd);
fn(arg1, arg2, ...)
</source>
* A cheap way to deal with Python's lack of enumerations (useful for states, pin indices, annotation indices, etc.):<source lang="python">
class Cycle:
NONE, MEMRD, MEMWR, IORD, IOWR, FETCH, INTACK = range(7)
</source>Please be aware, though, that using this mechanism may slow down your decoder significantly. It may make sense to perform some basic profiling to see if this affects you, e.g. using "time ./pdtest -r $YOUR_PD".
* <div id="SIGROKDECODE_DIR"></div>You don't need to reinstall the whole [[libsigrokdecode]] project every time you make a change on your decoder. Instead, you can use the environment variable '''<tt>SIGROKDECODE_DIR</tt>''' to point the software to your development directory: <source lang="bash">$ SIGROKDECODE_DIR=/path/to/libsigrokdecode/decoders/ sigrok-cli … -P <decodername></source>Because this environment variable is evaluated by the [[libsigrokdecode]] code itself, it can be used for any program that uses the library, for example when calling [[PulseView]] or the '''<tt>pdtest</tt>''' unit test utility from the [http://sigrok.org/gitweb/?p=sigrok-test.git;a=summary sigrok-test] repository. If you compiled a recent [[libsigrokdecode]] by yourself ([http://sigrok.org/gitweb/?p=libsigrokdecode.git;a=commit;h=40c6ac1d3fbded276dcbff23e8bc099896ab2fb5 newer than this commit]), you can also put decoders into your home directory, without the need for an additional environment variable. On Linux systems, this name follows the [http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html XDG base directory specification], which by default resolves to <tt>~/.local/share/libsigrokdecode/decoders</tt>. If that folder does not exist, you can simply create it and drop your decoders there, in their own subdirectory, like you would do in the libsigrokdecode source tree. On Windows systems additional decoders are read from <tt>%ProgramData%\libsigrokdecode\decoders</tt>.

* To debug the Python implementation of a decoder during development, maintenance or research either add print() statements at appropriate locations. Or get WinPDB and use the remote debugging feature as outlined below (add this hook somewhere in pd.py, then "File -> Attach" to the running process). Decoders cannot be used in "regular" debuggers since they expect a rather specific environment to execute in, for all of receiving their input as well as having their output saved or presented as well as processing samples (data types, runtime routines). Remote debugging works in both the sigrok-cli and pulseview context. Adding another print() statement before starting the embedded debugger can help identify the moment in time when to attach.<source lang="python">
def __init__():
import rpdb2
rpdb2.start_embedded_debugger("pd")
...
</source>

For Windows you might want to use the following code, adapting it to your Python and WinPDB-reborn version:<source lang="python">
def __init__():
import sys
sys.path.insert(0, 'c:/Program Files (x86)/Python38-32/Lib/site-packages/winpdb_reborn-2.0.0.1-py3.8.egg')
import rpdb2
rpdb2.start_embedded_debugger("pd", fAllowRemote=True)
...
</source>

== Unit tests ==

In order to keep protocol decoders in a running state even when we make changes to a decoder or libsigrokdecode itself, we use unit tests for as many decoders as we can. These are stored in the [http://sigrok.org/gitweb/?p=sigrok-test.git sigrok-test repository]. If you want to add, modify or run one of them, clone that repository and [https://sigrok.org/gitweb/?p=sigrok-test.git;a=blob;f=README check the README] for documentation.
We greatly appreciate it when you submit unit tests for your decoder so we can keep it in good health!

== Submitting your decoder ==

When you've finished your decoder and everything is working nicely, please contribute the decoder to the sigrok project so that other people can benefit from it (and test it, improve upon it, and so on).

* Check the decoder's operation in the most recent version of the software. You expect the decoder to get accepted in the project's mainline codebase. So it should work in that environment. Either build from up-to-date sources, or download nightly builds.
* Tell us about the location of your public git repo on the '''#sigrok''' IRC channel on FreeNode. As an alternative send the decoder to the [https://lists.sourceforge.net/lists/listinfo/sigrok-devel sigrok-devel] mailing list (preferrably against current master and as a full commit instead of a mere diff). Remember that pushing to a public git repo is preferred over email attachments.
* Please also make example data files (*.sr) including a small README available. Developers need these in order to properly review and test your decoder. Users need these to learn what the captures are about in the first place. Preferrably these files should also come as patches against the latest git master of the [http://sigrok.org/gitweb/?p=sigrok-dumps.git;a=tree sigrok-dumps] repository. See [[Example dumps]] for details. Submitting captures before any decoder materializes or work on a decoder even starts is very useful.
* Finally, please also consider adding a few "unit tests" for your decoder in the [http://sigrok.org/gitweb/?p=sigrok-test.git;a=tree sigrok-test] repository. These test will automatically run the decoder against various input files specified in '''test.conf''' and check whether the expected output is produced (examples: [http://sigrok.org/gitweb/?p=sigrok-test.git;a=blob;f=decoder/test/rfm12/test.conf rfm12], [http://sigrok.org/gitweb/?p=sigrok-test.git;a=blob;f=decoder/test/nrf24l01/test.conf nrf24l01]). This allows us to notice and fix any regressions in the decoder and/or the [[libsigrokdecode]] backend that may arise over time.

Thanks a lot!

[[Category:APIs]]

UNI-T UT61E

2020-11-01T21:48:03Z

Buttim: added special syntax for Windows COM ports

{{Infobox multimeter
| image = [[File:Old_ver_front.png|180px]]
| name = UNI-T UT61E
| status = supported
| source_code_dir =
| counts = 22,000
| categories = CAT II (600 V) / CAT III (300 V)
| connectivity = [[Device_cables#UNI-T_UT-D02|RS232]] / [[Device_cables#UNI-T_UT-D04|USB]]
| measurements = voltage, current, resistance, capacitance, frequency, duty cycle, diode, continuity
| features = autorange, true-rms, data hold, min/max, relative, bargraph, backlight
| website = [http://www.uni-trend.com/UT61e.html uni-trend.com]
}}

The '''UNI-T UT61E''' is a 22,000 counts, CAT II (600 V) / CAT III (300 V) handheld digital multimeter with RS-232 or USB connectivity.

See [[UNI-T UT61E/Info]] for more details (such as '''lsusb -vvv''' output) about the device.

== Hardware ==

* [[Multimeter_ICs#Cyrustek_ES51922|Cyrustek ES51922]] multimeter chip (ES51922A actually, as per various photos: [http://i492.photobucket.com/albums/rr283/DarkShadower/IMAG0005.jpg 1], [http://www.eevblog.com/forum/product-reviews-photos-and-discussion/uni-t-ut61e-multimeter-teardown-photos/?action=dlattach;attach=19985;image;PHPSESSID=14790b9893bed7edb7d8c0505b195ed8 2], [http://img848.imageshack.us/img848/3784/dscf0150w.jpg 3], [http://we.easyelectronics.ru/uploads/images/00/05/21/2011/11/18/553300.jpg 4])

== Photos ==

'''Older version:'''

<gallery>
File:Old ver.JPG
File:Old ver front.JPG
File:Old ver back.JPG
File:Old ver batt.JPG
File:Old ver lcd.JPG
File:Old ver cables.JPG
File:Old_ver_pcb.JPG
File:Old ver es51922a.JPG
</gallery>

'''Newer version:'''

<gallery>
File:New ver.JPG
File:New ver front.JPG
File:New ver back.JPG
File:New ver backb.JPG
File:New ver batt.JPG
File:New ver frontCover.JPG
File:New ver Knob.JPG
File:New ver lcd.JPG
File:New ver pcb front.JPG
File:New ver pcb back.JPG
File:New ver es51922a.JPG
File:New ver ad737.JPG
</gallery>

== Protocol ==

See [[Multimeter_ICs#Cyrustek ES51922|Cyrustek ES51922]] for the DMM IC protocol.

Depending on the cable, additional decoding is needed, though.

Different cables are available to communicate to the DMM: regular serial cables which provide a COM port, and USB HID based cables where applications are required to handle a proprietary protocol of running serial communication on top of HID requests. See the ''[[Device cables]]'' page for details; the same cables can be used with many different DMM models.

Depending on the specific cable in use, either a device driver ending in '''-ser''' or not ending in '''-ser''' must be used. See README.devices for details.

The message ''"HID feature report error: LIBUSB_ERROR_PIPE"'' results from using the USB HID driver with a USB-to-serial cable. In this case, try using --driver='''uni-t-ut61e-ser'''

The transmission of the measurement data cannot be disabled. The respective Cyrustek ES51922 pin (111, '''RS232''') is tied to GND (i.e. transmission is always enabled) on this multimeter.[http://www.steffenvogel.de/2011/01/25/inner-workings-of-uni-trend-ut61e-digital-multimeter/]

== Usage ==
The following [[sigrok-cli]] command can be used to receive five measured values from a device connected via USB (note that the USB VID/PID after the '''<tt>conn</tt>''' option needs to be changed depending on the exact USB adapter cable used):
<source lang="bash">
$ sigrok-cli --driver=uni-t-ut61e:conn=1a86.e008 -O analog --samples 5
</source>

If your meter has a serial (RS-232) cable connected to a USB-to-serial adapter, a different driver is used. Example for ttyUSB0:
<source lang="bash">
$ sigrok-cli --driver=uni-t-ut61e-ser:conn=/dev/ttyUSB0 -O analog --samples 5
</source>
Same example for COM1 (Windows), please note the special syntax for specifying the COM port:
<source lang="text">
C:\> sigrok-cli --driver=uni-t-ut61e-ser:conn=\\.\COM1 -O analog --samples 5
</source>

'''<tt>--samples <n></tt>''' stops acquisition after the specified number of measurements, while '''<tt>--continuous</tt>''' does not stop. Type just '''sigrok-cli''' by itself for a summary of options.
More information on drivers can be found in the [http://sigrok.org/gitweb/?p=libsigrok.git;a=blob;f=README.devices README.devices] file of the [[libsigrok]] source tree.

== Resources ==

* [http://www.uni-trend.com/manual2/UT61English.pdf Manual]
* [http://www.uni-trend.com/Web%20site/DMM%20Software/UT61E_setup%20v2.00.exe Vendor software]
* [http://www-user.tu-chemnitz.de/~heha/hs_freeware/UNI-T/ Henrik Haftmann: DMM.exe etc.] (Windows software for various UNI-T DMMs, and lots of device/protocol info)
* [http://www-user.tu-chemnitz.de/~heha/bastelecke/Rund%20um%20den%20PC/hid-ser.en.htm Henrik Haftmann: Hoitek HE2325U info]
* [http://www-user.tu-chemnitz.de/~heha/hs_freeware/UNI-T/UT61E.LOG Henrik Haftmann: UT61E log and protocol docs]
* [http://diyftw.de/wiki/doku.php?id=projekte:ut61e diyftw.de: Uni-Trend UT61E (UT-D04 linux treiber)] (device info, Linux software using HIDAPI: [http://diyftw.de/wiki/lib/exe/fetch.php?media=projekte:ut61e-linux-sw-0.02.tar.gz ut61e-linux-sw-0.02.tar.gz])
* [http://www.steffenvogel.de/2009/11/29/uni-trend-ut61e-digital-multimeter/ Steffen Vogel: UNI-TREND UT61E Digital Multimeter] (device info, Linux software for serial port: [http://static.steffenvogel.de/wp-content/uploads/2009/11/dmmut61e-0.01.tar.gz dmmut61e-0.01.tar.gz])
* [https://bitbucket.org/kuzavas/dmm_es51922 Multimeter data parsing utility] complete implementation written in Python
* [http://www.steffenvogel.de/2011/01/25/inner-workings-of-uni-trend-ut61e-digital-multimeter/ Steffen Vogel: Inner workings of UNI-TREND UT61E Digital Multimeter] (teardown)
* [http://erste.de/UT61/index.html erste.de: UT61 - USB Multimeter unter Linux auslesen] (info on the Hoitek HE2325U (clone?) and how suspend/resume fixes some issues with it)
* [http://translate.google.de/translate?sl=auto&tl=en&js=n&prev=_t&hl=de&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fwe.easyelectronics.ru%2FACE%2Fdorabotka-napilnikom-multimetra-ut61e.html&act=url easyelectronics.ru: Refinement of a file multimeter UT61E]
* [http://translate.google.de/translate?sl=pl&tl=en&u=http%3A%2F%2Fflodins.info%2Fmoim-zdaniem%2F81-multimetr-uni-t-ut61e flodins.info: Multimeter UNI-T UT61E]
* [http://www.eevblog.com/forum/product-reviews-photos-and-discussion/uni-t-ut61e-multimeter-teardown-photos/?action=dlattach;attach=20302;PHPSESSID=14790b9893bed7edb7d8c0505b195ed8 UNI-T UT61E schematics: ut61e sch.pdf]
* Teardowns: [http://www.eevblog.com/forum/product-reviews-photos-and-discussion/uni-t-ut61e-multimeter-teardown-photos/msg45069/#msg45069 1], [http://www.eevblog.com/forum/product-reviews-photos-and-discussion/uni-t-ut61e-multimeter-teardown-photos/msg113968/#msg113968 2], [http://www.eevblog.com/forum/product-reviews-photos-and-discussion/uni-t-ut61e-multimeter-teardown-photos/msg86347/#msg86347 3], [http://www.eevblog.com/forum/product-reviews-photos-and-discussion/uni-t-ut61e-multimeter-teardown-photos/msg86378/#msg86378 4], [http://www.eevblog.com/forum/product-reviews-photos-and-discussion/uni-t-ut61e-multimeter-teardown-photos/msg86802/#msg86802 5], [http://www.eevblog.com/forum/product-reviews-photos-and-discussion/uni-t-ut61e-multimeter-teardown-photos/msg82784/#msg82784 6]

[[Category:Device]]
[[Category:Multimeter]]
[[Category:Supported]]