01:17 <mtrbot-ml_> [mattermost] <sb10q> ha, Clone may be a solution as well and avoids the problems with passing tx/rx around that you mention

01:17 <mtrbot-ml_> [mattermost] <sb10q> but what about locking issues?

01:18 <mtrbot-ml_> [mattermost] <sb10q> can I receive (or wait for data) in one task, while transmitting in another?

03:30 <mtrbot-ml_> [mattermost] <sb10q> kasli 2.0 ethernet is working! it was simply the SFP/RJ45 not fully inserted

06:31 <mtrbot-ml_> [mattermost] <alexist> Hi! May I ask one more question...?

06:33 <mtrbot-ml_> [mattermost] <alexist> Hi! May I ask some question...?

07:21 <_whitenotifier-9> [smoltcp] Dirbaio synchronize pull request #336: WIP: Separate IP parts from EthernetInterface. - https://git.io/JffHD

07:26 <_whitenotifier-9> [smoltcp] Dirbaio commented on pull request #336: WIP: Separate IP parts from EthernetInterface. - https://git.io/Jftwo

07:28 <_whitenotifier-9> [smoltcp] Failure. The Travis CI build failed - https://travis-ci.org/github/smoltcp-rs/smoltcp/builds/679637679?utm_source=github_status&utm_medium=notification

07:42 <mtrbot-ml_> [mattermost] <sb10q> sure, go ahead

07:52 <mtrbot-ml_> [mattermost] <alexist> Looking at Sinara project at GitHub, I found some boards which are not in the homepage’s order list. I wonder whether it is possible to order these boards, especially VHDCI Carrier, and Sinara Banker. Additionally is it ok to say that Banker is developed board from VHDCI Carrier...?

07:53 <mtrbot-ml_> [mattermost] <sb10q> yep, it's possible, though those boards are less mature than the others. write us an email for price, lead time and other details

07:54 <mtrbot-ml_> [mattermost] <sb10q> banker is not related to the vhdci carrier

07:57 <mtrbot-ml_> [mattermost] <alexist> Ah ha! Furthermore, then is it possible to connect Sinara boards like Urukul with kc705? I saw some photos that kc705 is connected with Urukul through VHDCI carrier. So I wonder it is possible still.

07:59 <mtrbot-ml_> [mattermost] <sb10q> it is possible in theory, but not supported anymore and doing it is probably more expensive than a kasli

08:03 <mtrbot-ml_> [mattermost] <alexist> Then Banker and additional board except kc705 could be more expensive than Kasli considering only price...?

08:05 <mtrbot-ml_> [mattermost] <sb10q> if you want the lowest-cost solution, use the off-the-shelf modules, i.e. what is in the webshop - or develop gateware/software yourself

08:09 <mtrbot-ml_> [mattermost] <alexist> Ah ha thanks, it becomes more clear! Really thanks for your time!

08:28 <mtrbot-ml_> [mattermost] <sb10q> simple kernels are running on zynq now :)

08:41 <mtrbot-ml_> [mattermost] <sb10q> why is zynq hiding 1MB of the SDRAM? this stuff sometimes looks like memory management on a 1990 MS-DOS PC...

08:41 <mtrbot-ml_> [mattermost] <hartytp> @sb10q awesome!

08:43 <mtrbot-ml_> [mattermost] <hartytp> BTW I don’t see how the VHDCIcarrier is less mature than the boards you have on the we shop. Less used maybe?

08:43 <mtrbot-ml_> [mattermost] <sb10q> yeah, less used. also I don't know how long VHDCI cables perform at high speeds?

08:44 <mtrbot-ml_> [mattermost] <hartytp> But I think it’s worth publicising as it’s a nice part of the family eg we use it to allow “remote ems”. Eg digitise a bunch of signals using sampler at one end of the lab and then route to kasli via a single scsi cable

08:44 <mtrbot-ml_> [mattermost] <sb10q> can you sync Urukul at 1GSPS at the end of 5m of VHDCI cabling etc.

08:45 <mtrbot-ml_> [mattermost] <hartytp> Not sure about that but @cjbe @dpn use one at least 5m for su servo without issues.

08:46 <mtrbot-ml_> [mattermost] <hartytp> I can also imagine it being nice eg if one wanted a bunch of dio somewhat far from Kasli. Anyway the point is that it’s a simple well tested design that works and has uses so no harm in publicising it — people will find uses!

08:47 <mtrbot-ml_> [mattermost] <hartytp> Anyway I do agree strongly with the main point that Kasli is sufficiently cheap that it doesn’t make sense to buy a bunch of adapters to get a kc705 up and running

09:01 <mtrbot-ml_> [mattermost] <sb10q> @hartytp do you have a kasli2 already?

09:23 <mtrbot-ml_> [mattermost] <hartytp> No idea if we’re even receiving deliveries. @dpn

10:06 <mtrbot-ml_> [mattermost] <sb10q> rust tools really need an option `--just-fucking-compile-it` that enables all nightly/experimental features without having to spend an hour figuring out the correct syntax and place to enable a particular feature...

14:54 <mtrbot-ml_> [mattermost] <hartytp> @sb10q @rjo what are your thoughts about the "fast servo" EEM? We have too much on our plate to take it on, but I think it could be a nice addition to Sinara. Do you have any plans to advertise it once the hw is read and see if anyone is interested in picking the project up and funding it? It's not a small job, but it's an interesting design that I can imagine being useful for some experiments...

14:58 <rjo> As you know, lack of comprehensive review and involvement by those with experience in building, using, and developing tends to lead to bad designs, long delays, and little uptake.

14:59 <rjo> I have a couple of groups interested in principle but nobody willing to invest money. That's the reason we're staying out of it. Same for a couple other projects.

15:01 <rjo> It's not our job to advertise projects that we are not involved in. It would be a bad idea. We can't do that. You may want to talk to CTI or TS to do advertising of their projects.

15:04 <rjo> I also think that everyone who gets involved by advocating for certain features or design decisions should feel responsible for the project. After all Greg and his students are developing these to meet those demands and trust that those decisions are in the best interest.

15:33 <rjo> I'd hate to see that fast servo eem become a dead end. There needs to be a discussion about the requirements and non-features (RF demodulation, wide-band but DC accurate) and an analysis whether the current monolithic approach is the best. And then it's very unclear to me what the gateware priorities are. It would also be bad if everybody is left with a "minimal" firmware/gateware set because there is no longer term plan.

21:04 <_whitenotifier-9> [smoltcp] Dirbaio synchronize pull request #336: WIP: Separate IP parts from EthernetInterface. - https://git.io/JffHD

21:06 <_whitenotifier-9> [smoltcp] Dirbaio commented on pull request #336: WIP: Separate IP parts from EthernetInterface. - https://git.io/Jftpj

21:11 <_whitenotifier-9> [smoltcp] Failure. The Travis CI build failed - https://travis-ci.org/github/smoltcp-rs/smoltcp/builds/679840508?utm_source=github_status&utm_medium=notification

21:20 <_whitenotifier-9> [smoltcp] Dirbaio opened pull request #337: Assign map instead of using mem::replace. - https://git.io/Jfth4

21:22 <_whitenotifier-9> [smoltcp] Dirbaio commented on pull request #336: WIP: Separate IP parts from EthernetInterface. - https://git.io/Jfthg

21:29 <_whitenotifier-9> [smoltcp] Success. The Travis CI build passed - https://travis-ci.org/github/smoltcp-rs/smoltcp/builds/679844545?utm_source=github_status&utm_medium=notification

22:24 <_whitenotifier-9> [smoltcp] Dirbaio opened issue #338: TCP RSTs replied-to with ACKs - https://git.io/Jfqeu

22:35 <_whitenotifier-9> [smoltcp] Dirbaio edited pull request #336: Separate IP parts from EthernetInterface. - https://git.io/JffHD

23:44 <mtrbot-ml_> [mattermost] <dpn> Regarding long VHDCI cables, we are using two Samplers at the end of 10 m without issues as part of SUServo, yes

23:45 <mtrbot-ml_> [mattermost] <dpn> And, @hartytp, we aren't receiving anything sent to the department, but Finance people are officially okay (or at least tolerate) having things sent to your home address