Current Server Time: 22:33 (Central Europe)

#apertus IRC Channel Logs

2016/01/24

Timezone: UTC


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