[Avian] has picked up a Miniware LA104 – a small battery-powered logic analyzer with builtin protocol decoders. Such analyzers are handy tools for when you quickly need to see what really is happening with a certain signal, and they’re cheap enough to be sacrificial when it comes to risky repairs. Sadly, he stumbled upon a peculiar problem – the analyzer would show the signal glitching every now and then, even at very low bitrates. Even more surprisingly, the glitches didn’t occur in the signal traces when exported and viewed on a laptop.
He dug into the problem, as [Avian] does. Going through the problem-ridden capture files helped him realize that the glitch would always happen when one of the signal edges would be delayed by a few microseconds relative to other signal edges — a regular occurrence when it comes to digital logic. This seems to stem from compression being used by the FPGA-powered “capture samples and send them” part of the analyzer. This bug only relates to the signal as it’s being displayed on the analyzer’s screen, and turned out that while most of this analyzer’s interface is drawn by the STM32 CPU, the trace drawing part specifically was done by the FPGA using a separate LCD interface.
It would appear Miniware didn’t do enough testing, and it’s impossible to distinguish a good signal from a faulty one when using a LA104 – arguably, the primary function of a logic analyzer. In the best of Miniware traditions, going as far as being hostile to open-source firmware at times, the FPGA bistream source code is proprietary. Thus, this bug is not something we can easily fix ourselves, unless Miniware steps up and releases a gateware update. Until then, if you bought a LA104, you can’t rely on the signal it shows on the screen.
When it comes to Miniware problems, we’ve recently covered a Miniware tweezer repair, requiring a redesign of the shell originally held together with copious amount of glue. At times, it feels like there’s something in common between glue-filled unrepairable gadgets and faulty proprietary firmware. If this bug ruins the LA104 for you, hey, at least you can reflash it to work as an electronics interfacing multitool.
“and they’re cheap enough to be sacrificial when it comes to risky repairs”
Ehmm…. what does that mean. I can see what you mean if this article was about a chisel, used a a screwdriver.
But an electronic tool, if it goes up in smoke while doing a measurement, no matter how cheap it is, if you have only one you can’t continue. And buying X more just until the problem is diagnosed makes no sense either. So I’m a bit confused here.
The difference is between ‘oh crap, I need to buy a new one’ and ‘oh crap, I can’t afford to buy a new one’.
I think the point is that it is cheaper to replace $100 toy analyzer than e.g. your laptop if you are using a PC-based analyzer or your oscilloscope.
Of course it sucks when something goes up in smoke but if it does, I prefer that it is something that I can easily replace.
(btw, I don’t think it is is Miniware making these, I think they are only rebadging it, it is available under many other brands)
usb isolator, $10 saleae clone and sigrok/pulseview setup never let me down over last 3-5 years.
This. Though USB2 high-speed isolators can be a bit expensive at $50.
Ok if you’re doing something it can do. I got one a while back (quicker to order from the Bezo barn than go into work…), But got hit by it not coping with 1.8v logic. Couldn’t find any info online on how to change the trigger level, so in the drawer it went.
Noob here, why do you need to isolate the USB on these devices? Interference?
In case of an unexpected high voltage failure. Sacrificing the cheap Saleae clone is nothing, but sacrificing your computer can be an expensive job.
for me it’s a knockoff arduino nano with sigrok. Even printed a little case for it. Not great but it works well enough
I run into issues like this in my work, (automotive diagnostics) your always on the lookout for a bargain, but if you can’t trust the tools results , it’s useless irrespective of how cheap it is. Imagine a dmm on continuity that only beeped 9/10 times the probes touched. And you end up chasing your tail for a problem that doesn’t exist. Very frustrating.
Here is an (active project) of alternative firmware for this device:
https://github.com/gabonator/LA104
If the Chinese are using their own cheap tools to design their products, then they will never be able to create quality devices. If we start using their own cheap tools, then we will never be able to create quality devices either.
Conclusion: use our own quality tools, and leave the Chinese cheap tools to the Chinese?
Horses for courses. I own a couple of those cheap HF multimeters just for readouts on stupid stuff, like battery voltage, in a big project. I also will loan them out if someone asks me for a meter to borrow… No way I’m handing out an $800 fluke for that.
You also have to remember that not all of us are doing well financially. When I was growing up all I could afford was a radio shack meter! Plenty of other people are just starting this hobby or climbing up from the bottom. Best not to sneer and look down your nose… I’ve met great craftsman with simple tools that can outwork plenty of other guys equipped with the fancy stuff.
Nothing worse than an unreliable piece of test equipment. Unless perhaps it is a buggy compiler.
I’m not sure what you mean by Miniware being “hostile” to open source efforts? I’ve had really good experiences with their tools over the years and I’m sure I’ll have many more.
I can see their highly integrated (and thus non-repairable) tweezer design being labeled as “hostile to open source,” but that just seems to be a symptom of its compact design rather than anything nefarious?
Is there something hostile that they are doing that I’m missing?
I just checked Miniware’s website and found a link to resource downloads for the LA104 including schematics and source code. But it sounds like the particular blob that needs to corrected for this issue is a proprietary blob?
Just playing around with my LA104 for the first time. The pulse rendering bug is significant and noticeable. But I found that widening the pulses on the display (increasing the timescale) makes it less likely to render a pulse incorrectly.
I also accidentally discovered the subtle (and awesome) “autoscroll” feature, which pans across the timebase. Highlight the “Time” menu and click “OK” until that menu header shows “Time: X”. Then press and hold the “OK” button and swing wheel B either up or down. The captured data will pan left or right at a fixed rate. MUCH faster way to explore an entire capture. I noticed the rendering bug on the left edge of the display while autoscrolling, especially with narrow pulses (tighter timescales).