Wednesday, 2015-11-11

*** tpb has joined #timvideos00:00
Bertl_oOthey are also using a zynq based system and the cameras are FOSS/OH00:00
mithroBertl_oO: I think last time I looked at them, the price and performance didn't really stand up to commercial alternatives and the project kind of looked dead?00:01
Bertl_oOnah, andrey is quite active and they recently finished the design for the new nc393 camera00:01
mithroBut I didn't look too closely00:01
Bertl_oOI cannot judge the price but FOSS/OH often has a higher price because of lower volumes00:02
Bertl_oOthe advantage is that you have the freedom to do what you want :)00:03
Bertl_oO (here some updates)00:03
mithro_florent_: have you see before?00:08
tpbTitle: Elphel/gtxe2_gpl · GitHub (at
mithroBertl_oO: at some point we are all going to have to get together and write a WebM encoder00:14
Bertl_oOyou mean VP8/VP9?00:21
mithroBertl_oO: yes I do00:21
Bertl_oOyeah, might be interesting at some point00:23
mithroxfxf / CarlFK:
tpbTitle: Cameras · timvideos/HDMI2USB Wiki · GitHub (at
*** CarlFK has quit IRC01:29
tpbTitle: Options - Google Drawings (at
*** Bertl_oO is now known as Bertl_zZ02:18
*** CarlFK has joined #timvideos04:53
*** ChanServ sets mode: +v CarlFK04:53
tpbTitle: Options - Google Drawings (at
CarlFKmithro: lol @ venue equipment06:13
CarlFKdid you see vocto was used just in production ?06:14
CarlFK   (not vocto.  recorded to raw files,  veyepar made the .mlt cutlist, including the pic-in-pic. ... and see a bug in the encoder06:19
mithrowhat is going on in that video when the PIP is up?06:21
mithroThere is a kind of solarised component store06:22
mithroCarlFK: yes - I did hear that had happened06:22
mithroCarlFK: I'm interesting to hear how MaZderMind thinks it went06:22
mithroCarlFK: sadly, I can't read the German discussion :P06:23
CarlFKmithro: what is going on is a bug/artifact in the encoder06:23
CarlFKif you look in the background of the PIP, you will see the "stuff" that is somehow glowing06:24
mithroCarlFK: I've wondered if we should just capture the raw files using a gstreamer pipeline and then mux them together side-by-side using veyepar mlt06:24
CarlFK4:3 pres, so I moved it over to the left, and the area that opened up..   found some data to fill in? :D06:24
mithroCarlFK: was that a HDMI2USB capture?06:25
mithroCarlFK: there are some weird artifacts on some of the text edges which we should investigate06:25
mithroCarlFK: actually there are quite a few weird artifacts which can be seen if you turn on 720p mode06:26
mithroCarlFK: was your Atlys overheating?06:26
CarlFKmithro: um.. heck if I know :)06:26
mithroCarlFK: can you send me the raw video you captured from the hdmi2usb?06:27
mithroCarlFK: I think to figure out what is going on with your video, we will need
tpbTitle: Calculate CRC code on pixels during frame transfer · Issue #130 · timvideos/HDMI2USB-misoc-firmware · GitHub (at
CarlFKmithro: 400mb... 16%06:38
mithroCarlFK: oh that is the upload progress06:39
CarlFKmithro: yes06:39
CarlFKUpload:  22% |||||||||                               | Time: 0:04:51 376.13 kB/s06:39
CarlFKlook familiar :)06:39
mithroCarlFK: I have a feeling I wrote something for you around that?06:41
CarlFKthat's the patched or something like that progress bar06:42
mithroha yeah06:43
*** se6astian|away is now known as se6astian08:07
xfxfCarlFK: oh wow, vocto works?08:17
xfxfholy shit that's awesome, well done08:18
xfxfvid obv isn't perfect but man, that's a huge step forward08:18
xfxfCarlFK: what camera are you using?08:19
*** CarlFK has quit IRC08:20
mithroxfxf: that video isn't from voctomix from what I understand08:27
xfxfis that a veyepar job?08:27
mithroxfxf: yes08:28
mithro5:17 PM <+CarlFK>   (not vocto.  recorded to raw files,  veyepar made the .mlt cutlist, including the pic-in-pic. ... and see a bug in the encoder08:28
*** CarlFK has joined #timvideos08:35
*** ChanServ sets mode: +v CarlFK08:35
_florent_CarlFK: can you give the revision of the firmware you used for the video with artifacts?08:53
CarlFK_florent_: it is what is in testing :)08:53
CarlFKno clue how easy it will be to trace that to what you need08:54
CarlFKthe machines are all packed right now and I need to get to bed08:54
mithroCarlFK: I can get you that09:04
mithro_florent_: I can get you that09:04
mithro_florent_: be back in an hour09:04
ysionneaumithro ping!10:08
mithroysionneau: pong?10:08
ysionneaumithro: does the new code seems more flexible to you?10:10
ysionneauthe C code makes sense?10:10
mithroysionneau: I haven't yet had a chance to look at it on anything apart from my phone10:14
mithroysionneau: which isn't the greatest for understanding what is going on :P10:14
ysionneauahah ok no pb10:14
ysionneauI need to refactor a bit anyway, to add some higher level layer10:15
tpbTitle: HDMI2USB-firmware-prebuilt/testing at master · timvideos/HDMI2USB-firmware-prebuilt · GitHub (at
mithro_florent_: git revision v0.0.0-453-g4f2aac210:16
seaLnemithro: the problem i found when having a look for cameras was the lack of 720p10:17
mithroseaLne: _florent_ refactored the code so we can enable 1080p30 now10:18
mithroseaLne: Did you see ?10:19
tpbTitle: Cameras · timvideos/HDMI2USB Wiki · GitHub (at
seaLnei was just reading backlog10:19
mithroseaLne: ahh cool10:20
seaLnebeen looking at what was available on ebay the last few weeks10:20
mithroseaLne: please do add things there if you find interesting stuff10:21
_florent_mithro: OK thanks, it seems the changes I did on the buffer before the encoder are not yet ready to be used in production10:28
mithro_florent_: I think I've seen this before your changes10:29
_florent_what? the artifacts or the issues with colors?10:30
mithro_florent_: no the white lines and pixel offsets10:30
_florent_I'll try to look at that soon10:31
mithroI think I see some similar artifacts in my recording at
_florent_thanks, this seems really related to my last changes10:33
mithro_florent_: but it is hard to tell with the h264 encoding that hangouts did10:33
_florent_I think I should revert my changes for now (or you should use an older version)10:34
_florent_the artifacts we see in CarlFK video are clearly related to my last changes10:34
mithropossible artifact in SyPy video
_florent_ah yes, that's similar10:35
mithro_florent_: that is *well* before your FIFO change10:35
mithro_florent_: those issues look more like issues in the HDMI sampler then the JPEG encoder?10:36
mithroHere is another one from the SyPy video ->
_florent_ok interesting10:37
_florent_can you also log these captures in the issue?10:37
mithro_florent_: done!10:39
mithro_florent_: they do look like pixels "slipping" to me - but I might just be jumping to conclusions10:40
_florent_mithro: thanks, I will investigate on that10:46
*** Bertl_zZ is now known as Bertl11:38
ysionneaumithro: some documentation
tpbTitle: i2cslave/ at shift_register_complex · fallen/i2cslave · GitHub (at
ysionneausome pics of the setup
mithroysionneau: Did you mean to write up this documentation on the shift register when I was after this for the GPIO delay experiments?13:03
ysionneaunop I still have in my head to write the doc for the gpio delay stuff13:04
ysionneaubut I felt also like to write this one13:04
ysionneauI'll do that now13:05
mithroI feel like this is written from the wrong side?13:05
ysionneauwhat do you mean?13:05
mithroIt's written from the person accessing the emulated device, rather then the person doing the emulation?13:05
ysionneauah, the narration13:06
ysionneaumaybe yes13:06
ysionneauI'll add a small paragraph to explain the main.c then13:06
ysionneaubut there are some explanations in the documentation already for it13:06
mithroI don't quite understand what is going on in main.c13:08
ysionneaubasically I'm polling for something to happen on the I2C bus, when there's a read the shift reg becomes "empty" and I see it with a status flag, I can then refill the shift reg13:09
ysionneauwhen there's a write, the shift reg becomes "full" so I also detect that, and I can then do some protocol business (i.e. update the "addr" variable)13:10
ysionneaui2c_shift_reg_read() / i2c_shift_reg_write() are used to read from/write to the shift reg13:11
ysionneaui2c_status_read() / i2c_status_write() are used to read the status bits (FULL/EMPTY conditions) and for clearing them13:11
ysionneauI clear them by writing the READY value which is 013:12
ysionneauoh, and i2c_slave_addr_write() at the beginning is to set the slave address13:13
ysionneaufake_fw contains dummy data, just for the testing purposes13:13
ysionneaudon't know if that's clear enough :o13:14
*** thaytan_ has joined #timvideos13:16
ysionneaubasically i2c_status_read() returns the value of the shift_reg_empty / shift_reg_full bits you can see on the logic analyzer screenshots13:17
ysionneauand i2c_status_write() writes to them (usually just to clear them)13:17
*** thaytan has quit IRC13:17
mithroysionneau: so, looking at
mithroThere is the initial address frame13:25
mithroand then n data frames after it13:25
mithroso say, I have an I2C protocol, where the I2C master sends two datagrams as the first request (a 16bit address)13:29
ysionneauyes, 2 subsequent writes13:30
mithroI call i2c_shift_reg_read twice?13:31
ysionneauyou can't initiate anything as you are the slave13:32
ysionneauso you need to "wait" for the master to do those 2 writes13:32
ysionneauso you wait for the first time the shift reg is "full", you call i2c_shift_reg_read()13:32
ysionneauyou clear the flag, you wait again for it to become full again13:32
ysionneauand you call i2c_shift_reg_read() a second time13:33
mithroWhat is happening on line 25?13:34
ysionneauon line 25, I pre-load the shift reg with fake_fw[0]13:34
ysionneaubecause I can't know if the master will start with a read or a write13:35
ysionneauif it starts with a write to ask some address, then this will be overwritten13:35
ysionneauif it starts with a read, to sequentially read (from address 0) then it will get this first byte13:35
ysionneauif the master always do write(address) read(data); then this line 25 is for nothing and can be removed13:36
mithroysionneau: so, you then wait until the shift register is empty and load it with the next value on line 29?13:37
ysionneauthe actual reloading is done line 3213:37
ysionneaubut yes13:37
mithroSo, if you have I2C master reading two datagram bytes, you need to make sure the next value is in the register by the time it starts shifting it out?13:38
ysionneau(+ address auto increment)13:38
ysionneaumithro: yes, that's why I use clock stretching (aka PAUSE) when shift reg is empty13:38
ysionneauso that the master waits for the software reload13:38
ysionneauthat's what's happening in the first "scenario" of the documentation13:39
ysionneauseveral reads in a row13:39
ysionneaubasically, until the software clears the "shift reg empty" flag (line 33), the master cannot issue another read13:40
mithroysionneau: can this work without needing to do clock stretching?13:40
ysionneaumaybe, we would have to test13:40
ysionneaubut that would be open the "race conditions"13:41
ysionneauif I can call it that way13:41
ysionneaunot all masters support clock stretching though, I hope the FX2 does. If it really supports I2C (and not Two Wire Interface) it should13:42
ysionneau <=13:45
tpbTitle: I2C Clock Stretching in FX2LP - KBA84113 | Cypress (at
ysionneauit seems it does o/13:45
mithroysionneau: the only difference between the first address byte and the subsequent data bytes is if we know at the start if we should ack them?13:46
mithroIE we don't know to ack the first address byte until we know it matches our address?13:47
ysionneaunot sure I understand the question13:48
ysionneauaren't you mixing "slave address" and "byte address"?13:48
mithroI2C address13:48
ysionneauah ok13:48
ysionneauyes, if the I2C slave address is not ourself, we don't ack13:48
ysionneauwe let someone else ack (or no-one and this is a NACK)13:49
ysionneauI don't know if that answers your question13:49
* ysionneau not a native speaker here13:49
mithroI2C is effectively, Start Bit, 8 bits, ack, 8 bits, ack, 8 bits, ack, Stop bit13:50
ysionneauyes, or you can also replace the stop bit with a "restart bit" (which AFAIK is just a start bit)13:51
mithroThe "first" 8 bits are specially because they are the address + r/w direction of the I2C device13:51
ysionneauthose are handled by the gateware (the I2C slave addr matching)13:51
mithroysionneau: yes, but it means we can only pretend to be a single I2C slave at once, right?13:52
mithroAfter the 8 bits, how long do we have to perform an "ack"?13:52
ysionneauyes, but if the requests are not too mixy, you can change your I2C slave addr on the fly using the i2c_slave_addr_write() function13:52
ysionneauand you could multiplex several slaves13:52
ysionneauif you know the spatial (or temporal) access pattern13:53
ysionneaubut it does not cover all the cases indeed13:53
ysionneau14:49 <@mithro> After the 8 bits, how long do we have to perform an "ack"? < I think we should drive SDA low upon SCL going low from previous bit13:54
ysionneauso that it's ready when SCL goes up again13:54
ysionneauI don't know the tolerances13:54
mithroI'm guessing the same problem you ran into with just bit-banging would prevent you servicing an interrupt in time to confirm if you wanted to ack or not13:54
ysionneauI'm guessing also13:54
ysionneaubut, maybe clock stretching can be applied here also13:54
ysionneauand I could provide something more adaptable to allow to read the slave addr request and ack or nack by SW13:55
ysionneauI mean, maybe I can hold SCL low before the ACK/NACK bit, to tell the master to wait a bit so that the software makes its mind on whether it wants to ack or nack13:56
mithroThat feels very non-standard :)13:57
ysionneaunot sure, need to check the places where clock stretching is allowed13:58
mithroysionneau: for now, I think it's good enough without needing that13:58
mithroysionneau: we can keep the address checking specialization13:58
mithroysionneau: can we double buffer the register?13:59
mithroysionneau: so we don't have to do clock stretching?13:59
ysionneauthat's what I wanted to avoid :p13:59
ysionneauhaving a FIFO to handle13:59
*** thaytan_ is now known as thaytan13:59
mithroysionneau: why?13:59
*** ChanServ sets mode: +v thaytan13:59
ysionneaujust because I didn't feel very confortable writing it, I wanted to go for the simplest stuff14:00
ysionneaubut I can have a look at it14:00
ysionneauthere is a FIFO block in migen14:00
mithroysionneau: I think we only want a depth of one14:00
ysionneaujust need to drive it correctly14:00
mithrorather then a real fifo14:00
mithroactually, if you just make the shift register 16 bits, then it should work, no?14:01
ysionneauyeah I thought of that14:01
ysionneauthen you need some mechanism to know which part is real data or not14:01
mithroysionneau: what do you mean?14:01
ysionneauwell, you then have a "data_vailable" bit (on top of the already existing shift_reg_full bit)14:02
ysionneauah, you can check with data_available and not full.14:02
ysionneauwould mean only the lower part is real data14:02
ysionneauhmm then maybe we have issues for atomic update of the register14:03
mithroysionneau: actually its easier if we have 2 8 bit registers14:04
mithroysionneau: The "ACTIVE" and the "NEXT"14:04
mithroWhen the "ACTIVE" goes empty, there is a setting which says transfer NEXT into the "ACTIVE"14:05
mithroand you get an interrupt14:05
mithrothen you put the next byte into the NEXT14:05
ysionneauthat works for sequential reads I would say14:05
ysionneaubut not for random reads14:05
ysionneaufor sequential reads you can predict two reads in a row and put both active/next values14:06
mithroysionneau: For random reads you have to write a new address each time?14:06
ysionneaufor random read you have a write followed with a read14:06
ysionneaumithro: not sure, i would say once you've written one you can also use auto increment14:06
mithroysionneau: with auto-increment you'll know what the next byte is, right?14:07
ysionneauyes but for the first read14:07
ysionneauyou have WRITE followed by READ14:07
ysionneauyou don't know which data to send until the write is completed14:07
ysionneaubut you need to be fast because the read is coming right away after the write14:08
ysionneauand since you need to wait for the write to complete, you can't use double buffering tricks14:08
mithroysionneau: doesn't the read need to resend the address?14:08
ysionneauI was talking about I2C transactions14:09
ysionneauwrite (for the address) read (for the data)14:09
mithroEach transaction starts with the "address+r/w" byte, right?14:09
ysionneauin case of a random read, you have first a Write, then another transaction with a Read14:10
ysionneau(or 2 writes in case of 2 bytes addresses)14:10
mithroSo between the "write address EEPROM cmd" and the "get EEPROM data cmd" you'll have a whole byte of I2C data?14:10
ysionneauah yes, you have the slave address yes14:11
mithrowhich is the I2C address+r/w byte14:11
ysionneauI see, there's time then :o14:11
mithroYou have 9bits * 400kHz :)14:12
ysionneauyep that's pretty ok I guess14:13
mithroTo get your byte of data into the "ACTIVE" shift register, and also preload "NEXT" with byte+1 data14:13
ysionneauso IIUC I can just remove the clock stretching from the current implementation, and it should work out of the box14:14
ysionneaueven without adding extra shift register14:14
ysionneauexcept for sequential reads I mean14:14
mithroysionneau: not so, you need the clock stretching for the sequential read right now?14:15
mithroysionneau: the NEXT register just is a way to optimise sequential reads?14:15
ysionneaubut I can remove the clock stretching, and test some random reads14:15
ysionneauto see if that works well14:15
mithroysionneau: yeah, I guess so?14:15
mithrobtw I should be home in bed14:15
ysionneauoh you're not home14:15
ysionneauso, quickly, do I implement for double buffering stuff or are we good with the current implementation?14:16
mithroysionneau: btw -> this line has too many magic numbers14:16
mithroysionneau:   Wire.requestFrom(0x50, 9);    // request 9 bytes from slave device #814:16
mithrowhy 0x50?14:16
ysionneauthe main issue is the comment is wrong :p14:17
ysionneauit's device #0x5014:17
ysionneauI will replace with a macro DEVICE_ADDRESS14:17
mithroysionneau:   Wire.requestFrom(EEPROM_I2C_ADDR, 9);    // request 9 bytes14:17
ysionneauyep :)14:17
ysionneausorry about that14:17
mithroysionneau: no worries, I've spent the last 2 weekends removing magic numbers from the FX2 firmware14:18
ysionneau(at first I didn't plan on sharing the Arduino code :p)14:18
ysionneaubut I agree all of this needs some cleanup14:18
mithroysionneau: I assume your FX2 hasn't turned up yet?14:19
ysionneauI finished at more than midnight yesterday I was a bit sleepy:'14:19
ysionneauno :(14:19
mithro_florent_: btw Has a package from digilent turned up for you at all?14:19
ysionneauso I can't test with real HW14:19
mithroysionneau: I think your arduino emulation will be good enough to get this working14:19
ysionneaueither I wait for the package to arrive, or I start the integration work, send you a patch to your own repo, and let you test (but it's not cool for debug)14:19
ysionneauyes I think also14:20
mithroysionneau: oh, and remember your address is dependent on the EEPROM size emulation you are using14:20
ysionneauah yes, this is just testing code14:20
ysionneaudefault is 100 kHz o/14:21
ysionneaucool there's the eeprom layout14:23
ysionneauah yes I see the A0/A1/A2 pin values14:25
mithroysionneau: I actually have no idea how that effects the I2C address, I assume that maybe they are just the lower bits of the I2C address?14:25
ysionneauyes, it's not in this document14:26
ysionneaubut on another datasheet you went me it explains which bits are these A*14:26
ysionneauLSB or MSB I don't remember14:26
ysionneauah, got it14:26
mithroysionneau: so, what we need in the end is a gateware which samples the switch status on "boot" and then provides one of two .hex files14:26
ysionneauI would make this sampling + the chosing done in sw, is that Ok?14:27
mithroIdeally the .hex files would be stored in the SPI flash, but a temporary/initial solution would be to just bake them into the gateware as ROM data14:28
mithroysionneau: perfectly fine14:28
ysionneauI think storing both in spi flash is really the easiest solution14:29
ysionneausince sw can easily access it, it's memory mapped etc14:29
ysionneauthen you can just sample the switch status, and assign a pointer value to one or the other spi flash region and you're good to go14:30
ysionneauwe would also need to make the fw .bin instead of .hex, but I guess it's easy to do14:30
ysionneauah no I remember now, the meaning of A0/A1/A2 was in the eeprom datasheet, sounds logical now :)14:32
ysionneauok, page 7 of
ysionneauFigure 5-114:33
ysionneauslave address will be 1010 A2 A1 A014:34
ysionneauso 0x50 if A[2:0] == 000 for 1 byte addresses14:35
ysionneaufor 16 kB eeprom you need A[2:0] == 001 so slave address will be 1010 001 = 0x5114:36
mithroI'm heading home to bed14:38
*** se6astian is now known as se6astian|away16:20
*** se6astian|away is now known as se6astian19:03
*** se6astian is now known as se6astian|away19:03
*** se6astian|away is now known as se6astian19:04
*** se6astian is now known as se6astian|away21:48
CarlFKtumbleweed: you haven't built a box or anything for your atlys right?22:46
tumbleweedand I'm getting worried about the ports on it :)23:00
CarlFKtumbleweed: I'll make something for it.  I just got the cables23:01
tumbleweedoh, VGA adaptors arrived btw23:03
tumbleweedsame ones we used at cambridge23:03
CarlFKdid you use your Atlys in Cambridge?23:05
CarlFKusing dvswtich?23:06
CarlFKeverything 1024x768?23:06
CarlFKso 4:323:06
tumbleweedeverything 4:323:06
tumbleweedatlys was on a 1024x768 mode23:07
CarlFKfrom what I gather... the 2 rooms we are in are vga only, 4:3 screens23:07
tumbleweedwhat's the story with recording? did they agree to dvswitch in the end?23:07
CarlFKno .. you haven't been hearing me cry daily? :P23:08
tumbleweedwell yes, but I don't have the full picture23:08
tumbleweedyou're recording all streams and they'll edit by hand, later?23:08
CarlFKAtlys gst pipeline record to mkv.  camera record to SD Card,23:09
CarlFKcp that stuff onto my i7 laptop...23:09
CarlFKdo some veyepar things: add, read times, make .mlt23:09
CarlFKthen... drumroll23:09
CarlFKShotcut foo.mlt, find the .mkv in the list of assets, drag it down to the empty video track, save.23:10
CarlFKmv foo.mlt ../custom/mlt23:10
CarlFKgo back to normal veyepar encode/post23:10
CarlFKoh wait.. missed a small step23:11
CarlFKwrite down hms when talk start and end23:11
tumbleweedso, the stuff you get from the camera won't be well timecoded23:11
CarlFKin veyepar, replace the scheduled start with the real star23:11
tumbleweedit'd probably be easier to put the screengrabbed video into veyepar than the camera video23:11
tumbleweedwell, I guess that's not dvswitch either, so it's all kind of custom and hacky23:12
CarlFKthe camera and laptop clocks are synced thanks to daven (long time dc-video guy23:12
CarlFKlaptop audio out into that yellow video in23:13
CarlFKplay some modem sounding time code stuff23:13
CarlFKsets the cam's clock23:13
tumbleweedso what do we do? hang around and babysit the atlys?23:14
CarlFKand point the camera.. or soemthing23:14
CarlFKnot much :(23:14
CarlFKi feel a little bad23:14
CarlFKbut you made me go to ZA so that makes up for it :D23:15
CarlFKim not too worried about it23:15
tumbleweedI have things to hack on23:15
CarlFKI figured as much.23:15
tumbleweedbetter than lying in bed at home, watching TV23:15
CarlFKand there is a little tech to be gleamed from the whole thing23:16
CarlFKand we get to hang out with the PyOhio chair23:16
CarlFKso not 100% disaster23:16
tumbleweedsomething like this would be a great excuse to muck around with voctomix23:16
tumbleweedbut that requires hardware, and an actual separate camera operator23:17
tumbleweed(I mean, someone to take care of things while we fight with voctomix)23:17
CarlFKand more atlys boards23:18
tumbleweedor, even better, something that captures HDMI + audio23:18
CarlFKoh yeah, that :p23:18
CarlFKdo you have some 32g sd cards?23:19
CarlFKI have 6 new ones.  180 min each23:20
tumbleweedshould be enough23:20
CarlFKthe file names are 0000 0001 0002  and it resets when you put a fresh card in23:20
CarlFKI hope I don't step on files23:21
tumbleweedwhy can't they use nice filenames with the full timestamp in them?23:21
CarlFKdvswich makes so many problems go away23:21

Generated by 2.13.1 by Marius Gedminas - find it at!