decimal notation of shutter speeds faster than 1/10" don't work

[alxgomz]

After I had some weird results a few days ago while shooting the stars in the night, I did some tests using pktriggercord-cli. I think I have found a problem, unless I'm misunderstanding something (in which please let me know). It looks to me the the shutter speed do not work properly when using decimal notation if the shutter speed is faster than 0.1 sec

On my Pentax K-r (USER Mode, not using Bulb mode) using pktriggercord 0.85.01 $ pktriggercord-cli -t 0.1 -o /tmp/01 # works just fine $ pktriggercord-cli -t 0.04 -o /tmp/004 # gives me another frame of 0.5 sec exposure time $ pktriggercord-cli -t 1/25 -o /tmp/1-25 # works just fine

Actually when using values lower than 0.1 it looks like the pktriggercord don't get it and just reuses the current shutter speed from previous shot.

This is quite problematic because I suspects my astrophotgraphy program (ekos) to pass shutter speeds to libpktriggercord using decimals and to rely on it to choose closest shutter speed

[blemasle]

I've personally never been able to use Ekos to shoot something not using Bulb. Very interested in your finding as it could mean that I could also shoot flats and dark-flats with Ekos.

Well, at least once that massive memory leak is solved :(

I'll give it a try on my K5 to see if it's a camera specific issue. But I suspect your issue is a consequence of an already fixed, but not yet released bug. See https://github.com/asalamon74/pktriggercord/pull/45

[alxgomz]

I wish you were right. But unfortunately I have compiled and installed from master branch and get that very same behaviour.

With regards to Ekos I'm just taking my raw lights and darks with it, for flats and offset it's not an option because of this bug (and maybe others further down the road...)

[blemasle]

I've personally even stopped taking lights and darks with ekos because it can't survive the night If I do so. So I use pktriggercord-cli directly with some bash scripts. Trouble is, as soon as I try to use Ekos again after that it crashes and I have to restart the indi server :/

Anyway, that's another story. I'll try to see if I can reproduce the issue with my K5 as soon as possible :)

[asalamon74]

The camera expects the shutter speed in the format of p/q, hence the program tries to convert the number you enter to this format, but this looks buggy. I'll try to fix it.

[alxgomz]

Hi @asalamon74 , Thanks for taking a look. I checked the pktriggercord-servermode.c (as Ekos seems to uses servermode for its pktriggercord library) as I hoped I could maybe come up with a patch. However I really don't understand the logic behind https://github.com/asalamon74/pktriggercord/blob/338f2d05185329985003f282c493ad4883219429/pktriggercord-servermode.c#L360-L370

If you have a bit of tie to shed a light, that may help.

The same logic is found in pktriggercord-cli.c

[asalamon74]

Oh yes, the code is duplicated in pktriggercord-cli.c and in pktriggercord-servermode.c.

The code expects a floating-point number (%f). if it's lower then 2 it converts to p/10 format. So 0.4 will be 4/10, 1.2 will be 12/10. Otherwise it just use p/1 format, so 25 will be 25/1. As you already tested this will not work for numbers like 0.04 or numbers like 2.9.

A few lines before that the code handles the format 1/p (only integer number) which will be treated as 1/p.

[asalamon74]

I modified the code to understand decimal and rational notion better.

Now it's possible to specify rationals not only in the format of 1/q but p/q. So it's possible to set 3/30 for instance.

For the decimal, I send the value as p/1000 so 0.04 will be sent as 40/1000 and it will be correctly recognized as 1/25.

1/1000 means that very short values should still be sent using the rational format. But I hope it will work for all models (I'm not sure about 1/10000).

The camera (at least my K-x) will convert the value to a "nice" value. So 1/789 will be converted to 1/800.