[quote author="alanbur"] The sample sizes are limited - by default you can capture 32 traces at 4k depth - see http://dangerousprototypes.com/forum/in ... 47#msg4447 [/quote] That is true as is made clear in the topic you quote. However, it does not appear that the communications problems are related to incorrect sample sizes. Even with the appropriate bitstream and correct sample size, the communications problems still occur sporadically. I've not sorted out any exact pattern although they do seem to be more frequent with higher sample frequency.
And for whatever reason, the communications problems seem much less frequent on a Mac so it isn't much of an issue for me now that I've got SUMP working on my Mac.
Hi, swissMac- I've not done anything past what you have described to run SUMP. The only other java related configuration I've done is that I have the default JVM set to 32bit. You can do that by running the Java preferences pane and dragging the 32 bit jvm to the top of the list. Here is the java I'm running: java -version java version "1.6.0_17" Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-10M3025) Java HotSpot(TM) Client VM (build 14.3-b01-101, mixed mode) [metapb:FPGA_ROM/test_roms/2.01] scott%
and here is what I get if I run the analyzer.jar (svn version) from the command line: ava -jar analyzer.jar Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 /dev/tty.SerialPort-1 /dev/cu.SerialPort-1 /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem Device Controller found: org.sump.analyzer.devices.FpgaDeviceController /dev/tty.SerialPort-1 /dev/cu.SerialPort-1 /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem Device Controller found: org.sump.analyzer.devices.Hp16500DeviceController Device Controller = FPGA Controller Tool found: org.sump.analyzer.tools.I2CProtocolAnalysis Tool found: org.sump.analyzer.tools.SPIProtocolAnalysis Tool found: org.sump.analyzer.tools.StateAnalysis Tool found: org.sump.analyzer.tools.UARTProtocolAnalysis
I am able to select the capture icon which causes the capture pane to come up and I can then fill in the appropriate fields to select the com port, sample speed and size, trigger options etc and initiate a capture. It all works like it does on Windows. I did get see the same error messages and behavior as you are reporting when I tried to use the sept 09 SUMP. I wonder if there is some difference between different java versions used for compiling the various SUMP versions and different versions of Java on the Mac which are causing the problems? Anyway, the only thing I can suggest to you is that you make sure to try the 32 bit JVM. That is the only thing which I think might be different in what I've done. -Scott
Great! So probably SUMP 0.8 was compiled on Java 1.5. I'm not sure why that version wouldn't work for me on OS X 10.6 but I could never get the sampling panel to come up. Works fine with the newer version. Class files from Java 1.5 should generally work fine with Java 1.6, but in this case I had no luck. Glad that you found a solution but when newer SUMP version come out, you may have the same class version problem so you might still need to learn to compile SUMP on the version of Java that you have. -Scott
Jim- There was a change over between OS X 10.5 and 10.6 where the default version of java changed from 1.5 to 1.6. I'm guessing, from the error message you posted which says "bad version number in class file", that analyzer.jar is compiled under java 1.6 (which has been the standard version for quite a while now). As I recall, it was possible to get a version of java 1.6 from Apple for OS X 10.5 but I think it was 64 bit only and I'm not sure it would solve your problem. Otherwise, you can either upgrade to 10.6 or try to compile SUMP with the version of java that is currently installed on your machine. Also, java 1.6 is only available for Intel Macs I believe. Hope that helps. -Scott
I have SUMP working nicely on OS X 10.6.3 by using the following steps: 1) Copy librxtxSerial.jnilib and RXTXcomm.jar from Arduino18 (or Processing) to /Library/Java/Extensions (Arduino and Processing are Java based apps which use USB serial extensively so they manage to keep RXTX working). 2) Use the version of SUMP from http://www.gadgetfactory.net/gf/project ... r&view=log I didn't have any luck with the sep262008 release of SUMP. 3) I find the easiest way to run SUMP is to simply double click on analyzer.jar. I've tried a number of the OLS features using this version and everything I've tried seems to work fine.
Hi, Jack- Thanks for the clarification. I wasn't trying to be critical and in any case, the problem is partly mine since I missed the appropriate instructions and charged ahead assuming that the options in the SUMP client just worked. I did get 16k8bit_inside loaded and all of the measurements I listed in the first post in this thread now work fine with a 16k sample size. I did have a little problem with the batch file to load the bitstream. At least on my version of Windows XP, 'choice' is not a recognized command. I got around it by just editing the batch file and putting in the appropriate com port in the pump_loader line. I'm not a Windows guy so there may be some obvious way to fix this so that choice works but for now I've got things working. The OLS is really a nice piece of work. Thanks for the help. Scott
I'm using the bitstream as shipped from Seeed. I didn't realize the sample limitations in the current setup. Perhaps there is some documentation for OLS that I missed somewhere? I was just going by the Java client, since I didn't have any other information to hand. If 32 channels at 4K samples is the only thing available as shipped from Seeed, then things make a lot more sense. It sounds from your response that this is a temporary limitation and I'll look forward to new bitstreams that will bring larger samples. Thanks, Scott
I've been trying out my OLS on some simple test cases to learn the software and hardware setup. I' seeing some sort of strange results which vary with sample speed and sample buffer size. For example, I am generating a test signal with a simple Adruino program. The signal is going low for 20uS every 320uS (and is stable according to a Tek DSO I have access to at the moment). If I set the sample buffer size to 16K and try different sampling speeds (with no triggering) I get some weird results: Sampling rate Measured Period Duration of low pulse 1kHz 322 20 exactly correct 10kHz 409 20.8 20kHz 205 10.3 50kHz 82 16.8 100kHz 40 15.2
Much of the time, the trace at 50kHz and 100kHz shows just a continuous high signal. Given the total sample period at 50kHz, there should be at least one pulse caught but instead it is either zero or multiple with the wrong period between them. Similarly at 100kHz. So something strange is going on with the sampling which I don't understand. I've tried different input pins (buffered and unbuffered) and changed the number of channel groups I'm collecting, turned noise filter off and on and still get similar behavior. I've also gotten strange behavior when using triggering modes but I'll save that for another post. Has anyone else seen similar things? Ian suggests that this might be due to problems with the FPGA code. Since I've no experience with FGPA coding, perhaps someone here has some ideas about what is going on?
I'm getting communications errors when trying to capture data with my OLS. It seems mostly to happen with the larger recording sizes (64K and above) but sometimes with smaller sizes. It also seems more common with higher sampling rates (100KHz and higher). The symptom is a dialog box popping up (usually when the progress bar is fully to the right but sometimes part way through) which says Communications Error Error while trying to communicate with the device: ... Make sure the device is: -connected to the specific port
etc etc At this point, even if I try more times and the scan succeeds, no data is displayed. (the traces are displayed but they are all ground). I've tried using lower port speed, reseting the OLS, only capturing one channel, changing the pins I'm using on the OLS (buffered and non-buffered etc) and trying a different computer. But I'm still getting this behavior pretty often. I've mainly been using a Windows XP SP3 machine although I've tried a Windows 2000 machine as well. Any ideas what is going on?
