Advanced Search

propnut wrote: Download Deviation Uploader-0.9.0 from www.deviationtx.com/downloads-new/category/161-dfu-usb-tool
Open the software and then connect your radio to your PC using the USB cable. Then just touch the power button for a fraction of a second literally. You should get a USB symbol on the screen. The program should detect the radio as a devo 7E. If so then use the program to upload the latest nightly build for the T8SG V2 Plus.

I will try this despite the fact that usb seems to not be recognised by windows

Even if you don't get the USB symbol see if the program sees the radio. If so still try the software upgrade.

no usb detected at all . As you can see (from the video) it seems like the cpu tries to boot -maybe I can try to load bootloader+code through stm32 programming pins (?) maybe? but i cannot find a way.

I will try to check if usb port circuit is connected to cpu (STM32F103). I hope cpu doeas not wait to detect rf module or lcd -in order to boot- as these are diconnected from the pcb.

mangmeephol wrote: This capacitor you can check have how much capacity? I am check this capacitor check no have capacity.

That is noise bypass cap, there will be 0 volts across it. You will need to remove it from circuit and use capacitance meter to check capacitance value but it will be good. No problem there.

Will look at my tx.

www.deviationtx.com/forum/search?query=d...te=all&childforums=1

Part of 8s power circuit can be found in above link.

No have burn in circuit. But VDD. Output 2.08v. Only

Hello to all,

i recently launched myself into a first foray into drone building and have been stumped ever since i finished putting together my first configuration.
I am trying to bind a T8SG V2 (which has the A7105 included with no added module) with the V911 2-servo PCD circuit to control elevator flaps and motor.
The problem is that when i turn on the transmitter after plugging the battery into the v911, the red light never achieves a solid red, it maintains a slow blinking, despite a beep from the transmitter after the 3 second binding process.

I have included the required parameters in hardware.ini and tx.ini and tried a model configuration found on this forum (all data below).

I am completely stumped at this point and would appreciate any help/indication!!!

Cheers,

Nic

Hardware.ini:
;Only useful for transmitters with an after-market vibration motor
;enable-haptic=1
;
;switch_types: 3x4, 3x3, 3x2, 3x1, 2x8, 2x7, 2x6, 2x5, 2x4, 2x3, 2x2, 2x1, potx2, potx1
;May occur more than once if necessary.
;Add nostock if stock FMOD and HOLD switches have been removed.
extra-switches = nostock
extra-switches = 3x4
extra-switches = 2x2
extra-switches = potx2
;
;Audio player connected to UART (Devo12/S internally, others via trainer port): audiofx, dfplayer
;voice=
;
;Enable if audio device is wired to uart5 instead of ppm on devo7e-256
;voice-uart5=1
;
;button_types: trim-all, trim-(left|right)-(up|down|both)
;May occur more than once if necessary.
;extra-buttons=
;
[modules]
; there is no need to enable the cyrf6936 module unless
; it is wired to an alternate port. It is Enabled automatically otherwise
; enable-cyrf6936 = B12
; has_pa-cyrf6936 = 1
enable-a7105 = A13
has_pa-a7105 = 1
enable-cc2500 = A14
has_pa-cc2500 = 1
enable-nrf24l01 = A15
has_pa-nrf24l01 = 1
; enable-multimod = A13

tx.ini:
current_model=5
language=0
music_shutdown=0
mode=1
brightness=7
contrast=6
volume=2
audio_vol=1
vibration=1
power_alarm=0
batt_alarm=4100
batt_critical=3900
batt_warning_interval=30
splash_delay=35
[modules]
enable-a7105=A13
has_pa-a7105=1
enable-cc2500=-0
has_pa-cc2500=0
[calibrate1]
max=4064
min=2
zero=1987
[calibrate2]
max=4095
min=178
zero=2208
[calibrate3]
max=4095
min=56
zero=2064
[calibrate4]
max=4033
min=5
zero=2062
[calibrate5]
max=4095
min=0
zero=2889
[calibrate6]
max=4095
min=0
zero=1575
[autodimmer]
timer=40000
dimvalue=0
[countdowntimersettings]
prealerttime=30000
prealertinterval=10000
timeupinterval=10000
[telemetry]
temp=celcius
length=meters
alertinterval=15

ramunas wrote: @Fernandez - As I was dealing with the batt too low message on the T8SG, I had to go into tx.ini with Notepad++ and edit batt_critical=3900 to a much lower value to keep that warning from coming up. I am flying with batt_critical=2800 right now. Also I did observe that you cannot set batt_alarm to anything below 3300 using the transmitter menu buttons, but again using Notepad++ to edit tx.ini works. I was able to lower batt_alarm to 3volts by directly editing batt_alarm=3000. Note that the batt_critical low value will keep the warning message from coming up, but on the T8SG the power down configuration save will still fail for voltages below 3.8 or 3.75volts. To get around that you need to modify the 560K-560K ohm voltage divider. 240K-560K ohms works for me and allows the T8SG configuration save to work to something below 2.8volts, consistent with the batt_critical that I am using.

Myself I have U7E, but it is moreless identical to the jumper. I use direfctly a single pololu step up step down 3v3 regulator connected to two 18650 liion in parallel.
The batteries I connected them to this module to charge and protect the cell against overcharge and discharge.
www.banggood.com/5Pcs-USB-Lithium-Batter...tml?cur_warehouse=CN
The module input I soldered to the USB 5V line and I charge my U7E via USB port.

Indeed it is required to edit and lower the, batt_critical=2800 overall TX works very well.
Oh and I also bypassed the input diode in my U7E power circuitry, so no more loss voltage drop due to that. and I lowered the resistor as described here above to save at shut down.

ramunas wrote: I have experimented replacing the original hi-dropout voltage 3.3v and 5v linear regulators with Pololu up/down 3.3v and up 5v switching regulators on 4xAA Eneloops or 1x18650 Li-Ion battery. The goal was to keep the power shutdown and save circuitry untouched. No problems with the 4xAA in this setup (no surprise since the Walkera 7e circuitry was designed for 4xAA). With the single 18650, the Pololu regulators work well maintaining the 3.3v and 5.0v through the full range of battery voltage 4.2 - 3.0v, and therefore the system operates fine until shutdown. At shutdown the original hardware circuitry succeeds in saving model changes only for battery voltages above 3.8v. Below 3.8v there are no model change updates at shutdown regardless of the batt_critical voltage setting. Looking at the power shutdown circuitry, the 560K - 560K voltage divider at mcu pin A3 seemed to be a likely cause. As battery voltages drop below the design voltage, it is reasonable that A3 will at some point not have enough positive signal to trigger the shutdown save operation. So I reduced the 560K between A3 and J1 switch pin1 to 240K, and the shutdown save now works fine down to 2.8v. With that it seems possible to have a single 48gram Li-Ion cell provide 3000+mah. The reduced weight is nice. Note that 4 Eneloops in a Walkera battery holder are around 125grams.

I have a series of pictures to help clarify the text description above. The voltage regulators are all on the back side of the main board, so you have to disconnect enough to at least flip the board over.

There is plenty of flat space to attach the Pololu switching regulators above the stock linear regulators which I removed. I wired the Pololu's as follows:

I taped the Pololu's in the orientation shown so the wiring is clearly identifiable. The 5v step-up regulator is item #2564, and has a designation U1V10F5. The 3.3v Step-Up/Step-Down is item #2122, and has a designation S7V8F3. The Pololu's connect to 4 lands on the back of the main board as follows:

I found the removal of the stock first batch regulators took more heat than I expected, so be prepared and careful not to remove other components in the area. I left the SHDN on the 3.3v Pololu floating since the VIN already incorporates the 1-2 second power extension at shutdown for configuration saves. If your goal is just to use 4xAA Eneloops or something similar, then this is all you should need to do. A batt warning at 4.4v or so should be fine. The Pololu's will maintain the 5v and 3.3v over a battery range of 5.8v down to at least 3v, which also covers essentially the full useful range of single Li-Ion cells.

If you want to use a single cell Li-Ion there is an additional problem (failure to save configuration at shutdown for voltages below 3.8v) that needs to be cleared as discussed above. The solution that worked for me was to modify the voltage divider going to MCU pin A3:

This increases the drive to pin A3 and allows configuration save at least down to 2.8v in my unit. The location of this resistor on the main board is as follows:

A picture of my board with the parallel jumper resistor approach:

I am using this now with a batt-warning of 3.3v and a batt-critical of 2.9v. I would really plan to lower the batt-warning to 3.1v, but the Deviation user interface wont allow it to be set below 3.3v at the moment. At some point I will try to edit the Tx.ini file as a workaround, but it will take a long time for my Li-Ion cell to get down to those voltages. I just want to add that anyone trying this should continue to treat it as an experiment. I like the way it works, but until there are more users that try it out, there can easily be additional issues that may show up.

Fernandez wrote: This is indeed of interest, I had problems I could not switch of anymore the TX at low voltage, can you confirm the battery monitoring still works fine doing this mod? Btw a vbat calibrate parameter scale and offset, would be nice too have too.
I managed to fit two 18650 in parallel in my devo 7e, using single lipo or ion, we can easily charge over USB, as there are many charging circuits avaialble.

I can confirm that the battery monitoring circuitry actually surprised me in it's accuracy. Actual battery voltages from 4.20v to 3.03v were reported as 4.15v to 2.97v (averaging about .05v -.06v low. But note that my particular Pololu 3.3v regulator is putting out 3.33v (1% high). That will cause the voltage reported to the monitor to be low by 1% or about 0.04v. So the actual error in the circuitry is less than 1%. I agree that a vbat scale and offset calibrate parameter would be nice. In the above measurements, the schottky diode to the right of the main board battery socket is still in the circuit. So the formula being used to report the battery voltage seems to be doing a good job of implementing the offset due to the schottky as well as the scale of the battery voltage. While experimenting to get the shutdown parameter save operation to work at low voltages, I put a short across the schottky, which raises the voltage available on the main board by about 0.35v, and makes it easier to keep everything working at the low voltage end of the Li-Ion cell. But with the schottky shorted, the battery monitor reports the battery voltage as 0.32v high (no surprise since the formula includes an incorrect offset). In a situation like this, an adjustable offset would be nice.

I have not had a failure of the transmitter to turn off. I ran more tests down to 2.8v with the 560K resistor reduced even further to 240K, and it now saves configuration at shutdown even at 2.8v

This is indeed of interest, I had problems I could not switch of anymore the TX at low voltage, can you confirm the battery monitoring still works fine doing this mod? Btw a vbat calibrate parameter scale and offset, would be nice too have too.
I managed to fit two 18650 in parallel in my devo 7e, using single lipo or ion, we can easily charge over USB, as there are many charging circuits avaialble.

PhracturedBlue wrote: Once I have my hands on the Tx, I'll take a look at the design and see what they have done. We could ask if they're willing to provide a schematic, that would be a be a good sign of faith, and make things a lot easier. But just to be clear, I'm not willing to sign an NDA for it....If needed I'll just trace out what I need by hand.

Jumper confirmed that T8SG use same power circuit design as Devo7E.

Devo 7e power circuit:
www.deviationtx.com/forum/7-development/...oard?start=100#63244 :


Devo 8s power circuit:

ridgerunner wrote: My brand new Jumper T8SG (delivered 2017-09-23) worked for about 1/2 hour then got permanently stuck in USB mode.

Does anyone know if there's a master reset button inside? (I haven't opened up the case until I hear how Banggood handles my failed unit.)

Hoping that Banggood/Jumper will quickly fix the design problem and make this right.

Have you tried reinstalling the filesystem? If you see the USB logo, it means the filesystem is corrupted. That shouldn't happen, but can theoretically happen if there is a bug in the firmware, and/or the transmitter shuts down improperly. If you don't have access to the USB port then I guess that can't be done without opening it (and as you say, that may be a problem if you want a refund).
The problem with not shutting down was also common on the Devo radios. Maybe Jumper copied Walkera's power circuit (which I never really liked). The issue was caused by a failing switch (Walkera used very cheap switches for the power switch, I would not be surprised if Jumper did the same). The faulty power switch has been known to cause the flash to get wiped as well (d to poor signalling probably). Fixing your radio is probably as simple as replacing the switch with a $1 replacement and reflashing the filesystem, but I can understand you might not want to do that to a brand new radio. The bad switch could also be paired with a bad memory chip, or bad soldering contacts, and those would not be quite as easy to root-cause and repair.

To note, I don't have a Jumper Tx yet, and have not looked closely at the circuit board images in this thread.

www.deviationtx.com/forum/3-feedback-que...be-dead?limitstart=0
In this thread are some tips and a shematic of the power circuit of the Devo 8s (very similar)

vadimus wrote: I doubt they are protected but why is the protection nneede...

I was just wondering cause 17670 is a strange size (not unheard of but not common either) and I have a flashlight that takes max Ø = 17mm but also max length is 65mm so I thought maybe if there's a protection circuit they might actually be 17650's and that'd make them another option I could look for in my never-ending search for more cells to fit this damn thing.

17670's?! Are there protection circuits on them?

Where did you get them?

Arnold wrote:

Deal57 wrote: ...
;enable-cyrf6936=B12
has_pa-cyrf6936=1
...

Just an aside here, Jeff.
You have the cyrf in the tx, but not on the MM, correct?
On the next line your are saying there is a power amp circuit in the cyrf module.
Does that mean you've replaced the standard cyrf module with the "S" version in the tx?
Or does it mean something else? I thought that line about PA in the hardware.ini file was only relevant when using the cyrf module on the MM.

Another question: Why mount a cyrf module on the MM in the first place, since all Devos have one on the board anyway? Maybe 2 is better than 1?

That's correct, he is using the stock CYRF. And that's a reasonable question for which i can only "punt!".

I may have assumed incorrectly, as I've only tested the power functionality on my Devo7e, but I routinely un-comment the line
"has_pa-cyrf6936=1".
In the 7e this enables the use of the power settings for the stock, modified (range mod) CYRF module. Based on searches on this site I cannot tell for certain that it has any effect on the Devos with the "S" version stock CYRF module (6s, 8s, 10e, etc.), but it doesn't seem to hurt on my 6s. When I get a chance I'll check the mA used with and without it.

In any case I don't see that it hurts this situation either way (I could be wrong!). But it brings to mind a question:

@bmw2444: did this multimodule work before you updated your firmware?

I just got mine today. It's like a Cheerson CX-10 clone with way more power. It looks like it has enough power to handle some wind. It also has headless mode and return to home.

I haven't seen anything on here about it being Deviation compatible but...
This review says the FQ777-124 has "CX-10" printed on the green circuit board.
He tried the Deviation CX-10 protocols, with no luck.
Maybe it wouldn't be that difficult for somebody to mod the CX-10 green protocol.
www.rcgroups.com/forums/showthread.php?t=2432513

I hope somebody gets a protocol working for it. I love flying my CX-10 with my Devo 8S, and this one looks like it could be twice as fun.

mwm wrote:

DOONBY4797 wrote: Would it be possible to take power directly from your switches (which ever you choose) and use that to trigger a sound on the sound board? Essentially wiring the board with power and then input from the different switches to trigger that sound?

If the board has a "switch mode" (the ones linked to do, as well as an Adafruit Sound Fx board I bought for a non-RC project), then yeah, you should be able to do that. Personally, I'm more interested in replacing the alerts with voices, so I don't have to guess whether a beep was because the one of the batteries was getting low, poor signals strength, or something else.

I think I'm going to write something to play the stuff in sounds.ini on my desktop....

That's what I am also interested in, Voice! It looks to me like the main circuit board in the TX is integrated ( like an integrated mother board for a pc). So the challenge would be locating what generates the different (beeps) for the given input or signal, I.E LOW BATTERY, LOST SIGNAL ECT... and tapping into that. Sending those given signals to the FX board and triggering the proper sound (voice) for the given input?

I had initially thought about the sounds.ini file but speculated that because it works on simple numbers (b1=100)and letters that using an mp3 or similar type file would not be feasible due to the type of code it uses. Again I am not familiar enough to write code to make this work and do not pretend to understand how it works. would be nice to have a Taranis to tear into and see what they are doing and have an extra Devo to experiment with.

Poldi wrote: Recently I acquired a Win8 tablet, wich I thought would also suit my hobby well since I can easily take it to where I need it with my TX and models. No way: it will not recognize my Devo8S and I fail again to maintain any drivers.

So I desprerately seek help to overcome this USB trouble!

Your tablet will it see usb flash drive ?

I ask because mine has mini usbs and wouldn't. So a cheap usb hub changed stock usb lead for mini usb and still no joy till i shorted sence pin to gnd, then drive appeared. In the i bought proper tablet hub which can charge and power usb devices.
I cant remember off top my head but i'm pretty sure tablet not triggering the usb circuit in tx.
If i'm right it should be 5V from usb triggers Fet in tx which puts 3.3V to pin on mcu which means usb lead is plugged in. Even though its in DFU / drive mode.
Now thinking on maybe usb port on tx is damaged in some way?

Do have a question. I have all 3 A7105/CC2500/NRF with lna+pa and have devo8s upgrade module. Well only need A7105 and CYRF but may as well add them all but I'm happy with with stock CYRF module.
So do i remove it to use it with your circuit or can it stay in place? I'm easy either way and I'll plan my layout. Either way I don't plan on using one pcb to mount all modules. I'm thinking pcb to mount attiny/ISP and new power supply from battery. Mount modules on back panel of Tx, I've looked and there more than enough room.
Something to think about most USBasp are 5v (but some are 3.3v too) modules I've used are ok with 5v logic so don't use USBasp to power when programming but maybe add jumper to disconnect modules? And would it be an idea to contact LazyZero and ask him to add this to lazyzero.de/en/modellbau/kkmulticopterflashtool before you release code ? Me I prefer Winavr command line but its not everybody cup of tea.