I've both devices, a Bus Pirate and an OLS.
In order to test (me and the OLS) and to understand the right parameters for the Sump client, I'm using the signal generation of the BP (1Khz-50%).
I monitor it with a real scope, no problem signal is delivered.
Then I'm trying (expecting) to have the trace in a Sump capture.
As it is a single basic signal input it should be simple.
That's not the case. I've a lot of glitches and wrong samples on all entries, and whatever the input port used (0-15), I'm not able to trace a 1KHz-50% signal... :(
Questions : what should be the parameters for the Sump capture ? Has anybody done a such basic test ?
Regards
The standard firmware loaded at the factory is set up for 32bit wide samples and 4K buffer size. So you might try something like 10kHz sample rate with those parameters for your 1kHz test signal.
Thank you, but it's not the answer to my question.
In order to clarify I'm providing a little bit more information
First the signal as generated by Bus Pirate (and correctly observed on a scope)
HiZ>g
1KHz-4,000KHz frequency generator/PWM (beta)
Frequency in KHz (50) >
Prescale:8
PR2:39
Duty cycle in % (50) >
PWM active
HiZ>
THis signal output (from BP) is connected to channel 20 (wing) in order to respect the signal voltage (3.3V)
Then, using OLS with a Sump client I get the following result :
(http://http://www.usinages.com/files/thumbs/t_sump_381.jpg)
>>>>
MAGNIFY HERE (http://http://www.usinages.com//files/sump_381.jpg)First remark : I need to select Chanel 4 in order to observe Chanel 20. Curious
More surprising : where are the noisy signals on Chanel 5 coming from ?
If I input to Chanel 16, I read on chanel 0 and I've a noisy input on chanel 1...
If I input to Chanel 17, I read on chanel 1 and I've a noisy input on chanel 0...
If I input to Chanel 18, I read on chanel 2 and I've a noisy input on chanel 3...
etc....
In other words, considering a channel pair (0-1 or 2-3, or 4-5...) I always have a noisy signal on the adjacent chanel...
Can somebody do the same test and tell us what he observes?
Can somebody explain ?
Regards
For the channel 4/20 swap there is a simple explanation: the standard 32-Bit VHDL code assumes channels 0-15 on the I/O header (right side of the board - orientation as shown in the documentation (http://http://dangerousprototypes.com/2010/02/25/prototype-open-logic-sniffer-logic-analyzer-2/)). You connected to channel 20/4 on the wing header (on the bottom side of the board - orientation as shown in the documentation (http://http://dangerousprototypes.com/2010/02/25/prototype-open-logic-sniffer-logic-analyzer-2/)) hence it's channel 20! The I/O header is considered the primary header.
There is no need to connect 3.3V signals to the wing header - the I/O header is 5V (TTL) tolerant so you can connect 3.3V and 5V (TTL) signals to it while
the wing header is max. 3.3V tolerant. Actually the
I/O header should work for input signals (high-state) between 2.0 and 5.5V!
Could you please repeat your test with the test signal connected to channel 4 on the I/O header and check if you get "noise/crosstalk" on the adjacent channel as well? If you get noise/crosstalk, could you connect the adjacent channel pin that shows the noise to one of the GND pins on the I/O header and repeat the test?
As it is a single basic signal input it should be simple.
Please excuse this question as it may sound a bit hillarious to anyone who has some experience with electronics (but then you mention to connect only the PWM signal from the BP to the OLS but no other signal): Do you have a ground connection between the OLS and your test hardware (Bus Pirate in your case) - like a scope GND of an LA needs to be connected to GND of the target.
I have my two prototypes in the office atm - the three pre-order units from Seeed are somewhere stuck in shipping/customs o.O. - so I will not be able to perform tests before later tomorrow and only with the prototypes ...
Thank you for answer.
Understood for wing/normal chanel.
As I'm now trying to "play" with a Bus Pirate and a touch pad, I need time to restart the test according to your requirements.
However
Please excuse this question as it may sound a bit hillarious to anyone who has some experience with electronics (but then you mention to connect only the PWM signal from the BP to the OLS but no other signal): Do you have a ground connection between the OLS and your test hardware (Bus Pirate in your case) - like a scope GND of an LA needs to be connected to GND of the target.
, Yes I can confirm that there is a common ground between all devices, BP, OLS and analog scope... I was just talking of signal chanel. ;)
I'll come back later
Tnks
Coming back... with bad news
Either there is a problem in my OLS, or I've a big misundertsanding in the settings of the Sump client. Or both as a OR rarely exclusive !
I've a lot of signals captured (wrong signals) when I connect the AUX signal (from BP) to chanel 4 (OLS). Or any other chanel ....
The workbench here
(http://http://www.usinages.com/files/thumbs/t_img_0356_520.jpg)
Click here to magnify (http://http://www.usinages.com//files/img_0356_520.jpg)
The Sump results with settings...
(http://http://www.usinages.com/files/thumbs/t_sump_181.jpg)
Click here to magnify (http://http://www.usinages.com//files/sump_181.jpg)
Seems crazy ... if not bugged !
First of all, if I replicate your setup including your SUMP settings, I see the same high frequency glitches on the low channels as you do. It is sort of strange. However I'm not sure what you are expecting to get with this setup. With the default firmware/bitstream the signal you are inputing should show up on channels 16+ and yet you aren't even collecting or triggering on those channels.
If you try changing to triggering on the appropriate channel and collect also those higher channels I find that you get the expected output. Also I would trun off RLE since I don't see the point of using that with a steady 25KHz input signal.
So I don't really know why your settings give such odd results but more appropriate settings seem, for me at least, to give the expected display from SUMP.
RLE only works with 32-channel captures, with everything else it just reports gibberish
RLE only works with 32-channel captures, with everything else it just reports gibberish
Thank you for the info. I'll test w/o RLE