Something is working

I wouldn't be impressed if somebody fixed my car this way, but lo and behold, a little progress at last. I got completely lost up my own problem looking at the output from usbmon. I gave up on javax.usb in the end - it wasn't the right tool for my job. Some of the driver examples look impressive, so beyond the difficulty in installing it, I'm looking forward to using javax.usb again in the future. I don't need a driver though, I just want to check that the drivers I have are working correctly. By the time I'd written a java utility to parse the contents of /proc/bus/usb/devices (what devices are connected to my Linux system) and /sys/kernel/debug/usbmon/*t, I'd more or less got the hang of reading the text contents by eye. Well enough to see that my GW Instek GDS-2062 wasn't making complete replies to commands to its serial port.

I didn't know what to do after that, so I looked again at the driver issue. When I connect the oscilloscope to the Linux system, it's 'recognised' as a USB modem. Perhaps this is a fault of the oscilloscope's vendor and product ids being set incorrectly? So I used rmmod to remove the cdc_acm module and modprobe to load the usbserial module, specifying the scope's vendor and product ids on the command line. I did it slightly differently this time, specifying that the ids were in hexadecimal format:

modprobe usbserial vendor=0x0558 product=0x2009

Coupled with a change to the way I'm reading the (USB) serial port from my Java scope utility, it all seems to mostly work. At least well enough for me to get back to my original problem, which was the C2 communications between Silicon Laboratories' IDE and their prototype boards. I'm trying to get the C2 programming facility hosted by one of their microcontrollers (so one micro can program another). The change I made to the Java code was a reversion to some older code that waited around too long (in my opinion) for the remote system to finish sending data. Either the change of USB driver, or the extra delays in the Java program have made the previous problem (truncated replies and scope lock-ups) go away. I'm making hay while the sun shines. If the problem rears its head again, I'll try to take better notes as I go along, so I can deduce what the solution really is.

I've got some dread lurgy on my scalp and in my ears at the moment. Yes, I do wash. It's making it difficult to concentrate, so I'm giving up for today after posting my first successes with the Java utility. Can I attach an archive to a post? It doesn't look like it, perhaps I'll post it elsewhere on the web. If you're really desperate, reply this blog, and I'll send it to you.

Java scope utility

On my desk I have a Linux desktop that I do most of my work on. Next to it I have a notebook running Windows. I don't want to use Windows, but at the moment I don't have an alternative for flashing the Silicon Laboratories microcontroller prototype boards I have. There is the ec2drv project at sourceforge, but I don't want to use the Silicon Labs debug adapter for my project. Not because there's something wrong with it, I think the adapter and the prototype boards are good products at good prices, but it's just not appropriate for my design. So I'm stuck with Silicon Labs' IDE for now. All my programming and compiling is done on linux, using SDCC.

After following the C2 application note from Silicon Labs, my boards gave no sign that flashing was going to work. Looking at the oscilloscope traces, the code on the board sending the C2 commands seemed to be right. Checking against the Silabs IDE, well, that's not so easy. A lot of traffic goes between the IDE and the target board, for even simple jobs such as resetting the system. My oscilloscope, full of natty features, a great price, doesn't work very well. A pity, it looks like it could, with a bit of firmware programming effort. So I wrote a Java utility to help me out. It's quite useful already - I don't have to get up! The scope is almost a metre away from where I sit, so I could lean over and with a bit of reaching, hit the Run/Stop button. But it's right next to the 'Auto Set' button, which should do something useful, but it appears to me to just completely randomise all settings. The scope works well enough to tell me that the 'reset' button in the IDE does quite a bit more than just pull the C2K line low.

The trace is imported from the scope, and is a fairly good likeness, except that you can see more of the sample buffer. The big red box in the middle is a select box I've drawn with the pointer. Right-click on it, and I've added a 'Read C2' option that converts the two waveforms to C2 commands. The program's output for this waveform is:

RESET
C2Reader: WA02WD02WD04

The reset is obvious, but the IDE software then writes address 0x02 (the flash programming control), then writes data 0x02, 0x04. I'm basing what follows on an assumption: that these codes are the ones referred to in AN127 "Flash programming via the C2 interface" as the key codes that enable C2 flash programming. They're different codes from those in AN127. But why do I have to do all this to find that out? I'll search silabs.com again to see if there's a misleadingly named application note wich tells me what I really, really want to know. I'm resisting the urge to shout. Good, aren't I?

It takes a bit of fiddling about to get the right time scale and offset for the scope to deliver useful samples for reading C2 commands. They're delivered very fast from the debug adapter. Too fast for a snoop program to run on the microcontroller (tried that). Using the Java utility though, I can set the time scale / offset, sample memory length and run/stop mode from my chair. How useful is that! I'd better go and do some exercise to make up for it.

javax.usb

One day I'll work out whether a lot of my problems aren't coming from having something non-standard about my desktop PC that means a lot of downloaded software doesn't do quite what it says on the label. Once I got everything installed from this package, I couldn't get past a very annoying bug:

javax.usb.UsbException: Properties file javax.usb.properties not found

The javax.usb.properties file was in my java install directory, located under jre/lib/ext. The very terse instructions that are available for javax.usb tell you the properties file must be in the CLASSPATH. As I got more desperate, I coped javax.usb.properties to every java-related directory I could think of. There must have been 20 copies of the file by the time I gave up. Still the same problem. The problem manifests itself when the UsbHostManager class does its initial setup, in the setupProperties method:

InputStream i = ClassLoader.getSystemResourceAsStream(JAVAX_USB_PROPERTIES_FILE);

The javax.usb classes are all loaded from a jar file located in jre/lib/ext, and putting the javax.usb.properties file in the same jar file solved the problem for me. You can do it with "jar -uvf jsr80.jar -C /path/to/properties/file javax.usb.properties". The -C takes care of the path to the properties file. Without the -C option, javax.usb.properties is added to the jar file but includes the path information on your system.

Back to work. Well, back to trying to work out why my tools don't work!

USB monitoring on Linux

I am dying. The Java utility for viewing waveforms from my GW Instek GDS-2062 oscilloscope is coming along nicely. One of the nice things I can do now is to change the settings on the scope by clicking on the utility on my PC monitor. There's a proprietary flash-writing program on my laptop, connected via USB serial to some Silicon Labs' prototyping boards. I want to write my own re-flashing code, to run on the microcontroller, rather than on a PC. It's not working. The available examples don't work. Code written to the instructions in the manual doesn't work. I have a proprietary program that does work though, so I want to see how it does it.

The oscilloscope's firmware could be better. The manufacturer has alluded to an update, but a release eludes them. I could piece together pictures captured with their freewave utility, but that stopped working a couple of weeks ago. That method is painful because the scope's support for zooming and panning along the sample memory is broken. Instek does provide a programming guide for the oscilloscope's serial port command language. I used that to write the Java utility, coupled with the RXTX serial communications software for Java. It works sometimes, and sometimes it doesn't. Sometimes when it doesn't it appears that the scope makes a truncated reply. At least, that's what appears to happen from the desktop end. But does it really? Sometimes the oscilloscope locks up when this bug appears, and needs to be switched off and back on again. Sometimes it doesn't and appears to work normally.

I want to know exactly where the communication goes wrong. Since the PC and oscilloscope are connected by a USB lead, the best thing to do is to look at the USB traffic. I found a site that explains it: http://www.mail-archive.com/synce-devel@lists.sourceforge.net/msg00254.html
There's a recommendation to look at the documentation distributed with the Linux kernel for the usb monitoring code. You have to build a debug kernel to do what follows, so none of this will work on 'normal' kernels. That's got to be a good thing from the security point of view. If you're debugging hardware and drivers, rebuilding a kernel and rebooting probably isn't going to hurt you. That much. The output of the usbmon code is available as a plain text file. Nice! But it isn't exactly 'readable'. For that a couple of utilities are mentioned in the kernel documentation, usbdump and USBmon. usbdump doesn't seem to exist. I can see mail on mailing lists where people seem to be suggesting they're about to write it, but I can't find the actual software anywhere. USBmon was easier to find. Wouldn't compile. It looked like it might have compiled once, but the names of classes and files were ... odd.

I've been here before! Nothing works! Well, I'll try writing my own code to make the USB traffic a little more readable, and see if I can't pin down my serial comms woes a little better. Rather than try parsing the /proc/bus/usb/devices file myself, I downloaded the javax.usb software from http://javax-usb.org The install wasn't entirely straightforward, I still ended up editing a Makefile.

That might be my lot for today. It's looking quite cool outside this evening, must be under 30C. Time for me and the daughter to take a stroll. We're on the flight path for KLIA, and there's a lot of traffic in the late evening. She loves to point at the planes (so low you can see the windows sometimes!) and run after them, pointing and shouting "Ohhhhhhhh". She's 16 months old. I'd like to do the same thing, I'm 16 too (in base 34). More later.

Kubuntu 0 Windows 1 (Skype stops play)

After the DNS problem was laid to rest, kubuntu really did work like it promised to. Installing new programs was a breeze! The package maintainers have done a great job of ensuring newly added programs are integrated into the rest of the desktop. Some stuff that I miss from time to time in Slackware, such as a file window popping up when I plug in my USB drive, and being able to browse the shared folders on other machines on the network straight out of the box, was very exciting. I showed my wife. She said "where's skype?". I hadn't yet installed it. I looked at our so-cheap-you-couldn't-turn-it-down webcam and had a bad feeling. It's unbranded. One person had enquired in a web forum, just once, about it and got a very snotty answer from the package maintainer. Without naming names, I suspect the maintainer was not the originator of the software. It was a reasonable request from the webcam owner, and I reckon if he'd asked the bloke who writes the software for webcams like his, he'd have got a very different answer.

Anyway. No Linux support for that webcam. "Write some!" I hear you all advise. Well, I started. And then I stopped. The code looked straightforward enough to modify. After I'd made a couple of changes, I could see that Linux was 'recognising' the webcam, and it looked a small matter of ... oh wait. I'd have to plug the webcam into a PC running Windows and snoop the USB messages. And if that worked, then I could use some open source software to video chat with anybody who... uses... open... source... video... chat... software. Starting to get the picture? Skype for Linux doesn't do video! And there's little promise of it from their website. My wife was very generous. She discussed it with me quite rationally for ooh, minutes. It must have been clear to her how clear it was to me exactly how long she was going to tolerate the excursion into Linux. Ah. There we are: "To begin, click your username". The end of the adventure. Now where are all those shiny CDs of proprietary drivers?

DNS woes

This is nothing to do with kubuntu. I was having the problem with Adept package manager waiting for lists again. Patience ran out, so I thought I'd enter the IP addresses for security.ubuntu.com and my.archive.ubuntu.com directly into /etc/hosts. Thinking slackware didn't have the problem, I pinged those servers from a PC running slackware. I got 1.0.0.0 back as an address. Hmmm. Using telnet to connect direct to the router, a ping from there gives me the correct address. So what's going on? Editing the IP addresses of the servers direct into /etc/hosts means DNS won't be used at all. It's not a fix, just another workaround.

Can we rule out IPv6 now? It's not compiled into the Slackware kernel I'm using, and not loaded as a module. It seems intermittent too. I haven't changed anything on my Slackware PC, and now a ping to those servers works. I give up. The workarounds will work. One day, if I'm really, really bored, I might look at this problem again.

Kubuntu cheering up nicely

I would have greatly preferred kubuntu to just work straight out of the box. It didn't. At the moment, it's sitting there, looking pretty and installing new software (ekiga), courtesy of the 'Adept' package manager. To be fair to kubuntu, a very great number of people complaining online about the DNS resolution to 1.0.0.0 issue appear to have the same ADSL router as me. A D-link DSL-G604T. After reading all the comments, I'm still not convinced who to blame. Some blame it on incorrectly used IPv6 on the PC, or incorrectly handled IPv6 at the router. My Slackware machines work a treat with my router, but I habitually download the latest kernel from www.kernel.org and build it myself without IPv6. A great number of the workarounds for this problem require edits to the kubuntu system files. I don't think that's right: If it was really kubuntu's fault, I'm sure the maintainers would do that to the distribution. The workaround I'm using now is to turn off DNS relay on the router, and to manually set my ISP's DNS nameservers. That's not right either. I'm relying now on my ISP not changing the IP address of their DNS equipment.

Everything seems to be working just fine for now. It's a lingering disappointment though. I think perhaps I had this problem once with my Slackware installations here, but Windows never presented this problem. I suspect a great many Slackware users build their own kernels, it feels like 'the right thing to do' with Slackware. My expectation for kubuntu is that somebody has already taken care of selecting the best mix of software, and that I don't have to maintain it. Since kubuntu is on my wife's PC, any suggestion that I'm 'fixing' it will swiftly lead to its replacement with Windows. More later, I expect.

Later Edit: That change to the router didn't help. It must have just coincided with something else I was doing on the PC. The adept package manager is still 'waiting for headers 0%', unless I open a console and ping the security.ubuntu.com and my.archive.ubuntu.com servers. Or maybe that's a coincidence too. Aaarg!

Kubuntu woes

I downloaded the firmware for my router. Unpacked it. It's the same as the firmware already installed. Bugger - why can't they (d-link) provide the version of the firmware on the download page? Aaaarg! Well, that won't be a solution. But then, I don't really know what the problem is. This forum suggests it's an IPv6 issue. After following the destructions to turn the IPv6 module off, rebooting a couple of times (there was an extra alias...) it appeared IPv6 was no longer loaded. But it had no positive effect on the problem! In desperation, I followed the workaround: added my ISP's nameservers to /etc/resolv.conf, which worked. It's sitting there now, doing a apt-get dist-upgrade. It says it'll be 6 hours. That's no bad thing, I should be getting some work done.

Kubuntu

We have a PC here that's been recently rejuvenated with a new motherboard, power supply, 1GB memory, a Pentium D, and most recently a SATA hard disk. The case is looking decidedly scruffy, but still perfectly functional. The on-off switch recently fell out, it had been sticking a bit, but it has since succumbed to fatigue and gone the way of most old plastic. Poking your finger into the hole in the front of the case doesn't feel very high tech, but it works, and there's no danger. Anyway. I'm not convinced it ever had a pukka copy of Windows on it. My wife bought it donkey's years ago. It had Windows 98 on it when I first saw it. Recently it's been running a copy of XP Professional that a shop gave me. Yes! Gave me. In Malaysia, computer shops "don't sell software". That's what the shop told me. I suspect if I hadn't just bought a lot of hardware too, they might have charged me a few ringgit.

The PC has been slow / failing to shut down recently. I suspect one of the hard disks is failing, but not sure how that causes the symptom. The new SATA disk was bought for a fresh installation of ... something. I'm fed up with pirated Windows software - keeping it up to date seems like a good idea, and the Windows Genuine Advantage program worked for us: we decided if we wanted to use Windows, we'd buy it. So we looked at the price, and decided we didn't want it that much. I use slackware on my desktop and laptop, but impress no-one with my choice of xdm (What? I just want to type in my username and password - what do I need pictures and animated menus for?), and icewm with a black desktop. It works, and it's fast. OK, so sometimes I spend a lot of time editing text files to get things working. For me, it's not an issue - most of my jobs have been like that! My wife wants something that JustWorks(TM), so I had a look for a Linux that JustWorks(TM).

Searching the net brought me to Kubuntu so I downloaded the install CD ISO, and started this morning. It's mid afternoon now and I'm not happy. This morning, I was dancing for joy. So pretty! And quick. The install CD boots to a fully working Kubuntu system without actually installing. Install is a shiny big icon on the lovely desktop that gave me a peaceful feeling. The installation is swift too, and there was very little for me to do, beyond selecting a time zone. There was a "scanning the mirror" message at one point that really didn't seem to be doing much. That prompted a web search, and lots of other people had been annoyed by it too. I waited it out, and it finally went away and appeared to complete successfully. Oh, one annoyance was a badly laid out partition editing dialog. Some of the controls were obscured by other controls. I should have taken a picture, obviously.

It doesn't work!

Then the pain started. I just wanted to install firefox. I like it. My wife likes it. Could I? No. The software updating / management feature of kubuntu (one of the reasons I chose it) didn't work. It was nice, said I had some sort of firefox installed at first, but not a complete installation, and I certaily couldn't find any way of starting anything that looked like firefox. I could delete the bits that were there though, that felt like progress, in a funny sort of a way. Kubuntu seems to do a lot for the user. When I stop wanting to do what I want to do and start wanting to do what Kubuntu thinks is the RightThingToDo(TM), then I'll have a much better time I think. I'm blaming Kubuntu now, but as time wore on, I realised I might not be being fair.

I opened a konsole. It looked just like an xterm to me, which struck me as a very good thing. I tried apt-get. It fails, in a similar way to the Adept (!) application that does the same thing, but it told me why. It couldn't fetch whatever these things fetch from one of the places these things fetch whatever they fetch, and it implied the place it was trying to fetch ... from had an IP address of 1.0.0.0. Brilliant! That doesn't look like Kubuntu's problem at all! A quick google, and I could see people were trying acts of desperation like using their ISP's DNS instead of their router's DNS. Madness! DNS works perfectly well on the router - everything else (surfing, pinging) works a treat.

I don't know what the real problem is. I've seen forums where the suggestion is that it's a bad interaction between IPv6 on their PC and the software on their router. I'm off to update the firmware on my router, and if that works, I'll let you know. If it doesn't, well, I'll have to thinmk of something, won't I?

Getting there...

A relatively early night tonight - only 1am as I write this. Still plenty of wrinkles to work out, and only limited data from the scope presented at the moment, but the closing and reopening of the streams from the scope seems to have made a huge difference. Still can't reliably connect to the scope on Windows, but on Linux, I get a 90% success rate at the moment! The scope still locks up, requiring a power cycle, but it's rare enough now to almost (!) forget it. So first views of the Java-presented data from the Instek GDS-2062 (just one click to connect, one click to update).

These are the small (500 points) sample sets. There's about twice as much data visible, compared to the screen on the scope. There appears to be a 'glitch' visible as a spike at the left side of the blue trace. It's repeated in the yellow trace, but more visible when the time/div is decreased. This may be an error in the scope. I'll look into that.

At the moment, the only data displayed are the sample points, the marker (a '1' and a '2') for the offset voltage, and the Volts/div for the two channels. It's easy to add the rest of the data, expect an update soon.

And here is the actual oscilloscope. See? Only half the samples visible.

Instek oscilloscope, RXTX, USB serial woes

Lost a day to trying to debug the serial receive logic in the Linux kernel. Hadn't tried that before, but have to say that inserting

printk(KERN_DEBUG "Handy debug message here\n");

throughout the serial and tty code was an easier than expected experience. I'd read people saying that before, but didn't really believe them. You really can just edit the kernel source, insert your debugging code (caveat haxor!) rebuild, reboot, and see what goes on in a live kernel by looking in /var/log/debug. After doing a lot of debug message inserting, rebooting my PC and that pesky oscilloscope many, many times and reading a lot of debug messages, I reckon I don't know what the problem is. I'm fairly certain that the problem is not with the PC, but with the oscilloscope.

Freewave and Portmon

Freewave, the software that can be used with the scope, mysteriously started working again. The meaningless dialog box (that meant the software tried to do something that it shouldn't) has gone away, so I tried fetching a large sample set from the scope again. This time, I downloaded Portmon from Microsoft. I wish I'd done this at the start. Oh yeah, I remember, this all started when Freewave mysteriously stopped. Anyway, Portmon tells me that the Freewave software doesn't just send a series of commands to the scope, it seems to reset the serial port after each command, and follow it up with two 'purge's. To be sure to be sure, obviously. In fact, there are three purges after each command. I'm not sure what effect these will have on the scope - after all, only rx, tx and gnd are connected at the port. The RXTX package stays fairly faithful to the Java Stream definitions, so I'll try some close()-open()s and a flush or two. If it all goes a bit stable, I'll post the code and a picture or two,

ttyACM0

Something that caught me out badly a few times was ttyACM0, the device file for the scope's USB connection, being created with 660 permissions, owned by root.root. I edited my udev.rules file, found under /etc/udev, to fix this issue. I'd be more explicit about it, but I'm not convinced I did it perfectly! I must read up about udev one day.

Better get this code tidied up, post a final message, and get back to some proper work!

RXTX serial port pain

The failure of the USB serial ports to work is puzzling. I've used them lots of times before with other serial devices, and they've been fine. What's the issue? There's nothing wrong with the lead. The last remaining non-USB serial port in my house is on my desktop. A null modem lead from the USB serial port connected to this port, and a minicom on either port proves that messages are delivered correctly.

Uh? It works. OK, I'll try that again. I could cry. I have a minirc.usb0 in /etc, so I can start 'minicom usb0' for another serial device (my phone, I think). Starting minicom this way, and changing the bps to 38400 from 9600, I can communicate with the scope. Starting minicom with no rc file (it uses the default minirc.dfl), the port settings are /dev/modem 38400,N,8,1 with no flow control. The only thing I appear to need to change is the port. Changing the port to /dev/ttyUSB0, so that all settings appear to match, I can't communicate with the scope. With the null modem lead between the two ports, I see the data is garbled.

Again, more carefully... Null modem between USB serial and built in serial. Minicom on one terminal, minicom usb0 on the other. Change the bps to match, and it works. Minicom (/dev/modem) on one terminal, change the port to ttyUSB0, minicom won't start in another xterm: /dev/modem is locked. Not another bug! I'll try updating to latest (2.2) minicom, mine is 2.1. The minicom project is at http://alioth.debian.org/projects/minicom/

Hmmm...same problem. Looking at the code (my eye sockets are starting to bleed), it doesn't seem to re-initialise the port after the user selects a new serial device. The lock remains on the port minicom originally started with. The code does look awfully neat and tidy though, so I'm not keen to edit it. Saving the new settings, exiting minicom and invoking it as 'minicom usb0' (for example) seems to work a treat. Something to remember, while I forget the rest.

Scope software

Back to that software. With a null modem lead between the GDS-2062 and the USB serial port, and trying to acquire a 12,500 point waveform, it seems the read of the InputStream stops at 4,095 bytes. Interesting number! There should be 25,014 bytes in this message. There's no further reply from the scope. Trying to toggle between USB and RS232 on the scope settings results in the scope locking up, necessitating a power cycle. I don't understand why the scope is bothered - there's no flow control on the port (only rx, tx and gnd are connected, according to the user guide).

I use a java.io.BufferedInputStream to get bytes from the serial port. A quick glance at the web tells me the default buffer size in BufferedInputStream is 2048 bytes. I use BufferedInputStream to wrap the InputStream obtained from RXTX's SerialPort object. The InputStream Object is a RXTXPort$SerialInputStream, which has no buffer, but wraps the native functionality. My code loops around after issuing a command to the scope, sleeping and polling the InputStream's available() method until the whole message has been returned. The RXTXPort's available method is a wrapper for a nativeavailable function, which in turn calls ioctl(fd, FIORDCHK, 0). Ooh, that's deep.

Checking again, I notice that using minicom to retrieve the long sample memory also fails. It's not minicom's fault. Trying 'cat /dev/ttyS0' on one terminal, and 'echo "acq1:mem?" > /dev/ttyS0' on another, also fails. It seems like a few thousand characters in minicom. I tried 'cat /dev/ttyS0 | hexdump -C' and this tells me I get over 11,000 characters. That's more than the java code reports, but still short of the expected 25,000. Interestingly, I get 4,096 characters again if I use 'hexdump -C < /dev/ttyS0'. Is it just down to the serial port's buffer not being emptied fast enough? How big is the serial port's buffer?

RXTX Bug

A very, very small bug. I've never actually felt fired up enough to fix some open source code. Not good enough really, I use open source stuff by preference. I've sent money to some projects I've felt particularly grateful to, but not enough money and not enough projects to stop me feeling slightly guilty! What's the problem? I want RXTX to recognise my USB serial (or is it a modem?) device on ttyACM0. The advice in the documentation is to put an entry in gnu.io.rxtx.properties to tell RXTX which unusual ports you want. I did that, and got nowhere. I recompiled the code (Hooray for Open Source!) with the debug flag on, and got this:

The file: gnu.io.rxtx.properties doesn't exists.
java.io.FileNotFoundException: /usr/local/java/jre/lib/ext:/usr/java/packages/lib/ext/gnu.io.rxtx.properties (No such file or directory)

I'm so happy I could jump for joy - an easy bug! Looks like the code is appending the filename to a colon-separated list of paths, instead of to each path in the list in turn. Ooh, now that I look at it... maybe too many people have edited this code... it's a bit confused. The gnu.io.rxtx.properties file contains some handy properties, but the code replaces the entire System properties with the one or two in the file. That can't be right. There's even a comment at the head of the ChangeLog for 2.1-7pre22 that says not to overwrite System properties.

I just want to get the piece of code I'm interested in working. Doing anything else strikes me as rude, so I'll press on. The fix is to just extract the necessary data from the properties files - note that there could be more than one, thanks to the previous change.

It's getting worse!

OK, so I made the initial change to make sure those properties were being read properly. Now there's a function in the native library 'testRead' that says ttyACM0 fails. In some way. So I want to add some debug comments to that C code. But RXTX 2.1-7r2 doesn't build properly! When you extract the tarball, it won't make:

make: *** No rule to make target `i686-pc-linux-gnu/librxtxSerial.la', needed by `all'. Stop.

I don't know why!
But it's okay, I was just doing the usual ./configure, make, make install process. The problem goes away if, with a freshly extracted source, you:

aclocal
./autogen.sh
./configure
make
make install

make install fails at this point with the error:

libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory

Again, who knows why. I do know that the error is caused by the absence of a value being assigned to RXTX_PATH in Makefile. Editing Makefile, and editing the line so it assigns RXTX_PATH to the path to where the JRE's ext libraries are kept will allow make install to finish. For me, it's:

RXTX_PATH = /usr/local/java/jre/lib/i386/

Phew! I can finally compile and install all my changes. There's another problem in the Makefile that causes (on my system) the newly created RXTXComm.jar file to end up in the '/' directory. Locate and change the JHOME assignment to something useful for your system. For me it's:

JHOME = /usr/local/java/jre/lib/ext/

Such a slow process. Now it's my bedtime. testRead is rejecting /dev/ttyACM0 at the same place it rejects all the other non-connected devices:

do {
fd=OPEN ( name, O_RDWR | O_NOCTTY | O_NONBLOCK );
} while ( fd < errno="=" ret =" JNI_FALSE;">

The same code accepts /dev/ttyUSB0 - the only serial port connected to my laptop. But I can't establish a connection to the scope over the USB serial lead. My head hurts. One last try, USB serial from Windows. Nada. Serial works fine from the desktop, so it's a USB serial issue. Too tired to think.
Night!

That oscilloscope software

Will now plot the two waveforms from the scope in a window. It'll discover the scope by searching ports. But it's having trouble acquiring a 'long' memory from the scope. There are 2 options on this scope, a short (500 samples) memory and a long (12,500 or 25000) memory. The communication between the PC and the scope is by short message and (potentially long) reply. There's an RS232 port and a USB host socket on the scope. The reply that contains the sample memory is one long string, with the sample data presented as pairs of bytes. For the short memory, the message is just over 1,000 bytes long. The long message is around 25,000 or 50,000 bytes long! At least, it should be. My program only gets the first part of the message.

I tested the scope's reply against HyperTerminal on win and minicom from Linux, and there does seem to be an issue with a truncated reply. I'm not convinced it's the fault of the scope, but most of the times it happens, the scope locks up, requiring a power cycle to make it usable again. I must check again, but either the null modem cable between serial ports, or the USB A-B cable and HyperTerminal does allow a full 12,500 sample reply to be acquired. The USB connection is a bit odd. The VendorId is 0558, allocated to Truevision Inc in the Linux USB ID list. The Instek setup.inf has the same vendor id and a product id of 2009, and simply registers the scope as a USB serial device. In desperation, I had a look inside the scope. It seems surprisingly well built! The USB host socket connects to a Philips ISP1362 USB On-The-Go controller, so I'm guessing whatever OS is running on the nearby BlackFin processor is repsonsible for those Vendor and Product IDs.

I was having no luck with the long sample memory reply on my Linux desktop at all. Truncated every time, at around 1,000 characters - 24,000 short! I was using

modprobe usbserial vendor=VVVV product=PPPP

to get the scope to be recognised as /dev/ttyUSB0. I tried on my laptop - it has a slightly different Linux setup on it - and the scope was recognised as /dev/ttyACM0 - a USB modem (supported by the cdc-acm module). I've had a couple of limited successes with this method, so I'm bringing both laptop and desktop up to the same software revisions. RXTX is giving me a problem though: it has a problem opening the handy gnu.io.rxtx.properties file, due to a (real!) bug. I'll sort that out, try sending a patch off to the developers, and see how I get on from there.

It's not looking very encouraging at the moment, I'm hoping for a piece of software anybody could just download and start using, whether on Windows or Linux (no means to check anything else), and it has been a bloodbath so far. Well, a nosebleed, at least. More later!

GW INSTEK GDS-2062

I bought this oscilloscope only recently. The list of features were excellent, and it cost about half what an equivalent scope would have cost from another manufacturer. I wish I had paid more. Don't get me wrong, it has lots and lots of cool features. When I calibrate the two channels, and attach the probes to the same ground and DC voltage, the scope reports values that differ by 10% between the 2 channels. The firmware appears to be not completely finished. It took me some frustrating days to work out that the 'menu off' button that restores the scope display doesn't work when the scope is 'STOP'ped. It has a sample memory longer than the section presented on the display. It has a cool 'window' bar to tell you how much of the sampled memory you're currently looking at. You would expect the horizontal /div and position controls to allow you to see the rest of the sample memory. They don't. It has completely locked up on me a few times, necessitating a power off and back on.

Emails to the company, and enquiries placed via their web form go unanswered. A representative from their US operation did once reply to say there would be updated firmware available in February. There isn't, in March. But hey, my own deadlines can be quite flexible. I am at least convinced that one day, they might release some updated firmware that might even be an improvement.

I did briefly enjoy using their Freeview software for a while. To overcome the problem with not being able to look at the full sample memory, I repeatedly triggered the scope against the same high-speed (~10MHz) digital event, each time advancing the trigger by a few microseconds. Each time I did that, I used Freevew to capture an image of the scope screen and then used the GIMP (marvellous, everybody should download it) to stitch the images together into one big image. Then I could read the content of the mysterious message. This is extremely laborious, but it worked. What I saved in the price of the scope, I lost in time. Recently though, the Freeview software just stopped working. WTF? It's a MS-Win based program, so when it stopped working, it told me with a little dialog. I don't know what the dialog was telling me - it was one of those win dialogs that have no understandable content, but you know, deep down inside, that this software is never going to work ever again, unless you reinstall your system and make several other things worse in the process.

So I've been writing a Java utility to display the waveforms. I'll post it somewhere when it's done. It will at least give me a choice of systems to connect my scope to. I end up transferring all the data from the Win XP software on my laptop back to my Linux desktop to work on it, I'd rather just use Linux on the laptop. In case you're wondering how it's going... well! Well, a little bit slowly. I'm using a null modem RS232 lead at the moment, and the gnu.io serial port classes from rxtx.org

Better get back to it, fixing the tools is easier than getting my work done, but it won't pay the rent!