Jumper T8SG - First TX stock running on Deviation

FDR wrote:

dc59 wrote: Thanks FDR!!
But I can't find Jumper in Development.

Because you are not a developer.
Do you wanna be?

No wonder! It's truth， I'm not developer ！
No need to put me in before Jumper want me in.
Thanks a lot.

I think it is reasonable to include dc59 in the developer list - he's helping with communication a lot.

BTW, I can see the Jumper category.

Thanks victzh & FDR , I have posted some documents already.

I hope it's not too cloak and dagger and you keep us little guys updated with info. It's been really interesting seeing the progress you guys have made

yets wrote: I hope it's not too cloak and dagger and you keep us little guys updated with info. It's been really interesting seeing the progress you guys have made

Don't worry about this, I will keep update info. here.

mwm wrote:

fneuf wrote: Were it could be seen as becoming tricky here, and I think that's what Iroquois is implying, is that Jumper is the only one to make money out of this product (again if I'm initial statement is not proven wrong),.

Again, that's the way open source works. The point of releasing something as open source is to let other people freely derive benefit form your work. TBH, most people simply use it, and don't contribute anything back to the community. Some more conscientious people will try and help others, write docs, make videos, etc. I think they're the smart ones, because that helps the community grow, and a larger community means you're more likely to get that third class of person: those who can contribute code. Not that docs etc. aren't important and appreciated, but more people can contribute those than can contribute code. This is all that jumper is doing, but that they (and the storefronts they use, etc.) are benefitting financially annoys some (maybe a lot) of people. They aren't the first to do this: all the variations of the 4-in-1 modules that either ran deviation protocols or only worked with deviation, and even the folks who advertised RF modules as "for deviation" all benefitted financially from our work, but nobody seemed annoyed about them.

Bottom line, if you don't want to let other people make money off your work, you don't release it under an open source license, and you don't contribute that work to open source projects.

To wax philosophical, this objection to financial benefits is deep-rooted. Before there was a GPL and an FSF, a lot of "free" software was released with some kind of "not for commercial use" clause. Some even did the "Released to the public domain. Not for commercial use." (sorry, no: releasing something in the public domain gives up your right to say how it's used, and that second sentence might as well not be there). I think this has a lot to do with why the GPL became so popular compared to other licenses: the alternatives at the time (MIT, BSD, etc.) made no bones about allowing commercial use, whereas people incorrectly assumed that the GPL disallowed that. The FSF and RMS have no fault here - they went out of their way to explain that commercial use was fine, you could charge whatever you wanted for your product (but were restricted to "reasonable" shipping and handling fees for the sources, which IIRC they charged $150 for), but you had to share any improvements you made with the community.

Deviation is licensed under the GPL, so is open to such commercial use. Not that it hasn't been pirated: for months the multi-module project was distributing deviation-based software in violation of the license. But since they were only violating the intent and spirit of the license and not making money in the process, very few people cared.

I was clumpsily trying to set the scene, closed product development vs open one. You made it way clearer than me with much more details and facts that I could give.
Thanks for the clarification, I think it was important to state that here for further references, if needed.

Hi
Do I have to make changes to the ini file for oprating Sw9 and Sw10
I have in my T8SG the t8sg-v5.x.x-217-10-05
Thanks

Ok
Thank you

I have in my T8SG the t8sg-v5.x.x-217-10-05
It looks that the ini file that in my Tr is configed to the extra 2 additionl switche , is it ok?

Hall sensor gimbals upgrade kit for DEVO passed final test , users just need to remove stock gimbals VR and install this hall sensor , calibrate stick ! done !

dc59 wrote: Hall sensor gimbals upgrade kit for DEVO passed final test , users just need to remove stock gimbals VR and install this hall sensor , calibrate stick ! done !

Very nice! I'm not interested in Jumper T8SG, but will definitely purchase the hall effect gimbals for the 7e once they're available. dc59, thanks for keeping us informed on the progress.

phantom8 wrote:

dc59 wrote: Hall sensor gimbals upgrade kit for DEVO passed final test , users just need to remove stock gimbals VR and install this hall sensor , calibrate stick ! done !

Very nice! I'm not interested in Jumper T8SG, but will definitely purchase the hall effect gimbals for the 7e once they're available. dc59, thanks for keeping us informed on the progress.

THIS. This is fantastic news. Thanks for pushing for this guys. There'll be a lot of happy Devo users

fneuf, I wasn't trying to imply anything. I just don't understand why people are trying to make the two transmitters identical. If you take the T8SG as a standalone product, there's nothing wrong with it.

Iroquois wrote: fneuf, I wasn't trying to imply anything. I just don't understand why people are trying to make the two transmitters identical. If you take the T8SG as a standalone product, there's nothing wrong with it.

Who is trying to make it identical? The hardware is based on the devo 7e, there isn't really any difference already just a couple of quirks with the T8SG that need improvement.

Iroquois wrote: fneuf, I wasn't trying to imply anything. I just don't understand why people are trying to make the two transmitters identical. If you take the T8SG as a standalone product, there's nothing wrong with it.

But it's not a stand-alone product. It's part of the deviation ecosystem, and beyond that the world of hobby-grade transmitters. While some of the choices in those communities are arbitrary - and deviation is flexible enough to "fix" differences - where the community has agreed on one of the arbitrary choices, doing things the other way varies from annoying to hazardous to your craft.

hexfet wrote: I don't think the reference source is changeable in software for the F103. According to the datasheet in the 64-pin package it is hardwired to Vdd.

Don't see anything obvious looking at the code. I'll test with my tx this week.

Just to confirm what others have said, the battery voltage measurement depends on the CPU Vdd input voltage. The measurement is not accurate when the CPU input voltage is too low. The attached file shows the CPU supply voltage (Vdd) and displayed battery voltage as the battery voltage falls. This is based on measurements from my T8SG.

@hexfet - Very useful plots! The plots show that the 3.3v supply to the RF chips is dropping 1:1 with any further drop in supply voltage beyond the bend in the curve. I think everyone who realizes this will see the main priority needs to be to fix the hardware to keep the 3.3v supply in regulation throughout the useful battery voltage range. Once this is done the existing s/w will provide an accurate battery reading. I think Jumper knows something needs to be done since some of their first questions were about better low dropout voltage regulators.