Now that I’ve successfully updated to the latest BenF firmware, I’ve very happy with my little 'scope.
I have two requests:
Can the Measurements menu include counting the number of pulses? Perhaps following the trigger direction (positive trigger, positive pulses)?
Also the B button currently toggles the state of the cursor lines. Could this toggle all the lines, or a pair of lines. It’s somewhat tedious to turn off each cursor sequentially.
Thanks!
-Brian
Maybe I can hijack this thread with another request: Would it be possible to enable the fast dual interleaved adc conversion for us V2 users? When I understand correctly, both ADC pins are connected with each other, which would make this mode possible. I would love to get 2 mega samples for ‘free’ 
Greets,
Reini
What would be really sweet would be to have the second channel routed to the unused connector on the audio jack. Then, with a software switch we could have 2 channels @ 1Ms (alternating) or 1 channel @ 2Ms (with an appropriate connector to short the two channel inputs).
-Brian
I’m really surprised they didn’t do this (set up the audio jack as per Brian’s description) in the V2, or even the V1 for that matter. As soon as I looked at the micro-controllers datasheet, it looked like the obvious way to pin it out.
With such a trivial hardware mod, they could have given us 2 x 1Ms channels or 1 x 2Ms. 
Hi DarthKevin,
some of your questions are addressed in another thread (How users can impact hardware…). The problem is hardware related. Although 2 Msps is feasible with the actual hardware (uC), the usable analog bandwidth is FAR from supporting 1 Msps. So in the end you will get a system with more resolution for “low” speed signals. But if you pass a few hundred kHz the signals will start to degrade (A LOT).
What is not feasible is multiplexing inputs (channels) into the same ADC, because the current OA (Operational Amplifier) couldn’t keep the switching pace for sure.
As you can see, not exactly a trivial hardware mod.
Sampling rate != analog bandwith. I can sample a 300 kHz signal with 1 Gsps. In the current setting you can’t distinguish between a 300 kHz square and triangle signal, so you are actually far away from the 500 kHz maximum frequency. I don’t want to view signals > 500 kHz, but want signals with a lower frequency to be measured with a greater sample rate.
Greets,
Reini
you’re right reini. 1 Msps was a typo but i made it that way to indicate that analog bandwidth can’t reach 500 kHz across all gains. So its possible than you can’t resolve a sine from a square of 300 kHz @ 2Msps with some gains.
Yes, I think this might add value to what we have.
This would be somewhat akward to implement as it conflicts with switching individual lines on/off and I’m not sure we want to give up that. As an alternative you can use profiles. Just create one profile for each of your favorite configurations.
[/quote]
This would be somewhat akward to implement as it conflicts with switching individual lines on/off and I’m not sure we want to give up that. As an alternative you can use profiles. Just create one profile for each of your favorite configurations.
[/quote]
I guess I never considered wanting just one line on, as I always consider them in pairs as a measurement.
-Brian
I appreciate your response Slimfish but I still stand by my statement.
Pining out a second A to D port to the stereo jack would have given 2 channels which is useful for all sorts of things even at quite low frequencies like audio.
Running the leads together for 2 Meg samples (well 2 interleaved 857 Ksps) would pretty much double the usable bandwidth in single channel mode and increase the resolution for everything slower.
For people like me who work almost exclusively at 125KHz, we’re just hanging off the end of what’s usable now. Doubling the sample rate would make a big difference (to me) even with the op amp specs exactly as they are. Of course that does NOT mean we can go around scoping 500KHz waves but I don’t think anyone has suggested that it would.
BenF,
While I’m asking for features, can you add a baud rate calculation to the measurements? I understand it would be approximate, but it would have helped quite a bit today.
Thanks,
-Brian
Hi Brian!
What do you really want to know? Why is the baud rate not known? If you want the raw bits per second, can’t you just look at the frequency or estimate it by looking at the length of one 1 or 0?
Looking at the frequency calculation doesn’t work because there will be varying pulse widths depending on the data being sent. I can find a one or zero, measure the width and invert in my head, but it would be quicker for the scope to do it, in the same way that it’s nice for the scope to measure frequency.
In today’s case our system wasn’t talking to a device, and I needed to verify that we were both using the same baud rate. We weren’t, so then I need to find out what the device is talking, so I can adjust our system.
The Nano is perfect for this; I had the information I needed in much less time than tracking down a bench scope and getting a power cord over to the machine.
-Brian
Brian,
Just thinking aloud here but if the Nano grabbed a buffer and then post processed it to look for the baud rate then there is a danger that at any resolution high enough to give good baud rate calculation sensitivity, the sample may be too small to be sure that you’d see a single bit by itself.
[You could never be totally sure anyway of course. Pathological example I know, but a packed stream of 0xF0 chars sent at 48Kbaud is indistinguishable from a packed stream of 0x55 chars at 9600 baud.]
It might be better to only check “normal” baud rates such as whole number divisors of 115200 and do several sweeps.
With the extra code space gcc makes possible, someone enthusiastic could write a nice new mode that automagically monitors the line, decodes not just baud rate but parity and stop bits and displays a comms dump in ASCII and HEX.
Dual trace would be nice for logging RS232 but even a single trace would be fine for RS485 and in practice RS232 would be fine 99% of the time if you used two diodes and a resistor to ground. The number of implementations of RS232 where characters are simultaneously travelling both directions at once is very low.
Come to think of it, for bidirectional RS232 you could build the cable with one signal diode and one red LED in one direction and one signal diode and one blue LED in the other (and of course a resistor to ground). That way, there would be a voltage difference between the two TX drivers and the Nano could tell which direction the data came from. [PLUS there’d be some pretty lights when data arrived!]
That would be pretty cool, but I think we’d be 15 years too late for the market.
This is true, but in general, there’s a usually a couple of minimum pulses in a capture. I’d just check a scan for the smallest pulse and invert. I’m not so worried about an exact calculation, I just want to know at a glance that it’s 38400 instead of 19200.
I would love this; it was one of the first things I thought of when I received the unit. Right now, I have an old PC on a cart that I use when I need a logger. When it dies, I’m out of luck since the SW requires 2 “real” COM ports. Unfortunately, I don’t know when I would ever have time to work on it.
I may still be working with RS232 15 years from now! (gack!)
-Brian
You guys need a logic analyzer – not a scope. With something like this
http://www.seeedstudio.com/depot/open-workbench-logic-sniffer-p-612.html?cPath=61_68
you can look at digital traces (32 channels) of 50Mhz+ waveforms simultaneously with modes for RS-232, I2C, SPI, RS-485 and what not. The Nano can be somewhat useful for basic digital analysis (if nothing else is available), but it really isn’t suitable for this. Rather than a single analog input, we would need multiple digital inputs (these can be sampled much faster) and a different user interface. With a logic analyzer we don’t look at the shape of the signal, but data pulses, clock pulses and relative timing between them.
For someone really motivated it should be possible to sacrifice the SD card support and access 5 digital inputs through the card slot… The kitchen sink next 
For a logic analyzer we would use peripheral DMA to memory and then IO’s should come from the same hardware register (e.g. consecutive bits on PORTE). Then you’re down to 4 bits if using the SD card as a connector. More of an issue though is that these IO’s are shared with the display controller and so can not be wired to a logic probe.
PORTC on the other hand has 7 unused consecutive IO’s - so if you’re heading for the kitchen sink armed with a soldering iron, this is a better choice.
As BenF pointed out to me recently, the lower right context sensitive area of the screen displays the current cursor value. This value can be used to place a cursor in an exact location on the screen. A single cursor line can mark a voltage level on the screen or a time offset-from-trigger on the screen. Any one of these cursor lines can be used to expedite waveform analysis at a glance.