Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests

[tautech]

And if we want make better.
Oscilloscope decoder need have more settings for signals.
Now there is only one threshold for one signal.

Sorry, that was my mistake. There are indeed two settings, separate for CK and D. But I share your opinion

No, there IS only one threshold for one signal in SDS2000X Plus, SDS2000X HD and many other Siglent oscilloscopes (and many others too). Example SCL (this is one signal in my context) have just one threshold. Can not define threshold for High state level and Low state level.

Here's an example of how NXP says general information related to their stuff and views on I2C definitions.

Yet we can define the logic type/level when in Digital mode.
Maybe a small range of choices need be added for analogue decoding too ?

Something we need take to the Siglent forum ?

[Performa01]

Rookie's method (trial and error) to set up the decoding?

I prefer to use an informed choice for the thresholds.

Didn’t expect that my words could be misinterpreted so badly (on purpose?)

What I meant was of course that we set up the decoding first, including baud rate, polarity, idle level or whatever applies to the protocol in question, then test it and only when it runs okay, copy the settings to the trigger. I was talking about serial decode in general and the fact that I2C doesn’t have any specific settings apart from the R/W-bit inclusion is irrelevant here.

One can always make some mistake, such as wrong signal connections or inappropriate threshold levels. It is sensible to test this before happily copying to the trigger and just hoping that everything works and the scope will trigger on the right message…

On the issue of the default path: Pages 312 to 314 each show a menu that has the option "Save Path" or "Recall Path" with "Internal" and "External". These options do not exist on my scope. When saving/recalling via mouse or on-screen-finger one can choose this via the file manager. This does not work, though, when hitting the PRINT button. So, concrete question: How do I set the scope up such that after powering up, without messing with menus first (i.e. by default), hitting PRINT saves the screenshot in a particular folder, that is not called 'SIGLENT', on the thumb drive?

The page you're mentioning explains all a sort of things by using menus. It does not explain how to set up defaults. In fact, the only sentence in the manual where the word 'default' refers to a path, is "The default save path is \SIGLENT\." (Page 318 EN01D)

It might not be brilliant in a didactical sense, yet you just should have sticked to the page I’ve referred to.

It simply works as follows:

In the SAVE menu, you select the appropriate type (PNG), image style and menu inclusion and then you launch the File Manger:


SDS2354X_Plus_File Manager

Now you see the internal memory (local) as well as any externally plugged thumb drives (U-disk). You select the external U-disk here. There is no internal/external switch – don’t know where this error in the manual comes from, since to the best of my knowledge it has never worked any different to what it does now.

Now you select the U-disk, navigate and subsequently use the “New Dir” command to create a new folder wherever you want with whatever name you like, then navigate into that folder and save the PNG file under an arbitrary name that you like. Bingo!

This very first screenshot will be saved just with the name you’ve typed. All subsequent screenshots (initiated by the blue “Print” or “Save” button will go to the same folder and have the same filename, but get a sequence number appended. The sequence number starts with “2” in this special case; after emptying the screenshot directory on the PC, sequence number will be reset to “1”.


Custom Screenshot Save Path

If you forget to plug your U-disk in, the scope automatically stores to the internal memory. If it was a precious, irreplaceable screenshot, then you can insert the U-disk and copy the file using the File Manager. Otherwise, you can just delete it – or leave it where it is until you run out of internal memory one day...

[Slartibartfast]

And if we want make better.
Oscilloscope decoder need have more settings for signals.
Now there is only one threshold for one signal.

Sorry, that was my mistake. There are indeed two settings, separate for CK and D. But I share your opinion

No, there IS only one threshold for one signal in SDS2000X Plus,

I guess there is a misunderstanding at work here. If by "one threshold for one signal" you mean "one threshold per signal" then we're in sync. In an earlier posting I stated falsely that there is only one threshold that applies to both signals. I had thought you were referring to that.

[Slartibartfast]

Rookie's method (trial and error) to set up the decoding?

I prefer to use an informed choice for the thresholds.

Didn’t expect that my words could be misinterpreted so badly (on purpose?)

Well, since I'm used to well-informed postings from you I suspected that what you wrote was not exactly what you meant. That's why I used two flashy devil smileys to make it very clear that I wasn't serious.

Didn't expect that two such smileys in those locations aren't enough to make that obvious.

What I meant was of course that we set up the decoding first, including baud rate, polarity, idle level or whatever applies to the protocol in question, then test it and only when it runs okay, copy the settings to the trigger. I was talking about serial decode in general and the fact that I2C doesn’t have any specific settings apart from the R/W-bit inclusion is irrelevant here.

What you write here I indeed cannot find in your original words, at least not with my (admittedly very limited) capability of english understanding.

Be that as it may, however, "copy the settings to the trigger" does not make too much sense, IMHO. Even if I couldn't see the edge I want to trigger on beforehand, I'd still know the two digital logic levels, and can choose the trigger level from that. And then of course you're right saying that some glitches may necessitate tweaking the trigger level a bit. But this is also why I prefer to choose levels independently: In order to find some rogue glitches I'd need exactly such a threshold as I avoided to use for the decoder, to avoid upsetting it by the same glitches.

One can always make some mistake, such as wrong signal connections or inappropriate threshold levels. It is sensible to test this before happily copying to the trigger

Apart from trying out I have never used that copying function. In addition to making limited sense (as I wrote above), I'm also far faster just rotating the trigger level knob versus clicking through menus to reach that copying function.

On the issue of the default path: Pages 312 to 314 each show a menu that has the option "Save Path" or "Recall Path" with "Internal" and "External". These options do not exist on my scope. When saving/recalling via mouse or on-screen-finger one can choose this via the file manager. This does not work, though, when hitting the PRINT button. So, concrete question: How do I set the scope up such that after powering up, without messing with menus first (i.e. by default), hitting PRINT saves the screenshot in a particular folder, that is not called 'SIGLENT', on the thumb drive?

The page you're mentioning explains all a sort of things by using menus. It does not explain how to set up defaults. In fact, the only sentence in the manual where the word 'default' refers to a path, is "The default save path is \SIGLENT\." (Page 318 EN01D)

It might not be brilliant in a didactical sense, yet you just should have sticked to the page I’ve referred to.

It simply works as follows:

Why should I have assumed that what you choose in the file manager also applies to the PRINT button, let alone surviving a reboot? To me, this is far from obvious. IMHO it flies in the face of user interface good practices, because it is not intuitive. Brilliant or not, the manual just does not have this information.

I will play with that a bit tomorrow.

There is no internal/external switch – don’t know where this error in the manual comes from, since to the best of my knowledge it has never worked any different to what it does now.

I beg to differ. I have a fairly clear memory of having played with that menu entry. Maybe you never used it because you found out early what you're describing here?

[2N3055]

I use copy to trigger and back quite often.
It not only copies levels, it does it for all the signals and also signal to channel assignments and other parameters.
For full SPI that is 4 channel assignments and level for each.. and other settings..
I connect, capture single, set timebase, capture again, go to decode, setup signal connections and levels. Once I get meaningful result, copy to trigger. No need to set 10 parameters again.

[Performa01]

Be that as it may, however, "copy the settings to the trigger" does not make too much sense, IMHO. Even if I couldn't see the edge I want to trigger on beforehand, I'd still know the two digital logic levels, and can choose the trigger level from that. And then of course you're right saying that some glitches may necessitate tweaking the trigger level a bit. But this is also why I prefer to choose levels independently: In order to find some rogue glitches I'd need exactly such a threshold as I avoided to use for the decoder, to avoid upsetting it by the same glitches.

We are talking about serial triggers here, not a simple edge trigger. Of course you can use edge/pulse/timeout triggers, maybe in conjunction with holdoff, to get a stable capture of the serial data stream, but then you get all packets, even though you might only be interested in very specific ones, e.g. with certain addresses and/or certain characters in the payload.

For this to work, the serial triggers need to be able to decode the data stream, hence also need the correct settings. There is no “trigger level” for serial triggers, just signal assignments to the input channels, separate threshold levels for each channel, polarity, idle level, baud rate, command bit inclusion and the like. On the other hand, if you turn the trigger level knob, nothing will happen at all.

There can be different concepts. Siglent uses the most obvious one: triggers and decoders are completely independent modules. Triggers are implemented in hardware, because of the speed requirements, whereas decoding is done in software because of the flexibility. Of course, we could just have one single setting that is used by both modules, but where to place them?

Some people don’t care for serial trigger and just want to see every single packet – and use some edge/pulse/timeout trigger for that. They want to find the protocol settings in the serial decoder of course.
Some other people don’t need to decode anything, they just want to trigger on a specific serial packet and watch the related signals at that point in time. These folks only need to set up the trigger and of course expect to be able to do this in the trigger settings. Btw, there have been times (long ago) where serial triggers have been free, whereas serial decoders were paid options. At about 2017, Siglent were the first to provide basic triggers and decoders (UART, SPI, I2C, CAN, LIN) for free…

Back to topic: We could have different places for accessing the serial settings and still use a common data set for them. Then any change in the decoder would immediately affect the trigger as well – and vice versa. Most of the time, this would be the wanted behavior, But since trigger and decoders can be used independently, even on different serial buses at the same time, we don’t want to limit the user (user shall be master and not slave of the machine) and consequently allow individual settings for the individual modules.

With the possibility to copy the decoder settings into the trigger as well as the trigger settings into the decoder just with a single touch, we have the best of both worlds.

Apart from trying out I have never used that copying function. In addition to making limited sense (as I wrote above), I'm also far faster just rotating the trigger level knob versus clicking through menus to reach that copying function.

I hope that you’ve realized by now that there is no “trigger level” for serial triggers and the trigger level knob has no function at all. But you can save the hassle to retype a bunch of settings. Imagine SPI as a popular example:

4 different Signals -> 4 different channels, 4 threshold levels, clock phase and CS type -> 10 settings.

That’s much more hassle than just remembering a single threshold level and then turning a knob.

There is no internal/external switch – don’t know where this error in the manual comes from, since to the best of my knowledge it has never worked any different to what it does now.

I beg to differ. I have a fairly clear memory of having played with that menu entry. Maybe you never used it because you found out early what you're describing here?

Yes, I found it out immediately – and quite honestly, this is something I set once in my lifetime and then forget about it – as long as I don’t need to do a demonstration like in my last post, but this has been the first time in my long career as Siglent DSO power user….

[Slartibartfast]

Seems I have come across another bug. It may be related to decoding again, at least up to now I only observed it in that context.

I noticed some peculiar behaviour, as shown in screenshot A (A to D attached in that sequence). I had been listening on some UART line, where the traffic is under my control. At 115200-8N1, I noticed some decoded data being shown, where its associated voltage trace shows no activity (right half of the screenshot). Strange?

Now, I turned the timebase knob one tick to the right (shot B). The trigger LED flickers for a moment, as if the scope retriggers, however this is not the case. There was no activity on the bus while I turned the knob, which I also confirmed using a second scope attached at the same time. Now, I turned the timebase knob one tick back (i.e. to the left), restoring the previous timebase setting (shot C). But - what's that: Suddenly there is activity on the trace where previously was none. The puzzle deepens.

Looking carefully, comparing the left half of shot A and C, you'll notice it's a completely different trace! So I manually decoded the trace shown in shot A, and knowing what truely was on the bus, I immediately knew what was happening: I got the data that was sent before, caught with the previous trigger, which should be obsolete at the time when shot A was taken.

Repeating the exercise with 'single' trigger (shot D), I looked at the previous data packet, and got exactly what was shown in the trace in shot A, but is very different from what the decoder track shows there.

So it's an update problem. There are two data packets, 15ms apart. The scope triggers on the first, shows the trace, possibly starts decoding, then triggers again, decodes the new data and shows it in the decode track, but fails to update the voltage trace. Operating the timebase does not re-trigger (as remarked before; the trigger LED should not flicker, which is a minor bug), but it causes both the decode trace and the voltage trace to update, so after that they are consistent with each other.

The failure to update the trace is a serious bug, and possibly a hard-to-find one for the firmware engineers, unfortunately, as it may be a race condition between concurrent threads.

Cheers  Peter

PS.: Like before, this was with firmware version 1.5.2r3, which I believe to be the most recent one.

PPS.: In case it isn't obvious from what I wrote: The failure to update as described is absolutely repeatable, however I have not established how sensitive it is to which circumstances.

[Slartibartfast]

Some people don’t care for serial trigger and just want to see every single packet – and use some edge/pulse/timeout trigger for that. They want to find the protocol settings in the serial decoder of course.

Yep, that's me, up to now.

I have not needed protocol triggers up to now. I may need them in the future of course, and from what you describe it seems I have underestimated the usefulness of the 'copy' function. I should like to read up on it.

Apart from trying out I have never used that copying function. In addition to making limited sense (as I wrote above), I'm also far faster just rotating the trigger level knob versus clicking through menus to reach that copying function.

I hope that you’ve realized by now that there is no “trigger level” for serial triggers and the trigger level knob has no function at all.

No need to realise now, I've known for the last, like, 20 years, that protocol triggers don't have a trigger level. It's really that obvious. 

There is no internal/external switch – don’t know where this error in the manual comes from, since to the best of my knowledge it has never worked any different to what it does now.

I beg to differ. I have a fairly clear memory of having played with that menu entry. Maybe you never used it because you found out early what you're describing here?

Yes, I found it out immediately – and quite honestly, this is something I set once in my lifetime and then forget about it.

Then I wish you good luck. I also thought, when I set the screenshot-storage directory roughly a year ago, I might never need to touch that setting again. Well, the update to 1.52r3 reset that directory to factory setting. Seems the firmware engineers do not ask you whether you'd like to never touch a certain setting again.

Of course you can still refuse to never set it again.

Cheers  Peter

PS.: I do not know if you ever worked in an environment where collegues use the same scopes, and change settings to your disliking? Do you "set once in my lifetime and then forget about it" there too?

[cte]

I think I found a bug in sequence mode, when used in conjunction with specific zoom levels and/or timebase.

I have an SDS2104X Plus with Firmware Version 1.5.2R3, CPLD Version 05 and Hardware Version 05-05

Steps to reproduce:

• Apply signal on Channel 1 + 2. I had both channels at 5V/div with 10:1 divider (probably not relevant for bug reproduction).
• Set timebase to 500µs/div.
• Turn on sequence mode.
• Now turn on zoom mode and zoom to 20µs/div.

The signals are not drawn to the screen anymore, instead it's endlessly showing "Processing..." in the lower right of the screen. User interface responds sluggish, but you can recover by changing the zoom level away from 20µs/div.


Demonstration video:


Maybe someone can try to reproduce this?

[3.141529]

A feature request:

What I want to do is measure how long a signal remains high or low over a set period. I have a circuit with a busy signal and I'd like to know the amount of time it spends busy over a period of time. Currently I can work it out manually in one of two ways using measurements:

• I can measure the Area@DC of the busy signal and divide by the amplitude
• I can measure the +Width of the busy signal, select Statistics and multiply the mean by the count

Both of which are somewhat tedious. It would be nice if simple measurements were added that would give the cumulative + or -Width values.

[Performa01]

I think I found a bug in sequence mode, when used in conjunction with specific zoom levels and/or timebase.

I have an SDS2104X Plus with Firmware Version 1.5.2R3, CPLD Version 05 and Hardware Version 05-05

Steps to reproduce:

• Apply signal on Channel 1 + 2. I had both channels at 5V/div with 10:1 divider (probably not relevant for bug reproduction).
• Set timebase to 500µs/div.
• Turn on sequence mode.
• Now turn on zoom mode and zoom to 20µs/div.

The signals are not drawn to the screen anymore, instead it's endlessly showing "Processing..." in the lower right of the screen. User interface responds sluggish, but you can recover by changing the zoom level away from 20µs/div.

I've tried with both Ch.1 + Ch.2 and also Ch.3 + Ch.4, but was unable to reproduce this particular behaviour with FW 1.6.0, HW 02-00.

In General, Sequence Recording can be unresponsive, because the difference to normal mode is exactly that it only acquires the number of specified segments, while not drawing anything on the screen and ignoring most user inputs. On the other hand, I've never seen a "processing" message before in the lower right corner (only "Acquiring..."), so there might be something wrong indeed.

Since I cannot reproduce any of this with FW 1.6.0 I take it that this bug will be solved with the next public firmware version.

[rf-loop]

I think I found a bug in sequence mode, when used in conjunction with specific zoom levels and/or timebase.

I have an SDS2104X Plus with Firmware Version 1.5.2R3, CPLD Version 05 and Hardware Version 05-05

Steps to reproduce:

• Apply signal on Channel 1 + 2. I had both channels at 5V/div with 10:1 divider (probably not relevant for bug reproduction).
• Set timebase to 500µs/div.
• Turn on sequence mode.
• Now turn on zoom mode and zoom to 20µs/div.

The signals are not drawn to the screen anymore, instead it's endlessly showing "Processing..." in the lower right of the screen. User interface responds sluggish, but you can recover by changing the zoom level away from 20µs/div.

I've tried with both Ch.1 + Ch.2 and also Ch.3 + Ch.4, but was unable to reproduce this particular behaviour with FW 1.6.0, HW 02-00.

In General, Sequence Recording can be unresponsive, because the difference to normal mode is exactly that it only acquires the number of specified segments, while not drawing anything on the screen and ignoring most user inputs. On the other hand, I've never seen a "processing" message before in the lower right corner (only "Acquiring..."), so there might be something wrong indeed.

Since I cannot reproduce any of this with FW 1.6.0 I take it that this bug will be solved with the next public firmware version.

I have reproduced it also with FW1.6.0 (HW 06-05)
ETA: for reproduce this,  mode need be 8bit

Also if Timebase is still 500us/div and zoom window timebase is 500ps/div this same problem exist but now only ifcombination: Interpolation=Sinc, display type=Dots

 "Processing" bar appears and continue infinitely...

later when I get some free time I try find what is procedure how it can repeat... (do it need using some special order or what.) Also never seen this before and I have used Sequence quite lot.
ETA: after Security erase and factory defaults, it happen just simply.
There need be Ch1 and Ch2 on only  OR  Ch3 and Ch4 only. With other combinations I can not reproduce this 

[Wintel]

Hi,

Does the FW 1.6.0 will support Math Digital Filter and 4 Math traces (F1~F4)?

[rf-loop]

Hi,

Does the FW 1.6.0 will support Math Digital Filter and 4 Math traces (F1~F4)?

Not.

[Performa01]

Does the FW 1.6.0 will support Math Digital Filter and 4 Math traces (F1~F4)?

It has been stated several times already that there are not enough HW resources (FPGA, RAM) in the SDS2000X Plus to support any resource-hungry additional features, like math channels as well as the traditional ERES and Average acquisition modes. After all this is an alalysing oscilloscope with deep math and measurements, which does not work on heavily decimated (or even just screen) data.

It is different for the filter math. This has been shown to be operative with a beta version of FW 1.5.2 already, but had to be disabled because the full filter functionality also requires the extended memory management which supports fixed sample rate like on more advanced instruments such as the SDS2000X HD. This feature in turn is not yet ported to the SDS2000X Plus and this is a low priority task, so it might take a while. It is not in the 1.6.0 frmware, but I'd expect the next pulic FW release to be one step ahead.

[cte]

I have reproduced it also with FW1.6.0 (HW 06-05)
ETA: for reproduce this,  mode need be 8bit

Also if Timebase is still 500us/div and zoom window timebase is 500ps/div this same problem exist but now only ifcombination: Interpolation=Sinc, display type=Dots

 "Processing" bar appears and continue infinitely...

Thanks for checking this out. Was already thinking I might have a faulty device... 


In 500µs/div timebase and zoom window timebase at 500ps/div I can confirm the problem exists, but it doesn't make a difference whether I choose Vector or Dots mode. In Vector mode, it seems to be dependant of the number of Sequence Segments selected in Sequence menu and there is a delay until which the problem occurs:

(Settings: 500µs/div timebase, 500ps/div zoom, Sinc interpolation, Vector mode, 8 bits Resolution, 10 M max mem depth)

• with 2 Seq. Segments: nearly instanteous
• with 3 Seq. Segments: around 10 to 12s
• with 4 Seq. Segments: about a minute
• with 5 Seq. Segments: can take several minutes: measured 1'20'', 0'12'', 3'15'' and 1'55''

When the bug occurs, "Clear Sweeps" button (or Display -> Clear Display) resets it and the trace is shown again until bug gets triggered again after some time.


Max mem depth has to be at 10M or 100M. I haven't seen it on the lower settings.

Bug seems unaffected by any vertical settings so far. I used the probe calibration square signal on Ch 1 and have put Ch 2 to GND and it's still reproducable.

[Helix70]

When using the scope with digital channels but NO analog channels, it would be great if the vertical scale labels (voltage) were turned off, as it interferes with the labels for the digital channels, and isn't relevant. I know I can turn off all axis labels, but would like to keep the timebase labels.

[maxspb69]

Is the approximate release date for the new firmware known?

[mathstudi]

To the experts among us,

I got a nice I3C demo project with a Microchip PIC18F16Q20: https://github.com/microchip-pic-avr-examples/pic18f16q20-i3c-getting-started-mplab-mcc and a STMicro Sensors (LSM6DSO32) with I3C support: https://binho.io/blogs/i3c-articles/stmicro-sensors-with-i3c-support-available-now

Will the firmware upgrade 1.6.0 also include support for a new serial I3C decoder?

Cheers, mathstudi

[smallfreak]

I found a weird behaviour today saving images.

First I plugged in an USB stick and it was commented something like "stick found".
Upon pressing the "print" I was reminded that the image was saved. Each time, it incremented the name by one.

After the session I took out the stick to read the images on the PC, but there was nothing on it. So probably it saved to "internal". Back to the scope, there were no images in the internal memory either. Just to be sure, I took another one and it showed up as the one and only in the internal memory.

As I wanted to move this to the USB stick, that I again placed into the connector, I found that it had not been recognized at all. No "external". I tried with several sticks - none of them are recognized anymore, although they are good at the PC.

Did I break something? Can I convince the scope to at least format one? Do I have to prepare on specially to get it recognized again?

I'm a little confused. This has been working before. 

I just glimpsed at the firmware page, the latest one is still SDS2000X Plus_V1.5.2R3_EN.zip?

[tautech]

I found a weird behaviour today saving images.

First I plugged in an USB stick and it was commented something like "stick found".
Upon pressing the "print" I was reminded that the image was saved. Each time, it incremented the name by one.

After the session I took out the stick to read the images on the PC, but there was nothing on it. So probably it saved to "internal". Back to the scope, there were no images in the internal memory either. Just to be sure, I took another one and it showed up as the one and only in the internal memory.

As I wanted to move this to the USB stick, that I again placed into the connector, I found that it had not been recognized at all. No "external". I tried with several sticks - none of them are recognized anymore, although they are good at the PC.

Did I break something? Can I convince the scope to at least format one? Do I have to prepare on specially to get it recognized again?

I'm a little confused. This has been working before. 

Do you have the USB stick formatted FAT32 and preferably 4k clusters ?
Try a reboot.

I just glimpsed at the firmware page, the latest one is still SDS2000X Plus_V1.5.2R3_EN.zip?

Yep still the current version however V1.6.2 is with beta testers.

[tautech]

I just glimpsed at the firmware page, the latest one is still SDS2000X Plus_V1.5.2R3_EN.zip?

Yep still the current version however V1.6.2 is with beta testers.

Played with V1.6.2 last night and some cool things have been added.....can't wait for it to go public.

One little teaser screenshot....teaser I said and replaced with another....

[hpw]

As an E02A documentation update request for the "How to Extract Data from Binary File..."

Did just used a hex editor to analyze the content of a 32M file and found the following:

- Version is already Version 4, as on manual page 37 only mentioned for SDS200X HD after 0.9.6 & SDS5000X & SDS 6000 after 1.4.1.0

- the starting of data is located at 0x1000

- the data is as word offset binary (16 bit values)

   Example as using the extract tool to get the decimal text values from the csv file

Data on Bin    Text on csv file
33600         1.08E-04
33600         1.08E-04
33408         8.33E-05
33472         9.17E-05
33600         1.08E-04
33600         1.08E-04
33472         9.17E-05
33600         1.08E-04


- there is some complete false: Convert the Data to Voltage

  Formula on page 46:  voltage = (data-128) * ch_volt_div_val /1000/code_per_div + ch_vert_offset

  as this formula is for 8 bit data as data-128

- In addition the mystery: Code_per_div is 25 as mention for SDS1000 & SDS2000X... so for the binray offset is this still valid?


And updated Version 4 documentation or corrected calculations are welcome...

Hp

[maxspb69]

I would like to believe that colored digital channels are not the only significant innovation in 1.6.2. 

[tautech]

I would like to believe that colored channels are not the only significant innovation in 1.6.2.

It's not, the Fade saved file feature already in some other models is also added.

So far we have not seen release notes but they will come at public release.
Sorry you missed the previous teaser showing a Serial coms tester.