Current Server Time: 09:55 (Central Europe)

#apertus IRC Channel Logs

2019/09/16

Timezone: UTC


03:20
Yash_Gupta
joined the channel
05:33
Yash_Gupta
left the channel
06:24
Bertl_oO
off to bed now ... have a good one everyone!
06:24
Bertl_oO
changed nick to: Bertl_zZ
07:24
sebix
joined the channel
07:24
sebix
left the channel
07:24
sebix
joined the channel
09:27
comradekingu
joined the channel
10:01
fredy
left the channel
11:14
fredy__
joined the channel
11:57
sebix
left the channel
12:42
RexOrCine
joined the channel
13:36
BAndiT1983|away
changed nick to: BAndiT1983
14:09
BAndiT1983
changed nick to: BAndiT1983|away
14:22
sebastian_
joined the channel
14:27
Bertl_zZ
changed nick to: Bertl
14:27
Bertl
morning folks!
14:30
se6ast1an
good day!
14:33
supraraj
joined the channel
14:33
supraraj
Aloha
14:57
supraraj
left the channel
15:22
futarisIRCcloud
left the channel
15:51
fredy__
left the channel
15:53
fredy
joined the channel
15:59
sraj
joined the channel
16:14
sraj
left the channel
16:57
sebastian_
left the channel
17:03
davidak
joined the channel
17:04
davidak
oh no i'm too late
17:05
se6ast1an
no, we have just been cought in lots of internal discussion and now I need to go to the supermarket :)
17:05
se6ast1an
but we shall really start after my return
17:06
davidak
oh, ok
17:19
supraraj
joined the channel
17:19
supraraj
left the channel
17:20
davidak
i also have to get something to eat, but i have nothing to report, so it's fine to read when i'm back
17:40
davidak
i guickly got a vegan kebab :)
18:11
Bertl
how was the oxymoron? :)
18:22
se6ast1an
I return!
18:23
se6ast1an
so regarding the meeting: Bertl can you give an update on the AXIOM Remote?
18:23
davidak
Bertl, very delicious!
18:23
se6ast1an
current status quo and next steps
18:32
Bertl
sure, during GSoC Nira did some work and testing regarding button debouncing in software
18:32
Bertl
which can potentially reduce the amount of required components dramatically
18:33
Bertl
we currently use hardware debouncing which is basically an RC filter for each button/encoder input
18:34
se6ast1an
can you already give a recommendation regarding the 3 options: software, hardware or a mix of both decouncing methods?
18:34
se6ast1an
to be used in the next hardware revision?
18:35
Bertl
well, the 'mixed' version is not really a big win
18:36
Bertl
i.e. proper RC filter design does get rid of the bouncing in 99.9% of all cases
18:36
Bertl
for perfect debouncing, we would require special hardware
18:36
Bertl
(which is not an option)
18:36
Bertl
the software only approach looks quite promising but is currently missing proper implementation and integration
18:37
Bertl
based on the feedback I got from BAndiT1983, we probably should consider switching from I2C to UART
18:37
se6ast1an
will nira continue working on it now after gsoc?
18:38
Bertl
at least she promised to continue working on it, but haven't heard from her since GSoC ended
18:38
davidak
can you explain shortly what "button debouncing" is? is it to detect a button press only as one press and not multiple?
18:39
Bertl
se6ast1an: where was the wiki page from Nira?
18:39
Bertl
https://wiki.apertus.org/index.php/Software_Button_Debouncing
18:39
Bertl
davidak: this should explain the problem and the proposed solution
18:40
davidak
thanks
18:40
Bertl
specificall this: https://github.com/niratubertc/GSoC/blob/master/Software_button_debouncing.pdf
18:40
se6ast1an
right, for me the thing is that the open questions I had regarding button choices, button illumination, rotary encoder choice and knob design are soon to be answered and I want to evaluate if we have any other open questions/challenges before we could do a V2 prototype hardware plus enclosure
18:41
Bertl
except for the interface decision and the question if we need an additional flash or want some kind of SD interface
18:41
davidak
Bertl, sadly it don't explain what it is
18:41
davidak
i just don't know the term "button debouncing"
18:42
Bertl
section 2.1, reference [5] is not clear enough?
18:42
se6ast1an
davidak: when you press any electric button it doesnt just switch from ON to OFF state or the other way around cleanly
18:42
se6ast1an
rather there are many "bounces" between these states
18:43
se6ast1an
debouncing prevents the effects of this behaviour
18:43
se6ast1an
flash or SD I would currently say no as we can store any additional data/presets/etc. on the connected camera
18:44
davidak
Bertl, that explains it. it's what i expected, good
18:44
se6ast1an
interface would still be usb-c as my prefered option, you wanted to investigate if we need to be able to switch pin out to account for flipping the connector, did you do that already?
18:44
Bertl
good, then I think we should switch to UART for the events
18:45
Bertl
haven't done that yet, but it shouldn't be a big deal
18:45
Bertl
worst case scenario is that we need an additional component to switch the pins
18:46
Bertl
(which should be rather cheap)
18:46
Bertl
but I will try to check till next week
18:46
se6ast1an
great, then we should collaborate on this in the coming weeks to box off the remaining changes/things
18:47
Bertl
sure
18:48
se6ast1an
any news on the USB3 development front?
18:49
Bertl
last time I checked, apurvanandan[m] was communicating with _florent_ with some 'difficulties'
18:49
Bertl
basic problems, as discussed before, are the reliability of the data stream
18:50
Bertl
i.e. it requires selected hardware (on the PC side) an unburdened bus infrastructure and a lot of CPU resources to run
18:50
se6ast1an
right, are there still steps left on the implementation side to actually load/stream image data from the beta?
18:51
Bertl
the integration with the axiom beta codebase is not complete yet
18:51
Bertl
but apurvanandan[m] promised to take care of that
18:52
Bertl
there is also some cooperation in the works to integrate it with Fares encoder
18:54
Bertl
I spent most of my free time in the last two weeks to get a test setup for astronomy applications (e.g. planet validator)
18:54
se6ast1an
great, apurvanandan[m] if you read this later please be so kind and give us an update and ETA if you can
18:54
Bertl
which among other things, included testing the direct sensor cooling
18:55
davidak
Bertl, have you some results in which temperatures the Beta can operate?
18:56
Bertl
we didn't do any specific temperate tests, but it was operated between 5 and 55 deg celsius without problems
18:56
davidak
i think there was a question for low temperatures
18:56
davidak
that's something. thanks
18:57
se6ast1an
and Bertl you mentioned you still need to evaluate the images right? did you record the sensor temperature externally?
18:57
Bertl
http://vserver.13thfloor.at/Stuff/AXIOM/BETA/axiom_beta_sensor_cooling.jpg
18:58
Bertl
this is the current setup for sensor cooling
18:58
Bertl
still without peltiers, but it manages to keep the sensor temperature around ambient plus 2-3 degrees
18:59
Bertl
se6ast1an: we didn't do any external temperature recordings but we have the internal sensor measurements which should be fairly accurate
19:00
Bertl
(just needs a two point calibration to interpret)
19:00
se6ast1an
right
19:01
Bertl
btw, here are the raw images from yesterdays session:
19:01
Bertl
http://files.apertus.org/KUFFNER/
19:03
se6ast1an
great, thanks
19:03
se6ast1an
quick update from the axiom beta compact CAD design front
19:04
se6ast1an
there is some interest from the freecad community to convert the designs to freecad: https://github.com/apertus-open-source-cinema/beta-hardware/issues/6#issuecomment-529706895
19:04
se6ast1an
I have signed up there now and am curious to see how the collaboration turns out: https://forum.freecadweb.org/viewtopic.php?f=8&t=39387
19:05
se6ast1an
on the design front itself I have to solve the problem that due to adding a second optical filter holder into the optical light path the emount part needs to get a lot shorter
19:05
se6ast1an
the area where this becomes a problem is the unlock pin on the bayonet which needs a certain "depth" to operate
19:06
se6ast1an
not sure yet how exactly I will solve that
19:06
se6ast1an
ideas welcome
19:06
Bertl
wouldn't it be better to put the filter holders 'inside' the mount area (as suggested some time ago)?
19:07
se6ast1an
yeah I did consider that carefully but that would a) require quite an amount of additional space I do not have to offer currently and b) not solve the unlock pin issue directly
19:08
se6ast1an
a) could be solved by making the filter holders much smaller but that reduces our options for future larger sensors and or larger lens mounts
19:09
Bertl
good point
19:11
se6ast1an
thats it from the CAD front from me
19:11
se6ast1an
I am preparing to take a timelapse sequence with the remote beta in the darkbox
19:11
Bertl
great news about the freecadprogress
19:11
se6ast1an
have installed a wall clock in view already
19:11
Bertl
*freecad progress
19:11
se6ast1an
but currently battling with the firmware issues to capture a snapshot remotely in an automated way
19:12
Bertl
worked like a charm on the astronomy beta
19:12
se6ast1an
once that is solved I will also attempt to take some interleaved HDR sample snapshots with a pendulum for ugur
19:12
se6ast1an
which firmware version are you running on the astronomy beta currently?
19:13
Bertl
the 'original' one we use to ship with the Betas ATM
19:14
se6ast1an
yeah we know that works :)
19:15
se6ast1an
the goal is to get the new firmware to work reliably!
19:16
Bertl
ah, my bad, thought you want to take pictures
19:16
se6ast1an
:P
19:17
davidak
:D
19:17
se6ast1an
https://www.youtube.com/watch?v=AbSehcT19u0
19:18
Bertl
LOL
19:22
davidak
se6ast1an, can you also update https://www.apertus.org/axiom-beta-status ?
19:22
davidak
i was asked how many axiom betas already exists, but i don't know
19:22
davidak
the map there implies 4
19:23
davidak
but i think there are more dev kits?
19:23
Bertl
yeah, at least five :)
19:23
davidak
:D
19:23
se6ast1an
did you click the map? :)
19:23
davidak
no
19:24
davidak
>This page can't load Google Maps correctly.
19:24
Bertl
it's all about clicking nowadays :)
19:24
davidak
it's not obvious
19:25
Bertl
good user interface design is a lost art ...
19:25
se6ast1an
feel free to suggest an alternative image
19:25
davidak
i count 15 on the map
19:26
davidak
it might be great if you keep track of how many you produce and publish the number
19:26
se6ast1an
not everyone agreed to and was added to the map
19:26
davidak
so people see you do something :D
19:26
se6ast1an
we have shipped slightly below 50 units so far
19:27
davidak
wow, that is more than 5
19:27
Bertl
yeah, about an order of magnitude :)
19:28
davidak
embed the map there instead of that image, so it's always up to date
19:28
Spirit532
left the channel
19:28
davidak
have the actual number under it as text
19:28
davidak
and use openstreetmap
19:28
Bertl
second that, RexOrCine will love to work on that
19:29
davidak
he can also post on social media when you made the 50th
19:30
RexOrCine
More inclined to design a map as was done with APOCs but I suspect it's more than 50 now.
19:30
Spirit532
joined the channel
19:31
davidak
RexOrCine, you can use OSM with different design, but it's more work
19:32
davidak
but then you have a reliable solution that you don't have to update manually
19:32
davidak
not sure if it's worth it
19:33
davidak
i think it's more important to have an up to date map
19:33
RexOrCine
True. I'm more familiar with just plain design and like the control, that why I'd be more inclined, but yes it does need periodic updates... which is ok I guess. Will have another look at this when I'm back in Vienna though.
19:34
davidak
thanks
20:12
namibj
se6ast1an: the filter holder handling I'd suggest would be to offer a way to skip the traditional threaded spacer area and instead stack the filters with a circlip-style holder you could mount the glass element in after extracting from the threaded ring. Twist of a polarization filter would need to be considered. I think focal-plane filters are generally annice and good idea, because some wide lenses
20:12
namibj
can't use front filters. Bonus if a filter wheel could mechanically fit without total lack of structural integrity for the emount-holder (bending the optical axis).
20:15
BAndiT1983|away
changed nick to: BAndiT1983
20:21
Bertl
meeting seems to be over ... off for now ... bbl
20:21
namibj
Bertl: for cooling thst doesn't beed to go below 20~30°C, you might want to consider (flat?) heatpipes, possibly in form of a (possibly modified) laptop cooling setup with wide availability (bending/mounting heatpipes isn't trivial, and the laptop comes with a compact low-noise fan assembly).
20:22
Bertl
the current aluminum plates seem to do the job just fine, no heat pipes required for the sensor
20:22
Bertl
changed nick to: Bertl_oO
20:24
namibj
Yeah, I'm more concerned with thermal resistance vs. weight.
20:52
se6ast1an
namibj: not sure I understand your optical filter idea but please take a look at the current design and create a hand drawing or anything so I can imagine your idea better?
20:52
se6ast1an
https://cad.onshape.com/documents/9aa42c10d73de66c7f7ef0a4/w/d1382fd006d56e4c3066c63f/e/81e10d4de555d5c93d129a74
20:55
BAndiT1983
changed nick to: BAndiT1983|away
20:57
se6ast1an
off to bed
20:57
se6ast1an
good night
21:07
RexOrCine
left the channel
21:25
davidak
left the channel
21:37
namibj
se6ast1an: ok, it wasn't easy to operate the webview on the phone (I'm fighting the way to boot my PC install on spare hardware while repairs are pending), I could navigate to the point where I saw the filter holder plate. My idea would be to make them (optionally, to allow filters to be used with no risky handling) thinner, don't have it contact the glass directly anymore, but instead add a springy clip
21:37
namibj
(basically a ring that would nicely border the bare filter glass without the typical metal filter ring), which has a cut to be pushed open like a circlip to mount it to the glass. Then you'd have this metal-bordered glass circle (that combination is only fractions of a mm thicker than the glass) and the screw-holding spacer of same thickness, which fit sufficiently snugly as to not rattle. You might add a
21:37
namibj
spring where the cutout for the screw is currently in the filter holder to prevent rattling. This would require custom-thickness slabs for each (range of) filter glass thicknessnes, along with this ring-clip that holds the glass with small ridges over the rims of the glass faces. I think 0.1mm split in two 0.05mm thick ridges (measured along the optica axis) (one towards teh sensor, one towards the lens)
21:37
namibj
should be feasible if you can get the tolerances tight enough to cause these clop-rings to actually slightly compress against each other to brace the thin ridges against inertia forces from the filter glass when accelerating along the optical axis.
21:37
namibj
se6ast1an: if this still isn't clear, I'll find a way to illustrate it with drawings.
21:52
namibj
se6ast1an: the other consideration with a filter wheel seems mostly supported. it would require that the plates of the filter stack could be on the edge of a large plate of theet metal the right thickness, without getting blocked or interfering with any part of the camera. I'm not sure that sentence is easy to make sense of, so here a bit more pragmatic: look at how filter wheels for e.g. astronomy are
21:52
namibj
shaped/designed. It would be nice if one would only need to sacrifice two adjacent screws of the front assembly to replace the stack of filter plates with a future custom filter wheel. Thic mostly just needs protusion clearance on one half of the front face of the main body. "half" does not mean leflt, right, top or bottom specifically. It would be fine if it would mean "diagonally, upper left corner" or
21:52
namibj
some other "weird" angle of this dividing line. This is nothing you should compromise any feature you aren't (close to) indiffernt about the location on the front face. It could allow such things as quicly swapping an ND-filter when transitioning a steadycam from inside to outside or the other way around, and that's before one thinks about colors.
21:52
namibj
That'd be it for now, however.
22:40
Spirit532
left the channel
22:40
Spirit532
joined the channel
23:04
futarisIRCcloud
joined the channel