Forgot your password?
typodupeerror

Comment: Re: Better solutions (Score 1) 46

by fuzzyfuzzyfungus (#48230827) Attached to: A Low Cost, Open Source Geiger Counter (Video)
Would you be able to compensate for poor linearity with a hybrid approach involving a silicon detector and a layer of one of the formulations used in scintillation counters?

I'm thinking by analogy to the approach for making 'white' LEDs: the output of the LED alone is atrociously unsuitable, so you add a phosphor blob that absorbs some of the output and emits at enough other energy levels to fill in something resembling actual white light.

Would a silicon detector, with a layer of scintillation material chosen for good performance in areas that the silicon doesn't cover applied on top, potentially provide a more adequate result?

Comment: If you are planning on dropping them... (Score 1) 46

by fuzzyfuzzyfungus (#48224881) Attached to: A Low Cost, Open Source Geiger Counter (Video)
Does radiation detection(with actual accuracy, linearity, and repeatability, not just a quick demonstration that you can add some noise to a webcam by pointing a small sealed source at it) have currently good, or at least promising for the not too distant future, solid state options?

I'd imagine that for cost, robustness, and duration on battery power, the presence of little gas filled tubes, some with fairly delicate internal structure, that require a high voltage power supply is a necessary evil at best. In the case of a scintillation counter, the photomultiplier tube would be a similar headache.Are there better behaved options?

Comment: Re:Counterfeiters not competitors (Score 2) 536

FTDI didn't choose that specific value(though, thinking back to Intel's amusing choice of '8086' as their PCI vendor ID, you probably can choose a VID if you push hard enough or have a cute reason); but there are still some commonalities(though arguably some differences as well):

The USB spec (and, probably more importantly, USB as implemented on basically all commercially relevant systems) supports essentially two mechanisms for telling the OS what driver your device requires:

If supported by a generic class driver; your device descriptors include a bDeviceClass field containing a defined USB device class code; but isn't 0xFF(which is valid; but means 'vendor defined'), a bDeviceSubClass field with a valid subclass code, and a bDeviceProtocol field with a valid protocol code.

If your device is supported by a specific driver(or one of the hybrid arrangements, not uncommon, where a versatile device class like USB HID will be used to do most of the low-level work; but a vendor-specific driver will implement whatever device specific behavior is offered on top of that), then you need to supply the correct VID/PID combination.

Now, let me be clear, I see absolutely no reason why FTDI should need to provide driver support for clones, so even if Windows(correctly, as an OS) responds to a USB device with an FTDI VID/PID by loading the FTDI driver, it is fully within their rights to have a driver that detects and ignores non-FTDI parts.

However, (and this is where the analogy to consoles and trademarked-but-technically-necessary really comes in), the USB spec does not offer a 'compatible with VID/PID' device description option. Either you specify the appropriate generic class, or you specify a VID/PID and a vendor-specific class. There is no other way (barring atypical configurations and kernel hacker tricks that aren't of much use in the wider world) to do it.

If you want a Game Boy or whatever to load your cartridge, you need that logo to be present at the appropriate address. If you want to specify "I need the driver that supports device X", you have to supply device X's VID/PID. There is no 'compatible with device X; but actually made by me' mechanism.

If you are buying fake FTDI gear to take advantage of FTDI's driver devs, then I have no pity. Not FTDI's problem to support you. However, there are 3rd-party FTDI-device-supporting drivers (notably on Linux and BSD, maybe somebody has ported one to Windows or OSX, maybe you plan to implement your own, whatever) that it would be perfectly legitimate for an FTDI-compatible device to request, and (so long as it doesn't involve copyright or patent infringement, or fraudulent misrepresentation) there are perfectly licit non-FTDI chips that implement FTDI-compatible behavior. The USB-IF certainly doesn't have enough power over short hex values to stop that; and I'm not convinced that we would want them to.

A large number of now standard or semistandard devices, protocols, and command sets we don't even think about today started life as dirty clones of the more popular brand: The PC BIOS, the (still spoken, in extended form, by a moderately alarming number of things) Hayes command set, the 16550 UART (originally a National Semiconductor model number; now register compatibility with those is practically a standard in itself, thanks to about a zillion clones), the NE1000/2000-compatible NICs that helped make ethernet ubiquitous and cheap...

Again, FTDI has every right to make the use of their drivers contingent on the use of their ICs (or some other licensing terms, if that amuses them). Also, non-FTDI parts being sold (with varying degrees of sophistication, from pure nonsense to nearly perfect fakes) as FTDI is a bad thing. For FTDI, for the buyer being defrauded, for the electronics supply chain generally.

However, we would not be well served to be blinded to the (generally desirable and helpful, as much as incumbents dislike them) history of 3rd-party interoperable parts by lumping all of them in with 'counterfeit' parts and taking measures that make it easier to suppress them, and easier for 'counterfeit' to mean 'compatible with someone who doesn't want you to be compatible with them' rather than to mean 'based on illicitly copied designs and/or sold under fraudulent label'. These are two very different things.

Comment: Re:Counterfeiters not competitors (Score 1) 536

They could make the argument; but I'm not sure that they could win it.

It is widely accepted that you can use a protected mark, so long as you don't do so deceptively, to provide information about your product(the usual formulation is "Store brand product, compare to Product(tm) active ingredients). Not a trademark violation, even if the trademark holder might not like it; just telling the customer what your product is intended to be compatible with.

In computing applications, since the data are usually being sent to an (often inflexible and buggy) program rather than to a human, and since identifying information is often necessary for operation, even more blatant use is often accepted. Most browsers still claim to be "Mozilla/5.0" followed by a bunch of other stuff, often equally trademarked and equally false, because that particular string was the only way to get the correct output from assorted crufty HTTP servers. In more adversarial cases, like Lexmark's battle with Static Control Components over toner lockout chips, SCC ended up being allowed to duplicate an even larger chunk of Lexmark's firmware, over Lexmark's objections; because that was deemed a technically necessary part of producing an interoperable toner cartridge.

The USB VID/PID is conceptually in a similar position to the browser UA: it's not hard to find; but not really there for human readers and subject to fairly specific technical limitations if you actually want it to work. "0x0403" is a valid VID. "0x0403 (compatible; China Cloneshop)" is not. It won't even work, much less request the correct driver. USB does provide for purely descriptive, human readable, information fields ('Manufacturer String Descriptor', 'Product String Descriptor', and 'Serial Number String Descriptor') and those aren't subject to technical constraints.

I certainly wouldn't want to be on defense if I were selling a product with somebody else's trademark misused in the string descriptor fields; but the VID/PID would be much more defensible.

Comment: Re:Alternatives? Same problem.. (Score 1) 536

In this case, it is not questionable at all. They don't have any right to use the vendor ID (VID) assigned to FTDI.

Why not? The USB IF won't be happy about it, and not being able to trust VID/PID pairs makes driver devs sad and prone to resort to ugly fingerprinting heuristics; but none of that establishes a legal monopoly on "0x0403" for FTDI.

Comment: Re:Counterfeiters not competitors (Score 3, Insightful) 536

That isn't actually so clear:

According to the die shots, the clone chips' implementation is more or less entirely different from the FTDI implementation. Intended to be pin-compatible, and exhibit the same behavior; but totally different silicon, not a cut and paste job.

The clones that are then labelled and sold as 'FTDI' are, certainly, in all kinds of violation of trademark law; but what of any that are just blob-topped or generically packaged and not represented as being actual FTDI? Not something FTDI likes, or is obliged to provide driver support for; but neither was the Compaq 'IBM PC compatible' BIOS.

Even if the (typically very harsh, though widely unenforced) laws regarding trademark infringing goods do actually allow FTDI to brick them in the field, they haven't actually established that a given chip is a counterfeit, rather than a mere clone, before bricking it. Unless they wish to claim that "0x0403" is entitled for trademark protection, the driver is hardly in a position to distinguish between the two.

Comment: Must have been a fun conference call... (Score 3, Insightful) 536

I can only imagine that the lucky guy who picked up the call from Redmond about 'so, we understand that you...made a few changes...to the behavior of your WHQL drivers that frankly don't make Windows Update look very good...' got quite an earful.

Even if MS thinks FTDI is on the crusade of the righteous, it certainly isn't to their advantage to have Windows Update involuntarily pulled into the fiasco.

Comment: Re:Performance issues? (Score 1, Insightful) 168

Unless you are the sort of disconcertingly disciplined and organized person who sets up a monitoring and alerting system for their dinky little desktop, you probably aren't talking about 'the hard drive'. At a minimum, you are probably dealing with some flavor of RAID, or ZFS, or an iSCSI LUN farmed out by some SAN that does its own mysterious thing behind the expensive logo, or some other additional complexity. Flash SSDs are also increasingly likely to be involved, quite possibly along with some RAM caches in various places.

Comment: Re:Not "bricked" (Score 1) 688

by fuzzyfuzzyfungus (#48206603) Attached to: FTDI Reportedly Bricking Devices Using Competitors' Chips.
According to the eevblog report, the newest driver behavior involves reprogramming the USB PID of the target to 0, not merely refusing to do useful work with it.

Quite likely recoverable with some knowledge, unless it managed to close the door behind it on any future PID modifications; but munging a USB device's PID is definitely a step above simply refusing to talk to it.

Comment: Re:Is it legal to make code compatible alternative (Score 1) 688

by fuzzyfuzzyfungus (#48206547) Attached to: FTDI Reportedly Bricking Devices Using Competitors' Chips.
It is quite likely that the counterfeiters(at least the ones that actually stamp 'FTDI' on their products, or represent them as FTDI parts, I'm unconvinced that a VID:PID pair is a trademarkable thing) are committing 36 flavors of trademark infringement; but that still doesn't make it obvious that FTDI can just go all vigilante justice on them(much less on random people who may or may not know they were even using counterfeit chips).

Even when something is clearly recognized as a crime, the courts tend to take a somewhat dim view of those who go and dish out some extrajudicial punishment for it (typically with exceptions for things like self defense). Even when the law specifically defines transgressions that create a private right of action, the 'action' usually involves getting to sue the target, not take matters into your own hands.

Comment: Re:They are playing with fire (Score 1) 688

by fuzzyfuzzyfungus (#48206431) Attached to: FTDI Reportedly Bricking Devices Using Competitors' Chips.
A certain amount may end up riding on the meaning of 'component' and 'that component', as well. Sure, for a basic USB -> serial dongle the FTDI chip is practically the only component, with just a couple of cheap connectors and a passive or two; but there are some fairly expensive devices that are 'USB' because the manufacturer shoved a converter IC onto the previous generation serial design.

Even if FTDI finds a court that buys their right to destroy cloned chips by vigilante action(rather than by a copyright, patent, or trademark judgement in the appropriate venue), will they find one that is sympathetic when the device ruined is some fairly expensive bit of gear sold by a third party to a customer who didn't even know a USB bridge chip was involved?

Comment: Re:Why is FTDI the villan? (Score 2) 688

by fuzzyfuzzyfungus (#48206379) Attached to: FTDI Reportedly Bricking Devices Using Competitors' Chips.

As an EE, I will think twice about designing in FTDI products from now on.

Even if you happen to think that FTDI's approach is morally justified and hilarious, it'd still be worth considering avoiding them: some counterfeits don't even bother to pretend; but there are some very, very, convincing fakes that manage to sneak into more respectable parts of the supply chain. It's bad enough that you might get slipped counterfeits that don't meet spec, worse if you might get slipped counterfeits that appear to work and then get destroyed once in the hands of your customers.

You are in a maze of UUCP connections, all alike.

Working...