Help - Search - Members - Calendar
Full Version: Zaurus Oscilloscope
OESF Forums > Distros, Development, and Model Specific Forums > Model Specific Forums > C1000/3x00 General discussions
jfr
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
gsgmx
Sounds great,

i might get one of these scopes too. My Z is runnin g Cacko 1.23 now so your hostsw should run now. But i am planning to switch to pdaXii13. Qt apps do run there too, i am not shure whether or not.

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?

Thks, George
jfr
QUOTE(gsgmx @ Aug 25 2007, 12:42 PM)
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?
*

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
Drake01
QUOTE(jfr @ Aug 25 2007, 07:55 AM)
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
*

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?
pelrun
Wow, I think I need to start putting away some pennies for this... smile.gif
jfr
QUOTE(Drake01 @ Aug 25 2007, 04:24 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?
*

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
aeazocar
jfr,

Congratulations, this is a great project!
I am currently using pdaXrom, I will love to see it running on it.

Please keep us posted...

Alejandro.
Drake01
QUOTE(jfr @ Aug 25 2007, 06:55 PM)
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...
*

That's interesting. I had never actually checked that before. The documentation I've read on the Wiki's all states that it's USB 2.0, but not running at high speed. This output seems to imply something else.
boardboyd
Just to add, I'm in support of this project and would be interested it. I guess I'll also have to stop buying that extra coffee/day to save up for the hardware.
speculatrix
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.
jfr
QUOTE(speculatrix @ Aug 28 2007, 11:17 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.
*

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.
speculatrix
definitely very interested, whether the source was microphone, usb-based ADC (such as a proper scope module), or CF module!

for a while now I've toyed with the idea of building a general-purpose I/O module using a CF development kit with a CF extender. perhaps people know that the Handspring variant of Palm had a slot for expansion modules and it was basically a PCMCIA slot in a special form. It'd be nice if the Z could be similarly used.
Da_Blitz
mm, cant believe i missed this post, i am thinking of getting one of these now.

very very intresting wink.gif

edit:

just noted they do paypal, now i am very very intrested, been waiting for somthing like this for ages
louigi600
I've been using on my x86 pc (with linux naturally) a software that does bothe oscilloscope and spectrum analisys (within the audio band) without any additional hardware. The software is xoscope ... I've not attempted to build it for Z and it's not the kind of software I plan to use on my Z but you might like to have a go at building it for Z ;-)
Da_Blitz
xoscope is nice but it has its limits, mainly bieng limited to the sampaling freq. up to less than half the sample rate (ie 48000hz becomes 24000hz max) this might be fine for some people but for some things you need a higher sampling range

the only real down side i can see on this thing (for me at least) is the 2mhz capture rate, somthing higher would have been nice but its better than nothing and is most likly fine for what i will do with it
louigi600
A free audible band oscilloscope/spectrom analizer is a better value then a 200 $ 2Mhz usb device wich is still to be fully ported to Z ;-)
speculatrix
QUOTE(Da_Blitz @ Aug 31 2007, 02:13 PM)
xoscope is nice but it has its limits, mainly bieng limited to the sampaling freq. up to less than half the sample rate (ie 48000hz becomes 24000hz max) this might be fine for some people 
*


surely Nyquist's law suggests that's all you can do anyway?
louigi600
Hum ... I think it's more commonly known as "Shannon sampling theorem".
Anyway since xoscope does not use any additional hardware it's limited by two factors:
1) the Shannon sampling theorem"
2) the bandpas filters in the input circuitary sound hardware (wich must have a high cut off frequench <= 1/2 sampling freq or the ADC would start pproducing odd informations and any fast furier trasformation on the digital signal thus produced would be hevily distorted)
Da_Blitz
not to mention the low freq cutoff is normally fairly high.

i did have a fairly good usb sound card that did 24 bit @ 96khz which gets past point one but not point 2, in fact i have no idea what the freq. response is like on that thing. from most of the graphs i have seen the filters gut in very ffairly leaving a heavily distorted signal

then again sound cards were never really designed for that sort of thing smile.gif

xoscope has its uses, esp for low freq signal injection
speculatrix
hmm, it's been a long time since I did analogue and digital comms at university! I recall Nyquist being the stuff about sampling rate being double the max frequency to avoid aliassing, and Shannon being about information rate... but it looks as if it's all counted together now:

http://en.wikipedia.org/wiki/Nyquist%E2%80...ampling_theorem
jfr
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
speculatrix
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?
jfr
QUOTE(speculatrix @ Sep 1 2007, 10:14 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?
*

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 http://www.oesf.org/index.php?title=Compiler_Setup 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?
speculatrix
QUOTE(jfr @ Sep 1 2007, 11:36 PM)
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?
*


{... snipped the details...}

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?

'fraid I won't get round to running this very soon 'cos I'm running Angstrom with GPE (i.e. GTK/X11), but when qtopia2 or qtopia4 on angstrom makes it to beyond beta then I've love to give it a go building your code for Angstrom!

Paul
jfr
QUOTE(speculatrix @ Sep 1 2007, 11:56 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?
*

The Syscomp software that comes with the DSO-101, and from which my port was derived, is released as the Open Instrumentation Project 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.
speculatrix
I am wondering if anyone's done anything new for this?

On angstrom mailing list there's been a post about how the 1000/3x00 has got stereo input, its just not been wired up!
Ragnorok
- Neat! I've been looking for a DSO to do transient capture, but so far I haven't found one that appears to be what I'd need, mainly because the capture buffers are so darned tiny. But I could very well be wrong ... I have a Tektronix lab 'scope I use right now and I'm not so familiar with DSOs.
- I'm very, very interested in two things:

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.

2) This port. I really like the idea of using the Z as a portable o'scope. Very spiff!!

Details:

- I'm doing work with goto control systems for amateur astronomy, and I'd like to analyze the power rails for transients introduced by the pulse-width-modulation drive for the motors. Some goto mounts are very finicky about supply voltage, and I think it's actually because they put too much noise on the rails. My thought for analysis was not to trap individual transients, but to capture supply voltage and current data (using the two channels) and see where to goto crashes. It's the transient that causes the goto system to wonk out that I need to see. I was hoping a DSO would do the trick but nothing I've read indicates they will because I haven't seen any affordable ones that will capture 20MS/s continuously. They all do it 'til their buffer is full, then you're sunk, or at least that what numerous owner manuals seem to imply.
- I'd love to wrong! I'll buy one of these things, no problem.

- Thanks for your time...
pelrun
Well the syscomp features adjustable pre and post trigger capturing, which is what you want. If you can detect the goto "wonking out" quickly enough, then you can use that as the trigger input, and show what was captured just prior to the triggering.
jfr
QUOTE(Ragnorok @ Jun 30 2008, 01:10 AM) *
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.
Ragnorok
- Sorry for my slow reply. I have seventy different things to do any given minute and sadly reading OESF doesn't bubble to the surface as often as it could.
- This sure do help!!! Thanks jfr!!
- Based on your response I'm going to look into acquiring one of these. It sounds like if it won't work out of the box, it can be made to work, and the Syscomp folks are supportive for this effort. I have an FC9 system (the one I'm typing on now) that's devotable to development for Linux and/or the Z. The main driver here is price. I might be able to scrounge up the money for a DS-101 and fiddle with it as time permits, knowing I have full access to all required source to modify as needed to make it function. This is a doable solution, where $900 for a DSO that will do continuous sampling is not.
- At this point I don't know how I'd detect a crash. I may do something oddball like use the Tektronix to trigger on spikes and do a buffer dump, then reset for the next spike. Or I could use the ASCOM driver on the laptop to continuously poll the mount and trigger a capture when it fails to respond, assuming I can do that within the 1.6ms the buffer holds at 20M samples/second.
- I've always wondered why these darned things have such tiny buffers. Modern PC memory has like a 6Gbyte bandwidth and costs nearly nothing. That bandwidth will support 20M samples/second on 12 channels at 24 bits/sample. Even if bus contention reduces that rate by an order of magnitude it should handle the sample rate of the DS-101 without even trying, and a gig of that RAM would hold 3.3 full *seconds* of data instead of a piddly 1.6ms. Heck I'd make it with a standard RAM socket for user upgrade to more buffer.
- Still this is uber-spiff! Onto noodling finincing. Thanks again!!
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2014 Invision Power Services, Inc.