23:21 | jucar2 | left the channel | |
00:03 | dmj_nova | left the channel | |
00:03 | dmj_nova | joined the channel | |
06:20 | s3bastian | joined the channel | |
08:18 | s3bastian | left the channel | |
08:18 | se6astian | joined the channel | |
08:31 | se6astian | good morning!
| |
08:46 | dmj_nova | left the channel | |
09:00 | dmj_nova | joined the channel | |
09:41 | dmj_nova | left the channel | |
09:42 | dmj_nova | joined the channel | |
11:11 | se6astian | left the channel | |
11:39 | se6astian | joined the channel | |
12:15 | Bertl | morning everyone!
| |
12:16 | se6astian | hello!
| |
12:16 | se6astian | how are you?
| |
12:16 | se6astian | long time no see
| |
12:18 | Bertl | I'm fine, thanks for asking, and you?
| |
12:18 | se6astian | good good, had a very nice holiday
| |
12:19 | se6astian | a bit hindered by the "omg I am back where should I start my work again now" feeling still ;)
| |
12:22 | se6astian | so how has it been
| |
12:22 | se6astian | the led matrix arrived I read
| |
12:22 | Bertl | well, regarding axiom, we'd certainly benefit from a second look at the adapter layout ...
| |
12:22 | se6astian | did you get to populate the PCB yet?
| |
12:23 | Bertl | yes, the pmod debug module is working fine here since more than a week?
| |
12:23 | se6astian | great!
| |
12:23 | se6astian | can you take a picture/video to give us a chance to participate in seeing it work? ;)
| |
12:24 | Bertl | sure
| |
12:24 | se6astian | and about the second look
| |
12:25 | se6astian | I guess the path to get that done is pack the current state of the design into a file that is easiest to read (PDF maybe) and then send it off to the axiom-dev mailing list together with a description of what exactly needs being checked/verified?
| |
12:27 | se6astian | I think my highest priority task is to continue the 3d concept of the bigger axiom body
| |
12:27 | se6astian | I was thinking of moving the SSD drive bays from the front/right to the back/left side as having to remove the handle to change disks could be seen as rather cumbersome
| |
12:28 | se6astian | to save space I was thinking about switching from 2.5" SSDs to 1.8" ones, the speed seems to be the same for both kinds
| |
12:29 | Bertl | well, the layout is available as .tar.xz and .zip of pdfs already
| |
12:29 | Bertl | (always was since v0.8.1 or so)
| |
12:31 | Bertl | and I'm fine to send it to oshpark as is, although I'd appreciate some feedback (got none yet)
| |
12:32 | se6astian | ok let me prepare files for you
| |
12:32 | se6astian | URL please ;)
| |
12:32 | Bertl | http://vserver.13thfloor.at/Stuff/AXIOM/qad-center-v0.8.9.{zip,tar.xz,sch,brd}
| |
12:33 | Bertl | the zip and tar.xz both contain a set of pdfs for the layers, masks and silk screen
| |
12:40 | se6astian | Do you know how full the 4 layer batch queue is already?
| |
12:40 | Bertl | no idea at the moment
| |
12:41 | se6astian | ok I will just propose a deadline at the end of the week
| |
12:41 | Bertl | there was a run on the 22nd of july
| |
12:42 | se6astian | what things in particular do you think need to be verified so I can give people a hint at where to start?
| |
12:43 | Bertl | everything, from part footprints over schematic connections to possible high frequency problems in the layout
| |
12:44 | Bertl | I've included a number of test pins and holes to allow for patching up some connections (if we need them) and I also designed it with and without on-board regulators
| |
12:44 | Bertl | so we should be somewhat flexible to add some stuff as patch
| |
12:45 | Bertl | the planned setup is without the DA converter and without the 3.3/1.8V regulators
| |
12:45 | Bertl | (we need the 3.0V regulator though)
| |
12:45 | se6astian | I created an email and sent it to you for reviewing
| |
12:45 | se6astian | this would be what I send to the entire team
| |
12:47 | Bertl | s/in complete/is complete/ and the tar.xz is missing but otherwise looks fine
| |
12:48 | Bertl | it seems the next 4layer is planned for Aug 15th
| |
12:48 | se6astian | uh thats in 2 days
| |
12:48 | Bertl | the last one was Aug 5th, according to twitter
| |
12:48 | se6astian | then better just commit it
| |
12:49 | Bertl | well, it takes about two weeks in the fab (IIRC) and another 1-2 to get here (JFYI)
| |
12:50 | Bertl | of course, if we figure out a problem before that, we could schedule another one sooner
| |
12:51 | se6astian | email sent
| |
12:51 | Bertl | here a video of the pmod debug in (test) action from the worlds worst videographer (me :) http://vserver.13thfloor.at/Stuff/AXIOM/video-2013-08-13-14-23-12.mp4
| |
12:51 | Bertl | here a still: http://vserver.13thfloor.at/Stuff/AXIOM/2013-08-13%2014.22.40.jpg
| |
12:52 | se6astian | very nice!
| |
13:05 | se6astian | now when the 1.8" ssds go into the enclosure: a) how to get them back out and b) how to close the "door" when they are inside the enclosure...
| |
13:05 | Bertl | and very useful ... requires only a few lines of VHDL code to show up to 64 signals
| |
13:06 | Bertl | so we already know, we want SATA and 1.8" SSD(s) in the final camera?
| |
13:06 | se6astian | I guess its the most viable option currently yes
| |
13:07 | se6astian | unless there are reasons for not going that way that I dont know of yet
| |
13:07 | Bertl | well, my impression was, that we wanted to focus on the front end and leave the recording part to whatever gets attached via high speed serial
| |
13:08 | Bertl | (which might include a SATA disk/raid of course)
| |
13:10 | se6astian | yes that was the original plan, but after some FPGA guys concluded that adding a SATA interface wouldnt be that much trouble...
| |
13:10 | Bertl | but I'm fine with having SATA 1.8" fixed as well, are there any plans to test that (i.e. some kind of prototype?)
| |
13:10 | Bertl | if so, what board is planned for that?
| |
13:11 | se6astian | the Axiom concept is just vapour ware so far ;)
| |
13:11 | se6astian | aka there are no intensions to build it right away
| |
13:14 | se6astian | or let me rephrase that
| |
13:14 | Bertl | okay, then I guess it doesn't matter too much where the SATA disc goes and how it is connected :)
| |
13:14 | se6astian | goals: 1. finish prototype 2. shoot some sample footage 3. present footage and Axiom concept in crowdfunding campaign 4. raise the money and dance or cry and move on
| |
13:15 | se6astian | so the concept isnt that technical yet really, its just a visualized plan of what we want to do with the money then
| |
13:16 | se6astian | of course it cant hurt to know the next development steps, but we shouldnt get ourselves tangled up in the details already
| |
13:16 | Bertl | okay, personally I'd limit the project (in the next phase) to having a frontend with high speed serial output. period.
| |
13:16 | Bertl | no problem with planning a stage after that which includes e.g. on-board sata
| |
13:17 | Bertl | but note that properly handling sata protocol and physically attaching one or two discs will be a project of its own IMHO
| |
13:18 | Bertl | (and it will require a test system with high speed serial already available, like the one I'd consider the next step :)
| |
13:19 | Bertl | note that I'm also perfectly fine if the 'FPGA experts' handle that in one round ...
| |
13:20 | se6astian | well do you have the concept image in the last version in front of you?
| |
13:20 | se6astian | the email I sent on July 10th?
| |
13:20 | se6astian | subject: Rethinking the Axiom concept - please particiapte
| |
13:24 | Bertl | you mean the axiom-extension0*.jpg(s)?
| |
13:26 | se6astian | yes extension04.jpg
| |
13:26 | se6astian | then you see that the next step is actually the version without any internal recording option
| |
13:27 | Bertl | okay, so we are on the same page then, good!
| |
13:28 | Bertl | although I'm pretty sure we will need a prototype between axiom HD and axiom 4K (if those are the proper names)
| |
13:29 | Bertl | and I'm also sure that the Axiom HD should be designed to do 4K via those serial ports
| |
13:30 | Bertl | so, maybe there are actually 4 'products'? i.e. HD/4K and FrontEnd only/FE+Recorder?
| |
13:31 | se6astian | we could just add an SFP+ port to the HD variant to enable higher bandwidth transfers?
| |
13:31 | Bertl | I have no clue what the 3 connectors shown in the extension04.jpg are
| |
13:32 | se6astian | should visualize 3 BNC connectors ;)
| |
13:32 | Bertl | yeah, well, I got that, but what speed/protocol?
| |
13:32 | se6astian | like this: http://www.lafcpug.org/images_review_pana_hpg20/07_ag_hpg_20_recorder_brockett.jpg
| |
13:33 | Bertl | so we want an input?
| |
13:33 | se6astian | one could be 3g-sdi cleanfeed for recording, the other one with OSD overlays, the last one I don't know yet :)
| |
13:33 | se6astian | no that image was just to show the connectors from closer up :)
| |
13:35 | Bertl | okay, I don't think that we should designate the connectors (not even sure that 3xBNC is the best idea, but I'm fine with BNC in general :)
| |
13:35 | Bertl | so let's assume that each BNC connector represents a serial port
| |
13:36 | Bertl | so we could transport up to 2.97 Gbit/s on each port (assuming 3G-SDI)
| |
13:37 | Bertl | that would give up to 8.9 Gbit/s total
| |
13:37 | se6astian | you mean we go the route the reassign the protocol/standard on each connector via the FPGA on the fly?
| |
13:38 | Bertl | maybe on the fly (think partial FPGA reprogramming) maybe just in different firmwares
| |
13:38 | Bertl | I think that is part of the desired flexibility, no?
| |
13:38 | se6astian | yes I would love that
| |
13:39 | se6astian | we just need to find a way how to display to users what the connector is doing atm
| |
13:39 | se6astian | lcd next to each connector might be a bit of an overkill
| |
13:39 | Bertl | could be on the OSD screen (wherever that is) or via some (o)led
| |
13:39 | Bertl | (think connector configuration screen)
| |
13:40 | Bertl | I don't think that is something which will change during recording
| |
13:40 | Bertl | it's more something you tailor to your needs and actual equippment
| |
13:40 | se6astian | status led is a nice idea
| |
13:40 | se6astian | and a printed label linking color to standard
| |
13:40 | se6astian | will do that now ;)
| |
13:41 | Bertl | well, don't go overboard with that :)
| |
13:42 | Bertl | as I said, I don't think that is something you change often, IMHO it makes more sense to label the ports clearly
| |
13:42 | Bertl | i.e. SD-A, SD-B, SD-C for example
| |
13:42 | Bertl | and then have a (G)UI to select SD-A is video raw, SD-B is video + overlay, SD-C is data for recorder/SATA for example
| |
13:43 | se6astian | the gui we will definitely have as well but it think its a handy thing to also show something where the actual connector is
| |
13:43 | Bertl | or on a different setup, SD-A is view finder, SD-B and SD-C is 4k recorder (for example)
| |
13:44 | Bertl | (try to model that with LEDs :)
| |
13:45 | se6astian | very simple, green is cleanfeed, orange is OSD
| |
13:45 | se6astian | and RGB leds next to each connector
| |
13:46 | Bertl | so you still need a legend what color is what
| |
13:47 | Bertl | e.g. blue green is linked (dual SD), etc ...
| |
13:47 | Bertl | but yeah, an RGB led besides each connector won't hurt (just draw additional power but that can be turned off:)
| |
13:48 | Bertl | as long as you avoid having specific labels on the connectors (regarding protocol or data) it should be fine
| |
13:49 | Bertl | it will get confusing if you label a port as HD or clean or whatever basically limits the data being transferred
| |
13:50 | Bertl | (i.e. that designation should be dynamically or at least flexible)
| |
13:52 | Bertl | note that SD/HD/3G-SDI are all backwards compatible
| |
13:52 | Bertl | so, making all 3 ports 3G-SDI will allow for non 3G-SDI connections as well
| |
17:02 | [1]se6astian | joined the channel | |
17:04 | se6astian | left the channel | |
17:04 | [1]se6astian | changed nick to: se6astian
| |
20:42 | se6astian | left the channel |