Current Server Time: 03:29 (Central Europe)

#apertus IRC Channel Logs

2020/06/08

Timezone: UTC


00:58
renzhi_
joined the channel
01:00
Spirit532_3
left the channel
01:00
Spirit532_1
left the channel
01:00
renzhi__
left the channel
01:01
Spirit532_1
joined the channel
03:12
Bertl_oO
off to bed now ... have a good one everyone!
03:12
Bertl_oO
changed nick to: Bertl_zZ
03:15
shi
joined the channel
03:17
renzhi_
left the channel
03:26
comradekingu
left the channel
03:33
comradekingu
joined the channel
03:41
renzhi_
joined the channel
03:42
shi
left the channel
04:15
renzhi__
joined the channel
04:17
renzhi_
left the channel
05:16
shi
joined the channel
05:18
renzhi__
left the channel
05:26
BAndiT1983|away
changed nick to: BAndiT1983
05:41
Spirit532_1
left the channel
05:47
shi
left the channel
05:48
shi
joined the channel
08:39
panintended
Hi all, it's been a while
08:40
BAndiT1983
hi panintended, how are you?
08:40
panintended
BAndiT1983: All good, how have you guys been?
08:41
renzhi_
joined the channel
08:42
mumptai
joined the channel
08:42
panintended
For https://lab.apertus.org/T1203 I see that we'd like to add attributes dynamically e.g. "ExposureTime", "WhiteBalance", "LCDBrightness".
08:43
shi
left the channel
08:43
panintended
I want to see what your policy is regarding e.g. STL containers since this is to be run on a low-resource device
08:43
panintended
So that I proceed accordingly
08:44
BAndiT1983
STL could be bloated a lot for pic32, the firmware should be kept slim
08:45
BAndiT1983
in fact the settings are not that dynamic, as we usually know which one are required
08:46
panintended
I see, I thought so.
08:48
panintended
ok, thanks. I'll return to it and get back with other things that might be a unclear
08:48
BAndiT1983
great, just drop a message when you need something
08:49
panintended
will do
09:44
BAndiT1983
panintended: maybe the settings can be reduced to few data types, e.g. integer, float, text
09:45
panintended
yes, I created an Attriubute class with an enum "Type" member for this
09:45
BAndiT1983
very good
09:45
panintended
and used a C union as the storage. I'd like you to review this sometime today
09:46
BAndiT1983
okay, sounds good, just ping me, although i have to read about unions again, used them very seldom
09:46
panintended
I'll let you know once it's in my fork
09:46
BAndiT1983
please do
09:47
panintended
sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/vTIBBYiTiROmFCBcXCfjobhK >
09:47
panintended
this will have a fixed size of 32 bytes, regardless of what you use it for
09:47
BAndiT1983
you can also use uint8_t as it will be unsigned char
09:47
BAndiT1983
already thought that ;)
09:48
BAndiT1983
but isn't uint32_t just 4 bytes?
09:48
panintended
so yeah, this is just for space efficiency's sake
09:49
BAndiT1983
we also need floating point numbers, e.g. when time is involved
09:49
BAndiT1983
32 chars should be enough for data exchange, in my opinion
09:49
panintended
yes, it's 4 bytes. but the compiler needs to know how much memory to allocate for this "struct". So it will allocate the largest of the member's size
09:50
BAndiT1983
i know, just wanted to verify
09:50
panintended
yeah, sure I'll add a float too
09:50
panintended
anyway, I'll let you know once I have something ready
09:51
BAndiT1983
very good and already looking nice
09:51
panintended
ah, nothing special really :)
09:52
panintended
I'll try my best, but I'm sure an embedded systems guy will scold me for parts of my code
09:52
BAndiT1983
that would be Bertl ;) am also not that deep there usually
09:53
panintended
:)
10:10
panintended
another question regarding the firmware code: are C++11 features allowed? For example range-based for loops
10:10
BAndiT1983
yep, c++11 is activated
10:10
panintended
or the use of auto
10:11
panintended
ok, I will use auto and for-ranged for loops for now. Let me know if you want to change this
10:12
BAndiT1983
just avoided STL and too advanced stuff, on one side to allow people with less experience extend it and on the other side to avoid larger firmware size when not required
10:12
BAndiT1983
you can check how the size of firmware changes in the build folder, the .map file
10:12
panintended
ah, which reminds me ':D
10:13
panintended
how do I build? Do you guys have a readme with toolchani details, etc?
10:13
BAndiT1983
yes, in the readme ;)
10:13
BAndiT1983
you need to download and install xc32 from microchip
10:14
panintended
yes, you do. I found it xD
10:18
panintended
ok :)
10:27
renzhi__
joined the channel
10:29
renzhi_
left the channel
10:42
LordVan
left the channel
10:58
renzhi_
joined the channel
11:01
renzhi__
left the channel
11:05
bluez_[m]
Hey Bertl! Can you confirm that these are the commands we need to program the PICs in beta main board: https://drive.google.com/file/d/1mWhFZ5BNiwE43WLxiJsuubEAHqbUzx4-/view?usp=sharing
11:08
bluez_[m]
And are these what I should mention in the wiki for https://lab.apertus.org/T1207 ?
11:12
renzhi__
joined the channel
11:15
renzhi_
left the channel
11:24
Bertl_zZ
changed nick to: Bertl
11:25
Bertl
morning folks!
11:25
BAndiT1983
hi
11:28
renzhi_
joined the channel
11:28
Bertl
bluez_[m]: looks good. I always do an rf_sel A/B first although that should not be required
11:30
renzhi__
left the channel
11:33
bluez_[m]
alright! i'll add it to the wiki then..
11:35
renzhi__
joined the channel
11:37
renzhi_
left the channel
11:46
shi
joined the channel
11:48
renzhi__
left the channel
12:48
bluez_[m]
Bertl: Okay I added it to the wiki.. please have a look..
12:48
bluez_[m]
https://wiki.apertus.org/index.php/Beta_Main_Board
12:49
renzhi_
joined the channel
12:50
Bertl
looks good, did you test it as well?
12:51
shi
left the channel
12:57
bluez_[m]
nah i didn't ':D
12:57
bluez_[m]
lemme test then
12:58
renzhi__
joined the channel
13:00
renzhi_
left the channel
13:02
bluez_[m]
why does it say no module named 'intelhex'?
13:03
Bertl
because it is probably not installed :)
13:03
bluez_[m]
should i install that using pip?
13:03
Bertl
yeah
13:03
BAndiT1983
interesting, what are you using python for?
13:04
BAndiT1983
maybe we can change the remote programmer task to it, if it already understand intel HEX
13:04
BAndiT1983
*understands
13:06
bluez_[m]
Bert: okay turns out rf_sel is required ':D
13:06
bluez_[m]
otherwise it doesn't find the pic
13:07
Bertl
BAndiT1983: bluez_[m] was asked by se6ast1an to document how the PICs currently get reprogrammed on the Beta
13:08
BAndiT1983
ah ok
13:08
bluez_[m]
BAndiT1983: yeah
13:08
BAndiT1983
just looked up this module, will definitely talk to metal_dent[m] about switching to python for UART LVP, this would simplify the task
13:09
bluez_[m]
Bertl: so guess i should add rf_sel as well to the wiki...
13:09
Bertl
at least for now
13:09
bluez_[m]
but shouldn't it do it by itself?
13:10
Bertl
BAndiT1983: this is what I've done for the initial programming of the remote PICs
13:10
bluez_[m]
<Bertl "at least for now"> yea for now..
13:11
BAndiT1983
Bertl: not with pickit?
13:11
BAndiT1983
but why do i ask, as i should know already that you can flash a pic with just a wood plank and some nails
13:13
BAndiT1983
the LVP part is rather nice to get the idea of things working and we are on the good way to get it done soon, many thanks for the python idea, haven't thought of it, although i use it almost daily for the PCB stuff at the moment
13:13
Bertl
for the pickit I would require some connector for the PIC16s which isn't there :)
13:13
BAndiT1983
dumb question from my side, forgot that we have a chain there
13:14
BAndiT1983
would JTAG work for such stuff without LVP on the main MCUI? asking just out of curiosity
13:14
BAndiT1983
*MCU
13:15
Bertl
I think you can program the PIC32 MCU via JTAG, but I've never tried
13:16
BAndiT1983
i mean the chain, know from xilinx fpga boards about boundary chain and that i can access chips with just one JTAG connector
13:16
BAndiT1983
could one probably flash pic16 or is jtag missing there?
13:16
Bertl
PIC16 do not support JTAG
13:16
intracube
left the channel
13:16
BAndiT1983
ok, thanks, then my question is volatile by definition
13:17
intracube
joined the channel
13:23
bluez_[m]
Bertl: made the changes..
13:28
Bertl
thanks
13:58
shi
joined the channel
13:59
renzhi__
left the channel
13:59
shi
left the channel
14:00
shi
joined the channel
14:02
BAndiT1983
changed nick to: BAndiT1983|away
14:05
renzhi_
joined the channel
14:07
shi
left the channel
14:28
renzhi__
joined the channel
14:29
BAndiT1983|away
changed nick to: BAndiT1983
14:31
renzhi_
left the channel
14:51
renzhi_
joined the channel
14:53
renzhi__
left the channel
14:58
megora
joined the channel
15:18
renzhi__
joined the channel
15:19
renzhi__
left the channel
15:20
renzhi__
joined the channel
15:20
renzhi_
left the channel
15:21
se6ast1an
good day
15:22
renzhi__
left the channel
15:22
renzhi__
joined the channel
15:24
Dest123
joined the channel
15:27
BAndiT1983
hi
15:34
renzhi_
joined the channel
15:35
renzhi_
left the channel
15:36
renzhi__
left the channel
15:48
se6ast1an
bluez_[m]: great to see progress with the PIC programming
15:48
se6ast1an
did you have to install any additional modules?
15:48
se6ast1an
if yes we need to add them to the base firmware
15:49
se6ast1an
also what do you mean with "upload a special FPGA firmware" exactly?
15:57
bluez_[m]
> did you have to install any additional modules?
15:57
bluez_[m]
I had to install a python package thats all... intelhex
15:58
Bertl
this should be part of the updated firmware
15:58
BAndiT1983
this would be also helpful for the remote flasher, as i tend to use python because of this module, this would spare a lot of trouble and development
15:58
bluez_[m]
> also what do you mean with "upload a special FPGA firmware" exactly?
15:58
bluez_[m]
I mean the gatware... there is an icsp.bin image that we upload into the fpga if m not wrong..?
15:59
Bertl
correct
16:00
se6ast1an
is the correct verb "upload" here? or "flash" ?
16:01
BAndiT1983
vintage term is burn
16:01
se6ast1an
just checked IntelHex is already there indeed: https://github.com/apertus-open-source-cinema/axiom-firmware/blob/master/makefiles/in_chroot/requirements_pip.txt#L8
16:02
se6ast1an
owah, time flies
16:02
se6ast1an
MEETING TIME!
16:02
bluez_[m]
> is the correct verb "upload" here? or "flash" ?
16:02
bluez_[m]
M not sure there ':D
16:03
bluez_[m]
Will check..
16:03
se6ast1an
everyone please pm me for ordering the reports as usual
16:04
se6ast1an
bluez_[m]: you are our #1 :)
16:04
bluez_[m]
Thanks!
16:04
bluez_[m]
Hello everyone
16:04
bluez_[m]
So this week i made more progress with the driver
16:05
bluez_[m]
I added a sysfs interface where we can easily add more entries
16:05
bluez_[m]
Currently the only entry now is idcode...which correctly reads out the idcode from the mxo2
16:06
bluez_[m]
I was having issues with read/write...bertl helped nd i realised the bits were all reversed... so finally it worked
16:07
bluez_[m]
I also made many changes to adhere to the linux kernel coding style that i was missing
16:08
bluez_[m]
Further i will be working on the upload interface finally...
16:09
bluez_[m]
https://github.com/Swaraj1998/axiom-beta-rfdev
16:09
bluez_[m]
Here is the code
16:10
bluez_[m]
Nd ofc today i added the pic programming brief guide :)
16:10
bluez_[m]
Thats it from me!
16:10
se6ast1an
that is https://wiki.apertus.org/index.php/Beta_Main_Board#Programming
16:10
se6ast1an
many thanks bluez_[m]!
16:10
se6ast1an
apoorva_arora you are next
16:10
apoorva_arora
Thank you, Good afternoon everyone..
16:11
bluez_[m]
Np!
16:11
se6ast1an
bluez_[m]: you tested the flashing already right? please close lab task when confirmed working
16:12
bluez_[m]
> bluez_: you tested the flashing already right? please close lab task when confirmed working
16:12
bluez_[m]
Yes i did! Will close it then..
16:13
apoorva_arora
So, I continued my work on SERDES PHY. I first tried to build upin the PHY made by GSOC student from 2018 but realized that it was not compatible with the protocol that needs to be built on top of it. So, I made a completely new SERDES. with proper handshaking signals allowing data and control flow for burst as well as as singular data transfers
16:15
apoorva_arora
Currently I finished The SERDES master which will be implemented on ZYNQ side. Master is able to read and write to the LVDS as well as generate clock for the slave (the concept is based on SPI protocol).
16:15
apoorva_arora
I am currently building the test bench for the master and this week I will implement slave side as well.
16:15
apoorva_arora
here is the code: https://github.com/Apoorva-ar/GSOC_2020
16:16
apoorva_arora
thats all from my side
16:16
Bertl
what data rates can you achieve?
16:17
apoorva_arora
I can not predict at the moment because I dont know how to predict data rates without complete timing closure (after pacemetn and route)
16:17
apoorva_arora
Maybe you could help me with that
16:18
Bertl
okay
16:19
se6ast1an
many thanks apoorva_arora
16:19
se6ast1an
preetimenghwani is next
16:19
preetimenghwani[
hello everyone
16:21
preetimenghwani[
So this week i spent most of the time working on test framework, the code is ready (i.e modifications done ), need to make changes in script to test it.
16:21
preetimenghwani[
thats it from my side
16:21
Bertl
link to the code?
16:23
preetimenghwani[
ah! haven't made repo yet, sorry for that, will send you in sometime
16:23
preetimenghwani[
*will put here after the meeting
16:23
preetimenghwani[
if thats okay
16:23
Bertl
please do so! tx!
16:24
se6ast1an
many thanks!
16:24
se6ast1an
panintended, please go ahead
16:25
panintended
sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/vlgnbdjfaxSCzCdYIHeaaLTD >
16:25
Bertl
please avoid long messages in the meetings
16:27
Bertl
http://irc.apertus.org/index.php?day=08&month=06&year=2020
16:27
panintended
Ah, sorry about that. I had it ready in a text file and pasted it. Should I paste it line-by-line next time?
16:27
se6ast1an
yes please
16:27
se6ast1an
regarding 3, you discovered the microchip wonder #1 :)
16:27
panintended
ash, i see
16:27
BAndiT1983
panintended: if you disable some options in xc32 setup then you're good to go usually, anything besides pic32 can be turned off
16:28
BAndiT1983
yep, 2 things i dislike about the xc32 is the size plus the proprietary stuff
16:28
panintended
Let me paste my status once again
16:28
panintended
Hi all.
16:28
panintended
Good to be back after a hiatus (personal obligations and let me know if you want to adopt a kitten...)
16:29
panintended
1. Today I put a bit of time and had another look at T1203. This is essentially a refactoring of the new FW with a design pattern that would make adding new attributes (e.g. like we now have white balance) more maintainable, easily extensible
16:29
panintended
2. I set up some boilerplate code for how attirbutes are stored in the "database" object. I hoped to submit them for review today, but it this will have wait till tomorrow I'm afraid.
16:29
panintended
3. Also I tried to install XC32 in my dev environment and I ran out if space! I need to get this sorted so that I know that code I push compiles. Is >6GB of disk space really needed for this?
16:29
panintended
That's all for now, should have more news soon.
16:29
se6ast1an
many thanks!
16:29
Bertl
the pic32 and pic32mx libs are about 2GB each
16:30
Bertl
so if you do not use them, you can remove them
16:30
panintended
BAndiT1983: I did try running the installer with --help, but didn't see any useful options
16:30
BAndiT1983
we only need pic32mz, just as info
16:30
se6ast1an
Bandit your turn!
16:30
BAndiT1983
ah, you try it from terminal, please look at the docker container i've created, but let me explain it later
16:30
BAndiT1983
alright, hello everyone
16:30
panintended
the issue is that my VM runs out of space ':D. Anyhow, I'll figure this out
16:31
BAndiT1983
you can extend the virtual "HDD"
16:31
panintended
thanks, please go ahead :)
16:31
BAndiT1983
this week i had mostly 3 tasks: panelisation script for PCBs, soldering the adapter board for e-mount research for schmoggie and guiding metal_dent[m]
16:32
BAndiT1983
the panelisation script is coming along, it still has some quirks, also the python modules are not without problems here and there, but i can show some raw results
16:32
BAndiT1983
this is the board outline: https://pasteboard.co/JbnLJb5.png
16:33
BAndiT1983
you can see alrady the array of power boards there, later we will populate the panel with multiple sub-panels which consist either a set of boards for 1 camera or same board in case we have to reorder, e.g. because of design errors
16:33
Bertl
it is very dark though :)
16:33
BAndiT1983
the resolution is very high and the lines are getting very slim
16:33
BAndiT1983
this is the preview from pcbway, as i had to investigate which layers are correct and which need more adjustments -> https://pasteboard.co/JboEGFo.png
16:34
Bertl
the bridges can be a lot smaller btw
16:34
BAndiT1983
still not final, but bridge generation is already automatic, will also add insets, so the subpanels can be cut off where mouse bites are
16:35
BAndiT1983
like i've discussed with se6ast1an, it was just according to OSHPark requirements of 100mil/2.54mm, so i'Ve just added the option in the script for it, it's adjustable anytime
16:35
se6ast1an
I think what Bertl means is the length of the bridge not the width
16:35
se6ast1an
but yes as you just said its a simple value change
16:35
Bertl
I mean the bridge width, not the slot width
16:36
Bertl
we do not want to mill away that much :)
16:36
BAndiT1983
ah, this is also adjustable by setting the number of bridges horizontally and vertically
16:36
BAndiT1983
bridge width is also settable ;)
16:36
BAndiT1983
trying to keep everything adjustable there
16:37
BAndiT1983
regarding the adapter board: finally soldered the adapter board, nothing fancy, just a veroboard with 6 voltage dividers to bring the voltage from 3.3 to 3.15V down
16:37
BAndiT1983
will try to deliver it on thursday, as it'S holiday in germany
16:37
Bertl
what resistances did you use?
16:37
BAndiT1983
and finally GSoC, was looking with metal_dent[m] at low-voltage programming of PIC16 on the axiom remote, she can tell more about it
16:38
BAndiT1983
220 and 5K1
16:38
BAndiT1983
online calculator plus verified with multimeter ;)
16:38
BAndiT1983
maybe not the top-notch solution you're used to, but have to get slowly into the field again
16:39
BAndiT1983
that would be it for now
16:39
se6ast1an
many thanks!
16:40
se6ast1an
metal_dent[m]: your turn!
16:40
metal_dent[m]
hi, everyone!
16:40
metal_dent[m]
last week i mostly read about more ways for flashing the firmware
16:41
metal_dent[m]
studied the existing bootloader code, the asm files, the lst files and the also the procdef file as it tells about the memory segments
16:43
metal_dent[m]
for parsing the hex file me and BAndiT1983 decided to create two arrays one for prog mem and other for conf mem but i guess BAndiT1983 is telling now to switch to python scripts (sorry i havent read the logs yet as i was off for sometime)
16:44
metal_dent[m]
so we'll discuss more about this after this meeting
16:44
Bertl
what did you learn from the bootloader code you studied?
16:44
metal_dent[m]
that's it from me! (also se6ast1an i do remember about the other side tasks and will get around to them soon)
16:45
se6ast1an
yes, I was about to ask about https://github.com/apertus-open-source-cinema/AXIOM-Remote/pull/17
16:46
metal_dent[m]
> what did you learn from the bootloader code you studied?
16:46
metal_dent[m]
the one in the repo doesn't work properly so i studied minicom output, where the initial output block gives the IDs, configuration words etc
16:46
BAndiT1983
we still need some adjustments there, but LVP can be done in the next days, so it would be good to do the PR afterwards
16:46
BAndiT1983
the one in the repo works correctly, but CI build is somehow not working
16:46
metal_dent[m]
yeah so minicom is not possible on that
16:50
se6ast1an
anything else metal_dent[m]?
16:50
metal_dent[m]
no, that's all
16:50
se6ast1an
many thanks!
16:51
se6ast1an
quick updates from me:
16:51
se6ast1an
1. the last hand built beta dev kit shipped last week, now all the focus is on getting the hardware ready for industrial production (PCB panelization, last new Powerboard tests/reviews, preparing pick and place files, etc.)
16:52
se6ast1an
2. We installed nextcloud talk as audio, video, screen/file sharing platform and first tests showed that some minor UI issues pose an entrance barrier but once these are overcome the platform works well. Anyone who is interested in this please contact me to get an account (guests can participate but not host meetings).
16:53
se6ast1an
3. In a collaborative effort of me and several GSoC students the documentation of the remote beta setup which bertl talked about in previous meetings has been documented with a list ofvreference commands. The guide itself is not made public but provided to those who need it to avoid requiring to remove all hostnames/ports/etc. for security purposes.
16:54
se6ast1an
Bertl: received more PCIe SSDs to benchmark with the ultra96 from me but thats maybe a topic he will cover
16:54
se6ast1an
thats it from my side
16:54
se6ast1an
vup are you ready for your turn?
16:54
vup
yeah
16:55
vup
As mentioned some meetings ago, we ordered a test pcb from jlc, to see if they would manufacture it.
16:55
vup
It arrived and I took some images:
16:55
vup
https://files.niemo.de/DSC01196.JPG
16:55
vup
https://files.niemo.de/DSC01197.JPG
16:55
vup
https://files.niemo.de/DSC01206.JPG
16:55
vup
They look fine afaict, so this confirms that we should be able to use jlc.
16:55
vup
However one thing I noticed looking at these PCBs is, that we probably want to use tended via's (which should be no problem).
16:55
vup
Furthermore I continued with the board layout of the micro r3. I did a first pass at placing all the connectors according to our current mechanical concept (the one sebastian alreay mentioned last week: https://cloud.apertus.org/index.php/apps/gallery/s/PGHsr9PjkaxLoJC).
16:55
vup
A 3d export of the current board can be found here: https://files.niemo.de/r3.step.xz (attention, its 180Mb of step unpacked, so make sure you have enough free RAM when opening it :)
16:55
vup
I also redid the fanout of the ecp5, paying more attention to high speed signals and while its not perfect, doing it on 4 layers seems doable without too many compromises.
16:55
vup
Finally we also added a second button to the r3, which can be used to select the bitstream the ECP5 loads, so that when using only the ECP5 it is always possible to load a "golden" bitstream, which then can be used to load a user bitstream, even if the user bitstream is broken.
16:55
vup
Further work on the layout is now mainly waiting on a thorough review of the schematic and all our footprints.
16:55
vup
I also did some small improvements to the fw 2.0, like enabeling sysrq again, making bootdelay work again in u-boot, installing the bringup scripts to /usr/axiom/bringup-script, allowing passwordless login as root via ssh and some more small changes.
16:55
vup
Bertl: there is now a script called axiom-bringup-environment.sh that should launch a shell with the bringup scripts in $PATH aswell (still with axiom- prefix and underscores replaced by dashes)
16:55
vup
But we can talk with anuejn about the replacement of underscores by dashes, don't think he will be too opposed to undoing that.
16:55
vup
Finally anuejn refactored the nmigen gateware a bunch and there is now a handy cli, that lets you build any gateware for any of our supported platforms (micro, beta and zybo currently).
16:56
vup
It looks like this: https://github.com/apertus-open-source-cinema/nmigen-gateware/blob/7700b8b5678cd521d5f80dbf5260dd0d369953c7/src/hdmi_test.py
16:56
vup
So we no longer have top-level files for each platform :)
16:56
Bertl
vup: excellent!
16:58
se6ast1an
great vup
16:59
se6ast1an
anything else?
16:59
vup
nope, thats it from me
16:59
se6ast1an
forgot to add another topic to my list:
16:59
se6ast1an
4. AXIOM Team Talk 15.4 has passed first review phase and is now being refined in editing by Max, release is not too far off anymore
16:59
se6ast1an
Bertl your turn!
16:59
vup
(s/tended/tented/)
17:04
Bertl
sec phone
17:04
se6ast1an
sure
17:06
Bertl
okay, sorry, just got a call
17:06
Bertl
back now ...
17:06
Bertl
I did some ultra-96 testing which again is both promising and disappointing
17:07
Bertl
as se6ast1an mentioned, I got new SSDs and enclosures for teting
17:07
Bertl
and the basic results are this: we can get up to 400 (maybe even 420) MByte/s write rate via the USB 3 ports of the ultra-96
17:08
Bertl
but all the SSDs I tested so far (3 different ones) only provide the write performance for a short time
17:08
Bertl
after some time the throughput dramatically decreases
17:08
BAndiT1983
heat problem?
17:09
Bertl
so for example, testing with an INTEL_SS_DPEKNW020T8
17:09
Bertl
give an average throuhgput of 406MB/s for 100GB of data
17:10
Bertl
but an average of 140MB/s for 1TB of data
17:11
Bertl
for the Force_MP_510 SSD about 402MB/s can be reached for 20GB
17:11
Bertl
but writing the full SSD gives an average of 280MB/s
17:12
Bertl
it doesn't look to me like it would be a problem of the USB interface though
17:12
Bertl
so more investigation and/or tests are probably required
17:12
se6ast1an
very interesting
17:13
se6ast1an
is the "start phase" repeatedly faster?
17:13
Bertl
yes
17:13
Bertl
I can probably setup some test software to plot the throughput
17:14
Bertl
besides testing with the ultra-96 we did some planning on the camlink4k/hdmi side for future testing
17:14
se6ast1an
it would be interesting to see if there is a pause duration required between fast writes or if its linked to writing specific areas of the ssd
17:14
Bertl
I'll setup some in-detail tests
17:15
se6ast1an
did you also observe this slow down when running the bench marks from a PC and the ssds attached over USB?
17:15
Bertl
I haven't tested this yet
17:15
se6ast1an
ok
17:16
Bertl
so that's it from my side
17:17
Bertl
(besides the usual business and GSoC mentoring)
17:17
se6ast1an
many thanks!
17:18
se6ast1an
that concludes our meeting today!
17:18
se6ast1an
many thanks to all participants!
17:19
Dest123
Hello everyone
17:20
Dest123
I'm sorry I missed the past couple of meetings
17:20
Dest123
I only started working this past Saturday, so there is no much progress
17:21
Dest123
I'm currently working on sensor's registers and its SPI interface
17:21
Dest123
that's it for me :)
17:21
Bertl
thanks!
17:45
preetimenghwani[
https://github.com/preetimenghwani/axiom-firmware
17:46
Bertl
thanks!
17:46
preetimenghwani[
its in pixel_remapdev
17:47
preetimenghwani[
branch
17:48
Bertl
where does the /* OBUFDS_inst end?
17:50
preetimenghwani[
just a minute there is a mistake i guess i will push latest one in a minute
17:50
Dest123
left the channel
18:03
preetimenghwani[
done!
18:43
RexOrCine1
left the channel
18:58
Bertl
off for now ... bbl
18:58
Bertl
changed nick to: Bertl_oO
20:23
Bertl_oO
off to bed now ... have a good one everyone!
20:23
Bertl_oO
changed nick to: Bertl_zZ
20:37
se6ast1an
off to bed, good night
21:43
BAndiT1983
changed nick to: BAndiT1983|away
22:08
megora
left the channel
22:30
madonius
left the channel
22:32
madonius
joined the channel
22:48
Maqs
left the channel
22:48
Maqs
joined the channel
23:05
felix__
vup: for the non-test pcb i'd strongly recommend ENIG finish; makes bga soldering much easier/better. if you still want to be able to probe signals, just tenting the vias between the bga pads on the top layer might be an option to consider
23:06
vup
yep ENIG is planned
23:06
vup
good idea re tenting just the top layer
23:07
felix__
it's also not running at frequencies where the nickel might cause problems
23:10
vup
yeah 5GHz should be fine
23:32
renzhi_
joined the channel
23:37
renzhi_
left the channel
23:37
renzhi_
joined the channel
23:56
Spirit532
left the channel
23:56
Spirit532
joined the channel