Current Server Time: 15:15 (Central Europe)

#apertus IRC Channel Logs

2014/11/10

Timezone: UTC


00:36
g3gg0
left the channel
00:55
davidak
left the channel
01:03
wescotte
left the channel
01:48
intracube
left the channel
01:49
intracube
joined the channel
03:02
comradekingu
left the channel
05:10
phobos
joined the channel
05:12
phobos
greetings and aloha: i have been planning to design and implement a camera, and was starting design when i found your "gamma" camera.
05:12
phobos
can anyone here help me decide whether i should help with your "gamma" versus continue on my own?
05:17
phobos
i have many years of hardware, software, optics, mechanical product development behind me. also lots of work with CCDs on large telescopes, and image processing.
05:17
phobos
so... any takers? can anyone discuss the status of the "gamma" camera effort with me?
05:23
intracube
phobos: most of the apertus team are in Europe so it's a bit early in the morning for a response :)
05:27
intracube
the current focus is on the Beta camera. I think plans are to ship it in mid 2015
05:27
intracube
Gamma camera will come sometime after that
05:27
PRN
joined the channel
05:28
intracube
se6astian|away and Bertl_zZ are the guys to speak to about the details
05:29
PRN
phobos: my 2cents: it's more of a philosophical question, you should ask yourself!
05:29
PRN
like do you support open source?
05:30
PRN
if yes, joining the team and helping them the way you can is best
05:31
PRN
contact Bertl/Sebastian for details.....they will be online during Europe day time, as intracube already said
05:32
phobos
i have supported open-source before, sure.
05:34
phobos
i was planning to spend about $100K to develop and implement the camera, so my plan was to generate revenue at the end, but that can still happen with open-source.
05:34
phobos
depending on the philosophies and inclinations of those involved.
05:35
phobos
my primary application was going to be robotics vision systems, but as it turns out, the difference from your "gamma" and my vision doesn't seem to be very much.
05:36
phobos
BTW, what is the time where most of these folks are? 3:40am?
05:37
troy_s
phobos: I suspect the gap between visions is probably enclosure and firmware.
05:37
phobos
yes. i was looking at the cmosis sensors (12mp and 20mp), so that much is similar.
05:37
troy_s
phobos: Not many options there. They are both sub-optimal.
05:38
troy_s
There are at least two folks that frequent here making cameras outside the project.
05:38
phobos
i want to put some very simple (low level) image processing capabilities in the FPGA, which output "clues" that let software in the PC detect and track and identify objects and edges.
05:38
troy_s
One is a stills camera.
05:38
troy_s
What for?
05:39
phobos
because robotics needs to look at one frame, then immediately control physical manipulators to interact with what the camera sees.
05:40
phobos
and if the PC tries to completely process each image on its own, it needs to read every single one of the 12 or 20 million pixels at up to 120FPS before it even starts trying to understand what's in the image.
05:40
intracube
phobos: Austria and central Europe, so 6:40am
05:40
intracube
https://apertus.org/team
05:40
intracube
morning troy_s
05:40
phobos
okay, that's a bit better.
05:41
troy_s
phobos: So not stills, but robotics?
05:41
phobos
i'm usually in hawaii, but currently on the west coast (pacific time zone) at the moment. about 21:40 (9:40pm) here. but i'm a night owl, work all night, wake up late.
05:41
phobos
definitely not stills for me.
05:41
phobos
typically 30FPS to 120FPS.
05:42
troy_s
phobos: Not sure how it would fit in, but reuse is certainly plausible from the imaging side.
05:42
phobos
for cinema, mostly all you need to do is store the image in flash memory for later extraction or download. but in robotics, the images (and clues) need to get to the PC immediately.
05:42
troy_s
phobos: I suspect Bertl_zZ would be able to give a much better picture of the situation as well as tips.
05:42
phobos
so, for example, perhaps 4 * 10Ge running full bore to the PC.
05:43
phobos
you know when he usually gets online?
05:43
troy_s
Surprised someone hasn't tried doing a flip to spline based imaging for robotics.
05:43
troy_s
Try in about five hours.
05:43
phobos
what is "flip to sline"?
05:44
phobos
what is "flip to spline"?
05:44
troy_s
Well a hasty pre-process to a spline based image
05:44
phobos
okay, i never heard of "flip".
05:44
troy_s
Change / convert.
05:45
phobos
mostly what i'm planning to do in FPGA so far is mostly detection of edges and features (hot spots (in each color), cold spots (in each color), and etc).
05:46
troy_s
That is why I was wondering if a hasty conversion to spline might be an interesting experiment.
05:46
phobos
which helps provide the PC enough information to guess how this frame is different from last, and make a good guess about where objects moved from frame to frame, and predict trajectories.
05:46
troy_s
Get planar data shifts easier possibly, as well as fast calculations of optical flow possibly.
05:46
phobos
not sure, haven't looked into that. but off hand, i'd guess that would require more FPGA processing that may be possible.
05:47
troy_s
Maybe.
05:47
phobos
i don't want to adopt a $20,000 FPGA.
05:47
troy_s
Optical flow on splines would seem helluva faster.
05:47
phobos
shooting for $200 to $500 range FPGA.
05:47
troy_s
Because on raster it isnt super.
05:48
phobos
well, i'll have to look into them more before i can comment.
05:48
troy_s
No clue what a 500$ FPGA can do.
05:49
phobos
not as much as a $20,000 FPGA can do. :-)
05:49
troy_s
As much as a 500$ desktop?
05:49
phobos
but... $20,000 is about 10x more than i hope the whole camera costs.
05:49
phobos
well, the FPGA can do a lot in parallel... IF... what you need done is compatible with the FPGA architecture.
05:50
phobos
one problem is, you can't hold 2 or 3 whole 12mp or 20mp images inside an FPGA... at least not with moderate price FPGAs.
05:51
phobos
so, FPGAs are great for computations you can do "on the fly", as the pixels enter from the image sensor and get prepared for storage or packing into ethernet packets or whatever.
05:51
phobos
but... not so good for "whole image" much less "compare this frame with last" type work.
05:52
phobos
but... an FPGA is great for providing "tips" and "clues" about the current image coming off the FPGA, and those "tips" and "clues" from this frame can be compared to last frame, and that can provide a huge boost in efficiency in the PC.
05:53
phobos
i guess one way to look at FPGAs is to say... a $500 FPGA can perform certain processes vastly more and faster than a $500 PC, but only those certain processes.
05:55
phobos
while it has become popular to put CPUs inside FPGAs, they get very, very expensive... very, very quickly. which is fine if you're building million dollar MRI machines or something, but not for $1000 to $5000 cameras.
05:55
phobos
BTW, who has been mostly working with the image sensors?
06:02
phobos
i'm not sure how important it will be, but i also invented a lossless compression technique for image sensor output.
06:03
phobos
the compression ratio sucks compared to lossy techniques, but it can at least "make the CF last longer" or "push more over 10Ge or USB3 or SATAIII per second".
06:03
phobos
i already made that public a few years ago, but don't know whether it made its way to apertus, or whether anyone at apertus would even care.
06:04
phobos
but... i do get the impression apertus folks do value "no compression artifacts".
06:05
phobos
in my opinion, an uncompressed 2.5K image is better than a 4K compressed image.
06:10
intracube
left the channel
06:14
intracube
joined the channel
06:20
PRN
better to project on a 4k platform?
06:23
phobos
could you rephrase that?
06:24
phobos
my focus is 4K to 5K sensors, and eventually 8K sensors.
06:25
PRN
a 2.5k image is better when projected on a 4k projector than a 4k compressed image?
06:25
PRN
and please define "better" here!
06:26
PRN
also how "compressed" we are talking about here?
06:30
phobos
well, in this case i'm talking about cinema, which means to me "what the image looks like to a human being".
06:31
phobos
but i did some image processing projects for NASA, and practically went nuts when i found that virtually everything i tried enhanced the damn compression artifacts more than any real/useful information in the images.
06:32
phobos
the compression ratio totally sucks compared to ANY lossy compression. typically it was about 20%.
06:32
phobos
which for a previous project i did was the difference between being able to shove the image data through 1Ge, and not being able to.
06:33
phobos
the virtue of the compression technique is... how simple it is to implement in an FPGA to run at real time (compress as quickly as the pixels arrive from the image sensor).
06:34
phobos
and on the other end (in the PC), it only takes a few lines of C (or several CPU machine instructions) to decompress back to original form.
06:34
PRN
Okay, as we are talking about cinema here: even after the DI process(where the raw capabilities are fully used), we anyway have to do heavy compression for the final dcp.
06:34
phobos
and the technique only works on images (still or video).
06:35
PRN
which gives all the compression artefacts end of the day. Am I missing anything?
06:35
phobos
what "gives all the compression artifacts"?
06:36
phobos
since it is lossless, the final result is exactly what came off the image sensor. exactly, bit for bit.
06:38
phobos
what is "final dcp"?
06:41
phobos
if i understand your point (not sure), many image processing techniques work vastly better on uncompressed images.
06:42
phobos
and so, the result of performing image processing on uncompressed images, then compressing to generate a final result... often generates much better looking images than performing all the image processing on compressed images.
06:42
phobos
but... maybe i misunderstand you.
06:48
PRN
I will tell you my experience, on epic i've done tests with compression ratios of RC2:1 to 18:1. I could not differentiate RC2:1 to RC7:1 when projected on a 4k sony projector for my naked eye
06:50
PRN
my point about compression artefacts was: at somepoint during post production of cinema, you are doing the heavy compression
06:51
PRN
age processing on uncompressed images, then compressing to generate a final result... often generates much better looking images than performing all the image processing on compressed images.:: Yes I agree with you
06:53
PRN
but my question is: how better would it be? as, its a pain to handle a terabyte of data at the end of one day shoot. is the quality worth the pain?
06:53
phobos
one thing i don't know (cinema not being my focus), is whether every cinema application performs compression.
06:53
phobos
if i go watch a high-end movie at a movie theater with the most modern equipment, am i seeing an image that was uncompressed in the projector system?
06:54
PRN
you can do the color correction on raw image as of today, though it takes humongous amounts of resources and hence money
06:54
PRN
nope you are watching heavily compressed image on the projector system
06:56
phobos
also, i always look at individual frames. it might be that artifacts tend to blur and cancel (due to the nature of human vision) when flashed at 48 or 60 frames per second (or more).
06:57
phobos
my personal interest in lossless compression was to move the data from camera to computer faster, without loss of information during that process, or during image processing on the PC.
06:58
phobos
i can't remember what it was any more, but i looked at a website that showed some uncompressed video and compressed video from video cameras with the same sensor, and the difference was quite obvious.
06:59
phobos
sorry i can't remember what website that was any more.
07:18
PRN
left the channel
07:43
Bertl_zZ
changed nick to: Bertl
07:43
Bertl
morning folks!
07:50
intracube
morning Bertl :)
07:50
Bertl
phobos: but most likely, the data was uncompressed during all post processing up to the moment where it finally got encoded :)
07:50
phobos
hello there.
07:50
Bertl
phobos, troy_s: we have at least one person (probably two) interested in computer vision/robotics as well
07:50
phobos
the late night crowd said i need to chat with you Bertl.
07:51
Bertl
yeah, I read up on the chat
07:51
phobos
oh, good that you can see that. saves my fingers.
07:51
Bertl
there is an online IRC log as well
07:52
Bertl
so, let
07:52
phobos
yes. well, since you've read a lot of my babble already, do you have any comments to get us started?
07:54
Bertl
as you already stated that FOSS/OH wouldn't be a problem for you, it seems to me that you might want to go for the AXIOM project (may it be Beta or Gamma)
07:54
Bertl
after all, the idea behind the AXIOM is to allow you to control every part of the system, including the FPGA
07:55
Bertl
(especially as you have been looking at identical sensor options)
07:56
Bertl
but let's do it the other way round, what problems do you see by e.g. using the AXIOM for your purposes?
07:57
phobos
yes, it looks plausible, especially the gamma. but i have a few questions just to get my head in the right place.
07:57
Bertl
go ahead then, ask
07:58
phobos
well, some of this is questions, some is just throwing ideas out so we can brainstorm to a solution.
07:58
phobos
it seems i do not attach as much value to extreme modularity.
07:59
phobos
i tend to prefer to put as much functionality as i can in the smallest volume i can (with the least number of connectors, etc).
07:59
Bertl
okay, fair enough
07:59
phobos
however, for development and testing, sometimes a modular approach is easier, and a more integrated product can be created after the fact.
08:00
Bertl
you've seen the Beta size?
08:00
phobos
i was looking, for example, at the 4-or-8 core 64-bit AMD ARM Soc chip.
08:00
phobos
i see photos on your website of course, and have a fairly good idea from that.
08:01
Bertl
so the sensor/interface board is about 60x60mm
08:01
phobos
my point of that AMD "Seattle" chip is... it contains something like (from memory): 8 * SATAIII, 2 * 10Ge, 1 * 1Ge, 8 * PCIe gen3/2/1, UART, SPI, I2C... and more i'm forgetting.
08:02
phobos
in the beta? and you want the same for gamma?
08:02
Bertl
it will be similar for the Gamma, yes
08:03
Bertl
but note: we are currently working on the Beta, so that is something we are designing right now, while the Gamma is more a vision
08:03
Bertl
also note: we plan to do a Parallella version of the Beta
08:03
phobos
from the time-frame diagram, it looks like the beta will be done in 5 or 6 months. so the design must be done, or close.
08:04
Bertl
we are faster than you might expect :)
08:04
phobos
you'll be done in a couple months?
08:04
ItsMeLenny
joined the channel
08:04
Bertl
I just returned from Mexico giving a talk at the TAG event about building the AXIOM Alpha from scratch in six months :)
08:05
phobos
and i fear jumping in on beta, because i'd almost certainly land on somebody's toes! :-)
08:05
Bertl
that's fine
08:06
Bertl
the idea behind the Beta is to get something you can easily adapt to your specific needs and something we can test with in real world situations
08:06
phobos
my point with the Seattle chip, for example, is that you can have multiple outputs for SATAIII, multiple outputs for 10Ge, multiple outputs for other I/O standards and who knows what else.... all on one PCB.
08:06
Bertl
it might not be that the Beta is exactly what you want, but you can extend it and shape it, even if we disagree on certain decisions
08:07
phobos
however, 60mm square is a bit smaller than i was thinking about before i looked at your project, so the abundance of connectors might just not work on such a tiny PCB.
08:07
Bertl
for example, if you don't like the 16 epiphany cores for processing
08:07
Bertl
(which would be there in the Parallella setup)
08:07
phobos
what are they? a cpu inside the xilinx FPGA?
08:08
Bertl
http://www.parallella.org/board/
08:08
phobos
in my designs, i've gone the opposite direction (sorta). for example, i've tried to stay with cheap FPGAs (no CPUs, no transceivers), and adopt slow interfaces like XGMII for 4 * 10Ge.
08:08
Bertl
they are connected to the FPGA
08:09
phobos
in my investigations, when you add more features (CPUs, etc) and faster transceivers to FPGAs, their costs go up exponentially.
08:09
Bertl
correct
08:09
phobos
not, my focus has been altera, but i would imagine this is universally true, since they compete.
08:09
phobos
sorry, start that previous sentence with "now, my..."
08:10
Bertl
the Beta will feature the Zynq 7010/7020 and 7015 (4 MGT)
08:10
Bertl
but there is no reason why you couldn't use an Altera FPGA as well
08:10
phobos
what is 4 MGT. 4 million gigabit per second transfers?
08:11
Bertl
4 Multi Gigabit Tranceivers
08:11
phobos
what is a "multi-gigabit transceiver". you mean like the 3Gbps and 6Gbps transceivers?
08:11
comradekingu
joined the channel
08:11
Bertl
Our main reason for going Xilinx (so far) has been that the development boards are reasonably priced
08:11
Bertl
and the hardened arm cores simplify testing
08:11
phobos
i see. the altera development boards looked cheap as hell too (to me).
08:12
phobos
it is in their interest... to suck people in.
08:12
Bertl
all we found back then costed about 2000-3000 USD
08:12
Bertl
while the MicroZed is about 250 USD :)
08:13
phobos
yeah, you see, by going with the slow XGMII interface for 10Ge PHYs, i was able to adopt a $160 FPGA.
08:13
phobos
oh, sorry. some of the development boards were like $180.
08:13
phobos
but... if you want some of the super-duper features ones, they are about $2000.
08:13
phobos
yes.
08:14
phobos
but personally, i expect to spend about $100K on this project, so i would never let $2000 change my design choices.
08:14
Bertl
careful, we are using the MicroZed in the Beta design
08:14
comradekingu
Can i make a task to rewrite this? https://www.apertus.org/forums/ucp.php?mode=register
08:14
Bertl
so it would be a $1800 price difference for the Beta
08:15
phobos
i'll have to look up MicroZed. BTW, what are those connectors you adopted for module to module (PCB to PCB) ?
08:15
Bertl
comradekingu: probably
08:15
Bertl
phobos: but if you find the time, please check out the MicroZed and PicoZed (feature wise) and make a suggestion for a similar Altera board
08:15
phobos
but... what does the development board have to do with the beta? you actually put a Xilinx development board INTO the camera?
08:16
Bertl
yes
08:16
comradekingu
challenge accepted
08:16
phobos
okay, i'll look them up and compare.
08:16
Bertl
phobos: the AXIOM Beta is designed for developers and early adopters
08:17
Bertl
so having a development board there makes perfect sense (at least to us :)
08:17
phobos
but... i must say... i would make ALL my designs based upon what is best (features and price) for the final product, not the development process.
08:17
Bertl
which is what the Gamma is about
08:17
phobos
except... i don't have enough savings to ever create an ASIC for the project. :-(
08:18
Bertl
i.e. different goals
08:18
phobos
yeah, that's what it looked like.
08:18
Bertl
Beta = development and experimentation
08:18
Bertl
Gamma = professional end user equippment
08:18
phobos
i don't think I should want to influence your beta design at this point!
08:19
phobos
unless you really haven't started. but even then, i don't like stepping on toes.
08:19
phobos
i'm sure lots of people have spent lots of time coming up to speed on the sensors and FPGAs and development tools for the beta already.
08:20
phobos
unless... i have a totally wrong idea from the website.
08:20
phobos
is the beta more for experimentation with shooting with these sensors... or learning about how to design a device like these cameras?
08:22
Bertl
experimentation with the camera itself
08:22
Bertl
as we did the proof of concept design with the AXIOM Alpha
08:23
Bertl
but of course, we will also use it to improve on the Gamma design
08:24
Bertl
but as I said, don't worry too much about stepping on somebodys toes, be polite (if possible), be reasonable and bring good arguments
08:25
Bertl
we are easily convinced by good arguments and we have no problem adjusting our designs if there is a good reason for it
08:26
comradekingu
<3
08:26
Bertl
we do not plan to satisfy every concept and idea brought up here, but we will definitely look into it
08:27
phobos
but... i have to assume it is too late, or almost so, to muck around with the "beta" design at this point.
08:27
Bertl
phobos: judging from what you want to do, you might be interested in helping/working on the Beta Interface Board, while considering adding your own 'Beta Board' design with one of those AMD chips on it
08:28
Bertl
(unless you're more happy with utilizing the 16/64 epiphany cores for computer vision)
08:29
phobos
i should probably ask about how data gets shipped around (typically). recorded onto internal flash then transmitted? stored on n * CF which are then removed and inserted into a PC. or... oh, now i remember some odd connectors on the beta.
08:37
phobos
well, if i was to put one of those Seattle chips on an alternate beta interface board, it could provide up to 8*SATA3 and/or 2*10Ge and/or 8xPCIe (gen3/2/1). but probably isn't optimal for those connectors you show.
08:39
Bertl
the connectors are to the Interface and Sensor Board
08:39
Bertl
(assuming you are looking at the right pictures :)
08:40
Bertl
http://vserver.13thfloor.at/Stuff/AXIOM/BETA/axiom_beta_sensor_cmv12000_v0.9_all.png
08:40
Bertl
http://vserver.13thfloor.at/Stuff/AXIOM/BETA/axiom_beta_interface_cmv12000_v0.3_all.png
08:40
Bertl
you might also look at the Beta Shield connectors, which would not affect you in this case, but you could adopt that interface as well
08:42
g3gg0
joined the channel
08:42
Bertl
regarding data flow: no, we do not plan to store it on CF
08:43
Bertl
that would be way too slow for the datarates we plan to handle
08:43
lab-bot
allan created T145: Rewrite EULA for forum registration. http://lab.apertus.org/T145
08:43
Bertl
internal recording is not planned for the Beta, it will be part of the Gamma though
08:45
Bertl
hey g3gg0! how's going?
08:57
comradekingu
http://lab.apertus.org/T145 supplied with suggestion for new forum registration text
08:57
phobos
yeah, the beta has 3x HDMI. that's an interface i haven't worked with, and don't know what interface chips are available for (or FPGA IP).
08:58
Bertl
we've written our own IP for the FPGA and there are chips from Analog devices for it as well
08:58
phobos
do you expect most customers will want (primarily or only) CF storage for the gamma? or not?
08:58
Bertl
I think on the gamma we will use small SSDs (1.8" or maybe 2.5") in a raid setup
08:59
phobos
do you envision a default, or every option is an interchangable module?
09:00
Bertl
for the Gamma it will be a module, yes
09:00
Bertl
but I guess it will be a very popular one :)
09:01
phobos
have you considered (maybe) making the PCBs a bit higher in the gamma? i assume you choose 60mm width to support 3D, right?
09:02
phobos
though there's no requirement to exactly center the sensor of the PCB stack.
09:02
phobos
... "over the PCB stack".
09:03
Bertl
for the gamma, we haven't decided yet on the exact size, but it would make sense in the 60x60mm area
09:03
Bertl
it might still be, as you said, like 60x90 or so
09:03
Bertl
we will see when we get there :)
09:04
phobos
the problem with 60x60 is... if you want to have a number of connectors, there's almost no room left for anything else.
09:04
phobos
and, as i understand it, you already have two pretty large connectors between the PCBs.
09:08
Bertl
yes, we'll see how it works for the Beta Interface PCB, if it turns out to be a real limitation, we'll change it
09:24
Bertl
phobos: you do not need to decide for or against the Beta, just decide if you like to hang around and more importantly if you like to share your ideas and concerns
09:25
phobos
sure. but if i do this, it will be 80+ hours per week and all i do for a year. so, i may not be approaching this exactly the same way as is typical.
09:25
phobos
not sure about that, of course.
09:25
phobos
maybe some of you do that too.
09:25
phobos
but product development is what i do.
09:26
phobos
i'm in my brainstorming phase on this right now, but once my tires hit the ground, there'll be streaks on the road.
09:28
Bertl
no problem there ... if product development and making big bucks is all you care about, then so be it ... most likely the Beta will not fit your goals there though :)
09:28
phobos
as far that interface for the beta, my first question is about how many people will have an interface on their PC (as opposed to their monitors).
09:29
phobos
well, big bucks is never my goal, i have other reasons to get this stuff done. but i do want to at least earn back my time spent.
09:29
Bertl
we have surpassed our crowdfunding goal and added a bunch of stretch goals, one being a PC based recording solution
09:30
phobos
nonetheless, i don't see why open-source won't work in a hardware project, and still leave room to sell differentiated physical products and make some money.
09:30
Bertl
that is very true, and you still can make good money with services around the "product"
09:30
phobos
i haven't done open-hardware before though, just open-source software, so... probably i need to make sure there are no "issues".
09:31
phobos
what i was thinking, is it doesn't matter whether i give everything i do away to you guys, as long as i can repackage the components i want into a different physical package, add robotics software, and sell it.
09:31
Bertl
there is no viral component in the Cern OHL we are using, if you are referring to that
09:32
phobos
no, i just don't know what differences might exist in the open-hardware agreements versus open-source software agreements.
09:32
phobos
like, if we get gamma working, and i take design aspects, layout new PCBs and design a new case... do my PCBs and case become free for anyone else to make?
09:33
Bertl
but in general I think it makes sense to have a basic design you can build upon instead of re-inventing the wheel over and over again
09:33
phobos
sure does.
09:33
phobos
i don't completely understand the significance of your statement "there is no viral component in the Cern OHL".
09:34
Bertl
no, your designs do not automatically become free, although I would hope that you open them up to the public as well
09:35
Bertl
and of course, you cannot patent or register your designs if they are based on open hardware, but I guess that part is obvious
09:35
phobos
probably some or most. but maybe i'd add some image recognition firmware for robotics and create some integrated (not modular) robotics-optimized cameras.
09:35
Bertl
no problem there at all
09:36
phobos
while i can imagine that very likely nobody would copy them, and so i could sell and make some payback, there's no guarantee if my extra firmware automatically becomes freely available (and my case designs, etc).
09:36
Bertl
the OHL (open hardware license) does in no way affect the software
09:36
phobos
i would, of course, know that everything i did to help create gamma was totally open.
09:37
Bertl
the software coming from our side is covered by a different license (GPL) which is stricter in the case of derived development
09:37
phobos
one thing i developed a few years ago was a lossless image compression technique, to reduce storage requirements and transmission rates (for robotics).
09:37
Bertl
but it also leaves a lot of options to build your software around it
09:38
phobos
i already opened that up to the public, though i have no idea how many people picked up on that.
09:38
Bertl
just for reference, do you have an url for that?
09:38
phobos
if it helps gamma (and/or beta), that's great.
09:38
Bertl
(might be interesting for the folks working on robotic vision)
09:38
phobos
sadly, the compression ratio is terrible compared to lossy techniques.
09:39
Bertl
well, that's not unexpected
09:39
phobos
no, but i can send something to you.
09:40
phobos
in my case, the small degree of compression saved my butt... made it possible to send images via 1Ge at full speed. otherwise, would have fallen just short.
09:41
phobos
i called it "delta compression", because the basic idea is to store a smaller "delta" value for each pixel instead of the absolute value of the pixel intensity.
09:41
Bertl
ah, yes, I remeber the email :)
09:41
phobos
the compression ratio sucks, but it is mind-numbingly simple to implement in FPGA (in real time as the pixels enter the FPGA).
09:41
Bertl
*remember
09:42
phobos
did i already send this to you in the past? hahaha.
09:42
Bertl
unless I have a dejavu moment, yes :)
09:43
phobos
in my case, what it did was this. for each 12-bit pixel, if the change in intensity was +/- 119 from the previous value (of same pixel color), then just save the 8-bit delta (plus an offset to make the range 0x10 to 0xFD).
09:43
Bertl
but you didn't send any links or code or documentation, just the info
09:43
phobos
otherwise you have to send 16-bits for the pixel, 4-bits of zero in the upper nybble, and the full 12-bit pixel value in the low 12-bits.
09:44
phobos
so... more pixels compress than expand, and that's how you win.
09:44
phobos
it only takes the CPU on modern PCs a few machine instructions per pixel to decompress.
09:44
phobos
anyway, if you provide an email address, i can send you a coherent description.
09:45
Bertl
you sent an email as 'Max' to the team, I just looked it up
09:45
phobos
well, i didn't publicize it, i just gave it away to a few people and said "consider it public domain".
09:45
phobos
oh, the recent message? i thought that didn't get through.
09:45
Bertl
yes, please do so, you can send it to team.at.apertus.dot.org
09:46
phobos
can i send a PDF attachment?
09:46
Bertl
sure, no problem
09:47
phobos
okay, i'll do that in the next day or so.
09:47
Bertl
but make sure that you have a proper license on your code or design or whatever, so that it can be used without problems (under whatever conditions you see fit)
09:49
Bertl
regarding email: it got through but it wasn't answered yet as far as I can tell
09:52
phobos
okay, i just sent a PDF that has a bunch of "background thinking" on the first few pages that you can ignore, but then has a couple pages about the image compression technique.
09:53
phobos
back when i invented this, i got a variety of uncompressed images and compressed and decompressed them to test my code and compression ratios, but i haven't done anything since.
09:54
phobos
whether i can even find my old code is unknown, but i'm almost certain i could write new code faster than dig through old disks and backup DVDs.
09:54
phobos
it really is that simple.
09:55
phobos
probably no need to answer the email at this point, unless there's something in there i forgot.
09:55
Bertl
okay :)
09:56
phobos
i just typed into your website, so i don't have a copy of what i typed! hahaha.
09:56
Bertl
I can send you a copy :)
09:57
phobos
well, i've released open-source applications before, but this was so simple and short, i just told the people i gave it to, to consider it public domain (without guarantees, of course).
09:58
phobos
if anyone wants help putting the compression part into your FPGA, they should contact me. if someone needs C code to decompress, i can write that in a few minutes.
09:59
phobos
the one factoid implementor need to remember is... the delta is always from the previous pixels OF THE SAME COLOR. in monochrome, that's the previous pixel, but in bayer that's the pixel before last.
09:59
phobos
forget that little detail, and it anti-compresses! hahaha.
10:00
Bertl
yeah, makes sense
10:00
phobos
i don't need a copy unless you think i do.
10:01
Bertl
okay, no problem then
10:03
Bertl
so, one maybe interesting area for you might be the Beta Interface board
10:03
Bertl
it basically goes between the sensor and the main Beta board
10:04
Bertl
and it is designed to create a common sensor independant interface to the main board
10:04
Bertl
we plan to utilize a low power FPGA on that board to preprocess and shape the sensor data before it is sent over to the main board
10:07
phobos
you want to have a sensor independent interface to the main board. presumably you don't mean it has a fixed number of channels (unless that number is a maximum, say, 64 channels).
10:07
Bertl
the interface to the sensor board has 80 LVDS pairs
10:07
phobos
and what is on the "main board"? circuits to send the data out through those 3 HDMI connectors?
10:07
phobos
including clock signals.
10:08
phobos
so 64 data and 16 clocks.
10:08
Bertl
the interface to the main board has 36 LVDS pairs
10:08
Bertl
most sensors communicate with 300-600MHz
10:08
phobos
so the interface matches the CMV12000 and you expect all future sensors will be compatible with that?
10:09
Bertl
no, but most sensors we have been looking at match the interface
10:09
phobos
obviously you can send CMV20000 over that, because it only has 16 LVDS for data.
10:09
Bertl
we do not expect all future sensors to work with it, but most LVDS based sensors will
10:10
Bertl
main target for the Beta are the CMOSIS sensors CMV2/4/8/12/20k
10:10
Bertl
and the KAC 12040
10:11
phobos
so, we have "sensor PCB" ==>> "FPGA PCB" ==>> "main PCB" (which at first, i guess, just sends the data out through those 3 * HDMI connectors)?
10:11
phobos
okay, i've only looked at the CMV12000 and CMV20000, so i don't know those others yet.
10:12
phobos
are you going to allow a peltier behind the sensor?
10:12
Bertl
I will upload an interface diagram soon (probably tonight) which will explain the interconnections better
10:12
phobos
or at least some other way to suck heat out of the sensor.
10:13
Bertl
you could put a peltier behind the sensor, but IMHO it's better/easier to put it on the side
10:13
phobos
okay, cool.
10:13
Bertl
there is a metal plate planned covering all the front of the sensor board
10:13
Bertl
(with direct context with the sensor base)
10:13
phobos
have some kind of liquid-filled pipe to the sensor?
10:14
Bertl
it can be easily extended to the side or top of the camera
10:14
phobos
okay, yeah.
10:14
Bertl
and either use heat pipes or peltier to transport the heat away
10:14
phobos
is there room in the gamma to put the peltier beside rather than behind?
10:15
phobos
do you have a nominal case diameter for the gamma? when i look at the nice 3D rendering of the gamma, what was the outside diameter of that case?
10:16
Bertl
no fixed sizes for the Gamma yet, but check with se6astian|away (when he comes back), he has all the data about the "current" design
10:16
phobos
are you saying the cooler might be a separate case that attaches outside the camera case itself?
10:16
Bertl
yes, for the Beta we will investigate different cooling options
10:17
Bertl
and we plan to have an optional fan on the top of the camera
10:17
Bertl
(the same place might as well be used for a peltier with heat sink)
10:19
phobos
is there a desire to keep the camera as short as possible? when i ask these questions, i'm always asking about gamma.
10:19
Bertl
no desire to keep it short for the Gamma
10:19
phobos
as well as small in width and height, obviously.
10:20
Bertl
the professional cinema movie folks do not really care that much about small
10:20
phobos
i guess i'm asking about ergonomics here, specifically for cinema purposes.
10:21
phobos
is the small width and height considered important too? i just wonder about all those 3 directions, what people think about making them bigger (or smaller).
10:21
Bertl
but we do not plan to make it larger than necessary for several reasons. nevertheless, it might get a larger case than the actual electronics require
10:22
phobos
did somebody have a big brainstorming session about all that, somewhere along the line?
10:22
Bertl
the Gamma design is a vision at the moment, nothing more
10:23
Bertl
we have brainstorming sessions all the time, mostly here on the channel
10:23
phobos
the main reason i ask is this. when designing devices with small PCBs, you approach a point where interconnect between PCBs consume most of the volume in the device.
10:23
Bertl
naturally
10:25
phobos
so, for example, to be a bit "crazy" now... if we make a long PCB that is only 60mm or 90mm wide, that could be put in a "long" module (perhaps even with 3 or 4 PCBs oriented that way).
10:25
phobos
this just seems like one of those cases (pun) where the ergonomic considerations are pushing in the opposite direction as "electronics efficiency". do you feel that's true?
10:27
phobos
in other words, if the gamma was more like the shape of the blackmagic, the PCBs could be much larger (and thus more efficient, volume wise). but i have to assume you guys really don't like that approach. am i correct?
10:27
Bertl
I think something like 60x150 would be an option if there is a good reason for it
10:27
phobos
you mean the case would be something like 70mm wide by 160mm high by who-knows-how-long?
10:27
Bertl
the problem I see with long, small PCBs is that they tend to have many long traces covering most of the PCB area
10:28
Bertl
as probably the interconnect will be at the edges
10:28
phobos
yes to that too.
10:28
phobos
obviously the best from an electronics point of view (ergonomics aside), is big honking square PCBs.
10:28
Bertl
yeah :)
10:29
phobos
i can see why people want a narrow case (3D for one). i don't see an obvious reason the case couldn't be tall... except it might look really stupid.
10:29
Bertl
yes, no problem there as I said
10:30
phobos
and deep... doesn't seem important.
10:30
Bertl
there is actually a good reason for making it taller
10:30
Bertl
because as troy_s can explain to you, cinema folks expect a specific hight for the lense/sensor center
10:30
phobos
hmmmm... this really is tough.
10:31
phobos
what size are the PCBs in the beta, just for comparison?
10:31
Bertl
http://vserver.13thfloor.at/Stuff/AXIOM/BETA/axiom_beta_sensor_cmv12000_v0.9_all.png (the measurements are around the PCB)
10:32
Bertl
this is for sensor and interface, the main board matches the size of the MicroZed
10:32
phobos
you mean they want the centerline of the optical system to be a certain distance above the base of the camera (that attaches to the tripod top plate)?
10:32
Bertl
yes, precisely
10:32
Bertl
to match other equippment usually rigged up around the camera
10:32
Bertl
(there should be some entries on the wiki and tasks in the lab)
10:32
phobos
say what? you eurogeeks are working in inches? seriously? hahahaha :-o
10:33
Bertl
we are working in inches, mils, mm :)
10:33
Bertl
kind of the result of electronic parts and devices still using both
10:34
phobos
sorry, i always thought you guys were lightyears ahead in that department.
10:34
Bertl
take the sensor, it is a µPGA with 1.27mm pin distance :)
10:36
phobos
okay, and this is nominally what you expect ALL the gamma PCBs to look like (in size and corner holes)... unless you change your minds?
10:37
Bertl
no, not at all
10:38
Bertl
but it will give us an idea what sizes make sense
10:38
Bertl
and it seems to be sufficient for the Beta
10:38
phobos
is there a search function to help me look through past brainstorming sessions (based upon keywords like "case")?
10:39
Bertl
google
10:39
phobos
okay, and limit that with "site:whatever"?
10:39
Bertl
case site:irc.apertus.org
10:39
Bertl
or better enclosure
10:40
phobos
like: case site:irc.apertus.org ?
10:40
phobos
okay, beat me to it.
10:41
phobos
okay.
10:41
Bertl
a lot of information can also be found on the mailing lists and of course on the wiki
10:42
Bertl
(you might want to search there as well)
10:43
phobos
mailing lists?
10:44
Bertl
yes, there is a development mailing list (and some others as well) on google
10:44
phobos
is this IRC what you call the "mailing lists"?
10:45
Bertl
IRC is where you are now (Internet Relay Chat)
10:45
phobos
so, what? google "apertus development mailing list"?
10:46
Bertl
https://www.apertus.org/mailinglists
10:47
Bertl
please contact se6astian|away to subscribe you to the axiom-dev mailing list if there is interest
10:47
phobos
right, so being a techie, i want to be on axiom-dev@googlegroups.com .
10:48
phobos
in general, does more happen in here, or in that axiom-dev forum? where should i spend my time, do you think?
10:50
Bertl
IRC is definitely the main place for communication nowadays
10:50
phobos
okay.
10:50
Bertl
tasks, wishes and collections of thought go to "the lab" or on the wiki
10:50
Bertl
(http://lab.apertus.org/)
10:52
phobos
and when you said you were going to upload an interface diagram, where will that appear?
10:53
Bertl
probably on my file server first, but it will end up on wiki or lab pages as well
10:55
phobos
so let's say i was going to write some code for the lossless compression algorithm. is this labs where that should go?
10:56
Bertl
actually code goes to the github repository for now
10:56
Bertl
but a design or explanation or just idea would best be handled on the lab or in the wiki
10:58
Bertl
the lab is quite new, so we are still getting used to it
10:58
phobos
i suppose i should make a confession. my previous open-source experience was releasing competed working software i had already completed. so i'm feeling a bit overwhelmed at how much stuff there is in many places in an open-project like this!
10:59
phobos
i wonder if coordination isn't 10x more work than the project! :-o
10:59
phobos
maybe it will all feel normal in a month.
11:00
Bertl
at least not for now, just focus on IRC, everything else will be either linked or referenced
11:00
Bertl
(like I already did with a number of links :)
11:03
phobos
okay.
11:25
davidak1
left the channel
11:45
phobos
left the channel
12:01
intracube
left the channel
12:07
intracube
joined the channel
12:24
davidak
joined the channel
12:26
Bertl
changed nick to: Bertl_oO
12:53
Rebelj12a
joined the channel
12:54
Rebelj12a
There are a lot of obstacles when collaborating with someone from a different country in a project.
12:55
Rebelj12a
Not this project mind you a different one. Translator sends Japanese and English back and forth basically. D:
13:16
se6astian|away
changed nick to: se6astian
14:18
designbybeck
joined the channel
14:36
Rebelj12a
left the channel
15:01
ItsMeLenny
left the channel
15:02
Rebelj12a
joined the channel
15:04
Rebelj12a
Also, in any case… your going to like this. I need to do Mocap for a scene… yay… literally like… maybe 5 second part of a clip. Fantastic.
15:04
Rebelj12a
Well plus character scan and beheading. fun stuff
15:06
Rebelj12a
Although, im probably way out of my depth.
15:06
Rebelj12a
Also I have a fellow who made his own jib crane. Has a tutorial video, pdf and tips. Ill be adding it to the wiki.
15:07
Bertl_oO
well, English is quite common for technical folks, but I can imagine that being a problem
15:08
Rebelj12a
Hah yeah in response to my other one. Yeah its difficult. Well hes japanese and a writer/fashion designer and a bit older so.
15:09
aombk2
joined the channel
15:09
Rebelj12a
Between attempting to license japanese music… and trying to hit my network contacts for anyone I know in japan for picture of places mentioned in an interview yeah. Difficult XD
15:11
Rebelj12a
Sorry about the other post, that was for troy we were discussing compositing and vfx XD
15:12
aombk
left the channel
15:20
Bertl_oO
no problem
15:21
Rebelj12a
But yeah networking trying to gather as much info as I can for the wiki. Unfortunately swamped lately so I cant just sit down and organize the thing. But once its all done for the winter (nobody does much in the winter here) Should have plenty of time.
15:24
intracube_
joined the channel
15:27
intracube
left the channel
15:27
Rebelj12a
There was a program, someone linked me. An irc client that runs off server. You connect to the server instance and can access it anywhere without logging off and logging back in type thing. Anybody know what that might be?
15:28
Rebelj12a
I had a link but I forgot what it was hmm
15:28
intracube_
changed nick to: intracube
15:28
Bertl_oO
there are several actually, there is miau and there is bip
15:28
Rebelj12a
Hah open for suggestions on the best one?
15:28
Bertl_oO
and a lot of others, they are called IRC bouncers or IRC proxies
15:29
Rebelj12a
ahhh ok
15:29
Bertl_oO
I've had good experience with bip, simple to configure and works fine
15:29
Bertl_oO
a friend of mine is using miau very happily
15:29
Rebelj12a
Does it work on mobile, linux windows mac etc XD
15:30
odinho
dircproxy, --- I guess some clients like irssi and possibly weechat can do such proxying as well.
15:30
Bertl_oO
it runs on the server, and usually under a unix flavor
15:30
Bertl_oO
what client you use to connect doesn't matter
15:30
Bertl_oO
(i.e. you attach via IRC protocol again)
15:30
Rebelj12a
hmmmm
15:31
intracube
changed nick to: intracube_
15:31
Rebelj12a
Well yeah just switching between them or switching to mobile I dont want like two instances of my username popping up or continous connect disconnects. You know… courtesy..
15:31
Bertl_oO
that is what the irc proxy takes care of
15:31
Rebelj12a
oh ok
15:31
Bertl_oO
it stays on always, keeps your nick, records stuff if you are offline
15:31
Rebelj12a
Weechat I think thats the one.
15:32
Bertl_oO
once you connect via whatever client you like, it replays the missed stuff and forwards your input to the irc network
15:32
Rebelj12a
m ok
15:32
Bertl_oO
weechat is a little bit of both, irc client and proxy
15:34
Rebelj12a
Ah wonder if i can install it on my webserver hmmmm
15:34
Rebelj12a
Bluehost is limited. Eitehr way thanks Weechat was the one I was looking for.
17:01
troy_s
Rebelj12a: Quassel
17:11
Bertl_oO
changed nick to: Bertl
17:11
Bertl
back now ...
17:12
Bertl
yeah, quassel is similar to weechat, it also uses a client/server model
17:30
troy_s
Bertl: Greets Herb
17:30
troy_s
How are you?
17:31
Bertl
fine, thanks! and you?
17:31
troy_s
Off now.
17:31
Bertl
:)
17:33
troy_s
Bertl: What are you working on?
17:34
Bertl
currently on the Interface Board and the basic interface to the Beta Board
17:35
troy_s
What is the interface board for? The sensor?
17:35
troy_s
Or the data output bits?
17:35
Bertl
the interface board goes between sensor board and the actual beta board
17:35
troy_s
Right.
17:36
Bertl
it creates a common interface to the beta board for all sensors we have planned for
17:36
Bertl
(and probably for a bunch more :)
17:36
troy_s
So you wire up a standardized link between sensor to get to interface layout?
17:37
Bertl
yes kind of, the interface board has up to 80 LVDS connections plus up to 6 different voltages to the sensor board
17:37
Bertl
they can be somewhat arbitratily assigned to the sensor interface
17:38
Bertl
the interface board will carry a low power FPGA which processes the sensor data and creates a structured stream of data
17:39
troy_s
Three sentences, two acronyms. Busted! Hee hee.
17:39
Bertl
hehe
17:39
troy_s
So the interface will be doing the primary manipulations or merely structural?
17:39
troy_s
(Debayer versus order/structure/protocol)
17:40
troy_s
The latter I assume.
17:40
Bertl
if it works well, it will do pixel reordering and checksumming
17:40
troy_s
Right.
17:40
Bertl
as well as bandwidth management
17:40
Bertl
it is not planned to do debayering or interpolation
17:40
troy_s
Another FPGA?
17:41
Bertl
but it might be used by the ML folks for accumulating sensel data
17:41
Bertl
CPLD or FPGA yes (on the interface board)
17:42
troy_s
Low cost 3D shader.
17:43
troy_s
Sebs working in sync or on hardware?
17:43
Bertl
probably on the enclosure and mechanical parts as time permits
17:44
troy_s
That is what I expected.
17:49
Bertl
please remind me, what was a 'good' distance from camera base to lens center (height)?
17:52
se6astian
https://wiki.apertus.org/index.php?title=Rods
17:52
se6astian
85mm to rod center
17:52
se6astian
the rods typically need a bit of space to be fixed under the lens base themselves
17:53
se6astian
so < 75-70 max is a good guestimate
17:53
Bertl
s/lens base/camera base/?
17:53
se6astian
yes
17:53
Bertl
okay, thanks!
17:53
se6astian
the rods typically need a bit of space to be fixed under the camera base themselves
17:54
se6astian
these pats typically look like this
17:54
se6astian
http://ecx.images-amazon.com/images/I/41Fy7uyHWdL._SY300_.jpg
17:54
se6astian
*parts
17:54
Bertl
I see, yes, makes sense, thanks
17:56
slikdigit
joined the channel
18:16
davidak1
joined the channel
18:42
lab-bot
kontrakatze created T146: Reorganisation of channels for communication. http://lab.apertus.org/T146
18:43
intracube_
left the channel
19:16
wescotte
joined the channel
19:39
troy_s
se6astian: Worth mentioning on rods subject, I confirmed that the 15mm are very much standards these days, with the 19mm holding a bit in Europe in some regions. Perhaps you have a better position for figuring out the ratios being over there.
20:07
se6astian
troy_s: On the hundreds of gigs I have only seen the 15mm/60mm appart rods in action so far
20:07
se6astian
I know we at the university own a 19mm rods set with baseplate
20:07
se6astian
but no accessories for it
20:08
se6astian
and we never actually used it for anything :)
20:10
Bertl
off for a nap ... bbl
20:10
Bertl
changed nick to: Bertl_zZ
20:16
lab-bot
sebastian closed T8: Research Sony E mount patents as "Resolved". http://lab.apertus.org/T8
20:26
Rebelj12a
So lets say… I have a cmos sensor from a webcam… lets say… I dont know the specs yet. Would it be possible to take that sensor and record from it. If so, how long of a process is this going to be XD
20:43
Rebelj12a
Im guessing fairly difficult
21:03
se6astian
changed nick to: se6astian|away
21:28
davidak1
left the channel
21:29
davidak1
joined the channel
21:32
Rebelj12a
Blast, gotta stay off hackaday… the stuff people make there gives me too many ideas.
21:33
Rebelj12a
Stuff like this… which is awesome… https://hackaday.io/project/369-oscar-the-open-screen-adapter
21:37
derWalter
joined the channel
21:51
sb0
joined the channel
22:03
Rebelj12a
https://hackaday.io/project/1552-lofi saved
22:20
davidak1
left the channel
22:32
Bertl_zZ
changed nick to: Bertl
22:32
Bertl
back now ...
22:33
Rebelj12a
Maglev, slider… … for fast stabile pans? Ok enough hackaday… for a day… too much...
22:34
slikdigit
left the channel
22:39
danieel
Rebelj12a: the process is fairly straightforward once you discover what the parts are
22:40
danieel
that OSCAR you are referring... is just a clone of my product, which was made *without* having any datasheet for the retina LCD at those time
22:41
Rebelj12a
danieel Yeah looking at that, Its a firewire isight camera. So mac closed im sure… old school one heats up pretty good too but the firewire interface simply wont work. Well unless arduino has firewire libraries, regardless of having a plug around on an old motherboard im sure, but still… direct sensor access would be nice for a better quality image in theory.
22:42
danieel
find it on ifixit if you are not going to open it yourself...
22:42
Rebelj12a
Ohh I just saw it and thought it was pretty cool.
22:43
Rebelj12a
I probably will look it up, still settling on a design. On one hand… higher resolution is better, im thinking of integrating it into a sort of handheld or tripod mounted scanner.
22:43
danieel
do you know the model/year?
22:44
Rebelj12a
er 3d scanner that is, something that will take and interpolate pictures or laser line. pictures preferably for texture.
22:45
Rebelj12a
probably it has a model number
22:45
danieel
to me it seems like an ccd
22:45
danieel
is it this? http://jjhale.com/blog/2010/03/irsight-converting-isight-webcam-to-ir-webcam/
22:45
Rebelj12a
holy crap someone is still selling one for 182? O.o
22:45
Rebelj12a
A1023
22:45
Rebelj12a
Yep looks just like it
22:46
Rebelj12a
probably around 2004
22:46
danieel
640x480 CCD ... good luck with driving that :)
22:46
danieel
if you are into oldschool analog, try it
22:47
Rebelj12a
Bah CCD
22:47
Rebelj12a
yeah
22:47
Rebelj12a
crap
22:48
Rebelj12a
Maybe ill just take it out and stick it in my 8mm movie cam XD
22:49
sb0
left the channel
22:49
danieel
must go resting.. gn
22:50
Rebelj12a
night
22:53
Rebelj12a
Well found linux isight drivers for firewire thats a start right...
22:53
Rebelj12a
haha
22:53
sb0
joined the channel
22:56
Bertl
danieel: well, you could have open sourced it and now you would be famous ... but somebody beat you to it and created oscar ...
23:02
designbybeck
left the channel
23:04
Rebelj12a
Well hackaday is hardly famous and theres the IP aspect of i.e. apple owning it alls… Although taking it and using it for something would be great.
23:05
Rebelj12a
Long debated this. Taking a monitor like the high resolution ipad, seeing If i can get the wacom to register in one case so I can have a real time drawing monitor. That would be nice.
23:30
Rebelj12a
Ok im looking at a circuit board here, I know its kinda noobish but how do I figure out what it is this board is so I can lookup the datasheet?
23:32
Bertl
depends on the circuit board :)
23:33
Rebelj12a
oh god really D:
23:35
Rebelj12a
I dont know, its for a film scanner… but its not optical the board is covered so im guessing light.
23:36
Rebelj12a
lines labled… r-g-b-v n1 and-nc2-v++-IR
23:36
Rebelj12a
Im guessing a light of some sort
23:42
Bertl
well, sounds interesting, but that is probably not enough to identify the board :)
23:43
Rebelj12a
Bah
23:44
Rebelj12a
Oh yeah its soldered onto the white box, which must be a light array
23:44
Rebelj12a
Theres a backwards R and U combined logo
23:44
Rebelj12a
hmmm
23:44
Rebelj12a
Pan 301
23:44
Rebelj12a
s202 FAU Rev3
23:44
Rebelj12a
FM1-0598/FM1-3650
23:45
Rebelj12a
Ill be frank I dont like asking for help but I dont even know where to start here D:
23:46
Bertl
backwards R and U is not a company
23:46
Rebelj12a
Oh… ok...
23:46
Rebelj12a
Ugh this is why I like standards D:
23:47
Bertl
the RU is actually an UL mark
23:47
Rebelj12a
oh….
23:47
Rebelj12a
haha
23:48
Bertl
http://ul.com/corporate/marks/ul-listing-and-classification-marks/downloadable-ul-marks/
23:48
Rebelj12a
Aha its a FARE Automatic Retouching and Enhancement device. Patent # got it
23:48
Rebelj12a
hmm
23:48
Bertl
in this case it means that your PCB is produced for canada/united states and is supposed to be _inside_ a device :)
23:49
Rebelj12a
hey hey now “supposed” to be
23:54
Rebelj12a
Ah I think its the FM and sorry thats FH1-3650
23:55
Rebelj12a
Or that may just be the pcb assembly D: