Messages

1

C1000/3x00 General discussions / Zaurus Oscilloscope

« on: July 20, 2008, 06:39:45 pm »

1) Can this DSO do transient analysis even with that tiny 32k sample buffer?  At 20MS/s that's a minuscule slice of time, so on the surface it looks inadequate.  But it very well could work somehow that I'm not aware of, in which case I'd be very, very interested to hear it.

Sorry for this slow reply - I've been distracted by $DAYJOB.

You can't use the DSO-101 for continuous sampling in the sense I think you mean: you'd have to read a 32K sample set, then tell it to go and get another one, and so on. But what does happen is that while it's waiting for a trigger condition, it will be continuously collecting samples and when the trigger occurs you'll have 16K samples from before the trigger, and 16K after it. In other words, that 32K is a circular buffer, and I think that's the key here.

The issue, then, is how to trigger the scope when the crash happens. You say you want to monitor both supply voltage and current, using the two channels. If you're doing that, then the only way to capture the event is to detect the crash, and send a manual trigger command to the scope when it happens. That would mean modifying the software. To go further with that idea, I'd need to know how you detect that a crash has occurred. As an example, though, I don't think it would be hard to modify the software to accept a signal from another program as a trigger command. The difficulty would be that there would be latency involved in such a system.

But if you were prepared to monitor just one of those variables at a time, then you could monitor it on channel A and trigger from channel B in single-shot mode, if channel B could be connected to some source that would act as a crash detector. That would be my favourite solution.

More generally: if you go to the Syscomp website at <a href="hhttp://www.syscompdesign.com/">http://www.syscompdesign.com/</a> and look in the Downloads section, you'll find a link to my software as an ipk file, together with some descriptions. I haven't yet put the source code on there, mainly because I haven't yet got round to documenting the rather complicated build process. But I do confirm that I'm perfectly willing to share it for free. In fact, if you or anyone else wants to work with it, PM me and I'll send the source to you and work with you on the build process. That way, the documentation will get done. The build is a cross-build on a Linux desktop.

Also, I think if you contact Syscomp directly (the email address is on their website), you're likely to receive informed answers to questions related to (and not of course limited to) astronomy.

Obvious disclaimer: Syscomp are not responsible for any inaccuracies in this post.

Hope that helps.

2

Python / Using Mysql With Python

« on: October 16, 2007, 04:13:23 pm »

Apologies for bumping my own post, but after more searching I found the answer and I thought I'd post it in case anyone else should get bitten.

The Python code was looking for the connection socket as /var/run/mysqld/mysql.sock, but the directory was empty.

In /etc/mysql/my.cnf, the socket location was given as /tmp/mysql.sock and indeed that socket file exists. So the solution was to add:
unix_socket='/tmp/mysql.sock'
as an extra parameter to the MySQLdb.connect() call. Magic.

Hope that helps someone.

3

Python / Using Mysql With Python

« on: October 15, 2007, 08:02:45 pm »

I thought I'd try out the Python/PyQt/MySQL combination, but I've hit a snag that I can't handle. Any words of wisdom would be very welcome.

The machine is a C3000 with stock ROM.

I installed the Zaurus Python Image v2.4 from pyqplayer.sourceforge.net: files
python-exe_2.4.0-1_arm.ipk
python24.ex2.gz

Python runs fine, as far as I can tell.

For MySQL, I installed
mysql_3.23.49-8.7_arm.ipk
That works fine using the mysql app: as zaurus or root I can create and populate databases. No passwords set yet.

But from python, I can't connect to MySQL. I've created a test database called 'junk' and here's what happens when I try to access it.

$ python
Python 2.4 (#1, Jan  5 2005, 19:21:20)
[GCC 2.95.1 19990816 (release)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import qt
>>> import MySQLdb
>>> ms = MySQLdb.connect(host='localhost',user='zaurus',db='junk',passwd='')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/QtPalmtop/lib/python2.4/site-packages/MySQLdb/__init__.py", line 64, in Connect
    return Connection(*args, **kwargs)
  File "/home/QtPalmtop/lib/python2.4/site-packages/MySQLdb/connections.py", line 109, in __init__
    super(Connection, self).__init__(*args, **kwargs2)
_mysql_exceptions.OperationalError: (2002, "Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)")
>>>

The MySQL daemon is running (or the mysql app wouldn't have worked). The directory
/var/run/mysqld
is empty.
There are no error reports in dmesg.
Running as root gives the same error.

I'm totally new to Python, and I've no idea what to try next.

Cheers and TIA

John

4

C1000/3x00 General discussions / Zaurus Oscilloscope

« on: September 01, 2007, 07:24:34 pm »

are you releasing this work under the GPL or other approved OSS license, and if so, is your friend releasing his work too so that you can release source code?
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

The Syscomp software that comes with the DSO-101, and from which my port was derived, is released as the [a href=\"https://sourceforge.net/projects/oip]Open Instrumentation Project[/url] on sourceforge, under the GPL. I plan to contribute my port to that project when it's proven to work well enough, so It'd be under the same licence.

5

C1000/3x00 General discussions / Zaurus Oscilloscope

« on: September 01, 2007, 06:36:03 pm »

cool! excellent work! I assume you're using the qtopia/qt toolkit, did you build the toolkit from scratch or did you find a verson for downloading?
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

Well, it's based around the Qt library, but almost all the widgets are hand-crafted (I invented a JWidget base class, which paints itself on a single parent QWidget). The reason was that I couldn't control the QWidget resize behaviour well enough: the widgets on the scope panel have to rearrange themselves in response to a change in the main window size (ie orientation), but when Qt issues the resize event it's already recalculated the window size from the current widget arrangement and I couldn't find a way around the problem. I'm sure it would have been possible with the right insight, but there you go. It did make life easier with the horizontal scroll bar and its drop-down cursors.

Which reminds me to mention that the horizontal scroll bar has a hidden feature. If you drag the thumb, it responds as normal. But if you start the drag in the trough, it gives a finer control. At high magnifications, that means you can still position the waveform accurately.

The project's cross-compiled from a desktop machine, basically using the instructions given at [a href=\"https://www.oesf.org/index.php?title=Compiler_Setup]https://www.oesf.org/index.php?title=Compiler_Setup[/url] and with the downloads recommended there. I wrote a Tcl script to automate the build and the ipk generation.

I also had to incorporate a fixed-point arithmetic class, because otherwise the display update was much too slow, given the Z's lack of floating point hardware. Got the update time down from 114ms to 27ms that way.

Did you try running the program btw?

6

C1000/3x00 General discussions / Zaurus Oscilloscope

« on: September 01, 2007, 10:44:06 am »

Ok, here's some further info on the project. On my minimalist web site there's now a page with screen shots and description of the work so far.

There's also an ipk file, for any brave souls who would like to see whether the program runs on their machine. If you try it, take a backup first - this needs to be treated as untrusted software which could crash and burn. It should run on C1000, C3000, C3100 and C3200 but I've been testing it only on a stock C3000.

Running the program without a scope connected to it won't be a terribly rewarding process, but you should be able to operate the controls and generally inspect the GUI.

For anyone who might already have a DSO-101, you'll also need to change the permissions on /dev/ttyUSB* to allow read/write access for all users.

Feedback (positive or negative) would be very welcome.

Cheers

John

7

C1000/3x00 General discussions / Zaurus Oscilloscope

« on: August 28, 2007, 07:46:46 pm »

am definitely interested... in fact I talked to a UK distributor of one USB scope (I think they were called Elan) and at the time they didn't/wouldn't do a linux driver; it was also about US$300 or so, and I decided against it.

I did wonder whether the microphone input could be pressed into service as an ADC using suitable signal conditioning.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=166780\"][{POST_SNAPBACK}][/a][/div]

I think the microphone input could certainly be used for a scope program, but I wanted something with a bandwidth from DC, and a "proper" high-impedance input that would take standard scope probes and not load the circuit under test. The DSO-101 has a 2MHz bandwidth and a sampling rate up to 20MHz, which was plenty for my needs and which comfortably exceeds anything the mic input could deliver. But if anyone were to put together a scope program using the mic input, I imagine there would be interest in that too.

Well, there's clearly interest in this thing. I'm now working further on the software, with the idea in mind of a demo mode - try the software without having to buy the hardware first. I'll also try to put together a few screen shots and explanations, to give an idea of what the GUI is like.

8

C1000/3x00 General discussions / Zaurus Oscilloscope

« on: August 25, 2007, 07:55:21 pm »

Sounds like a very cool project.  I'd also to point out that the Z does have a USB 2.0 port.  The USB 2.0 standard can operate at different speeds.  (Decided to actually check Wikipedia to get my facts straight)  "High speed" is 480Mbps, "Full speed" is 12Mbps, and "Low speed" is 1.5 Mbps.  The Zaurus does not run at High speed, but supposedly it supports the rest of the 2.0 protocol.

Out of curiosity, have you run this on a desktop PC?  How does it perform on a PC?  And this generally works well on a Z?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=166677\"][{POST_SNAPBACK}][/a][/div]

Thanks, Drake01 - I really had thought it was USB1, and I admit I'm still not quite convinced. The output of lsusb -v on my C3000 begins:
Bus 001 Device 001: ID 0000:0000  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10

I thought the last line there was the USB version number, and hence my comment. But I admit to not having checked further, and I'd certainly welcome a reference where I could learn more. I haven't yet plucked up the courage to go and read the full standard...

Desktop PC: the original Tcl/Tk software runs fine on a desktop (Linux, Mac or Windows, though I've only run it under Linux). I haven't gone so far as to try the port on a desktop - if that's what you meant - some of the code assumes it's on a Z, and I wasn't aiming for anything other than a Z port.

Cheers

John

9

C1000/3x00 General discussions / Zaurus Oscilloscope

« on: August 25, 2007, 08:55:20 am »

The DSO is described as USB Host powered, so does it run direct from the 100mA the Z can supply or does it need more mAmps?  So it needs a powered USB hub?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=166672\"][{POST_SNAPBACK}][/a][/div]

It does need a powered hub - the scope draws (I think) about 400mA. Also, the scope spec says it needs USB2, but I've found that the Z's USB1 port does drive it acceptably enough. There's an occasional problem in high-resolution mode (where you can capture 32k samples per channel and then examine the waveform in detail), in that sometimes some sample data will be lost. I haven't tracked that down fully, but I believe it's due to the USB1 issue and I haven't found it to be a significant drawback. My software doesn't flag it up when it happens, but it could easily be made to do so.

Cheers

John

10

C1000/3x00 General discussions / Zaurus Oscilloscope

« on: August 24, 2007, 07:43:12 pm »

This post is a trawl, to see whether there's any wider interest in an oscilloscope project I've been working on.

The project uses a digital scope manufactured by Syscomp - the DSO-101. It's a two-channel scope, which plugs into a USB port and uses the conputer as its driver and display. You can read lots more about it at Syscomp's web site.

What I've been doing is to port the host software to the Z.

I bought the scope in the first place in connection with a Morse-to-speech project (mentioned before in these forums). I liked the spec and the price, and I particularly liked the fact that the software that runs on the host is open sourced. The software is written in Tcl/Tk, and I've been porting the main functionality to C++/Qt.

The scope hardware is physically bigger than a Zaurus, but not by all that much, so I thought it would be neat to use the Z as a host and thus end up with a pocket-sized oscilloscope system.

I've now got the port working pretty much to my satisfaction (YMMV). The port doesn't have all the advanced features of the original software, but I think it does count as a workable system. My Zauri  are still using their original Sharp ROMs, and the program should work on C1000/3000/3100/3200.

(Dis)claimer: When I first bought the scope, I was merely another customer for Syscomp. I then offered them a couple of contributions for the host software, and that progressed to the point where I became a beta-tester for them. From that, I discussed the idea of the Z port and they were immensely supportive, including supplying extra hardware for the purpose. From that, you'll correctly gather that I think these people are Good Guys. But I have no commercial relationship with them - this is an open source project, pure and simple.

Maybe this is just my private toy, but if anyone else would be interested, I'd be happy to share it.

Cheers

John

11

Linux Applications / Interrogating The Usb Serial Devices

« on: August 03, 2007, 05:31:10 am »

can my program find the manufacturer, product and serial number strings (as listed by lsusb) of the hardware connected to a given ttyUSB port

that's a good question, and I don't know.

could you use sudo to allow lsusb to be run by non-priv, or, make the file setuid? It's not suid on my x86 desktop, but still prints *some* useful things.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=165678\"][{POST_SNAPBACK}][/a][/div]

I could certainly do that, but lsusb still doesn't give the vital information as to which ttyUSB port each piece of hardware is connected to.

Hmm. If you of all people don't know the answer, this is even tougher than I'd imagined :-(

12

Linux Applications / Interrogating The Usb Serial Devices

« on: August 01, 2007, 09:56:57 pm »

I've been wrestling with this, and it's time to give up and ask the experts.

C3000 with stock ROM, but portability desired.

My program will communicate with two separate USB serial devices, which will appear on /dev/ttyUSB0-1. I can probe the devices to find out which device is on which tty, but if there are other serial devices connected, the probing would be likely to upset their operation. (The stock ROM has only two serial devices, but mknod seems happy to create more, and I'd like my program to assume that other devices could be present.)

The devices are identified by their Manufacturer, Product and SerialNumber strings in the output of lsusb -v, but that gives me two problems:
1. lsusb -v has to be run as root; I'd prefer my program not to need root privileges.
2. Although it identifies the devices, it still doesn't answer the question of which tty each is connected to.

I can get my program to run dmesg and then parse the output, and I've had some success there - but:
1. Parsing the dmesg output is hardly elegant, and presumably highly non-portable, not to say driver-dependent.
2. dmesg appears to use a circular buffer, and the information I need is not necessarily still present when I need it.

The question in its most simplified form:
How can my program find the manufacturer, product and serial number strings (as listed by lsusb) of the hardware connected to a given ttyUSB port, with bonus points for elegance and portability?

As usual, enlightenment would be much appreciated.

Cheers

John

13

C1000/3x00 General discussions / Screen Capture, Portrait Mode, Stock Rom - How?

« on: July 29, 2007, 10:17:05 am »

Brilliant - thanks, jfv! And over an ssh connection, the plain command works like a charm.

For a second there I thought someone stole my handle.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=165480\"][{POST_SNAPBACK}][/a][/div]

The handle isn't a steal - just a close imitation. Please consider it the sincerest form of flattery  

14

C1000/3x00 General discussions / Screen Capture, Portrait Mode, Stock Rom - How?

« on: July 28, 2007, 09:11:55 pm »

I have a stock C3000, and I know that I can create a screen capture by typing Shift-Fn-C. What I don't know and probably should, is how to get a screen capture in portrait mode, when the keyboard is by definition inaccessible. I've tried opening it up just a little, but it switches to landscape mode before I can open it wide enough to get my fingers to the keys.

I searched, and found scrot, but that seems to require X11 to be installed.

I feel pretty stupid about this, because there just has to be a simple way, surely?

Enlightenment would be much appreciated. If said enlightenment included a way to trigger a full-screen capture from a program (stock ROM, please remember), that would be icing on the cake.

(I'm asking this because I want to create screen shots of my program while it's running. I do realize that I can save the program's part of the screen area from within the program, but I'd like to see the title bar and task bar in the screen shot too.)

Cheers

John

15

Software / Morse Code Input

« on: May 01, 2007, 12:26:22 am »

To do the timing on the Z, you'd need to be confident that your userland program would be able to measure the timings of events with 10 to 20mS accuracy - preferably 10mS or better. I lacked that confidence, but I'd be very interested if anyone could prove me wrong.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160035\"][{POST_SNAPBACK}][/a][/div]

10 mS is a long, long time to the computer.  I make video games for a living, and we try to get 60 frames per second.  Every 16.7 mS, the games I work on need to do physics calculations, transform and draw thousands of polygons, process artificial intelligence, and so on.  Granted, the hardware we develop for is designed for this sort of thing, but you can do a whole heck of a lot in twenty milliseconds of computational time.

I would be really surprized if multitasking on the Z would skew your timings too much.  I expect you could use a standard message pump and take for the time stamp the time that you get the callback to process the event, and that the amount of time that this would be off -- probably on the order of microseconds -- would be far less than the amount of variation time your program has to account for when looking at human-provided input.  

[Hmm... It appears that a single task may get up to ten milliseconds in one go, on the high end.  That computing quantum is higher than I thought, and may actually cause you a problem.  I don't know what the actual time is for the Z.  It may be, though, that multiple timings are skewed by the same amount, and, especially since your task will be the only one running, I don't think it'll be an issue.]

Armagon
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160140\"][{POST_SNAPBACK}][/a][/div]

I think you're very likely to be right - and for the archive, I agree with your point.

I note your "Hmm" though. I was trying to avoid getting involved with issues I couldn't measure, which is why I didn't want to go down that road. I don't have a problem with the amount the machine can do in a stated period of time, but I did worry about how long my program could potentially be backgrounded,

In my particular case:

Given that I'm developing this for one single individual, and given his particular situation, I'm not in the position where I can carry out experiments. Either it works first time when he's presented with it, or it's dead in the water. I feel more confident that my (let's say, in general terms unnessarily elaborate) solution will work out of the box, because I don't know how long the Z could take control away from my program, and I think I've evolved a solution where it isn't necessary to know that.

There's still the other issue: debouncing. A typical Morse key has brass contacts, and when contact is made, there's a whole lot of noise there. In my experiments, I found that the noise would persist for about two thirds of the length of a 20wpm dot. In my solution, the PIC does the debouncing, which makes the Z program a lot simpler. If the debouncing had to be done on the Z, I think the timing requirements would be an order of magnitude more severe. Well, either that, or I'd have to be a cleverer programmer than I am. Which is not likely to happen any time soon :-(

We've already seen in this thread the solution that I entirely missed: the use of the audio port, which by definition capures samples at regular and known intervals, and buffers them until you're ready for them. If I were starting again on this project, I think I might well begin there. That does seem to be a way of getting the Z to do the timings with accuracy.