JamesF

Aha!  Just discovered that the kernel driver is returning an ENOSPC error which means it can't allocate sufficient bandwidth on the USB bus.  No idea why that should be, but I'll have to look into it over the weekend.

James

Just tried the SPC900 on the netbook and it works fine.  I think therefore that it must be some sort of hardware compatibility issue with my laptop, or the Linux drivers for the laptop implementation on my laptop are iffy.  Irritating

James

I've spent this evening making different bits of the application hang together (getting the captured frame count to show in the status bar, disabling some controls when the application is capturing to disk etc.) and doing some tidying up before I embark on getting my ASI120 to work.

Thus far I've been testing with an SPC900, my modded Lifecam and a cheap old webcam I bought to turn into an IR cam.  Mostly they work on my desktop box, though there is some issue with the brightness control on the Lifecam.  I reckon that might be something weird with the Lifecam though.

I thought I'd also give it a go on my laptop and netbook, both of which have built-in cameras.  The netbook is still building the ffmpeg library, but on the laptop the built-in camera works fine (but highlighted a bug with showing some unsupported camera controls  When I plugged in the other cameras however, the SPC900 would not work, throwing an error in the kernel.  I might have put this down to software, but bar a few patches that I am now installing, the laptop is set up almost exactly the same as my desktop.  The logs show the camera throws an error in the kernel which is certainly the same.  This happens whether the camera is directly-connected or in a hub.  Most odd.  I'm starting to wonder if it might not be something to do with the USB hardware itself.  Hopefully tomorrow I can try it in the netbook.

I think I shall ignore the problem for the time being if it continues to fail in favour of getting the ASI120 working as that would mean I can actually go out and capture some real data with it.  Perhaps at a later date I will need to revisit the user-space USB driver for the Philips cameras after all.

James

I'm also the maintaner of INDI, what issues are you facing with INDI exactly?

When I have some time, I'll make a list

James

Yes.  Sadly INDI has a few other niggles that irritate me and I can't find a way to do within its existing architecture some things I want.  If I can find a way of fixing them then I shall do so.  If I can't then, err, I'll think about that when I get that far.  Which is probably going to be a while yet.  I have other fish to fry first.

James

Has anyone tried Ekos in KStars? Ekos already relies on INDI, so you have all the V4L2 cams, SBIG, QHY, QSI, FLI, Starlight Xpress, ATIK...etc CCDs already well supported. When I first got my astrophotography gear a couple of years ago, I was also furstrated by the lack of decent capturing software for a typical amatur astrophotograhy session. I wanted to be able to perform a decent polar alignment, focus my CCD, guide it, and capture images with different filter wheels while I am away, and this is why I developed Ekos, I wanted to do everything from one place.

I'd not want to discourage others from trying it, but for me this isn't just about creating another capture program.  My longer-term goal is to create a suite of imaging tools I can do all sorts of other things with, such as running them on different architectures and even on headless servers or ones without any kind of graphics display at all (though they are not my only goals).  Writing a capture program is just one step along the way.  Fortunately it's a step that has very useful output

James

And woohoo!

It's been a slog and a half and more than once I was considering abandoning AVI formats altogether, but as of five minutes ago I have this:

$ ls -l oaCapture-20131004-011601.avi -rw-r--r-- 1 james james 47297118 Oct  4 01:16 oaCapture-20131004-011601.avi$ file oaCapture-20131004-011601.avi oaCapture-20131004-011601.avi: RIFF (little-endian) data, AVI, 640 x 480, ~15 fps, video:

I had to resort to building my own copy of ffmpeg, to get their Ut Video encoder as the default Ubuntu/Mint version doesn't have much to offer in the way of codecs suitable for AVI files that can also handle RGB format frames that I could get to work.

This is a quite a big step forward and I'm feeling rather pleased with things right now

James

Ah, so this is your new capture program James. Looks good! .. keep at it

Theirs nothing like having your own software doing just what it is you want it to do rather than having to use someone elses software doing what it is they wanted it to do.

I think there might be a linux SDK for talking too the fireflys, although not 100% sure as I only used there Windows SDK.

Indeed it is, Cath.  I shall have a look for a Firefly SDK.  It would be quite handy to have those cameras running with this.

James

I am planning to open source PIPP once I have reworked it to be a C++ QT application (rather than a C# GUI round a C++ application), plus tidied up some of my scruffy code!  Though finding the time to do this is the hard part.

I have sent you a PM that you may or may not find useful!

Thanks for the PM.

Though I shudder to admit it, the awful weather has been something of a blessing in terms of getting coding done 

Once I've made more progress with this I'm more than happy to help with the Qt port of PIPP if you need it, but we can discuss that further down the line if you've not already done it by then

James

I'm going to have another look at the ffmpeg stuff today.  If I can't get things to work then I'll leave it for the moment and do SER and FITS as they look far simpler.

James

It took me ages to get ffmpeg working on Windows, there are so many out of date examples out there on the internet.  Once I got it building all was fine as I distribute the DLLs with PIPP.  Ironically I build the Windows' ffmpeg DLLs on my Linux box because it is much easier.

How would this would this work with Linux?  Would you build and distribute the ffmpeg libraries with your application or does it not work that way?

Also, are you planning to make your program open source?

Cheers,

Chris

I'm finding a huge number of out-of-date examples myself  Even the example code that is shipped with the source code for the version I have installed doesn't actually build without lots of warnings

I'd probably opt for static-linking the ffmpeg libraries into the executable on Linux if I have to go down that route.  It's far easier to keep things under control that way and the cost in terms of size is hardly huge.

It will definitely be open source.  I've earned my living from working with open source software for fifteen years or more and been a user of it in one guise or another for not far off twice that.  It would feel disrespectful not to give a little back.

James

Unexpected side-effects of the US government shutdown.  I can't get to NASA's copy of the FITS specs.

http://heasarc.gsfc.nasa.gov/fitsio/CCfits/html/index.html

James

With standard AVI libraries I could not figure out how to generate mono (DIB) AVI files that were not 3x the size the needed to be.  That is why I wrote my own class.  For the Ut Video codec (and MPEG-4) I just wrote a wrapper for ffmpeg and I am very pleased with how that worked.

Chris

I had shied away from ffmpeg because the interface seems to change on such a regular basis.  I've downloaded  the demo code from the ffmpeg website and none of the different version actually compile against the libraries I have installed.  If I get it to work I might have to static link it.

James

With standard AVI libraries I could not figure out how to generate mono (DIB) AVI files that were not 3x the size the needed to be.  That is why I wrote my own class.  For the Ut Video codec (and MPEG-4) I just wrote a wrapper for ffmpeg and I am very pleased with how that worked.

Chris

Some seem to do it by just taking the mono data and creating a new RGB frame using the same pixel values for each channel.  Not exactly very efficient, as you say.

James

Well, I've spent a good few hours this evening trying to get the application to write AVI files and I'm still not there

Libraries for creating AVI files on linux are fairly thin on the ground -- there mostly seems to be ffmpeg, libav (an ffmpeg fork, I believe) and libavifile (which may use some ffmpeg code too).  They're utterly impenetrable and reliable documentation is scant where there is any at all.  In the end, libavifile seemed the least worst, but it's taken me most of the evening to find a codec it will actually allow me to use.  I did think about grabbing the Ut codec source, porting it to Linux and working out what I need by way of a wrapper around it to make it look like an avi, but that would mean that the file wouldn't play back under Linux

Hopefully I can get it finished tomorrow.  Then SER and FITS should be a doddle by comparison...

James

Well, I've (kind of) fixed the Lifecam errors I was getting.  So nice of the camera to lie about the default state of the auto-exposure control...

James

I guess my long-term goal Gina is to be able to do all the capture-side stuff on Linux if I can.  I can handle doing the processing on Windows if I must, but in my experience Linux (most flavours of UNIX, really) are so much more robust than Windows which makes them more suited to running unattended overnight or even over a period of weeks.  And I can't deny that it might be rather cool to be able to sit in the office working or stuck on a conference call, notice it's sunny, say, and be able to fire up the solar rig from my desk and do a bit of imaging without having to stop work

James

More progress this evening.  I have resolution and frame-rate changing working after a bit of a fight.  This means that the SPC900 appears to work nicely now for me.  I have one remaining niggle with the Lifecam where the V4L2 layer is giving an error when I try to change the exposure length and another issue with an old webcam that is also supported under V4L2 that shouldn't take long to tidy up.  Once I have those sorted I'll try running it with another couple of cameras and if no further errors present themselves then it looks like the actual capture side is sorted for V4L2 cameras.

Then I'll have to think about writing the data out onto disk.  Not sure how I'm going to go about that at the moment.  I might create another thread just for writing data to disk even if it is a bit hairy.

James

I almost forgot to mention...

I received a used QHY5 today, so I should be able to test that along with my QHY5L-II when the time comes.  There's not much else for Linux that supports the latter camera, so having one that I know works with other software will make life easier.

At the moment however I'm trying to get my head around the synchronisation between resolution changes and frame rate changes for V4L2 cameras.  Changing the resolution can alter the number of frame rates available.  For example, setting the SPC900 to 320x240 will allow it to run at 30fps whereas the maximum allowed at 640x480 is 15fps.  Debugging multithreaded applications is hard

James

I'm pleased to report that Alan dropped me an email earlier today to say that the binary I sent him works fine which is very pleasing to hear.  Just need to knuckle down and get a bit more done now.

Then I'll have to look into packaging stuff up in RPMs/.debs.  It's been quite some time since I built an RPM from scratch and I've never done a .deb.

James

Just emailed it

James

Well, I may have most of the camera controls working, but the last two are proving a bit of a pig.

It looks like either the SPC900 driver or the V4L2 layer doesn't allow the frame size or frame rate to be changed once a camera has been started.  Even stopping the camera streaming data and changing the values doesn't seem to help.  Looks like I might need to close and re-open the device if the resolution or frame rate changes.  But that's something to play with tomorrow.

James

It would be nice to see the SPC900 properly supported again. In order to control it my 'field' laptop still runs Ubutnu 10.04.........

Actually Alan, as I have most of the controls working this evening, I could punt the binary over your way if you want to give it a whirl to see if you get anything on-screen.  It will be useless for anything else, but you might at least be able to test the camera to see if you can get it to work on Mint 15.

James

There is some source on Github for the Beagleboard with same sensor https://github.com/Aptina/BeagleBoard-xM/blob/master/MT9M034/Angstrom/mt9m034.c  might be of help.

I have a feeling that doesn't help, from memory.  One or the other camera is connected up via an I2C interface if I recall correctly, whilst the other isn't.  I may be completely misremembering that however.

James

I recall writing my thesis with  some windows version of vim at the time using ( tex/latex ) on a 286 with 64 kB RAM, it was the only thing light enough I could use from home and could handle a document of that size and compile it to a processed dvi , and it handled it with a breeze. Word perfect or whatever word processors were around even on a 386 would just fall over in those days with documents of that size. Vi was so fast that even doing a search and replace in several hundred pages was instant, I am reminiscing now, but those were the days compared to the grinding of some of the bloatware of today :0)

Yes, I think Moore's Law applies to software, too  Computing power might double every eighteen months, but software bloats to consume most of the additional resources.  Total functionality doesn't grow that much at all

James