OESF | ELSI | pdaXrom | OpenZaurus | Zaurus Themes | Community Links | Ibiblio

IPB

Welcome Guest ( Log In | Register )

2 Pages V  < 1 2  
Reply to this topicStart new topic
> Zaurus Oscilloscope, using commercial hardware
louigi600
post Aug 31 2007, 06:18 AM
Post #16





Group: Members
Posts: 474
Joined: 21-May 06
Member No.: 9,928



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 ;-)
Go to the top of the page
 
+Quote Post
speculatrix
post Aug 31 2007, 08:20 AM
Post #17





Group: Admin
Posts: 3,281
Joined: 29-July 04
From: Cambridge, England
Member No.: 4,149



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?
Go to the top of the page
 
+Quote Post
louigi600
post Aug 31 2007, 10:01 AM
Post #18





Group: Members
Posts: 474
Joined: 21-May 06
Member No.: 9,928



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)
Go to the top of the page
 
+Quote Post
Da_Blitz
post Aug 31 2007, 10:26 AM
Post #19





Group: Members
Posts: 1,565
Joined: 7-April 05
From: Sydney, Australia
Member No.: 6,806



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
Go to the top of the page
 
+Quote Post
speculatrix
post Aug 31 2007, 12:01 PM
Post #20





Group: Admin
Posts: 3,281
Joined: 29-July 04
From: Cambridge, England
Member No.: 4,149



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
Go to the top of the page
 
+Quote Post
jfr
post Sep 1 2007, 06:44 AM
Post #21





Group: Members
Posts: 36
Joined: 29-March 05
Member No.: 6,732



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
Go to the top of the page
 
+Quote Post
speculatrix
post Sep 1 2007, 01:14 PM
Post #22





Group: Admin
Posts: 3,281
Joined: 29-July 04
From: Cambridge, England
Member No.: 4,149



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?
Go to the top of the page
 
+Quote Post
jfr
post Sep 1 2007, 02:36 PM
Post #23





Group: Members
Posts: 36
Joined: 29-March 05
Member No.: 6,732



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?
Go to the top of the page
 
+Quote Post
speculatrix
post Sep 1 2007, 02:56 PM
Post #24





Group: Admin
Posts: 3,281
Joined: 29-July 04
From: Cambridge, England
Member No.: 4,149



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
Go to the top of the page
 
+Quote Post
jfr
post Sep 1 2007, 03:24 PM
Post #25





Group: Members
Posts: 36
Joined: 29-March 05
Member No.: 6,732



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.
Go to the top of the page
 
+Quote Post
speculatrix
post May 13 2008, 01:04 PM
Post #26





Group: Admin
Posts: 3,281
Joined: 29-July 04
From: Cambridge, England
Member No.: 4,149



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!
Go to the top of the page
 
+Quote Post
Ragnorok
post Jun 29 2008, 04:10 PM
Post #27





Group: Members
Posts: 298
Joined: 27-October 03
From: Greenfield, NH
Member No.: 781



- 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...
Go to the top of the page
 
+Quote Post
pelrun
post Jun 29 2008, 05:00 PM
Post #28





Group: Members
Posts: 369
Joined: 6-September 04
From: Brisbane, Australia
Member No.: 4,488



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.
Go to the top of the page
 
+Quote Post
jfr
post Jul 20 2008, 02:39 PM
Post #29





Group: Members
Posts: 36
Joined: 29-March 05
Member No.: 6,732



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.
Go to the top of the page
 
+Quote Post
Ragnorok
post Aug 28 2008, 10:36 AM
Post #30





Group: Members
Posts: 298
Joined: 27-October 03
From: Greenfield, NH
Member No.: 781



- 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!!
Go to the top of the page
 
+Quote Post

2 Pages V  < 1 2
Reply to this topicStart new topic
2 User(s) are reading this topic (2 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 25th October 2014 - 10:14 AM