Deviation for Devo F4?

I think you're getting confused... when I said that, I was referring to my test with A2. A2 isn't connected to anything at all, it is doing nothing.. it's just a pin that is sitting there all on its lonesome. In fact, if you open up the transmitter and look at A2 (the one I marked in red on the MCU photo), you'll see it's not connected to anything. I mentioned the USB port which is A11 and A12 BEFORE realising that A2 wasn't being used for anything. So, if you use A2, you're not having anything to do with the USB port.

The only time it might give an issue in the USB port is if you use A11 or A12.

Also, I know A2 doesn't conflict with the USB port because I changed the position of the pin, and then AFTER I started up in USB mode and copied the devo.fs file over with A2 activated in the hardware.ini file. So, as I said, A2 isn't doing anything, it doesn't conflict with anything, and it's quite an easy one to solder to as it's the last pin on the MCU.

Epitaph wrote: ... So, as I said, A2 isn't doing anything, it doesn't conflict with anything, and it's quite an easy one to solder to as it's the last pin on the MCU.

So, no downside at all. That's what I'll do, then. Thanks for doing the investigation, finding and proving this!

No, no downside found so far... that said, the only thing I have not been able to test it with is with multiple modules as I only have 1 added module. But to be honest, I don't see how that could cause a problem as it's a completely separate port from A13 and A14, and I know it doesn't conflict with USB, Arduino via PPM, or anything. So I would venture to say no downside at all.

Thanks for the find! What gauge wire do you use to solder to the tiny pads? Or just strands from a multi strand wire?

Not sure what gauge it is, I just use the 40 wire IDE computer ribbon cable. The MCU for the A2 solder of the module is fine to solder with this wire as it's the end pin, so you don't have to start separating strands to do it or anything, just solder it on the side.

Thought I'd publish this in case anyone's interested in doing something similar.

I have a pair of v1 Quanum goggles here, but I never use them because when you start adding the receiver on, and then the LiPo, what with them being already pretty boxy, they felt heavy and awkward to wear. On the other hand, the Devo F4 has a video out jack, but in a nasty place, especially if you fly "tray" style. So I decided to add a connector to make things easier on the back of the transmitter, in this case an RCA connector for video, and I also added a power jack for powering them if need be, or anything else that can use a 2S power supply.



I just connected a JST connector inside so I could separate the 2 halves of the transmitter case in the future should I need to open up again. The red of the JST to the point marked CORE on the picture, and the black to the point marked SHIELD.



Then just solder the other end of the JST to the RCA connector on the case, and that's it.

Seeing as I connected the power jack directly to the battery (to keep everything on one side of the case, and to not have more power going through that single power switch on the transmitter). Seeing as the connector is easy to get things in that could short out the battery, and to just control it a little, I added a small switch to control the power jack on the rear of the transmitter, hidden away inside the battery bay on the "shelf" that's inside... so with the switch off, there's no power at the jack on the back.



I haven't finished the mod yet, as I still have to change things on the Quanum goggles yet, but I have connected the monitor they contain to the RCA and the image is perfect, you can run though all the transmitter menus and make adjustments via the goggles if you want, and you still have the image on the F4 screen... if for example you wanted to show someone else the FPV experience, you can put the goggles on them, and still control the model perfectly via the F4 screen... and with that OSD option djtrance is working on, it would be great!!

About extra switches, PhracturedBlue wrote: ... I probably need to change the code so that you attach to C9 instead of c6 for the tap pin (so you can use the non-diode mod)...

I've been trying to find information about this non-diode mod, but haven't found anything. Can anyone point me in the right direction or provide a workable description, please?

Arnold wrote:

About extra switches, PhracturedBlue wrote: ... I probably need to change the code so that you attach to C9 instead of c6 for the tap pin (so you can use the non-diode mod)...

I've been trying to find information about this non-diode mod, but haven't found anything. Can anyone point me in the right direction or provide a workable description, please?

Why do you want do do that? Non Diode mod goes similar to Devo7e but with "our" connection points

any progress here?

SirDomsen wrote: Why do you want do do that? Non Diode mod goes similar to Devo7e but with "our" connection points

I'm not sure I want to do it, since I don't know the difference from the diode version. That's what I'd like to sort out. I've been procrastinating on the switch connections. I have the switches Installed (2-2way and 4 3way), but not wired yet. Probably time to get moving on it.

Other than this "no progress" report, there's no progress from me.

I'm not sure what you are talking about as in "diode mod"... are you talking about adding switches without diodes or the 7E diode mod for range? The F4 doesn't suffer from that problem as far as I know (if it did, why make an original Devention 100mW firmware?)

Epitaph wrote: I'm not sure what you are talking about as in "diode mod"... are you talking about adding switches without diodes or the 7E diode mod for range? The F4 doesn't suffer from that problem as far as I know (if it did, why make an original Devention 100mW firmware?)

No, nothing to do with range. My question stems from a comment PB made (see my earlier post #52565) in which he mentioned a non-diode mod. That set me to wondering what that was and if it has any benefit.

It's not much of a benefit... you save a dollar in diodes, and that's it.

Epitaph wrote: It's not much of a benefit... you save a dollar in diodes, and that's it.

I may have already wasted that much on brain power just pondering the question.

I have been using the Devo F4 as my primary micro-quad Tx, mainly because I have added the 3-in-1 module and now I can fly almost all the tiny toy quads that are available. however, I see that whenever I make a few changes to the models stored on the Tx, the filesystem gets corrupt. Some changes work and persist, but some just kill the filesystem, and I need to reflash the F4 all over again. (Flash the original firmware, turn off/on for the original firmware to format the storage location, flash the deviation firmware, flash devo.fs).
Does anyone else see this issue too? The size of my devo.fs is around 54KB 42KB now with about 6 protocols and 8 model files.

I suspect you're getting too close to filling the available space on the F4, which is 60kb. As you make changes to your models on the radio, the .ini file expands to a larger size and you may be exceeding the limit. This can cause file corruption.
If you are copying the devo.fs file from your computer to the F4, I suggest you try a different method. Using the Buildfs tool, send the output file (devo.fs) directly to the F4 instead of sending it to the computer. And consider not changing the model config on the radio. Let me know if you'd like more guidance on doing this.

I can confirm some instability of the devo.fs. Sometimes everything works,fine, but I have the feeling,when,I power it up after a longer time, the,FS sometimes crashes. Also if you change too much things on a model file. I have 34kb of size. PhracturedBlue mentioned one time that there were made some improvements in devo.fs stability with later nightlies - I can confirm that, too. Problem is better now but not gone.
Unfortunately none of the Gurus here is working on it I guess. And as I'm not a coder, I only can wait and offer my help for trying things they change out...

Yeah, that is what I usually do. I use the buildfs to directly create the devo.fs on the TX instead of saving it and transferring it over. I do keep a copy of all the changes that I make on the TX on the buildable rootfs I flash from. It's just that sometimes, even if I do not make any changes, the filesystem crashes. I somehow suspect that the TX saves the trim settings when it shuts down which causes writes to the filesystem and so now I trying to cultivate the habit of returning all the trims to neutral before switching the TX off.

On 22 April 2016, at 15:56, SirDomsen wrote: ... Wiring as in the pictures. Tried the latest nightly - the switches work now as expected...

I used SirDomsen's pix from this post (#47103) as my guide for connecting switches SWA & SWB, but I get the trim beeping. I connected two 3-way switches. The first attempt was without diodes and the result was that the radio would startup in USB mode unless I centered the switches first, then it would start normally, but I couldn't get past the trim beeps with every button press. So, the second attempt was with diodes and this time the radio starts OK, but still getting the trim beeps and won't proceed.
So, how can I get rid of the trim beeps? I find no clues from reading the thread.

> Edit: I changed the switches. Now have 1-3 way and 2-2 way, just like Sir Domsen. But Still have those beeps.

sensaurabh wrote: Yeah, that is what I usually do. I use the buildfs to directly create the devo.fs on the TX instead of saving it and transferring it over. I do keep a copy of all the changes that I make on the TX on the buildable rootfs I flash from. It's just that sometimes, even if I do not make any changes, the filesystem crashes. I somehow suspect that the TX saves the trim settings when it shuts down which causes writes to the filesystem and so now I trying to cultivate the habit of returning all the trims to neutral before switching the TX off.

Can confirm, when you trim your quad, it's most likely that the FS crashes - can you confirm that if not trimmed, it does not crash? I think i never recognized that relationship between trims and crash...