james_lan replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 2 weeks ago

[2018-05-11T21:56:03.775 CDT DEBG ][ org.kde.kstars.indi] - ISD:Telescope sending coords RA: "15h 35m 12s" ( 15.5868 ) DE: " 67° 02' 27\"" ( 67.0409 )
[2018-05-11T21:56:05.524 CDT DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:FI#> "
[2018-05-11T21:56:10.537 CDT DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] <setObjectRA> "
[2018-05-11T21:56:10.997 CDT DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:Sr 15:35:12#> "
[2018-05-11T21:56:10.997 CDT DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:Sr 15:35:12#> successful. "
[2018-05-11T21:56:10.997 CDT DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] <setObjectDEC> "
[2018-05-11T21:56:10.997 CDT DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:Sd +67:02:27#> "
[2018-05-11T21:56:10.997 CDT DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:Sd +67:02:27#> successful. "
[2018-05-11T21:56:10.997 CDT DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] <Slew> "
[2018-05-11T21:56:10.998 CDT DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:MS#> "
[2018-05-11T21:56:10.998 CDT DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <0> "
[2018-05-11T21:56:10.999 CDT INFO ][ org.kde.kstars.indi] - LX200 OnStep : "[INFO] Slewing to RA: 15:35:12 - DEC: 67:02:27 "

Ok, so I got a short log. (The one prior to this was 20 seconds) Showing the delay I'm talking about. Note the 7 second discrepancy between being commanded to and actually moving. Ekos shows 'Slewing' in the main window, but there's no motion. So I'm not sure if it's a Kstars/Ekos issue, a driver issue or an OnStep issue. (I just updated to 18.04 Ubuntu, but everything should have been updated.) I'd say it wasn't OnStep, given the log, but I've only seen it so far on OnStep Alpha. If anyone else wants to take a look. (This is my 2nd OnStep Mega mount)

I'm on 2.9.5 (latest per ppa repository) I just upgraded to the 18.04 version (vs the 17.10, same version)

Indi is current, or at least current as of the last time I pulled from it. I'm gonna try to clean everything and build a new version making sure there's nothing left around.

Ok, looking more carefully, it looks like :FI# if FOCUSER1_OFF is on, gets a 5 second delay from OnStep (or lx200_OnStep.cpp) as does :FM# so that's something to go back and look at, or report. Sometimes typing things out gets you to the solution faster...

That problem (repeated delay) would have only occurred for me (or azwing. depending on the branch) because I removed the :FA# check, to force it on. Well, each command was coming up against the timeout, resulting in a 5 second delay. (#FG, #FI, #FM #FT). (It's defined as 3, but in my logs is always 5 seconds.) Adding an :FA check around the focuser updates didn't work initially. I looked at onstep and realized it wouldn't reply if the focusers weren't on at all. Added code below and it worked, and of course performing that check once (as was done previously is better).

Code to add to command.ino


#ifndef FOCUSER1_ON
if (command[0]=='F') {
// :FA# Active?
// Return: 0 on failure
// 1 on success
if (command[1]=='A') { // Not present so return 0 always.
reply[0]='0';
quietReply=true;
}
} else
#endif

#ifndef FOCUSER2_ON
if (command[0]=='f') {
// :fA# Active?
// Return: 0 on failure
// 1 on success
if (command[1]=='A') { // Not present so return 0 always.
reply[0]='0';
quietReply=true;
}
} else
#endif



----


However, it was/is a cause of freeze on connection, that I recall, so there's almost no connection delay from hitting 'Connect' to it working. I've sent an email to the OnStep list with this. It's alpha, but once that continues down, everyone should see an improvement on connect.

This stream of consciousness has been a bug fix for me, due to a self-inflicted bug that resulted in a fix for everyone else. ;)

Read More...

james_lan replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 3 weeks ago

I'm kinda meh about it. I'd love to have it working for guiding, I've gotten it to work once for guiding. (On Sirius?, I can't recall) However, it doesn't work well, at least with lin_guider (thus the attempt to get it to work natively with INDI and it's guider.) I got a NexImage 5 (Quite cheaply), which seems working ish. I discovered it would lock up, with other stuff last night, so I'm not sure exactly why. I had run tests of it just being on for probably hours watching some flowers in my yard. Frustrating is a word for it. My guess is that it's not sending the frames or something. I have logs to look at. Wheeeeee!

One thing that was frustrating was with the current OnStep Alpha and current indi seem to have slow serial connections. Like seconds long delays. I can go into a serial terminal and type some commands and it responds (Eg: :Gt# (time) type) pretty close so I'm sure it's not the serial connection itself. This is on a Mega with a DS3231 Focuser and RA/DEC, ST4 was set to pullup. A testing Mega (nothing on it) didn't have that delay problem until I flashed it. So not sure what's up. If anyone wants to take a look I've got 37MB of logs... and no recollection of when I had the issues. Everything seems to respond near instantly in the logs, that I've seen so far. when going through them, does anyone else get that?

Read More...

james_lan replied to the topic 'Experiences with Celestron NexImage cameras?' in the forum. 3 weeks ago

Pull request submitted: github.com/indilib/indi/pull/587

(The more of git I use the more it's both more powerful and really annoying.)

Read More...

james_lan replied to the topic 'Experiences with Celestron NexImage cameras?' in the forum. 3 weeks ago

Some more notes for anyone else who tries to use this: I got the controls back, apparently, there's a kernel->userspace transfer or something going on with uvc type things.

You'll need the file from the The Imaging Source github above, you need uvcdyntrl installed, then run this:
uvcdynctrl -i data/uvc-extensions/tisEUVC.xml -d /dev/video1

It goes from this:
v4l2-ctl -d /dev/video1 -l
brightness (int) : min=0 max=255 step=1 default=12 value=12
gain (int) : min=4 max=63 step=1 default=16 value=36
exposure_absolute (int) : min=1 max=300000 step=1 default=127 value=127
focus_absolute (int) : min=0 max=1000 step=1 default=0 value=0
privacy (bool) : default=0 value=0

to this:
v4l2-ctl -d /dev/video1 -l
brightness (int) : min=0 max=255 step=1 default=12 value=12
gain (int) : min=4 max=63 step=1 default=16 value=36
trigger_global_reset_shutter (bool) : default=0 value=0
exposure_absolute (int) : min=1 max=300000 step=1 default=127 value=127
focus_absolute (int) : min=0 max=1000 step=1 default=0 value=0
privacy (bool) : default=0 value=0
trigger (bool) : default=0 value=0
software_trigger (button) :
gainr (int) : min=0 max=63 step=1 default=1 value=36
gaing (int) : min=0 max=63 step=1 default=1 value=36
gainb (int) : min=0 max=63 step=1 default=1 value=36
binning (int) : min=1 max=4 step=1 default=1 value=1
x_offset (int) : min=0 max=1794 step=2 default=0 value=0
y_offset (int) : min=0 max=1464 step=2 default=0 value=0

Of those:
Brightness does nothing that I can tell.
Binning breaks it.
Trigger of all types is are somewhat untested by me, though they seem related to the snapshot mode.
Focus does nothing.
Exposure Absolute is in 0.1ms intervals. (Up to 300000 = 30 seconds, which seems to work. (Haven't tried it a lot yet, that's based on the white as this thing's background that showed up on streaming about 30 seconds after!))
R/G/B gains do work. There's probably an ideal value... but that either takes a patient approach or is the thing that drives people mad trying to properly figure out.

Testing with an ETX-70, I can see a fair number of stars. Sadly I can see stars, but I start to sink in the mud, and I'm exhausted. :(

Read More...

james_lan replied to the topic 'Experiences with Celestron NexImage cameras?' in the forum. 3 weeks ago

Ok, I've got it working. Amusingly helped by some networked RGB lights called Filimins that a friend started a business building.

Or did last night, I let my computer go to sleep and lost some controls (v4l2 problem not INDI) Like the R/G/B gains.

Here's the branch if you can use it, via some git magic, otherwise I'll make a clean pull request at some point in the next few days. github.com/james-lan/indi/tree/neximage (I'm based off of azwing's so that causes some issues I think.)

Read More...

james_lan replied to the topic 'Single Warning about cameras using either RAW or JPEG, and R+J' in the forum. 3 weeks ago

Attached Should have the camera back up in the next week for testing.

Read More...

james_lan replied to the topic 'Experiences with Celestron NexImage cameras?' in the forum. 3 weeks ago

I did find a seemingly great deal on a NexImage 5, so I did get it.

Here is the USB ID:
Bus 003 Device 055: ID 199e:8207 The Imaging Source Europe GmbH

Based on the driver package prior to seeing it, I was able to track back it, and most other Celestron cameras back to The Imaging Source. Which lead me to here: github.com/TheImagingSource/tiscamera/wi...USB-2.0-CMOS-Cameras

I followed that procedure, with the commands in bold, and the serial number replaced with <SERIAL>
sudo ./firmware-update -l

Found 1 device(s).

Name - ID - Serialnumber
NexImage 5 - 199e:8207 - <SERIAL>
sudo ./firmware-update -id <SERIAL>

Device manufacturer: Celestron
Product name: NexImage 5
Serial number: <SERIAL>
VendorID:ProductID: 199e:8207
Firmware version: 129
UVC mode is: off
Camera EEPROM size: 32768

sudo ./firmware-update -ud <SERIAL> -f ../../../data/firmware/usb2/dfk72uc02_3012.euvc

!!! Attention !!!
This action could break your camera.

Do you really want to proceed? [y/N] y
Firmware Size: 19968 EEPROM Size: 32768
100 %

Upload successful!
Please reconnect your camera.

sudo ./firmware-update -id <SERIAL>

Device manufacturer: Celestron
Product name: NexImage 5
Serial number: <SERIAL>
VendorID:ProductID: 199e:8207
Firmware version: 196
UVC mode is: on
Camera EEPROM size: 32768


Following that, the camera worked, and at low exposure time, gave me a great picture of some garden flowers, along with insect, via a Celestron First Scope Telescope (using v4l2 and guvview. A 76mm/300mm FL telescope. I'd see about a picture of stars, but there's the issue of these things called clouds that show up as an extra on seemingly any astronomy related purchase. This one came with a very large free package of wind as well!

Unforuntely, INDI doesn't seem to be as cooperative as guvcview.

This appears to be because of the formats supported:
ioctl: VIDIOC_ENUM_FMT
Index : 0
Type : Video Capture
Pixel Format: 'GREY'
Name : 8-bit Greyscale

Index : 1
Type : Video Capture
Pixel Format: 'GRBG'
Name : 8-bit Bayer GRGR/BGBG

Which looks like a 2 line pattern, if that's to be believed. Based on looking at guvcview's colorspaces.c it looks like that's how it's handling it.

If trying to stream, you get ... basically static.
For now, greyscale seems to work. I've been piddling around with a new conversion:

void bayer_grbg_to_rgb24(unsigned char *dst, unsigned char *src, long int WIDTH, long int HEIGHT)
{
	//Format is
	// GRGRGRGRGR
	// BGBGBGBGBG
	// GRGRGRGRGR
	// BGBGBGBGBG
	long int row;
	long int col;
	long int src_pixel;
	long int src_pixel_row2;
	for (row = 0; row < HEIGHT; row++) {
		for (col = 0; col < WIDTH; col++) {
			i=(row*WIDTH+col)*3; //Output is in 3 bytes RGB, so convert a single pixel each time.
			src_pixel=(row*WIDTH+col)*2; //Bayer pattern has 2 bytes in first row: GR
			src_pixel_row2=((row+1)*WIDTH+col)*2; //Bayer pattern has 2 bytes in 2nd row:BG
			dst[i]/*RED*/=src[src_pixel+1];
			dst[i+1]/*GREEN*/=(src[src_pixel]+src[src_pixel_row2+1])/2;
			dst[i+2]/*BLUE*/=src[src_pixel_row2+1];
		}
	}
}

I've added in the case to adjust the size of the rgb24_buffer based on pixel format: case V4L2_PIX_FMT_SGRBG8: in v4l_builtin_decoder.cpp, allocBuffers() but I'm a bit at a loss on it. Sometimes, it runs for a few minutes, and sometimes it fails immediately. It's probably something stupid that someone will see immediately above.

Unless the *src has some size issue.

Read More...

james_lan replied to the topic 'Single Warning about cameras using either RAW or JPEG, and R+J' in the forum. 4 weeks ago

Sure, what email address should I send it to, or should I attach it here?

I don't think all of the debugging was enabled, and further testing will need to wait until the camera is back in bulb. (So whenever the part gets in.)

Read More...

james_lan replied to the topic 'Single Warning about cameras using either RAW or JPEG, and R+J' in the forum. 4 weeks ago

Unfortunately not.

I have found it under the capturesettings tab, but adjusting that seems to produce odd behavior. It works on the card (NEF (RAW) and JPEG produced), but the download from the camera goes from 50 MB to 70 MB, I checked the raw data in the files, and it doesn't seem to include the JPEG data or structures, so I don't know what's going on. Test 3 and 4 were taken with the setting changed. (Setting is RAW on the camera)

Oh, fun, after trying to set that again, it reset the camera. SO DEFINITELY NOT AN OPTION. (Not your fault, but I used the one with a broken control, and getting it back into bulb mode requires me to fix it. I'd been putting off getting the part to fix it (D5300s have a flex cable that's subject to breaking easily, this will be the second one I've replaced (I got both cameras used, and beat up.))

file output:
test-nikon2.fits: FITS image data, 16-bit, two's complement binary integer
test-nikon3.fits: FITS image data, 8-bit, character or unsigned binary integer
test-nikon4.fits: FITS image data, 8-bit, character or unsigned binary integer
test-nikon5.fits: FITS image data, 16-bit, two's complement binary integer
test-nikon.fits: FITS image data, 16-bit, two's complement binary integer

47M test-nikon2.fits
69M test-nikon3.fits
69M test-nikon4.fits
46M test-nikon5.fits
47M test-nikon.fits

Read More...

james_lan replied to the topic 'Single Warning about cameras using either RAW or JPEG, and R+J' in the forum. 4 weeks ago

Unfortunately, for Nikon, that's not set there. Looking around I think there is a setting for it, but it's not showing up there. A quick test didn't seem to correct it on my D5300.

So for now, it needs to be set on the camera, to be either a JPEG mode, or (preferred) RAW.

Couple other possibilities of detecting it: File size changes drastically every other image. I think a warning, restricted to Nikon users would be the best solution? (Do any other non-Canon cameras have the issue?)

Read More...

james_lan replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 1 month ago

I've been working on PI Camera stuff for a bit so, I haven't gotten a change together yet.

I looked a little and I think it can be cleaned out, I've got a TODO around renaming OSFocus1RateSP? I'd tacked on the re-initialize the focuser position (for min/mid to it) The saving position isn't great for the way I use it. Put the camera in (repeatable), then have it move out.

Other than that, I think we can remove the rest of OSFocus1 stuff without issue.

Might not be bad since I haven't looked at the secondary device for Focuser2 to just throw it on a FOCUS2_TAB

There is the outstanding issue of it calling capture multiple times (not much of a problem on Kstars > 2.9.4 but I need to look into why. See KDE bugreport earlier.)

Read More...

james_lan created a new topic ' Experiences with Celestron NexImage cameras?' in the forum. 1 month ago

I've looked at cameras, and I have seen a few deals on NexImage cameras lately which look on the surface like they'd be good deals. However, I can find almost nothing about how well, or poorly they perform under Linux and INDI. The few that I do find either seem to refer to the old ones, with a Phillips chip. With Linux, so often things are either: No mention, because you plug it in and have 0 problems, or no mention, because no one has ever looked at it.

So I'm wondering if anyone has a NexImage, and if so, which one, and how well do they function? I'm guessing they'd be v4l devices, but based on a few posts on the internet I could find. It looks like the original color one works fine.

So if people could comment on that it would help me, or someone else searching the internet before asking questions.
Models, that I'm aware of:
NexImage Solar System Imager Model: 93709 (Sensor: ??, can't find it on Celestron's site, from comments elsewhere seems to be a Phillips chip also used in webcams?)
NexImage Burst Color Model: 95518 (Aptina AR0132 color sensor)
NexImage Burst Monochrome Model: 95519 (Aptina AR0132 mono sensor)
NexImage 5 Model: 93711 (Micron MT9P031, Some reference I can no longer find, I saw that it worked with the QHY5 drivers? Same chip as the QHY5P-II-M)
NexImage 10 Model: 93708 (ON Semi MT9J003 Color CMOS, USB 3)

(Useful reference: s3.amazonaws.com/celestron-site-marketin...ras+Compare_2017.pdf because of this, and having some technical details, I'll mention the models of Skyris too, in case that goes away, and some dead forum post is useful)

Skyris 132C Model: 95508 (Aptina AR0132 color, USB 3)
Skyris 132M Model: 95509 (Aptina AR0132 mono, USB 3)
Skyris 236C Model: 95506 (Sony IMX236LQJ color, USB 3)
Skyris 236M Model: 95507 (Sony IMX236LQJ mono, USB 3)

Read More...

james_lan created a new topic ' Single Warning about cameras using either RAW or JPEG, and R+J' in the forum. 1 month ago

Reading through posts, I recalled an issue that was driving me nuts when I started using INDI/Ekos: Images were duplicated. They would be fine on the camera, but that was really frustrating on the solver and other issues. I'd have to take a frame, disconnect, reconnect and take another one.

I looked a lot and finally at some point I found a small (very non-prominent) mention somewhere in the documentation that said not to use Raw+JPEG. Which I like for most shooting, as it allows for faster browsing. (Time to load a jpeg from a card is significantly less than a RAW. For frames you are already going to process, it doesn't matter nearly as much.)

So to help new people out, a dismissible warning (similar to the To take a dark frame cover your scope/camera warning/notice) would be good. Possibly an option, which could be on by default, but a save would get rid of?

Read More...

james_lan replied to the topic 'Raspberrypi Camera Driver Raspistill - Searching for teammate' in the forum. 1 month ago

github.com/james-lan/indi/tree/raspiccd

I have started some work on doing this and have gotten images. (Really crappy ones so far) using a V2 and using this library: www.uco.es/investiga/grupos/ava/node/40

After getting those images, I think I'm going to have to either make my own replacement for the library I'm using (tearing into raspistill) or use the raspistill method above.

The more I look at the Raspi cameras the more it looks as ad-hoc as the above code, but I have an understanding of it, which should let me make a decent replacement.

Updates will take a bit.... on the last reboot, the root fs on the SD apparently corrupted.

Read More...

james_lan replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 1 month ago

It was a problem, and it's fixed in most versions marked as 2.9.4 as far as actually triggering multiple times. So that's great. There's the question of why it's called multiple times, but with the code change, it doesn't matter.

Read More...

Login

3rd Party

Choose from the numerous 3rd party INDI drivers to suit your needs!

Got Problem?

Check out the FAQ, the forum, and the bug tracking system to resolve any issues you might have!
You can also subscribe to INDI newsletter and development mailing lists to get the latest updates on INDI!