<d1b2>
<cfy_yfc> is there any existing design for an enclosure that can be 3D-printed? something simple to get started and to protect the prototyping Glasgow Explorers?
<_whitenotifier-9>
[glasgow] whitequark closed issue #300: error: The 'amaranth' distribution was not found and is required by glasgow (install not working) - https://github.com/GlasgowEmbedded/glasgow/issues/300
<whitequark>
Attie: ah I didn't realize you're via the bridge
<whitequark>
it's nice to still have you around
<d1b2>
<Attie> o/
<d1b2>
<Darius> it's you who's via the bridge!
<d1b2>
<Darius> (all a matter of perspective..)
<whitequark>
hehe~
<d1b2>
<Attie> I'm here, but life has changed shape for me, so less ability to be proactive on things like Glasgow 😦
<whitequark>
I figure
<d1b2>
<Attie> still got a pile of wish list items!...
<whitequark>
so I have a lot more bandwidth these days, which is good
<whitequark>
there's actually not that many issues / PRs in the queue, I should go through many this weekend
<d1b2>
<Attie> was thinking about how to sniff on 2x UART Rx the other day (e.g: between uC and modem)
<whitequark>
also, I just did a near complete rework of how YoWASP works so it's now production-ready
<d1b2>
<Darius> sigrok? 🙂
<whitequark>
oh yeah yeah, multi-applet support
<d1b2>
<Attie> I saw your recent news - congrats!
<whitequark>
I think I'll kick most applets out into something like glasgow-community and then we'll be able to iterate faster with a smaller amount of easier to use core applets
<whitequark>
the upcoming Amaranth changes will also be very helpful
<d1b2>
<Attie> one of my things for the "UART tap" was to have correct ordering between the streams - so perhaps not multi applet(?)
<whitequark>
oh I see
<d1b2>
<Attie> -community sounds sensible, especially given the new users that we might be seeing soon
<whitequark>
yeah...
<d1b2>
<Attie> let me know if you'd like input / support
<_whitenotifier-9>
[GlasgowEmbedded/glasgow] whitequark 074db5d - software: depend on amaranth-yosys directly.
<d1b2>
<Rogan> Am I wrong in thinking that if the two streams are full duplex, then the ordering doesn’t strictly matter because it’s just a coincidence of timing when the bytes are transmitted, whereas if they are half duplex (request/response), then there will be a (possibly really small) time period between one side transmitting and the next?
<tpw_rules>
i mean lots of protocols are still request/response over full duplex connections
<tpw_rules>
(but can sometimes have asynchronous elements)
<d1b2>
<Rogan> Sure, I was using half- and full-duplex as shorthand for request/response initiated from one side only (or passing a possibly implicit token back and forth), vs either side can speak at any time.
joerg has quit [Ping timeout: 260 seconds]
joerg has joined #glasgow
ar-jan has joined #glasgow
redstarcomrade has quit [Quit: Connection closed for inactivity]
ar-jan has quit [Ping timeout: 248 seconds]
<d1b2>
<Attie> cellular modems like this are typically driven by AT commands (request / response), but they also have URCs (Unsolicited Result Code) which can happen unexpectedly.
<d1b2>
<Attie> fundamentally though, for a debug tool like this to be coherent / truthful, ordering between two related streams like this is very important... possibly even exposing timing information too
ar-jan has joined #glasgow
<d1b2>
<Rogan> Fair enough. I created a simple python script that would read from two independent serial ports, and interleave the data, but I allowed a small timeout (0.1s) for formatting reasons - basically to keep the data on the same line where possible. But as soon as any data was readd from the other serial port, I switched. Data was presented in different colours to make it more obvious which was which
<gruetze_>
oh, multi-rx would be really useful (exactly for the cellular modem usecase - mine's a bit weird though - fun GSM extensions)
<d1b2>
<Rogan> Probably not really the place for it, but here they are
<ar>
cfy_yfc: you can export dxf and step from these files
<ar>
pdf and svg should also work, but at least with some lasercutter software svg happens to have scaling issues
<d1b2>
<cfy_yfc> In the past (once or twice) I sent dxf to my local library which offers to Glowforge designs ... for free! but they typically ask me about a reference measurement, as dxf does not seem to contain this ... or when reading it into the Glowforge software it seems to be missing; OK, seems like I will do dxf then and provide a reference as before; thanks!
<d1b2>
<XoD> This needs to be a live stream! 😍
jstein has quit [Quit: quit]
cr1901 has quit [Read error: Connection reset by peer]