Aim TTi 1908 and Linux - Page 1
Forum section: electronics / testgear

author: hirada
author_rank: Regular Contributor
timestamp: February 22, 2021, 08:51:48 am
content: Has anyone, who does owns such a DMM, ever successfully connected it to a linux box? I am wondering, wether the 1908 (not 1908P) could be read out or configured out from a standard terminal client, using its USB interface?

author: bd139
author_rank: Super Contributor
timestamp: February 22, 2021, 08:59:51 am
content: Most TTi stuff uses a standard USB serial adapter with a custom product ID from experience. Check the vendor ID and product ID when you plug it in. You’ll have to persuade it to use the right driver which can likely be hinted at by the vendor ID. If you can crack it open and look for the USB chip it’ll give you a clue as well.Can’t remember how you tel Linux to do that off the top of my head. It’s easier than on Mac and Windows though!!

author: hirada
author_rank: Regular Contributor
timestamp: February 22, 2021, 09:30:03 am
content: Thanks very much. However, I cannot test, as I would not buy it if it does not work. In addition it is not clear, wether the USB Port on the non P model is as fully featured as on the P model. In the manual there may be a hint that all the remote commands only work on the P models anyway. Does this include USB?As in other places again they do suggest, the P model only adds the physical interfaces like LXI an RS232 (and GPIB). But that one is simply a tad to expensive for me.

author: Kean
author_rank: Unknown
timestamp: February 22, 2021, 10:17:56 am
content: I don't have one, but this seems pretty clear in the datasheet.Quote

author: hirada
author_rank: Regular Contributor
timestamp: February 22, 2021, 11:06:20 am
content: Thanks, that is exactly what I was referring to. As the manual states:Code:Full digital remote control facilities are available through the RS232, LAN, USB and GPIB interfaceson programmable models. Host powered USB on non-programmable models....Does this imply the non-programmable models (the non P) do not offerfullremote control facilities despite being equipped with an USB port? Maybe I am lacking some english here, but this reads as a trap, as the first sentence is about features, the second about hardware. That again only may be existent for firmware updates or their own propietary software and being crippled otherwise. Or not.Not clear to me. Hence my question for experience. And if it is, what I am hoping, does the standard (non P) USB play well with linux?According to the manual, it is a standard virtual com port, so USB communication class, and they claim to use the standard windows driver, therefore I am positive, but would not mind if someone could confirm. Sometimes the devil hides in the details.

author: Kean
author_rank: Unknown
timestamp: February 22, 2021, 11:49:57 am
content: That is an awkward quote from the manual, but the way I read that is "Host powered USB" provides "full digital remote control facilities" on "non-progtammable models".From what I recall of looking at their prducts in the past, the non-P models were not programmable at all - i.e. no communication interfaces. It would appear that the cost of adding USB interface is now low enough that they can include it in the base model and stay competetive. And very useful to be able to ship firmware updates. The cost of LAN hardware has also dropped sufficiently for LAN to be standard on many devices now.Looking athttps://www.aimtti.com/resources/usb-driver-v211it would appear that the 1908 (and many other models) just implement a CDC virtual com port. I see that is also mentioned in the manual Apparently it isn't using an FTDI interface as they also have an FTDI driver for some other models.I couldn't find any protocol info, but presumably the USB virtual com port will use the same command protocol as the RS232 on the P model. Most likely SCPI based, so should be fine on Linux as long as you aren't scared to write some code.This forum topic seems to imply TTi use the same command set on the various interfaces, at least on some other models. You'd expect them to carry this across their product range.https://www.eevblog.com/forum/testgear/bench-psu-remote-control-application-for-tti-pl-p-series-(winlinuxmac)/Your best bet is of course to ask the sales rep and confirm suitability before purchase so you have the option for return if it doesn't do what you need.

author: Kean
author_rank: Unknown
timestamp: February 22, 2021, 11:54:47 am
content: You could ask in this topic - maybe the OP could check if they don't knowhttps://www.eevblog.com/forum/testgear/aim-tti-1908-5-12-digit-benchtop-multimeter-(preview)/Also this topic is for software that supports some Aim TTi products, so would possibly be worth taking a lookhttps://www.eevblog.com/forum/testgear/program-that-can-log-from-many-multimeters/

author: hirada
author_rank: Regular Contributor
timestamp: February 22, 2021, 12:21:47 pm
content: Hello Kean,thanks again for your help and effort. Originally I've intended to reply to the first thread you've linked to, but I've been told by the forum software, since the last reply was 120days old, to rather open a new one. But sure I am hoping someone will be looking at this as well.QuoteI have contacted AIM Tti way before this thread, but have not gotten any response. So far at least.QuoteIf simplest of shell batches count as code, that is exactly what I want this DMM for. The commands and com ports settings themselves are thankfully clearly documented in the manual, so as long as I am able to properly talk to a /dev/ttyUSBndevice, I would be perfectly fine.That would also imply usability with an ordinary terminal program. That is all I am asking for, I am already doing this with other gear. I do not want to use any special software.Code:but presumably the USB virtual com port will use the same command protocol as the RS232 on the P modelThat is my assumption as well and that confirmation by an owner was is hope for this thread. I could any maybe will contact the seller beforehand, as returns are of course legal, but always unpleasant, but maybe someone pops up who has done, or tried, this already.

author: HKJ
author_rank: Super Contributor
timestamp: February 22, 2021, 03:14:29 pm
content: Quote from: hirada on February 22, 2021, 12:21:47 pmUsing special software gives many extra possibilities, that can be remote controlling the meter, making charts, automate test with other equipment, etc.

author: hirada
author_rank: Regular Contributor
timestamp: February 22, 2021, 04:28:46 pm
content: Quote from: HKJ on February 22, 2021, 03:14:29 pmYes, if the software does support all of ones test equipment and can handle it (more or less) simultaneously, then that is certainly true. But I suspect, even this software requires that the OS is able to talk to the respective devices. So the manufacurer needs to stick to some common standard, like USB Communication Class AND implement it somewhat cleanly. Well, and document the commands.Gossen f.e., as far as I know, does not stick to any standards and uses a propietary, undocumented protocol. Not sure about the U1272A I've asked asked in your test connection thread.Therefore my assumption: If a simple shell batch can handle a device, so then could test connection. Which looks really, really promising, I just have had a first look at your page today thanks to Kean and will certainly give it a try.But for now my primary focus and buying relevance is, can it be queried and operated from the linux command line? Either using LXI tools or simply reading and writing to a serial device. Be it real or USB. Then we may upgrade to more sophisticated software.

author: HKJ
author_rank: Super Contributor
timestamp: February 22, 2021, 04:44:38 pm
content: Quote from: hirada on February 22, 2021, 04:28:46 pmTestController can handle (virtual) serial and network devices without any device drivers (except the virtual serial driver) and can basically handle all devices it knows simultaneous. I prefer documented protocols (From manufacturer or internet) before I implement them, but I have in a few cases reverse engineered protocols.The above is supposed to work on Windows, Linux & Mac, on Windows I also support Brymen USB meters.It is possible for users to implement support for other devices and share them. This do not require programming, but that the protocol is in some supported standard format (SCPI & MODBUS are), but I have also in a few cases implemented a binary protocol from a hex dump, last one was ATorch energy meter.Quote from: hirada on February 22, 2021, 04:28:46 pmI have documentation (From Gossen) for the Gossen Energy meter, but have not implemented it in TC yet.

author: hirada
author_rank: Regular Contributor
timestamp: February 22, 2021, 05:21:18 pm
content: Quote from: HKJ on February 22, 2021, 04:44:38 pmNow THAT would be a complete game changer for my choice of multimeter. I guess, I suspend the AIM a little. Just in time, this information, I guess. Even, if it takes some more time. Summer is coming anyway. And I would need to seriously save some more money.Quote from: HKJ on February 22, 2021, 04:44:38 pmYes, I've had a first look at your homepage. Without having ever seen the software, I've been just lurking about how to possibly implement my prema 6040. Which is non standard, but super simple with a fixed outputformat. Like 5 commands or so. As far as I can tell, that would be that binary DMM2 driver, as the output format is fixed. However, it constantly outputs data, no need to query. But I am about to hijack my own thread.Quote from: HKJ on February 22, 2021, 04:44:38 pmThe probably good news here, this implies, is that most manufacturers really stick to that standard serial driver interface, instead of requiring propietary ones. For me, all those IR-USB adapters gave the impression of being manufacturer specific implementations. Also, since most only point to their own software, stating, it is required. Really documenting the command set only seems to start with benchtop DMM. Except the Hioki.Especially as I have found discussions about perl scripts for Keysight or discussing to decode th Gossen BD232 or IR adapters, I've had the impression of manufacturers deliberately are locking in.Or use a standard protocol, but modify it ever so slightly, so that it only works with their specific stuff. All to common these days, hence my questions.Seems to be more relaxed than I was afraid of. If that holds true, these are good news. Really, really good.

author: hirada
author_rank: Regular Contributor
timestamp: February 27, 2021, 08:46:02 pm
content: Ok, first an excuse. In the overview, right on page 4 the manual states:QuoteI should have read the overview more carefully.Therefore, after some consideration, I finally did pull the trigger and got one, as realistically I won't have the money for an Energy before end of the year and the price was a steal. And we need to see wether the Energy really will run with Linux, though I do have confidence in HKJ.So, in case anyboby else besides me should ever be interested in this:It works!Thanks all again.Code:Feb 27 20:42:12 messstation kernel: usb 2-1.4: new full-speed USB device number 5 using ehci-pciFeb 27 20:42:13 messstation kernel: usb 2-1.4: New USB device found, idVendor=103e, idProduct=04c4, bcdDevice= 2.00Feb 27 20:42:13 messstation kernel: usb 2-1.4: New USB device strings: Mfr=4, Product=12, SerialNumber=30Feb 27 20:42:13 messstation kernel: usb 2-1.4: Product: 1908 DMMFeb 27 20:42:13 messstation kernel: usb 2-1.4: Manufacturer: TTIFeb 27 20:42:13 messstation kernel: usb 2-1.4: SerialNumber: xxxxxxxxFeb 27 20:42:13 messstation kernel: cdc_acm 2-1.4:1.0: ttyACM0: USB ACM deviceFeb 27 20:42:13 messstation kernel: usbcore: registered new interface driver cdc_acmFeb 27 20:42:13 messstation kernel: cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adaptersJust a short play from the command line:

author: bd139
author_rank: Super Contributor
timestamp: February 27, 2021, 08:58:53 pm
content: Very nice. Thanks for posting back. Let us know how the meter is as well

author: HKJ
author_rank: Super Contributor
timestamp: February 27, 2021, 09:29:25 pm
content: Quote from: hirada on February 27, 2021, 08:46:02 pmIt is not very much about confidence in me, it is more about somebody doing the definition. With the dump you have posted it is possible to make a definition to show VDC and ADC, but without a meter it is not possible to test it.To get started go to the "Load devices" page and right click on the combobox ("Search socket") and select "Create new SCPI definition", select serial port and specify the port name. It will create a skeleton for the meter.

author: hirada
author_rank: Regular Contributor
timestamp: February 28, 2021, 11:35:23 am
content: Later in this post I am lamenting about the output format not being fixed. That of course is not true, I just cannot count, that's all. See a later post.I also have been mentioning, that the VA mode does not work with the 10A range. This seems to have been fixed as well. Also more in a later post@HJK:There was a slight misunderstanding. I have not been primarily referring to you doing this implementation, but more to your statement that the Energy would play with linux. At least with with testcontroller.But on the other hand, if someone else is supposed to implement it, it would mean that you pass on the documentation. If that does not violate any terms of agreement with Gossen, that's perfectly fine.I still have a Metrahit Extra, but without that IR adapter, and now that I own the 1908, it eventually will have to go. But if against all odds there is still something I could help out with, just let me know.I already have a template for my power supply, however, it took me some time to find the part where you can specify more serial parameters. Still lots to learn, but we'll get there.But thanks for guidance!@bd139:In fact it is actually a great little meter. In short, it is the successor to the venerable Fluke 45. The similarities are striking. On paper it may not have the most flashy specs, but to me it excells in usability. YMMV, of course.The display is top notch. A real gem. And so is the continuity test. Usability is straight forward and the possibility to run of battery is a welcome addition as well. And it is made in UK. Not, that chips with vinegar really go well along with human rights either, but...In addition I very much like the fact, that it can measure and display volts and amps in one go (limits apply) or alternatively can read AC+DC values and have the pure AC or DC values displayed in the 2nd display. Latter is something some handheld multimeters can do as well, first however is not so common any more and probably has been one of the main selling points for me. With the lack of AC peak measurements being the main point of hesitation.It does have however have it's fair share of limitations and I can see, why, for it's retail price vs. its features, it does not get any more love. All of those are however very clearly stated in the manual, so you know beforehand.Accuracy wise it is actually not that bad. For small values it beats the HMC8012 (on paper at least), but it also does lacks a uA or 10mV range. Generally, for sub mA or sub 10mV AC measurements this is not your device - it does not feature a jack for shielding either. Further, it is only specified up to a crest factor of 3. That is rather on the low side.The 10A range can only be selected manually, which in turn limits the VA function up to 1.2 Amps. This is really an unnecessary annoyance and probably could easily be fixed in software, but I would not hold my breath for this ever to happen. Not an issue with PC reading, you do the calculation there.As VA is just calculated, no real power measurement. But, contrary to the HMC8012, also works for AC. Since those measurements are done alternatingly, it does not take phase into consideration. Probably the reason Hameg did not implement this at all.Again, that those measurements are not two independend, parallel measurements, but alternating ones, is clearly stated in the manual. For AC volts and -current in normal/slow mode that comes down to a 12sec coffee break before a reliable/stable reading. All other combinations are fine.Half the time in fast mode with losing one digit.It is still faster than my prema with up to 20sec and I am an old bloke, I have time. Given, that this an bonus feature anyway, I have no problems with this at all. You can always measure both units independendly as with all other meters, if you are in a hurry.Thank to the directly accessible buttons that is way faster and more convenient than having to turn a dial. And having to make sure, the meter does not tip over while doing so. Also, you can leave both cables (current and voltage) connected even while measuring only one unit exklusively and then switch. No warning beeps or shut jacks blocking you. Excellent.The stats/math functions are implemeted somewhat half heartedly. They only operate against preset values in the menu, not against a set Null value. This does hurt especially for the otherwise rather usefull Delta% function.Also, you cannot calculate the more practical dBV, just dBm.As you can tell from the screenshot, the output format is a little awkward as well, as you have to parse the string to figure out, wether the exponent is negative or not present at all. At least they've could have made the output a fixed length sting by adding a "+" for positive exponents.Finally, you cannot turn it off completely on the front. According to another post it still draws around 2 Watts when Idle. Maybe depending on the state of the battery. To turning it off completely, you need to access the back side. Or switch the power outlet.The 10 Megohm range is also rather slow. Measuring the impedance of another multimeter (10 Meg) took a couple of seconds, before settling. 4-Wire Measuring a 100 mOhm 5% resistor compared to a milliohmmeter gave ~3mOhm difference (97 vs. 93 on the 1908). The milliohmmeter itself displayed a difference of 1 mOhm, dependending on wether the testcurrent used was 200mA or 1 A. So to me that is not groundshaking, but not shabby either.Generally, when measuring resistance (auto), also 4-wire, you need to take ~5 sek into account for it to settle. I do remeber discussions about the ohms speed on the 121gw, so that may be an issue for some. It generally does not do the Kessel Run in less than 12 parsec(tm).So asides the insulting low max. 1V diode test voltage, that all is nothing, that cannot be dealt with. But again, at least in parts shows unnessecary sloppiness.I cannot talk about temperature, when I am cold, I get a thicker sweater. That is to say, I do not have any probes. Can utilize PT100 or PT1000. Both 2 and 4 wire.Capacitance: The only comparisson I have, is my Der EE-5000, itself not a real precicion instrument either. The 1908 has around 50pF fixed uncertainty according to it's manual, but after Null, a capacitor, that is being displayed with 48pF on the EE, with a little variation dependending on the frequency used, is being displayed as 0.04nF on the 1908. That really exceeds my expectations.A 100nF foil cap is displayed as 92.5nF on both meters, with one digit more on the EE. A 100uF elko is being measured 98.02@100Hz on the EE, the 1908 shows 102uF. That all is AC vs. DC measurement. So I am rather pleased with these results. Again, not groundshaking, but makes for a reliable or rather trustworthy impression.Now I have never seen one in real life, so just judging by paper, but most of the more esoteric functions are also being delivered by the 121GW for less than half the price.Shure, you do lose a digit (well, only a little more than half, 50000 vs. 120000), some math functions, external triggering, 4 wire ohms measurement, and probably step down a little on the display, although I am sure it is fine as well, but may gain speed and portability. And gain a proper Diode measurement as well as low current and volt ranges. And at least some form of peak measurement.Well, and you do lose linux compatibility, but as far as I get it, the interest in this is rather little anyway. To be polite. So, if it was not for this reason, initially I'd probably went for the 121GW. Now however I do enjoy the better usability compared to any handheld meter.Mine happens to be returned unit, that I got in de facto new condition, but obscenely cheap. Still more than a 121gw, of course.With its comparably small size, light weight, direct and immediate operation, this outstanding display, with that added flexibility of dual measurements, that seemless and hasslefree PC connectivity it will surely become my goto first device. It just a pleasure to use. Sometimes reality is more than just specs on paper. YMMV, again.And while I contacted the seller beforehand, this is a definite keeper for me. I am however not sure, wether I would spend the full retail price for it. But know that I actually have used it a little, I am also not sure, if I so did (buying at retail price), wether I still would not want to keep it.This may hint the dilemma vendors face that still produce in europe, as Hameg devices generally have only mediocre specs as well at an even more premium price. However Hameg seems to somewhat implement its features way more thoughfully and consequently than it has been done here. But it may show, there is a limit to maintain at least a somewhat competitive pricing for europe made hardware. The developement of the software may be a contributing factor.Long story short: To me the 1908 seems more an everyday kiss style workhorse meter than something fancy or special you'd have to bow before to get your 24th digit and fortune telling. And what you usually associate with a benchtop meter.Not that I mind those at all! But those would usually not be the thing I'd grab first. That may just be me, and in addition from a purely hobbyist view. Pros will have completely different requirements, no doubt. It does sit somewhere in between a benchtop and a handheld MM and fills a niche.Oh, and it does feature a pretty comprehensive manual. So those that are scared away by now, it is worth a look.And again, I only have played with is for a short time, above may contain errors.And, a final and redundant word about PC connectivity. Since so far nobody really showed any interest in using this with linux, it will not be any different with FreeBSD, but for the history books, the 1908 does work here flawlessly as well:Code:ugen0.3: <TTI 1908 DMM> at usbus0umodem0 on uhub0umodem0: <TTI 1908 DMM, class 2/0, rev 2.00/2.00, addr 2> on usbus0umodem0: data interface 1, has no CM over data, has no break

author: HKJ
author_rank: Super Contributor
timestamp: February 28, 2021, 12:18:12 pm
content: Quote from: hirada on February 28, 2021, 11:35:23 amI do not have any agreement with Gossen about that document, but normal copyright applies, i.e. I will not post it in a public forum.The document is a pdf in German, but not very hard to figure out.Quote from: hirada on February 28, 2021, 11:35:23 amYou can always ask about TestController, either on email or in the TestController thread.

author: voltsandjolts
author_rank: Unknown
timestamp: February 28, 2021, 12:38:17 pm
content: Cross ref to another 1908 thread:https://www.eevblog.com/forum/testgear/aim-tti-1908-5-12-digit-benchtop-multimeter-(preview)/The internet seems to lack photos of the 1908 internals....can you help....you won't need the warranty anyway, so it'll be fine

author: bd139
author_rank: Super Contributor
timestamp: February 28, 2021, 12:56:12 pm
content: Thanks for the extensive review hirada. Much appreciated

author: PKTKS
author_rank: Super Contributor
timestamp: February 28, 2021, 01:37:36 pm
content: Quote from: bd139 on February 22, 2021, 08:59:51 amAbsolute TRIVIAL...... unless using the "POTTERIX" systemd... weird thingos...(which mostly mimics the MS also crappy methods..)you just do... (even with absolute garbage products that still holds..)Code:modprobe -a usbserial vendor=0x22b8 product=0x4181modprobe -a usbserial vendor=0x22b8 product=0x4061To select the proper item your driver will handle..but pleeease...LOAD YOUR USB STACK by HAND ...not letting that shitty systemd crapping the USB (stack) handlers..Paul

author: bd139
author_rank: Super Contributor
timestamp: February 28, 2021, 02:05:39 pm
content: Ugh I hadn’t realised systemd had got its ugly tentacles around that as well.

author: sb42
author_rank: Contributor
timestamp: February 28, 2021, 03:05:44 pm
content: https://wiki.debian.org/usbserialI don't see how this is systemd's fault, though I do see how I could write a udev rule to automate the manual steps on device insertion.

author: hirada
author_rank: Regular Contributor
timestamp: February 28, 2021, 03:10:34 pm
content: QuoteThe internet generally lacks information on this device. Probably, because having a Rigol et al. gives larger forum threads, therefore more incentive to own one, also because of the price/feature ratio. This one here is just too unspectacular, it simply just works as advertised. So far at least.However, as much as I appreciate the help I generally have recieved so far in this forum, since I do not have one of those aforementioned, fortune telling bench MM, I am not so sure about my warranty. So I am very sorry to refuse this request for now.Thanks for the reference to that other thread, I have been aware of it, but, as metioned earlier, when I originally wanted to reply, I have been told, for age reasons I'd rather should open a new one.QuoteThat is exactly what I have been doing, creating usable names, or rather links, for the devices and setting up the serial port upon pluggin in.Now, I have a final (?) screenshot, showing the 1908 in comparisson with my Prema MM, latter one being probably horribly out of calibration, so make of it whatever you want.

author: PKTKS
author_rank: Super Contributor
timestamp: February 28, 2021, 03:46:50 pm
content: Quote from: sb42 on February 28, 2021, 03:05:44 pmYou can ... and not a "fault" ...The dark side is that the whole STACK IS IN KERNEL..I have seen 0 (ZERO) distros based on systemd potterixin which you have control over the USB stack.Once the stack is loaded OK all should go as planned ..But *IF* the stack wrongly load modules in some weird way...Your USB handler may be claimed by the wrong piece of the stack.Do the proof of PUDIM.. just try it... if tit works OK.If not.. ditch the crappy kernel w/USB built in and load by hand.several compromises arise at this pointPaul

author: Monkeh
author_rank: Super Contributor
timestamp: February 28, 2021, 05:07:50 pm
content: Quote from: PKTKS on February 28, 2021, 03:46:50 pmWell you're not looking, because I'm looking at two major releases of Debian right now which do not build the USB stack into the kernel. Not that it's at all important to, because it hasn't caused a problem any time in the last decade or so, and they'll fix any such bugs if reported accurately very promptly.

author: hirada
author_rank: Regular Contributor
timestamp: March 01, 2021, 08:10:11 am
content: I need to correct myself again. In an earlier post I have been complaining about the remote output format not being fixed. Again, I just cannot read, that's all. The format IS fixed. When the exponent is negative, it has a single digit with a leading dash (somehow I've read two digits+dash), if it is positive, it is double digit with the first being a zero. Sorry for that!But I may have found another issue. When doing a relative measurement using the Null function, the meter displays the unnulled reading in the 2nd display. That is very handy, though it would be perfect if one could toggle between the nulled value and the unnulled reading, but that's just luxury.The issue is, that remotely, you cannot read out that 2nd display, it just outputs "range", which is the default for single display measurements. So while the display does show the actual reading - next to the realtive -, you cannot access it remotely. As long as Null is being used, you remotely just get the relative reading. Not sure if this would not even qualify as a bug.In addition, it seems one cannot read out the state of the battery remotely. At leat until now I have not found how to do it. If that turns out to be true and not just being a reading issue again, that is a bit of a bummer.

author: PKTKS
author_rank: Super Contributor
timestamp: March 01, 2021, 09:18:56 am
content: Quote from: Monkeh on February 28, 2021, 05:07:50 pmIt **MAY** be TRUE...I have stopped following DEBIAN for some time ..TBH.. since clever folks realized how bad those pitfalls are...and ROLLED THE PROPER DEVUAN fork..Perhaps the "debian leaders" realized how shitty that potterix can beand decided to "review" some of those mimics..perhaps. TBH i have 0ZERO interest following the potterix distros..My time is limited and I follow just what matters.Anyway my advice is simple:- IF IT JUST **WORKS** than go with it..if not follow the advices...Paul

author: hirada
author_rank: Regular Contributor
timestamp: March 03, 2021, 04:56:45 pm
content: And now for something completely different: Positive news.While my first enquiry about linux compatibility has never been answered, the report about the proposed issue with the 2nd display Null issue has been answered within less than two days - including a fixed firmware file. That again is pretty impressive and sets quite a standard for the competition.It just took me while to organise a suitable windows machine needed for the update procedure - at the end a hasty setup virtual machine with passed through USB adapter - and to organize a tool small enough to fitting through the tiny hole in the back to being able to press the udate enable button. Other than that, pretty straight forward and painless.And now the remote operation for the null function is working as expected as well.

author: bd139
author_rank: Super Contributor
timestamp: March 03, 2021, 06:03:24 pm
content: That is rather impressive. Well done TTiI've spoken to their support a couple of times via email regarding service information and they've been really good generally but that is exceptional.I suspect on the Linux front, they just don't have anyone who can deal with it or knows about it.

author: hirada
author_rank: Regular Contributor
timestamp: March 08, 2021, 08:28:54 am
content: Some more good news. Not sure wether this was an operation error previously by me or wether it's new, but the VA mode in the 10A range is now working. It is not described in the manual, so in case of an operating error, this time it is not due to my inability to read, but it does work now.Remotely slight unintuitive, as there is no "VA 10A" command, you first have to select 10A current as 2nd reading before you can select va, but once you know this, it's basically a non issue.Locally you can do the same, or operate "2nd + range up" while being in VA mode, exactly as with current, that again is described in the manual. I believe having tried this before with va, but would not bet on it.I'll occasionally update this thread, just in case someone else has interest in this device in a very distant future, or remote galaxy with fast internet, as it generally really is quite a pleasure to work with and still seems to receive support from the vendor.