Waveform display bug in the LA104

29.03.2022 18:44

I recently picked up a Miniware LA104, a small 4 channel logic analyzer. I thought a stand-alone, battery powered logic analyzer might be useful in some cases, especially since it comes with built-in protocol decoding for I2C. I have a few random USB-connected logic analyzers in a drawer somewhere, but I found that I rarely use them. When I do need a logic analyzer I tend not to have a PC at hand with all the necessary software setup, I don't want to risk the laptop by connecting it to a possibly malfunctioning device or there's a suitable oscilloscope nearby that works well enough for the purpose.

The first test I did with LA104 fresh out of the box was to connect all of its 4 channels to a 100 kHz square-wave signal and run a capture. I was disappointed to see that the displayed digital waveform had occasional random glitches that were certainly not there in the real signal. 100 kHz frequency of the input signal was well below the 100 MHz sampling frequency of the LA104, so no undersampling should occur either:

Miniware LA104 displaying waveform with glitches.

Interestingly, when exporting the captured waveform to a comma-separated value (CSV) file using the function built into the stock firmware and displaying it in PulseView, the glitches were not visible anymore:

The captured 100 kHz waveform displayed in PulseView.

This suggested that the waveform capture was working correctly and that the glitches were somehow only introduced when drawing the waveform onto the LA104's LCD screen. Considering that this device was released back in 2018 it's unlikely there will be another firmware update from the manufacturer. However since the source for the firmware is publicly available, I thought I might look into this and see if there's a simple fix for this bug.

For the sake of completeness, I was using firmware version 1.03, which came preloaded on my device and is also the latest publicly available version from Miniware at this time. I'm aware that there exists also an alternative open source firmware for LA104 by Gabonator on GitHub. However that project seems to be focused on various other, non-logic-analyzer uses for the hardware. A quick diff of the logic analyzer app in Gabonator's firmware against the Miniware's source release showed that logic analyzer functionality hasn't received any significant changes or bug fixes.

Looking at the Save_Csv() function in the firmware source, it appears that the CSV export directly dumps the internal representation of the waveform into a file. The exported file for the 100 kHz waveform looked something like the following:

Time(nS), CH1, CH2, CH3, CH4,

First column is the time interval in nanoseconds while the rest of the columns show the logic state of the four input channels. It's interesting that the first column is not a timestamp. The CSV also does not contain all input samples, rather it only lists the detected changes in input states. The first column contains the time interval for which the channels were held in the listed state after the last change. In other words, the LA104 internally compresses the captured samples using run-length encoding.

In the example above, it means that all four channels were in the logic 0 state for 4990 ns, followed by all four channels in the logic 1 state for 4990 ns, and so on. This timing checks out since it corresponds roughly to the 100 kHz frequency of the input signal. Note also that all intervals are multiples of 10 ns - this makes sense since the 100 MHz sampling rate makes for a sampling period of 10 ns. The export function simply multiplies the sample run length by 10 to get the time interval in ns.

Inspecting the part of the CSV export where the LA104 displays the glitches gives a hint to where the problem might be:


The highlighted lines show that the logic analyzer detected that some channels changed state one sample time before others. That is fine and not very surprising. I'm not expecting all channels to change state perfectly in sync down to the nanosecond scale. This can be due to slightly different wire lengths, stray capacitances and so on.

It seems however that the waveform drawing routines on the LA104 do not handle this situation well. At the scale of the display, the 10 ns delay is much less than one display pixel, so it should not even be visible. However for some reason LA104 chooses to display this short transitional state and then ignores the next, much longer stable state altogether. This leads to the waveform seemingly skipping cycles on the display: in the first instance channels 3 and 4 stay in logic 1 state for a cycle when they should go to logic 0; in the second instance channels 1 and 3 stay in logic 0 state for a cycle when they should go to logic 1.

Waveform on the LA104 with highlighted glitches.

In fact, the glitch disappears if I zoom enough into the part of the waveform where the missing edge should be. This suggests that this is indeed some kind of a failed attempt at skipping over signal transitions that are shorter than one display pixel:

Glitch disappears when zoomed into the missing edge.

Looking deeper into what might be causing this led me to the ShowWaveToLCD() function, which seems to be called whenever the waveform on the screen needs to be refreshed. Unfortunately, this function only seems to send some instructions to the FPGA and not much else.

LA104 consists of a STM32F103-series ARM microcontroller and an FPGA. The FPGA is used for waveform capture while the microcontroller handles the user interface. According to the public schematic, both the FPGA and the ARM are connected via a shared bus to the LCD. Hence it seems feasible that the waveform drawing is done directly from the FPGA. This was still a bit surprising to me, since everything else on the screen seems to be drawn by the code running on the ARM. Probably drawing the waveform directly from the FPGA was faster and led to a more responsive user interface.

Unfortunately, this means that fixing the waveform display bug would require modifying the FPGA bitstream. Its source is not public as far as I know. Even if it were, apparently building the bitstream requires a bunch of proprietary software. In any case, there's not much hope in getting this fixed in a simple way. It should be possible to write a new function that does the waveform drawing from ARM, but that would require more effort than I'm prepared to sink into fixing this issue. In the end it might turn out to be too slow anyway.

I'm afraid LA104 will end up gathering dust in a drawer with my other logic analyzers. A logic analyzer for me is primarily a debugging tool, but a tool that misleads me by showing problems that are not there is worse than having no tool at all. I might find some use for it for capturing signal traces for later off-line analysis on a PC, since so far that seems to work reliably. Other than that, sadly I don't see myself using it much in the future.

Posted by Tomaž | Categories: Code | Comments »

Effect of ground cutout on the CM4 antenna

10.03.2022 11:16

Recently I had the opportunity to test how much the design of the carrier board affects the performance of the PCB antenna on the Raspberry Pi Compute Module 4. I compared a custom carrier board with the CM4 centered over a continuous ground plane, a similar board with the suggested ground cutout under the antenna and the official Raspberry Pi CMIO4 board that has the cutout, but also places the module on the edge of the board. I recorded the RSSI of the Wi-Fi signal in different locations using these carrier boards. I found that the cutout only improves RSSI by around 3 dB on average. Both custom boards performed significantly worse than CMIO4.

PCB antenna on the Raspberry Pi CM4.

One of the improvements of the Raspberry Pi Compute Module 4 over the Compute Module 3 is the on-module Wi-Fi radio interface with a built-in antenna. The antenna on the module provides basic wireless connectivity without requiring any external components. However the Compute Module is not a stand-alone device and the quality of Wi-Fi reception is affected by the design of the carrier board the module sits on. Ground plane on the carrier board and any other components placed near the antenna will change its properties and hence the losses in signal transmission and reception.

Figure 11 from patent CN110770975A.

Image by Proant Ltd

This is Figure 11 from patent CN110770975A. The antenna on the CM4 is similar to ones shipped on other Raspberry Pi boards with on-board wireless interfaces, like the Zero W and Raspberry Pi 3. It consists of a triangular slot etched into the copper layers of the PCB with a few tiny SMT capacitors soldered on top. The copper pattern forms a resonant cavity antenna with resonances at 2.4 and 5 GHz. The design has been licensed by the Raspberry Pi Foundation from the Swedish company Proant AB. This antenna design is currently marketed by Proant under the trademark name Niche. The original patent is in Chinese, however Google Patents has a good English translation that references the figures in the Chinese document. Some professional measurements of the VSWR and the radiation pattern are also available from Antenna Test Lab.

Figure 4 from the Compute Module 4 datasheet.

Image by Raspberry Pi Trading Ltd

The datasheet for the Compute Module 4 suggests that an external antenna be used where possible. Otherwise it suggests that the carrier board should ideally have at least an 8 x 15 mm cutout in the ground planes under the antenna and that the antenna be oriented towards the edge of the device.

Ground plane cutout for the antenna on CMIO4 carrier board.

The picture above shows the official CMIO4 development board for CM4. As you can see, it follows both of these these recommendations. However many carrier boards in the wild do not include the ground cutout and/or place the board somewhere in the middle of the carrier PCB. The datasheet suggests that the designer checks the performance of the antenna on their specific design, but doesn't go into further detail on how to do that.

I recently had the opportunity to test the antenna performance on two custom carrier boards where the only major difference between them was that Board A had the recommended 8 x 15 mm ground plane cutout and the Board B did not. More precisely, Board B had ground and power planes and signal layers without any consideration for the antenna. Board A maintained the 8 x 15 mm keep-out area recommended by the datasheet on all layers. No copper planes or traces were present inside this area. I also had a stock Raspberry Pi CMIO4 board at hand for comparison.

Carrier board A with a continuous ground plane.

Carrier board B with ground cutout under the antenna.

Both custom boards placed the Compute Module 4 in the middle of a larger PCB, with the PCB extending approximately 47 mm beyond the edge of the CM4 with the antenna pattern. They used the mating connector with 1.5 mm stacking height. I can't disclose the details of the design, so I'm only sharing a rough sketch of the important dimensions. The carrier board shape was more complicated than shown. The boards had the CM4 mounted on the top side, while all other SMT components were on the bottom side. Wi-Fi reception was tested without any enclosure and apart from the carrier board PCB there were no other parts near the antenna.

My test consisted of taking one board, placing it in a specific location relative to the wireless access point, turning it on and recording the RSSI on both the Compute Module 4 (station - STA) and the wireless access point (AP). I fixed the transmit power on both sides using the set txpower command. I then turned it off and repeated the measurement for all locations. I repeated the sequence for all boards. Locations were in different rooms in a brick building and had different orientations of the antenna relative to the access point. I took care that at each location the antenna was oriented consistently for all boards. Access point was a TP-Link Archer C5 and wasn't moved during the measurements. The measurements were done in the 2.4 GHz band.


function measure {

	ssh $HOST 'N=0
	while [ $N -lt '$NMEAS' ]; do
		iw dev '$DEV' info
		iw dev '$DEV' station dump
		sleep 1
	done' > $FN

ssh $HOST_D "iw dev $DEV_D set txpower fixed 1800"

sleep 120

measure $HOST_D $DEV_D $FN_D&
measure $HOST_A $DEV_A $FN_A&


The gist of the script I used for the measurement is above. It takes 100 samples of the RSSI using the station dump command in 1 second intervals from both the access point and the station. The 120 second sleep after setting the TX power is there because I found on previous experiments that on some wireless adapters it takes some time for the TX power command to take effect. I think this pause is not necessary for CM4, but I left it in the script just to be sure. From the TX power reported by the info command it appeared that the TX power on both sides was indeed fixed at the set levels.

RSSI measured at the wireless LAN access point.

RSSI measured at the Compute Module 4.

In the plots above, the solid horizontal lines show the mean RSSI for each location and carrier board. Apart from the mean value, the distribution of the 100 RSSI samples is also shown in the form of a violin plot. Top figure shows RSSI reported by the access point and the bottom figure shows RSSI reported by the Compute Module 4. Higher RSSI means better reception.

The results show that Board B with the cutout consistently outperformed Board A without the cutout. The difference isn't large however, only about 3 dB on average. Similarly, CMIO4 consistently outperformed Board B. The difference was larger here and varied quite a lot by location. On location 3 it was as large as 17 dB on both sides of the connection. On average the difference was around 8 dB.

TX bitrate reported by the wireless LAN access point.

Bitrates selected by both the access point and the Compute Module 4 depend on the quality of signal reception as well. On average, the transmit bitrates on the access point were around 16 Mbit/s higher with Board B than Board A. Bitrates on CMIO4 were around 18 Mbit/s higher than with Board B. Again there was a lot variation between locations. However the bitrates might have been also affected by interference from other traffic on the 2.4 GHz band, not just antenna performance.

In conclusion, it seems that the addition of the cutout helps somewhat with the antenna performance. However judging by the fact that the difference between CMIO4 and Board B with the cutout was higher, it seems that the recommendation that the antenna is placed on the edge of the circuit board is more important than the cutout itself.

It's hard to say what these numbers mean in practical use, in terms of connection reliability. Let's assume that in free space Board A can operate reliably some distance from the access point. Then Board B with 3 dB better reception would be able to operate at the same reliability at a distance 140% larger than Board A. Similarly, 8 dB difference for CMIO4 translates to around 250% larger maximum distance. In a building with walls the effect is hard to predict. From other experiments I've done I can say that the CMIO4 performance is comparable to a typical half-wave dipole antenna, at least using this method.

The only apparent problem I've seen during my testing was that the Compute Module 4 had problems associating with the Wi-Fi network on Board A on location 2. Two or three attempts were usually necessary to get network connectivity. Otherwise the wireless network seemed to work fine for a usable ssh connection.

The exact results would very likely differ for a different design of the carrier board or a different choice of locations, so I think these numbers only give a rough idea of what the effect of the cutout is in general. It would be interesting to get some reflection measurements as well using a VNA. Unfortunately the few CM4s I have available are quite precious since it's very hard to get new ones at the moment. Connecting the antenna to the VNA would require some, very likely destructive, modifications to the module to connect a coax cable to the antenna. Because of this I only did what measurements I could using the stock radio present on the module.

Posted by Tomaž | Categories: Analog | Comments »