ChanServ changed the topic of #glasgow to: glasgow debug tool · code https://github.com/GlasgowEmbedded/glasgow · logs https://freenode.irclog.whitequark.org/glasgow · discord https://1bitsquared.com/pages/chat · production https://www.crowdsupply.com/1bitsquared/glasgow · no ETAs at the moment
balrog has joined #glasgow
tomtastic has quit [Ping timeout: 256 seconds]
tomtastic has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 246 seconds]
<d1b2> <xobs> Good morning, all!
<d1b2> <xobs> As @esden alluded to, most of the lineworkers can't do much with the information beyond determining "it's busted". So having "PASS/FAIL" is usually enough.
<d1b2> <xobs> Here's two Fomu test jigs. The lights were actually the idea of the factory.
<d1b2> <xobs> We could have put a text console in, but the Chinese workers wouldn't understand the English output. Instead we put LEDs.
<d1b2> <xobs> There's a chart at https://github.com/im-tomu/fomu-factory-test/blob/master/jig/README.md that tells you what the LED pattern means. All the lineworker needs to know is: If LED 5 is ON and LED 1 is ON, then the device is PASS. However, if LED 5 is ON and LED 1 is OFF, then FAIL. LEDs 2, 3, and 4 give more information, but the worker doesn't care about that.
<d1b2> <xobs> The factory translated this table for me, which makes it easier for them to know what to rework.
Stormwind_mobile has joined #glasgow
<d1b2> <esden> I see so the led do have an indicator in the table to tell the line workers which part of the board to rework.
<d1b2> <esden> or rather the person that would do the reworking if there is enough boards to repair
<d1b2> <esden> @xobs thank you for sharing the additional information. 🙂 Are you using the recorded (json database of exclave) test results data for anything?
<d1b2> <xobs> @esden occasionally I have the factory email me the results database and I write some awful jq command to look for patterns in failures, which means I can tell the factory which parts they need to focus on fixing. But oftentimes they already know that.
<d1b2> <esden> Ok cool! 🙂
_whitelogger has joined #glasgow
_whitelogger has joined #glasgow
* whitequark reads the backlog
<whitequark> i think we'll need to agree to designate some time interval to focus on glasgow shortly, well, "we" mostly means "I do" there
<ktemkin> incidentally, I promised @esden I'd spend some time helping with {materials, demos} for the CS campaign back in December, and then stuff came up and he never wound up communicating what he thought would help :)
<d1b2> <futaris [AU]> Catch-22. Chicken and egg essentially. Until it's used by users you don't know what users want to use.
<d1b2> <futaris [AU]> Catch-22. Chicken and egg essentially. Until it's used by users you don't know what users want to use.
<ktemkin> there's a big difference between "what shows off something well for a CS campaign" and "what users will wind up using the thing for", though
<d1b2> <mattvenn> I'm not an expert, only deployed 2 jigs. But fwiw here is my experience: I wouldn't use pis. They were too weird for the factory. 2nd time I used cheap ThinkPad. I would definitely recommend network connectivity. Zerotier worked much better than reverse SSH. Bunnies product behind the product is very insightful. I've had intermittent problems with 2nd jig that I can't replicate in my lab. I'm guessing emc. Next time I would do basic emc
<d1b2> compliance on the jig! Our cm was useful for diagnosis and fixing, so having more output than pass fail is worth having. I like the LEDs on the jigs above. We used a pyqt app with Chinese translated status. Fetching detailed results over the network helped me identify new problems. Have another set of everything custom or difficult to source there already on site so if something goes wrong it can be replaced without blocking the line.
espes has quit [Ping timeout: 260 seconds]
Getorix has joined #glasgow
Getorix_ has quit [Ping timeout: 260 seconds]
carlomaragno has joined #glasgow
<d1b2> <transorbs> At my last job we started using raspberry pi's to run test jigs, worked fairly well
Stormwind_mobile has quit [Ping timeout: 272 seconds]
<_whitenotifier-f> [GlasgowEmbedded/glasgow] electroniceel pushed 1 commit to wip-revC2 [+0/-0/±4] https://git.io/JfMTT
<_whitenotifier-f> [GlasgowEmbedded/glasgow] electroniceel f8d1861 - revC2: replace ADC with INA233 voltage & current monitor
<_whitenotifier-f> [glasgow] electroniceel synchronize pull request #196: WIP revC2 - https://git.io/JfXxO
<electronic_eel> ok, so my proposed schematics change for changing to the INA233 is now in the wip-revC2 branch
<electronic_eel> I did it with all the bells and whistles for now, meaning a) including a lowpass filter on the shunt input
<electronic_eel> and b) a 36V tvs diode
<electronic_eel> the INA233 can measure up to 36v, but we can't use that if we connect vsense to the regular tvs diode set, because they will conduct at about 8v or thereabouts
<electronic_eel> with the separate tvs diode, you can safely measure stuff like a 24v supply or something
<electronic_eel> I had to do one change that affects other circutry: I changed the dropper resistor after the vio regulator from 0.68 to 0.47
<electronic_eel> this is to allow the INA233 measure the full specified current range of the vio (150mA), it can now measure up to 174mA
<electronic_eel> the dropper resistor was added from revC0 to revC1, to fix the issue of the ldo not properly switching off on a short
<electronic_eel> we also added the polymer bulk capacitor for this
<electronic_eel> the 0.68 ohms value was just guessed
<electronic_eel> but I'll of course will have to check that it still works as designed with 0.47
<electronic_eel> whitequark: esden: what do you think about completely removing the footprint of the ATECC?
<electronic_eel> it doesn't hurt where it is, but I see that there are constantly popping up questions about it
<whitequark> sure, why not
FFY00 has quit [Remote host closed the connection]
<electronic_eel> when someone sees it, I can understand that there pop up questions about some closed stuff being hidden or some future agenda to close it up
FFY00 has joined #glasgow
<electronic_eel> I can fully understand that, because they don't know how deep whitequarks love for closed stuff goes ;)
<whitequark> :p
<tnt> whitequark's secret masterplan for world domination ... it all starts with one chip.
<whitequark> ohh i hope not... i have enough responsibility as it is
<_whitenotifier-f> [GlasgowEmbedded/glasgow] electroniceel pushed 1 commit to wip-revC2 [+0/-0/±3] https://git.io/JfMkm
<_whitenotifier-f> [GlasgowEmbedded/glasgow] electroniceel d9e81bd - revC2: remove ATECC ic from schematics
<_whitenotifier-f> [glasgow] electroniceel synchronize pull request #196: WIP revC2 - https://git.io/JfXxO
Stormwind_mobile has joined #glasgow
<d1b2> <esden> hehehe... @whitequark : "what? world domination? naaahh that is too much responsability..." 😛 you made my day 😄
<whitequark> tell me i'm wrong...
<d1b2> <esden> As far as I understand typically people don't feel responsible when they take on world domination... the fact that you see it as a responsibility speaks volumes. 🙂
<whitequark> oh
smkz has quit [Quit: smkz]
smkz has joined #glasgow
smkz has quit [Client Quit]
smkz has joined #glasgow
<d1b2> <niklas> hey!
<whitequark> hi niklas!
<d1b2> <niklas> I heard you have verified the rev C2 design?
<whitequark> we're actively working on it recently
<d1b2> <niklas> I finally ordered the JLCSMT version of C1
<whitequark> not yet done... here's the PR https://github.com/GlasgowEmbedded/glasgow/pull/196
<d1b2> <niklas> So this is already with the INA233?
<whitequark> yep, electronic_eel just pushed some commits
<whitequark> like 2 hours ago
<whitequark> i'm not sure of the exact status but i believe at least the basic idea is correct there
<d1b2> <niklas> nice
<d1b2> <niklas> I super curious if my 1,70€ CY7C68013A work 😄
<electronic_eel> hi niklas
<whitequark> why not? those chips are super common
<whitequark> and i've never heard of anyone getting fakes
<whitequark> i mean, they probably exist, it just doesn't look like a widespread issue
<d1b2> <niklas> yeah but they are $10 at mouser and digikey
<d1b2> <niklas> this is almost too cheap
<electronic_eel> whitequark: the schematic with the INA233 as pushed should work, the only think I have to verify is the dropper resistor value after the ldo (which doubles as shunt for the INA)
Stormwind_mobile has quit [Ping timeout: 256 seconds]
<electronic_eel> @niklas I heard from wq that you were waiting to hear some more specifics about how the ina should be added from me
<whitequark> niklas: people sell logic analyzers on ebay for like $3 or $5
<whitequark> so $1.70 for the FX2 seems about right
<electronic_eel> I think this was some miscommunication, I thought you knew what to do. sorry for that
<whitequark> though that's for the SOIC (?) not QFN
<whitequark> (was it TSOP?)
<electronic_eel> there is just a SSOP package alternative I think (0.635 pitch)
<whitequark> oh yeah SSOP
<whitequark> those are the cheapest by far
<whitequark> but also kind of annoying, that package is *huge*
<whitequark> massively thick
<electronic_eel> yeah, like right out of the 90ies
<d1b2> <esden> I did get "refurbished" FX2 chips before ... they work fine, they are just desoldered from some other boards and cleaned. It is actually cool because the chips get actually recycled that way. 😄
ali_as has quit [Remote host closed the connection]
ali_as has joined #glasgow
<d1b2> <niklas> electronic_eel yeah it was miscommunication, I thought it's better to wait till you come up with a design for the INA233, I didn't know you were waiting for me. Sorry.
<d1b2> <niklas> Anyway, I would be very happy to adapt these changes for Edinburgh 🙂