Jumper T8SG - First TX stock running on Deviation

I got reply from T8SG maker , this is their questions,



Translate to English as below,
1, About voice module,where can they get relative information about hardware.
2, They are preparing sample for FCC/CE verification but they got some trouble about frequency setting(I'm not really understand about this question)
3, Is it to register an account for they customer service person then they can reply something? (I will help them to register an Deviation account)
4, They are willing to cooperate with Deviation and produce a serial multiprotocol TX such as color touch screen etc. , how can they get Deviation authorization? what's the detail condition about authorization?

mwm wrote: I think they need to do two things in order to cooperate with us:

1. Get preproduction units to some of the developers here.
2. Have someone on these forums to get general feedback on them

Needs to happen preproduction so that the changes make it into production. And you can't really tell about things until they're in your hands. The developers should have the best feel for what's possible/coming, as well as a good feel for what the community wants.

Hi Mike,

1, How many developers need sample/prototype TX do you think? would you please give me a list? I can help to discuss with them.
2, I will help them to register a Deviation forum account for replying question and get feedback.

Thank you very much.

Holy moly this is amazing ! PhracturedBlue, mwm, goebish, midelic and everyone else who's ever worked on these a big thank you
It's all yours to customise

dc59 wrote:

Please post the google translate version of this (or just post/attach the utf text). Might help to figure out item 2.

Lots of information on the voice mod here . Here's a dfplayer datasheet .

It would be nice to have all unused mcu pins brought out to a pad or via for future experimenting. A stereo connector for the trainer port with both tx and rx i/o pins connected. I second the suggestion to make the gimbal mounting compatible with the taranis.

hexfet wrote: Please post the google translate version of this (or just post/attach the utf text). Might help to figure out item 2.

Lots of information on the voice mod here . Here's a dfplayer datasheet .

It would be nice to have all unused mcu pins brought out to a pad or via for future experimenting. A stereo connector for the trainer port with both tx and rx i/o pins connected. I second the suggestion to make the gimbal mounting compatible with the taranis.

Hi Hexfet,

Google translate version:
1. What kind of hardware support does the sound module add (with or without this tutorial)
2.FCC and CE certification issues, is preparing samples sent to the certification company (the current certification company needs remote control frequency, the default is the frequency hopping certification company that can not measure the transmission frequency power, the need for fixed high, medium and low Frequency)
3. Customer service in the Deviation Forum reply is a direct account can be registered?
4. We would like to be able to work with Deviation official, launched a series of multi-protocol remote control (such as follow-up color touch) cooperation or authorization required what conditions

Based on past testing with FCC for telecom I've a guess at item 2. For the lab testing they need the radio to have a test mode(s) to transmit at certain frequencies ("high, medium, and low"), possibly with a given power level (max possible, max allowed, etc), for a set duty cycle or other test parameters. For example my company had to provide a test program to stream "U" out all serial ports for FCC emission testing.

Can we get the requirements for the test modes that are needed? The certification company should have guidance on the things the equipment under test needs to do.

If they are talking colour touch screen, then the same body but using colour touch ala the Devo 6S would be awesome. That said, I reckon the body needs a little work, a bit grippier /more ergonomic etc.
Maybe a rotary encoder could be a good addition that they could work with the developers to implement, for more user-friendly non-touch nav?

dc59 wrote: 1, How many developers need sample/prototype TX do you think? would you please give me a list?.

From Github commits, the Most active developers are:

PhracturedBlue
Goebish
Vladislavy
F-D-R
Hexfet
mwm
Victzh (though I havent heard from him in a while)
And me (Moeder)

I hope I didnt forget anyone.

A cheap replica. No CE.
Deviation is a grey area.

I hope my radio will be shipped really soon ..... I think they want to work for future improvements .... I am pretty sure.
But this first radio.... is already really promising.... Now the FCC certification is another story for sure.

Moeder wrote: From Github commits, the Most active developers are:

PhracturedBlue
Goebish
Vladislavy
F-D-R
Hexfet
mwm
Victzh (though I havent heard from him in a while)
And me (Moeder)

I hope I didnt forget anyone.

Thanks Moeder! I have sent them the list , I will let you know their answer once I get reply form them.

im happy spending little more and enjoy my 10 with 4in1 without doubt. the only thing i like with this is the throttle spring that i yet modified on my devo 7 and gonna make on my 10

@Moeder

I just got reply from them , they will send sample TX to 8 developers on your list,
but they need your name , address , phone no. , mode 1 or 2 data, would you please
PM me those data? or if you want to contact them directly , I can PM you their e-mail.

And they just told me , T8SG used different LCD, they changed some code in lcd.c as below,

void LCD_Contrast(unsigned contrast)
{
//int data = 0x20 + contrast * 0xC / 10;
LCD_Cmd(0x81);
int c = contrast; //contrast should range from ~72 to ~200
LCD_Cmd(c);
}

void LCD_Init()
{
//Initialization is mostly done in SPI Flash
//Setup CS as B.0 Data/Control = C.5
rcc_peripheral_enable_clock(&RCC_APB2ENR, RCC_APB2ENR_IOPBEN);
rcc_peripheral_enable_clock(&RCC_APB2ENR, RCC_APB2ENR_IOPCEN);
gpio_set_mode(GPIOB, GPIO_MODE_OUTPUT_50_MHZ,
GPIO_CNF_OUTPUT_PUSHPULL, GPIO0);
gpio_set_mode(GPIOC, GPIO_MODE_OUTPUT_50_MHZ,
GPIO_CNF_OUTPUT_PUSHPULL, GPIO5);
LCD_Cmd(0xE2); //Reset
volatile int i = 0x8000;
while(i) i--;
LCD_Cmd(0xAE); //Display off
LCD_Cmd(0xA6); //Normal display
LCD_Cmd(0xA4); //All Points Normal
LCD_Cmd(0xEA); //??
LCD_Cmd(0xA0); //ADC Normal
LCD_Cmd(0xC8); //Common Output Mode Scan Rate
LCD_Cmd(0x2C); //Power Controller:Booster ON

FDR wrote: It would be nice to know the exact type of the LCD driver, and how we can detect it.That way we could include the detection, and add these differences dinamically.
Otherwise it would need a different target...

Hi FDR,
They mail me this file about LCD.

Moedder beat me to it. While the gitthub active list isn't perfect (some devs have gone inactive, and some just do pull requests), is about as close as your going to find.

You might pass on that the best way to submit change to deviation is through a pull request oh GitHub.

If the tx is going to need a new target anyways, would it be possible to use a bigger screen ? Looks nicer
And a more powerful processor if possible but I assume that will require a bit of hardware reshuffling.
The added processing power might be useful later on for things like lua scripts if they are implemented and so that Devs don't worry all the time about running out of flash

I agree with PB that a new target would actually be preferred to distinguish this from other builds for the mentioned reasons, and also to not further confuse end users.
Information on the boot loader used would be interesting, I suspect they used the devo7e boot loader code provided in the U7E instructions. I'm not sure this could impose legal complications for the manufacturer, as it is a Walkera development.
A possibilty to make firmware updates is a must have, first of all since the build they are using in the pictures (based on the commit hash) still has the buggy Mux delay code....

@dc59: I sent you a PM