@Maxlor: so please let me know exactly what usecase you have in mind. Most guys in this forum probably have 10 different scopes at home, so the ideal crowd to validate and fine-tune our stretch goals (hey the SmartScope would make a great 11th!)
I come to electronics from the digital side of things. I work with events much more often than continuous signals, that means I capture something, then analyze it. Having a scope with a bit of memory allows me to not have the settings perfect the first time but instead pan and zoom a bit. So that offers me more comfort and flexibility, and makes me think less hard about what exactly it is that I need.
I'll give you a concrete example: last week I was working on my wireless sensor node. It runs off a coin cell, and the wireless module does draw a bit more power than what's wise for a coin cell, but it just about works. Because of the large inner resistance of a coin cell, you see very clearly however when the module wakes up and goes to sleep, and when it starts and stops sending, because the battery voltage changes slightly. The goal is then to make the module go back to sleep as quickly as possible.
I'm using SPI to talk to the module. First I send it the data it should transmit, then I poll whether it's done, then I tell it to go back into standby. The whole affair took about 10ms, so I had my scope capture that. Upon noticing the actual wireless transmission takes less than 1ms, I wondered what the module's doing for the other 9ms, so I started looking at the communication a bit more closely to understand how the SPI communication correlates to the module's activities. I learned then for example that there's no point in starting to poll for end-of-transmission immediately, I can let my MCU sleep for 1ms. With a couple of other modifications, I got the module active time down to 4ms.
So what I'm saying here is, it was really helpful to be able to capture 10ms, then be able to zoom into it enough to decipher the 2MHz SPI communication. That'd require about 40kpts per channel. Granted, it could have been done with at least enough resolution to see that SPI communication is going on, and how many bytes are transmitted (2kpts maybe?), the counting and comparing with what the micro sends out, but the task then becomes more difficult and error-prone. Working with a shorter time base to see just parts of the full signal, and thus be able to see the SPI communication more clearly is not that helpful in this case, because you only have a couple of external reference points (module turns on/off, starts/stops sending.) If they are outside of the displayed area, it's much harder to understand whats going on. And again, harder -> more mistakes.
As for the LA part: storing only transitions instead of constant sampling, those 40kpts would come down to... maybe around 1600 transitions on the clock line (100 bytes transmitted)? And I don't think that's a particularly long sequence. With an NFC card reader we were integrating into a project some time ago, you'd have both lengthy setup sequences (with long pauses mandated by the NFC chip) and long data transmission sequences (1KB NFC cards are not uncommon, and the resulting on-wire communication sequence has overhead.) Now, most of that data is probably not interesting, but if you're interested in the end of the sequence (what's the last thing the NFC chip sends before hanging?) you either need some clever triggers or just have a comfortable amount of memory to work with.
I hope that helps illustrate my point of view a bit. I'll be watching those stretch goals
Or maybe the second version. It might be better to ship what you have now, and build a more complex model later, with all the added experience you get from the first run.
Home
Help
Search
Login
Register
