@Rob:
I know that all, the reason why I want you to show your settings (trigger) is, that I think the Signal is just not the same as on your testboard.
At the moment I have the board at work, test the I2C with two another scopes, in summary with four different scopes and just can't get the same result.
Every other decoding signal is no problem.
I made a short video from the SDS2104X+ to show that I had a stable signal, uploading it when back at home.
I also think like Martin72 that we have different board revisions.
On my board there is this imprint:
SDY8.007.126B,
STB3_160100.
There is also a bar code and the serial number, which I don't want to publish.
@Martin72 and @tautech: What board revisions do you have?
I bought my board from BATRONIX at the end of February 2022.
Hi,
My board is older, maybe I find a pic from it because I leave it at work today.
https://youtu.be/ndXcrO2niZ4Clip from today at work, stable signal, more stable you would get when pressing the stop button.
On my board there is this imprint:
SDY8.007.126B,
STB3_160100.
I bought my board from BATRONIX at the end of February 2022.
Same as mine however I have had this STB-3 for many years, certainly 5+.
Maybe we need share the scope Setup files to diagnose if settings are different.
You can experiment with those by saving, then default the scope and then recall the setup file to return the scope to previous settings.
You can experiment with those by saving, then default the scope and then recall the setup file to return the scope to previous settings.
When I reload the setup after resetting (Default) the scope I have to correct the SDA threshold in the decoder from 10.13V to 1.73V. In CH2 I have to change the attenuation from 1x to 10x. All other parameters are taken over properly.
The output of the I2C SDA signal remains unchanged.
Maybe there is a Siglent developer of the STP-3 reading the forum who can reproduce the behavior described by Martin72 and me when decoding the I2C signal.
At the moment the scope is not connected to the network. I will post the screenshots with my settings in the forum this weekend.
When I reload the setup after resetting (Default) the scope I have to correct the SDA threshold in the decoder from 10.13V to 1.73V. In CH2 I have to change the attenuation from 1x to 10x.
Same here, on the HD...
Thresholds are somewhere after restart and the attenuation thing I also recognized it from time to time.
I really don't know why you find basic I2C decoding difficult.
New SDS2104X Plus.....didn't even set edge to falling and only added 2ms trigger Holdoff.
Select Decode and check it is set to I2C then assign channels and then adjust Thresholds.
It took longer to boot than make these decode settings....
Does any of this apply to an SDS2104 NOT X? Probably not?
I really don't know why you find basic I2C decoding difficult.
I, for example, do not.
With the Batronix signal, it is also only a matter of a few moments...
I already had a stable trigger, see video.
A "stationary image" is not important for decoding, it is the thresholds for the signals.
You can try it out:
Turn the trigger level away and then press stop, no problem.
Do the same with the signal thresholds and nothing will be decoded.
At least I tried this with SPI and UART, it is unlikely that it should not apply to I²C.
So I don't think our problem is caused by the trigger.
Nevertheless, this was a good tip in the "manual" of the STB-3 board:
https://www.nxp.com/docs/en/user-guide/UM10204.pdf(direct link to a pdf from NXP(Philips) )
I really don't know why you find basic I2C decoding difficult.
I, for example, do not.
With the Batronix signal, it is also only a matter of a few moments...
I already had a stable trigger, see video.
A "stationary image" is not important for decoding, it is the thresholds for the signals.
You can try it out:
Turn the trigger level away and then press stop, no problem.
Do the same with the signal thresholds and nothing will be decoded.
At least I tried this with SPI and UART, it is unlikely that it should not apply to I²C.
So I don't think our problem is caused by the trigger.
Nevertheless, this was a good tip in the "manual" of the STB-3 board:
https://www.nxp.com/docs/en/user-guide/UM10204.pdf
(direct link to a pdf from NXP(Philips) )
Batronix packets are all header without any payload......the last few bits in the packet that are constantly changing.
With simple decode trigger settings for STB-3 we only see the header as stable and to trigger on payload bits we must use a serial trigger.
I only Stop'ped that screenshot to have it all stable.
I don't want to rule out the possibility that it's still my stupidity that's preventing me from getting it right....
Unfortunately, I won't have access to the board until tomorrow.
The signal is decoded to SIGLENT plus 4 random characters.
I always get NT plus 4 random character.
Does this have something to do with the trigger, I can't imagine.
But as written, I don't want to rule out my stupidity for this yet.
Tomorrow maybe.
I always get NT plus 4 random character.
Same issue here. For decoding I used a saleae Logic Pro 8.
- Sampling Rate 500 MS/s
- Duration 60 s
I made some screeshots.
Correctly, I get "N" and "T" like on my Siglent SDS2000X Plus decoder. As an example, I find the "E" only in the random part.
I always get NT plus 4 random character.
Same issue here. For decoding I used a saleae Logic Pro 8.
- Sampling Rate 500 MS/s
- Duration 60 s
I made some screeshots.
Correctly, I get "N" and "T" like on my Siglent SDS2000X Plus decoder. As an example, I find the "E" only in the random part.
Study your captures.
There are several incorrect waveforms.
I2C is an
Idle High protocol yet the Saleae shows start
and end waveforms all over the place.
Go back to the STB-3 instructions and read each packet consists of 4 parts: W, Ack; header (always Siglent) and a payload of 4 characters.
With display settings we can eliminate the need to display Write and Ack and only the header and payload.
As I2C is Idle High, a falling edge DC trigger plus a packet width of holdoff is an appropriate trigger setting.
You can trigger on Clk or data but Clk is the more correct as we don't have a CS with I2C.
Hi, just test it at work with 2ms holdoff time.
No chance.
Study your captures.
There are several incorrect waveforms.
I2C is an Idle High protocol yet the Saleae shows start and end waveforms all over the place.
Thanks for the explanation. Unfortunately, I didn't make it
.
The 2 ms holdoff time did not work for me either on my Siglent SDS2000X Plus.
I am convinced that my STB-3 is giving an incorrect I2C signal. Randomly I watched a Youtube video (
) where someone is also using the STB-3 and tadaa, same problem (07:18) 0x4E 0x54 0x5F 0xXX 0xXX 0xXX.
Question to the forum: Has anyone - besides tautech
- ever been able to trigger the I2C signal on the STB-3 correctly?
I am convinced that my STB-3 is giving an incorrect I2C signal.
Me too.
I had the time base in the ms range to generate 200 lines and had scrolled through them, it is always the same.
NT_XXXX and nothing else, even if the triggering would be fundamentally wrong, should appear alone by chance also times other values (S,I,G,L,E), it remains however always the same.
Also, my data signal looks different from that of tautech, see comparison picture.
I had written to Siglent 2 days ago, but have not yet received an answer.
Where the question would be anyway, what we do if the signal should actually be wrong.
I am convinced that my STB-3 is giving an incorrect I2C signal.
Me too.
I had the time base in the ms range to generate 200 lines and had scrolled through them, it is always the same.
NT_XXXX and nothing else, even if the triggering would be fundamentally wrong, should appear alone by chance also times other values (S,I,G,L,E), it remains however always the same.
Also, my data signal looks different from that of tautech, see comparison picture.
Also having suspicions about your STB-3 and have asked Defpom if he could check his for us.
I had written to Siglent 2 days ago, but have not yet received an answer.
Where the question would be anyway, what we do if the signal should actually be wrong.
Please keep us informed as if we do have some problem with STB-3 it need be fixed and I'll be following this up with HQ to hopefully get a new flash/FW available for those whose STB-3 are seen to not be working correctly with I2C.
Meanwhile I did some more tests with SDS6000A, SDS1000HD and SDS1104X-E, all of which decoded as I expected.
If I get time I can test over the weekend, I can test on the sds2(5)104x plus, sds1(2)104x-e, sds2(35)102, keysight dsox1(2)104, Micsig 300MHz (forgotten model no.)
If I get time I can test over the weekend, I can test on the sds2(5)104x plus, sds1(2)104x-e, sds2(35)102, keysight dsox1(2)104, Micsig 300MHz (forgotten model no.)
That seems a lot of trouble when just one of your Siglents would indicate if your STB-3 works correctly with 12C.
I sense a decoding video in the making.....
My STB-3 is a pin header version.
My STB-3 is a pin header version.
Well shit.... there goes that theory.
My STB-3 is a pin header version.
Well shit.... there goes that theory.
Yep.
Instead we need find out exactly what versions Martin and mathstudi have.
I think all but the last 4 characters of their SN# will give that info and maybe build dates too.
So let's build a list of those that work as expected and those that don't.
Mine's
JXX170227GAA0010 (RoHS)
The underlined section is what we need.
Yep.
Instead we need find out exactly what versions Martin and mathstudi have.
I think all but the last 4 characters of their SN# will give that info and maybe build dates too.
So let's build a list of those that work as expected and those that don't.
Mine's JXX170227GAA0010 (RoHS)
The underlined section is what we need.
Mine's
JXX170227GAA0146 (RoHS)
I got the pin header version too.
I bought the STB-3 last year in February 2022 from BATRONIX in Germany.
Mine I've bought in 02/2020 from Welectron.
Number will follow when back at home.