<GitHub22>
[smoltcp] barskern commented on pull request #225 09f68be: I agree with this, however the reason for the awkward debug log is that this action doesn't technically send a retransmit, but it sets the socket up to send one. When the timeout expires for a "normal" retransmit it says something similar to this, hence I used the same phrase. https://github.com/m-labs/smoltcp/pull/225#discussion_r194208894
<GitHub135>
[smoltcp] barskern commented on pull request #225 09f68be: I agree with this, however the reason for the awkward debug log is that this action doesn't technically send a retransmit, but it sets the socket up to send one. When the timeout expires for a "normal" retransmit it says something similar to this, hence I used the same phrase. https://github.com/m-labs/smoltcp/pull/225#discussion_r194208894
<GitHub144>
[smoltcp] whitequark commented on pull request #225 e9e5502: I hate to nitpick, but this match statement could be replaced with a `if self.local_rx_dup_acks == u8::max_value() { "+" } else { "" }` in the debug statement below, and then we wouldn't have logic and presentation of debug logging mixed. https://github.com/m-labs/smoltcp/pull/225#discussion_r194212873
<sb0>
rjo, I tested the latest misoc, and the #1040 problem is still there
<sb0>
so is #1039
<sb0>
did you test the new code on the board? am I doing something dumb?
sb0 has quit [Quit: Leaving]
_whitelogger has joined #m-labs
<rjo>
sb0: i tested all and couldn't reproduce them. but if it is still broken then i guess i messed up the testing.
hartytp has joined #m-labs
<hartytp>
sb0: can we add microscope probes to the sawg output and capture a trace with a few cycles of the output
<hartytp>
That would verify that the problem is indeed the sawg
<hartytp>
Then add probes to different parts of the signal chain to pin down where the issue is?
<hartytp>
(By the way, I really like microscope from my brief play with it yesterday)
hartytp has quit [Ping timeout: 260 seconds]
hartytp has joined #m-labs
<hartytp>
Afaict that's easy to do with microscopes buffered probes
<hartytp>
rjo: if you let me know what probes you want then I'm happy to give that a go tomorrow
<GitHub-m-labs>
artiq/master 0b08622 Robert Jördens: sawg: don't use Cat() for signed signals...
<GitHub9>
[smoltcp] barskern commented on pull request #225 e9e5502: Don't worry about nitpicking, I think that is a great way of maintaining a good code standard! And I like getting your feedback because it makes me think twice about how I would write something. Keep on nitpicking 😊 https://github.com/m-labs/smoltcp/pull/225#discussion_r194221448
<rjo>
while i was running a barely modified test of #1039 the output signal disappeared and subsequent load/start all lead to this. tripped supply, a rework come undone?
<sb0>
rjo, just reflashed an older gateware/firmware and same problem. looks like a hardware issue indeed. i haven't physically disturbed the board, so I don't know what happened...
<sb0>
we have another RTM but one DAC on it is broken
<sb0>
jbqubit_, btw how much crap did the customs give you/Greg when you sent the boards back to PL? did you write anything special on the declaration?
jbqubit_ has quit [Ping timeout: 260 seconds]
jbqubit_ has joined #m-labs
<jbqubit_>
I've received two shipments now from Warsaw that breezed through customs. Including the right type of information as to the package contents proved helpful. Here's my latest advice on that front.
<jbqubit_>
I'm away from the lab today and powered off my Sayma. So I can build gateware but can't do/host tests until I return to UMD tomorrow.
<sb0>
jbqubit_, that's to UMD. I'm asking to Poland.
<jbqubit_>
To test current SAWG the RTM with a single working DAC seems sufficient.
<jbqubit_>
I've had good experience lately shipping to Technosystem using FedEx. Greg lives near their facility and is able to pickup packages quickly.
<sb0>
yeah, but if you check the wrong boxes then there is a big customs tariff
<jbqubit_>
I've asked a couple students who might be working today at UMD to cycle power on Sayma board. Will let you know if somebody switches it on.
<jbqubit_>
In addition to detailing the contents of the package, indicate that the devices are being returned for repair and that they will be sent back to HK.
<jbqubit_>
Might be helpful to ask Technosystem to create a Return Merchandise Authorization (RMA) number or some such official sounding thing.
<sb0>
yeah, well, Greg seems blissfully unaware of such things
<sb0>
and detailing the contents of the package can backfire. for the Sayma board I sent to Duke, I explained it was a "signal generator" and this resulted in imbecilic customs questions such as "what is the horsepower of the diesel engine inside the generator"
<jbqubit_>
For import to USA I've honed the language of shipping-to-umd advice based on experience with such imbecilic questions. Some of the email threads with customs agents have gone on for > 5 back and forth.
<sb0>
on the other hand, packages with vague descriptions such as "electronic circuit" are sometimes simply waved through
<jbqubit_>
I tried vague sounding contents. It never worked for me. Specific part numbers, manufacturer name, description of part, description of end us of part and comment on potential hazards of part seem to cover the bases.
<reportingsjr>
Write "gift". That is the real trick.
<sb0>
"gift" works between individuals, but i'm not sure if shipments between companies/universities labeled as "gift" would seem suspicious
<sb0>
it also can be considered illegal and get us into trouble.
<reportingsjr>
:) I wasn't being serious
<reportingsjr>
That's just what 80% of vendor on aliexpress put on packages
<sb0>
yeah, in the aliexpress/taobao/etc. world, some companies also let you provide the declared value and give you a "hint for information purposes only" of what the declared value is for packages of similar size taking that route
<sb0>
those import/export declarations are just a joke. on several occasions I've exported resistors by certifying that I would use them for the purpose of creating voltages proportional to the current through the resistor.
jbqubit__ has joined #m-labs
jbqubit__ has quit [Client Quit]
jbqubit__ has joined #m-labs
<sb0>
why something as commonplace as regular 0603 1% resistors require such a declaration is also a mystery.
jbqubit__ has quit [Client Quit]
jbqubit_ has quit [Ping timeout: 260 seconds]
sb0 has quit [Quit: Leaving]
jbqubit_ has joined #m-labs
jbqubit_ has quit [Client Quit]
jbqubit_ has joined #m-labs
<jbqubit_>
UMD Sayma is now powered on, booted and responding to ping.
<jbqubit_>
SB has login credentials and instructions
<jbqubit_>
Web-based oscilloscope on local subnet is connected to a pair of sawg, one from each DAC chip.
<GitHub113>
[smoltcp] m-labs-homu closed pull request #219: Add support for arbitrarily many routes instead of only gateways. (master...managedmap-routes) https://github.com/m-labs/smoltcp/pull/219
<GitHub20>
[smoltcp] m-labs-homu commented on issue #178: :umbrella: The latest upstream changes (presumably 06d18130cd8b25edbcad207bbdbb157f1c1203df) made this pull request unmergeable. Please resolve the merge conflicts. https://github.com/m-labs/smoltcp/pull/178#issuecomment-396000642
<GitHub193>
[smoltcp] ProgVal commented on pull request #232 67c539c: nit: not sure about this repo's coding style, but I personally prefer this: `repr.window_scale = self.remote_win_scale.map(|_| 0)` https://github.com/m-labs/smoltcp/pull/232#discussion_r194240529