<cyrozap>
@Elon Musk: I remember reading on SparkFun's blog a while back that it usually takes several months from the time they release a product to the first appearance of a clone (all their designs are OSHW), so they just price their products so they'll be able to make a profit before the clones appear. And so, rather than attempt to profit off of the same design indefinitely, they just keep comping up with new
<cyrozap>
ones to sell to stay ahead of the clones. I must have read that over 10 years ago (and I somehow can't seem to find a link to the original post...), so maybe things have changed since then, but SparkFun is still around and (presumably) profitable so clearly that hasn't been a terrible strategy for them.
<cyrozap>
IMO, if your only value-add for the "original" product is "it's manufactured by the same people who designed it", that's not a sustainable business model. But if instead it's "we provide support for original products, with a valid order number" (the "selling support included with the product" model), or "when you buy from us, you know it's been built with quality components and tested to work properly"
<cyrozap>
(the "sell the brand" model), or (as in SparkFun's case) "you can get it from us months before you'll find it anywhere else" (the "natural exclusivivity" model), then it's much more likely to succeed.
<sorear>
important to note that the people manufacturing glasgow are _not_ the people who did the original design
<sorear>
so I don't think the business model stuff you're talking about applies at all
<d1b2>
<xabean> There will always be clones of $thing, no matter what it is. I just hope enough people support the devs (e.g. funding through crowdsupply, buying from 1b2) to make it worthwhile for the devs.
<cyrozap>
Personally, if I was designing some OSHW board, I would love if someone else did all the work (and put up all the up-front capital) to manufacture, market, and sell it, even if it means I wouldn't personally profit from it. Because generally, when I build something, it's because "nothing like this exists, and I really want it to exist", and dealing with things like manufacturing and shipping and returns
<cyrozap>
is a a full-time job--and I already have one of those. I would much rather spend my free time desinging more stuff that doesn't exist than on a second full-time job, and let the people who know how to aggresively reduce BOM and manufacturing costs do what they're already good at.
<cyrozap>
sorear: I was speaking generally, but I think the business model aspect still applies here--1b2's seems to be the "natural exclusivivity" model (I mean, the campaign already has 760 backers, and if they're doing 3-4x COGS, even after paying the distributors that's a pretty decent profit, even if they never sold any more than that), at least initially, and "sell the brand"/"selling support included with
<cyrozap>
the product" in the longer term (the "cost down" clones can have fatal flaws due to their component choices/redesign, and good luck trying to return a board to an AliEx seller).
<sorear>
if you want to fund ongoing development, wq has a patreon; I have not heard anything about 1b2 optimizing for profit margin
<whitequark>
fwiw, i'm not happy about that conversation, i grossly mishandled it
<whitequark>
what i should have done instead is offered Niklas to qualify Edinburgh boards so they could be fully supported instead
<whitequark>
(or, otherwise, know exactly where they could not be fully supported)
<whitequark>
the motivation is still the same, but i would take completely different actions today, ones that would not alienate people trying to collaborate
<whitequark>
i think upstream libusb can actually be used with termux? i'm not entirely sure though
<sorear>
I think there's still time
<whitequark>
hm?
<whitequark>
we already discussed that, you're just linking old conversations here without newer context
<sorear>
I don't think you've made a more cost-optimized board permanently impossible
<whitequark>
i don't understand how that statement is relevant
<whitequark>
what i meant is that i talked to Niklas and suggested what i should have suggested in the first place
<sorear>
I've lost track of what's being argued here
<d1b2>
<j4cbo> i think "variants should have a different name" is a reasonable policy (and does not exclude also working together to ensure compatibility)
<d1b2>
<xabean> derivative works also disconnect you from whatever the original project's goals may have been, which can be good for both the original and derivative.
<d1b2>
<Elon Musk> nah the chinese cloners aren't going to make variants, they will copy the board as-is (and maybe add a better looking enclosure)
<d1b2>
<Elon Musk> engineering is expensive and they aren't gonna spend any more time than they have to to make a buck
<d1b2>
<Elon Musk> i don't think 3 months of sales is usually enough to make back development costs
<d1b2>
<Elon Musk> that's an incredibly short product lifecycle
<d1b2>
<Elon Musk> especially when you spent years on it
<d1b2>
<Elon Musk> patreon doesn't really work either
<d1b2>
<Elon Musk> wq is a very high profile engineer with 20k followers on twitter, and even then still only gets maybe 3k/month on patreon
<d1b2>
<Elon Musk> that's nowhere near what an engineer at that skill level should be paid
<d1b2>
<j4cbo> i think clones (not interested in contributing back, and probably don't care about license at all) and forks / derivative works (people interested in adding and sharing their own spin on it) are different categories
<d1b2>
<Elon Musk> yes
<whitequark>
who would have thought that a user who goes by "Elon Musk" has brain capitalism *sigh*
<d1b2>
<Elon Musk> fyi i'm not a fan of patents at all but i think copyright is completely fine
<whitequark>
fyi i fucking hate patents, copyright, and elon musk
<whitequark>
is this clear enough
<whitequark>
i would pay money to not be in this conversation ever again
<d1b2>
<Elon Musk> haha
<d1b2>
<Elon Musk> but wasn't tesla the first company that said they will let you use their patents royalty-free if you let them use yours?
<whitequark>
get out
<d1b2>
<j4cbo> certainly not
<whitequark>
it is with great regret that i admit that my passion for open source hardware makes it possible for elon musk fans to benefit from my work
<sorear>
i am also suspicious of the claims above that 1b2 is selling at 4x their costs and using the balance primarily to fund glasgow development
<d1b2>
<Elon Musk> 4x cost is pretty reasonable
<sorear>
it would be _reasonable_ but i do not think it is _factually correct_
<d1b2>
<Elon Musk> oh
<d1b2>
<Elon Musk> i just did a bom analysis yesterday though
<d1b2>
<Elon Musk> and 4x looks about right
<d1b2>
<Elon Musk> well 4x COGS, but of course you have other expenses of running a business and stuff
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel has joined #glasgow
<d1b2>
<transorbs> Hey whitequark, sorry to be offtopic in this channel, but I recall you a while back finding a source for schematics of consumer goods (cellphones, laptops, etc). I'm trying to hunt down some camera schematics.. Do you remember your source?
<fridtjof[m]>
transorbs: I've had good results for service manuals mostly (but also schematics sometimes) on a site called elektrotanya.
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
esden has quit [Ping timeout: 264 seconds]
eddyb[legacy] has quit [Ping timeout: 246 seconds]
eddyb[legacy] has joined #glasgow
esden has joined #glasgow
ExeciN has joined #glasgow
ExeciN has quit [Client Quit]
<d1b2>
<theorbtwo> Surprisingly many service manuals include schematics.
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #glasgow
Stormwind_mobile has quit [Remote host closed the connection]
Stormwind_mobile has joined #glasgow
tmbinc has joined #glasgow
<tmbinc>
I want to create an applet that can speak both JTAG (well, a 3-pin variant of it) as well as SPI (with some hard rules about clock - literally the device burns a power transistor if I don't keep SPI CLK at the right freq, don't ask.)
<tmbinc>
I did manage to implement a custom JTAGProbeBus that does the right thing, but what's the right choice to add a second interface "next" to it?
<whitequark>
hm
<whitequark>
are the JTAG and SPI pins shared?
<tmbinc>
For example, should it use a separate interface? As far as I read, there are only 2 pipes, so if I use the analyzer, I can't claim a second one
<tmbinc>
yes, eventually they are shared.
<whitequark>
that's kinda cursed. hmmmm.
<tmbinc>
(Which i planned to implement in the SPI part of it0
<whitequark>
i would suggest you use two subtargets, but if you *also* want to use the analyzer...
<tmbinc>
it _is_ cursed, but also pretty cool. (Those are Agilent N67xx DC power modules - they have fixed 48v bulk input, and then are fully programmable ove rthis digital interface)
<whitequark>
it might be easier to add your own mux/demux logic
<whitequark>
i don't envy you, with the current architecture it is not trivial, and it is *definitely* not upstreamable at all
<whitequark>
i can provide some general assistance though
<tmbinc>
I see - is the 2 pipes thing a hardware limitation?
<whitequark>
fx2, yes
<whitequark>
eventually there will be a built-in multiplexer for exactly this situation
<whitequark>
probably using COBS
<tmbinc>
Ideally i'd like support for multiple applets at the same time, of course :)
<whitequark>
in your case, multiple applets won't really help
<whitequark>
you want the underlying logic that supports multiple applets
<whitequark>
most of the multiple applet support issue is actually the UI
<whitequark>
the underlying logic, while not trivial, is far simpler and we will implement it long before the UI
<tmbinc>
fair point, I haven't though about the UI that much yet
<tmbinc>
Doesn't COBS require to buffer up to 256 bytes?
<tmbinc>
i always found that annoying
<whitequark>
yep, but you already want that for USB anyways
<whitequark>
since unless you are sending full size bulk packets you are losing bandwidth massively
<tmbinc>
fair point but isn't the buffer in the FX2 today?
<whitequark>
it is in the FX2 and in the FPGA too, since there are multiple pipes but only one FX2 port
<whitequark>
(and in the OS and...)
<whitequark>
(there's a lot of buffering everywhere to get high throughput)
<whitequark>
really, i don't think that COBS will add more than one BRAM of overhead
<tmbinc>
Ok, for now I'll hack my way through the JTAG stack with no intentions to make this clean then :)
<whitequark>
yep, sounds good, the JTAG stack should be plenty hackable also
<tmbinc>
I already had to hack it since i need a TCK2X signal
<whitequark>
i know people cut it out of glasgow completely and grafted to a plain UART for example
<tmbinc>
this cursed thing expose the FPGA JTAG directly, and they just added a D-FF for the 3pin->4pin expand, so negative clock edge for TCK will update TMS, positive will update TDI (and clock the JTAG SM)
<tmbinc>
so they "autodetect" the module by reading the (Xilinx) IDCODE, then uploading a bitstream that allows boundary scan (because for some more cursed reason on Spartan-3 you can't just HI-z everything), detect a few hardcoded pins, and then upload the final bitstream
<tmbinc>
that final bitstream then drives the power logic, and if you don't keep a clock, it will - somehow - make the first-stage P- and N-FET drive at the same time. boom.
<electronic_eel>
compared to the cursed jtag stuff whitequark posted some time ago this doesn't seem too cursed to me. except the boom-on-no-clk part. that is really cursed
<whitequark>
that sounds like an incompetently designed power electronics part
<whitequark>
to put it bluntly
<whitequark>
the JTAG stuff is ... okayish
<whitequark>
i mean it's mildly cursed but yeah i've seen *far* worse
<tnt>
maybe it's an intentional booby trap ...
<electronic_eel>
don't think so. they probably wanted to do everything in the fpga and save money on a driver with integrated hw lockout and dead-time generation. that part is ok. but then they let an inexperienced eng write the gateware or something
<whitequark>
tmbinc: does the unplanned explosive disassembly happen during programming or when you drive the module in its intended configuration?
<whitequark>
... honestly, either case is incompetence, but depending on which one it is, the degree differs
<whitequark>
>High-end modules for critical test requirements
<whitequark>
uhhuh
<tmbinc>
well, the "intended usecase" uses the N6700/1/2 or N6705 chassis, which uses an FPGA for config that switches to SPI directly after the last JRUN
<tmbinc>
so it works okay in their use case
<electronic_eel>
...given that there are no intermittent connections on the bus connectors or similar problems. then it can go boom in their intended usecase
<whitequark>
"it works okay in best circumstances" is like the lowest bar for any software/hardware
<whitequark>
if it exploded in normal use, they couldn't sell it, of course it doesn't explode during normal use. that's completely unimportant
<sorear>
to what extent is "explode" literal
<whitequark>
High-end modules for critical test requirements
<whitequark>
High-end modules for critical test requirements
<whitequark>
er, sorry, misclick
<whitequark>
sorear: if it shorts the 48V power rail through a half bridge, it would be very literal
<d1b2>
<Attie> it's there a current limit option during power up and config or something?
<d1b2>
<Attie> yeesh
<electronic_eel>
the psu supplying the 48v rail would be a quite beefy one. adding some current limiting that kicks in early enough to let a shorted bridge survive would have to be quite sophisticated
<whitequark>
I believe it is possible to do so, but... it would be a lot cheaper to use a half bridge driver with built in dead time, wouldn't it?
<whitequark>
or many other ways to make this module fail safely
<whitequark>
(some sort of small hard logic circuit that shuts down the FET drivers if there is no clock for example)
<electronic_eel>
i guess just properly writing the gateware with some small hard logic would be enough. but you have to do proper engineering to think about this case and take measures to prevent it
<whitequark>
yep
egg|laptop|egg has joined #glasgow
<whitequark>
my first supply at the lower end of this scale (50W) took care of this issue, it is baffling that Agilent didn't
<electronic_eel>
maybe some cost-cutters came in and removed it from the todo list
<whitequark>
that seems like some extreme cost cutting
<whitequark>
half bridge drivers with integrated dead time are extremely cheap
<whitequark>
possible though, I guess
<electronic_eel>
maybe also a time-to-market thing? they wanted to go full-fpga but then they ran out of time and didn't have time to implement proper protection?
<whitequark>
I mean, some of my classmates in high school understood this, how come Agilent engineers didn't *start* with it?
<whitequark>
it's such a basic thing
<electronic_eel>
maybe they didn't really wrote the gateware, but just clicked together some autogenerated ip blocks. and their codegen didn't offer an option for this or something
<whitequark>
we're back to incompetence
<tmbinc>
it has a stage 1 switching regulator, and after that a linear stage 2
<tmbinc>
so it shorts the 48V input to the stage1, and the 48V are monitored, so they quickly shut off
<tmbinc>
so "explode" is not literal, but you need to replace the FETs
<whitequark>
i see
feldim2425_ has joined #glasgow
<tmbinc>
They have ~3 (4 if you count the eload) different designs, in different configurations
feldim2425 has quit [Ping timeout: 260 seconds]
feldim2425_ is now known as feldim2425
<tmbinc>
some of them are low-end-ish (like the one I've tested with), some are mid- to high-end
<tmbinc>
or example they have 4 quadrant SMUs, which are pretty cool
<tmbinc>
the nice thing is that they sample I/V every few 8us or so, and you can update the setpoint at the same frequency
<tmbinc>
the output stage is usually not that fast (except for the SMUs) though
<tmbinc>
an example app note is playing a wave file into a speaker :)
<electronic_eel>
how do they do the galvanic isolation? does every module connect to it's own isolated 48v input or does the module do the isolation itself?
<electronic_eel>
whitequark: isn't eliminating completely unused functions usually job of the linker?
<electronic_eel>
my naive idea of what a linker does suggests that this shouldn't be a too complicated operation
<whitequark>
electronic_eel: sdcc won't even eliminate dead static functions, which is uncharacteristically bad for a compiler
<whitequark>
as for the linker, linkers can only eliminate dead functions if you build with -ffunction-sections
<whitequark>
and sdcc's binutils are so primitive that this isn't even a thing
<whitequark>
it's really, really, really dumb for a toolchain
<whitequark>
it's one of those compilers about which the GCC docs say that you should not use defines anymore, because gcc (unlike those old compilers) can inline functions
<whitequark>
*not use defines for performance
<whitequark>
well, sdcc is actually newer than gcc, but it's ancient in spirit
<tmbinc>
electronic_eel: every module is isolated; the 3 IO lines are opto-coupled, the 48V go over a transformer
<tmbinc>
I mean, every module isolates itself
<electronic_eel>
ok, i was assuming that this kind of optimization was kind of a given for current toolchains. seems like this was a wrong assumption then.
<whitequark>
sdcc is only current in the sense that it is still maintained
<whitequark>
it is the single most primitive production compiler i've ever worked with
<whitequark>
its only advantage is that its internal data structures are actually well suited for 8051
<whitequark>
ok, and it actually implements new standards like C11, which is much better than the norm for this sort of device
<whitequark>
you sometimes have to do things like invert loops or rearrange variables to improve its codegen
<electronic_eel>
tmbinc: so if each module isolates itself, do they really use a 48v-to-48v isolator, a buck afterwards and then a linear reg? that seems like a strange architecture to me. I'd probably have combined the isolation and buck in one part.
<whitequark>
(it is only occasionally able to change the loop so that djnz will be used)
DarthCloud has joined #glasgow
DarthCloud has left #glasgow [#glasgow]
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
feldim2425 has quit [Ping timeout: 260 seconds]
feldim2425 has joined #glasgow
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #glasgow
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #glasgow
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #glasgow
feldim2425 has quit [Quit: ZNC 1.8.x-git-91-b00cc309 - https://znc.in]
feldim2425 has joined #glasgow
FFY00 has quit [Read error: Connection reset by peer]
FFY00 has joined #glasgow
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #glasgow
FFY00 has quit [Ping timeout: 268 seconds]
FFY00 has joined #glasgow
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #glasgow
FFY00 has quit [Read error: Connection reset by peer]
FFY00 has joined #glasgow
GNUmoon has quit [Remote host closed the connection]
nicoo has quit [Write error: Broken pipe]
nicoo has joined #glasgow
FFY00 has quit [Quit: dd if=/dev/urandom of=/dev/sda]
FFY00 has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
<_whitenotifier>
[GlasgowEmbedded/glasgow] electroniceel pushed 2 commits to wip-revC2-firmware [+0/-0/±6] https://git.io/JLSZx
<_whitenotifier>
[GlasgowEmbedded/glasgow] electroniceel c48983d - firmware: handle voltage alerts on revC2
<_whitenotifier>
[glasgow] electroniceel synchronize pull request #242: Bring revC2 firmware to the same level as revC1 - https://git.io/JInii
<_whitenotifier>
[glasgow] electroniceel commented on pull request #242: Bring revC2 firmware to the same level as revC1 - https://git.io/JLSZh
<_whitenotifier>
[glasgow] electroniceel commented on pull request #243: firmware: switch the DAC off too when switching off Vio - https://git.io/JLSne
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has quit [Remote host closed the connection]
GNUmoon has joined #glasgow
GNUmoon has quit [Ping timeout: 240 seconds]
egg|laptop|egg has joined #glasgow
GNUmoon has joined #glasgow
DarthCloud has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
<eddyb>
hmm, what would be the easiest way to confirm activity on a high-speed interface (like PCIe)?
<eddyb>
can I use the Glasgow directly to build a very basic indicator, or should I look at capacitors instead? (tho presumably it's hard to attach anything without murdering link quality)
<eddyb>
(if I had to guess, the smart way to do this is to have a MΩ resistor feeding into an opamp/comparator, and slap a capacitor on the end of that)
<eddyb>
or subsample with an ADC to build a really terrible eye diagram, but I don't have the hardware for that :P
egg|laptop|egg has quit [Read error: Connection reset by peer]