Current Server Time: 18:41 (Central Europe)

#apertus IRC Channel Logs

2016/01/24

Timezone: UTC


01:48
John_K
got the image working fine after removing the systemd link for cmv12k
01:49
John_K
will start bringing up buck supplies after supper
04:35
Bertl_zZ
changed nick to: Bertl
04:35
Bertl
morning folks!
05:20
John_K
good morning!
05:23
Bertl
how's the progress? FTDI working with the right crystal?
05:23
John_K
haven't had a chance to replace it yet, going to focus on power supply bringup now that the Linux image is running
05:24
John_K
(I don't have a hot air re-work station here at home yet)
05:25
Bertl
I see, well, if you do not care about the 24MHz crystal, there is a simple trick to switch it out
05:26
John_K
oh?
05:26
John_K
cut it in half? :)
05:26
Bertl
you put a tiny square piece of copper or copper mesh (desoldering wick) on the crystal
05:26
Bertl
get your biggest iron/tip and just heat it up to 360°C
05:26
John_K
hehehe
05:27
John_K
yeah I suppose that would work
05:27
Bertl
that way it comes off really fast with no harm to the PCB
05:28
Bertl
I sometimes prefer that to IR or hot air because it is really beneficial for the PCB and surrounding
05:28
Bertl
(but of course, it stresses the crystal so you won't be able to use that lateron)
05:28
John_K
good point, it seems like it would be hard to get the new crystal on with just an iron though
05:29
Bertl
that is actually not a problem either
05:30
Bertl
you clean the pads and place it properly, then you pin it down with something (I usually use a third hand with a wooden toothpick :)
05:32
Bertl
then you just put solder on all four pads, it will make the connection just fine as the crystals have edge connections as well
05:32
John_K
maybe I'll give that a shot on one of the boards tonight
05:33
John_K
currently the FTDI is just for FPGA JTAG right?
05:33
Bertl
yeah, and you do not even need it for that
05:33
John_K
right, since PS can load the FW
05:33
Bertl
i.e. you can use the JTAG header on the Microzed
05:33
John_K
or that ;)
05:33
Bertl
you just need a programmer for that
05:33
Bertl
and yes, you typically load the bitstream from the PS
05:34
Bertl
it is just a convenient way for debugging (the FTDI)
05:34
John_K
right
05:35
Bertl
btw, I think I found a way to attach it to the I2C bus and have it work without disruptive behaviour (without level translation or something like that)
05:35
John_K
it seems there is something amiss with mmc1, I'm seeing a lot of messages like "mmc1: Got command interrupt 0x00030000 even though no command operation was in progress." during boot
05:35
John_K
ooh that would be nice
05:35
John_K
IOW_mmc1: Card removed during transfer!
05:35
John_K
mmc1: Resetting controller.â
05:35
John_K
I also just saw "
05:36
John_K
maybe there is a missing pull-down?
05:37
John_K
have you seen these as well?
05:37
Bertl
yes, I'm not sure what the cause is, but most likely it is a driver issue
05:37
Bertl
the main problem with mmc1 is that we don't have a work CD there
05:38
John_K
oh
05:38
Bertl
and while the driver allegedly supports operation without CD, it seems to have some issues
05:38
Bertl
we have a CD pin, but a) it has a bug on your version of the board
05:38
John_K
the line isn't routed? or the HW doesn't support CD for mmc1?
05:38
John_K
ah
05:38
Bertl
and b) it is connected to one of the GPIO extenders
05:38
John_K
so no interrupt
05:39
Bertl
so it won't help with the current driver/setup
05:39
John_K
right
05:39
Bertl
the best way is to either ignore or disable mmc1 for now
05:39
Bertl
you probably don't need it anyway, or do you?
05:39
John_K
yeah, I don't think I'll be using it anyway
05:39
John_K
I don't think so
05:39
Bertl
for the bug, it's the pins of the microSD slot which are connected the wrong way
05:40
Bertl
I presumed that CD1/CD2 (schematic/layout) would get connected/disconnected when a card is inserted
05:40
Bertl
but actually they get both connected to MT1/MT2 instead
05:41
Bertl
this was fixed recently
05:42
John_K
noted
05:42
John_K
btw in pac1720_info.sh
05:42
John_K
MR1v=(0.03 0.03 0.03 0.03 0.03 0.03 0.03 0.03 0.03 0.03 0.03)
05:42
John_K
MR2v=(0.03 0.03 0.03 0.03 0.03 0.03 0.03 0.03 0.03 0.03 0.03)
05:42
John_K
is that indicating a 0.03 ohm sense resistor?
05:42
Bertl
those are the shunt resistor values
05:42
Bertl
yes
05:42
Bertl
so if you are using R03, then that will work fine, if you are on R015, you need to change that
05:42
John_K
ok, I used 0.025 ohm. Would explain why some of my values are off
05:43
Bertl
or R025 then :)
05:43
John_K
:)
05:43
Bertl
only the aperage is wrong though
05:43
Bertl
the voltage is not affected
05:43
Bertl
*amperage (i.e. current)
05:44
John_K
https://gist.github.com/John-K/d7e80129f449bee9e442
05:44
John_K
initial values
05:44
Bertl
that looks bad
05:45
Bertl
I wouldn't connect that to a microzed
05:45
Bertl
(which you probably already did)
05:45
John_K
right :\
05:45
Bertl
there is one critical voltage which is generated by VIO
05:45
Bertl
it is shown in the list as VCCO_* and PCIE_IO
05:46
John_K
that's why I was trying to get I2C up before connecting it
05:46
Bertl
this one powers the FPGA IO voltage which can be 1.8-3.3 volt
05:46
John_K
eep
05:46
John_K
crap, VIO came unconnected
05:46
Bertl
normally that is not a problem, as the regulator is either fixed or configured to 3.3V
05:46
John_K
that's very strange
05:47
Bertl
it's the middle block on the left
05:47
John_K
so that measurement was with VIO (middle power pin) disconnected
05:47
Bertl
labeled VIO
05:47
John_K
right
05:47
Bertl
the rest looks actually fine
05:47
Bertl
so I would consider this bad luck
05:48
Bertl
but the microzed might still be fine, the zynqs are quite sturdy
05:48
John_K
so just VCCIO_* and PCIE_IO are fed by VIO line?
05:48
Bertl
yep
05:48
John_K
ok
05:48
Bertl
the rail is called VCCIO
05:48
John_K
any clue why they'd read as 5v with no voltage applied?
05:48
Bertl
the regulator is labeled VIO
05:49
Bertl
no voltage applied?
05:49
John_K
correct, VIO was floating for those readings
05:49
Bertl
you have to explain what you mean by that
05:50
Bertl
i.e. I don't understand what you are trying to say
05:50
John_K
I desoldered the connector and am feeding each 5v rail from a separate wire at the moment, the wire for VIO was disconnected for that entire boot of the zynq
05:50
John_K
make sense?
05:50
Bertl
no
05:51
Bertl
you have two input rails
05:51
Bertl
one is called BETA_5V the other ZED_5V
05:51
John_K
GND, BETA_5V, VIO, ZED_5V, GND
05:51
Bertl
both are connected to 5V at the time of the reading
05:51
Bertl
VIO is not connected
05:51
Bertl
that is for remote sensing a battery in the future
05:52
John_K
ok, you just had me confused then ;)
05:52
John_K
VIO != VCCIO, got it
05:52
John_K
so Beta_5V feeds VIO regulator
05:52
Bertl
it is also labeled VIN not VIO
05:52
John_K
my bad, I typed that from memory
05:53
Bertl
yes, the BETA_5V powers all the power board
05:53
Bertl
the ZED_5V powers the Microzed
05:53
John_K
does VIO regulator auto-start? or does it need to be enabled by the scripts on the Zynq?
05:53
Bertl
it is enabled by the power_on.sh
05:53
Bertl
it doesn't auto start
05:53
John_K
ah :\
05:54
John_K
was hoping to test without the Zynq connected
05:54
Bertl
that is a little tricky as you figured
05:54
John_K
hehehe yes
05:54
Bertl
that's why I consider it a good idea to have that FTDI conencted to the I2C bus
05:54
John_K
hopefully will be easier in the future either with FTDI or test pads
05:54
John_K
absolutely
05:55
John_K
btw, what was your idea to get that hooked up the right way?
05:55
Bertl
ah, I tested with the FTDI here and looked at the behaviour
05:55
Bertl
and I found that it doesn't mess much with the IOs but it seens to hang in an undefined state with back power
05:56
Bertl
my first idea was to put a discharge diode between VCCD and VREGIN
05:56
John_K
so just make the FTDI self-powered instead of bus-powered?
05:56
Bertl
that would have been an option as well, yes
05:57
Bertl
but we want to save power, so I'd rather have it off than on
05:57
John_K
makes sense, this will be eventually battery powered after all
05:57
Bertl
well, I also saw that the dischage idea wouldn't work, as both VCCD and VREGIN got backpowered
05:58
Bertl
but I also noticed that this only happens once the FTDI was plugged in, i.e. activated
05:58
Bertl
(and then unplugged)
05:58
John_K
interesting, so from a cold boot it's fine, but after a boot it gets backpowered after you remove the USB cable
05:59
Bertl
which made me wonder if a reset would help
05:59
Bertl
precisely
05:59
Bertl
so, I added (for testing) a simple p-channel mosfet with source at VREGIN and gate at VCCD to pull up the reset
06:00
Bertl
i.e. when it is back powered, VCCD and VREGIN will be the same, and the reset gets pulled low by a resistor
06:00
Bertl
on the contrary, when it is bus powered, VREGIN will be at 5V but VCCD at 3.3
06:01
Bertl
which will pull up the reset line :)
06:01
John_K
very nice :)
06:01
John_K
sounds like a good solution
06:01
Bertl
seems to work on the breadboard here, but I still have to test it on the power board
06:01
John_K
btw, we could also switch to FT2232H which give us ADBUS/ACBUS and BDBUS/BCBUS so we could have both a JTAG and I2C configuration active
06:02
Bertl
yeah, I had that planned in the beginning, but the TQFP is larger and the QFN is more problematic to solder
06:02
John_K
agreed
06:03
Bertl
and it is not very likely that you will use the I2C very often
06:03
John_K
it's also 60% more expensive
06:03
John_K
true
06:03
John_K
probably only during test
06:07
Bertl
yeah
06:26
jucar
joined the channel
06:28
Bertl
off for now ... bbl
06:29
Bertl
changed nick to: Bertl_oO
06:30
John_K
mcp1727
07:18
jucar
left the channel
07:29
John_K
it would seem my assembly house put random resistors for R37,R38 as I left them DNP on the BOM
07:30
John_K
populating 510k/100k for 2.5v now
07:42
John_K
actually, they did not populate any resistors. That would explain the output
07:44
John_K
bbl
07:54
jucar
joined the channel
07:57
davidak
left the channel
08:17
John_K
@Bertl_oO: added in the missing R-divider with 510k/100k and it looks good to me now. Thoughts? https://gist.github.com/anonymous/64b1a8bc589f40de6694
08:27
jucar
left the channel
08:35
niemand
joined the channel
08:47
Bertl_oO
looks a lot better
08:48
Bertl_oO
do you have something to test the MicroZed for dammage?
08:57
John_K
for example?
09:02
Bertl_oO
something which interfaces the IO banks
09:03
John_K
not offhand, no
09:03
Bertl_oO
e.g. one of those demo breakout boards or similar
09:04
John_K
I'm seeing descrepancies between my DMM and the pac1720 script btw
09:04
John_K
my DMM reports 1.981v and the script 1.9531v
09:05
John_K
for NN LDO
09:05
Bertl_oO
that is within the measurement range
09:05
John_K
within accuracy of the IC you mean?
09:05
Bertl_oO
yes, the PACs are not very precise on the voltage
09:05
John_K
aha ok
09:06
Bertl_oO
if you look closely, the last hex digit doesn't change at all
09:06
Bertl_oO
and actually the next two bits are zero as well
09:07
John_K
ah, I had not
09:07
Bertl_oO
so for example f80 and fc0 are only one "step" apart
09:08
Bertl_oO
which means that after 2.4219V the next step is 2.4609
09:08
Bertl_oO
but they do a decent job on the current side
09:11
Bertl_oO
maybe the readout can be improved, the sensor can do a lot more than we currently use
09:17
Bertl_oO
I guess lowering the sample rate to 1 per second should improve resolution
09:17
John_K
interesting, I'll read up on the chip
09:17
Bertl_oO
http://ww1.microchip.com/downloads/en/DeviceDoc/20005386A.pdf
09:18
John_K
btw, do you happen to know what the output voltages for SW,SS,SE,EE WW,NW,NN,NE should be?
09:18
John_K
I'm tracing through the PCBs but figured it would be faster to ask
09:18
Bertl_oO
they are documented in the SFE schematic
09:18
John_K
ok let me load that
09:20
John_K
got them, thanks
09:20
Bertl_oO
np
09:27
intracube
hi, is transferwise still the preferred payment for people outside the Eurozone?
09:27
intracube
wonders how it compares to credit card + stripe.com
09:27
Bertl_oO
no idea, please check with se6astian|away
09:27
intracube
Bertl_oO: ok, will do :)
09:28
John_K
it seems S_VW for VTREF supply isn't documented, datasheet says 1.0v-3.6v, is any value in there valid for our application?
09:28
John_K
datasheet for MIC47050YML that is
09:29
Bertl_oO
VREF is currently unused, i.e. not populated
09:29
Bertl_oO
the VTREF output voltage needs to be around 0.8V IIRC
09:30
Bertl_oO
(please check with the CMV12k AN)
09:30
John_K
ah yes, I did not populate it
09:30
Bertl_oO
so the input voltage doesn't matter that much
09:30
John_K
row noise sheet saw 560-570mV
09:31
John_K
s/saw/says/
09:31
Bertl_oO
so even lower then
09:31
John_K
but yeah, no matter in the current case
09:31
John_K
do you know offhand which LDOs aren't needed at all currently?
09:31
John_K
I'm just hunting
09:32
Bertl_oO
https://wiki.apertus.org/index.php/AXIOM_Beta
09:33
John_K
aha
09:33
John_K
forgot about the photo
09:34
Bertl_oO
check the PCBs for populated chips
09:35
John_K
that works :)
09:35
Bertl_oO
but be careful, IIRC, I forgot two there
09:35
John_K
hah, which two?
09:35
John_K
MCN and MCS?
09:36
Bertl_oO
nah, those are for the center solder on area
09:36
Bertl_oO
it was one or two of the small power fixed regulators
09:37
Bertl_oO
probably on the back side of the board
09:37
Bertl_oO
(we should have a picture of that as well somewhere :)
09:37
Bertl_oO
but from the sensor related voltages the image is correct
09:37
Bertl_oO
so WW, SW, SE and EE are not required
09:38
Bertl_oO
also note that this was version 0.18, some things have been fixed in your version
09:39
John_K
right, that was my worry about just copying what was in those photos
09:41
John_K
https://kelley.ca/temp/Power_Board_v0.22_bot.jpg
09:41
John_K
https://kelley.ca/temp/Power_Board_v0.22_top.jpg
09:41
John_K
for reference
09:41
John_K
will upload better shots of all the boards later
09:42
John_K
looks like I need to fix 3 of the variable resistors tomorrow, then I should be able to install the sensor and try to capture some photons
09:43
Bertl_oO
yeah, if I had seen that before, I could have warned you about VIO :/
09:43
John_K
yeah :\
09:43
John_K
well you get to see my bad re-work with 0603s for it now :)
09:44
Bertl_oO
stacked resistors :)
09:44
John_K
I don't shy away from hacks :)
09:44
Bertl_oO
you didn't populate the temperature sensor (U29)?
09:45
Bertl_oO
no problem there, just curious
09:46
John_K
yeah, I can't remember offhand why I did not
09:47
Bertl_oO
you also need to add the bottom entry female headers for power (to proceed to the next level :)
09:47
se6astian|away
changed nick to: se6astian
09:47
Bertl_oO
\o/ se6astian!
09:47
John_K
yes, I have them on the board from the top-side photo
09:47
John_K
but the bottom side board I took from a board that hasn't had them installed yet
09:47
John_K
hey se6astian
09:48
se6astian
good morning
09:48
se6astian
hey John_K, got your email
09:48
se6astian
will reply now soon
09:49
John_K
great! thanks
09:50
John_K
just sent you my email address via PM to make sure it's correct
10:02
intracube
hi se6astian
10:02
intracube
is transferwise still the preferred payment for people outside the Eurozone?
10:02
intracube
was wondering how it compares to credit card + stripe.com
11:08
se6astian
yes
11:09
se6astian
stripe charges around 3-5%
11:09
se6astian
depending on if there is a currency exchange involved as well
11:10
se6astian
transferwise fees are areound 1%
11:10
se6astian
exchange rate fees already included
11:16
se6astian
but from reports tranferwise is also a bit more cumbersome
11:16
se6astian
you need to first transfer money from the bank account to transferwise, then send the transferwise transfer...
11:17
se6astian
but its definitely the cheapest option outside europe
11:19
intracube
se6astian: ah ok, thanks :)
11:19
intracube
will probably go through transferwise then
11:46
se6astian
great
12:01
darthrak_
joined the channel
12:36
se6astian
gotta go
12:36
se6astian
changed nick to: se6astian|away
13:12
darthrak_
left the channel
13:24
darthrak_
joined the channel
13:57
darthrak_
left the channel
14:21
se6astian|away
changed nick to: se6astian
14:42
jucar
joined the channel
15:08
jucar
left the channel
15:19
darthrak_
joined the channel
15:29
darthrak_
left the channel
15:34
alexML
intracube: found an interesting paper: https://hal.archives-ouvertes.fr/file/index/docid/733853/filename/best_hdr_algo_hal.pdf
15:34
alexML
maybe there is a chance to recover these response curves without reinventing the wheel :P
15:38
darthrak_
joined the channel
15:43
darthrak_
left the channel
16:25
intracube
alexML: most of that is way over my head :)
16:25
intracube
aren't those algorithms specifically for combining multiple images though?
16:33
davidak
joined the channel
16:33
alexML
for both PLR and the highlight recovery trick, we have to recover the sensor transfer curve
16:34
alexML
(for the trick, I only recovered the curve from one overexposed image to a normally exposed one, not the sensor curve)
16:34
alexML
and I'm looking for a way to do that (one that would actually give a decent result)
16:35
alexML
so far, I tried mkhdr (Debevec) and pfshdrcalibrate (Robertson
16:36
alexML
both failed miserably :(
16:37
alexML
the curve looks roughly like that: http://files.apertus.org/AXIOM-Beta/snapshots/nonlinearitytests-21.01.2016/
16:37
alexML
but the results were not consistent (one experiment gave one curve, another experiment gave a different one)
16:41
intracube
alexML: lots of variables that could change and end up invalidating the data, I guess
16:42
intracube
was wondering today what PLR mode artefacts would manifest as
16:42
alexML
of course
16:42
intracube
someone mentioned motion blur issues in the highlights
16:43
alexML
we could ask se6astian to create a short video panning the camera from left to right in PLR mode, I think
16:43
intracube
I can see how the other HDR mode (double-exposure) could do that, but can't see how PLR would
16:44
intracube
alexML: yep, I'm looking forward to the PLR testing
16:45
intracube
the cmv12000 datasheet isn't that clear about some aspects
16:45
alexML
alright, added that to the todo list
16:45
alexML
https://wiki.apertus.org/index.php/AXIOM_Beta_TestsTODO
16:49
Bertl_oO
it might make sense to create tasks for specific tests
16:50
intracube
discussion about the CMV12000 HDR modes and Red's HDRx: http://www.dvxuser.com/V6/showthread.php?299568-Question-about-RED-s-HDRx-why-don-t-people-use-it
16:50
intracube
^ very thin on real info though
16:54
alexML
yeah, we'll see how well it works in practice
16:56
alexML
a while ago I've proposed a HDR mode that would not have any motion artifacts - by exploiting the 300fps capability of the sensor
16:57
alexML
that is, record at 300fps, preprocess the frames in fpga (if that's fast enough, no idea), and output let's say 25fps
16:58
alexML
if you don't care about shutter angle, you could get 12 frames averaged into one => log2(sqrt(12)) = 1.8 extra stops of DR
16:58
alexML
if you care, you'll get less :P
16:59
alexML
(actually, if the fpga is fast enough, I would do a temporal aliasing filter - lookup "tessive filter")
17:05
intracube
^ yep, I've seen the tessive filtering before and was surprised it isn't used more commonly
17:11
alexML
I think once we sit down and tinker with high fps capabilities a bit, we can come up with modes that bring extra DR, low motion artifacts, and low temporal aliasing as well
17:12
intracube
interesting method for eliminating rolling shutter: https://vimeo.com/5976527
17:13
alexML
yep
17:13
intracube
I thought about something like this a while back - leave the sensor set to 360°
17:13
intracube
then use a separate shutter device
17:14
alexML
(Canon uses the same trick with mechanical shutter in photo mode :P )
17:14
intracube
which would block light during the part of the read/reset that causes the jello effect
17:15
alexML
(on 5D3, at 1/4000, the exposure is actually 0.13 seconds on the bottom row)
17:15
alexML
( http://www.magiclantern.fm/forum/index.php?topic=12523.msg121962#msg121962 )
17:15
intracube
alexML: doesn't the mechanical shutter itself have a shear effect?
17:15
alexML
it has, but much less than the electronic one
17:16
intracube
remembered it being an issue years ago with film SLRs
17:16
intracube
ah, ok
18:13
jucar
joined the channel
18:42
slikdigit_
joined the channel
19:48
arpu
joined the channel
19:48
slikdigit_
left the channel
20:43
se6astian
off to bed
20:43
se6astian
good night
20:43
se6astian
changed nick to: se6astian|away
21:01
aombk
anybody uses any cloud backup storage?
21:30
niemand
left the channel
21:33
jucar
left the channel
21:36
davidak
aombk: what do you need exactly?
21:37
davidak
i use Syncthing to sync my devices P2P and have one VPS to have one node that is always an
21:37
aombk
i need about 500gb of cloud storage for backup.
21:38
davidak
i'm using this for 2-3 years now. before that BTSync what is similar but no free software, ownCloud what doesn't work so well and dropboxâ¦
21:40
davidak
should it be secure?
21:42
aombk
what were you thinking?
21:44
davidak
i would suggest you to use client-side encryption, so the provider newer sees the data.
21:45
davidak
https://spideroak.com/features/zero-knowledge they provide it directly
21:45
davidak
or you can use software to encrypt it (on the fly) and use any provider
21:47
aombk
have you any experience with amazon cloud storage?
21:47
davidak
no
21:47
davidak
but many companys are using it, so it can't be that bad
21:48
davidak
but maybe you don't need that performance for just store data
21:48
davidak
https://www.backblaze.com/cloud-backup.html they have very cheap storage
21:51
davidak
they build their own storage hardware with cheap consumer hdds and it is kind of open hardware https://www.backblaze.com/blog/cloud-storage-hardware/
21:54
aombk
didnt get a result about them in the cloud storage searches i did. the look interesting
21:54
davidak
https://www.backblaze.com/blog/hard-drive-reliability-q3-2015/ there reports are very helpful for buying hdds
21:56
aombk
indeed, great database!
21:58
aombk
i have to do this quickly because i have a seagate network storage
21:59
davidak
it could take some time if you have a slow uplink
22:00
aombk
i know
22:03
davidak
and your storage is going to fail?
22:04
aombk
i dont have any signs but i can never be sure and i always have a slight anxiety