#apertus IRC Channel Logs

good day!

Aloha

no, we have just been cought in lots of internal discussion and now I need to go to the supermarket :)

oh, ok

i guickly got a vegan kebab :)

I return!

Bertl, very delicious!

sure, during GSoC Nira did some work and testing regarding button debouncing in software

we currently use hardware debouncing which is basically an RC filter for each button/encoder input

to be used in the next hardware revision?

i.e. proper RC filter design does get rid of the bouncing in 99.9% of all cases

(which is not an option)

based on the feedback I got from BAndiT1983, we probably should consider switching from I2C to UART

at least she promised to continue working on it, but haven't heard from her since GSoC ended

se6ast1an: where was the wiki page from Nira?

davidak: this should explain the problem and the proposed solution

specificall this: https://github.com/niratubertc/GSoC/blob/master/Software_button_debouncing.pdf

except for the interface decision and the question if we need an additional flash or want some kind of SD interface

i just don't know the term "button debouncing"

davidak: when you press any electric button it doesnt just switch from ON to OFF state or the other way around cleanly

debouncing prevents the effects of this behaviour

Bertl, that explains it. it's what i expected, good

good, then I think we should switch to UART for the events

worst case scenario is that we need an additional component to switch the pins

but I will try to check till next week

sure

last time I checked, apurvanandan[m] was communicating with _florent_ with some 'difficulties'

i.e. it requires selected hardware (on the PC side) an unburdened bus infrastructure and a lot of CPU resources to run

the integration with the axiom beta codebase is not complete yet

there is also some cooperation in the works to integrate it with Fares encoder

great, apurvanandan[m] if you read this later please be so kind and give us an update and ETA if you can

Bertl, have you some results in which temperatures the Beta can operate?

i think there was a question for low temperatures

and Bertl you mentioned you still need to evaluate the images right? did you record the sensor temperature externally?

this is the current setup for sensor cooling

se6ast1an: we didn't do any external temperature recordings but we have the internal sensor measurements which should be fairly accurate

right

http://files.apertus.org/KUFFNER/

quick update from the axiom beta compact CAD design front

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

the area where this becomes a problem is the unlock pin on the bayonet which needs a certain "depth" to operate

ideas welcome

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

good point

I am preparing to take a timelapse sequence with the remote beta in the darkbox

have installed a wall clock in view already

but currently battling with the firmware issues to capture a snapshot remotely in an automated way

once that is solved I will also attempt to take some interleaved HDR sample snapshots with a pendulum for ugur

the 'original' one we use to ship with the Betas ATM

the goal is to get the new firmware to work reliably!

:P

https://www.youtube.com/watch?v=AbSehcT19u0

se6ast1an, can you also update https://www.apertus.org/axiom-beta-status ?

the map there implies 4

yeah, at least five :)

did you click the map? :)

>This page can't load Google Maps correctly.

it's not obvious

feel free to suggest an alternative image

it might be great if you keep track of how many you produce and publish the number

so people see you do something :D

wow, that is more than 5

embed the map there instead of that image, so it's always up to date

have the actual number under it as text

second that, RexOrCine will love to work on that

More inclined to design a map as was done with APOCs but I suspect it's more than 50 now.

RexOrCine, you can use OSM with different design, but it's more work

not sure if it's worth it

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.

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

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).

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?

good night

(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

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.

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

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.