Thanks for your explanation, there is indeed such an objective fact in China.
To clear up any confusion…
I have not given Convoy any special licenses. If this product ships without providing full source code, it will probably be a license violation, and Convoy would lose the right to sell anything based on my code.
Full details are in the license (translated: zh-cn, zh-tw).
It is not difficult to satisfy, and usually costs nothing. It is a “share and share alike” style license, meaning that anyone who distributes a compiled version (including derivatives) must also provide the complete source code for that same version, under the same license, retaining all the original copyright marks.
Usually people satisfy the license by doing the following:
- Publish a message somewhere prominent stating that the product uses copyrighted code released under the GNU Public License v3 (GPLv3).
- Include information about how to get the exact source code used in the product. If it is an unmodified version, a link to the upstream code works. Or if it’s modified, they must find a way to publish the version they used.
That info generally goes on the product page and/or in the included paper manual. Ideally both:
- The license applies to anyone who distributes the code in a compiled form, which includes companies who sell products based on the code. In other words, it applies to every vendor and reseller. So it’s a good idea to put the information in a printed manual which ships with the product, because that means the vendor doesn’t have to know or care about the license.
- Even if the license info is in the manual, it is also a good idea to include the license info on the original manufacturer’s product page too. This allows people to verify the license is being fulfilled, which means I don’t have to bother the manufacturers with messages like this one.
The concept of “trade secret” is completely incompatible with the concept of free software. The whole point is that nothing is secret — anyone can use it however they want, as long as they make sure the same freedom is passed on to others.
I will continue to communicate with the driver manufacturer
To clear up any confusion…
I have not given Convoy any special licenses. If this product ships without providing full source code, it will probably be a license violation, and Convoy would lose the right to sell anything based on my code.
Full details are in the license (translated: zh-cn, zh-tw).
It is not difficult to satisfy, and usually costs nothing. It is a “share and share alike” style license, meaning that anyone who distributes a compiled version (including derivatives) must also provide the complete source code for that same version, under the same license, retaining all the original copyright marks.
Usually people satisfy the license by doing the following:
- Publish a message somewhere prominent stating that the product uses copyrighted code released under the GNU Public License v3 (GPLv3).
- Include information about how to get the exact source code used in the product. If it is an unmodified version, a link to the upstream code works. Or if it’s modified, they must find a way to publish the version they used.
That info generally goes on the product page and/or in the included paper manual. Ideally both:
- The license applies to anyone who distributes the code in a compiled form, which includes companies who sell products based on the code. In other words, it applies to every vendor and reseller. So it’s a good idea to put the information in a printed manual which ships with the product, because that means the vendor doesn’t have to know or care about the license.
- Even if the license info is in the manual, it is also a good idea to include the license info on the original manufacturer’s product page too. This allows people to verify the license is being fulfilled, which means I don’t have to bother the manufacturers with messages like this one.
The concept of “trade secret” is completely incompatible with the concept of free software. The whole point is that nothing is secret — anyone can use it however they want, as long as they make sure the same freedom is passed on to others.
I got a reply.
Although the same function has been achieved, driver manufacturer does not use the existing open source code because of the different circuit principle. This circuit currently uses code written by the driver manufacturer itself.
Ok I will made some close up pictures with my Andonstar micro and will post them soon. But I think marks on micro and transistors was laser trimmed. Also from Convoy store listing we can see markings of transistors but the MCU is it without it. Also it have 10 pins compared to 8 pins of Attiny so the Biscotti firmware is most likely ported to another MCU family.
The component in this picture is MOS FET AON7524, I will announce the MCU model later.
RENESAS R5F10Y14/16 RL78/G10 ?
https://www.renesas.com/us/en/doc/products/mpumcu/doc/rl78/r01ds0207ej0310-rl78g10.pdf
Although the same function has been achieved, driver manufacturer does not use the existing open source code because of the different circuit principle. This circuit currently uses code written by the driver manufacturer itself.
I earlier asked if it’s the same “Biscotti” driver (as used in the Convoy C8+ with Biscotti firmware).
Based on this explanation, the SST40 “Biscotti” is not the same “Biscotti” but “something similar function”.
I’m curious then, would it also have the same 12- mode groups, enable/disable mode memory? Or maybe just “something similar” in concept?
Would be good if someone has already gotten the “SST40-Biscotti” driver and put it to the test.
(As of the moment, our country is in lockdown, so most overseas sellers have stopped shipping to our country for a full month now and may still not be able to do so in another 2 weeks…) [eg. Banggood says “No shipping method available” for ALL products now, whereas before, only “pure battery products” have “No shipping method available”]
HT45F3420 10-pin MSOP
So it’s a Biscotti clone, but not Biscotti. And given that information is being withheld, I can’t modify it and flash my own version like I’ve been able to with Biscotti (custom modes etc).
Thanks, no thanks.
(I’d strongly suggest using another name - even “Biscuit (Biscotti-clone)” or similar. Because it’s not the same firmware.)
So it’s a Biscotti clone, but not Biscotti. And given that information is being withheld, I can’t modify it and flash my own version like I’ve been able to with Biscotti (custom modes etc).
Thanks, no thanks.
(I’d strongly suggest using another name - even “Biscuit (Biscotti-clone)” or similar. Because it’s not the same firmware.)
I agree. Knowing whether we can use our own customized variants is a big deal and re-using the name may mislead people to think that it’s possible.
Simon Mao:Although the same function has been achieved, driver manufacturer does not use the existing open source code because of the different circuit principle. This circuit currently uses code written by the driver manufacturer itself.
I earlier asked if it’s the same “Biscotti” driver (as used in the Convoy C8+ with Biscotti firmware).
Based on this explanation, the SST40 “Biscotti” is not the same “Biscotti” but “something similar function”.
I’m curious then, would it also have the same 12- mode groups, enable/disable mode memory? Or maybe just “something similar” in concept?
Would be good if someone has already gotten the “SST40-Biscotti” driver and put it to the test.
(As of the moment, our country is in lockdown, so most overseas sellers have stopped shipping to our country for a full month now and may still not be able to do so in another 2 weeks…) [eg. Banggood says “No shipping method available” for ALL products now, whereas before, only “pure battery products” have “No shipping method available”]
i have no difficulty with delivery to Philippines.
Even mailing a mask is no problem.
the function is the same instead of “similar”
So it’s a Biscotti clone, but not Biscotti. And given that information is being withheld, I can’t modify it and flash my own version like I’ve been able to with Biscotti (custom modes etc).
Thanks, no thanks.
(I’d strongly suggest using another name - even “Biscuit (Biscotti-clone)” or similar. Because it’s not the same firmware.)
This was my mistake. At first, I thought that the driver manufacturer used the biscotti code. Later, I realized that it was the code he wrote himself.
I havent given a name to this, so simply call it 12 groups sst40 driver
No probs Simon - we can all get blindsided.
d_t_a:…
Based on this explanation, the SST40 “Biscotti” is not the same “Biscotti” but “something similar function”.
…
Would be good if someone has already gotten the “SST40-Biscotti” driver and put it to the test.
……
the function is the same instead of "similar" :-)
Smells like surströmming, sorry to say.
So who is going to dump the MCU's code?
I did notice a difference with mine but wasn’t sure if it was just a quirk with my build (used it in a photo red triple). When set to the five mode group, there seems to be a large jump between modes 2 & 3. My other Biscotti drivers have very linear mode spacing. Not really a complaint, just an observation.
I have a quirk in a 20mm “SST40” driver that I recently bought from your AE store. Between modes 1 and 2 there is a bright “pre-flash”. Is this normal? Anybody else experiencing this? It’s installed in an S21a running a triple XPL_HD from an LG M50.
Simon, what’s the order code (or at least CRI bin, the 16th digit which can be B, H, or U) for the XHP35 HI 4000K B4-40E?
Simon, what’s the order code (or at least CRI bin, the 16th digit which can be B, H, or U) for the XHP35 HI 4000K B4-40E?
I asked this to Simon nearly two weeks ago via message in AliExpress. I told him that, according to datasheet, a B4-40E should be U CRI code or CRI90+, whereas the D2-1A (6500K) should be H CRI code or CRI80+. Simon replied “uh, sorry, the LED I sell is not high CRI LED”. Confusing, I know.
I did notice a difference with mine but wasn’t sure if it was just a quirk with my build (used it in a photo red triple). When set to the five mode group, there seems to be a large jump between modes 2 & 3. My other Biscotti drivers have very linear mode spacing. Not really a complaint, just an observation.
I have a quirk in a 20mm “SST40” driver that I recently bought from your AE store. Between modes 1 and 2 there is a bright “pre-flash”. Is this normal? Anybody else experiencing this? It’s installed in an S21a running a triple XPL_HD from an LG M50.
This may be caused by a high internal resistance somewhere, or it may be a driver problem.
oweban:So it’s a Biscotti clone, but not Biscotti. And given that information is being withheld, I can’t modify it and flash my own version like I’ve been able to with Biscotti (custom modes etc).
Thanks, no thanks.
(I’d strongly suggest using another name - even “Biscuit (Biscotti-clone)” or similar. Because it’s not the same firmware.)
This was my mistake. At first, I thought that the driver manufacturer used the biscotti code. Later, I realized that it was the code he wrote himself.
I havent given a name to this, so simply call it 12 groups sst40 driver
So, to amend the mistake, the post title should be changed… or not?
Tldr;
So, is it possible to buy s21a with biscotti?