| *** tpb has joined #timvideos | 00:00 | |
| *** cr1901 has joined #timvideos | 00:09 | |
| *** sb0 has joined #timvideos | 01:15 | |
| xfxf | mithro: when you're up, can you msg me the IP of my connection? | 02:12 |
|---|---|---|
| xfxf | woo dynamic ip's | 02:12 |
| mithro | Just about to get up now | 02:13 |
| mithro | Did you see my note about the fuse? | 02:13 |
| mithro | CarlFK: did you get any where? | 02:14 |
| CarlFK | mithro: just hooked it up, fumbling to get my tester app going | 02:15 |
| CarlFK | ImportError: No module named serial | 02:15 |
| CarlFK | any idea what the python3 name is? | 02:15 |
| sb0 | still serial | 02:18 |
| xfxf | mithro: i did, i think the heaters are tripping it. turned the one off in the office, turn the one off in your room too if it's on | 02:18 |
| xfxf | that circuit has a 20A fuse on it, i somehow doubt we're pulling more than that | 02:19 |
| xfxf | CarlFK: iirc that's not std library - pip3 install pyserial ? | 02:20 |
| CarlFK | Successfully installed pyserial-3.1.1 | 02:22 |
| CarlFK | ImportError: No module named serial | 02:22 |
| CarlFK | er, pip3 missed that... maybe | 02:22 |
| CarlFK | Requirement already satisfied (use --upgrade to upgrade): pyserial in ./.virtualenvs/veyepar/lib/python3.5/site-packages | 02:22 |
| xfxf | CarlFK: i just had the same problem on OS X | 02:27 |
| xfxf | try this | 02:27 |
| xfxf | python3 -m pip install pyserial | 02:27 |
| xfxf | my pip3 was pointed to a different python installation than my python3 in my path | 02:27 |
| xfxf | above solves it | 02:27 |
| xfxf | you probly want to use pyvenv with python3 was well, not virtualenv | 02:27 |
| xfxf | s/was/as/ | 02:28 |
| xfxf | mithro: poke, IP address pls (the box i normally bounce to is off) | 02:30 |
| CarlFK | xfxf: are you sure it is serial and not pyserial? | 02:32 |
| xfxf | pretty sure yes | 02:33 |
| xfxf | look inside of site-packages if you want to verify, it's just python after all | 02:33 |
| CarlFK | um.. look for what? | 02:34 |
| xfxf | alternatively you probably have a python3-serial package or something if you're on debian/ubuntu and you don't mind installing it globally | 02:35 |
| *** rohitksingh_work has joined #timvideos | 04:18 | |
| mithro | Heyo rohitksingh_work | 04:30 |
| rohitksingh_work | mithro: hi! | 04:30 |
| mithro | cr1901: So, were are we at with your pull request? | 04:33 |
| cr1901 | mithro: Still writing the docstrings. Might as well finish that before I go to bed. | 04:34 |
| cr1901 | mithro: Provided my energy doesn't give out, let's go ahead and get this merged before I retire for the night | 04:35 |
| mithro | cr1901: That would be awesome | 04:36 |
| mithro | CarlFK: Did you see the frequency counter stuff I linked? | 04:36 |
| mithro | CarlFK: It lets you see the pixel clock frequency even when the the video data is out of range | 04:36 |
| cr1901 | Then I need to make a post to EE.StackExchange... yay :/ | 04:37 |
| mithro | CarlFK: IE If someone is sending 1080p60 resolution, you can see the pixel clock frequency | 04:37 |
| CarlFK | mithro: something chanege and confused my tester... | 04:38 |
| CarlFK | maybe... | 04:38 |
| mithro | CarlFK: was it the v0.0.2 tag? | 04:38 |
| CarlFK | mithro: don't know.. digging.. here is the log so far: | 04:39 |
| CarlFK | http://paste.ubuntu.com/22775370/ | 04:39 |
| tpb | Title: Ubuntu Pastebin (at paste.ubuntu.com) | 04:39 |
| mithro | CarlFK: that looks right? | 04:40 |
| *** Bertl_zZ is now known as Bertl | 04:47 | |
| mithro | rohitksingh_work: Where are we at with the VGA gateware do you think? | 04:47 |
| rohitksingh_work | mithro: there is now merge conflict in atlys_video target i guess | 04:48 |
| mithro | CarlFK: what does "nodir" mean? I assume it means that revision doesn't have a file for the Atlys? | 04:48 |
| CarlFK | mithro: correct | 04:58 |
| mithro | CarlFK: It looks like the "fixed" pull request only just made it to the prebuilt repo | 05:15 |
| CarlFK | mithro: im done for the day.. brain is 1/2 asleep.. can you give me the commands to test to see if it boots? | 05:18 |
| mithro | CarlFK: I'm not sure how you do it, I'm pretty sure you do it differently to how I would... | 05:24 |
| CarlFK | mithro: how would you do it? | 05:24 |
| mithro | CarlFK: "make load-gateware" on a checkout of the HDMI2USB-misoc-firmware repo | 05:24 |
| CarlFK | oh right.. I don't have any of that installed | 05:25 |
| mithro | I think you have been using openocd or modeswitch? | 05:25 |
| cr1901 | mithro: Two classes left to document | 05:25 |
| CarlFK | mithro: both. (which surprises me) | 05:26 |
| CarlFK | run_cmd(["hdmi2usb-mode-switch", "--mode=jtag"]) | 05:27 |
| CarlFK | run_cmd( ['openocd', '-f', 'board/digilent_atlys.cfg', | 05:27 |
| CarlFK | '-c', "init; pld load 0 {}; exit".format(fp) ] ) | 05:27 |
| CarlFK | ah, I get it | 05:27 |
| *** sb0 has quit IRC | 05:30 | |
| mithro | CarlFK: in theory you should just be able to do "hdmi2usb-mode-switch -v --load-gateware {}".format(fp) | 05:31 |
| CarlFK | mithro: what dir/ver should I be using? | 05:34 |
| CarlFK | HDMI2USB-firmware-prebuilt/archive/master/v0.0.2-63-g24c11c0/atlys no hdmi2usb | 05:34 |
| CarlFK | mithro: why did the counter seem to go from 701 to 16? | 05:35 |
| mithro | v0.0.2-63-g24c11c0/atlys/hdmi2usb | 05:35 |
| mithro | CarlFK: what do you mean? | 05:35 |
| mithro | CarlFK: oh, because the number is "number of commits since the tag" | 05:36 |
| mithro | CarlFK: so when v0.0.2 was tagged the number resets | 05:36 |
| CarlFK | mithro: 63 a 3 digit number at 701 | 05:36 |
| CarlFK | ah | 05:36 |
| CarlFK | bash: cd: v0.0.2-63-g24c11c0/atlys/hdmi2usb: No such file or directory | 05:36 |
| CarlFK | no hdmi2usb | 05:36 |
| mithro | https://github.com/timvideos/HDMI2USB-firmware-prebuilt/tree/master/archive/master/v0.0.2-63-g24c11c0/atlys/hdmi2usb | 05:37 |
| tpb | Title: HDMI2USB-firmware-prebuilt/archive/master/v0.0.2-63-g24c11c0/atlys/hdmi2usb at master · timvideos/HDMI2USB-firmware-prebuilt · GitHub (at github.com) | 05:37 |
| CarlFK | mithro: ah, git pull, it is there now | 05:37 |
| CarlFK | mithro: it boots | 05:40 |
| CarlFK | git describe: v0.0.2-63-g24c11c0-dirty | 05:40 |
| mithro | CarlFK: As I mentioned I wanted you to do a bunch of actual testing on the 3 revisions I listed | 05:41 |
| CarlFK | mithro: that will have to wait till tomrorow. I'm having trouble typing | 05:42 |
| mithro | CarlFK: okay | 05:48 |
| CarlFK | about 1a, Ill be up in 6 hours. | 05:48 |
| cr1901 | mithro: Check now | 05:56 |
| cr1901 | I'm brushing my teeth while I wait :P | 05:56 |
| mithro | cr1901: Give me a little bit, just in the middle of finishing something | 06:02 |
| cr1901 | mithro: How long? I need to be up in 4-5 hours | 06:05 |
| mithro | cr1901: Looks good | 06:06 |
| mithro | cr1901: Just one small change | 06:06 |
| cr1901 | Cool | 06:06 |
| mithro | cr1901: I think some of the modules you have in the module already have existing migen/misoc primitives - but lets not block on that for now | 06:07 |
| cr1901 | mithro: They do in the old API. I wrote this to be easy to change when you went to the new API. But since that's prob not gonna happen anymore, you're right. | 06:08 |
| mithro | cr1901: Hrm? We still plan to move towards the new migen/misoc/litex | 06:08 |
| cr1901 | mithro: Ahhh, I thought you were now only targeting Litex | 06:09 |
| cr1901 | which is "a continuation of the old API", AIUI | 06:09 |
| mithro | well, litex is suppose to be compatible with migen/misoc? | 06:09 |
| cr1901 | The old API | 06:09 |
| cr1901 | _florent_: Feel free to disagree with me here :P | 06:09 |
| mithro | litex has some stuff backported/kept around | 06:09 |
| cr1901 | Well, it can prob safely be changed | 06:10 |
| cr1901 | mithro: Unfortunately, right now I'm not in a position to test it. My minispartan board isn't here, and this isn't a powerful netbook. I would expect building a bitstream to take upwards of 20 minutes | 06:10 |
| mithro | cr1901: It works last I tested it | 06:11 |
| mithro | cr1901: I can test again shortly | 06:11 |
| cr1901 | mithro: Very well, fixing it now | 06:12 |
| cr1901 | mithro: Sorry, energy's fading. I can't do it right now :/ | 06:19 |
| mithro | cr1901: okay, have a good night | 06:23 |
| *** ssk1328 has joined #timvideos | 07:13 | |
| *** sb0 has joined #timvideos | 08:12 | |
| xfxf | thaytan: my usb audio is getting totally out of sync with my v4l video :/ any ideas? | 09:49 |
| *** danielki has joined #timvideos | 10:42 | |
| *** sb0 has quit IRC | 10:46 | |
| *** danielki has left #timvideos | 10:53 | |
| *** danielki has joined #timvideos | 10:57 | |
| *** sb0 has joined #timvideos | 11:02 | |
| *** cr1901 has quit IRC | 11:56 | |
| *** rohitksingh_work has quit IRC | 12:09 | |
| *** cr1901 has joined #timvideos | 12:10 | |
| *** sb0 has quit IRC | 12:12 | |
| mithro | Hey, ssk1328 how is it going? Getting anywhere? | 12:15 |
| ssk1328 | mithro: Yeah | 12:15 |
| ssk1328 | mithro: Working on the new HDMI_OUT rework | 12:15 |
| ssk1328 | mithro: With direct connections in the mixer block | 12:15 |
| ssk1328 | mithro: Right now trying to fix a bug | 12:15 |
| ssk1328 | mithro: I created a separate branch for this | 12:16 |
| mithro | How is that going? Anything I can help with? | 12:16 |
| ssk1328 | mithro: https://github.com/timvideos/migen/blob/ad57f636eb95c0c0ba539fe9048266120f3f5c54/migen/flow/plumbing.py#L19 | 12:17 |
| tpb | Title: migen/plumbing.py at ad57f636eb95c0c0ba539fe9048266120f3f5c54 · timvideos/migen · GitHub (at github.com) | 12:17 |
| ssk1328 | mithro: When trying to use this COmbinator block | 12:17 |
| ssk1328 | mithro: WHat format is subrecord supposed to be in | 12:17 |
| ssk1328 | mithro: I tried a list of layouts, but that didn't compile | 12:18 |
| mithro | I think it's a list of strings | 12:18 |
| mithro | It's a list of things that layout_partial arguments actually | 12:19 |
| ssk1328 | mithro: list of strings mught make sense | 12:21 |
| mithro | It's a list of tuples | 12:22 |
| mithro | Where the tuples are arguments you would give to the layout_partial function | 12:22 |
| RattusRattus | mithro: hay again. Finished schematic review for TOFE VGA expansion board. where would you like me to post comments? I see from earlier that you suggest to CarlFK I should post patches. Not sure how to do that (yet) but would be happy to do so with help. Although I suspect reading comments would be a good first step... | 12:22 |
| mithro | https://github.com/m-labs/migen/blob/fa3537d0e0909807c5f5fb3858e175b3a4545acb/migen/genlib/record.py#L69 | 12:24 |
| tpb | Title: migen/record.py at fa3537d0e0909807c5f5fb3858e175b3a4545acb · m-labs/migen · GitHub (at github.com) | 12:24 |
| mithro | RattusRattus: maybe post it in a Pastebin first, and then create GitHub issues for the major items? | 12:25 |
| mithro | RattusRattus: https://github.com/timvideos/HDMI2USB-TOFE-VGA/issues/new | 12:26 |
| tpb | Title: Sign in to GitHub · GitHub (at github.com) | 12:26 |
| RattusRattus | mithro: ta! | 12:27 |
| mithro | RattusRattus: you can modify the schematic and send a pull request if you wanted to | 12:28 |
| RattusRattus | mithro: not done this GIT thing before.... | 12:28 |
| mithro | Sadly, it's not that easy to do merging, so tell me if you are doing that | 12:29 |
| mithro | RattusRattus: have you done svn? | 12:29 |
| RattusRattus | indeed. well lets start with a paste of comments and take it from there.... | 12:29 |
| RattusRattus | one moment | 12:29 |
| mithro | GitHub have a way to access git repository with svn if you would prefer, otherwise I can walk you through the basics | 12:32 |
| mithro | I'm on a train currently | 12:34 |
| thaytan | xfxf, no, that's a case that should definitely work fine | 12:34 |
| mithro | But will be back in xfxf's place in ~20 minutes | 12:34 |
| RattusRattus | http://paste.debian.net/787612/ << Comments | 12:35 |
| tpb | Title: debian Pastezone (at paste.debian.net) | 12:35 |
| * RattusRattus is happy to do updates, so I guess I'll need a walk through on GIT. Will need to do that from home though (at work right now) | 12:36 | |
| xfxf | thaytan: hrm. any ideas? i'm running out of them :/ | 12:37 |
| thaytan | xfxf, what's the setup in that case? same? 2 source elements in 1 pipeline sharing a clock? Does the audio source have a slaving method set? | 12:38 |
| xfxf | I'm picking up mithro from train - I'll be home in 15 and will put the pipeline as a simple gst-launch line in a single script | 12:44 |
| xfxf | It's currently the Python script I pasted earlier, which takes a v4l stream and a alsa or pulse stream and muxes them into the uncompressed format vocto requires | 12:45 |
| *** rohitksingh_work has joined #timvideos | 12:47 | |
| CarlFK | thaytan: this, plus maybe this added to the audio src: provide-clock=false slave-method=resample | 12:57 |
| CarlFK | http://paste.ubuntu.com/22798848/ | 12:57 |
| tpb | Title: Ubuntu Pastebin (at paste.ubuntu.com) | 12:57 |
| mithro | RattusRattus: looking at your comments now | 13:03 |
| thaytan | those should never drift out of sync, although it could be handy to put audiorate in the audio path as well, to insert or drop audio samples | 13:03 |
| thaytan | with no queue in place there, you've only got 200ms of buffering inside ALSA before you'll lose samples | 13:03 |
| thaytan | so a subtantial delay in the muxing or transmitting could cause you to miss samples | 13:04 |
| thaytan | I'd add a queue and an audiorate element | 13:04 |
| xfxf | @thaytan: the actual script i'm using is here: https://github.com/xfxf/voctomix-outcasts/blob/master/ingest.py | 13:05 |
| tpb | Title: voctomix-outcasts/ingest.py at master · xfxf/voctomix-outcasts · GitHub (at github.com) | 13:05 |
| xfxf | which is like the one carl pasted but with some additions | 13:05 |
| xfxf | oh nm, he's pasted the actual pipeline it constructs | 13:05 |
| xfxf | so indeed, as above | 13:05 |
| thaytan | so, because both audio and video are timestamped off the same clock, you should not get drift in the resulting mkv file | 13:06 |
| thaytan | but there might be gaps from missed audio if the network delays anything | 13:06 |
| xfxf | definitely getting drift | 13:06 |
| thaytan | so there might be jumps in the timestamps, even though things are in sync | 13:07 |
| xfxf | this is from the same machine | 13:07 |
| xfxf | not over network | 13:07 |
| thaytan | if anything then treats that audio stream as continuous, it would drift out | 13:07 |
| thaytan | xfxf, can you record the exact incoming mkv file to disk? | 13:07 |
| xfxf | hmm, https://github.com/xfxf/voctomix-outcasts/blob/master/ingest.py#L247 | 13:07 |
| tpb | Title: voctomix-outcasts/ingest.py at master · xfxf/voctomix-outcasts · GitHub (at github.com) | 13:07 |
| xfxf | would the set_offset()'s be causing any issues? | 13:07 |
| xfxf | i was using those on my latest test/run | 13:07 |
| xfxf | because the audio comes in slightly later than the video, so delayed the video slightly (--video-delay 200 to that script) | 13:08 |
| xfxf | thaytan: re recording exact incoming mkv file, i tried that, but because it's uncompressed video/audio, i run out of disk I/O | 13:09 |
| xfxf | i'm now trying the same thing with a filesink, but with a 'videoconvert' and 'audioconvert' after the raw lines, with mpeg2 encoders | 13:10 |
| xfxf | which isn't exactly the same but i think it's the closest i can do | 13:10 |
| thaytan | xfxf, if you delay the video by 200ms, you're really pushing the friendship | 13:10 |
| thaytan | since 200ms is the default buffersize for alsa / pulse sources | 13:10 |
| thaytan | so now that buffer will run seriously close to full all the time, waiting on the muxer to mix things | 13:11 |
| xfxf | right, unfortunately, there is a delay between the video and audio so i needed to do that so i have lipsync | 13:11 |
| xfxf | should i increase the buffer size? | 13:11 |
| thaytan | again, add a queue | 13:11 |
| thaytan | between alsasrc and the muxer, like in the video chain | 13:11 |
| xfxf | http://paste.ubuntu.com/22799860/ | 13:11 |
| tpb | Title: Ubuntu Pastebin (at paste.ubuntu.com) | 13:11 |
| xfxf | thaytan: like the above, sans the mpeg2 lines? | 13:12 |
| xfxf | (that's what i'm using to try and replicate this issue locally without vocto) | 13:12 |
| xfxf | er, there was a queue there, sorry, i'll re-add it | 13:12 |
| thaytan | that's not the same as what carl posted | 13:12 |
| thaytan | his had a queue in the video chain | 13:13 |
| mithro | RattusRattus: What is the best way to respond to these things? | 13:13 |
| xfxf | https://paste.ubuntu.com/22799985/ | 13:14 |
| tpb | Title: Ubuntu Pastebin (at paste.ubuntu.com) | 13:14 |
| xfxf | like that, or stick the queue elsewhere? | 13:14 |
| RattusRattus | mithro: lol. here? I did look for a mailing list but that appears to be for software. | 13:15 |
| RattusRattus | brb - impromptu office meeting | 13:17 |
| mithro | RattusRattus: so you're one of these people who like small value resistors on their digital IO lines, huh? | 13:21 |
| ssk1328 | mithro: HDMIOut rework works, mixer block is connected directly right now | 13:23 |
| ssk1328 | mithro: No I will need to add pipeline modules in Mixing block | 13:23 |
| mithro | ssk1328: I'm not sure what that means? | 13:23 |
| ssk1328 | mithro: So mixer block is a dummy is just connects the first input to output | 13:24 |
| ssk1328 | mithro: Now I am adding floatadd modules to mixer block | 13:24 |
| ssk1328 | mithro: And other floatmodules | 13:24 |
| mithro | ssk1328: Can you push the changes with the dummy mixing block? | 13:25 |
| ssk1328 | mithro: In minute | 13:25 |
| ssk1328 | mithro: https://github.com/ssk1328/HDMI2USB-misoc-firmware/tree/hdmiout_rework/gateware | 13:27 |
| tpb | Title: HDMI2USB-misoc-firmware/gateware at hdmiout_rework · ssk1328/HDMI2USB-misoc-firmware · GitHub (at github.com) | 13:27 |
| *** rohitksingh_work has quit IRC | 13:39 | |
| mithro | RattusRattus: http://paste.debian.net/787629/ | 13:47 |
| tpb | Title: debian Pastezone (at paste.debian.net) | 13:47 |
| mithro | RattusRattus: the tpd7s019 does look like it might be a good idea | 13:50 |
| mithro | ssk1328: what is a "Combinat" ? | 13:53 |
| ssk1328 | mithro: I tried making the Combinator work, but that didn't, so using this for now | 13:54 |
| mithro | ssk1328: You should give it a proper name :P | 13:55 |
| xfxf | thaytan: https://github.com/xfxf/video-scripts/blob/master/pycon/test-hdmi2usb-capture.sh | 13:55 |
| tpb | Title: video-scripts/test-hdmi2usb-capture.sh at master · xfxf/video-scripts · GitHub (at github.com) | 13:55 |
| xfxf | each has a queue now, and i've added 'audiorate' | 13:55 |
| ssk1328 | mithro: self.combiner was intuitive enough | 13:56 |
| xfxf | am testing this + simultaneously the same thing within vocto without the last 2 lines on each src (Xconvert, mpeg2 line) | 13:56 |
| mithro | ssk1328: You should also just pass in the crossbar and have the PixelGather call "getmaster" n times | 13:56 |
| xfxf | does that look OK? | 13:56 |
| ssk1328 | mithro: Yeah, i was waiting to add that in for loop | 13:57 |
| ssk1328 | mithro: Any good way to get rid of pack_factor dependency on lasmim.dw | 13:59 |
| ssk1328 | mithro: Actually I figured out | 14:01 |
| thaytan | xfxf, yes, looks OK to me | 14:02 |
| xfxf | thaytan: cool, ta. would you advise any of the slave-method's over the other? | 14:04 |
| xfxf | i'm using re-timestamp now, was using resample before, same issue | 14:05 |
| mithro | https://github.com/xfxf/voctomix-outcasts/blob/master/ingest.py#L220 | 14:05 |
| tpb | Title: voctomix-outcasts/ingest.py at master · xfxf/voctomix-outcasts · GitHub (at github.com) | 14:05 |
| mithro | That slaves the vocto mix pipeline to the network clock | 14:05 |
| mithro | what does clock.wait_for_sync(Gst.CLOCK_TIME_NONE) do? | 14:06 |
| thaytan | xfxf, no, as long as it's not "none" | 14:10 |
| thaytan | mithro, waits until the slaved clock has managed to sync to the master | 14:10 |
| thaytan | with infinite timeout | 14:10 |
| thaytan | so it'll sit forever if the master is firewalled or otherwise unavailable | 14:11 |
| mithro | thaytan: In a pipeline like xfxf's what would happen if the v4l src isn't getting frames at a constant frame rate? | 14:15 |
| thaytan | mithro, the videorate element will drop / repeat frames to make a constant framerate stream | 14:16 |
| thaytan | but only when a frame actually arrives - there's no timeout mechanism to trigger it if frames are really far apart, for example | 14:16 |
| thaytan | you handle that case on the server side | 14:16 |
| *** rohitksingh has joined #timvideos | 14:18 | |
| xfxf | mithro: should i be trying your latest firmware in master? | 14:27 |
| mithro | xfxf: sure | 14:28 |
| *** sb0 has joined #timvideos | 14:33 | |
| * RattusRattus returns | 14:33 | |
| RattusRattus | mithro: yes - series termination resistors make a huge differance. They are especially usefull on high speed signals. they improve noise immunity and, if coupled with controlled impeadance tracking, reduce emmissions as well | 14:35 |
| ssk1328 | mithro: You around for some discussions regarding mixer block? | 14:36 |
| ssk1328 | mithro: Apparently having to add mixer block before VTG doesn't make a lot of sense now | 14:37 |
| ssk1328 | mithro: Our document for reference https://docs.google.com/document/d/1g1c2IwCVxVzSHWdXbZ746HP-fnM4y1WqFuBZNkLi5mw/edit#heading=h.4gwktoqxm2hh | 14:37 |
| tpb | Title: Mixer Block Design - Google Docs (at docs.google.com) | 14:37 |
| mithro | RattusRattus: I've seen them cause almost as many problems as they solve | 14:38 |
| mithro | ssk1328: sure, why do you say that? | 14:38 |
| ssk1328 | mithro: The pipelines modules all run at pixel clock, so need to define all the clocking things here | 14:40 |
| ssk1328 | mithro: Plus, before FIFO of Driver, each token is #pack_factor number of pixels | 14:40 |
| ssk1328 | mithro: So pixel clock doesn't make sense here | 14:41 |
| mithro | ssk1328: Looking at the diagram, the Unpacker is what converts the pack_factor number to individual pixels | 14:42 |
| mithro | ssk1328: that is before the VTG | 14:42 |
| mithro | ssk1328: The HDMIOut should just take a stream of pixels + the VTG signals | 14:42 |
| mithro | IE HDMIOut == the DAC part of the system | 14:43 |
| ssk1328 | mithro: No, see the pixel_layout() in format.py, | 14:43 |
| ssk1328 | mithro: I hope the pack_factor value for our DMA is more than one | 14:44 |
| mithro | ssk1328: What are you saying no too? | 14:47 |
| ssk1328 | Unpackes doesn't convert it into individual pixels | 14:48 |
| CarlFK | thaytan: to help us test the vocto stuff, I am trying to mock out the vocto code with gst-launch commands.. but this doesn't work: https://github.com/CarlFK/voctomix-outcasts/blob/master/tests/mock-stack.sh | 14:48 |
| tpb | Title: voctomix-outcasts/mock-stack.sh at master · CarlFK/voctomix-outcasts · GitHub (at github.com) | 14:48 |
| CarlFK | matroska-demux.c(4489): gst_matroska_demux_parse_id (): /GstPipeline:pipeline0/GstMatroskaDemux:demux: Invalid header | 14:48 |
| mithro | ssk1328: what does unpack do then? | 14:48 |
| ssk1328 | mithro: Some combinatorial connections, nothing sequential | 14:49 |
| mithro | ssk1328: Why does it exist? | 14:50 |
| ssk1328 | mithro: I guess cast is the equivalent of unpacker here https://github.com/timvideos/HDMI2USB-misoc-firmware/blob/master/gateware/hdmi_out/__init__.py#L30 | 14:50 |
| tpb | Title: HDMI2USB-misoc-firmware/__init__.py at master · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 14:50 |
| ssk1328 | mithro: It just connects data_width worth of data to our pixel_layout | 14:51 |
| thaytan | CarlFK, you can't set clocks with gst-launch | 14:51 |
| thaytan | so it won't really work the same | 14:51 |
| CarlFK | thaytan: I was going to get to that in a bit ;) | 14:52 |
| thaytan | and you aren't setting matroskamux streamable=true | 14:52 |
| thaytan | do you do that in the python script somewhere? | 14:52 |
| CarlFK | I dont think so | 14:52 |
| mithro | ssk1328: It's a bit weird that the VTG deals with unpacking pixels, but I guess for now go with diagram P4? | 14:52 |
| ssk1328 | mithro: Actual unpacking is being done in FIFO of driver if I am not wrong | 14:54 |
| ssk1328 | mithro: Here https://github.com/timvideos/HDMI2USB-misoc-firmware/blob/master/gateware/hdmi_out/phy.py#L54 | 14:54 |
| tpb | Title: HDMI2USB-misoc-firmware/phy.py at master · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 14:54 |
| RattusRattus | mithro: so C5VO1 datasheet is saying fit 2u2F ceramic you are now saying 22uF electrolytic.. thats fine (for bulk holdup on the rail) but you probably still want the ceramic in there as well for the low ESR to stop oscillation | 14:57 |
| RattusRattus | you are saying that you are not sure fitting the recomended noise suppression caps on the PSU, but on the schematic you have warnings about noise on that PSU rail? I am confused, why warn about noise sensativity and at the same time don't fit the the very thing that will improve the noise figure? | 14:59 |
| RattusRattus | ^^ point 6 | 15:00 |
| mithro | RattusRattus: Trade offs right - adding 0402 capacitor is not a great idea on a board which is suppose to be hand solderable | 15:01 |
| RattusRattus | point 9 - this will never be a comercial grade device without them..... its your call. I would always fit them (but then I'm usuly the person called in to fix EMC issues on kit that fails EMC | 15:01 |
| RattusRattus | mithro: rarther like defensive programming I try and adopt a defensive PCB stratagy. you can always not fit a part, it is much harder to fit a part if there isn't a space on the board for it.... | 15:03 |
| mithro | RattusRattus: Adding ~20 resistors which means an extra ~400 parts to hand solder means it won't happen | 15:05 |
| RattusRattus | but if you have stong feelings that you shouldn't do this then I am not going to fight over it. I have given my recomendations and will try and be supportive whatever your decision. I am happy to contribute even if the result is yes we looked at that and have decided not to implement it. the point is it has at least been considered. | 15:05 |
| mithro | RattusRattus: If it was being machine built / commercially built, you might convince me | 15:06 |
| RattusRattus | are the opsis borads hand built? | 15:06 |
| mithro | RattusRattus: No | 15:06 |
| RattusRattus | ok. what if I were to do the hand soldering? :-) | 15:07 |
| mithro | RattusRattus: well, more hand built then a 10k factory | 15:07 |
| mithro | RattusRattus: but still using a pick/n/place and stuff | 15:07 |
| RattusRattus | ack - product is not 100% machine built | 15:07 |
| mithro | RattusRattus: I'm still skeptical of adding resistors to high speed lines - the pads + resistor muck with your impedance matching | 15:08 |
| RattusRattus | (/me has worked on 100k+ volumes and also 10 PA volumes so is aware of both production environments) | 15:08 |
| mithro | The Opsis is done in batches of ~20 units if I understand correctly | 15:09 |
| mithro | The current batch of VGA boards were hand soldered by rohitksingh in his bedroom if I understand correctly :P | 15:09 |
| mithro | with what looked like a terrible soldering iron from the pictures | 15:10 |
| RattusRattus | re series termination - shouldn't have any effect on impeadance matching, it does make length matching a little more complex I admit, but you only have to add the length of 2 traces togeather | 15:10 |
| mithro | RattusRattus: impedance is control by things like the width of the trace, right? | 15:11 |
| mithro | ssk1328: So I think we are better off converting to pixels earlier on in the pipeline because most things need to work with pixels | 15:11 |
| RattusRattus | yes, and distance to adjacent tracks, height over ground etc. | 15:11 |
| mithro | The SMD resistor pads (and the resistor itself) is a giant discontinuity in that | 15:12 |
| ssk1328 | mithro: So I guess, I should do the P4 diagram now | 15:12 |
| mithro | ssk1328: Yeah - go with the P4 diagram if you think it's going to get you finished sooner - I do think we'll need to eventually refactor to P2 after GSoC | 15:13 |
| * RattusRattus rolls over laughing 'impeadance' in this case is the effective charicteristic of the transmission line. the input you are driving will effectivly be open circuit (severl meg) adding 30 or 50R to that will make little or no differance, but will reduce amplitude of reflected signals massivly. | 15:15 | |
| RattusRattus | hence the series termination being good for EMC but not really effecting the transmission line itself | 15:16 |
| mithro | RattusRattus: If my trace needs to be 5mil width for 50 Ohm, and you make the trace 20mil - it's going to have a very different impedance right? | 15:18 |
| mithro | RattusRattus: The resistor pad is a short 20mil wide trace. | 15:18 |
| RattusRattus | yes. so I have 96mm length transmission at 5mil and 4mm at 20 mil there is a differance but this is no where near as bad as 100mm all at 20mil... | 15:20 |
| RattusRattus | at which point you are gaining more by having the resistor reduce reflection than you lose by the short length of incorrect impeadance. | 15:21 |
| RattusRattus | (which btw is true of the IC & connector footprints as well) | 15:21 |
| RattusRattus | anyway you have said that you are not interested in series termination. so lets move on. | 15:23 |
| mithro | RattusRattus: This is the type of thing I'm talking about -> http://www.ti.com/lit/an/slla324/slla324.pdf | 15:23 |
| mithro | RattusRattus: I guess maybe it is because I'm working in a different domain here | 15:25 |
| mithro | Anyway - if you are offering to do the construction (and will actually do it) then you get to say if there are series resistors | 15:27 |
| mithro | People doing the work get to make the choices :-P | 15:27 |
| mithro | RattusRattus: I'd like to understand point 10 | 15:28 |
| RattusRattus | mithro: (1) so this is looking at ESD protection in a transmission line (indeed I state in points 17 and 19 there should be ESD protection). it then goes on to compensate for the effect of introducing the IC package to the charicteristic impeadance by using 'skinny' lines to balance out the effect. nice. | 15:29 |
| RattusRattus | (2) the same technique could apply to series termination - only there is no signal (at least not enough) after the resistor to make any effect | 15:30 |
| RattusRattus | mithro: if hand placing then yes I can assemble. logisticly I know that of your estimated 10 boards I would end up with 3 of them any way so I guess that makes sence | 15:31 |
| mithro | RattusRattus: I would probably do ~20 boards with the expectation of getting about 15ish that works reliably | 15:31 |
| RattusRattus | meh that would still make the 3 for Debian a significant fraction of the boards. | 15:32 |
| RattusRattus | re point 10 | 15:32 |
| RattusRattus | the datasheet talks about there being high ripple current (i.e. big noise source) on the V_DD net (driving the digital RGB bus). thefore filtering this power domain, and keeping it as small as possible is advantagous in reducing noise emmission | 15:34 |
| RattusRattus | the ferite adds some degree of isolation from this power domain to the parent domain (main 3V3 rail). Selecting a ferite to be as high impeadance as possible to the clock frequency you will use on this bus means that you get the effect at the point where you begin to need it. in all probability the impeadance will still be rising at higher frequencies as well, but this is the first frequency that | 15:38 |
| RattusRattus | needs to be 'snubbed' | 15:38 |
| mithro | RattusRattus: So, I think I'm still missing something here | 15:47 |
| RattusRattus | right now that poer domain is directly connected to the main 3v3 rail. you don't want that rail acting as an antenna and then back coupling into your sensative analogue signals | 15:48 |
| mithro | RattusRattus: can you do a diagram of (21)? Or even better add it directly to the schematic :P | 16:07 |
| RattusRattus | sure | 16:07 |
| CarlFK | thaytan:https://github.com/CarlFK/voctomix-outcasts/blob/master/tests/mock-stack.sh I think it worked, but it is back to erroring http://paste.ubuntu.com/22814309/ | 16:09 |
| tpb | Title: voctomix-outcasts/mock-stack.sh at master · CarlFK/voctomix-outcasts · GitHub (at github.com) | 16:09 |
| RattusRattus | I think you miss understand my comment on point 20. the IC has an internal weak pull down an A0. it will default to A0 = 0. adding an external pullup will make A0 = 1. therfore there is never any need to fit a pull down.... | 16:10 |
| RattusRattus | mithro: want me to addin ESD as well? | 16:11 |
| mithro | RattusRattus: I was looking at your suggested IC | 16:11 |
| * RattusRattus has used the TI part before but not the other | 16:12 | |
| mithro | RattusRattus: it looks like it might be cheaper then the I2C level shifter | 16:12 |
| mithro | Looks like http://www.digikey.com/product-detail/en/on-semiconductor/CM2009-02QR/CM2009-02QROSCT-ND/2442764 might be an alternative | 16:12 |
| tpb | Title: CM2009-02QR ON Semiconductor | Circuit Protection | DigiKey (at www.digikey.com) | 16:12 |
| RattusRattus | yep. looks fine | 16:13 |
| RattusRattus | looks pin compatible with the Ti parts as well. | 16:15 |
| mithro | RattusRattus: I've pushed the latest changes to git | 16:17 |
| RattusRattus | cool will download this evening, and add the 5V VGA bit | 16:17 |
| mithro | okay | 16:18 |
| mithro | at some point I have to do the IO pin changes | 16:18 |
| RattusRattus | want me to addin the VGA ESD filter too? | 16:18 |
| mithro | RattusRattus: I wouldn't object | 16:18 |
| RattusRattus | and the SP724AHT? | 16:19 |
| RattusRattus | Don't wory about pin swapping - do that during PCB layout | 16:19 |
| mithro | RattusRattus: KiCad doesn't have a nice way of doing pin swapping | 16:20 |
| mithro | RattusRattus: so the PCB person sent me a list of her suggestions which I have to do manually | 16:20 |
| RattusRattus | :-) yep. swap and itterate, I remember those days | 16:21 |
| RattusRattus | are you paying for board layout? | 16:21 |
| RattusRattus | or is she doing it free | 16:21 |
| mithro | Doing it for free, she's retired and looking for something to do I believe | 16:22 |
| *** rohitksingh has quit IRC | 16:22 | |
| RattusRattus | :-) great (/me would have done it to save you paying otherwise) | 16:23 |
| mithro | RattusRattus: well, I have a bunch of other boards I need done :-P | 16:24 |
| RattusRattus | I am concerned about #12 though. you state "DATACK is bidirectional. Either the FPGA or the AD9984 can supply the data | 16:24 |
| RattusRattus | clock signal.but the datasheet states "This is the main clock output signal used to strobe the output data and HSOUT into | 16:24 |
| RattusRattus | external logic | 16:25 |
| RattusRattus | so you are going to have a problem there | 16:25 |
| * RattusRattus is happy to route OH PCBs | 16:25 | |
| thaytan | CarlFK, not sure, but if you start the sender before the receiver, the receiver might not get all the data? | 16:25 |
| thaytan | missing the first part of a matroska file, even a streamable one, isn't good | 16:25 |
| CarlFK | ah right | 16:26 |
| RattusRattus | mithro: I havn't found how to make that output Hi-Z in the datasheet | 16:26 |
| *** rohitksingh has joined #timvideos | 16:27 | |
| mithro | RattusRattus: maybe I'm confused with a different AD part | 16:27 |
| mithro | RattusRattus: The FPGA pin can be set as In, Out or BiDir | 16:27 |
| RattusRattus | lol - this is the only potential show stopper :-) as long as you only ever use the FPGA as IN then no issue, but if you want to drive from the FPGA as well then we need to add in a buffer with high-Z on dissable | 16:29 |
| mithro | RattusRattus: hrm? If the AD part doesn't support driving DATACK, then we don't make the FPGA do that :P | 16:31 |
| mithro | RattusRattus: oh, the FPGA can put its pins in High-Z too | 16:31 |
| RattusRattus | OOOOH!!! of cause we also need to check power on / reset states of IO lines from the FPGA to here as well. if any default to output that will later be used as an input then that is a VERY good reason to include series termination... | 16:31 |
| mithro | RattusRattus: we can control what they are during power on / reset - I believe its currently configured as high-z | 16:32 |
| RattusRattus | mithro: the AD part always drives the DATACK line..... it was you suggesting that you may want to drive that from the FPGA that has me worried | 16:32 |
| RattusRattus | reset power on as Hi- | 16:33 |
| RattusRattus | Z is always the safest | 16:33 |
| RattusRattus | that clock is the dot clock from the AD part to the FPGA..... | 16:33 |
| mithro | RattusRattus: I was sure that it had a way to source the dot clock from the FPGA instead - but that must be a different part | 16:34 |
| RattusRattus | EXTCK/COAST This pin has dual functionality. | 16:35 |
| RattusRattus | EXTCK allows the insertion of an external clock source rather than the internally | 16:35 |
| RattusRattus | generated, PLL locked clock | 16:36 |
| RattusRattus | but that is for analogue signal | 16:36 |
| mithro | rohitksingh is the expert anyway | 16:36 |
| RattusRattus | :-) | 16:37 |
| RattusRattus | ok | 16:37 |
| RattusRattus | ttfn - will update schematic tonight | 16:37 |
| mithro | I'm about to go to bed | 16:37 |
| mithro | as soon as CI provide I can merge this change | 16:37 |
| *** rohitksingh has quit IRC | 16:42 | |
| *** rohitksingh has joined #timvideos | 17:02 | |
| *** rohitksingh1 has joined #timvideos | 17:08 | |
| *** rohitksingh has quit IRC | 17:09 | |
| *** danielki has left #timvideos | 17:45 | |
| *** sb0 has quit IRC | 18:16 | |
| *** hozer has quit IRC | 18:32 | |
| *** rohitksingh1 has quit IRC | 19:00 | |
| *** Bertl is now known as Bertl_oO | 20:17 | |
| *** ssk1328 has quit IRC | 20:55 | |
| *** cr1901 has quit IRC | 23:56 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!