I've started to use a raspberry pi as a computer on my bench (it is small, quiet and cheap). I mainly wanted something to capture and plot data from instruments via GPIB and serial and do some simple browsing and viewing (like viewing assembly diagrams while placing parts). But sort of on a whim, I decided to see if Jawis OLS client would work on the pi. The latest Raspbian distributions have java 1.7 preinstalled so there wasn't much to do except to download and unpack the latest OLS client. In fact, it almost works out of the box. The one issue is that the version of JNA that Jawi packaged with the OLS client didn't include the appropriate JNI shared library for linux-arm. However, the latest JNA builds do. After some fumbling around, I finally understood where the JNA stuff was packaged up in the OLS distribution (it is in plugins/org.rxtx-2.2.0-10.jar). I replaced the JNA code in org.rxtx-2.2.0-10.jar with the contents of jna.jar from https://github.com/twall/jna and repackaged a new org.rxtx-2.2.0-10.jar. OLS 0.9.7 then fires up and seems to run fine. I'm using an early pi with 256M of memory so it takes a little while for OLS to first come up. I suspect that a newer pi with double the memory would be faster. But once it is running, it seems quite usable. All the measurements and markers seem to work and the performance isn't bad with the interactive measurement pane. I tried to capture a simple square wave test signal at 200MHz capture rate and it worked just fine. I also tested the protocol decoders using the Test Device I2C data and that worked fine also. [attachment=1] Overall, it works better than I expected and, in fact, works well enough to actually use in practice. I've attached the new version of org.rxtx-2.2.0-10.jar. If you want to try OLS out on a pi, download and unpack the latest linux version of the OLS client and then unzip org.rxtx-2.2.0-10.jar into the plugins directory. After that, you can just use run.sh to fire it up. I modified run.sh to ask for less memory when java is starting up but I don't know if that really matters or not. -Scott
I've updated to the 2.1 firmware and bitstream and mostly things seem to be working. I've done some simple tests with a pwm signal from a bus pirate and all the inputs seems to capture the correct waveform and timing. However, I'm noticing that the triggering isn't very reliable. I'm trying to trigger on a leading edge (using the simple trigger with 50/50 display) and I'd say about 1/2 to 2/3 of the time the trigger works and the rest of the time, the signal seems to be captured at a random time. I don't see any other problems with the capture. I've tried on both Windows and OS X using the java client included with the 2.1 release. I've tried both the 8bit and 16 bit wide bit streams at various capture rates and various input signal frequencies and see the same problem with triggering in all cases. Is it just me, or do others see problems with triggering also? -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?
