Hi,
I’m using my PCSU1000 a lot, if not always, to measure I2C communication.
It would be extremely handy if I could indicate the ACK pulse in another colour than red or blue (current default colours for the scope channels). So, the first 8 clocks could be the default blue or red colour, the 9th clock pulse should be another colour, so that it catches the eye.
Currently, I always have to count the number of clocks to see where the ACK is located, but if you have a bunch of I2C data this is a very error prone approach…
Anyone any idea:
[ul]
[li]if such addidtion already exists[/li]
[li]if not, how to create such addidtion[/li][/ul]
Any help/input/ideas very much welcome.
–
Best rgds,
–Geert
Thank you for the suggestion.
This is interesting feature but I’m sorry it is very difficult to implement to the current software.
Can you use the PCSU1000’s Delay option ‘Delay by Events’ to locate the 9th clock pulse of interest?
The trigger horizontal position mark will show the position of the 9th clock pulse.
You can use the ‘Delay by Events’ in ‘Single’ run mode mainly.
For more details please see Help -> Contents -> Controls -> Delay -> Delay by Events.
Will try this and let you know the outcome of it.
Best rgds,
–Geert
[quote=“VEL255”]Thank you for the suggestion.
This is interesting feature but I’m sorry it is very difficult to implement to the current software.
Can you use the PCSU1000’s Delay option ‘Delay by Events’ to locate the 9th clock pulse of interest?
The trigger horizontal position mark will show the position of the 9th clock pulse.
You can use the ‘Delay by Events’ in ‘Single’ run mode mainly.
For more details please see Help -> Contents -> Controls -> Delay -> Delay by Events.[/quote]
Tried your option, but as expected, it only is useful for the first I2C byte passing by. So, that doesn’t really help if you have a bunch of bytes during an I2C communication session with a device.
You said “with the current software” it’s next to impossible to implement. Does this mean it’ll be taken into account for one of the next SW releases?
Best rgds,
–Geert
[quote]Tried your option, but as expected, it only is useful for the first I2C byte passing by. So, that doesn’t really help if you have a bunch of bytes during an I2C communication session with a device.[/quote]OK, I see.
Is it possible to locate the next ACKs by using the delay multiple of 9 ?
[quote]You said “with the current software” it’s next to impossible to implement. Does this mean it’ll be taken into account for one of the next SW releases?[/quote] This possibility can be considered. - Anyhow, I think this feature is very difficult to implement to the software.
That is indeed possible. A bit “strange” at first since you have to add each time 9 units to the number of delayed events, depending on the I2C byte you want to observe, but that might be a workaround for now.
That’s a pity…
Ideally, you could try to make a kind of “2 channel logic analyser” from the digital scope, where you could switch from “analogue” waveforms (for the situations/cases where you really want to see what’s the shape of the I2C clock and data pulses) to “digital” waveforms, as can be seen on a logic analyser. I think it would be easier then to implement the above in the “logic analyser” mode.
You could make it such that, by pressing an additional “button”, you switch easily from “analogue” to “analyser” mode…
Once you succeed in this attempt (for the I2C protocol), then the road is open to make the same for other protocols…
Just a hint, to make the software/scope even more attractive…
Best rgds,
–Geert
[quote]You could make it such that, by pressing an additional “button”, you switch easily from “analogue” to “analyser” mode…
Once you succeed in this attempt (for the I2C protocol), then the road is open to make the same for other protocols…
Just a hint, to make the software/scope even more attractive…[/quote]Thank you for sharing your thoughts.
Your suggestions are highly appreciated.
If they are feasible they will definitely be taken in consideration to be added to the next updates…