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
|