Current Server Time: 00:52 (Central Europe)

#apertus IRC Channel Logs

2017/03/13

Timezone: UTC


02:34
dimaursu16
left the channel
02:49
jucar
joined the channel
03:39
RexOrCine
left the channel
03:55
jucar
left the channel
04:17
Bertl
off to bed now ... have a good one everyone!
04:17
Bertl
changed nick to: Bertl_zZ
06:25
IldarValiev
joined the channel
06:35
IldarValiev
left the channel
06:47
ItsMeLenny
joined the channel
07:01
se6astian|away
changed nick to: se6astian
07:02
IldarValiev
joined the channel
07:10
IldarValiev
left the channel
07:13
anuditverma
joined the channel
07:17
anuditverma
left the channel
08:36
Spirit532
left the channel
08:39
Elbehery
joined the channel
08:46
dimaursu16
joined the channel
08:50
IldarValiev
joined the channel
09:04
IldarValiev
left the channel
09:52
IldarValiev
joined the channel
09:54
ildar123
joined the channel
09:54
IldarValiev
left the channel
09:55
ildar123
left the channel
10:10
Elbehery_
joined the channel
10:12
Elbehery
left the channel
10:30
arpu
left the channel
10:44
arpu
joined the channel
11:02
LordVan
joined the channel
11:10
ItsMeLenny
left the channel
11:31
Bertl_zZ
changed nick to: Bertl
11:32
Bertl
morning folks!
11:45
Elbehery_
hello !
11:45
Bertl
hey, how's going?
11:46
Elbehery_
all good :)
11:52
usmankhan
joined the channel
11:52
usmankhan
left the channel
11:53
usmankhan
joined the channel
11:55
usmankhan
good morning!
11:55
Bertl
morning usmankhan!
11:57
usmankhan
Bertl, where can I get the exact specifications of sensors and battery supply? I am looking to design a PID controller accordingly
12:00
Bertl
sensor is non trivial, as we support several sensors with different power requirements, here is a list of potential sensors with links:
12:00
Bertl
https://wiki.apertus.org/index.php/Image_Sensor_Table
12:01
Bertl
on the input side, we currently max out at 2x 5V/3A, where one rail directly supplies the MicroZed and the other is used for everything else
12:02
Bertl
I think it is somewhat safe to assume that the maximum amperage for any DC/DC is about 2A (probably 1.5A is more than enough) and will typically be around 500mA or less
12:02
usmankhan
Ok
12:03
Bertl
the voltage range per regulated rail can be assumed between 1.0 (typically 1.5 is fine) and 4.0 (typically 3.6 max)
12:04
Bertl
from the eight regulated rails, typically two supply the interface board (currently unused) and six supply the sensor
12:04
Bertl
from those six rails, two can carry slightly more power than the others (because they have more connections)
12:06
Bertl
the routing fabrics and other electronics usually consume a maximum of 100mA from the 5V supply rail, so the totla for all the regulated rails can be assumed to be around 2.5A @ 5V (to keep a safety margin to the 3A max)
12:06
Bertl
*total
12:08
usmankhan
alright
12:17
Bertl
maybe add that information to the lab task when you find the time
12:19
usmankhan
Sure
12:31
Bertl
thanks, appreciated!
12:52
intracube_afk
changed nick to: intracube
13:01
usmankhan
left the channel
13:04
usmankhan
joined the channel
13:04
niculescu_vlad
joined the channel
13:04
Bertl
welcome niculescu_vlad!
13:13
niculescu_vlad
Hi!
13:14
niculescu_vlad
Mr. Bertl, as I told you in the PM, I am interested to work on the fan controller and switching converter
13:14
Bertl
niculescu_vlad meet usmankhan, usmankhan meet niculescu_vlad!
13:15
niculescu_vlad
What I want to ask first: is the fan controller a project for summer of code, or just a test task to be accepted in the SOC?
13:15
Bertl
really depends on the complexity
13:16
Bertl
there are a number of related tasks and the fan controller can become quite complex
13:16
Bertl
first, T731 is required to actually reach the PWM I2C inside the routing fabric (FPGA)
13:17
niculescu_vlad
you mean the I2C block described in FPGA
13:18
Bertl
correct
13:18
Bertl
then the various temperature sensors are located on different busses which kind of requires interaction with the control daemon T723
13:19
Bertl
(actually T757, but T723 is the connection)
13:20
Bertl
so it can become rather complex to integrate all the parts to have a closed loop system which actually regulates the fan according to all the gathered data
13:21
niculescu_vlad
but is the gathered data related only with temperature?
13:22
niculescu_vlad
In other words, just the temperature sensors will provide the input data in the controller?
13:22
Bertl
all sensors could potentially contribute to the regulator
13:22
Bertl
for example the power measurements and the current sensor state can be used to predict behaviour
13:23
niculescu_vlad
so, there are not only temperature sensors. That was my question
13:23
niculescu_vlad
Is there a list with all the sensors?
13:24
Bertl
correct @ not only temp sensors
13:24
Bertl
btw, I suggest you use a real IRC client instead of the web interface, as the web interface becomes annoying very fast ... there are a number of available clients for all platforms
13:24
niculescu_vlad
ok
13:24
Bertl
regarding sensors, that also depends on some tasks
13:25
Bertl
currently we have several different temperature sensors in different places
13:25
niculescu_vlad
what is the purpose of this controller?
13:25
Bertl
the PWM fan controller?
13:25
niculescu_vlad
for what does it regulate the temperature?
13:25
Bertl
ah, good question!
13:25
niculescu_vlad
for a camera circuit?
13:25
Bertl
for the entire camera, but the fan is placed on the MicroZed
13:26
Bertl
let me find a picture to illustrate
13:26
niculescu_vlad
ok
13:27
Bertl
https://www.apertus.org/sites/default/files/ibc.jpg
13:27
Bertl
here you basically see the current status, where the fan is simply mounted on the heatsink of the microzed
13:28
Bertl
in the version with enclosure, the fan is planned on the top of the enclosure, basically above the PCB stack
13:28
Bertl
https://www.apertus.org/sites/default/files/AXIOM-Beta-Simple-Enclosure-Explosion01.jpg
13:28
niculescu_vlad
Great. So, it is a protection circuit. For this application, I guess over charge and over voltage circuits will be included.
13:29
Bertl
the main source of heat is the ZYNQ on the MicroZed and currently the power board, which will hopefully get less heat intensive with the switching regulator :)
13:30
Bertl
but the cooling requirements are diverse, e.g. the Zynq is happy at 90°C while the Image Sensor should stay near room temperature
13:31
niculescu_vlad
oh! So that is why you need a high yield switching regulator! To reduce the heat.
13:31
Bertl
there are also state dependent requirements, for example if you are shooting (capturing video) you want to keep the fan as quiet as possible while still preventing the system from overheating
13:32
Bertl
OTOH, if you are not recording, the fan can speed up to prepare the system for the next shoot
13:32
Bertl
yes, the heat is one reason for the switching regulator ... we are currently burning half the power on LDOs :)
13:32
niculescu_vlad
I dealt with power management applications with microcontrollers, but the algorithm is the same
13:33
niculescu_vlad
Yes. I guess you also want to keep the cooler at a constant speed. A future signal processing will easier cancel the noise if it is constant
13:34
niculescu_vlad
The adapive filters can do a quite good job with this
13:34
Bertl
so as you can see, the fan controller really ranges from 'easy' to 'hard' here
13:35
niculescu_vlad
Yes. Indeed, some research will be required at first
13:35
Bertl
Elbehery_ meet niculescu_vlad, niculescu_vlad meet Elbehery_!
13:36
Bertl
usmankhan is also working on the switcher and Elbehery_ is working on the FAN control ... so please coordinate and cooperate there ...
13:37
niculescu_vlad
Ok.
13:38
Bertl
do not hesitate to ask if something is unclear, I will try to answer as best as I can. When I'm away or asleep, I will read up when I come back and reply ASAP
13:38
niculescu_vlad
ok. Thank you very much. I will get in touch with them
13:39
Bertl
also, think outside the box, i.e. if you have a great idea how to improve this or that, do not hesitate, we even have a task for that (T727 :)
13:40
niculescu_vlad
ok. That's great
13:44
AndroUser
joined the channel
13:45
niculescu_vlad
left the channel
13:45
AndroUser
changed nick to: niculescu_vlad
13:45
Elbehery_
hey niculescu_vlad, i am also working on the fan controller, at the moment i am trying to build very simple prototypes for both the slave and the pwm interface
13:47
niculescu_vlad
Ok. But are we supposed to start coding before the start of gsoc?
13:48
Elbehery_
no but i am trying to have a very simple model that can be enhanced, re-designed in order to understand more about the design parameters
13:48
Bertl
it is always good to have something before the actual GSoC start, especially for the selection
13:48
usmankhan
I am working on the switching regulator project, and figuring out the small signal model of buck converter so that we can determine PID controller parameters. Feel free to let me know if you have any questions and I will do my best to answer what I have learned so far :)
13:49
dimaursu16
left the channel
13:51
niculescu_vlad
Sure. This is good. I can design the pid controller for the fan
13:51
Bertl
also note that as this is a FOSS/OH project, besides the GSoC participation, fame and honor awaits you :)
13:51
niculescu_vlad
And also try to implement a variant of pwm generator
13:52
niculescu_vlad
Elbehery, what pwm resolution do you want to achieve?
13:52
Elbehery_
so far the i2c slave was implemented with an 8-bit pwm interface, but bertl mentioned that these might not be enough
13:54
Elbehery_
an initial design is posted here "https://github.com/ELBe7ery/i2c_draft_gsoc"
13:54
niculescu_vlad
But i guess the fun is not controlled via i2c. Just raw pwm
13:54
niculescu_vlad
Like any dc motor
13:54
Elbehery_
well, the reading are sent to the pwm via the i2c bus [as far as i understood from bertl]
13:55
niculescu_vlad
The i2c is required just to read the temperature sensors. Isn t it?
13:55
Bertl
correct, the relevant schematic is here: http://vserver.13thfloor.at/Stuff/AXIOM/BETA/axiom_beta_main_board_v0.36_r1.2.schematic.pdf
13:55
Bertl
the I2C is mainly to interface the PWM controller to the rest of the system
13:56
Bertl
it has to be located in the east routing fabric (MachXO2)
13:56
niculescu_vlad
I will try a draft for the pwm generator for the cooler. It needs good resolution to allow the command in small steps
13:56
Bertl
which has only a very special connection to the Zynq
13:56
Elbehery_
[temp. sensors]-> [software] -> I2C valid PWM values -> [PWM interface] -> fan
13:56
niculescu_vlad
Yes.
13:57
Bertl
(see T731 for details on that)
13:57
niculescu_vlad
[temp. sensors]-> I2C -> software->valid PWM values -> [PWM interface] -> fan
13:57
niculescu_vlad
I would say that
13:58
Bertl
not all temp sensors are on I2C though :)
13:58
niculescu_vlad
Ok. Are there analog sensors?
13:58
Bertl
the sensors will hopefully be soon handled by the control daemon
13:59
Bertl
no analog sensors at the moment
13:59
Bertl
the Zynq provides an on-die temp sensor which is converted by the Zynq internal ADC and can be read from userspace
14:00
Bertl
the image sensor has a temp sensor as well, but that one requires calibration
14:00
Bertl
(details can be found in the sensor datasheet)
14:01
usmankhan
left the channel
14:02
Bertl
note that small changes to the PWM circuitry are also an option for the next main board version, but we still need to handle the current interface as well (first page of the schematic I linked)
14:05
LordVan
left the channel
14:05
niculescu_vlad
Ok. I have classes now but i will do a deep investigation after
14:07
Bertl
great! have fun!
14:15
Elbehery_
how much should be the fan PWM frequency be? i am trying to identify the motor attached in the image above but can't identify it.
14:16
RL
left the channel
14:16
RexO
joined the channel
14:19
niculescu_vlad
Usually it is about khz
14:20
Elbehery_
20~25k?
14:22
Bertl
the fan we are currently using is a Fonsoning FSY31S05M
14:23
Bertl
5V 120mA DC Brushless Fan
14:26
Bertl
we will probably use a slightly larger fan for the enclosure (40mm or maybe even 50mm)
14:28
Bertl
off for now ... bbl
14:28
Bertl
changed nick to: Bertl_oO
14:30
jucar
joined the channel
14:31
ArrunM
joined the channel
14:33
ArrunM
Hello bertl, question about designing bidirectional protocol
14:37
ArrunM
i am considering about a header with port and protocol used ,no of packets etc and a second header which is protocol specific and that only used by the application receiving or sending the data again with spi ,i2c.... then data
14:39
ArrunM
every data stripped from their protocol is saved and then a packet is created
14:41
ArrunM
do my initial start only includes the part of creating packet from that data and sending it across and back modified?
14:41
ArrunM
should i need to design protocol specific header now!!
14:43
ArrunM
i will send a packet design and project flow as soon as possible !!
14:44
Bertl_oO
hello ArrunM!
14:45
Bertl_oO
keep in mind, the connection is a serial transfer over a single LVDS pair, so the protocol should be simple and efficient
14:46
Bertl_oO
also note that we probably want CRC or ECC to ensure that the transmitted information is correct
14:48
ArrunM
constructing a packet diagram, little information about no. of ports and how much size should be allocated to data part of the packet
14:49
ArrunM
ecc or crc will be taken care of
14:51
ArrunM
as i dont know what to do when error occurs , left it as is and note or make it transfer that packet again?
14:53
Bertl_oO
in both cases (CRC and ECC) an error counter should be incremented, in the ECC case, if correction is possible, account it differently
14:54
Bertl_oO
packets with uncorrectable errors can be dropped/ignored
14:55
Bertl_oO
in case of the real-time wire updates the retransmission should be automatic (i.e. the next slot will update the values anyway)
14:55
Bertl_oO
in case of bidirectional protocols like I2C, SPI, etc a retransmission is desireable
14:56
Bertl_oO
but at least the error case needs to be handled gracefully
14:56
Bertl_oO
please add information and details to the lab task where appropriate
15:03
ArrunM
ok!!
15:04
usmankhan
joined the channel
15:06
jucar
left the channel
15:14
Spirit532
joined the channel
15:24
IldarValiev
joined the channel
15:26
BAndiT1983
joined the channel
15:26
BAndiT1983
hey Bertl_oO
15:27
ArrunM
left the channel
15:28
ArrunM
joined the channel
15:30
BAndiT1983
left the channel
15:31
IldarValiev
left the channel
15:45
dimaursu16
joined the channel
15:45
dimaursu16
left the channel
15:45
dimaursu16
joined the channel
15:50
RexOrCine
joined the channel
15:51
MichaelH
joined the channel
16:02
niculescu_vlad
Which are the communication protocols of the sensors?
16:02
niculescu_vlad
Excluding the i2c
16:08
se6astian
32 lvds channels plus clock IIRC
16:08
se6astian
for raw image data
16:09
se6astian
not sure if you mean this by "communication" as well
16:09
niculescu_vlad
I mean just the sensors
16:09
niculescu_vlad
That dri e
16:09
niculescu_vlad
That drive the fan coltroller algorithn
16:10
niculescu_vlad
Sorry for spelling. I am mobile
16:14
se6astian
ah sorry
16:14
se6astian
then Bertl_oO will be able to help you
16:14
Elbehery_
as far as i know, the only way to set the pwm fan signal would be via the control algorithm which is written in C/python that will send the proper speed via the i2c bus
16:15
illwieckz
left the channel
16:18
niculescu_vlad
I don't think the fan speed is sent via I2C. The cooler is a simlle dc motor. You can adjust its speed by modifying the parameters of the pwm
16:20
niculescu_vlad
I was asking just about the communication between sensors and processing unit
16:20
niculescu_vlad
Other protocols like spi or uart
16:20
niculescu_vlad
I want to start implementing the verilog modules. That is why I was asking
16:22
sagnikbasu
joined the channel
16:27
illwieckz
joined the channel
16:27
illwieckz
left the channel
16:27
illwieckz
joined the channel
16:27
ArrunM
left the channel
16:27
Elbehery_
i think bertl mentioned this earlier i quote "<Bertl_oO> the sensors exist throughout the AXIOM Beta, on different busses and readable via different mechanisms" but i am not currently aware of more details
16:28
g33kyaditya_away
left the channel
16:31
ArrunM_
joined the channel
16:32
aombk3
joined the channel
16:36
g33kyaditya
joined the channel
16:36
aombk2
left the channel
16:37
simonrepp
joined the channel
16:46
se6astian
meeting starting in 14 minutes
16:55
Bertl_oO
changed nick to: Bertl
16:57
slikdigit
joined the channel
16:57
tyrone
joined the channel
16:58
davidak
joined the channel
16:58
davidak
good evening
17:00
se6astian
hello!
17:00
simonrepp
o/
17:00
rexbron
left the channel
17:01
se6astian
right so welcome to another IRC meeting
17:01
se6astian
minutes are now stored in our wiki
17:02
se6astian
if you scroll down on the frontpage
17:02
se6astian
in the yellow box
17:02
se6astian
https://wiki.apertus.org/index.php/IRC_Meeting_Notes
17:02
rexbron
joined the channel
17:02
se6astian
simonrepp: will also create the ones for today
17:02
se6astian
as always please send me a PM now if you have a topic to report about in the meeting
17:03
Alvis_
joined the channel
17:03
Alvis_
Hi
17:03
Bertl
Hey Alvis_!
17:03
Alvis_
I'm Alvis from University of Waterloo
17:04
Alvis_
I'm interested in working with apertus in GSoC this summer
17:04
Bertl
welcome to our channel! we are currently having a meeting, so please be a little patient
17:04
Alvis_
I have a background in C/C++ and GPU programming
17:04
Alvis_
Oh
17:04
Alvis_
No problem at all!
17:04
Alvis_
OpenCine: Raw Image Debayering Methods looks like an interesting task to me
17:04
Bertl
just hang around, it will be over in an hour or less
17:04
Alvis_
sure!
17:05
Alvis_
I'll leave some messages here first is that ok?
17:05
Bertl
after the meeting, yes
17:05
Bertl
the meeting happens here on this channel :)
17:05
Alvis_
Ohhh
17:05
simonrepp
Alvis_: do write them down in your text editor, you can paste them later :)
17:05
Alvis_
I'll wait after that then
17:05
Alvis_
Ya, thanks!
17:06
se6astian
ok Bertl please go ahead with your updates
17:06
Bertl
okay, a number of things happened on my side since last time
17:07
Bertl
first, after the planned 4K HDMI module contribution didn't happen as expected, I started looking into it
17:07
OscaR
joined the channel
17:07
Bertl
this resulted in a decision to go with the Artix FPGAs for this plugin (featuring 4 MGTs with up to 6.6GBit/s
17:07
Bertl
)
17:08
Bertl
we also decided to use the Trenz Artix modules for prototyping and thus I developed a carrier board for testing
17:08
Bertl
we will also be able to use those boards for other stuff, like testing SFP and fiber optic connections
17:09
se6astian
4k hdmi fpga stuff noted here as well: https://wiki.apertus.org/index.php/4K_HDMI_Plugin_Module
17:09
Bertl
unfortunately I spent most of the remaining time with updates on 'old stuff' and reworking AXIOM Beta PCBs
17:10
Bertl
we recently discovered, that our 3x mDP (mini display port) module is incorrectly wired
17:11
Bertl
i.e. I somehow assumed that the pinout on the mini DP connector would be the same as on the DP connector, and nobody figured that out :/
17:11
Bertl
so there is an updated version available now, which not only has the correct pinout but also is suited for mDP to HDMI adapters
17:12
Bertl
and then, as you probably experienced first hand, the GSoC 'students' are showing up, which I consider a very good sign
17:13
Bertl
that's basically all from my side, hope I haven't forgotten anything
17:13
se6astian
great thanks
17:13
se6astian
simonrepp: you are next in line
17:13
illwieckz
left the channel
17:14
illwieckz
joined the channel
17:14
simonrepp
real quick info mostly for the vienna apertus people: i'll be hosting a 2-3 days live art booth at the linuxwochen.at, and I requested the booth be placed next to AXIOM :)
17:14
se6astian
excellent :D
17:14
Bertl
\o/
17:14
simonrepp
= i'll be doing full days of live blender/inkscape/krita working, and maybe we can do some collab for apertus stuff if we have ideas :D
17:15
simonrepp
that's all from me ;)
17:15
se6astian
sounds great, thanks
17:15
davidak
very nice
17:15
se6astian
anyone else who wants to report anything please pm me now while I provide updates
17:16
se6astian
1. we currently have filmmaker/dop http://www.imdb.com/name/nm6877423/ here in vienna
17:16
se6astian
he arrived today and will get a beta lent for his next project to be shot in paris
17:17
davidak
do you know if it will be his main camera?
17:17
davidak
or just to play around
17:17
se6astian
his main and only camera :)
17:18
davidak
wow, great
17:18
se6astian
another film project in parts shot with the axiom beta has premiere tomorrow: http://www.imdb.com/title/tt5902750
17:18
se6astian
on our side I have been editing together small clips with beta sample footage for TT 12.3
17:18
se6astian
still a couple more to go and max will do the rest of the team talk editing
17:19
davidak
we should feature such things on the (new) website, if we are allowed
17:19
se6astian
definitely
17:19
se6astian
next topic: we are in the process of applying to https://prototypefund.de/
17:19
se6astian
to fund a few fpga development related tasks in collaboration with timvideos.us
17:20
se6astian
to pay a german fpga developer to work on tasks with overlap
17:20
se6astian
4k HDMI for example
17:20
se6astian
or SDI HDL, etc.
17:21
se6astian
and I have been working on visual concepts how a next interation of the Beta married with the Gamma could look like
17:21
se6astian
its for the far future
17:21
se6astian
nothing to share yet publically
17:21
se6astian
but its progressing well
17:21
davidak
can we already see it?
17:21
se6astian
privately yes :)
17:21
davidak
k
17:21
se6astian
thats it from my side, no progress with the new website yet unfortunately again
17:22
se6astian
no drupal theme developer progress so far
17:22
se6astian
our hackmd installation notes.apertus.org can be officially considered dead as several people now tried to get it to run and all failed
17:22
davidak
very sad
17:23
Bertl
we can try again after a server update (which is planned anyway)
17:23
Alvis_
left the channel
17:23
se6astian
right
17:23
davidak
would it be an option to install docker?
17:23
Bertl
nope
17:24
se6astian
new axiom print flyers design is also progressing: https://lab.apertus.org/M11/36/
17:24
Bertl
davidak: server is already virtualized and thus docker won't work
17:24
davidak
Bertl: docker is containerization ;)
17:24
se6astian
also still work in progress is the search for a logo series for beta/gamma/remote, etc.
17:24
se6astian
https://lab.apertus.org/T741
17:24
se6astian
and the related font for it: https://lab.apertus.org/T744
17:24
Bertl
davidak: I know :)
17:25
se6astian
thats it from my side for today
17:25
simonrepp
]
17:25
se6astian
and as I got no new pms
17:25
se6astian
that should also be it for the meeting agenda
17:25
se6astian
last point: next meeting
17:26
se6astian
27.03 19 :00 ?
17:26
se6astian
in two weeks
17:26
davidak
ok for me
17:26
Bertl
sounds good to me as well
17:27
simonrepp
fine with me!
17:28
se6astian
then its official
17:28
se6astian
I will send the invitations again
17:28
davidak
thanks
17:28
Bertl
thanks!
17:29
se6astian
thanks to you as well, and I have to leave for another appointment in the city center with said DOP who is now in vienna
17:29
Bertl
have fun!
17:31
simonrepp
here are the notes for everyone who wasn't paying attention :D https://wiki.apertus.org/index.php/IRC_Team_Meeting_2017-03-13
17:32
OscaR
:D Thanks!
17:32
Alvis
joined the channel
17:33
Bertl
wb Alvis! meeting is over, you can paste your questions now :)
17:34
Alvis
Hi, I'm Alvis from University of Waterloo
17:34
Alvis
I'm interested in working with apertus in GSoC this summer
17:34
Alvis
I have a background in C/C++ and GPU programming
17:34
Alvis
OpenCine: Raw Image Debayering Methods looks like an interesting task to me
17:34
Alvis
I would like to learn more about the technical specifics and anything about preparation/application I should be aware of
17:34
Alvis
Thank you!
17:34
OscaR
@Sebastian, just got a reply from Cmosis. I'm sending you a mail right now.
17:35
Bertl
Alvis: BAndiT1983|away is the person you want to talk to
17:35
simonrepp
left the channel
17:35
Alvis
oh ok thanks Bertl
17:35
Bertl
he should be around soon
17:36
Bertl
it is probably a good idea to check out the OpenCine repository to get a feeling for the existing codebase
17:38
Alvis
Great
17:38
se6astian
changed nick to: se6astian|away
17:38
OscaR
left the channel
17:42
aombk
joined the channel
17:43
aombk3
left the channel
17:44
ArrunM_
bertl i just pm you packet diag on https://lab.apertus.org/
17:45
ArrunM_
should I paste it here?
17:46
Bertl
here is fine, if the paste is longer, use a pastebin
17:47
Bertl
you can also add it to the lab and just paste the url or task ID here
17:49
Bertl
off for now ... bbl
17:49
Bertl
changed nick to: Bertl_oO
17:50
ArrunM_
https://ibb.co/d0PxDv
17:51
ArrunM_
Anything else that should be considered ? width of the packet is kept small to avoid choking realtime data
17:52
ArrunM_
Protocol data use data specific to application, ie reconstructing i2c or any protocol and the last byte store data to be transmitted!!
17:55
tyrone
left the channel
18:01
Alvis
left the channel
18:02
Bertl_oO
ArrunM_: note that with a serial connection, we do not necessarily have to limit ourselves to 8bit blocks
18:03
Bertl_oO
e.g. we could do 10 or 12bit chunks with 2-4 bits CRC/ECC per chunk
18:03
Bertl_oO
and assemble that to larger blocks
18:03
Bertl_oO
(just giving an example here)
18:06
ArrunM_
as these packets are quite compact and fixed width, transmission like i2c uses 8 bit blocks
18:07
ArrunM_
if say 10 then extras gets wasted
18:07
Bertl_oO
they would be used for CRC/ECC
18:08
tyrone
joined the channel
18:08
Bertl_oO
but as I said, that was just an example, the 8 bit words are fine as well
18:15
se6astian|away
changed nick to: se6astian
18:16
MichaelH
left the channel
18:22
sagnikbasu
Bertl_o0:Hi. So I was wondering for the bidirectional packet communication project, do we need to create a packet for handshaking (RTS/CTS) purpose ?
18:23
niemand
joined the channel
18:23
niemand
left the channel
18:23
niemand
joined the channel
18:26
sagnikbasu_
joined the channel
18:28
Bertl_oO
the LVDS connection can be assumed 'permanent' after initial synchronization (and maybe training for higher speeds)
18:29
Bertl_oO
i.e. there is no need for request to send or clear to send messages
18:29
sagnikbasu
left the channel
18:38
niemand
left the channel
18:38
niemand
joined the channel
18:38
usmankhan
left the channel
18:43
se6astian
changed nick to: se6astian|away
18:49
ArrunM_
left the channel
19:07
sagnikbasu_
left the channel
19:09
se6astian|away
changed nick to: se6astian
19:14
Alvis
joined the channel
19:16
se6astian
changed nick to: se6astian|away
19:17
davidak
left the channel
19:18
Vlad_
joined the channel
19:21
tyrone
left the channel
19:26
tyrone
joined the channel
19:32
Vlad_
left the channel
19:32
niculescu_vlad
left the channel
19:41
BAndiT1983
joined the channel
19:42
Vlad_
joined the channel
19:42
BAndiT1983
hi Alvis, you had a question about OpenCine?
19:46
niculescu_vlad
joined the channel
19:54
BAndiT1983
left the channel
20:16
Vlad__
joined the channel
20:19
Vlad_
left the channel
20:24
slikdigit
left the channel
20:25
Alvis
left the channel
20:26
Alvis
joined the channel
20:28
slikdigit
joined the channel
20:30
BAndiT1983|away
changed nick to: BAndiT1983
20:32
BAndiT1983
changed nick to: BAndiT1983|away
20:43
Alvis
BAndiT1983|away, yea
20:43
Alvis
I'm interested in OpenCine: Raw Image Debayering Methods
20:43
Alvis
Can I have more details about the task?
20:44
slikdigit
left the channel
20:45
BAndiT1983
joined the channel
20:45
BAndiT1983
just saw that you replied, but i was off
20:45
BAndiT1983
Alvis: what parts are you interested in?
20:46
Alvis
BAndiT1983, oh it was just a minute ago haha
20:46
Alvis
The task is about porting the code to OpenCL/GPU right?
20:47
niemand
left the channel
20:47
BAndiT1983
i'm checking the logs periodically, this week i will be just sporadically available, as i have to cure a bit
20:48
BAndiT1983
task include multiple things, it's about implementing algorithms on cpu first, accelerate them with threads and afterwards or in parallel port them to OCL and/or GPU shader
20:48
BAndiT1983
*includes
20:49
BAndiT1983
there was a discussion about further plan for OC and we want to target a frame server, so we can provide raw data to applications which don't understand it in first place
20:49
BAndiT1983
so debayering will be important there and especially fast processing
20:50
BAndiT1983
we have SHOODAK algorithm which was created by a camera guy, who is interested in the project, so we wanted to finally implement it as his team of devs is not available at the moment
20:50
BAndiT1983
have you checked OC already and tried to compile the code?
20:52
Alvis
uh not yet
20:52
Alvis
so this task is about both coding the algorithm and porting it to GPU?
20:52
BAndiT1983
it should be the first step if you are still interested
20:52
Alvis
yup
20:53
BAndiT1983
GPU is just an extension of the task, it's more important to implement the algorithm so it fits OC structure
20:53
Alvis
oic
20:53
se6astian|away
changed nick to: se6astian
20:53
Alvis
wait he already has the algorithm so it's not a phd thesis project right?
20:54
BAndiT1983
there are 3 levels: 1. implement algorithm, e.g. green edge directed debayer, 2. accelerate it on CPU through threads or OCL, 3. GPU implementation (possibly that it is already covered by OCL, but it has to be investigated also using shaders)
20:54
BAndiT1983
he invented an algorithm, which we want to reimplement on faster base
20:55
BAndiT1983
in fact there are 2 versions, but i have to ask him about details, haven't talked to him for a long time
20:56
BAndiT1983
it was mentioned here -> https://www.apertus.org/what-is-debayering-article-october-2015
21:03
se6astian
changed nick to: se6astian|away
21:04
se6astian|away
changed nick to: se6astian
21:05
slikdigit
joined the channel
21:05
RexO
left the channel
21:07
Elbehery_
Hello bertl, are you online ?
21:07
RexO
joined the channel
21:12
Bertl_oO
kind of, _oO means I'm otherwise occupied .... i.e. I'm working on something away from the keyboard or similar
21:12
Bertl_oO
but depending on the stuff I work on, I'm checking IRC more or less often
21:12
BAndiT1983
i thought you are constantly amazed by something ;)
21:13
BAndiT1983
or irritated
21:13
Elbehery_
Aha, okay i will post the top module that i have implemented so far
21:13
Elbehery_
on the lab comments section
21:13
Bertl_oO
BAndiT1983: yeah, but you have to try harder :) the best explanation for _oO I've heard so far was 'Operation Octopus'
21:13
Elbehery_
please let me know once you check it, i do have more questions
21:18
Vlad__
left the channel
21:18
BAndiT1983
Bertl_oO: seen discussions about the protocol, checked the task and it said HDL or verilog, how is it done usually in FPGA?
21:19
Bertl_oO
I hope it says HDL (VHDL or Verilog) :)
21:19
Bertl_oO
both VHDL and Verilog are HDLs (Hardware Description Languages)
21:19
BAndiT1983
i think it does say it, had just a glimpse today, had more to do with visiting my doctor
21:20
Bertl_oO
that is basically the way you 'program' for an FPGA
21:20
BAndiT1983
i know :D i wanted general thing about implementation, what is used to build packets, is it done in memory?
21:20
BAndiT1983
i'm not a really bloody beginner ;)
21:20
BAndiT1983
just had no time to power up my spartan6 board
21:21
BAndiT1983
currently i'm using google flatbuffers for the daemon and it is really slim and fast, so i was wondering how it could be done on FPGA
21:21
Bertl_oO
I see, well, you need some kind of 'memory' (explicit or implicit) to handle any state machine
21:22
BAndiT1983
so you build it in sdram and step over the bytes to send it?
21:22
Bertl_oO
usually no :)
21:23
Bertl_oO
while memory as 'ram' is available inside an FPGA, it is usually scarce and comes in blocks around 16kb
21:23
Bertl_oO
so typically it's more FIFOs (shift registers, etc) holding the short data
21:24
Bertl_oO
if you have to accumulate a larger (or unknown) number of packets, then FIFOs implemented with dual port memory are more common
21:26
BAndiT1983
does opencores provide something to start with or do you want it done from scratch?
21:27
Bertl_oO
really depends on the task, there is a lot of open IP out there, but usually it is geared to a specific task and adapting it often takes more time than writing it from scratch
21:27
BAndiT1983
and another thing which occured to me, what about the wishbone bus? have you considered it?
21:28
Bertl_oO
Elbehery_: looks good (the TOP overview and code)
21:28
se6astian
off to bed
21:28
se6astian
good night
21:29
se6astian
changed nick to: se6astian|away
21:29
BAndiT1983
night
21:29
Elbehery_
night :)
21:29
BAndiT1983
where is master.sendData() used?
21:29
Elbehery_
master is defined at the tb file
21:29
Elbehery_
sendData is a task inside this module
21:29
Elbehery_
sends the given data to the given address over the i2c bus
21:30
Bertl_oO
BAndiT1983: wishbone is a nice and FOSS/OH bus system, but it is more suited for soft cores communicating with peripherials
21:30
BAndiT1983
we have a hardcore ARM ;) so it seems not suiting the task
21:30
Bertl_oO
of course, it also works nicely if you have pipelines of IP cores
21:31
Bertl_oO
one problem is that the hardened ARM has an AMBA (AXI 3) interface bus system, which is not compatible with wishbone
21:31
Bertl_oO
there is an ongoing project to build a FOOS/OH bridge system
21:31
BAndiT1983
i've seen that AXI was mentioned in lab, but it seems that there are tons of different architectures also in FPGA world
21:32
BAndiT1983
how is the protocol triggered between the FPGAs?
21:34
Bertl_oO
the idea is to have a steady flow of packet exchange between both FPGAs (i.e. slots for data) which is established at startup
21:35
BAndiT1983
constantly? or has it some sort of interrupt to start new exchange?
21:35
Bertl_oO
when a remote device, e.g. an I2C slave attached to the MachXO2 is addressed on the Zynq I2C bus, then the query is relayed over the stream
21:35
Bertl_oO
replies get relayed back and will be returned accordingly
21:36
Bertl_oO
changes to the 'real-time' wires will be transported and thus updated on a regular basis
21:36
Bertl_oO
an interrupt would require some kind of 'interrupt line' which is not really available
21:36
BAndiT1983
we get info about shields at start usually, right? does it have hot-plug?
21:37
BAndiT1983
just thinking about enumerating sensors which are present in the system, e.g. load description, ask every sensor/actor if it exists, reply to user what succeeded or failed
21:37
Bertl_oO
shields are not hot-plug-able and do not contain any information, plug-ins on the other hand are hot-plugable and always contain an eeprom
21:37
BAndiT1983
i've dropped a couple of steps, but you get the idea
21:39
BAndiT1983
what if some shiled were exchanged, how do we get available actors on-board?
21:39
Bertl_oO
Elbehery_: so if you have questions, now is the time to ask, before I go to bed :)
21:39
BAndiT1983
you and go to bed? at that time?
21:42
RexO
By "go to bed" he means take his socks off and slump onto a keyboard.
21:43
BAndiT1983
:D
21:43
Elbehery_
aha, okay , first thing i want to make sure about, does the big picture of the system i have posted on my github is correct ! i mean am i getting the whole big picture correctly ?
21:43
BAndiT1983
Rex, don't make me laugh as coughing hurts a bit
21:44
RexO
Have you seen Altered States? Cos that's what happens when Herbert exhausts himself.
21:45
BAndiT1983
haven't seen it, but the pictures are telling me it's crazy
21:45
RexO
https://youtu.be/67lYG7a4YOA
21:45
niculescu_vlad
left the channel
21:46
BAndiT1983
just watched it, man, the drugs were free in that time, i suppose
21:46
RexO
It's a tale of sensory deprivation and regression. A must watch really.
21:48
Bertl_oO
Elbehery_: it is correct, but not in all detail
21:49
Bertl_oO
the Software part is running on the Zynq (hardened arm cores) which sees a 'virtual' I2C bus
21:49
tyrone
left the channel
21:49
Bertl_oO
(or to be precise, a number of busses)
21:50
Bertl_oO
this particular I2C bus is then transferred via the packet protocol to the MachXO2 (routing fabric east) where it attaches to the I2C PWM interface
21:51
Bertl_oO
but except for that, it is correct and complete
21:51
Elbehery_
Aha, do you think the design should allow more numbers of bytes for the pwm resolution ?
21:52
Bertl_oO
I really don't know, it might be more than sufficient, only time will tell
21:52
BAndiT1983
how big is the packet for PWM?
21:53
Bertl_oO
it might be enough to pulse the fan at a really low frequency as well, way below the typical 20-40kHz, but we have to test this
21:53
BAndiT1983
is it a stepper motor, because of pulse?
21:53
Bertl_oO
nope, just a brushless fan
21:53
Elbehery_
Aha, great
21:54
BAndiT1983
so it's a classical straightening of the pulse then?
21:54
BAndiT1983
forgot the engish word -> rectifying
21:54
BAndiT1983
*english
21:54
Bertl_oO
no rectification at the moment, but maybe we will do that :)
21:55
BAndiT1983
i thought it's important for normal pwm, at least i know it from atmel chips
21:56
Bertl_oO
the current circuit can be found in the schematic on page 1
21:56
Bertl_oO
as I mentioned before, nothing is set in stone, and we can easily adapt the circuitry to something different if we figure that it improves things
21:57
Bertl_oO
doesn't mean that we do not have to handle the existing circuitry as well
22:08
BAndiT1983
will be interesting to see if the motor makes unwanted noises at low frequency
22:09
Alvis
left the channel
22:14
BAndiT1983
left the channel
22:30
Elbehery_
good night :) see you all tomorrow
22:31
Elbehery_
left the channel
22:37
Bertl_oO
so, socks are basically off :)
22:38
dimaursu16
left the channel
22:46
Alvis
joined the channel
22:52
slikdigit
left the channel