Products > Test Equipment

Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests

<< < (169/206) > >>

Slartibartfast:

--- Quote from: KungFuJosh on November 23, 2023, 07:20:52 pm ---The point being if you know what you're looking at, and familiar with the actual specs of the devices you're comparing, you can make smarter choices.

--- End quote ---

That's useless in the context. The one thing that might help is knowing exactly what you need, and not getting tempted by new features that beforehand were deemed not to be needed. But even then the thought would pop up that the very set of features deemed to be needed may be available cheaper next year. So in addition, you'd need to set a budget, buy, when the features fit into the budget, and better not keep looking at prices.

On the other hand, understanding that a general "right time to buy" doesn't exist provides for the relaxed attitude that allows you to look at future prices without regret.

Cheers  Peter

PS.: Better forget about sales. If you deem your own time to be worth anything, then you'll find that looking out for when the device you want is on sale costs you so much time that in the end you paid more than just paying the normal price. With sales, you just trade in time and effort for a little price reduction.

KungFuJosh:

--- Quote from: Slartibartfast on November 29, 2023, 04:18:56 pm ---PS.: Better forget about sales. If you deem your own time to be worth anything, then you'll find that looking out for when the device you want is on sale costs you so much time that in the end you paid more than just paying the normal price. With sales, you just trade in time and effort for a little price reduction.

--- End quote ---

That depends on whether or not somebody is in a hurry. I wouldn't wait 2 months to save $20. OTOH, if you already have a scope, and you want something better, saving $400 off of a $1400 scope is significant. If you can't wait, you can't wait. Those are different situations. You can't speak for everyone regarding the urgency of their purchase or the specs they require. Pricing is more of a concern for hobbyists/home users than what most corporate budgets care about. But whatever, I'm content with my SDS2504XP. I'd be surprised if I ever need anything better. 🤷

Slartibartfast:
Wondering if this is a bug in the I2C decoder.

The screenshot shows a READ operation of 4 bytes from a standard 2kBit EEPROM, connected by a I2C bus that has somewhat borderline pull-up resistors. Even though being borderline, bus semantics are properly followed, as you can see by close inspection. First we see the dummy write, setting the internal address register to 0. Then, without a STOP, but with a START, a read operation commences. The address (0xA1) is decoded fine, and also the first byte sent by the EEPROM (0xFE). Then, for no apparent reason, the decoder looses sync and fails to decode the following byte (red arrow). Following bytes (green arrow) are decoded wrong, more specifically, they are shifted by one bit. Interestingly, on a following bus operation (not shown in the screenshot), the bits are also shifted in the same way, even though a STOP and a following START condition would have provided the opportunity for the decoder to re-sync.

What do you think? Bug?

Cheers  Peter

PS.: I've added two screenshots. The first one shows the mentioned failure to recognise a STOP/START condition for resynchronisation. The second one shows where it, after loosing sync, suddenly starts decoding a new command, that on the bus would require a START condition (at least), where obviously there is none. The C3 trace shows low-pulses where a ACK/NACK just has been transmitted, and the first bit of the next byte is about to start.

tautech:
Without a CS try adding some Trigger Holdoff.
The packet above is ~200us long, try adding 250-300us to prevent the tigger rearming before the packet is finished.

Slartibartfast:
Why do you think triggering is related to the issue?

From my point of view, there are traces that show signals from a specific time window of 200µs at some instance in time. This acquired data is what the decoder has to work on. Now, it is clear that if the traces would start right in the middle of an ongoing transmission, the decoder has nothing to sync on at the beginning of the trace, but even then it should resynchronise when it sees START or STOP conditions. But even that is not the case. The trace starts at a time when the bus is idle, and consequently the decoder start decoding porperly, and then suddenly looses sync. Later in the trace, the decoded information is inconsistent with the traces. This should not happen.

I completely fail to see any connection to the triggering.

Please note I'm not triggering on a bus event, but use normal edge-type triggering.

Cheers  Peter

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod