<GitHub117>
[smoltcp] dlrobertson opened pull request #141: [WIP] Use the time types instead of a u64 (master...add_timestamp) https://github.com/m-labs/smoltcp/pull/141
<GitHub12>
[smoltcp] dlrobertson commented on pull request #139 2dbdeb4: It is ambiguous what `length` is. Is length the length of the buffer, the length field, or the result of `Packet::data_len`? I think it should be the length field, but I could be swayed otherwise. https://github.com/m-labs/smoltcp/pull/139#discussion_r165238242
<GitHub88>
[smoltcp] dlrobertson commented on pull request #139 2dbdeb4: The data contained in the `Hop-by-Hop` extension header is `Ipv6Option`s. It isn't like an IPv6 packet where the data could be anything. I think either there should be no `data` member, only `length` and `next_header` which would be `emit`ed to a buffer then the IPv6 Options get `emit`ed to the `Hop-by-Hop` `Packet` `data_mut` buffer. https://github
<GitHub91>
[smoltcp] hjr3 commented on pull request #139 2dbdeb4: Ah, I changed this based on feedback from the last PR. It should be using `hdr_ext_len()` function for the number of bytes. Concerning that my tests passed. I will fix this and make the variable in `field::OPTIONS()` more explicit. https://github.com/m-labs/smoltcp/pull/139#discussion_r165245496
<sb0>
whitequark, ping
<whitequark>
sb0: pong
<sb0>
did you get my emails?
<whitequark>
yes
<whitequark>
those issues will take weeks if not months, I think.
<whitequark>
the device-assisted scheduling is especially bad
<sb0>
can you send me individual estimates for each issue?
<sb0>
and it's not something we have to develop right now, it's more long-term planning
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
rohitksingh-demo has joined #m-labs
<sb0>
_florent_, if the data is corrupted, could there be some issue with the gtp equalizer parameters? are those dependent on line rate?
<sb0>
and clock synchronizer failure shuo
<sb0>
ld be straightfoward to reproduce outside of artiq ...
<sb0>
note that the kasli has the si5324 reset line disconnected from the fpga, so you can load a first design that sets up the si5324, and then your gtp test designs
rohitksingh-demo has quit [Ping timeout: 276 seconds]
<GitHub159>
[artiq] sbourdeauducq commented on issue #914: If we put packages on pypi, we have to ensure that they are maintained and properly versioned there as well, otherwise there will be incorrect versions installed silently, and corresponding support issues. And pypi/setuptools don't have good ways of dealing with version dependencies, unlike e.g. cargo. So I think it is better to only support conda for packaging, which i
<sb0>
_florent_, how do you program the si5324 for your tests?
<_florent_>
sb0: i'm not using the si5324 in my design
<rjo>
sb0: we should expand the "Users and contributors" list on the webpage by PTB, Uni Hannover, HU Berlin, BMBF, SYSU.
<rjo>
sb0: and that page should mention the Kasli and EEM components.
rohitksingh-demo has joined #m-labs
rohitksingh-demo has quit [Client Quit]
<sb0>
_florent_, so how are you getting a 150MHz clock?
<sb0>
rjo, yes, I have a website redesign that I haven't pushed yet...
<sb0>
(nor completed)
<rjo>
sb0: ack. are you planning to go away from raw html?
<rjo>
IMHO it was a great idea to route the I2C bus to one FTDI port.really good for development.
<sb0>
_florent_, I used that to dispatch bugs in the ethernet core gtp garbage (with the board in Berlin, I didn't have the Kasli back then), and that was pretty smooth. having the board locally would not have helped much.
<sb0>
_florent_, oh and yes, you can use rjo's script to reconfigure the si5324 over USB
kuldeep_ has joined #m-labs
<rjo>
sb0: could you patch the capacitors on the XADC VREFP so that we can compare temperatures with an without heat sink?
<rjo>
sb0: on kasli
kuldeep has quit [Ping timeout: 276 seconds]
<sb0>
rjo, will do
<rjo>
sb0: they are 0201 but that's actually one of the easiest reworks i have done in a long time.
<rjo>
sb0: thanks
<sb0>
I have no problem with soldering 0201 but I don't have any in stock atm
<sb0>
rjo, oh, it's just shorting C49, correct?
<sb0>
rjo, re. website, probably a horrible NIH python-based hack. I haven't been convinced by the few frameworks I looked at
<sb0>
found them too inflexible and it would take me more time to get them to do what I want than hack together a site generator script from scratch...
<sb0>
jekyll is good if you're running a blog, but it's annoying for anything else
ohsix has joined #m-labs
<rjo>
sb0: yes. C49.
<rjo>
sb0: pandoc might be for you then. it doesn't force you into the blog corner.
X-Scale has quit [Read error: Connection reset by peer]
<rjo>
whitequark: i checked that lit and checkoutput are the same as before. something else changed.
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
rohitksingh-demo has joined #m-labs
Rex0r has joined #m-labs
X-Scale has joined #m-labs
<sb0>
_florent_, can you work on jesd sc1 until your kasli arrives?
<_florent_>
sb0: yes i started looking at the documentation, you had some plans about reading dac informations at startup for delay characterization, can you remember me what as it?
<rjo>
sb0: are you sending one to him or is this from technosystem/greg?
<GitHub88>
[smoltcp] hjr3 commented on pull request #139 92c168a: i changed `OPTIONS` to use the value of `field::LENGTH`. i refactored the code a bit and was able to remove some complexity too. https://github.com/m-labs/smoltcp/pull/139#discussion_r165370179
<GitHub107>
[artiq] hartytp commented on issue #854: Just throwing it out there, but is there a chance that SB's board is quite badly damaged? Could explain why he's seeing things like the 1V8 issue that aren't showing up on other boards. https://github.com/m-labs/artiq/issues/854#issuecomment-362397171
dlrobertson has quit [Read error: Connection reset by peer]